Morphing Code to Prevent Reverse Engineering?

ptolemu writes "Cringely's latest article discusses a new obfuscation technique currently being researched called PSCP (Program State Code Protection). An informative read that concludes with some interesting insight on the software giants that heavily depend on this kind of technology."

Comments

do what i do

[theMerovingian]

delete all the white space, and comment in Hungarian

Re:do what i do

[AntiOrganic]

Just name all of your variables in Hungarian notation like Microsoft. No one will have any idea what the fuck is going on even if your entire source code leaks.

Re:do what i do

[Dark Lord Seth]

Comment?

Re:do what i do

[kfg]

Ok, I tried that. It really works.

In fact, it obfuscated my Python code so badly even the interpreter couldn't figure out what the hell it meant.

Maybe I need to improve my Hungarian.

KFG

Re:do what i do

[Anonymous Coward]

Az a baj, hogy vannak azok kozolunk, aki angolt is es magyart is ismerik. A magyar nyelv nem lehetlen nehez megtanulni es megerteni. Sot, ezek is forithatnak a "csak angol-beszelo" reszere.

(The problem is, that there are those among us who speak both English and Hungarian. The Hungarian language is not impossibly hard to learn and understand. Heck, these folks could translate for the "only-English speakers.")

--AC

Re:do what i do

[BobGregg]

>>delete all the white space, and comment in Hungarian

Ha, you laugh. At my first job, the documentation for our product (a medical management system) was written by the original software developer - who was Hungarian. Screen after screen, there were pages filled with explanations like this:

LOBExpCode. This is the LOBExpCode for the system. Enter your LOBExpCode here.
NGFTSMapC. This is the NGFTSMapC for the system. Enter your NGFTSMapC here.

And so on. And no, no data dictionary. Occasionally there would be half-pages of attempted explanation in extremely broken English. Even our own developers couldn't tell what half the stuff did. So that's one form of code obfuscation...

Re:do what i do

[Ernest P Worrell]

Hungarian is the old standard. Microsoft is now encouraging a pascal/camel case type notation. New focus: readability.

Re:do what i do

[Anonymous Coward]

Proof positive of the undeniable advantages of offshoring!

Re:do what i do

[AbbyNormal]

Hope I never have to code review any of your work.

Re:do what i do

[stratjakt]

Never saw the unreadability of hungarian notation, myself. Like any syntax, it takes some getting used to, but I find it so useful to see a variable called giInstanceCount and know its a global integer.. or miInstanceCount for a class level, etc..

The scope tag is probably more useful than the data type.

Re:do what i do

[74nova]

that's just so abnormal it confuses people, it doesnt actually obscure anything unless you comment incorrect information.

Re:do what i do

[Ernest P Worrell]

Well, the idea is that, with strongly typed languages and a powerful IDE, you can quickly see the scope and type of any variable with a mouse over.

I was a big fan of Hungarian, but the more I think about it, most variables (so long as their not named Tmp, i, j, etc), are pretty obviously typed. InstanceCount sounds like an integer, DateReceived sounds like a time, FirstName, a string. Now that i've switched to descriptive names, i haven't run into a problem yet of not knowing the scope/type.

Re:do what i do

[loucura!]

You mean you don't know the scope of Tmp, i, and j?! What's wrong with you? Tmp is obviously a global string, i is a class level float, and j is a local pointer to a linked list. Jeez, programmers these days.

Re:do what i do

[Anonymous Coward]

apparently, these coders are not embedded coders w/ time and space limitations.

Re:do what i do

[SpaceRook]

What? You mean most people don't know what dwbzlsptlzdbkCount is?

Re:do what i do

[B'Trey]

I'm not a fan of Hungarian notation but this is quite simplistic. Is InstanceCount an int, a long or a short? Or is it a pointer to one of the above? Is FirstName a C-style string (ie a char *) or is it an instance of class String? Is DateReceived an int holding a Unix-style number-of-seconds-from-some-starting-date, is it a string holding the date (and in what format?) or is it an instance of class Date?

Hungarian notation was designed for large, multi-developer projects where you're frequently working on or with code you didn't originally write and the answer to questions like the above aren't necessarily obvious or quickly answered. It's one thing to say that HN is ugly or introduces other problems of its own (a stand I agree with) but it's another to say that the problem it addresses is non-existent or is easily solved by descriptive variable names.

Re:do what i do

[GeckoX]

Read the post he was responding to and you just might get it.

Re:do what i do

[Bugmaster]

I have always thought that if you need Hungarian notation to tell if "userName" is an integer or a string, then your program is too messy. Instead of using "lpszfoobarName", it would be better to organize the program to use smaller functions (methods, whatever) and more compact modules.

Hungarian notation is only truly useful in classic Win32 programming, because by now it's really its own programming language based loosely on C, where lpszfoobar takes the place of strong typing. But, if you're starting a project from scratch, you don't need to support legacy LPARAM/WPARAM/WPARAM_which_is_really_LPARAM, and thus there's no need for hungarian notation. Especially if you use a strongly-typed OOP language such as Java, and, AFAIK, C#.

Re:do what i do

[tmasssey]

Sadly, most of the Indian programmers I've spoken with have better English than most programmers I've met (or comments on Slashdot I've read), never mind L337 HAX0R D00D$...

Re:do what i do

[__past__]

i is always an integer with local scope, used as a counter in a loop and/or an index into an array or a similar collection. j, k and l are the same, if you need more than one variable that would qualify for being "i". This convention is perfectly clear and has been used for more than 40 years; calling "i" "index", "count" or "currentEmployeeIndex" does not carry any interesting surplus information. The same could be said for "n", which always is an integral number denoting the number of elements in some collection to operate on.

tmp is less clear, but it certainly would have local scope, and only exists because of shortcomings in the implementation language (like not having a primitive operation for swapping the values of two variables without introducing a temporary variable), but no real significance in the problem domain.

These variable names are perfectly acceptable and clear - unless you abuse them, of course, but you can abuse all nameing schemes. Nothing stops you from calling a global integer m_pszHelloKitty.

Hungarian notation on the other hand is problematic because a) it is just a non-functional workaround for the weak typing in C and C++ (and their habit to make type errors crash your program in random unrelated places, or just corrupt your data) and b) there aren't actually enough rules, and if there were, nobody could remember them all. "iSomeInteger" and "sSomeString" are pretty common, but if you happen to use more interesting types, or even a whole C++ class hierarchy, it just doesn't work anymore. The only use of Hungarian Notation is to make clueless middle managers happy, similar to a long-winded format for mandatory comments preceding any trivial function or multi-page e-mail disclaimers. Source code is readable when you can actually read it out loud and people would understand whats going on, not if you encrypt redundant information in variable names.

Re:do what i do

[Zooks!]

Of course, if you don't know what the type of a variable is you can also just look at the type declaration.

Unless you're using something like BASIC where variables just suddenly appear out of the ether I really can't see how Hungarian notation is necessary. Especially in an age where we have advanced editors with split windows, and powerful search tools like glimpse, cscope, and ctags.

Besides, why should I trust some agglutinated letters on a variable name when I can do the same thing the compiler will do and look at the type declaration and be totally _sure_ of the type of the variable? What if some doofus changed the type of the variable in the declaration but was too lazy to update all the instances of Hungarian notation? Hungarian notation can only lead to a code maintainence nightmare!

Re:do what i do

[Anonymous Coward]

The point is rather, do you (have to) care?

Re:do what i do

[Anonymous Coward]

Boy, if only there were some way to unambiguously declare the type of your variable. You could put it right next to where you declare the variable, or where it gets passed into the function. And then, if you needed to change the variable's type, you could do it from that one location. If only this were the case, we could get rid of the ugly maintenance nightmare that is Hungarian Notation.

Re:do what i do

[angst_ridden_hipster]

The problem with Hungarian, of course, is that it lies.

It's like the comments. They tell you what the programmer *meant* to do, not what he or she did.

Similarly, Hungarian notation tells you the *intended* scope, type, etc, but the compiler may have a very different view of things.

Re:do what i do

[Anonymous Coward]

Hungarian Notation:

For those programmers unable to grasp the commands for CTAGS (or ETAGS).

Re:do what i do

[jelle]

"Is InstanceCount an int, a long or a short? Or is it a pointer to one of the above? Is FirstName a C-style string"

Those are questions that the editor/gui should be able to answer without the need to add typing work for the programmer. I'm sure there are a lot of variables with erroneous hungarian notation, either because of programmer error, or programmer misunderstanding, or a 'forgot to update that' type of thing...Usually no information is better than misinformation.

Re:do what i do

[JWW]

Man, I wish I still had some mod points.

I absoultely despise Hungarian notation. Back about 7 years or so one of the less skilled developers where I worked thought that Hugarian notation was the answer to all our development problems.
Needless to say that wasn't exactly the case.

Although, that person does now work for Microsoft.....

Re:do what i do

[Dalcius]

That sounds pretty bad.

The company I work for has some legacy code still in use... written in Fortran and originally developed on some old unix system. The compiler limited variables, function names, program names, etc. to 5 characters.

5 characters.

Combine that with the lovely syntax of Fortran 77, tons of gotos, pages of variable declarations, sparse comments, NO whitespace whatsoever, and then picture yourself debugging that for a living.

And if that weren't enough, our sourcebase was purchased from a German company. Up until a few years ago, German comments could still be found.

Yes. Laugh it up. :)

Re:do what i do

[Anonymous Coward]

That's because they don't learn from American schools. My son's lunch menu routinely offers "Taco's" as the Wednesday entree. My son is in fourth grade and already he'd like to know who Taco is and whether he brought enough food for the entire school. I'm not ready to try to explain CmdrTaco to him.

And the poor results are hardly limited to programmers. I feel certain that the management did not consist of programmers at the restaurant I saw with a sign proclaiming that they were under "new management", complete with the scare quotes. I presume that means the same people, but they received some sort of training, or perhaps lobotomies.

Re:do what i do

[jcr]

calling "i" "index", "count" or "currentEmployeeIndex" does not carry any interesting surplus information.

Ever try searching for "i" in a modern IDE?

Long names are good.

-jcr

Re:do what i do

[__past__]

Long names are good

Sorry, but I can't agree with that without further qualification.

The language I use most of the time is Common Lisp, which started as a compromise between several Lisp dialects that have evolved since the late 50ies, together with new functionality designed in the 90ies. This lead to standard function names ranging from cdr and rplacd to update-instance-for-redefined-class. While there are more or less consistent rules explaining either of these, I think they are all bad. The trick is to come up with names that are both unambigous and short. This is very hard (and the fact that ANSI CL defines nearly 1000 names, all on one package, doesn't help). In fact, I often have the feeling that coming up with good names for my functions, classes etc. is harder than their actual implementation. But it is also more important, because that is what others will have to use and understand, and communication between humans is a more serious issue in programming than communication with the computer.

Besides, any sensible IDE would allow you to search for an exact name or at least a regular expression, so that a search for "i" would not find all mentions of "update-instance-for-redefined-class".

Re:do what i do

[the_diesel]

For the love of God and all that is Holy, never use the letter 'l' as a variable. Why? k = 1; l = 2; m = l + k; depending on your font, it may be very hard to figure that out, especially if you are skimming. Also, it's better for to double up, as in: ii = 1; jj = 2; which makes searches and replaces easier. Still, you don't want: kk = 1; ll = 2; mm = ll + k;

Re:do what i do

[Anonymous Coward]

> Ever try searching for "i" in a modern IDE?
>
> Long names are good.

Try searching for "i=" or "i++" or "i+=" and you might have better luck.

In any case, if you're searching through your source files for an index variable, you have bigger code management problems than variable naming!

Re:do what i do

[rossz]

Not a problem, I'd just have my wife translate for me.

Re:do what i do

[William Tanksley]

Ever try searching for "i" in a modern IDE?

Long names are good.

I agree with your conclusion, but your rationale is lacking. Yes, I've tried searching for 'i' in a modern IDE; it works perfectly well. Matter of fact, I search for it in vi, and it works perfectly well too, because 'i' and other short variables are only for local scopes -- I can find where they're defined by shifting my eyes upwards, and maybe pressing page up once.

Yes, not all code is good. But if you have a choice between a short index variable and a long one, you're writing the code. Write it well, and the length of the variable won't matter.

-Billy

Re:do what i do

[StormReaver]

"I have always thought that if you need Hungarian notation to tell if "userName" is an integer or a string, then your program is too messy."

I hated Hungarian notation when I was first exposed to it (expecially the horrendous form Microsoft uses). I have, however, found a very good use for a limited version of it. I had tried posting a code example, but that damn stupid Slashdot whitespace filter rejected the posting. It involved containers and counters sharing the same root name, but with datatype prefixes for easy organization.

I can use the same root name (Names) with the data type prefixing the root name. This works especially well when my method manipulates several container objects.

For those wondering, I get the size of the vector in its own counter variable before starting the loop mostly for efficiency. It's faster than calling vecNames.size() for each iteration within the loop. With hundreds of methods, those saved cycles can become noticable.

Basic prefixing is also quite handy when my methods grow beyond the height of my development window. For those readying the inevitable "your method is badly designed it it takes more than one screen": in most nontrivial software, well planned and implemented methods can easily grow beyond that size.

Re:do what i do

[NoOneInParticular]

Why on earth would you like to search for "i"? It's there, it's local scope, and usually only valid inside loops. Do:

for (int i = 0; ...;...)
do_stuff
// i is not valid here
for (long i =...;...;...)
do_stuff

Why would you need to search for "i" in code set up in this way?

Re:do what i do

[Anonymous Coward]

No, Indians speak much better English than we do. And they use it day to day in the business world.

Re:do what i do

[Bugmaster]

Er... I must confess, I find it hard to understand your "names" code without the code example :-( Damn you, whitespace filter !

I agree that methods can grow 2 or even 3 screens long, but in practice this happens rarely -- and, even when it does, it's usually still pretty clear what's going on. The method serves some specific, limited purpose, and thus there's very little room for confusion.

BTW, I don't think you're exactly right about calling vec.size() in a loop: AFAIK, the compiler is smart enough to optimize such calls away for you. We tested this on Sun's own JVM a couple years ago, and this turned out to be true... Of course, I can't speak for any other JVM out there, but I suspect most of them perform loop unrolling, subexpression collapsing (or whatever it's called), etc.

Re:do what i do

[Anonymous Coward]

tell that dumb bitch to get a professional web designer.

Re:do what i do

[BillyBlaze]

for (int i = 0; ...;...) do_stuff;
// i is not valid here

Yeah, that's how it's supposed to be. But not how it is in Microsoft's compilers (at least up to VC++ 6).

Re:do what i do

[red floyd]

I never use "i" as a loop index for that reason. It's always either "j", "idx", or "index", depending on the context.

Re:do what i do

[red floyd]

Nah. Just write in APL (or perl :-P)

Re:do what i do

[key45]

"Is InstanceCount an int, a long or a short? Or is it a pointer to one of the above? Is FirstName a C-style string"
Those are questions that the editor/gui should be able to answer

I use vi, you insensitive clod!

Re:do what i do

[darnok]

You don't have to be a non-English speaker to write code like that.

Many years ago, I inherited control of a R&D team. A year or so earlier, they'd hired a contractor for a couple of months; this contractor had created a ~1000 line Perl module that had acquired "sacred code" status since he'd left.

Any attempt to alter, extend or tweak the sacred code in any way resulted in it failing. It was totally bereft of comments, frequently had multiple commands within a single line of code, lots of "magic" regular expressions, and variable names that didn't make sense to any of us. Most variables had global scope, variables were frequently reused for no apparent reason and it didn't even have blank lines between functions.

I know Perl is frequently a write-only language, but this was something else. I can't believe a human could actually produce code like this on purpose; he must have used some sort of Perl obfuscator.

Everyone in my team was terrified of the sacred code, as they knew working on it was doomed to failure.

One of the most enjoyable times I had on that job was when the guy who created the code came back and asked for more work...

Re:do what i do

[Anonymous Coward]

you can abuse all nameing schemes

Clearly. :)

Re:do what i do

[Anonymous Coward]

The whole point of 'i' is that you only use it locally. If the area within which a variable called 'i' exists is more than a few lines, then it probably isn't a simple loop index - and in that case, yes, you do want to give it a meaningful name.

Re:do what i do

[wideBlueSkies]

So in other words you were writing Perl code. :)

wbs.

Re:do what i do

[lyphorm]

i is always an integer with local scope, used as a counter in a loop and/or an index into an array or a similar collection. j, k and l are the same, if you need more than one variable that would qualify for being "i". This convention is perfectly clear and has been used for more than 40 years; calling "i" "index", "count" or "currentEmployeeIndex" does not carry any interesting surplus information. The same could be said for "n", which always is an integral number denoting the number of elements in some collection to operate on.

I suppose that would be true of your own code, but when you have to work on something written by others, you can just forget all those assumptions. I've seen k used as a global variable referenced in 20 different functions (this is C I'm talking about). And the horror of horrors:

extern int i;

And I've seen "temp" variables abused so much it's a useless moniker.

I do agree with what you are saying. The problem is people producing crap for code and no naming convention will cure that. But I still prefer to stay away from single character variable names.

Re:do what i do

[Anonymous Coward]

/\bi\b

Re:do what i do

[Inthewire]

Although, that person does now work for Microsoft

So he's smarter than you?

Re:do what i do

[annodomini]

Ever try searching for "i" in a modern IDE?

Long names are good.

Sorry, I'm going to have to disagree. First of all, if you're using "i" in the common idiom, you should never have to do a search for it. All of the uses of i in the current scope should fit into 20 lines or so. And I can't see any reason why you'd want to do a global search for something that's used as a local variable.

Names should be as long as they need to be, and no longer. Local iteration variables only need to be one character, because all of their uses fit on the current screen, and they're used pretty often. A variable (or, more likely, function name) that is used infrequently, but in places all over the code, should probably be long enough to fully describe what it means, since people will likely have forgotten what it means in between times they've seen it.

Having to look at code which reads
someRidiculouslyLongFunctionName(SomeOtherLongFunc tion(fooBar, bazQuux), thingamadoodle);
can be really painful, and this then causes people to split code up over multiple lines, which leads to a reasonable amount of code no longer being able to be viewed in one screenful, which makes it much harder to read and edit code.

Long names are not good, when they are for a local variable which is used many times in a short piece of code, and it is clear what a short name represents. Long names are good when they are used for possibly confusing names, names that are used globally, and names that are used infrequently.

Re:do what i do

[God! Awful 2]

Hungarian notation on the other hand is problematic because a) it is just a non-functional workaround for the weak typing in C and C++

C++ has weak typing? Source?

-a

Re:do what i do

[szo]

Yes, please do. My salary would rise to the skies :)

Szo (hungarian)

Re:do what i do

[Karellen]

No, I only use vim. However, I can search for the variable "i" by typing: /\

which means:

/ = search for
\ = end of word

which finds the next occurrence of "i" as a distinct word in the current file. Easy. If your "modern" IDE can't do that, I'd really have to question just how useful (as opposed to covered in useless bells and whistles) it actually is.

K.

Re:do what i do

[__past__]

char *foo = "example";
Employee *emp;

emp = (Employee*) foo;
emp->fire();

This is weak typing. A strongly typed language does not allow treating objects as instances of types if they aren't actually. C and C++ are of course statically typed, i.e. you have to declare types of variables, but that is something different.

Re:do what i do

[iantri]

Is this a coincidence or a very subtle Monty Python reference?

Re:do what i do

[God! Awful 2]

Okay, I don't actually have a C++ compiler on this machine, but I am pretty damn sure the above code will generate two compiler errors due to illegal typecasts. Admittedly, the language lets you subvert the typing by casting through void *, but that's because C++ provides strong type-checking *and* full control.

If you define "strong typing" to mean that the programmer can't subvert it even if they try, then fine. But C++ provides strong type checking for many things, and it also provides native run-time type checking via dynamic_cast and RTTI (if you are willing to pay a performance penalty similar to what a "strongly typed" language would incur.

-a

Re:do what i do

[Anonymous Coward]

"Those are questions that the editor/gui should be able to answer..."

Absolutely. Now if we could just convince IDE developers that they should implement that...

Re:do what i do

[SlowMovingTarget]

Agreed, coming up with good names for functions can be very hard. You've got to love design patterns, not only do they lead you to common structures, they lend their names also.

I have a fairly good idea what FooBarFactory.newFoo() is going to do.

Re:do what i do

[rossz]

My (Hungarian) wife says, "if your Hungrarian post is a machine translation, it's not bad."

Re:do what i do

[Ralp]

I think you missed the point of the parent poster. The beauty of 'i' is that you should never have to search for it. Its entire scope should fit on the screen.

Of course if you're writing a very long loop or one that does anything much more interesting than just iterating through a series of elements, then it would be wise to consider if a more descriptive name might make things clearer. But in short loops, if you use anything longer than 'i' (or 'j', etc) then this longer variable name can, in fact, draw attention away from what is really going on in the code. It's short because it's supposed to be ignored.

Are folks really using obfuscation for Java?

[tcopeland]

I've done mostly server-side work where:

- the jar files were secure because they were on the server and
- bytecode optimization and jar size was the least of our problems

Obfuscation seems to be useful only for client-side Java applications that contains super-secret valuable algorithms. I mean, who cares if somebody decompiles your code to see how you did sortable JTables or whatever?

Re:Are folks really using obfuscation for Java?

[Dukael_Mikakis]

I agree. With my experience at a company that develops in Java, those that use Java become lethargic and lazy such that the actual code itself is typically very uninteresting (as Java does all of the "optimizations" that a developer in other languages could tool around with). Beyond that, most of the developers in my company are obsessed with performance because Java crushes our performance.

But then again, our software isn't on 90% of all computers or whatever, so I guess we're less worried about exploits.

Re:Are folks really using obfuscation for Java?

[Tassach]

Java works best as a server-side language; it's well suited to that role.

If you need a tamper-resistant client-side binary, don't use Java. It's that simple. A good engineer understands many different tools and selects the best one for the job.

Re:Are folks really using obfuscation for Java?

[Jackdaw Rookery]

Yep, that was my thinking too. Does it matter if it's pretty standard java stuff?

It's not like this will stop anyone anyway, it would make the reverse engineering process longer that's all.

Just keep your uber secret java code server side, use your tools well.

Re:Are folks really using obfuscation for Java?

[Unoti]

You mentioned lazy programmers, and having Java crush your performance. In my experience with Java, perceiving that the language is crushing performance is often a symptom of the programmers becoming lethargic and lazy. Perhaps you're having the same experience and don't realize it?

Re:Are folks really using obfuscation for Java?

[Anonymous Coward]

Mostly people will use an obfuscator to hide the fact that the applet is logging in to a database using an administrator account. Good luck.

(note to moderators: this is true)

Re:Are folks really using obfuscation for Java?

[Dukael_Mikakis]

The two things probably work in coordination. From my experience, Java does generally represent a performance drop from, say, C++. And so I think that's true regardless.

I think on top of that, Java does so much stuff, like garbage collection, that programmers don't need to worry about it. But the Java optimizations are always implemented conservatively. If I did my own garbage collection, I could free the memory as soon as I'm done with it, but under Java GC is done only periodically, and only sweeps items that fulfill certain qualities (so it might not get everything as soon as it should).

But you're right, a big part of it is that under Java many developers might be able to code sloppily and not worry too much because they have the defense that "it's the Java that's making it slow".

Re:Are folks really using obfuscation for Java?

[Jorrit]

If I did my own garbage collection, I could free the memory as soon as I'm done with it

Or you can do like many C++/C projects do and simply forget to free the memory (i.e. memory leaks).

Greetings,

Re:Are folks really using obfuscation for Java?

[TooTallFourThinking]

Or just make reverse engineering tools that much more sophisticated.

Re:Are folks really using obfuscation for Java?

[pragma_x]

Yes, although I cannot speak to having used it directly myself. I have, however done some research into the topic. Some of the better (commerical) techniques I've seen involved encrypting/encoding class files and restricting their use to a custom ClassLoader of some kind. This would result in a binary file that is complete gibberish to a standard Java runtime environment using the standard ClassLoader. Granted this isn't truely secure as the decryption key/algorithm has to exist within normal Java code someplace. It really just boils down to more obfuscation, not completely unlike what the author mentions in the article.

Re:Are folks really using obfuscation for Java?

[Anonymous Coward]

I don't use obfuscation, but I've seen many applets around that do.

As for the server code - many times there is some weirdo limitation or restriction that's in the app server code that you can actually decompile/fix yourself to get it to work. (I especially likes those that require a `special key' to open functionality - just decompile, change the file, recompile, stick it first in class path, and walla... it's all `fixed').

