Slashdot Mirror
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."
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?
The Army reading list
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.
Don't blame me; I'm never given mod points.
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..
*shrug* You still have controll over the computer. Just load something of your own mnaking before your OS loads the obfusicator. Interrupt 13, anyone?
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.
libertarianswag.com
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?
This looks vaguely like self-modifying code, like back in the old days of copy protection.
.net runtime engine (or maybe it's loaded and spews bytecode to the runtime), then it can be removed...or the output intercepted. .
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
What am I not getting here?
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.
[
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.
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.
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.
Neutrons are slippery little rascals, they can fool you. They can bounce and show up around corners you don't expect.
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.
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.
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.
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.
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.
Does my bum look big in this?
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:
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.
If you blog it...
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?
Find a job you like and you will never work a day in your life.
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.
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.
"He's lost in a 'floyd hole"
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.
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.
That's "Mr. Soulless Automaton" to you, Bub.
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.
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.
-----
Free P2P Backup, Windows & Linux
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.
John
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.
"The legitimate powers of government extend only to such acts as are injurious to others." Thomas Jefferson.
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#.
>|<*:=
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.
Programming can be fun again. Film at 11.
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.
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!
--
"I'm too old to use Emacs." -- Rod MacDonald
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.
Programming can be fun again. Film at 11.
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.
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.
Eloi, Eloi, lema sabachtani?
www.fogbound.net
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...
help me i've cloned myself and can't remember which one I am
"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.
--- Hindsight is 20/20, but walking backwards is not the answer.
...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).
"How to Do Nothing," kids activities, back in print!
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?
To a Lisp hacker, XML is S-expressions in drag.
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
The only title of honor that a tyrant can grant is "Enemy of the State."
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".
Programming can be fun again. Film at 11.
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;
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.
Ceci n'est pas une signature
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).
"Forget the engineers." -Carly Fiorina, briber of MIT Technology Review.
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.
.NET, yet .NET as it stands today is very vulnerable to security lapses
.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.
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
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
Watch out everybody, the black helicopters are circling overhead.
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.