Morphing Code to Prevent Reverse Engineering? 507
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."
Are folks really using obfuscation for Java? (Score:5, Insightful)
- 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?
Reverse engineering is not the problem (Score:5, Insightful)
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.
Won't work (Score:4, Insightful)
zzzzzzz (Score:3, Insightful)
Not enough eyes to make the bugs shallow... (Score:5, Insightful)
With Open Source, *everyone* gets to look at the code, so there any many eyes, and the bugs get shallower.
It's ironic (Score:5, Insightful)
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?
Isn't this just self-modifying code? (Score:5, Insightful)
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 need to tap the Analog Out... (Score:5, Insightful)
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.
Wow (Score:5, Insightful)
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 (Score:5, Insightful)
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 not the problem (Score:2, Insightful)
"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.
virus writers dream (Score:3, Insightful)
performance (Score:5, Insightful)
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:Won't work (Score:5, Insightful)
That IS the point, I'm sure you realize.
Security by obscurity (Score:1, Insightful)
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.
Great. (Score:5, Insightful)
Re:Reverse engineering is not the problem (Score:5, Insightful)
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.
I can see a market for this. (Score:5, Insightful)
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:Won't work (Score:5, Insightful)
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.
The software arms race. (Score:5, Insightful)
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.
Disagreements with the Premise (Score:5, Insightful)
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.
Just one question (Score:5, Insightful)
Two completely different issues (Score:5, Insightful)
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.
Re:Reverse engineering is not the problem (Score:5, Insightful)
Re:Are folks really using obfuscation for Java? (Score:4, Insightful)
Re:Not enough eyes to make the bugs shallow... (Score:5, Insightful)
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 [joelonsoftware.com].
Re:Won't work (Score:3, Insightful)
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:Isn't this just self-modifying code? (Score:5, Insightful)
Have these people learned nothing?
Sounds like a way to make things more unstable (Score:5, Insightful)
I'm sure this would make QA testing a nightmare.
Re:Top 12 Things A Klingon Programmer Would Say (Score:2, Insightful)
man i feel like a big dork.
Re:Isn't this just self-modifying code? (Score:5, Insightful)
If so, this raises a couple of issues:
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:Just one question (Score:2, Insightful)
"Is this a bug in the code morphing program or in the original application?" - wow, testing will get even funnier
Yawn (Score:4, Insightful)
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.
their logic is flawed. (Score:1, Insightful)
Yes (Score:5, Insightful)
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 [retrologic.com] fits saemlessly enough into the build process that adding a simple level of protection to the code is usually simple and transparent.
Re:Won't work (Score:3, Insightful)
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:Are folks really using obfuscation for Java? (Score:5, Insightful)
Or you can do like many C++/C projects do and simply forget to free the memory (i.e. memory leaks).
Greetings,
Re:Yes (Score:5, Insightful)
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 [pensamos.com]!
Re:Won't work (Score:3, Insightful)
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:Resource Waste (Score:3, Insightful)
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.
Re:Isn't this just self-modifying code? (Score:3, Insightful)
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:do what i do (Score:3, Insightful)
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:Are folks really using obfuscation for Java? (Score:5, Insightful)
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:do what i do (Score:5, Insightful)
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:Won't work (Score:2, Insightful)
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:do what i do (Score:5, Insightful)
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.
Just what we need: more bureaucracy (Score:1, Insightful)
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.
Re:do what i do (Score:5, Insightful)
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:Hungarian? Forget about it. Use Finnish. (Score:5, Insightful)
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.
Crap logic (Score:3, Insightful)
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.
Re:Are folks really using obfuscation for Java? (Score:5, Insightful)
If a CPU can understand your code, so can a human. The solution to this problem are licenses, not obfuscators.
Re:Reverse engineering is not the problem (Score:3, Insightful)
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:do what i do (Score:5, Insightful)
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.
Oooo... Self Modifying Code, version 2. (Score:4, Insightful)
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:do what i do (Score:4, Insightful)
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.
Never the same code twice? Yikes... (Score:5, Insightful)
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).
Code like this will be slower and more fragile (Score:5, Insightful)
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:Are folks really using obfuscation for Java? (Score:5, Insightful)
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.
Comment removed (Score:4, Insightful)
Re:do what i do (Score:5, Insightful)
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 (Score:2, Insightful)
I call bullshit (Score:3, Insightful)
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:Why go through all the trouble? (Score:2, Insightful)
Huh? (Score:4, Insightful)
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.
Re:Reverse engineering is not the problem (Score:2, Insightful)
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.
Please! No more Cringely! (Score:2, Insightful)
I feel dirty after reading them. God help the world if Enderle and Cringely ever start working together.