BEA, TOPLink, etc., those you can decompile and `augment' yourself if you felt like it.

Re:Are folks really using obfuscation for Java?

[Grishnakh]

If you need a tamper-resistant client-side binary, don't use Java. It's that simple. A good engineer understands many different tools and selects the best one for the job.

You're obviously not living in the "real world". Here, an engineer uses the tool that the PHB management selects for him, based on buzzwords, what competitors are doing, and what schmoozing vendors have sold to them.

Re:Are folks really using obfuscation for Java?

[__past__]

If you need a tamper-resitant binary, don't use anything that can be executed natively by any known processor architecture either. Compiled code for the JVM might be slightly easier to understand than code compiled for the x86 arch, but there are good decompilers for both.

If a CPU can understand your code, so can a human. The solution to this problem are licenses, not obfuscators.

Re:Are folks really using obfuscation for Java?

[rolling_bits]

Oh yeah, a good engineer will dump good development environments like VB, Delphi, etc to favor the fashioned languages. Perhaps because in the end the engineer does what the manager wants. VB and Delphi are dying a slow death.

Re:Are folks really using obfuscation for Java?

[Anonymous Coward]

Reminds me of discussions way back when with C, Pascal and C++. People would not switch from assembler because C was too slow with too much overhead. The Pascal P-System was slow too. C programmers don't want to use C++ because it is so much less efficient than C.

After you get through all this silliness you find out that particular implementations and programming techniques were the root cause of any real or perceived slowdown.

Move forward a few years and Object Pascal is one of the most efficient, although less popular, implementation tools with faster compilation. Java is moving in that direction to.

The bottom line is how well are things working now for you. JITs and AOTs compilers are being used with Java, C# and other OO languages with great results.

Re:Are folks really using obfuscation for Java?

[radish]

The two things probably work in coordination. From my experience, Java does generally represent a performance drop from, say, C++. And so I think that's true regardless.


I disagree, the theory of an optimising JIT compiler (such as HotSpot) disagrees, and a whole bunch of studies disagree. But you are entitled to your opinion.

If I did my own garbage collection, I could free the memory as soon as I'm done with it, but under Java GC is done only periodically, and only sweeps items that fulfill certain qualities (so it might not get everything as soon as it should).


Firstly, there are a number of GC strategies available, you only describe the most common. Secondly, what is the performance hit of an object staying around for too long? As soon as memory becomes tight the JVM will become more aggressive with GCs in order to free up space. If memory is not tight however, then NOT doing a GC is actually more performant (a no-op is always faster than a dealloc). Thirdly, Java GC is not really "conservative". An object is eligable for collection when (and only when) the reference count is zero. Off the top of my head I can't think of any reasonable argument that says it is safe to dealloc an object to which there is a live reference. If you know that the object is dead - just null the reference and voila - it's eligable for GC. In the apps I am responsible for the number one overriding priority is reliability - memory leaks, buffer overflows and magically vanishing objects are way too much of a risk and hence C++ is not a suitable environment for us.

Re:Are folks really using obfuscation for Java?

[cxvx]

Thirdly, Java GC is not really "conservative". An object is eligable for collection when (and only when) the reference count is zero.

Minor nitpick, that is not completly correct.
An object can still have references to it, and still be elegible for gc'ing. That is what Weak- and SoftReferences are used for.

From the API docs:

Soft reference objects, which are cleared at the discretion of the garbage collector in response to memory demand. Soft references are most often used to implement memory-sensitive caches.
Suppose that the garbage collector determines at a certain point in time that an object is softly reachable. At that time it may choose to clear atomically all soft references to that object and all soft references to any other softly-reachable objects from which that object is reachable through a chain of strong references. At the same time or at some later time it will enqueue those newly-cleared soft references that are registered with reference queues.

Re:Are folks really using obfuscation for Java?

[Dukael_Mikakis]

I've coded projects in both Java and C++ (and benchmarked them, actually), and in my experience (which is just that) the C++ ran more quickly than Java. You're entitled to disagree. Where I work we use OptimizeIt which does help things out, but our software still runs absolutely dreadfully (I won't deny that likely much of it is the programming itself). But I still stand by my contention that C++ allows you to run faster than Java. It allows you greater control (directly) and doesn't impose any of the overhead of hierarchy that Java does.

I enjoy Java and program in Java and will confess that the stuff they include is usually useful (our software would probably be fscked if we didn't have GC or any of these other features, they just degrade performance (and I believe they have to). I would love to hear your response.

When I describe the mark and sweep method, it is the most common, and will likely be the most frequently used. However check here for an analysis of the other types. If garbage collection were a lightweight, trivial process, then why would Java need to implement 6 different schemes?

Incidentally, we tried testing the various different schemes here and it was a mess trying to get anything out of it.

Yeah, all you have to do is null the object and it'll be collected. Keep in mind, though, that in C++ you just do a delete (or a dealloc) and it's gone, you don't need to scan the whole environment doing reference counts and then doing the corresponding deallocs.

I agree that Java is fine, and it's sturdy, and it's a delight to use, it's just that (all the way up to the great-grandparent) I think that he got it right when Java programmers are (rightfully so) more concerned about all these optimizations (why do you think they're necessary?) than about any sort of run-time security.

Again, just my opinion.

Re:Are folks really using obfuscation for Java?

[reynols]

Here, an engineer uses the tool that the PHB management selects for him...

Unless you do what I have managed to do, *so far*, which is to use your favorite non-MS language for client side development regardless of them claiming they're an MS shop. And when they do find out, you say it was the best tool for the job and ask them if it is worth it to convert the perfectly functional program over to the "other" language--and go glassy eyed when they start talking about future support issues, company standards, finding other developers to replace me when I "get hit by a bus" who also happen to know my "obscure language", blah blah blah...

Re:Are folks really using obfuscation for Java?

[Anonymous Coward]

Or you can do like many C++/C projects do and simply forget to free the memory (i.e. memory leaks).

That's what RAII is for. All your dynamic memory is automatically freed when the containing object is destroyed.

Actually... I tend to do manual memory management, and it's been a long time since I've had any memory leaks. (and I would know, my apps tend to run enough cycles that the existance of leaks would be obvious) Maybe the guys on these projects you speak of should look for a career where you don't have to occasionally pay attention.

Re:Are folks really using obfuscation for Java?

[Haeleth]

>From my experience, Java does generally represent a performance drop from, say, C++. And so I think that's true regardless.

I disagree . . . and a whole bunch of studies disagree. But you are entitled to your opinion.

Would you be willing to reference some of those studies? I'm familiar with the theory that suggests JIT might be able to outperform ahead-of-time compilers, but while I see it regularly cited on Slashdot by fans of $INTERPRETED_LANGUAGE, I have never seen anyone provide figures

Do you have actually evidence that Java can outperform C++, or are you just referring to the theoretical possibility that it might?

Re:Are folks really using obfuscation for Java?

[Anonymous Coward]

C++ has something called auto_ptr (kinda crappy) and the BOOST smart_ptr library (very nice).

No need to remember to delete memory allocated to pointers, they'll do it automatically.

For more info, see:

http://www.boost.org/libs/smart_ptr/smart_ptr.ht m

Re:Are folks really using obfuscation for Java?

[gnupun]

I too remember arguing with a friend about C++. Back then, professional programmers had just switched from assembly to C. And almost everybody was certain that C++ was waay to slow for "real" applications. Almost a decade later, and C++ is now considered fast and Java slow.

Re:Are folks really using obfuscation for Java?

[slamb]

> > Thirdly, Java GC is not really "conservative". An object is eligable for collection when (and only when) the reference count is zero.

> Minor nitpick, that is not completly correct. An object can still have references to it, and still be elegible for gc'ing. That is what Weak- and SoftReferences are used for.

You're right, but that's not the whole truth. Back in the day when Java did not have weak or soft references, objects could still be eligible for collection while being referenced. To understand this, imagine a program's memory as a directed graph; allocated memory blocks are vertices, and non-null pointers are edges. Then say certain things are "grounded" (I'm making up a term here; I don't know the proper one) - stacks of live threads and statically allocated memory. A vertex is eligible for collection if and only if there are no (strong) paths to it from a grounded vertex. (Strong path = one not using weak or soft references.)

So when does this actually happen? Well, you can represent a tree in memory, and you might have a reference back to the parent node. (Assume you're not using these new reference types, for backwards compatibility or whatever reason.) Then your graph has a cycle. If you remove all outside references to the tree, there still are non-zero reference counts there. Yet the garbage collector can learn that it is not reachable and dispose of it.

If it weren't for this problem, we wouldn't need garbage collectors. We'd just use reference counting and be done with it. Maybe it'd be advantageous to keep a data structure of stuff that could be freed rather than immediately doing so in some situations (for responsiveness when there's no need to free memory any time soon) but that's as far as anyone would ever take it.

Re:Are folks really using obfuscation for Java?

[Arker]

My first thought on reading the article, was another, more sinister, purpose for obfuscating client-side apps, and I can't believe no one else thought of this but I haven't seen a comment mention it.

The sort of morphing obfuscation routines he mentions would make virus detection a hell of a lot harder, don't you think?

Re:Are folks really using obfuscation for Java?

[Chainsaw]

You're obviously not living in the "real world". Here, an engineer uses the tool that the PHB management selects for him, based on buzzwords, what competitors are doing, and what schmoozing vendors have sold to them.

I'm not following you here. Are you implying that Sweden isn't part of the real world? My company has developed several applications for very different purposes. Our non-PHB just tells us what the end result should be like, and the engineers select the best method to get there. C or assembler for low-level vehicle programming, C++ (actually, Borland C++ Builder) for GUI applications, Java on Linux for server-side development. We select the technology, make it work and the Boss can keep on doing his favourite duty: send out invoices to our customers.

That's the world I'm living in. Plus paid overtime, five weeks of vacation etc etc. Welcome to the real world.

Re:Are folks really using obfuscation for Java?

[Tassach]

[P]aid overtime, five weeks of vacation etc etc. Welcome to the real world.

Sounds nice. How hard is it for an American to get a job in Sweden? Know of anyone who's looking for a SQL + *nix guru over there?

Re:Are folks really using obfuscation for Java?

[Chainsaw]

You shouldn't have much problem if you really wanted a job. The language barrier might present a problem at some times, but they should be few and far between. Children are being taught English from a very early age (used to be 10, think it's even earlier now).

Don't know of any open positions with those qualifications, but I would recommend looking at anyone of the smaller firms (up to 50 people). It gives you greater responsiblilty, but also provides you with more challenging tasks and actual appreciation of your wizardry.

Re:Are folks really using obfuscation for Java?

[rjshields]

I think the biggest beef that developers have with Java regarding its garbage collection is its non-deterministic finalisation. This means that you have no guarantee if or when the memory held by your objects will be freed. There is no way to explicitly free memory allocated by the JVM. This doesn't often matter, except quite a lot.

If you have file handles and other resources you need to free up in an object, you have provide your own method to do so (or override Object.finalize(), remembering of course to call super.finalize(), or you may inadvertantly create a memory leak) and remember to call it explicitly. This is not the best solution.

In C++ determinstic finalization, you are guaranteed that an object's destructor will be called when either a) an object goes out of scope (in the case of a stack based object) or b) you call delete (in the case of a heap based object). You can use the object's destructor to free up resources, as you have the guarantee that it will be called.

I'm not debating the advantages of garbage collection, my major beef here is that Java's creator has taken control away from the developer. Many would find that patronising. I doubt this is a problem in most situations or for most developers, but for those situations where you need to manage your own memory, sorry, you're screwed.

It should also be noted that should you want to use garbage collection with C++, you can use one of the freely available garbage collectors out there, such as this one.

Reverse engineering is not the problem

[geoffspear]

It's not the ability to reverse engineer code that creates security problems; if it was, open source code, which you don't even need to reverse engineer would be much less secure. The problem is just badly written code.

This technique might be interesting for stopping people from stealing your closed source code, but as far as security goes it's pretty much worthless. 99% of the vulnerabilities in MS's code were found before their code was leaked, and if you believe them, even the major exploit found after it was leaked had more to do with bad code than someone finding the existing problem by reading the code.

Re:Reverse engineering is not the problem

[chimpo13]

Where are you getting the 99%? I think with leaked code, it'll get worse.

Re:Reverse engineering is not the problem

[meta-monkey]

There are reasons beyond "theft" for wanting to obfuscate your code.

For instance, consider Quake. Quake is a great deal of fun, so long as everybody is playing fair. However, when somebody cracks the game and develops an aimbot (they're real), it's not fun anymore. Even if Quake were open source, some kind of run-time obfuscation would be great just to help prevent cheaters.

I recall reading about an exploit for Age of Empires (or was it Age of Kings...) where in a networked game, you could run a monitor program that would let you see what resources your opponent had. Then, by watching changes in their resource supply, you could guess what units they were building. That was automated for you, of course. "Ah, they keep spending 45 wood and 25 gold, they must be building archers! I should build cavalry."

Anyway, even when we're not talking about greedy corporations protecting their intellectual property rights, there are still good reasons for keeping what's going on in your program hidden from prying eyes.

Re:Reverse engineering is not the problem

[Anonymous Coward]

Two words:

"trade secrets".

If someone can reverse engineer a software DVD player, then he can reimplement it without paying for the trade secret from the DVD CCA. In addition, the implementation can leave out the no-skip "feature" and region coding, which are part of the deal when you buy the trade secret.

Re:Reverse engineering is not the problem

[meta-monkey]

they are now, that nobody plays them. They were most certainly not open source when they were released.

Re:Reverse engineering is not the problem

[Anonymous Coward]

Actually, Quake3 is Open as well (Although not under a GPL style licence). All the game logic is available and can be modified (into these things called "Mods').

Re:Reverse engineering is not the problem

[Dukael_Mikakis]

It's just like the axiom about divorce that goes something like "It's not the fact that divorce is legal that's killing our marriages, it's the bad marriages that are causing so much divorce."

Because of the n millions of lines of code in Redmond it's certainly daunting to actually go through and make good code out of the mess, rather than the obscurity.

The fact that there's an open vulnerable port is a flaw, and the FIX is to make the port secure, rather than to shift its address every five seconds or whatever, which is only a Band-Aid.

MS is just lucky that the bulk of its customers don't truly know what's going on, otherwise the business model they have wouldn't work.

I.e. since I'm not a doctor, my doctor can prescribe whatever for me, or insist that I do whatever, and I'll take it as scripture. If what he recommends is the stupidest thing in the world, or he's blatantly a horrible doctor, I would have no idea and suffer the consequences. If I were also a doctor, though, I'd be able to call shenanigans the very second he did something wrong. That's why educating the consumer is the most crucial point of this whole issue.

Re:Reverse engineering is not the problem

[Macrobat]

Details of Quake reverse-engineering can be found here. But I'm not so sure obfuscation would have helped in this case. It seems like Quake's design just put too much information in the hands of the client systems; it might have taken a day or two extra to decode, but the question is, why was such data allowed to be controlled by the client in the first place?

Re:Reverse engineering is not the problem

[luiss]

The examples you give in your post are examples of the "...badly written code" that geoffspear was talking about in his post.

It's "badly written" in the sense that it allows cheating. I'm not saying it's easy, but someone will figure out how to write games that do not allow cheating.

When researchers throw thier hands up in the air and declare it impossible, then maybe you would have a point.

Re:Reverse engineering is not the problem

[Li0n]

"However, when somebody cracks the game and develops an aimbot (they're real)"

Say it isn't so! :(

Re:Reverse engineering is not the problem

[inertia187]

Maybe it'll get worse. But I think the people who know where to look for vulnerabilities already have the insight. The people who need to look at the code are probably not as big a threat as the people who don't.

Imagine someone who can just guess where a buffer overrun might be and someone who has to view the source to realize the same thing. Which one is more likely to write a more effective exploit?

The source leak has it's ramifications, but I think those ramifications will manifest as better competition for Microsoft, not better exploits. Imagine how well Samba will integrate now that there's a better reference. Not that I condone that kind of thing, mind you. :-)

Re:Reverse engineering is not the problem

[Frizzle Fry]

Imagine how well Samba will integrate now that there's a better reference

I didn't think that SMB was in the portion of the code that was leaked. Was it?

Re:Reverse engineering is not the problem

[Anonymous Coward]

the question is, why was such data allowed to be controlled by the client in the first place?

Because Quake is old, and when it was released, most players were still on 28.8 modem connections. In other words: a lot of stuff was left on the client for the purpose of saving bandwidth.

The Quake 1 source wasn't released until a couple years later. So there was no reason to obfuscate it, since it wasn't out there* (yeah don't get me going on the history of id Software).

* wasn't _supposed_ to be out there. There was a copy of at least part of the Quake 1 source floating around the warez channels for awhile, courtesy of crack dot com.

Re:Reverse engineering is not the problem

[Rallion]

I think it pretty much is impossible in RTS, in a client-client model, at least.

One client's machine can not ever be trusted to watch it's own action and make sure it's within the rules, ever. The only alternative is to let the OTHER client(s) check, and then they have too much information.

There's no middle ground, see. It's not a complicated issue. What more research can you do?

Re:Reverse engineering is not the problem

[Slime-dogg]

"It's not the fact that divorce is legal that's killing our marriages, it's the bad marriages that are causing so much divorce."

I'd take it even further than that, and say "It's not the fact that divorce is legal that's killing our marriages, it's because divorce is legal that people don't think twice about getting married."

Re:Reverse engineering is not the problem

[Cebu]

"I.e. since I'm not a doctor, my doctor can prescribe whatever for me, or insist that I do whatever, and I'll take it as scripture. If what he recommends is the stupidest thing in the world, or he's blatantly a horrible doctor, I would have no idea and suffer the consequences. If I were also a doctor, though, I'd be able to call shenanigans the very second he did something wrong. That's why educating the consumer is the most crucial point of this whole issue."

An educated consumer seems nice in theory, but we can't all be lawyers, engineers, scientists and mathematicians. I'm sure if I were a doctor I would have a much better chance of calling the "shenanigans" of another doctor, then again I wouldn't know very much about algorithms or computational analysis.

Regarding your Band-Aid comment:
Say you are trying to prevent exploits to faults in your applications. If code obfuscation buys you 8 months of breathing space, while fixing all the faults would leave your application open to attacks for 18 months, I'll take code obfuscation... for now at least.

Obfuscation might be a useful stop gap, a method of increasing the complexity of attacking released products, and probably quite a great deal more. In the end, obfuscation is just another tool -- and in my opinion a useful one.

Live code bases are usually far from ideal, and the problems which arise from maintaining a code base are far from simple: you do what has to be done; whether that is fixing flaws, using a better development process, bolting on boiler plate, or providing quick dirty hacks to fix issues.

Re:Reverse engineering is not the problem

[Soruk]

No sane developer will look at that code, let alone refer to it or borrow bits. Otherwise M$ will have a good case for closing their project and suing their arses off.

Re:Reverse engineering is not the problem

[CaptnMArk]

/callvote insta_weapon 1

Re:Reverse engineering is not the problem

[IncohereD]

I think it pretty much is impossible in RTS, in a client-client model, at least.

Then change the client-client model, is the more research you can do.

If you still wanted to stay with a two person model you could send your data to a third party playing the same game, who would verify your data, and you would verify theirs. And you could massively distribute this.

One thought would be to be if one person accused you of cheating, you'd have to get your data verified by more people around the country, etc, etc, so you couldn't say just one person had a vendetta against.

This is a solvable problem. You just have to get past the old "playing across town over the modem" model.

Re:Reverse engineering is not the problem

[MisterFancypants]

Because Quake is old, and when it was released, most players were still on 28.8 modem connections. In other words: a lot of stuff was left on the client for the purpose of saving bandwidth.

You're essentially right, but I have to point out that the problem won't go away with 28.8 modems. Even on very fat broadband connections, aimbots remain and will continue to remain a problem that requires obfuscation on the client-side. Until we have networks so fast and latency free that the 3D rendering occurs on the server and the server sends full frames of pre-rendered graphics to the client (note: this day is a long way off, if ever) you'll have this problem.

Re:Reverse engineering is not the problem

[drinkypoo]

Because Quake is old, and when it was released, most players were still on 28.8 modem connections. In other words: a lot of stuff was left on the client for the purpose of saving bandwidth.

hurts bandwidth use. That stuff was left on the client because it becomes prohibitively CPU-expensive to have the server do all that processing. When Quake figures out if you can see something, it uses BSP-trees as its first line of occlusion culling. This was to reduce CPU load, because otherwise occlusion culling takes much more work, and computing for everything on a level with every frame is awfully CPU time-consuming. The server would have to process all of that stuff for every client to determine what data to send to each client, which means that the CPU time used would scale up with the number of players, probably about linearly, and rapidly overpower the computer one is trying to run it on.

Re:Reverse engineering is not the problem

[Erik Soderstrom]

As far as I know, Quake has been open source since 1999, and as far as I know, FuhQuake (opensource client derived from Quake/QuakeWorld and ZQuake) has no cheats what so ever, because they load a external security module. If you want to contribute to FuhQuake with code, you can, cause it's all open source. Its just that security module that is closed source. So what's the problem with having "all of it" open source, except the part where your "top secret security crypto" goes?

Re:Reverse engineering is not the problem

[zangdesign]

That's why educating the consumer is the most crucial point of this whole issue.

I don't disagree with you, but it ain't gonna happen. Consumers (users, lusers, what have you) are far too busy with other things to learn something that has been more or less promised to "just work", even if it means ignoring reality.

Most of the problems that happen in the real world, viruses, trojans, and hackers, happen to "someone else", and even if it did happen to them, they don't know enough to even recognize that there's a problem and they need to ask questions. They know that what used to work, doesn't work so well anymore.

Part of the problem is that we made computers easy to use (which was the right thing to do, regardless), but we also allowed marketing and advertising to sell it as the perfect solution to every problem when it clearly isn't. It's all well -intentioned, but we missed the mark in the process.

It's probably too late, now, anyway so there's probably not much we can do.

Re:Reverse engineering is not the problem

[orangesquid]

I know this is kinda OT, but, where did the term "aimbot" come from? Years back, I made this bot for AIM, called it AIMBot (the obvious), and got hundreds of people e-mailing, very confused about how to get CounterStrike to use aimbot.c.

*sigh*

Re:Reverse engineering is not the problem

[inertia187]

Yeah, the nonchalant attitude of Linus' "don't ask don't tell" policy is probably over, then.

Re:Reverse engineering is not the problem

[mindstrm]

Quake is a poor example, because it's not about security, though the client-server model parallels. THis is a case of putting processing on the client end because it's faster to do so, and the overall system is far more workable. Yes, it does mean people can cheat in certain ways.. that didn't stop the game from being a wild success.

A better example would be online gambling... if the javascript on the website or the java client or flash client are responsible for validating data, and the server just takes what it is told, you have a disaster waiting to happen. Client side validation should be done for aesthetic and usability purposes only, not security.

Re:Reverse engineering is not the problem

[kurtras]

I'm going to go out on a limb here, but, what's so wrong with reverse-engineering games to develop bots?

You call them 'cheaters', I see it as changing the dynamic of the game--it's no longer about how well you play the game, but how well you program your computer to play the game. And what's wrong with that?

So you're playing a multiplayer game and your opponent starts using a bot to get ahead...so why not load up your own bot then?

-Kurt

Re:Reverse engineering is not the problem

[RaymondRuptime]

But isn't it great to see so much money being spent to prop up the closed source system? I think these guys are "The Mole"...

Re:Reverse engineering is not the problem

[Anonymous Coward]

MS is just lucky that the bulk of its customers don't truly know what's going on, otherwise the business model they have wouldn't work.

No, they aren't lucky! There business model won't work much longer, but since it has worked for so long, they won't be able to change fast enough to fix what's wrong.

Re:Reverse engineering is not the problem

[Rakarra]

You call them 'cheaters', I see it as changing the dynamic of the game--it's no longer about how well you play the game, but how well you program your computer to play the game. And what's wrong with that?

So you're playing a multiplayer game and your opponent starts using a bot to get ahead...so why not load up your own bot then?

Because it's cheating, and it's not at all what the person signed up for. When I go to play online, having the expectation that the game isn't hacked and people aren't cheating to get ahead isn't unreasonable. You want to change the game dynamics? Fine, do it on your own server. Invite your friends, others, whomever. Just don't involve people who actually want to play the game the way it's supposed to be played, or at least not without their permission.

Re:Reverse engineering is not the problem

[SerpentMage]

While in the simplest form I agree, overall I disagree.

"All's fair in love and war" is what I would respond. To me these extra add-ons is an arms race to build the ultimate client. Frankly I am sure it would make the game more interesting if there was a market for this "arms" race.

Re:Reverse engineering is not the problem

[Tokerat]

And what's wrong with that?

It's cheating.

Play on servers which encourage you to use modifications, some people want to play the game as it was originally intended, they don't want to play YOUR game.

Also, gamers aren't all programmers, and by your description, unless youy write your own aimbot, you're just a skr1pt k1ddie with someone else's skr1pt, which is lame. The game becomes "Who can Google for the best cheat proggiez".

If I wanted to play hacking games, I'd buy Uplink.

Enough

[Tebriel]

The code I write is obfuscated enough as it is. I'm my own anti-piracy mechanism.

Re:Enough

[Mick Ohrberg]

I agree - I think it's hard enough to write non-obfuscated code, so why try to obfuscate it more?

Re:Enough

[metlin]

So you code in Perl too, eh?

Re:Enough

[Speare]

My one and only attempt at writing obfuscated Perl: The Pentominos-Solving Quine.

Re:Enough

[Anonymous Coward]

Only a Tcl hack would say that.

Re:Enough

[carlmenezes]

Nah, he probably uses LISP.

Re:Enough

[Anonymous Coward]

x86 assembly without macros.

Wonder Twins.

[Kenja]

Wonder Twins power, ACTIVATE!

Form of, illegible code.
Shape of, encrypted executables.

Not sure where the monkey fits into all of this.

Re:Wonder Twins.

[Anonymous Coward]

The monkey wrote the code, I think...

Re:Wonder Twins.

[Anonymous Coward]

Not sure where the monkey fits into all of this.

That's the code monkey. He's the poor guy that has to write all that crap rather than something useful.

Re:Wonder Twins.

[DreadSpoon]

Simple. The monkey *watches*. ;-)

http://www.penny-arcade.com/view.php3?date=2002- 06 -12&res=l

Re:Wonder Twins.

[Hentai]

The monkey watches .

Re:Wonder Twins.

[Anonymous Coward]

Gleek the Space Monkey? The Wonder Twins came to earth with their pet monkey, Gleek. Gleek is a blue monkey in a superhero costume. He is intelligent and can follow directions, but usually gets in trouble. Gleek cannot talk, but can make space monkey noises, principally "Gleek!"

Gotta wonder what sort of chemicals that dude was taking when he created Gleek. The Space Monkey. Who wore a cape.

Re:Wonder Twins.

[Anonymous Coward]

I for one welcome our new Coding-Monkey Overlords.

Re:Wonder Twins.

[Anonymous Coward]

Once you have the Wonder Twins, Gleek was just obvious. Also everybody loves monkeys.

I hated the Wonder Twins! they took a lot of time away from Supes, Bats and Bats. Batman r00lz! I know that in the final chapter he killed the Wonder Twins and kept the monkey.

Re:Wonder Twins.

[Mandomania]

The monkey watches :)

--
Mando

Re:Wonder Twins.

[Mr. Piddle]

Sadly, it is actually true that most male slashdotters can program using only their large breasts leaving their arms free to eat sandwiches pre-warmed in their six-keg.

Mod Parent Redundant

[Mateito]

After all, these nothing that these guys could come up with that ROT13 doesn't already do!

Won't work

[sosume]

It just won't work. Any code that can be run can be reverse engineered. So-called sophisticated coding techniques only lead to unreadable code..

Re:Won't work

[Anonymous Coward]

How does this work relative to the GPL?

In other words, let's say I download the code to the linux router project, make some additions and enhancements for my proprietary hardware platform, and sell my product commercially.

Now the GPL forces me to release my source code. Fine. I'll release it, but I'll release the obfuscated source code. Is this legal?

Sure, it could be reverse engineered, but isn't the obfuscation a significant barrier to interested parties, and a violation in spirit of the GPL? Does the GPL prevent this tactic?

Re:Won't work

[Chairboy]

> So-called sophisticated coding techniques only lead to unreadable code..

That IS the point, I'm sure you realize.

Re:Won't work

[supersmike]

I'm not a low-level guy, so I'm probably missing something here, but douldn't you have encrypted byte-code that get's decrypted on-the-fly or something? Or are you saying that the minute it gets translated into machine-executable code, there are ways to step-in and intercept that code?

Re:Won't work

[jfengel]

Sure, you can reverse engineer it. But is it worth the effort?

Most of the time it's not even worth reverse engineering unencrypted code, because it's really hard. There are open source projects that go undone because people don't want to expend the effort.

The trick is not to make it impossible, but to make it hard enough that it isn't done. That level is different for different projects, but it's always finite.

Re:Won't work

[Dukael_Mikakis]

Yeah, it's like adding another lock on a door.

All you need to do is figure out the scheme that the obfuscator uses and reverse engineer that. Ad finitum.

Re:Won't work

[Anonymous Coward]

The writers of the GPL anticipated your point and so the GPL specifies that the source must be presented in "the form preferred for making modifications" or something like that.

Re:Won't work

[tealover]

I believe he was talking from the perspective of the developer, which leads me to believe he doesn't understand the issue that is being discussed.

Re:Won't work

[alan_dershowitz]

The GPL explicitly states source code must not be obfuscated.

Personally though, I think advanced obfuscation would make it REALLY easy for closed source applications to conceal swiped GPL code. I'm sure its already happened, but up to this point, you could do some binary comparisons, or trace it in runtime. With this stuff the article was talking about, you couldn't do that anymore. What's to stop companies from violating the GPL license? their own sense of ethics. Yeah, we're in trouble.

By the way, if someone's interested in investigating a possible GPL violation, take a look at the Dolphin Gamecube emulator. Their last version had error messages from a GPL powerPC emulation core, and the binary is obfuscated :-/

Re:Won't work

[Deadstick]

I remember a primitive attempt at this in the copy protection routine for dBase III way back when the DMCA was but an industry wet dream. This was the ProLok Disk, the one with the laser burn.

There was a section of code hidden by about forty layers of byte-by-byte XORing against bytes looked up in a table. At each level, it would intercept the Debug and Single Step interrupts, XOR the next layer, and jump into it. In those floppy-only days, it had to be reverse engineered a layer at a time, each step producing a disk with one less layer. Approximately the 40th disk had the actual copy-test code...which turned out to be pirated code!

This was also before BIOS shadowing in RAM, and the BIOS executed straight from ROM. The test for the laser burn required hooking into it, which of course they couldn't do in ROM. Instead of working out their own shadowing routine they copied some 700 bytes of the IBM Fixed Disk BIOS, inserted their hooks, and then made a weaselly attempt to cover their tracks by interchanging logical-shift with arithmetic-shift instructions wherever it was guaranteed that nothing would go through the carry bit.

And all that meshugass was there only to hide the publisher's own piracy...the copycrack consisted of a two-byte change elsewhere on the disk.

rj

Re:Won't work

[mugnyte]

Well, that seems a bit simplistic. However, when I take a look at running code, there are several things that don't jive with the article:

One forms logical boxes around things. For instance, a good cracker knows to identify the boundary between the JIT and the bytecode, know where the security check call is made, and what threads are monitoring the heap and garbage collector.

When cracking, you initially "freeze" the code, the machine, the stack, and the registers. You're working at such a low level, it begins with a step-by-step of understanding how everything fits together.

For example: Imagine the .NET framework itself in a sandbox. You watch as the OS is fed an EXE, it identifies the type and starts to run it. The CLR (potentially) starts up and checks permissions, loads all the JIT stuff, etc. Then, bytecode is churned. You are stepping one instruction at a time, interrupting at each of the CLR's instructions. One notices the buffer used for the JIT and the "feed" going into it. Tools are written that do this watching and drop items (portions of files, by instruction) into logical "components" and each pass becomes a little clearer. By running the application and matching behavior to component, you begin to learn how the application is designed.

Also, you look at the program file itself. THIS is what the article seems to be saying: the bytecode is obsfucated...without context clues you're not going to discern how it works. But you can snap up context many times with a cracking tool. In this article, they seem to imply that each snapshot will be different by scrambling the variable names, or program locations. By seeing how all the names have been crammed, a pattern develops.

Also, I take issue that .NET can be both "open" and yet "secure". Unless the bytecode SPEC is proprietary and unable to be reverse engineered (it is neither, hence the "open" nature of it), one can form a CLR that processes valid-yet-obsfucated code and rebuild a logical image of how the program is designed. I can take the MONO bytecode runtime have it start to partition the code into blocks and examine, for the calls each block makes to layer beneath it, what it is allegedly doing.

Lastly, what makes these tools immune from reverse-engineering themselves? If I know the patterns this DASH-stuff uses, I can begin to reverse them. Unless there's one-way hashing or hardward/networked keys flying around, everything to solve the puzzle is right there, for me and my friends to examine at our leisure. This is done today by virus writers to try to avoid detection by checkers; they know how they work.

If this tool becomes actually as valuable as he claims, then I expect it's own design (stolen or RE'd) to appear in the cracker circles like any other.

But perhaps I'm missing something?

Re:Won't work

[Anonymous Coward]

Sounds like you could patent a method to efficiently reverse engineer code despite constant change.

Aren't patents always worth it?

Re:Won't work

[Fulcrum of Evil]

The only thing even close is "the source code for a work means the preferred form of the work for making modifications to it." I don't see that as explicitly ruling out obfuscation.

Try telling the judge that you name all your variables v0001, v0002, v001, and so on. Simply stated, obfuscation is something you do specifically to stop somebody from understanding the code.

Re:Won't work

[Golthur]

Yes, but this is a simplistic solution that still won't work. Once programs obfuscate themselves as they run, someone's going to make an automated tool to de-obfuscate it - e.g. a custom VM that justs dump out the bytecode on the path of execution as it executes it to a file.

Automation just breeds counter-automation. It's an arms race, and I don't really think JITO (Just In Time Obfuscation) is the answer.

Re:Won't work

[Phemur]

You've either missed the point or misread the article. It's not a coding technique, it's a run-time technique.

Phemur

Re:Won't work

[FuzzyBad-Mofo]

And all that meshugass was there only to hide the publisher's own piracy

Hilarious.. I'm sure there's a lesson in there somewhere.

the copycrack consisted of a two-byte change elsewhere on the disk.

Ah, but knowing which two bytes to change is the point of the whole exercise. I've cracked a number of "protected" C64 software titles, where the protection was almost always based on intentional disk formatting errors. The simpler ones simply tried to read the "bad sector", and used the error code as a key to continue loading.

The most devious protection I've cracked was on "Indiana Jones in the Lost Kingdom", where the routine would read a sector from the disk (containing garbage), then XOR it with the same sector. Performing this operation manually produced nothing useful. I examined the disk's low level format and discovered the trick: There were two tracks with the same ID! It turned out their routine read the first track 20, then XOR'd it with the second track 20. This produced the missing loader code, and thus the game was cracked.

Re:Won't work

[alan_dershowitz]

Quothe the GPL: "The source code for a work means the preferred form of the work for
making modifications to it."

Quothe Dictionary.com: "obfuscate: To make so confused or opaque as to be difficult to perceive or understand"

If you alter the source to make it hard to read, you broke this rule. To merely say "obfuscate" is actually _more_ vague than what the GPL says, in my opinion. My code is already obfuscated, simply because I'm a lazy programmer.

Re:Won't work

[Gr8Apes]

Easy enough to decompile any code, honestly. If it runs on current common hardware, it can be decompiled, and you're done, although the refactoring may be hell.

Re:Won't work

[pla]

Sure, you can reverse engineer it. But is it worth the effort?

Exactly the core issue with this entire topic...

Anything that can run, you can reverse engineer. I don't care how complicated the author makes it, if all else fails, you can always run it in an emulator and step through, instruction by instruction.

So, having personally done that as a firmware engineer, what would it take to make it "worth" doing, particularly on deliberately opaque code?

How about cracking DRM? Considering that MS dominates the market, whatever scheme they eventually go with will represent the DRM to defeat. Think of the fame that "CSS Jon" won, just for fronting the guy that traced through the CSS algorithm... Imagine the same, for something far more ubiquitous and difficult.

Then, you also have the illegal profit motive, which though unkosher, we cannot rule out. If tech-X uses protection-Y, where piracy of tech-X stands to make a lot of money, do you suppose some of the "big" players, such as the Mafia, might feel willing to spend the time and money to crack it?

So, while I agree, we should ask "does run-time obfuscation of my code make sense", we also need to ask ourselves "Should I bother, since this may prove so important that someone will crack it?". Interestingly, this seems like an almost symmetric arms-race - The more important (and thus needing protection) a given section of code seems, the more time and resources people will devote to reverse engineer it. Net result? No change in the availability of ready-made cracks. So, why bother?

Re:Won't work

[Ann Elk]

Ah, ProLock, now there's a blast from the past.

In a previous life, I worked in a group that tested third-party software, but my manager was too cheap to buy a separate copy for each tester. (The company will remain nameless to protect the guilty.) One of my "unoffical" job duties was breaking copy protection of new apps (mostly games) so we could all test them.

One day, we were visited by a group of folks from ProLock. Of course, they claimed their protection scheme was completely unbreakable. As if.

Their basic technique was pretty solid. By burning a hole (with frigin' lasers) in the floppy, they introduced physical changes in the media that absolutely could not be duplicated with software.

As Deadstick mentioned, the crack consisted of a two-byte change somewhere on the disk. Basically, at some point the program called a routine to see if the special laser-blasted sector was present. If so, the program continued. The patch was just to pretend the sector was always there.

As an analogy, the ProLock scheme was like putting a bank vault lock on a rice paper door. Instead of wasting time picking the lock, it's much easier to just rip another hole in the door.

Re:Won't work

[ceswiedler]

From the article, I gathered that there IS no single source-code representation of the compiled binary which would be readable. The binary code modifies itself as it runs to produce the correct interpreted instructions. If you decompiled it, you would get the source code for a self-modifying program.

Of course there's still the original source code, so there IS a representation which will run in a straightforward manner. But just because that 'cleartext' version exists doesn't mean you can easily generate it from the obfuscated version. Effectively they've found an encryption technique which requires a compiler to decode, as it runs.

Re:Won't work

[Deadstick]

As I remember, the effect of the laser burn was to "freeze" some bytes in one sector...you could read them but not change them. The test was to write it with all zeroes, read and compare with all zeroes, write with all ones, and compare with all ones. The burn would always create a compare error somewhere in the sequence.

rj

Re:Won't work

[chanceH]

so does this mean you couldn't GPL, say, perl poetry.

Re:Won't work

[thogard]

What that IS the point, I don't care. I look at the code as its running on the CPU or VM. For 90% of it, its trivial to figure out things like loops, assignment, calculations etc. Data structures show up cleanly as well. For some nasty C++ its sometimes quicker to debug the assembly than it is to figure out what is going on in the maze of twisty classes. The source may lie but the CPU doesn't.

Does anyone have a copy of the program xyzzy? Its a very old FORTRAN program that changes all the variable names to combinations of xyz as well as cleans up unneeded whitespace.

Re:Won't work

[UncleFluffy]

The writers of the GPL anticipated your point and so the GPL specifies that the source must be presented in "the form preferred for making modifications" or something like that.

Well, from the article, it looks like this code modifies itself on a regular basis ... so the object code is in fact (or, could be interpreted as by sufficiently well paid lawyers) "the form preferred for making modifications".

Re:Won't work

[Haeleth]

By the way, if someone's interested in investigating a possible GPL violation, take a look at the Dolphin Gamecube emulator. Their last version had error messages from a GPL powerPC emulation core, and the binary is obfuscated.

To quote the developers of the emulator in question:

Yes, we did use the incomplete and pretty bad Microlib PowerPC emulator to ease the initial stages of development. Yes, we have since removed and replaced it.Obviously we missed a few traces of the code, including the reported error message but not much more. Maybe we rushed this preview release a bit, but we really wanted to get something out there. If you feel that this absolutely tiny mishap in this little hobby project that we earn absolutely no money from is a major GPL violation, go sue us.

MSFT

[Anonymous Coward]

Microsoft doesn't need to do this. Windows source code is obfuscated enough.

Virii

[Anonymous Coward]

I can smell the virus from here, and that wont be good.

Re:Virii

[Darken_Everseek]

Thats an excellent point. What happens if someone writes a virus whose code is near-impossible to reverse engineer? Obviously, it'd take more than a script kiddie to pull it off, especially since the technique is patent-pending, but the possibility is interesting.

Re:Virii

[MORTAR_COMBAT!]

Exactly. Anti-virus software relies on being able to identify a virus signature. What if the virus changes its own signature significantly every time it runs?

Re:Virii

[Frizzle Fry]

Obviously, it'd take more than a script kiddie to pull it off, especially since the technique is patent-pending

Because a script kiddie would certainly respect and obey patent laws. And would abide by copyright law by not using a pirated version of the obfuscation program.

Reverse Engineering or Cracking?

[carlmenezes]

Seems to me that they're more worried about software being cracked than being reverse engineered. Not sure how successful they'll be there.

Resource Waste

[Coaster-Sj]

I could see this as useful on small sections of code. Doing this to an entire program would be a huge resource waste.

Re:Resource Waste

[October_30th]

Doing this to an entire program would be a huge resource waste

Unless, of course, it gives you and your company that extra competetive edge.

Re:Resource Waste

[Coaster-Sj]

But the whole program?

I could see protecting any code that was a trade secret. But protecting you user interface code??? We all know what it looks like already.

Re:Resource Waste

[Joe U]

Doing this to an entire program would be a huge resource waste.

Well... I was kinda getting tired of my new P4 running software very fast.

It's like I was thinking just yesterday, 'how can I relive the good old days days of the 8088 but still use a modern OS?'.

Re:Resource Waste

[Draknor]

You could run Windows XP....

Oh wait, you said *modern* OS - so sorry ;-)

Re:Resource Waste

[plover]

No, doing this to an entire program would obfuscate the critical sections, and that's the entire point. A reverse engineer can't just pop in, debug the stuff that looks complex (and therefore must be hiding the good stuff) and pop out again. That engineer will have to start with step one, every single time.

Remember, computers are now large enough and fast enough that there are plenty of cycles going to waste anyway. This theory is that if those idle cycles are spent rearranging the code, the reverse engineers' lives will be more miserable, and therefore the precious code is safer.

OpenSource

[dnoyeb]

Strikes me that OS does not have this issue.

Why would you want to prevent reverse engineering anyway? How hard could it be to just create the application from scratch? Likely much easier than reverse engineering.

And if its security, we know you do not get it by hiding the source...

Fail to see the need.

zzzzzzz

[SparafucileMan]

*shrug* You still have controll over the computer. Just load something of your own mnaking before your OS loads the obfusicator. Interrupt 13, anyone?

Re:zzzzzzz

[Anonymous Coward]

It's not polite to interrupt, unless of course you're dealing with SmallTalk or have a Lisp.

Re:zzzzzzz

[BiggsTheCat]

The obfuscator is not run on the client PC. It is run by the program's author. When the bytecode is shipped to you, it is already obfuscated.

Re:zzzzzzz

[KingRob]

With DRP hardware, you no longer have control over the computer - or at least the decryption process.

Re:zzzzzzz

[Anonymous Coward]

With DRP hardware, you no longer have control over the computer - or at least the decryption process.

That's what you think.

easy to do

[Anonymous Coward]

write really bad code. you don't see anyone reverse engineering Windows, do you?

Re:easy to do

[DarkAurora]

Um... yeah

Not enough eyes to make the bugs shallow...

[bc90021]

The problem with Microsoft's code being readable is that there are only Microsoft people reading it. Half the time they wouldn't see the forest for the trees (since they are so involved with it all the time anyway), and the other half they would miss things that other people might pick up.

With Open Source, *everyone* gets to look at the code, so there any many eyes, and the bugs get shallower.

Re:Not enough eyes to make the bugs shallow...

[LordNimon]

The problem with Microsoft's code being readable is that there are only Microsoft people reading it.

You make it sound as if all Microsoft developers belong to some kind of hive mind. Microsoft has quite a few software people working for them - a lot more than 99% of all open source projects.

Re:Not enough eyes to make the bugs shallow...

[El]

I'm convinced that Microsoft must not practice peer review, so most of their code has only been seen by one pair of eyes. Any Microsofties lurking out their care to correct me on this?

Re:Not enough eyes to make the bugs shallow...

[dtio]

Nonsense. They don't see the forrest for the trees? I beg your pardon?

You're a asuming that there is a Microsoft way to look at code and that every MS developer is a robot brain washed to think that way. MS hire very capable and brilliant people, you couldn't tell the difference between a bunch of NT kernel hackers and a bunch of Linux kernel hackers, both groups are extremely knowledgeable and manufacture high quallity code.

MS has the biggest industrial infrastructure in the world of quallity assurance. Every developer should go trhough an internship in Redmond to see this.

Large software *is* complex, period. Given a finite amount of talent and time, bugs are depedent of the size of the project, it really don't make a difference whether you're code is open source or not.

How many people do you think actually look at open source code to look for bugs?

Moral: if MS releases buggy, exploitalbe and potentially unsafe code is *not* because they are sloppy or because propietary code is inherently worse than open source, is because large software is complex and takes a lot of time to do it right.

Re:Not enough eyes to make the bugs shallow...

[LordKazan]

>I'm convinced that Microsoft must not practice peer review, so most of their code has only been seen by one pair of eyes. Any Microsofties lurking out their care to correct me on this? I doubt they would be allowed to - microsoft probably forbids them from commenting on microsoft's developement processes

Re:Not enough eyes to make the bugs shallow...

[stratjakt]

Except, noone wants to audit code.

It's boring and thankless.

How fast bugs get fixed seems, to me, to rely on a) how many people are finding/reporting them (from testers to users), and b) how many people are working to fix them.

Obviously MSFT has more users, and since Windows likes to phone home kernel exceptions, I'm sure they have the most data on bugs. The second factor though, I dont know. I dont know how many people MS has working on Windows, and of those people who's tasked with which components. I do know that so far as the linux kernel goes, it's a handful of folks doing most of the work. Of course, the whole OS is much bigger..

Yeah, the code is there, but how many people actively debug it? I use linux, and when I have a bug/crash/whatever, I jump onto google to find a fix or workaround. I don't have the time nor, frankly, the inclination to step through the code, find it, fix it, submit a patch, blah blah..

Re:Not enough eyes to make the bugs shallow...

[interiot]

After seeing the extreme comments in the source code, I had the same question, since I don't think I could ever go comments like that past any peer review I've been a part of. Someone I know said that Microsoft hadn't done peer reviews previously, but now that they're on the "we're increasing security" kick, that they've started doing code reviews on a more organizational level. (though by the time you read this, this is fourth-hand info, so caveat reader)

But maybe it's not all PR hype, who knows.

Re:Not enough eyes to make the bugs shallow...

[Draknor]

Although I enjoy Microsoft bashing as much as the next /.'er, this is bordering troll-ish.

As much as we may hate to admit it, there are a lot of smart people working at Microsoft. To think they would simply ignore peer code review (isn't that considered an industry "best practice"?) is silly. Maybe some smaller projects, *maybe*, but even then I'd be surprised if there wasn't at least a couple sets of eyes looking over the code.

I'm sure Microsoft has deadlines and management pressures to deliver, same as just about any software company, and peer review may not always be 100% comprehensive (and not nearly as extensive as open-source procedures), but I'm sure its there.

'Course, I have no proof to back up my claims either, so I could be just as ignorant as parent! :-)

Re:Not enough eyes to make the bugs shallow...

[EddWo]

Not a Microsoftie, buy seen enough of them mention it happening to think that at least some of it must go on. Microsoftie Blogs seem to talk about their development process quite often. Still they may only have adopted them in the last few years.

Re:Not enough eyes to make the bugs shallow...

[stevey]

Except, noone wants to audit code.

Some people still want to audit code.

Although it has to be said it's not something many people have the time or patience for.

Re:Not enough eyes to make the bugs shallow...

[Anonymous Coward]

MS has the biggest industrial infrastructure in the world of quallity assurance. Every developer should go trhough an internship in Redmond to see this.

As an aside, in software quality assurance alone, pretty much all the telecom vendors and many military contractors beat MS all to death with thier programs. Think 5-9's of availability, and you-pay-us-millions if you fuck up. OR, oopsie, my code killed people.

Your statements presume facts that are not in evidence.

TFOAE.

Re:Not enough eyes to make the bugs shallow...

[El]

As much as we may hate to admit it, there are a lot of smart people working at Microsoft. No argument from me there. I've personally known some excellent people that went on to work for M$. (Although now that you can no longer get rich off of M$ stock options, they are losing a lot of good people.) That's why I'm looking for other explanations for their poor performance. My M$ experience is rather dated, but I've personally fixed bugs by rolling back to the previous version of MFC -- that's right, the Microsoftie thought he was fixing a problem, but instead he created a much worse problem! Since I could read the source and see the mistake, it's obvious it wasn't subject to any review. Procedures in others areas (e.g. the OS itself) are probably more stringent. I don't envy Microsoft the task of trying to be backwards compatible with every previous version of software and every possible permutation of hardware out there, but let's face it: their results suck. Whether this is due to failure to follow best practices or due to being driven entirely by Marketing instead of Engineering is beyond my abililties to answer.

Re:Not enough eyes to make the bugs shallow...

[Anonymous Coward]

... is *not* because they are sloppy...

Microsoft's problem isn't sloppiness -- it's due to a culture where features are more important than reliability. It's due to a culture where there's a belief that you can "test quality" into software.

You can take the best people in the world and have them produce inferior software... all you have to do is put them in an environment that doesn't require quality from product conception and upward. Putting too many interfaces in a product (whether they are user features or network ones) dooms a product to being mediocre.

Re:Not enough eyes to make the bugs shallow...

[10am-bedtime]

i already found a bug and haven't even looked at the code in question: separate QA and programming "teams". when the inherent reflection required of Quality assurance is excised from the responsibilities of those w/ write privs, well, it's no surprise that quality is not assured. in fact, it's almost guaranteed that quality is censored.

please don't advise new programmers to study usloth or the misbegotten practices used there. instead, they would do well to read zamm by pirsig, tool about a bit on two wheels to have fun w/ the art of equilibrium, and move the code about in their heads instead of through their fingers.

Re:Not enough eyes to make the bugs shallow...

[Anonymous Coward]

i already found a bug and haven't even looked at the code in question: separate QA and programming "teams".

Have to disagree here. Independent QA is crucial to sucessfully developing quality code. Without it, you have, roughly speaking, the developers word that it is both complete, and correct. Systematic testing by a third set of eyes is needed. Afraid that developers will get lazy and say "QA will catch that."? Make Acceptance Testing the first thing the QA team does before/when development hands off the product.

The real bug is if there's lacking of accountability between QA team and development team for the bugs found by QA. If they can't enforce that certain problems be fixed, up to and including saying "We can't ship this", you're just wasting money paying a QA team.

Sometimes, I wonder if that's exactly what MS does...

TFOAE.

Re:Not enough eyes to make the bugs shallow...

[jizmonkey]

Absolutely, but non-showstopper bugs will go unfixed to make the scheduled ship date, and those bugs aren't fixed until later versions. The later versions usually have many more features and therefore more bugs. It's not just a matter of finding bugs it's also a matter of fixing them.

It's ironic

[Dukael_Mikakis]

The medical profession deals with viruses by identifying our weaknesses, and exposing them to the viruses (the ultimate "reverse engineering"?). If there were a biological DMCA, developing vaccines would certainly violate it on the illegality of "hacking into the body".

With software, though, people still insist on trying hide and pretend as if there were no viruses out there and that we would be impervious to them.

Can we finally just open all of our code so we can vaccinate it against all these exploits?

Re:It's ironic

[Anonymous Coward]

Bad example. Imagine yourself to be under going a viral (that has split second impact on you, if you are exposed to it) therapy with private doctor and you are a wrestler. Would u advertise to the world that you are susceptible to xyz virus ? Your opponent could just 'wear' it before getting into the ring with you. You will be done.

Morphing code eh

[Epyn]

I seriously doubt this is anything special, just more code and more code to disguise the code that actually does something. I can't imagine you really CAN protect a program for instance, without completely screwing it up, performance loss etc. These companies should provide the kinds of services and support systems that make investing in their product viable. err yeah...

Isn't this just self-modifying code?

[mveloso]

This looks vaguely like self-modifying code, like back in the old days of copy protection.

The thing I don't understand about the article (and how it describes the PSCP process) is this: how will this make reverse engineering more difficult?

When you're starting to crack something, you work backwards from system calls, library calls, and known behaviors. "Known behaviors" are, well, patterns of code that people (or compilers) use to do things. Anyone good at low-level stuff can probably identify the compiler used to build the code. Likewise, if you think about something enough, you can probably figure out three or four ways to do something, and look for that pattern in the code.

PSCP prevents this...how? By making this process happens as the program runs? How else do you reverse engineer something?

Anyway, it sounds like this thing sits right before the .net runtime engine (or maybe it's loaded and spews bytecode to the runtime), then it can be removed...or the output intercepted. .

What am I not getting here?

Re:Isn't this just self-modifying code?

[pc-0x90]

Java (and subsequently .Net) bytecode made a reverse engineer's life a bit easier on a whole, because of the way it could be decompiled into source that was extremely similar to the original. All this seems like it would do, is remove that benefit and cause the reverse engineer to approach it the same old way one would approach a compiled C program (as you described, with a debugger and hooks on syscalls). Or bust out a new type of disassembler to emulate traces, and dump that to an assembly listing. But you're right, it's not really that mind blowing if the reverse engineer has worked on non-java/non-.net binaries before.

Re:Isn't this just self-modifying code?

[El]

It makes reverse engineering more difficult because you can't disassemble the whole program at once, only the currently running portion. And you don't know what the boundaries between the currently running portion and the obfuscated byte codes are. However, if you just TRACE the running code, you should get a pretty good idea of how it executes under normal operation -- it's not like the actual algorithm changes every iteration. Granted, you probably won't know how it handles most exceptions and boundary conditions, but who cares?

Re:Isn't this just self-modifying code?

[Tophorn]

you've pretty much got this figured out. It's like DRM on audio files; eventually the sound has to come out of the speakers. It seems that if the program is running, then it can be loaded into a debugger and looked at, and if my computer can understand it (i.e. it functions) then the debugger will be able to.

Re:Isn't this just self-modifying code?

[hazee]

Yeah, and self-modifying-code was eventually abandoned because it played havoc with the then-new CPU caches and pipelines.

Have these people learned nothing?

Re:Isn't this just self-modifying code?

[plierhead]

From what I can make out (could be wrong) it blasts out a myriad of possible branches and loops that appear to be program logic but are actually executed solely to confuse the reverse engineer.

If so, this raises a couple of issues:

• Code bloat - very much an issue for a technology targetting client-side apps; and
• It negates Cringley's open source point:

  And there is even an Open Source aspect to this new form of protection: It can be used as a new form of attribution. Who wrote what part of that Open Source program? Copyright notices and comments can be removed, but the PSCP code renaming signature can't be.

  Open source code which can only submitted while obfuscated (thus preserving its signature) is not open source any more, so I don't buy this as a benefit of the technology.

I think the main dangers to people protecting their source code in the medium term will remain what they are now: Incompetence and conspiracy from within (witness the win2k code leakage)

Re:Isn't this just self-modifying code?

[lysander]

Exactly. This doesn't quite seem like the panacea that Cringely seems to think it is.

What I would be worried about is if it obfuscates while maintaining the correctness of the program. Debugging normal code is hard enough. Debugging this would be aggravating to the point of madness.

Historicaly, self-modifying code has either been used to get around hardware limitations (which modern hardware has fixed). In all other respects, it's almost always been a bad idea.

Re:Isn't this just self-modifying code?

[djtack]

Open source code which can only submitted while obfuscated (thus preserving its signature) is not open source any more, so I don't buy this as a benefit of the technology.

Yes, I was puzzled by his statements about watermarking open-source code. You would still have to distribute the original, unobfuscated source to allow people to make changes. The GPL even explicitly forbids distributing obfuscated code. It says something the like the code must be distributed in the "preferred format for making changes".

Re:Isn't this just self-modifying code?

[RedWizzard]

Granted, you probably won't know how it handles most exceptions and boundary conditions, but who cares?

Boundary conditions such as buffer overflows are the cause of most vulnerabilities. If boundary conditions are hard to observe then they will be hard to exploit.

Re:Isn't this just self-modifying code?

[rssrss]

" Yeah, and self-modifying-code was eventually abandoned because it played havoc with the then-new CPU caches and pipelines." Which means this stuff will be bog slow on P4s.

Re:Isn't this just self-modifying code?

[jmv]

Actually, it is possible to insert a signature without making the code obfuscated. One example is by playing with white spaces. It is, however, very easy to remove if you suspect there's a watermark in the code. A more clever method would slightly play with the style in general, but I don't think it could be robust enough. If you want to protect open-source code, you just mail it to yourself (to prove you wrote it) and then use a comparator like the one from ESR.

Re:Isn't this just self-modifying code?

[tietokone-olmi]

Not to mention what kind of games it'll play with processors that have a high branch misprediction penalty. Like, for example, anything at all that Intel has cranked out in the last six years, from the pentium pro and up.

Just need to tap the Analog Out...

[Speare]

Just like all the hubbub over proprietary signal encryption to "protect" digital audio streams, all you need here would be the CPU-equivalent of the old Analog Out jack.

Break it down to the Universal Turing Machine and tape analogy. The program code is the tape, and the state of the machine is in the tape-executing device. If the tape were to somehow morph itself dynamically, and yet execute properly by morphing to a well-designed program at the moment it is read for execution, all you have to do is to watch the read/write head of the UTM itself.

If they find ways to monkey around with bytecodes so that they're shifted around between disk and executor, just run it with a special version of the executor. Shouldn't be hard... the standard for what the unencrypted bytecodes are capable of accomplishing are standardized. Execute the code once, and take "notes" of what is being accomplished. Run through a code coverage test suite, even a crude black-box analysis, and you should get an unscrambled bytecode equivalent.

It just doesn't make sense. If obfuscation, i.e. obscurity, is your only security, it is no security at all.

Re:Just need to tap the Analog Out...

[Anonymous Coward]

wait, here's a tip.. you're a fucking idiot

Wow

[Anonymous Coward]

Cringely has really outdone himself that time. I can't even follow this poorly thought out mess. He seems to totally misunderstand every single concept he touches on.

Compilation to bytecode and an "interpreted language" are NOT THE SAME THING. Both the CLR and a compiled java class are effectively machine code for a machine that doesn't exist. These abstract machines have machine code that reveal *MORE* information to a disassembler/reverse engineer than, say, x86 or PPC assembly, but it is still far, far from being code. This is reaction one that I have. The rest of the article is so confused I don't even know how to respond to it.

Re:Wow

[Anonymous Coward]

These abstract machines have machine code that reveal *MORE* information to a disassembler/reverse engineer than, say, x86 or PPC assembly, but it is still far, far from being code.

Have you ever seen decompiled java bytecode? It's almost indistinguishable from the original source code. The problem with x86 assembly is that each instruction doesn't map 1:1 with the source. With java bytecode, it *is* close enough to a 1:1 mapping that perfectly legible code can be produced from an regular class file.

Re:Wow

[edwdig]

Having worked with Java bytecodes when I took compilers, I will say that you can get really close to the original program by looking at the bytecodes. You can't tell if someone used a while loop or a for loop, but you can still reconstruct the loop from the code.

The Java Virtual Machine is a stack machine - there are no CPU registers. There's a seperate memory store for local variables. That tends to make it easy to tell exactly what data is being operated on at any given time.

I've seen Java decompilers that return very clear, readable code.

Re:Wow

[bstuff]

>compiled java class are effectively machine code for a machine that doesn't exist Maybe you mean machine code for a processor that might not exist on the host machine. aJile Systems has a Native Java processor that runs at 100 MHz. It's assembly code IS Java Byte Code. Check out Ajile Systems for the processor. Or you can see products that use them at JStik.com. You can also check out benchmarks at PracticalEmbeddedJava.com. Your distinction is vaild, but he does have a point. Unless the host machine natively understands the "bytecode", then the bytecode runs on an interpreter ie JVM.

Re:Wow

[Anonymous Coward]

I actually did this to write code to plug in to a commercial Java application. The documentation for writing plugin modules was so poorly written it would have been impossible without decompiling some of their existing modules.

Although I'm no expert at Java bytecodes, I didn't have any problems, and the only tools I used came with the Sun JDK.

On the other hand, some other code we got from them was put through a C obfuscator and it was almost impossible to reverse engineer. I gave up. Of course now that they provide unobfuscated code I'm able to make improvements to it for our project.

Re:Wow

[pjt33]

You can't tell if someone used a while loop or a for loop

Depends. Some versions of javac vary the position of the test (start or end of the loop) according to the loop construct.

Re:Wow

[Anonymous Coward]

He thinks he knows how to design software better than all the brains at Microsoft...

Code obfuscation has been around for a long time and this particular buzzword/project is one of dozens. There are lots of reasons why it should not be applied to an OS:

- Many parts of OS code are much trickier than regular code (do things like switching stacks, enabling and disabling interrupts, etc.) and so standard obfuscation techniques can't be applied.
- Obfuscation, when it goes wrong, can introduce REALLY weird and hard to track down bugs -- not what you want in an OS
- It can make it difficult or impossible to use standard core-dump/stack trace techniques to diagnose bugs.
- It may significantly slow down the build process, which for something as big as Windows is already long. Slower turn-around means less time to fix bugs.
- There are patents on many of the techniques. Microsoft is a very attractive target for lawsuits.
- Any obfuscation technique can be reversed. The OS has a long lifespan, which means people have plenty of time to write a deobfuscator.
- As we all know, security by obscurity is not a reliable tactic.

Reverse Engineering is Good

[Jacek Poplawski]

Reverse engineering is good, and each coder should try it. This is the way to learn how someone else code is working, when that code is closed source. I don't think you can fool experienced assembler code with messing code around.
Think about R.E. like about game. It's like cracking, but it's good. And it's about creating, not about destroying.

Re:Reverse Engineering is Good

[El]

Actually, even stepping through the execution of your own code can give you insights into how the compiler operates, and allow you to write more efficient code. For example, I knew a C programmer who used to declare const strings and arrays local to each of his functions. I had to point out to him that these get copied onto the stack every time the function is entered, severely slowing program execution -- and he might want to consider making these static! Of course, I wouldn't have noticed this if I hadn't been stepping through his code in the first place.

the dark side

[musikit]

how come for every new technology that comes out that is suppose to "secure" us i can think of a way it can be used "malicously"

ex. I write YourDoom.A and i write it using this new code morphing obfuscator. how exactly are Anti-virus programs 1. suppose to remove this? 2. identify this?

Given the numberous amount of VB/Outlook bugs and considering that .NET is so "young" can't you see this used for creating a perpetual virus that can't be removed? you wouldn't even be able to ID the bug that caused this to virus to run itself.

Re:the dark side

[arkanes]

Polymorphic viruses have been around for decades. This is not a new technique or concept, simply a specific implementation.

Re:the dark side

[FictionPimp]

Couldn't you just write a virus to infect a user, then recreate a new version of the virus with some random buffer instructions added randomly in the code that doesn't effect the output... push ebx mov(eax, ebx) mov(ebx, eax)pop etc. Then distrubute it and do the same thing?

Re:the dark side

[scrytch]

ex. I write YourDoom.A and i write it using this new code morphing obfuscator. how exactly are Anti-virus programs 1. suppose to remove this? 2. identify this?

It's called polymorphic encryption, and viruses have been doing it for at least a decade. AV scanners look for the decryptor. Or they just intercept its attempted accesses when it does "wake up".

Re:the dark side

[SamNmaX]

All sides are dark. I don't want viruses nor my own purchased programs hiding what they are doing to my computer from me. We have seen plenty of examples of 'legimate' programs playing stupid tricks to do things from copy projection (i.e. modifying hard drive bootsectors) to adware (modifying core system files).

So, yes, tech like this perhaps could be used in viruses as well, however it's usually a pointless exercise no matter. So many companies think they have something important to hide, whether it be their copy protection or the billionth implementation of storing a record in a database.

Couldn't this be applied to P2P?

[Didion Sprague]

I don't know the answer to what I'm about to ask. I'm a writer, not a programmer, but as I was reading Cringley's column -- especially toward the end when he talks about how PSCP can be used in DRM to really (really, really) obfuscate a watermark -- I got to thinking: couldn't this theory of PSCP be used to further obscure (or encrypt -- whatever you want to call it) P2P networking?

And maybe this is already being done -- or maybe this is just pure stupidity on my part for asking the question -- but couldn't this sort of "morph-as-you-go" theory be used to obfuscate -- and essentially hide -- a network path used to get (or put) a piece of data? Kinda like BitTorrent -- but in a much more severe, much more shifty way? You getting the data -- eventually -- and you're both downloading and uploading as you go -- but the paths through which your current bit of data is being retrieved are both unknown until you visit it and obscured once you leave it?

Re:Couldn't this be applied to P2P?

[Dun Malg]

but couldn't this sort of "morph-as-you-go" theory be used to obfuscate -- and essentially hide -- a network path used to get (or put) a piece of data? Kinda like BitTorrent -- but in a much more severe, much more shifty way? You getting the data -- eventually -- and you're both downloading and uploading as you go -- but the paths through which your current bit of data is being retrieved are both unknown until you visit it and obscured once you leave it?

The problem with that, even if such a thing were possible, is that it would only obfuscate sources from someone looking through a log they seized after the fact. In reality, all they have to do to identify the source of something via P2P is download it themselves and record who they're getting it from. There's no way to send data to nowhere and have it arrive at a secret destination or request data from an unknown address and have that request get there. The totally anonymous medium you're looking for does exist, but it's not P2P, it's called USENET.

Re:Couldn't this be applied to P2P?

[Darth23]

I think that no matter what P2P program you use, once you're downloading from another PC or uploading to another PC, the person on the other end can easily find your IP address, and therefore (with an illegal subpoena) easily find you. Unless you were sending the packets to a central server, which forwarded them to a diffent computer whose identity/location was hidden from you. But then you'd have a centralized system again that could be esily shut down by the RI-MP-AA.

virus writers dream

[chammel]

Once the virus writers get a hold of this viruses will be much harder to catch, unless anti-virus writers start looking more for virus-like activity.

Re:virus writers dream

[carlmenezes]

You wouldn't happen to be a virus writer now, would you? :)

Re:virus writers dream

[nacturation]

Once the virus writers get a hold of this viruses will be much harder to catch, unless anti-virus writers start looking more for virus-like activity.

Of course, virus writers have been using this since the early 1990s. One particular virus called Ontario III (there might be others before it) used this trick. An interesting part from the virus writeup: "The Ontario III virus uses a very complex form of encryption with no more than two bytes remaining constant in replicated samples."

Re:virus writers dream

[chammel]

Right, but virus writers had to do the heavy lifting by writing or steeling the code themselves. If this is included in a .NET framework all .NET based viruses can have this obfuscation.

The PBS article was bunk

[Anonymous Coward]

The author of the PBS article didn't, even remotly, understand what he was talking about. There were several invalid statements, some stupid assumptions, some just wrong. How about some REAL research every once in a while before we go spouting off more garbage into the net.

Recompilers.

[xC0000005]

As I recall, Sierra games had a recompiler that screwed the code quite badly to make it hard to hack.

performance

[happyfrogcow]

When a computer program runs, the computer can follow millions of paths to get the job done. We leverage those millions of paths and transform them into billions of paths instead

Millions of paths implies some sort of jump instruction, whether or not that translates to millions of function calls, i don't know. assume it does. then instead of making millions of function calls, your making billions of function calls. Going from millions to billions is a large step, bigger than just swapping an "m" for a "b" in marketingspeak. So are they planning on passing this performance hit to the legitimate consumer? No thanks, I'll take my Free source code and like it.

Re:performance

[djmurdoch]

Millions of paths implies some sort of jump instruction, whether or not that translates to millions of function calls, i don't know. assume it does. then instead of making millions of function calls, your making billions of function calls.

I think you totally misread this. There are millions of possible paths for execution to follow that all lead to the same result. They're just increasing the number of possibilities, not increasing their length.

Re:performance

[El]

Information theory would imply that billions of paths take 1000 times more bits to encode than millions of paths. Either this obfuscation makes the code much, much bigger, or this explanation is bullshit. I suspect the latter.

Re:performance

[Tophorn]

um.... It's possible that he meant "millions of possible paths". You have to assume that the path which the program takes is the "Correct" path to do the task the program is supposed to do. It probably doesn't take billions of side paths to get the job done. Logically (to avoid enourmous performance hits) it tries to confuse the human with "possible" paths of execution; which leads to the whole "analog out" on DRM of audio files analogy. Which means that the program has to take some path and the reverse engineer simply goes along for the ride.

Re:performance

[Doc Scratchnsniff]

Consider a program with 60 procedures, which are arranged into 6 groups of 10. The top level of the program may call any procedure in group A, each procedure in group A may call any one of the procedures in group B, and so on. There are one million possible paths which may be taken in such a program. Now, suppose we create 30 more procedures, similarly arranged...

Re:performance

[Anonymous Coward]

Not if there's no additional information encoded in these paths.

Remember, the informational value of a transmission at a 50/50 probability of 1/0 is zero.

So, if it simply says "Generate one thousand extra paths for each of the valid million; they don't have to do anything useful, they just have to exist" then information theory says it can be exactly the same size (plus the size required by whatever new information is contained in the generate-one-thousand code).

Re:performance

[Grunhund]

That would also imply that you need to encode every path explicitly. What about an algorithm that creates paths it for you. It would take an infinite number of bits to encode the explicit form of all the squared numbers. The formula/algorithm for recreating any of these numbers takes far less.

Woohoo, Euclid Ohio!

[kisrael]

Went to high school in Euclid. Not hard to find, 'cause it's nestled up to Cleveland. (yeah yeah, 'just follow the river that's on fire' har har)

So basically, this stuff doesn't affect the original source code or, for that matter, the final running binary code, just the intermediate bytecode, which is what actually gets shipped and then JIT compiled to binary? Huh.

Re:Woohoo, Euclid Ohio!

[Anonymous Coward]

I actually looked at applying there, but it's too far north == too cold for me. Cleveburg sucks.

Re:Woohoo, Euclid Ohio!

[happyfrogcow]

bahehe. I got lost in Euclid so many times when I first got my drivers license, trying to head to 2600 meetings at Arabica in Coventry... ah 216.

Re:Woohoo, Euclid Ohio!

[kisrael]

Yeah, once you were off Euclid Ave it could be a bit confusing, especially if you weren't used to orienting yourself with the lake as North.

Lets see, Arabica (coffehouse) in Coventry...I think that was the one with the nickname "freakabica" (as opposed to the one near CWRU, which was "geekabica", and then the one in...I dunno, Shaker Hieghts, "chicabica", and then there was that coffeehouse that wasn't a proper Arabica somewhere...it was "wannabica")

Bullshit article

[Anonymous Coward]

If the written code is secure, all the .Net manifests in the world aren't going to allow someone to break in. All the open source arguments say having access to source makes code more secure. Having access to .Net manifests should allow the similar things. This obfuscation makes it more likely unsecured code won't be detected.

Right.

[El]

Self-modifying code will be much more reliable, and easier to debug! Cringely may not own PreEmptive stock, but I don't beleive for one second that he isn't getting some sort of renumeration from them. Here's an idea -- why doesn't the EFF or FSF patent security through obscurity, thus forcing all software vendors to implement REAL security?

Re:Right.

[nacturation]

Self-modifying code will be much more reliable, and easier to debug!

Have you considered the possibility that debugging is done in the original source code and only obfuscated before it ships?

Here's an idea -- why doesn't the EFF or FSF patent security through obscurity, thus forcing all software vendors to implement REAL security?

Perhaps you could elaborate on what you *do* consider to be real security for a software program.

Re:Right.

[dmaxwell]

Have you considered the possibility that debugging is done in the original source code and only obfuscated before it ships?

To the extent that is possible, sure. I could easily see this obfuscator clobbering fragile code. I suppose that can be tested for but that only defers the pain. Your customers won't necessarily come for your ass but the development team will love it.

This comes up with debugging normal code. Sometimes the debugging environment is just different enough to let flawed code seem to work ok but breaks horrendously otherwise.

Re:Right.

[nacturation]

I'm assuming, perhaps incorrectly, that the obfuscation is done in a manner which can be mathematically/logically shown not to alter the program given that certain coding practices are followed (eg: don't write self-modifying code yourself).

But maybe that's a pipe dream.

A few stray thoughts...

[Anonymous Coward]

1) We've seen this before. Self-modifying code, code which is encrypted until just before it is run, etc.

2) This should make for some fun viruses, too. They're almost always ahead of the curve, at least in the concept viruses (thankfully, the really evil viruses rarely seem to get released). No, the algorithm being patented would not stop them from using it, sorry.

3) These schemes usually get broken. I simply don't have enough information on this to analyze its weaknesses, but in general, there is probably a way to reverse it.

I wonder if +ORC is still around... ? He might have retired by now, for all I know. May have to ask Fravia or someone...

Re:A few stray thoughts...

[Xenographic]

I don't really know, but Fravia did put up some of +ORC's tutorials here.

Google is your friend.

Is it still Thursday?

[Anonymous Coward]

Wasn't there a story about a related technology yesterday?

Program State Code Protection

[zz99]

I tried googling for Program State Code Protection

*hmm* The closest thing I found was:

West Virginia State Code - Farmland Protection Program

The govenment use almost the same words already... I guess it will turn out that Al Gore invented this thing too... not just the interweb thingy :)

Re:Program State Code Protection

[gujju]

Why did I just let my mod points expire..and why couldn't this have happened earlier..Some one mod this guy up "funny".
Gujju

Anti-virus software and heuristics

[warlockgs]

Would code that was changing itself while running (polymorphic) be nailed by a heuristically-scanning anti-virus program? I would hate to de3velop something, and then all of a sudden get seriously bad press for releasing what seems to act like a virus. Just food for thought.

Re:Anti-virus software and heuristics

[Anonymous Coward]

Not antivirus but, the sentinals will get you. It won't be bad press, but Agent Smith will be at the door.

pscp?

[Anonymous Coward]

hope they dont go after the programmer of putty for creating a scp program called pscp

Ahhh, it makes sense now...

[lacrymology.com]

... obfuscation! That's why the Windows 2000 source looked so messed up.

-m

Very flawed article..

[CharAznable]

His whole premise is flawed.. he implies that recent security issues with Microsoft software are due to the fact that you can read the source code of .NET programs... as if Windows and IE were written in .NET... What about open source then?

And he's humble, too!

[Anonymous Coward]

This seems obvious to me, but I'm usually two years ahead of events. Hey Cringely, time distortion and delusions of grandeur are usually symptoms of drug abuse... what are you on? Crack?

More bloat.

[walkerIV]

Here it is, the killer-app of the 21st century. Need a reason to make people upgrade? Just built a run time morpher in the code. Use that Hyper threading for something useful. And then we can just layer them on top of one another, right. Add another morpher on a morpher and a new version of windows is ready. Like it can't already confuse itself to death.

Virtual Machine?

[Anonymous Coward]

So the code is hard to figure out until it's actually executed?

So you run it in a virtual machine and trace its execution, right?

Then it's just a 'simple' matter of disassembling it (If you're good with assembly :)

Or am I missing something?

Re:Virtual Machine?

[Anonymous Coward]

There's an already excellent virtual machine debugger used for exactly this purpose by a few crackers.

Self-modifying code is ENTIRELY obsolete. Has been for ten years. Sorry.

Security by obscurity

[Anonymous Coward]

This is a problem only to closed source systems, GNU/Linux is free software, and thus there is nothing to reverse-engineer.

Another great thing about my GNU/Linux boxen (besides being free as in speach) is that they don't get virii and BSODs all the time like my roommates M$ Windows^H^H^H^Hblows. So its open *and* secure.

Re:Security by obscurity

[JamesOfTheDesert]

GNU/Linux is free software, and thus there is nothing to reverse-engineer.

Unless you want to eat your cake and have it, too. Suppose you want to build on some OSS stuff, but don't want to have others be able to do the same with your own code. So, you follow the letter of the GPL and release the source, but make it so damn hard to decipher that it might just as well be binary.

Re:Security by obscurity

[graxrmelg]

The GPL says "The source code for a work means the preferred form of the work for making modifications to it." Some obfuscated derivative of the source code doesn't count.

Re:Security by obscurity

[latroM]

You don't really get the idea of Free Software which is based on co-operation and sharing information. In the world of Free Software people work for the community's benefit, not for their own selfish needs.

Re:Security by obscurity

[JamesOfTheDesert]

You don't really get the idea of Free Software which is based on co-operation and sharing information.

Yeah, actually I really do get the idea, having written a fair amount of it.

In the world of Free Software people work for the community's benefit, not for their own selfish needs.

Right. And anybody not pure of heart is, what, magically forbidden from using open-source code? My point was that there may be less than decent folks who might use code obfuscation and and similar hacks to weasel around of GPL requirements.

For what it's worth, the reason I use and contribute free software is because I see an immediate, personal, selfish benefit. It may also happen that others benefit as well. But that's not my motivation.

Re:Security by obscurity

[JamesOfTheDesert]

What does this mean if my source comes from a code generator?

Great.

[Anonymous Coward]

So legitimate software is going to take on the functionality that virus software has been using for years? And companies are patenting these techniques as if they are somehow new? Virus writers are the true innovators here. They pioneered the infamous Mutation Engine. I would consider off the shelf software that used those techniques innovative, in fact I find it creepy. Honestly, if the time wasted trying to protect so-called intellectual property was used instead to invent things to simplify our lives, we (as in humanity) would be better off.

Renaming all the variables `a'

[R.Caley]

Er, yeah. Given that the writer seems to think that makes sense, I wouldn't trust anything he writes. Ever.

Re:Renaming all the variables `a'

[Dun Malg]

Renaming all the variables `a'. Er, yeah. Given that the writer seems to think that makes sense, I wouldn't trust anything he writes. Ever.

Reminds me of a story I heard (may be true, but who knows) about a newspaper employee giving a tour of their typesetting facility. He was showing off their fancy typesetting machines which were, basically, early word processing machines. He demonstrated some of their more advanced features, such as find and replace.
"I can tell it, for example, to replace every instance of the letter 'o' with a letter 'i'", he said doing so with a few deft alt-macro keystrokes.
"And then I can change them right back again", and with a few more keystrokes he changed all the instances of 'i' into 'o'-- including the ones that were originally 'o'...

Re:Renaming all the variables `a'

[Anonymous Coward]

You messed up the story. It ends with "... including the ones that were originally 'i'..." (not originally 'o')

Re:Renaming all the variables `a'

[Dun Malg]

You messed up the story. It ends with "... including the ones that were originally 'i'..." (not originally 'o')

you're right! I totally suck! crap!

Top 12 Things A Klingon Programmer Would Say

[dnahelix]

Top 12 Things A Klingon Programmer Would Say

1. 12. Specifications are for the weak and timid!
2. 
   
   11. This machine is a piece of GAGH! I need dual
   processors if I am to do battle with this code!
   
   10. You cannot really appreciate Dilbert unless you've read
   it in the original Klingon.
   
   9. Indentation?! -- I will show you how to indent
   when I indent your skull!
   
   8. What is this talk of 'release'? Klingons do not make
   software 'releases'. Our software 'escapes' leaving a bloody
   trail of designers and quality assurance people in its wake.
   
   7. Klingon function calls do not have 'parameters' -- they
   have 'arguments' -- and they ALWAYS WIN THEM.
   
   6. Debugging? Klingons do not debug. Our software
   does not coddle the weak.
   
   5. I have challenged the entire quality assurance
   team to a Bat-Leth contest. They will not concern us again.
   
   4. A TRUE Klingon Warrior does not comment his code!
   
   3. By filing this SPR you have challenged the honor
   of my family. Prepare to die!
   
   2. You question the worthiness of my code? I should
   kill you where you stand!
   
   1. Our users will know fear and cower before our software.
   Ship it! Ship it, and let them flee like the dogs they are!
   

Re:Top 12 Things A Klingon Programmer Would Say

[happyfrogcow]

hehe. i resisted star trek for 24 years, just this year started watching the reruns. imagining worf reading this is pretty funny.

man i feel like a big dork.

Re:Top 12 Things A Klingon Programmer Would Say

[Anonymous Coward]

Score 3, Insightful? I guess knowing he's a big dork is quite the insight. Dumbass mods.

Re:Top 12 Things A Klingon Programmer Would Say

[happyfrogcow]

i agree with you, and I was the big insightfull dork. dumb mods.

Re:Top 12 Things A Klingon Programmer Would Say

[Anonymous Coward]

7. Klingon function calls do not have parameters' -- they have 'arguments' -- and they ALWAYS WIN THEM.

This is the good laugh I needed today, and I didn't stop laughing for 5 mins.

Re:Top 12 Things A Klingon Programmer Would Say

[Anonymous Coward]

man i feel like a big dork.

You are. You really, really are.

pah!

[openSoar]

i always write obfuscated code by default - goddamit! if it was hard to write, it should be hard to read

"Objective review?"

[Homology]

What a glowing article of a product from PreEmptive!

It is, of course, very reassuring to know that :

Understand that, as always, I have no stock in PreEmptive, I just like these people.

Beeing a bit cynical, I find the article more like a sales plug than a journalistic piece.

I can see a market for this.

[nicophonica]

I have worked on a couple of projects where the 'higher ups' (COO, CEO) were obsessed with the value of the intellectual property that their code represented. Woe be to the developer that tried to explain to them that their code was crap, written by team of programmers obviously just learning learning VB and trying to write it like a dumbed down version of Java. Most of programming was developing solutions to straight forward programming problems, which they still implemented in nearly the worst possible way.

Yet, I have no doubt that if someone came up to them and warned them about the dangers of IP theft and showed them this solution, they would bite.

If they really wanted to do maximum damage to their competition they should have just released the source code and hoped their competitors tried to used that as guidance.

There are probably some rare instances when a specialized software technique is developed and you want to keep its implementation specifics secret. I have yet to run into a single instance of this after many years in the industry.

Re:I can see a market for this.

[carlmenezes]

Very well put. Mod that comment up. This is nothing but a case of the blind leading the blind - they claim code morphing protects code n all, but the only people who will bit are those that understand very little about the technique - kinda like TV shopping.

Re:I can see a market for this.

[Anonymous Coward]

"There are probably some rare instances when a specialized software technique is developed and you want to keep its implementation specifics secret. I have yet to run into a single instance of this after many years in the industry."

Interesting. I think the same. Games and music yes, they rave about copy protection and obfuscation, but in defence, well at least not the projects I worked on in ADA, the issue was never there. Surely that's a more serious application?

Once there was a conversation about whether a missile could run a 'run-once' program that could not be recovered if it was a duff and didn't explode. I think the answer turned out to be yes but if and only if the trajectory is sequence(s) computed on launch - that is, if the program isn't going to encounter any unknowns that dont have a branch pre-run all the way to a sucessful hit. This takes up shitloads of memory but you can load it in RAM and it will erase itself as it goes.... a run once branched script that cleans up behind itself.

The fatal flaw if you attempt to apply this to media copy protection is that in the missile the enemy has no opporunity to read the code while it is in flight, but with deleiverable media you have to present the whole code in its original entirety.

This is not a subtle aspect of code. Its the deep implications of simple logic.

Prior art?

[Zakabog]

Isn't their a site that focuses on writing obfuscated code? It's just humor but wouldn't that count as prior art to any patents?

And how would those "Watermarks" help in open source. If you have this change all the variables to some names that don't make sense unless you're looking for the watermark. But wouldn't that make the code so much harder to read? And wouldn't that be VERY BAD for open source?

Re:Prior art?

[Drantin]

The IOCCC

Hmm...

[arvindn]

I wonder if they've seen the proof of the impossibility of obfuscating programs?

Re:Hmm...

[Yumpee]

Proof that there exist some functions with unobfuscatable properties (for some definition of unobfuscability) need not imply that practical obfuscation is not possible.

Christian Collberg has done some very interesting work on obfuscating programs at a high-level by densely intertwining their control flow and data accesses with a parallel heap-pointer-intensive computation. Sort of like a separate thread, with the key point that lots of dynamically allocated memory must be used to defeat analysis. This both obfuscates the original program and also helps in tamper-proofing (the original program can be modified by the compiler to rely on the values computed by this alternate thread).

Separating the main program from the inserted "thread" is much harder than checking and skipping some branch instructions in a decompiler or SoftICE. Static pointer analysis is an NP- hard problem for compilers, which makes de-obfuscation of this kind probably not practical.

Y.

Re:Hmm...

[eclectro]

Thanks for the informative link.

The thing that I do when I see a math paper like this is first head to the conclusion, and if you RTFP (Read The Fine Paper) it does not rule out all types of obfuscation.

It only rules out one type of obfuscation (virtual black box type)

One type of obfuscation in particular that it does not rule out by the proof is the indistinguishability or "differing inputs" obfuscator.

There does seem to be similarities between this and what Cringely was talking about.

I could not find any patent-pending application by this company as Cringely described. Maybe because it has already been discussed in math papers. I will let other more apt searchers correct me on this.

While the paper does not rule out the "differing inputs" obfuscator, remember that it might fall into the "impossibile obfuscation" category.

I would read what Cringely had to say about this with a jaundiced eye. I think that obfuscating code falls under "making water not wet" conjecture. Which means crackers will have to throw away their hex disassemblers and learn how to program new tools to divine code operation.

Which leads to the gaping omission in Cringely's rave.

Rather than buy a company, it's much easier to save money and use the bought politician you already have to get legislation passed. This is a much more likely outcome than somebody buying the company (preemptive) and would instantly make them irrelevant and worthless.

What Cringely blindingly forgets is that Microsoft already has a way to deal with reverse engineering anyway. This in one word is "palladium".

Microsoft already knows that software obfuscation is impossible . Besides, they would rather go to the logical conclusion anyway. It's better than chancing some intermediate software solution that might be cracked and spread accross the internet faster than NT/2000 source was.

So they are putting the hardware solution palladium in place.

A hardware solution like palladium will make software cracking an impossibility. I do not know how it will work, but reverse-engineering won't be a part of the "trusted computing" enviroment. Crackers could learn how to use a soldering iron. The only problem is that you won't be able to mod your friends computer in the next state over to run the code that you have ahem-"modified"

But expect the DMCA to be enhanced to prevent this legally anyway. Expect it to be given a spin name like "secure computing" for a "safe homeland". Expect computers that don't have it to be outlawed.

If you do find a hardware entry point, you won't be able to tell your friends about it, a la 2600. If you are an academic, you will be sued into silence, a la Felton.

But the law is only part of it. Expect only "trusted" computers to open an office document.

Check and Mate.

I fear the day will come that it will be easier to buy a gun than obtain a drm free computer.

I will probably craft my own computer, like the days of altair. I won't be able to tell anybody about it, and I won't be able to sell plans for it on ebay.

Which future do you think is more likely, mine or Cringely's?

The software arms race.

[kyz]

There is nothing new under the sun. These Java and .NET obfuscators are just the same old anti-SoftICE sections, which were just the same old Amiga/Atari copylocks, which were just the same Spectrum/C64 turboloaders, and so on.

Every single one of these is broken. Almost all good programmers are capable of deciphering the standardised, retail-boxed algorithm used for the obfuscation, and can easily un-obfuscate it. Are all the Java variables named "a"? Diddums! You don't have a Java decompiler with the option to ignore that simple tweak.

All that matters is:

1) How important is the code behind the obfuscation?

2) How much time and effort is the reverse engineer willing to spend?

If you use a company's retail-box obfuscator, anyone with the "'Brand X obfuscator' deobfuscator v1.0" can get straight at your code. It's a technological arms race, nothing more.

Re:The software arms race.

[D-Cypell]

How can you 'deobfuscate'??

The point is that you are losing information. If the variable 'secretCompanyKey' is changed to 'a' there isnt a program in the world that will change it back... the information has been lost. Its like trying to reverse a hash.

Of course, native compiles do this kind of obfuscation anyway, but then native programs dont give easy to read, full stacktraces with methods and variables included either...

Personally, I feel that protecting IPR is the PHB's job, but when im debugging someones shoddy code, im very grateful for that stacktrace!

Re:The software arms race.

[SmackCrackandPot]

So the boys and girls of PreEmptive Solutions built a version of DashO that not only optimized, but also obfuscated in whole new (and patented) ways. Instead of adding useless code, for example, it changed all the variable names -- hundreds, even thousands of them -- to the same name, for example "a." Try to figure that out from a code printout..

These Java and .NET obfuscators are just the same old anti-SoftICE sections, which were just the same old Amiga/Atari copylocks,

That's very true. The Atari technique consisted of setting the variable and array name tables to zero length strings. It was fairly easy to read the saved binary files of the Atari BASIC programs and read the command tokens. From these you could deduce what the variable was being used for, and rename it accordingly.

Re:The software arms race.

[kyz]

How can you 'deobfuscate'??

Work out how the obfuscator works, then reverse the process. If information is thrown away, provide fresh information as best as is possible.

The point is that you are losing information.

No, the point is that the obfuscated code still runs and still does the same thing as the pre-obfuscated code. If those properties are there, it is inevitable that you can derive the former from the latter.

I don't know why you speak of "variable names" or "stack traces". That is debugging, not reverse-engineering. Most reverse-engineers go on nothing more than a location or stack offset and read/write instruction bitwidth to distinguish variables. They certainly don't expect variable names. Those are derived from studying what the code does with the variable.

The reason you debug code is to make it work. If it's not your code, you're better off finding its owner and helping them debug it. The reason you reverse-engineer code is to get code you never had in the first place, and whose owner will not simply give you access.

Re:The software arms race.

[jsebrech]

The point is that you are losing information. If the variable 'secretCompanyKey' is changed to 'a' there isnt a program in the world that will change it back... the information has been lost. Its like trying to reverse a hash.

In the end, it's code, it has to perform all its functionality on standardised (and therefore known) hardware. You can't throw away information necessary to do this, and a reverse engineer is only interested in that kind of information, so therefore the program still contains all the information necessary to deduce the original program from the obfuscated one.

Reproducing Production Bugs...

[joekampf]

This is gonna make reproducing production bugs a bitch. Well which path did they take. What will this do to multithread debuging? UG! Besides Security by Obscurity is no Security at all.

Disagreements with the Premise

[no soup for you]

I don't love microsoft, but I think this article makes several claims without backing them up or offering any explanation as to their merits. Such as:

1. .NET, on the other hand, is Microsoft's chosen successor to Visual BASIC, and effectively exposes source code at the very heart of Microsoft consumer and enterprise applications.
2. If .NET is Such a Security Nightmare (It Is)...

And "You can write a program in C# or Visual Basic.NET." while factually accurate, ignores Delphi.NET, C++ managed code using the CRL, and other implementations of the CRL (COBOL, etc).

I think the basic premise of the article, where if someone is using your objects it is obviously a bad thing/security breach, is flawed. If you need to secure your objects, SECURE them! Seal them, see who is calling you, etc.

Lastly, As shown by previous posts, Obfuscation is not the end-all panacea to security. In my opinion, it's barely a detour. Otherwise, Open Source literally could not be secure.

Re:Disagreements with the Premise

[nacturation]

Lastly, As shown by previous posts, Obfuscation is not the end-all panacea to security. In my opinion, it's barely a detour. Otherwise, Open Source literally could not be secure.

I think you're touching on a different point. Security, as commonly used for Open Source software, can be defined as hardening the code to make it more resistant to elevation of privelege... an Apache hack giving you root access for example. For Closed Source, the obfuscation doesn't even attempt to answer the privelege aspect -- its sole purpose is to make the source code unreadable, regardless of how secure the application is.

Open Source, by definition, does not have its source code secured. Closed Source, by definition, has its source code *more* secured. This just attempts to increase the amount of security by which the source code is hidden.

Re:Disagreements with the Premise

[iplayfast]

Well said. I'm no MS supporter myself, but as I was reading the artical it struct me as loop sided. Nice of you to clearify my thinking :)

Re:Disagreements with the Premise

[bee-yotch]

And to add to this, "securing" code doesn't necessarily mean secure from security breach's. I believe part of what the author is getting at is that the companies have "trade secrets" within their code that they don't want other people to have.

For example, Microsoft wouldn't want the samba project to get ahold of their source code or it would make it easier to interact with microsofts products.

Just one question

[carlmenezes]

Seems to me that stuff like this would make it quite difficult to debug once an application has been released - also, how would things like a memory dump on application crash help to debug anything here?

Re:Just one question

[Mathi�u]

I agree: changing the code, even through an automated process, implies testing! So it seems for me that obfuscating the source will double the amount of testing required...

"Is this a bug in the code morphing program or in the original application?" - wow, testing will get even funnier :).

Bah

[Anonymous Coward]

It's not like no one's ever written a virus before that included obfuscation through self-modifying binary code. The major virus companies already have techniques for identifying and working with such viruses. Those companies that don't already have such techniques are selling products that don't work. :P

Second off, code obfuscators aren't magic. You can always still tell what's happening. It just takes longer and more effort.

Obscurity generation...

[zz99]

I have found that most code generation tools (the kind you program boubles and arrows in, like this one) will give you C code that looks like it's been obscurified on purpose.
E.g. all states and variables are in an array called n[][] and the program is basically a big loop.

Quite impossible to know whats going on

Two completely different issues

[BlueFall]

It sounds to me like the author of the article is talking about two completely different issues. The first is code decompilation and static obfuscation. The second is about runtime obfuscation.

In theory, if you don't run the binary you have, you don't need to worry about it modifying itself. The same techniques that work on obfuscated byte code now should work on the the binary. Now if you were trying to reverse engineer a program by running it and tracing it, that's where PSCP seems like it would help.

Finally...

[gmaestro]

Now I can distribute my patented "Hello, World" application (note the comma) without fear of infringement.

Just hire that guy from the movie Paycheck

[wmt]

Nothin can stop Ben Affleck as Michael Jennings, the "best reverse engineer there is."

bah, wtf. feeding off SCO paranoia

[happyfrogcow]

And there is even an Open Source aspect to this new form of protection: It can be used as a new form of attribution. Who wrote what part of that Open Source program? Copyright notices and comments can be removed, but the PSCP code renaming signature can't be.

What is this "code renaming signature"? The article only mentions it once. right here. Why can't it be removed for open source code? I bet it can be, give me a room full of monkeys(1) and a few terminals with vim.

Assuming it's *something*, sure, there's an application. [insert favorite hashing algorithm here] can also create a "signiture". Then maintain some version control that contains a source file and hash. Granted people can grab that source from the version control system, erase anything they want and create a new signature for that file, but I still would have an original version that has all the info in case something comes up where someone would want to know the documents history.

(1) those monkeys have nothing to do with anything but me wanting a room full of monkeys

Sounds like a way to make things more unstable

[Sporkinum]

If it changes how it executes every time, it sounds like it would be a fantastic way to introduce unreproducable bugs.

I'm sure this would make QA testing a nightmare.

You're Only Encouraging Him

[ortcutt]

If you read Cringely's articles, you only encourage him to write more of them. I mean, he does have Superman-like abilities, like being able to bounce a wifi signal off a mountain, but he's still insufferable. Here's a reminder of his amazing feat...

http://www.oreillynet.com/cs/user/view/wlg/1124

Let's try an experiment!

[El]

Let's start a software company based on an algorithm that promises to compress any string of bits into a 1 bit smaller string of bits, and thus by multiple invocations can compress any string of bits into a single bit... Then let's see if we can get Cringely to recommend this technology!

Deobfuscation is in NP

[BiggsTheCat]

Deobfuscation is in NP. That is, for any type of obfuscation, there is a method to reduce it to a deobfuscated copy. It may take polynomial time, but it can be done.

Read the paper if ya don't believe me.

Re:Deobfuscation is in NP

[Anonymous Coward]

Deobfuscation is in NP. That is, for any type of obfuscation, there is a method to reduce it to a deobfuscated copy. It may take polynomial time, but it can be done.

NP means "nondeterministic polynomial" time, which means that if you have O(2^N) computers, you can find the answer in polynomial time. Basically, you try every possible answer in parallel, and you have a polynomial-time function which tells you if any given answer is correct.

In other words, unless you have an extremely powerful quantum computer--or a proof that NP=P--solving problems in NP could take exponential time, which can easily exceed the life of the universe.

In general, all popular cryptographic functions have inverses in NP, but many are currently unbreakable.

The paper you link to is actually pretty remarkable, though--many functions which take programs as input do not halt with any amount of time on certain programs. So this paper proves that generalized deobfuscation is merely massively impratical instead of completely impossible.

Samba

[Anonymous Coward]

Well SMB, anyway. Not the entire OS.

How does this protect your .NET assembly?

[Xeger]

Okay: for argument's sake we'll say that PSCP works like a charm to prevent nasty evil crackers from debugging my program effectively.

We'll ignore the obvious problem presented by the fact that your .NET program's IL instructions are JITted into machine code at runtime, thereby making it pointless to modify the IL -- unless these people are invalidating the JITted code every time the IL code changes (is that even allowed?) or providing a translator between IL and machine code that inserts code-morphing instructions into the OUTPUT machine code (which I seriously doubt).

We'll ignore the fact that instructions which modify other code are generally very easy to spot -- because they must refer to regions of a program's address space where code resides -- and it should be easy to find these code morphing instructions and turn them into no-ops.

We'll set both of those tricky issues aside and focus on the crux of the matter. How does this PSCP protect the program *before* it starts running? When the cracker gets his hands on my juicy .NET assembly which is bursting with code, how does PSCP prevent him from taking the assembly apart and dissecting? Answer: PSCP *doesn't* provide any such protection.

So, the school of crackers that likes to use a debugger to deduce program behavior may find themselves having trouble. But in the worst case, all I need to do is run the morphing code in a debugger, record the location of the program counter at the point in the program's execution in which I'm interested, and then consult the corresponding section of the program code that resides in the original .NET assembly. I may need to hunt back and forth for a little while to find the specific place I'm interested in, but I can't imagine that PSCP is able to change offsets or locations of instructions by very much.

Think about it: if PSCP wanted to change the location of a jump target, for example, it would need to track down every other instruction in the program that jumped to that instruction, and modify the jump to point to the new location of the jump target.

Such solutions for Java already exist

[kompiluj]

Check out:
Retrologic awarded Java byte code obfucator (Open Source! and free!)
not free but you can try before you buy
ZelixKlassMasterYet Another Java Byte Code Obfuscator (YAJBCO)
But I'm not sure they really work - just provide level of security similar to classical machine code. Btw. the MyDoom virus was BurnEye encrypted - so what?

before any one else leaves this comment

[musikit]

"Resistance is futile"

Re:before any one else leaves this comment

[Anonymous Coward]

obfuscation is futile...all your byte codes are ours!

Hungarian? Forget about it. Use Finnish.

[Anonymous Coward]

and comment in Hungarian

As a Finn, I must propose our language as a viable alternative for obfuscation purposes. Please allow me to demonstrate:

Tama koodi ei toimi ja siina on ladonoven kokoinen aukko - mutta ei Linus sita tajua.

Re:Hungarian? Forget about it. Use Finnish.

[Anonymous Coward]

Tama koodi ei toimi ja siina on ladonoven kokoinen aukko - mutta ei Linus sita tajua.

"This code does not work and there is a security hole the size of a barndoor in it - Linus won't get it, though."

Re:Hungarian? Forget about it. Use Finnish.

[Anonymous Coward]

Or, run this on your C++ code (in vi)
:1,$s/\/\/.*//

Re:Hungarian? Forget about it. Use Finnish.

[__past__]

You are aware that hungarian and finnish are closely related languages, right? And that basically no other language is closely related to either of them? (IIRC, basque is, but its chances to become an official UNO language are pretty slim either)

Writing code and/or comments in finnish or hungarian would be the ultimate obfuscation technique. People who know english have a bigger chance to guess what words could mean if they were written in persian.

Re:Hungarian? Forget about it. Use Finnish.

[antime]

More recent research indicates that they're not related. And even if they were, there's no shared words (beyond coincidences, but those exist in all languages). A Finn will not understand Hungarian, nor will a Hungarian understand Finnish.

Re:Hungarian? Forget about it. Use Finnish.

[__past__]

Oh, interesting. I admit that I always took that a as a given, without actually knowing the details of either language. Do you happen to have a pointer to such research? Did it come up with other relationships, or does it just state that finnish and/or hungarian are weird in their very own way, different to all other languages known today?

Re:Hungarian? Forget about it. Use Finnish.

[arose]

You are aware that hungarian and finnish are closely related languages, right? And that basically no other language is closely related to either of them?

I don't know how finnish is related to hungarian, but I wouldn't take your word for it as you managed to forget estonian and liiv.

Re:Hungarian? Forget about it. Use Finnish.

[Anonymous Coward]

Nope, Basque isn't related to either of them, it's a true language isolate.

Finnish and Hungarian are probably related, but not closely. Not like Danish and Norwegian, which are basically as different as British and American; not even as close as French and Spanish, which are recognisably cousins even though they're mutually incomprehensible. More like Japanese and Korean, in fact: some structural similarities that suggest a relationship, but basically no shared vocabulary.

Re:Hungarian? Forget about it. Use Finnish.

[Arker]

You are aware that hungarian and finnish are closely related languages, right? And that basically no other language is closely related to either of them? (IIRC, basque is, but its chances to become an official UNO language are pretty slim either)

Umm no. You're way off, sorry.

Finnish and Hungarian are related, but not very closely. They're both Finno-Ugric languages, but the relation is roughly as distant as that between, say, German and Greek for instance. And probably less apparent, since German has quite a few Greek loan-words, particularly in scientific fields, but Hungarian and Finnish don't borrow from each other noticeably.

Other Finno-Ugric languages include Mansi, Khanty, Udmurts, and Mordvin, the balto-finnic languages (or dialects, depending on who you ask) which includes Finnish, Estonian, Karelian, Izhora, Veps, Vod, and Liv; and the closely related Saami languages spoken in the far north of Sweden, Norway, Finland, and northwest Russia.

This group is in turn more distantly related to the Samoyedic languages spoken in parts of Siberia.

Basque isn't closely enough related to any of these for linguists to have established any relationship, although many have suspected there was one and put a lot of time and energy into trying to find evidence of one.

Re:Hungarian? Forget about it. Use Finnish.

[virx]

Finnish and Hungarian are remotely related languages. But there are similar words on both - I once saw list of similar words between Estonian and Hungarian language (Estonian is closely related to Finnish) - I don't remember them, expect one (blood is "veri" in Estonian and "ver" in Hungarian). Languages are not only consider related because of the words bu also accentuation and the way sentecnes are made up.

Re:Hungarian? Forget about it. Use Finnish.

[szo]

It's true that we don't understand eachother, but the languages are related: both finn-ugro languages. But they were separated some 6000 years ago. But a few very ancient words (water, blook, hand, etc.) are very similar. The grammatical structure is very similar.

Szo

Re:Hungarian? Forget about it. Use Finnish.

[Anonymous Coward]

I believe that there are a number of similar common nouns between the Finno-Ugyric languages (including Finnish, Ugyric and Hungarian) and the Dravidian languages, of which the Tamil is the most widely-used modern language.

This would suggest a link between the Finno-Ugyric languages and proto-Tamil (which most probably has Mesopotamian and Harappan links).

Re:Hungarian? Forget about it. Use Finnish.

[Arker]

I believe that there are a number of similar common nouns between the Finno-Ugyric languages (including Finnish, Ugyric and Hungarian)

That would be Ugric or Ugrian you are referring to I believe. Wouldn't be 'Ugyric and Hungarian' however, because Hungarian is Ugric, that is Ugric isn't a language, but a language family, one which includes Hungarian along with a couple of West Siberian languages.

Anyway, I'm not sure if this is a vague recollection of something serious or if you've just been reading something from the tin-hat brigade, I've seen a bit from both on the subject. There are actually very few possible cognates between the two groups that can be taken seriously - (remember that we expect a few by sheer chance even if they aren't related) - but it's not entirely an unserious idea that there might be some relationship. Not with Finno-Ugric per se, but with the larger Ural-Altaic family which includes them. If there is a link, it's an incredibly ancient (and thus obscure) one, something like the proposed linkage between Indo-European and Hamito-Semitic languages, which is still nothing more than an interesting theory at best after many years of work by its proponents.

proto-Tamil (which most probably has Mesopotamian and Harappan links).

A lot of people assume that the Harrapans spoke some sort of proto-Dravidian, but their is really no evidence to back it up, it's just an assumption, and I think in many cases it springs from the visions brought to peoples minds by the (long since discredited) Aryan invasion theory. It's possible they did, it's possible their language was completely unrelated. At least until and unless someone deciphers those seals, their is just no way to know.

Re:Hungarian? Forget about it. Use Finnish.

[hicksw]

Funny you should mention this close relationship. I recall talking with a Welshman who married a Finn. He told me that the similarity between Finnish and Hungarian was comparable to the similarity between English and Sanskrit -- just about enough to entertain the comparitive linguists.

Re:Hungarian? Forget about it. Use Finnish.

[Anonymous Coward]

you seem knowledgeable: what is the evidence for a Korean-Ugric relationhip?

Re:Hungarian? Forget about it. Use Finnish.

[Arker]

Well let me first say I'm not a specialist in those languages, and I don't speak any of them, so all I can say is what I've heard and read. Furthermore, it's an issue of some debate among those who are specialists in it, it seems.

So, my understanding is that there isn't much direct evidence for it, but that most of those who focus on it think they are probably very distantly related. Let me explain how we get to that conclusion with very little direct evidence.

It's not established beyond controversy that the Uralic family (Finno-Ugric and Samoyed languages) are related to the Altaic group, first off. The majority of folks that have studied the problem enough to really have an opinion on it seem to think that they are, but it's not at all beyond controversy. There are a number of common features, for instance vowel harmony systems, and some reconstructed root words in each family seem to be related. On the other hand, bring it up with a group of linguists who specialise in one group or the other and I'm sure you'll find some that will argue vociferously that there is no connection and that these similarities are just coincidence.

The second point of contention here is whether Korean really belongs in the Altaic group. If it does, and if the Uralic-Altaic hypothesis is correct, then Korean is very distantly related to the Uralic languages, even though it's so distant there's little to no apparent sign of such a relation, but both of those propositions are controversial.

The non-controversial members of the Altaic family include the Turkic family (Turkish, Kazakh, Uzbek, etc.) the Mongolic family (a number of languages spoken in and around Mongolia and obviously related) and the Tungus (another group spoken now in part of Siberia, and once in a much wider area, including Manchuria.) There are quite a few signs that this family might well be related to the Uralic family -

Now, Korean from what I've read is a very difficult case. So is Japanese. Although it's controversial, a number of people do think that they are related to each other, and to the Tungus languages, moreso than any other group. If so then they're Altaic languages, and then if the Uralic-Altaic hypothesis is correct - voila, there's your link to the Ugric languages, albeit a very distant one.

To give you an idea of how distant, Uralic and Altaic are each roughly at the same level of abstraction as Indo-European, which includes every major European language except Finnish, Estonian, Hungarian, and Basque (a few other Finno-ugric languages exist in Europe but usually aren't considered 'major', Saami for instance) PLUS Persian and many of the languages of India, and that's just the living languages. That's a language family, and the ancestor language here probably split into separate groups roughly 8-10,000 years ago. That's about the limit to the non-controversial use of Historical linguistics - in fact if we hadn't deciphered some dead languages like Hittite that conformed to what the Indo-European hypothesis lead us to believe should be there that family relationship might still be controversial today. When you talk about linking Korean to Ugric, basically you're talking about linking languages last spoken somewhere in the same neighborhood of time, with the common ancestor perhaps last spoken 20,000 years or so, and no decipherable links like Hittite available at the moment to confirm it.

Hope that helps.

Classic Cringly from PBS!

[Anonymous Coward]

Executive summary of the article:

1. MS bad!
2. MS code is insecure
3. Linux rulez d00d!

Next, I assume we will hear from him how someone 'discovered' that writing a procedural like algorithm in a rules based language makes the code more secure.

I really really feel good that my tax dollars are being well spent at PBS to fund political speech.

I especially like the fact that I am funding political speech that I disagree with!

Hey, wait isn't that violating my 1st amendment rights!

Re:Classic Cringly from PBS!

[the_consumer]

Unless Microsoft is now the government, none of the examples you listed are forms of political speech.

Re:Classic Cringly from PBS!

[GeckoX]

FUD.
None of those things were stated, nor even implied. There is no condemnation of MS in that article, just observance of possible real-world issues that _could_ be addressed in this way.

Linux was advocated NOWHERE in there.

I'm more annoyed at whomever actually modded this funny.

Re:Classic Cringly from PBS!

[Power Luser]

The FUD was in the article, right there next to all the factual errors. Cringley falsely attributes Microsoft's "ever increasing" security problems to .NET, when nothing could be further from the truth. Most of the security problems Microsoft has had recently were not caused by any .NET applications, and were, in fact, caused by things that .NET could actually address. His entire motivation for code obfuscation is just wrong - code obfuscation is not intended for security, but protection of IP. Hell, the guy doesn't even seem to understand virtual machines, but talks about things "being intended for interpretation". And don't tell me the guy is dumbing down - he's
just plain dumb.

And those "real-world" issues you cite are actually non-issues that Cringely has made up in his head. It's typical Cringely style - make up some clear and present danger, or otherwise earth shattering motivation to explain some technology that he doesn't quite understand. And then, when something very vaguely related to something he's ranted on about, he revises his claims he predicted it. Very Nostradamus.

Cringely is a charlatan. Don't bother wasting your time on him.

I reverse engineered WinXP!!!

[Anonymous Coward]

And I am still in shock what I found...
RedHat Mother's Day edition with Hungarian comments and an obfuscating GUI layer.
No wonder Microsoft is scared to open it up.

Yawn

[ENOENT]

WHOOOO CAAAARRRES???

Yeah, users demand that their executables should change randomly at runtime. I'm sure that there can never be any bugs introduced by this process. Applications won't randomly crash for no reason...

Oh, wait. I guess this is MSFT. They wouldn't care about random crashes, data corruption, security holes, or any of that boring stuff.

So basically,

[stratjakt]

They're promoting security via obscurity.

Whatever.

It must be said

[pimpinmonk]

In Soviet Russia, the code modifies YOU!

Imagine the ramifications of that statement. Actually it's kind of true--my increasingly bad sleep patterns and worsening ability to attract women are probably direct results of coding! But hey, at least I can't get reverse-engineered (that sounds like sodomy, so I think it's a Very Good Thing(TM))

Re:It must be said

[Anonymous Coward]

Mod parent up, +4 funny (Not +5, only +4)

the "clearest text" version can always leak

[peter303]

The barrier is human, not technical. "Social Engineering" can get through the human aspect.

I use the term "clearest text" because the original source code may be so poorly written, that it is practically self-encrypting.

their logic is flawed.

[qnxdude]

All it takes is a code following disassembler, I use one for reverse engineering obfusticated firmware as a regular part of my job. Eventually the processor has to run the code, If you do a just in time disassembly, it doesnt matter how the fusk with the code, you can still understand it.

Re:their logic is flawed.

[Anonymous Coward]

The whole notion that source code is all-important is flawed. People just need skills and tools for working with object code, and there's no secets anymore. Source is convenient, of course. And you can't tell much about how a program works on a different platform than the one you're debugging, but if it runs on x86, it's just x86 instructions after all.

Cloakware

[roady]

Cloakware also has some nice obfuscation technologies

Sorry...

[Sloppy]

..but from reading this, I get he impression Cringely doesn't know what he's talking about.

Viruses already do this

[Animats]

write better polymorphic viruses.

Re:Viruses already do this

[Animats]

Actually, I had a long post on the theory and history of polymorphic viruses, and somehow posted only the last line. But that's all that's really needed. Just look up "polymorphic viruses".

Cringley, as ever, gets facts wrong...

[spectecjr]

In effect, the .NET code remains in interpretation-intended form right up until the end. The point is that it carries around tons of info with it that makes reverse engineering easy just as with interpreted languages. The original Microsoft BASIC was an interpreted language and subject to this vulnerability, which is why it was so easy to copy on punched paper tape and why Bill Gates once referred to many of his earliest users as "thieves."

Unfortunately for Cringely, he appears to have trouble figuring out the difference between a language interpreter and an interpreted language. Microsoft BASIC was written in assembly, and as such was not subject to this vulnerbility. The thing that made it easy to copy was the fact that it was ... well... binary data.

Signing self-modifying code

[kris]

Yeah, right. Write self-modifying code and try to run that in a Palladium/NGSCB'ed environment where your code is checksummed as it runs.

Yes

[Tim Macinta]

Obfuscation seems to be useful only for client-side Java applications that contains super-secret valuable algorithms. I mean, who cares if somebody decompiles your code to see how you did sortable JTables or whatever?

There are plenty of good reasons to use an obfuscator on code targeted at the client-side. Retroguard will strip out unnecessary information from your class files and will rewrite variable, class, and method names, usually to a substantially shorter size. This can save enough space in the deployment size to make obfuscation worthwhile for the space savings alone in environments where every byte counts (particularly, J2ME/MIDP).

Obfuscation does also provide a speed bump to those attempting to disassemble your code. Without obfuscation, anybody with a casual interest could just glance at your code using javap, etc. Retroguard fits saemlessly enough into the build process that adding a simple level of protection to the code is usually simple and transparent.

Re:Yes

[tcopeland]

> in environments where every byte counts

Right, yup, obfuscation reduces class file size. Certainly, that can be important in some environments.

> anybody with a casual interest could just
> glance at your code using javap,

Sure. But what will they learn? How the code processes MouseEvent.MOUSE_CLICKED? How you use sockets? How you show that nifty splash screen? I mean... who cares?

Going off topic now, but, anyhow, nifty!

Poor code is the real problem

[Ytsejam-03]

What exactly is the risk to Microsoft here? Since they started their big "security initiative," all of their programmers are writing secure code, right? RIGHT??? Then it should not matter if someone can easliy decomplie it.

Or perhaps the problem is that it will be too easy reverse engineer unpublished API calls.

.NET is not the reason that Windows security problems are being reported more frequently. In some cases (the RPC bug) these problems have existed for a several years! More security researches are looking for problems in Microsoft products than ever before, and that's why so many new problems are being discovered.

You got to be kidding me.

[Anonymous Coward]

I can't believe a company will pay for junk like this. If you are such a company, I have a program that will secure your source code. Here some output from it:
vag znva(ibvq)
{
cevags("Uryyb, Jbeyq\a"); /* abobql jvyy erirefr ratvarre guvf pbqr */
erghea 0;
}

leave your contact info in the subthread and I will get back to you.

Spaghetti code?

[TheBoostedBrain]

Ok. Let me see if i got it. Generating spaghetti machine code from structured source. Dijkstra will be very happy about that.

If it can be compiled, it can be cracked

[dr2chase]

Speaking as a former bytecode-to-native compiler writer, I can assure that if someone writes a compiler from Your Favorite Intermediate Language (YFIL) to native code, then someone can crack it. Every (stupid) obfuscator trick out there, the compiler has to tolerate in its quest for verifiable, compilable, optimizable code.

Examples of Stupid Obfuscator Tricks include:

• Scrambling exception ranges so they don't nest.
• Inserting non-structured GOTOs
• Inserting never-executed exits from synchronized blocks

There are others, these are just the ones that I recall. A compiler (static or JIT, it does not matter) must deal with all of these.

There are two outs that I know of. One is to only use interpreted code and morph it on the fly (still seems vulnerable to an observant interpreter, but perhaps the amount of necessary observations can be made extravagantly large), the other is to require use of a "trusted" compiler (which, in turn, requires use of a "trusted" OS to prevent substitution of an untrusted compiler, which in turn requires "trusted" hardware to prevent substitution of an untrusted OS).

Re:If it can be compiled, it can be cracked

[psoriac]

There are two outs that I know of. [...] the other is to require use of a "trusted" compiler (which, in turn, requires use of a "trusted" OS to prevent substitution of an untrusted compiler, which in turn requires "trusted" hardware to prevent substitution of an untrusted OS).

And is it any surprise that the "secure" DRM hardware environment is exactly the direction Microsoft et. al. is moving, along with the **AA?

Re:If it can be compiled, it can be cracked

[Anonymous Coward]

".. a 'trusted' compiler (which, in turn, requires use of a 'trusted' OS to prevent substitution of an untrusted compiler, which in turn requires 'trusted' hardware to prevent substitution of an untrusted OS). " ...which in turn requires a 'trusted' operator not to circumvent A, B, and C. :)

Best forget that one eh. Better to just ask the ask the end user nicely not to disassemble to code. I think your remark stands, if it compiles (ie is a useful working piece of code) it can be cracked (disassembled, reinterpreted etc). Period.

Certified Applications.

[fatgeekuk]

Ok, you are a member of a development department responsible for applications that need to be certified and tightly controlled. (maybe big pharma)

The FDA come a knocking and start asking about the checks in place that ensure that the code that you write and document is the code that actually gets performed.

FDA Auditor: So, this code specified in this document. Can you please show me how you ensure that this code is actually performed when you run the program here that you say is the one that this document references.

IT Guy: Sorry, Cant

FDA Auditor: Why isnt it?

IT Guy: because the code that gets run is different every time it is run, and indeed during a single run it changes.

FDA Auditor: So, What your saying is that you cannot guarantee that the applications specified in all these documents is the application code that actually runs.

IT Guy: Yep, thats about it...

Oh, now at this point in the discussion it gets serious.

Who on this list actually thinks that dynamic code obfustication like they propose is actually worth a damn.

What happens when this mutating mess gets it wrong?

Who is to blame?

Come on now, this is stupid, this is the worst form of pandering to corporate paranoia.

This is true snakeoil.

These are all just turing machines.

I, for one

[Anonymous Coward]

I, for one, vote for SCO's greek-letter obfuscation technique...

Slide 10

This argument is so stupid.

[tqbf]

Like Ultra-Wide-Band networking and enterprise XML integration, this column fits a Cringely mold of writing an entire article about the business plan of one small company most people haven't heard of, and passing it off as an important insight about the IT industry as a whole. It works for the most part because there are a lot of neat-sounding business plans out there. Every start-up company in the world has a story about how their vision, fully realized, would shake up the entire industry. It makes for great column-fodder, but provides poor analyses.

If you read the whole column here twice, you immediately become aware of the fact that Cringely's entire "argument" turns on the idea that security rests on keeping source code secret. Because "interpeted" code "always" discloses code secrets, "interpreted" platforms like .NET will require the intellectual property wrapped up in schemes like PSCP. Therefore, the "inventors" or PSCP hold an important position on the chess-board of the entire IT industry. Microsoft and Sun will launch bidding wars to ensure they control the PSCP IP.

Of course this is just crazy-talk. Just for a moment, leave aside the argument that something like PSCP can really prevent reverse engineering. In the post-PSCP world, all security rests in a distributed repository of millions of lines of source code "locked up" in an organization that spans 45 buildings and untold tens of thousands of people in Redmond. You can't keep source code secret. Closed source is a speed-bump to dedicated attackers, who will break into networks, find corrupt insiders, or even get janitor temp positions in order to get the code.

Nobody working in security seriously believes that the source code for Windows 2000 wasn't floating around the computer underground years before the most recent disclosure. 'Twas ever thus: most of the SunOS and Solaris exploits that powered attackers in the mid-90's were derived from stolen Sun source code. Stolen source trees have always been the most stable currency in the computer underground for exactly that reason. What you do with the compiled product of that code makes no difference if the blueprints are already in enemy hands.

I'm not sure it's even worth confronting Cringely's argument (that PSCP is a strategic technology that is crucial to .NET security) head-on, but I think I can make a decent response simply by evoking video game copy protection. Companies went through all sorts of contortion to devise copy-protection schemes. Kids with the Microsoft Macro Assembler bible thwarted them, because, just like in the DRM/Media battle, when you control the entire player architecture, it is impossible to completely secure the content. Regardless of whether PSCP makes it harder to grep out the cookie cutter exploit from the .NET IR, the payoff in the "battle" between code-obfuscation and exploit generation is much higher than the payoff to defeat copy protection, and nobody has ever won the copy protection battle.

Cringley is right every once in awhile (business plans occasionally do pan out!), like with Eolas and Burst. I normally wouldn't care enough to comment, but this time he's inadvertantly promoting a damaging and popular misconception in his article.

Re:This argument is so stupid.

[Yaa 101]

I like your post and agree to a large part but 1...

", and nobody has ever won the copy protection battle."

There are a lot of small time winners of these battles, called your local pirate, although not so much anymore now than used to a few years ago...
Nowadays more people have means to get that themselfs.

I would even predict that they will win the war as only 1 of the 2 parties involved is standing with it's back against the wall, namely the inflicters of these wars, the people that believe in copyright protection.

People tend to make large mistakes when constantly under pressure, this subject is not different.

Re:This argument is so stupid.

[Anonymous Coward]

From all arguments I've read, the copy protection scheme has been won for games. Not always but sometimes.

A game copy protection scheme that keeps out broken versions for simply two months is a win. Thats when most sales of hyped games occur. Investing in a protection scheme that lasts for 2 years (assuming somehow money invested means better protection) isn't at all necessary.

Re:This argument is so stupid.

[cardshark2001]

and nobody has ever won the copy protection battle.

Well, that's almost entirely true. There is one example I can think of though, in which a company won a pretty big skirmish....

There's no copy protection in Quake3. However, there is a proprietary key that is required to play on the internet. If you give this key out to anyone, you can't both play at the same time, and you also run the risk that the person you gave it to will also give it out, and that eventually you won't be able to play on the internet. Noone has been able to reverse engineer legit keys, because the algo is secret, and is server-validated.

Of course, one could run a rogue server that didn't care about keys, and rogue clients could connect to it, but most of the servers out there are legit.

Re:This argument is so stupid.

[fermion]

All you say is true. However, in my understanding the point of security is to help quantify and deal with risk. For instance, code available to a determined few is not the same as code available to everyone.

That said I believe you are correct in the assesment that this technology provides little to no security benifit. The problem is that this is exactly the kind of product that will make the PHB feel better. In that sense, it may become an important product in the .net world. After all, what benifit does .net provide other making the PHB feel secure in thier jobs.

Cringely promoting security through obscurity?

[AttilaSz]

From the article:

"(.Net) ...effectively exposes source code at the very heart of Microsoft consumer and enterprise applications. The result is that nearly every emerging Microsoft product is vulnerable, including the OS itself. That's one reason why we are always hearing more, not fewer, stories about Microsoft security problems. And that?s why Microsoft security updates are now at least a monthly event."

So, the guy claims that we're seeing more reports about Microsoft security problems because code written for .Net platform is easily reverse engineered? Looks to me as if he hints that hiding the source code prevents the risk of security problems through bug exploits.
Well, even if it were true, it certainly isn't true that we see more Windows security updates because of visibility of code written for .Net. The code of almost all Microsoft products is written in plain old C.
Oh, and BTW, since when is it a problem if we see at least one security update/month? I'd be anxious if there were *none* for a month! (I understand that can be a nightmare for sysadmins, but I'm lucky to only have two laptops and one desktop machine to maintain at home)

Tools can be reverse engineered.

[DroopyStonx]

Dunno the point of all this. Seriously, if you think about it, there's no way you can make your code 100% unreadable.

The tools that PROTECT your code can be reverse engineered as well. What then?

I Should be paid to read articles like that...

[Tarwn]

I found myself less informed after reading that article, less intelligent perhaps as well.

First of all, anyone that intends to write an article about a "new" software engineering theory or theoretical application needs to make sure they not only understand what they are talking about, but they also choose to collect quotes from people who know what they are talking about.
Here's a hint, if the person says "leverages" in a serious tone of voice they are either a sales-person or only received information from the sales team.

Now, beyond the other comments I could add, such as bad definitions of the framework, and the authors inability to name more than 2 examples of languages available to interact with that framework, there seems to be a large problem with the research content. There isn't any.

I could likely spend 20 to 30 minutes researching background informaiton on the internet and still have a more solid article, simply because I would have real information.

The information provided in this article appears to be the results of carefully skimming sales brochures. There is no real information on the processes involved, reverse engineering, or numbers invilved in terms of performance.
We find out that there are "...billions of paths..." but this is just marketing talk, obvious for it's lack of detail. Reverse engineering is detailed as something used by hackers (in the newer, negative sense) to find holes in code. There is no mention of the other side, ie reverse engineering old software when the original developers are not available and no one felt documentation or up-to-date source code was necessary, among many other valid and legal reasons for reverse engineering. There is a brief comment about the extra resource usage, but it is considered negligable (in comparison to...?) and in fact this process is also mentioned as having no negative impact. tanstaffl.

All in all this sounds like something that will be overhyped, overused, and in the end more of a pain than anything else. Clueless managers everywhere will demand all of the code use this new and impervious format when there are many easier ways to prevent security loss without the so far unknown problems with this new method (not to mention security holes in the obfuscation methods itself).

Now when people try to reverse engineer code to look for security holes they won't find them because the holes were swept under the carpet. I may stand up for MS more often than deride them, but the kindest way I can say this is that this new method of obscurity is a little less than bright. Just as I wouldn't use anything beta from MS, you can bet that I won't be using this technology either. I prefer solid code, testing, and a solid license. By the time they have finished reverse engineering version 1, the next version will be underway, leaving them just as far behind as before.

Re:I Should be paid to read articles like that...

[Ancient_Hacker]

Cringely does seem to have a very thin grasp of these concepts. "renaming every varaible to a" I suppose means removing or zapping the naem table-- something real code crackers have done without for many decades (and had to before debug info in the binary was popular). If the code is obfuscated, what's keeping someone from patching the de-obfuscator so it dumps out the good code to a file? Sheesh. Besides, it's a FUN challenge to reverse-engineer code. Better than crossword puzzles, and more challenging than acrostics. Bring em on!

Old news, folks/ Sorry.

[MsWillow]

"Morphing" code is not new. Heck, Alan Turing thought being able to have code modify itself was a *good* thing, as do. Back in the early days of DOS for the PC, I ran into many programs that "morphed," some to cram more code into the limited RAM (which was then called "overlaying"), and some to hide what went on inside as a copy protection mechanism.

As a high school student, back about 1977-ish, I even concocted a self-modifying program, in HP 2000 Access BASIC, long before I heard that it wasn't new. Trying to think parallel, to be able to design it, was most entertaining, and it later served me very well, both in optimising overlays for a communications program for DOS ("Backcomm", anyone?) and in removing the copy protection from games I bought.

Maybe with protected mode, C++, and nobody being taught that code space is really data space too, this technique appears to be new. *sigh* Guess again. It's been around, in one form or another, for decades.

Snake Oil

[roman_mir]

What a load of crock, this is definitely aimed at the CIOs and the so called CTOs of some large corporate IT divisions and it for sure will be another big buzz in the next round of 'architectural' meetings. And some of the so-called architects (I have a few in mind) will without doubt will push this shit forward as another excuse for taking up space in their positions, when in fact they are totally useless and constantly still other peoples' ideas.....

sorry, I am bitter :)

On the other hand byte code obfuscators will not stop anyone who wants to disassemble. I remember about 9 or 8 years ago I was disassembling a simple DOS com file (anyone remembers inclogo.com, with a INCLOGO word being printed in a 320x200 graphics mode with some simple 256 byte coloring and shading that changed in a loop? It looked cool, so I wanted to find out how it worked.) Couldn't figure out the machine code for some reason, so loaded it into the Turbo Debugger :) good old days, and followed the trace. Well, duh, it was self-modifying. In a simple loop it would modify the entire execution tree by XORing every byte with the next byte. All of a sudden a portion of the code that was obfuscated was readable machine code again. So all I had to do was write a C program that read the com file and spat out the deobfuscated version.
Ta da!

done.

How is this going to be any different? Code cannot be obscured to the hardware and a cracker works at the hardware level.

Doesn't this sound to you like the commercials for the 'new and improved 1024 bit encryption' that sometime ago was put out by one Israeli company (there was an article on /. about this, anyone remembers?)

This is snake oil.

psst..

[Anonymous Coward]

It's been known to happen, that modders occasionally use modding as a form of creativity - y'know, humor, et al. - in its own right.

Quake is still fun!

[Tei]

I play Quake everyday, and still new mods appear very interesting. Check this sites:

www.inside3d.com
www.quakesrc.org
www.fuhquake .net
www.quaketerminus.com

You will found that Quake fun has not end.

It's not about learning, it's about plagiarism

[Tim Macinta]

Sure. But what will they learn? How the code processes MouseEvent.MOUSE_CLICKED? How you use sockets? How you show that nifty splash screen? I mean... who cares?

"Super-secret" algorithms aside, it's not so much that I'm worried they will learn how to do what I did, it's more that I don't want people reusing my code without permission. I've found people who have copied pages from my website almost verbatim, and even one person who blatantly plagiarized a page of my and changed "Copyright Tim Macinta" to "Copyright his name"! Granted, that's a little easier to do with HTML than with Java, but if it's simple to protect against by using an obfuscator, then why not? I really wouldn't mind people learning from my code, it is actually reusing the code without permission and without attribution that I am protecting against. I'm not just being paranoid - I had somebody email me the source code to an applet I wrote once (which he apparently decompiled) with a note along the lines of "Ha, ha! Now I have your source!" I don't know what motivates these people, but there are enough of them out there that I have since started obfuscating almost everything as a basic precaution.

Going off topic now, but, anyhow, nifty!

Thanks. It's not as off-topic as you think. I used obfuscation with MMB (which is a client side Java app) to prevent plagiarism and reduce the siez (barely). Nothing about it is "super-secret", although it is a little more complex than just routing MouseEvents around.

Re:It's not about learning, it's about plagiarism

[tcopeland]

> I don't want people reusing my code
> without permission

Hm. Fair enough.

> "Copyright Tim Macinta" to "Copyright his name"

Jeepers. What a low blow.

> I had somebody email me the source code to
> an applet I wrote once (which he
> apparently decompiled) with a note
> along the lines of "Ha, ha! Now I
> have your source!"

Yeah, but you could have written him back saying "woop-tee-do, so what?" I mean, what's he going to do with the source code? Start a business and sell it? Probably not, and if he did you could email his business partners and let them know what kind of fellow they're working with. Or post a note to some place like Slashdot.

It just seems to me that a product like, say, MMB, is valuable not just as source code, but also in the support and updates and so forth that you and your company provide. So if some loser decompiles the code and posts it on a message board, the only folks that are going to download and use it are people that wouldn't have bought the product in the first place.

Anyhow, thanks for the note, glad the obfuscation is working well for you. Food for thought...

Re:It's not about learning, it's about plagiarism

[Anonymous Coward]

You are really not that important. But if it makes you feel good go for it.

Dig a hole. Bury that bone. Just don't forget the tombstone.

OO

[Gr8Apes]

That's what OO is for. Properly designed and architected, there will never be a question about what you're getting back. (Since you should never see a data member outside of its class.)

Re:OO

[B'Trey]

Pure OOP certainly solves some of these problems but , like Hungarian notation, it introduces problems of its own.

Of course, as a programmer you often have no choice as to what language you're working with. And as a maintenance program, you have no choice at all.

Re:OO

[E_elven]

Yep. Code like..

class something
{
...
public:
const std::string & id() {return _id;}
};

..is nearly unheard of.

I don't like Hungarian. I prefer obviousness, comments and agreements (as in, 'we do not use char*'s for strings in this project.')

The weakest link is...

[Yaa 101]

The program itself...
I remember from my C=64 days some very clever ways of protection of binary runcode involving morphing, decrypting and even help of devices, mainly the 1541 diskdrive with it's own 65xx and I/O chips on board.

For the windows platform the only thing you need is a good debugger ala WIN-ICE and startup the program, the art is to find out where to put the breakpoints and when/where to change data segments.
Mainly you let the program itself solve your problem.

And this is the weakest link...

Best copy protection is not to distribute your code, better one even is not writing your code.

It won't work.

[master_p]

A cracker could hack the obsfuscator code, which has to remain static throughout the program's execution, in order to completely bypass run-time obfuscation.

Re:It won't work.

[TruthSeeker]

Even if the obfuscator code was not static during execution (self obfuscating obfuscator ;->) the actual program using it would contain a static bootstrap sequence which could be "easily" reverse engineered.

Solution in search for a problem

[Bugmaster]

I agree that this real-time code-mutating thingy is pretty cool. But... why ? You take a moderate-to-major performance hit (all that code won't morph itself), and for what ? To stop people from reverse-engineering your program ? Why not just write it in a secure manner to begin with, so that reverse-engineering is not a threat ? It works for OpenSSH, after all, it can work for anyone else too.

Re:do what SCO does

[Anonymous Coward]

and hide the code by using a greek font.

gcc -S

[tepples]

Actually, even stepping through the execution of your own code can give you insights into how the compiler operates

Any more than gcc -S, which outputs assembly code instead of object code for a module, would?

I knew a C programmer who used to declare const strings and arrays local to each of his functions. I had to point out to him that these get copied onto the stack every time the function is entered, severely slowing program execution -- and he might want to consider making these static!

What kind of crap C compiler would allocate function-local const arrays auto by default?

Re:gcc -S

[Anonymous Coward]

The point was that the act of stepping through it gave you the insight. If you run gcc -s, you get no additional benefit... unless you then proceed to look at the assembly.

Re:gcc -S

[El]

What kind of crap C compiler would allocate function-local const arrays auto by default? diab. Hey, it must be better than gcc, 'cause you sure pay a lot more for it, right?

Re:gcc -S

[tepples]

True, but the point was that it's often easier just to look at the assembly language code for a module that your profiling has deemed a bottleneck than it is to configure a debugger. I wondered if the latter provided any specific benefits.

An example...

[inode_buddha]

... of code morphing under Linux, using assembly can be found here. The imagination runs wild...

More branches, eh?

[topynate]

Anyone heard of superoptimization? As in, automatic analysis of running code to reduce branches?

Interpreted?

[Dunedain]

I get two paragraphs in and notice he claims Scheme is interpreted. This is nonsense. Scheme code can be run by an interpreter, but interactive compilers have been standard practice for years.

Just what we need: more bureaucracy

[Anonymous Coward]

I find the topic to be just as useful as discussing the need for lawyers. Why can't companies strive for (accurate | stable | faster | extensiable | portable | open) code rather than put more and more efforts into secrecy, needless complexity and proprietary bases?

I would love to see any of the first set come first.

All we need is an obfuscation bug to end up detecting a false compromise situation and cause your entire platform to come crashing down.

It's just another layer of red tape to allow Microsoft and other paranoia-bound entities to stunt progress.

Half-Leak

[tepples]

Klingons do not make software 'releases'. Our software 'escapes'

You mean like Valve's Half-Leak 2 incident?

Re:Half-Leak

[dnahelix]

Oh, this is so important.
You should make a career of it.
I can't wait to get more mod points, so I can mod down anything you write.

Re:Half-Leak

[dnahelix]

DAMMIT! This was supposed to be a reply to darkhelmet's stupid response.

I think that I have a better obfuscation method

[rock_climbing_guy]

o yjoml yjsy o jsbr s nryyrt pngidvsyopm ,ryjpf/

Crack that code, you crack-smoking dirty rotten intellectual property thieves. Oh, and by the way, am I the only one who thinks that musicians are already applying this obfuscation to their music for the RIAA?

Rationalizing secrecy

[tepples]

Yet, I have no doubt

Then quit patronizing Interscope Records.

There are probably some rare instances when a specialized software technique is developed and you want to keep its implementation specifics secret. I have yet to run into a single instance of this after many years in the industry.

In other words, you never worked for a company that developed video codecs, 3D card drivers, or 802.11 card drivers.

The Research

[Coppit]

If you are interested in the research behind all this, see Chenxi Wang's dissertation. Here's a paper on it. The approach recognizes the fact that security is about raising the bar high enough to make it too much work for hackers. By changing the code on the fly, the hackers have to start reverse engineering it all over again.

I obscutify my code the old fashioned way

[Anonymous Coward]

Spagetti. Not to mention the spelling mistakes.

Cloakware!

[Anonymous Coward]

Great company here - I applied to work for them last year, but didn't make it beyond the initial interview (I suck I guess) but they do this and seem to make a profit out of their process. They have a series of white papers on their site. Great stuff to google for.

Crap logic

[arrianus]

Cringly somehow equates difficulty of reverse-engineering with security (in the sense of buffer overflows, etc.). Other than weak arguments about security-by-obscurity, it holds no water. The NSA has automated analysis tools that look for buffer overflows and the like. Plenty of attacks come about with people just throwing random packets at a machine, and seeing what crashes it. In addition, in spite of the well publicized NT source release, Microsoft licenses Windows source to universities and other organizations, and it is fairly wide-spread. Anyone who really cares can get it.

Very few people will reverse-engineer source code to make a competing product. With the exception of file formats and the like (Word format, DeCSS, etc.), it is generally much faster to reinvent than it is to reverse engineer -- this is often true even when you have the original source code, with comments. I guess the only other place I can think of where reverse-engineering might make sense is highly-optimized algorithm (3d rendering, video compression, etc.), but even there, it's sketchy as to whether there is any real benefit.

He goes on to talk about how source code watermarks are impossible to remove. Quite frankly, I've never seen a watermark in a non-lossy data format that's impossible to remove. They just take different amounts of time and effort.

I used to think this guy had a clue, or some insight once in a while. This article is just so confused, and wrong in so many ways, that we Cringeley has no grasp of basic technology. Damn. it sucks.

Yep, this is just self-modifying code.

[Anonymous Coward]

PSCP is fancy patent-speak for self modifying code, ala "Reflections on Trusting Trust" by Ken Thompson.

This article has several glaring errors:
1. Most of MS problems are due to buffer overflow problems in compiled code, not MSIL.

2. He is really talking about protecting code from theft, not security from hackers. Must be that MS kool aid going to his head.

3. There has to be non-trivial overhead with the PSCP process. If you are scrambling things at run-time, there has to be a run-time monitor doing the scrambling and something doing the unscrambling or translation for the processor. These scramblings have to have deterministic patterns, otherwise a computer wouldn't be able to execute instructions, load memory, etc. These patterns can be hacked. Also, these patterns are based on pseudorandom number generators, which can be hacked. The only thing this whole process will do is make core dumps harder to parse for the Indian technical help desk in Hyderabad.

4. Setting all variable names to a single name (e.g., 'a') in a program is the dumbest description of an obfuscator I've ever read. I've studied them in depth and have never heard of this.

Part of article doesn't make sense.

[1tsm3]

Looks like the author is getting carried away. I understand what he is talking about obfuscation and difficulty in reverse engineering. My point here is about the "digital rights management" and the "PSCP code renaming signature".

He says PSCP can be used to sign or water mark code so that stolen code or license agreement violation can be tracked down. He also says it will remove the need for copyright notices on Open Source projects!! He seems to be missing one big point here - the PSCP works on the byte code and not the source code that is being stolen or give out as Open Source.

When source code is stolen (as in the case of the recent M$ source code) the hackers get the source code that the developers work on. NOT the byte code to which PSCP has been applied!! And I'm damn sure that PSCP is not applied to the source code that the developer is working on-
1) Then he himself cant understand his code.
2) PSCP works like a byte code optimizer, It doesnit change the source code. Optimising the source code is the job of the programmer, not the PSCP program. If it were otherwise, then there will be no demand for skilled coders!!

Result - stolen code can't be tracker and hackers cant be Googled to jail!! At least I think I'm right in this one. Correct me if I'm not.

Clash with the Cache?

[jobbegea]

Wouldn't self modifying code be in conflict with the advanced pipleines and program caches of present days CPUs? Looks to me like asking for trouble

Does not compute

[http]

...and me with mod points.

i never thought i would quote linus torvalds, but in this case, you are a weasel.

you're right to say that the GPL does not have the word 'obfuscate' in it.

you're wrong in that code obfuscation is deliberately making something into an unpreferred form, namely, a form where it is not clear what the hell is going on, and hence effective/correct changes are difficult to make. how much more explcit do you want it to be?

as analogy (and normally i hate argument by analogy, it substitutes intuition for proof) no law (where i am, at least) explicitly forbids you from pointing a loaded firearm in my direction, either, but it's not something you're allowed to do (where i am, at least), and something that even morons can figure out you're not supposed to do, which is why they're not locked up.

damn ac's...such a necessary evil...

Oooo... Self Modifying Code, version 2.

[SmurfButcher Bob]

Yep, harkens back to the failures of the old Apple ][ era.

Self modifying code did little more than provide an extra 30 minutes of amusement.

It didn't stop any of us back then, it sure as hell won't stop anyone now. Apparently, these idiots have never heard of things like Soft-ICE.

Reverse engineering isn't hard, it's just tedious without the source. OTOH, we've been doing it for decades without source... it's only recently that we've had the luxury of (sometimes) having it. Regardless, these boneheads seem to confuse "reverse engineering" with "decompiling" - the two have nothing to do with each other.

"Changes variable names"... rofl, that's really gonna screw up DEBUG, isn't it...

Re:Oooo... Self Modifying Code, version 2.

[Teancum]

I totally agree. I remember some of those very silly anti-priacy schemes on the Apple ][, some of which were rather inventive.

It all boils down to one simple thing: In order to run an application, you have to be able to load it into memory. Unless the software vendor has the computer itself sealed with propritary and private opcodes in the CPU with custom hardware that self-destructs when opened, you will always be able to follow the "boot" sequence of the software, be able to emulate the CPU directly, and in that manner be able to completely reverse engineer software. Code morphing only adds a speed bump, and a rather small one at that.

Code morphing is much more practical when done like the Transmeta folks are doing with their CPU's: To speed up processor utilization when the software is using a bloated CPU instruction set (like the x86 CPUs by Intel). Merely adjusting and changing pointers through some psudorandom algorithm just isn't going to work to really stop a determined and competent software engineer from being able to interpret the same code that a machine also has to be able to intrepret.

I thought that maybe using a true random number generator (like a radioactive source generating seeds for the generator), but even this could be defeated for the discussion described.

The iron-clad anti-priacy would only be practical for some very secure military applications where designing a CPU from scratch could be considered a resonable cost-center for the project. You will never see something like this in mass-consumer products.

Code is ALWAYS un-obfuscateable -- but ...

[Anonymous Coward]

Obfuscation has value in that it makes it harder to crack programs. The harder you make it, the less people succeed, the less people succeed, the better.

If an obfuscation algorithm is created that makes it REALLY hard -- no one will tell you its unbreakable, its just really hard. And that's the point.

bleh

[linkdead]

The way I see it, you simply place the executable on your computer, make a copy osmehwere read only (cdrom), and start cracking. Sure it may change, but that's what your rad only backup is for. if your scared of the app phoning home, remove your phone line or network cable.

Really this kind of protection is not more secure, or even more difficult to work with. Remeber polymorphic code has existed since the 80's. Only this time it's being used on more complex programs, and as such is more likely to generate bug or reveal existing ones.

Anyways, do you remeber the whole AI spiel? So where's my computer that knows when I'm home and start up my games on it's own?....oh wait...I have to program it to....so much for AI...sure it's around still, but it's practically still a toy, much like I feel polymorphic code will never take off.

But it's patented!

[Anonymous Coward]

You guys who say this doesn't work are missing one detail. THIS IS PATENTED! That proves it's great. The patent office would never issue a patent to something that isn't brilliant.

This is on a par with Amazon.com's one-click ordering! Where can I buy stock!?!?!?

O vs. 0

[phlegmgem]

Why not just rename all class, method and variable names some combination of zeros and letter-O's. Along with removing whitespace and several other techniques, this could prove quite humorous to try to decode.

include OOO00OOOOOO;class OO0OO00OO extends OOOO000 {private int OO000;public String OO000000O(int OO000O,double OOO000000){return OO000O*OOO000000/(OO000+1);}}

Practically speaking, though, you could maintain a translation table to convert this back into it's original format for maintenance purposes. Imagine 100,000 lines of this sort of code...

Never the same code twice? Yikes...

[dpbsmith]

...that obfuscator had better be completely bug-free.

Just suppose that every once in a while the obfuscated version of the code just isn't exactly 100% functionally equivalent to all the others.

How are you ever going to debug that?

It's far worse than a bug in a compiler optimizer.

Worse yet, this could even be used to attack competitors. Let's say the obfuscator has the ability to distinguish code from different vendors in some way... (well, for example, let's supposed the code is signed). It could subtly sabotage the products of certain vendors so that they seemed to be buggy or unreliable... and the victim would never know what had happened or have any way of knowing what had happened (assuming the victim could not reverse the obfuscation).

Re:Never the same code twice? Yikes...

[Anonymous Coward]

And then imagine what an obfuscated obfuscator could do !
Or a beowulf clus<BLAM!>

gcc -s -O

[Ayanami Rei]

Well that was hard. Obfuscated and no variables in the stacktrace, nor non-public function names.

The parent was implying that the deobfuscation is code de-tangling (trying to recreate essential branch control structures out of the purposefully complicated bytecode or object code). He wasn't implying you get variable names back or anything like that.

But I mean, do you have to know that:

int * unknown_function1(int param[], int param2[]) {
int * auto_int_p = malloc(12);
auto_int_p[0] = param[2]*param2[1] - param[1]*param2[2];
auto_int_p[1] = param[2]*param2[0] - param[0]*param2[2];
auto_int_p[2] = param[1]*param2[0] - param[0]*param2[1];
return auto_int_p;
}

was originally was called cross_product? There are only so many ways to write certain things.

Sounds like something that happened at Apple

[Larry David]

Another Hungarian experience at Apple in 1982.

It Won't Work

[ajs318]

If a computer that was designed by human beings can make sense of an obfuscated programme, then it stands to reason that a human being could make sense of the same programme. It's exactly the same idea as "if it can be played then it can be copied". If it can be executed then it can be examined.

Sooner or later, somebody will come up with a simple de-compiler that will produce a programme full of IFs and GOTOs from a binary executable, and allow you to rename the variables to have sensible names on deducing what they are for. Somebody else will further refine it to automatically recognise loops and functions, and extend the rename functions accordingly. For example, incrementing a variable and conditionally jumping back to an earlier point in the code if it is less than a certain value looks like a for loop.

And once that genie is out of the bottle, there's no putting it back.

I suppose I shouldn't really keep rising to all this bait. I have faith that anti-"piracy" protection is ultimately impossible, and that Open Source will end up prevailing over Closed Source; and that should be enough for me. All the same, I don't see how anybody could not believe these things -- which I suppose is what motivates me to preach my beliefs.

Ill-Informed (and it's what you wanted anyway)

[ClubStew]

This guy is so ill-informed. Yes, .NET is a JIT'd language like Java, but this isn't the reason for so many MS holes recently - those are good ol' buffer overflows, something the Common Language Runtime (CLR) protects against.

Even disgregarding the last statement, Microsoft has currently not shown any massive holes in .NET-based software. The holes have been in native applications like Winodws itself (currently uses no .NET - or managed - code in the core libraries), IIS (again, no managed code), etc.

Yes, this does provide a way for people to view the Intermediate Language (IL, or MSIL with MS extensions) embedded in modules within assemblies, but isn't this what the OSS community basically wanted anyway? It's not open source, but it does provide insight into how Microsoft is doing things. I commonly find myself using ildasm.exe (the IL disassemblier that ships with the .NET Framework SDK) to get insight into how they achieve this or that. Microsoft even condones such a practice in many of their MSDN articles (sometimes even disassembling, changing, and reassembling the IL in order to derive from a class at compile-time).

Article Title

[telstar]

I think Cringely got it right when he titled his article "Mininterpretation".

Code like this will be slower and more fragile

[alispguru]

The original article quotes the code-morphing guy as saying:

And the increase in processing overhead is trivial. PSCP, if done right, costs almost nothing.

I don't believe it. This stuff can't cost "almost nothing" if it works with threads. If you have multiple paths of execution running through the same code, and the code is being dynamically morphed as the threads run, then either:

The morpher is fully thread-aware, to keep morph operations for thread A from pulling the rug out from under thread B (or C, D, ...). This implies extra sempahores, locking, unlocking, and the overhead of handling them.

The morhper is not fully thread-aware, and every so often the morpher for one thread will clobber another thread.

Am I missing something here?

Re:Code like this will be slower and more fragile

[Rocinante]

Am I missing something here?

Yes, you're missing something very important: the code-morphing guy is lying through his fucking teeth. This whole thing is a scam that will be sold to the same dipshit PHBs who are deploying dotnet in the first place.

As for Cringley, I want some of what he's smoking.

why yes

[TheLastUser]

Mostly for the space savings, reduces the overall size of the jar and makes applets load faster. Wouldn't bother for server side code, but I always add an obfuscation task to my ant build script for applets. Check out the yguard obfucator.

Probably really useful for j2me stuff, and web start apps too.

Ok, but what about...

[cb8100]

Last time I reverse engineered a running program, all I got to look at were the x86 assemby instructions and registers, not function names and variable names.

Obfuscate THAT!

Re:YOU FAIL IT!?

[Anonymous Coward]

Goatse.cx no longer works, moron.

Re:Advice please

[Anonymous Coward]

well, shift your child away from child pornography such as the infamous "*BSD Chick" and over to of-age porno, preferable of the gay nigger type.

If you need any more advice, feel free to join #GNAA on EFNet

--Penisbird

Re: OT grammar flame (or rather slow roasting)

[Anonymous Coward]

> I'm more annoyed at whomever actually modded this funny.

I'm annoyed when people use "whomever" when they mean "whoever." :)

FYI, the case of "whoever" is determined by its function in the dependent clause that it introduces, not by its function in the main clause. So you'd say, "All our base belong to whoever set up us the bomb," and "I, for one, welcome whomever our insect overlords choose."

I usually like Cringely's stuff but...

[Anonymous Coward]

...this column is incoherent.

Microsoft's security bugs are not due to .Net. Most of their own products are not managed code. They are C++. Getting buffer overflows in .Net is about as likely as getting them in Java programs.

He claims .Net is insecure because you can read the source easier. But opensource is pretty secure, and the fact that C++ code is compiled doesn't help it a whole lot. Counter the weak protection of compilation with the built-in security policies that the .Net runtime can enforce, and I'd say managed code is more secure out of the box.

The real kicker is when he advocates using an obfuscator to watermark opensource code. Um, yeah. That'll work.

Why go through all the trouble?

[Cyno]

Why not just print your code out and lock it up in a safe because nobody is going to care about it in 5 years.

Your Intellectual Property is stupid!

Re:Why go through all the trouble?

[edgedmurasame]

Well, some people value their "Intellectual Property", and the results they bring to people. As for protecting something, you should go as far as you need to make the pool of people as low as possible that can easily defeat it. That's how Ubisoft worked in the past with their products, and they only went far enough to get the sales numbers out, they knew they were going to get cracked - just that Ubisoft delayed it while they sold to the people who would buy it. I dont exactly like the idea of IP, but I dont like some other ideas, but I live with both and deal with both when things go Horribly Wrong(TM).

Variables that lie

[lolits]

Reminds me of an assembler language program I once had to fix, in which the programmer had equated "R5" with 3.

This stuff belongs in the same category

[His name cannot be s]

This stuff belongs in the same category as the Infinite compression technology, the Bidirectional unbreakable encryption that works like a one time pad (but it's generated, so you don't have to exchange anything) and the Sasquatch.

FUCKING FIGMENTS OF PEOPLES IMAGINATION!

feh :p

Worth it?

[Asprin]

Number one, Cringely kicks a whole lotta ass. 'Nuff said.

b) In reading his sketch of the likely-soon-to-be-patented PSCP technique, I was reminded of The Story Of Mel [pbm.com]. Anyone think this qualifies as prior art?

III. What exactly does .NET bring to the table that is worth all this? I mean, look at it! This is a really complicated and convoluted technique for solving a problem that we don't have yet, right?! Could someone please explain what's so wrong with what we're doing now that makes these changes look like a good idea? Seriously! I'm confused! Open source doesn't have these problems, does it?

Who needs this?

[Anonymous Coward]

If yout technology 'depends' on this you're fucked. Get out of software and try farming.

I call bullshit

[heironymouscoward]

The article describes the encryption technique as a way of signing open source code. But psudo-randomly changing all the program's variable names, in the source code, apart from being impossible to do at 'runtime' (it's source, remember), makes the open source code aspects null.

How can you submit a kernel patch that contains mangled code?

Bah. A useless article that hypes a junk technology designed to solve a false problem created by a weak solution to a weakness in a marketing-driven architecture that answers what is, anyway, a pretty simple question... how to write software people can use.

Re: And therefore...

[gr8_phk]

"which in turn requires "trusted" hardware to prevent substitution of an untrusted OS"

And therefore, you don't need to obfuscate anything because the user won't have access to it in any form.

Finally an acronym for an old thing...

[j.leidner]

"PSCP" is not new at all. Some Commodore C= 64 games back in 1982 were delivered in an encrypted form. Only a short window around the program counter's (PC) current position would be decrypted on demand by an interrupt-driven procedure.

Empirical study shows that such protection mechanisms are very weak.

New CPU prevents Buffer overflow exploits

[Anonymous Coward]

The new CPU that are designed against buffer overflow exploit - essentially prevent executing code from data space. This also mean that self modifying code is out of the question too.

Re:New CPU prevents Buffer overflow exploits

[TheLink]

"The new CPU that are designed against buffer overflow exploit - essentially prevent executing code from data space. This also mean that self modifying code is out of the question too"

Those CPU features only protect data from being executed by the CPU as machine code. They don't protect data from being "executed" by a program which is what happens for interpreters, JVMs etc.

So it remains to be seen whether self modifying code at a high level would reduce performance significantly - the self modification may not be at such a fine granularity at the CPU machine code level, whilst it is fine enough at the bytecode level.

Dunno what will happen when you involve Just-In-Time compilers though.

If indeed there are so many different versions of your program whenever it executes, then if someone reverse engineers your program and just extracts the "way it works" and reimplements it, then it's even more arguable that that person isn't copying your executable - since there isn't an original executable as such.

The other problem would be debugging. Anything that makes it hard to reverse engineer would make it hard to debug, easy to debug = easy to reverse engineer.

Reverse Engineering happens, but I thought nowadays many people are more interested in _rapid_ development? So if this makes things hard to debug, hard to QA/test (is the "random" bug in the code or in the morpher?) it slows things down.

By the time people reverse engineer the details of your stuff, you'd have come out with the next version. The obvious cool stuff won't be hidden by morphing anyway.

Re:Rationalizing your dumb ass

[Anonymous Coward]

blah blah blah...that developed video codecs, 3D card drivers, or 802.11 card drivers.

Which is all pretty rare as software development goes. But at least you proved someone else's point.

Simple use "ii"

[NotQuiteReal]

for (int ii=0; iiblah; ii++) ... Doesn't take much longer to type, and if for some odd reason, you do need to search, looking for "ii" is unlikely to turn up anything else...

Huh?

[JacobO]

I can't help but feel like there's something I should already know (but don't) when reading Cringely's material. The articles that I have just read (linked and related) seem to go into some detail about a topic (obfuscation, interpreters, high tech secrets) but then without any good reason he expects us to believe that we are somehow "vulnerable" because some module of code can be reverse engineered. Perhaps we are to believe that because of .NET we are all going to have our secrets stolen.

The result is that nearly every emerging Microsoft product is vulnerable, including the OS itself

Now, it seems to be that the only conclusion being drawn is that my OS is vulnerable because someone can reverse engineer its code as if understanding it makes it less secure. Is Linux any less secure than Windows because everyone has access to its source code? Isn't this really an issue for people who "need" to keep their source code from prying eyes so their IP is not stolen?

This one is quite confounding:

Microsoft is absolutely committed to .NET, yet .NET as it stands today is very vulnerable to security lapses

What is a "security lapse" and why does lack of good obfuscation tools allow it? Am I vulnerable without tried and trusted security through obscurity?

Looking further back at the article on .NET from November 8, 2001, there is an interesting theory on how .NET is Microsoft's way of tracking all "calls" through "Windows' communication system" (whatever that is) to record any use of non-MS services so the third-party provider can be summarily squished.

Watch out everybody, the black helicopters are circling overhead.

Are moderators really using crack for breakfast?

[RobertB-DC]

If a CPU can understand your code, so can a human. The solution to this problem are licenses, not obfuscators.

Now, I've had my comments in this vein modded "Interesting", but the "Funny" mods usually arrive soon after. It's always good for a laugh, +2 Interesting on a robotics story where I link to a Short Circuit page.

But this takes the cake. +5 Interesting for a comment that says [spoiler alert?] that the best way to make a program secure from reverse engineering is to make it unrunnable. And that the licenses we love to hate are the solution.

Great post, funny as all get-out. I had to re-read it to get it, which made it even better.

I'm glad the poster got some karma points, but it's time to add some Funny mods to the mix now. Put... down... the... crakpipe...

slashdot clueless again

[Anonymous Coward]

a million monkeys all banging on their typewriters... do any one of the commenters saying "this can't be done" or "this is nothing" actually know what they're talking about? NO. because none of them have read the patent filing. so forget it. you can't say much useful about this until you know *what it is*. ie. RTFA.

having said all that, i can say that i've been thinking about this same thing over the last few weeks and it would indeed make it impossible for anyone to reverse engineer the internals of your program - at least my version of it. you could still put hooks in where it connects to externalaties like MessageBoxA, but the program itself would be transformed in such a way that the result of execution is the same, but the path it takes to get there is completely insane...

there are two parts to this: #1: lossy transformations... just like a hash, you can't get back the original. you can arrange it so that information about the structure of the program is lost forever but the results are the same. #2: intense obfuscation. not just extra bytecodes here and there or simplistic program rewriting - crazy baroque rube-goldberg mass obfuscation. no human will be able to grok what is happening in a program by looking at its constituent pieces, and the lossy nature will ensure that another program can't regrokablize it for you.

Yes its called Freenet

[emkman]

It does what you just described, and its slow as balls.

I saw this done in the 1970s

[caramuru]

There is nothing new with this technique. You just OR, AND, etc. bitmaps over a block of executable code such that a new block is obtained, run the block, and repeat as necessary. However, the maintenance burden produced by this technique is huge. Every time that you modify the code, you must modify all of the bitmaps used subsequently.

By that logic...

[Rufus88]

By that logic, indentation also lies. But we still use it, don't we?

Re:By that logic...

[highwindarea]

I write a lot of python code, Identation is always right

That's jsut because game designers get lazy...

[IBitOBear]

Most game exploits could be stopped outright if every-so-often the well-known memory maps of the active data sets were MD5(ed) and transmitted to the server. As the hit-points and unit-statuses (like the unkillable peon hack for Starcraft) are well-understood by the server the faults can be easily detected and removed.

Remember that most game hacks involve an exterior program that twiddles the in-game parameters after the session is up and running. If the changes were treated as a proper database update journal then things are easy. As the server and the client "play their journal" out at one another a "checksum" operation can be requested and the two memory maps had better match. The errors don't have to be "corrected" after all, they just need to be punished.

This isn't un-crackable but it is un-crackable in psud-realtime. The theoritical cracker would have to have, essentially, a second game engine running to maintian "the image that ough to be there" along with the engine of the real game. Then there would have to be a reconciler of some sort. At a minimum the machine doing the hack would have to be at least three time (yes, oversimplified math 8-) as powerful as the gamer's gaming experience. (That is, if the hacker wants to watch untextured wireframes "kill eachother" at 4 frames a second... he could probably devise a cheat. 8-)

Even so, as the server-side is applying the remote journal some very simple interger checks (c.f. if ((StartingHP + RepairHP) Turns) then EjectCheater(); if ((Pedometer / Turns) > MaxSpeed) then EjectCheater();

Online game hacks almost invariably exploit the kinds of design errors that come from hiring programmers who have only ever programmed games. Simple distributed data integrity checks (and a suspicous mind, and an understanding of why windows programs are never secure) could pretty much cut them down to nill.

(And before anybody starts narfing, I fully understand that, what with the distributed processing model the above math would need "fudge factors" and some adaptability. These too, are techinques that are well understood by people who work with distributed processing and data collection and synchronization tasks understand. Lossy environment and everything. This also wouldn't involve any real CUP hardship if designed correctly. Compared to the time to compute and render a frame, doing an MD5 over the domain of core data every few seconds isn't that hard to schedule. And it wouldn't necessarily have to be even as strong as an MD5. But gawd people, these games arn't even doing a data domain XOR... They don't get to cry over it when people do an exterior memory image patch hack. It's like leaving your car running with the doors open in Flatbush and then whining when it gets stolen. 8-)

Sounds like an Apple ][

[Anonymous Coward]

PSCP - sounds like a fancy name for what Sirius software tried on the Apple ][ to protect their version of the Defender game...

Self-modifying code. At first glance, the code looked like nothing... Execute a particular instruction, and everything came into focus...

So this is different how? Oh yeah, they have to execute TWO instructions now to get things to sync up...

I'm figuring that it ought to work just as well as the so-called copy protection on the Apple did *NOT*!

And given that this whole scheme was concocted by humans, another human ought to be able to bypass it w/o too much trouble... Wasn't it a famous calculus prof who said "what one fool can do, so can another..."

*yawn* Nothing to see here... move along.

Searching for i

[Majik Sznak]

/\

Not too bad. Still, I'm a fan of descriptive variable names myself (somethingIterator)

Re:Searching for i

[Majik Sznak]

I am stupid, hear me roar. What I meant to say in that first line:

/\<i\>

Re:do what i do / Another horror story

[ravepunk]

I used to work for a company that wrote compilers. The runtime p-code intepreter for a particular product was hand-coded assembly with pretty dense comments and the main developer was known for... uh, smoking on the job let's say... I remeber this one section of code where the comments just ended. 7 or 8 screens of assembly later was the following:

SOSXI: RET ; oops.

... then the comments started up again. It took me and some fellow developers about 3 months to figure out that code.

You want to obsfucate code better? Get high and write it.
:/ Ravepunk

Ever used regexp?

[fleacircus]

Ever try searching for "i" in a modern IDE?

[control-f]
[enable regexp matching]
\<i\>
[enter]

That wasn't so bad, was it?

Re:Ever used regexp?

[jcr]

The issue I alluded to isn't the ability to search for "i", it's that you might get dozens or hundreds of hits.

-jcr

Re:Ever used regexp?

[Anonymous Coward]

If you're trying to find something in a large body of code by searching for an *indexing variable* instead of something like function or object name, you've already lost!

My experiences with prefixes

[gidds]

The scope tag is probably more useful than the data type.

Very true. I've used a few different conventions, and IMO including the type in the variable name is both pointless and painful. In most cases, the type is fairly clear from the usage anyway, and often doesn't matter exactly. Indicating it exactly can take many characters, making code far less readable; and using just one or two isn't precise enough to be useful anyway. Plus type also gets changed quite often, with all the potential for error that gives.

However, scope is another thing; I've found a single character scope prefix to be very useful. It tells you where to find the variable's definition, so you know where to look for anything else about it. Changing scope is extremely rare, and since similarly-scoped variables are declared together, mistakes should be obvious.

It depends on the language, of course. In C, it might be useful to distinguish some or all of: formal parameters, automatic variables, local statics, module (file) level variables, global ones, preprocessor constants, enumeration constants, and structure members. But in Java, things tend to be more obvious; functions tend to be small enough that their parameters don't get lost, local variables get declared close to where they're used, and it's usually clear what other names refer to. The only prefix I've found useful is an underscore before instance variables. (And arguably, using this. is clearer anyway.)

And it also depends on the size and organisation of a project. Small apps might find little benefit from a convention, whereas huge projects can be made much more manageable by indicating where to look for things.

Code readability is an art, really, and you can't force people to write good code with simple rules. Just as using single-character names for all variables obscures their meaning and makes code incomprehensible, so does using excessively long variable names obscure the meaning of the code they're in, and makes it incomprehensible. The ideal lies somewhere in between.

Article shockingly wrong

[GnrcMan]

This article seems to be arguing that MS's security problems are because of .NET/the CLR. That's just wrong.

FACT: Microsoft's operating systems, internet explorer, and office are NOT writen in C# at all. The .net runtime doesn't even ship with the OS by default!

FACT: Most of the security vulnerabilities being uncovered are due to buffer overflows. Writing software in something like C# actually reduces the chance of a buffer overflow. Strings in C and C++ are notorious culprits (okay, so the programmer is the real culprit) in buffer overflows. Strings are more dynamic in C#, eliminating many security problems. That doesn't make C# a panacea, but it certainly helps matters.

FACT: That article shows that a little knowledge is a dangerous thing. It really should have been fact checked by someone more technically adept.

Re:Article shockingly wrong

[Power Luser]

Cringely rarely makes sense about anything. Almost every Cringely article I've read in the last few years contains ridiculous assertions, glaring omissions or blindingly obvious factual errors.

I pity the people who take Cringely articles seriously and the fact that they get semi-regular attention on /. is more than a little worrying.

Re:Article shockingly wrong

[GnrcMan]

Yeah, I hear you. I didn't even mention the problems with premise of reverse engineering causing security holes. If that were true, where does that leave open source software, where you get to see the actual source code? I seem to remember hearing him expound on the virtues of open source in some article or other. But in this one, he forgets all that, and goes after MS with what can, at best, be considered a red herring.

His article seems to be primarily about byte code obfuscators. An interesting topic, but he muddles it completely with factual errors. Hmm... enough ranting, methinks. It's probably not worth it.

Re:Article shockingly wrong

[Anonymous Coward]

FACT: 83.64% of statements the begin with "FACT:" are made up on the spot.

If you want people to believe you, post links to references or well-reasoned proof, not all-caps assertions of factuality.

Re:Article shockingly wrong

[GnrcMan]

I simply didn't think it was worth my time to exaustively document these facts, seeing as it is Slashdot, and all. This is why I rarely post here any more. I always get drawn in to this bullshit.

But...since you asked...here you go, asshole (that was an ad homonym attack, BTW):

Fact #1: Since the .NET framework doesn't ship by default with IE, Office, or most versions of windows, up to and including Windows XP, it would be imposible for them to be responsible for security holes in the above mentioned software. If you install the .NET framework after the fact, well, then we can talk.

Fact #2: Probably poorly worded. Strings are a huge culprit, but buffer overflows (of which string overflows are a subset) are what are really at issue. C# makes buffer overflows in general less likely, because of both the dynamic nature of most buffers in C# as well as the strong checking that occurs. http://www.microsoft.com/technet/treeview/default. asp?url=/technet/security/default.asp and http://www.ntbugtraq.com/default.asp?pid=36&sid=1& A1=ind0402&L=ntbugtraq#13 both illustrate the rampant buffer overflow problem. Explaining exactly how C# helps reduce the likelyhood of a buffer overflow will take too long. I don't feel like typing that much, but rest assured, I'm very much knowledgable in the subject.

Fact #3: Okay, so this is an opinion...but it borders on a fact. A little knowledge *is* a dangerous thing. This article illustrates that nicely.

So fuck you very much, anonymous troll.
Do you have any real arguments against what I said? Or have you just succeeded in what you intended, trolling me?

Casey

but wait

[Anonymous Coward]

can you freeze a state on a computer
and if you can it wont morph
furthur more why can't you reverse engineer the code morpher itself.

Don't see a real benefit

[TheLink]

he's talking about morphing code for .Net and Java stuff to prevent reverse engineering.

That's usually pointless because the cool and interesting parts of a Java program aren't usually in the small little nooks and crannies, they're out there in full sight, at the user level or architectural level.

It's not like the case of proprietary software, drivers and firmware talking to proprietary hardware, where what this bunch of bits do becomes very interesting to potential competitors.

The only people who'd be interested in the nooks and crannies of a typical Java program (what this bit does etc) would be the programmer supposed to fix/improve the program. Not a competitor.

Please! No more Cringely!

[Power Luser]

Why does the moron get space on /. at all? Surely people can see the glaring errors, the ridiculous assertions and the "I'm at the center of the tech universe, so if I happen to have a half-baked idea about something then it must be so!" attitude that Cringely articles reek of.

I feel dirty after reading them. God help the world if Enderle and Cringely ever start working together.

Funny? Redundant!

[DarkHelmet]

http://polls.slashdot.org/comments.pl?sid=95819&ci d=8208868

Give credit where credit is due. Granted, for all I know the one I linked is ripped too, but still...

Time to filter out the new redundant / trolls, relevant or not.

Re:Funny? Redundant!

[dnahelix]

talk about redundant? "friendster"? Maybe you should call it "looster"

YES YES YES!!!

[severoon]

I TOTALLY AGREE--100%!!! If you use Hungarian notation correctly (if you visit this link do a page search for "hung" to find the appropriate section), not only do you get the many benefits of it, you can never be fired.

(Don't just stick to that one page, go to the main page for more information on writing code "properly".)

sev

crongley's basis of arguement

[aderusha]

it seems the the entire foundation of his arguement is that having access to the source leads to security problems. this coming from the same guy who generally likes linux and promotes it as an enterprise-ready secure platform. i'm not sure i understand what the hell he's talking about anymore...

Re: damn stupid Slashdot whitespace filter

[some guy I know]

Surround your code with and you shouldn't have a problem:

line
indented line
a more indented line

Re:do what i do [dangerously offtopic]

[Ralp]

* (an asterisk) is also a Vim shortcut for "search for word under cursor". Or, # to search backwards.
I never knew \ meant end of current word, thank you. :)

Re: match word end in vim

[some guy I know]

The parent of your post did not preview before clicking the "submit" button.

Beginning of word is "\<".
End of word is "\>".
AFAICR, this also works in vanilla vi.

Note that "word" means different things in vim, depending on the language mode.
For example, "\<hi\>" matches "(hi-mom)" in C/C++/etc. mode, but not in LISP mode.

Re: Preview button

[some guy I know]

Please use the Preview button before submitting your post.
Your example is misleading because you used "<" instead of "&lt;" to mean "<".
This caused your example to display incorrectly.
(Note that "Plain Old Text" isn't.)
Alternatively, you can surround your example text with "<ecode></ecode>":

I can search for the variable "i" by typing:

/\<i\>

Re: indentation vs Hungarian Notation

[some guy I know]

indentation also lies.

Most incorrect indentation can be fixed by running the source through a pretty-printer (such as indent or cindent).
I don't know of any pretty-printer that can clean up incorrect Hungarian Notation.

Re: Generated source code

[some guy I know]

What does this mean if my source comes from a code generator?

Then the real "source code" is the code that was input to the code generator.
For example, for lex/flex and yacc/bison, the "real" source code is in the .l and .y files, not the generated .c and .h files.

Re: misspelled menus

[some guy I know]

I once saw a sign in a restaurant offering a "bowel of chicken soup".
I was not interested in soup made from the bowels of chickens, and so I went elsewhere.

Actively changing code.. hmmm

[rofthorax]

Until they can encrypt and obfuscate operations on a CPU level, they will not be able to protect code from prying eyes or from backwards engineering.. But their aim is not to keep the hackers out, the aim is to assure potential buyers of their technology so that they can make money.. Who cares (they think) if it actually works or not..

The rest is just FUD to cover up this ploy..

Here! I know exactly what You're looking for.

[Arioch_BDV]

l-Zip - isn't it the archiver You've been looking for? :-D