Igor, On Jun 4, 2012, at 1:55 AM, Igor Stasenko wrote:
> On 3 June 2012 18:01, Phil (list) <[email protected]> wrote: >> On Jun 3, 2012, at 11:31 AM, Marcus Denker wrote: >> >>> >>> How do people do it with Java? Java .jar files are as easy to decompile as >>> Smalltalk bytecode... >>> >> >> ProGuard (http://proguard.sourceforge.net/) is a popular method. In its >> obfuscation phase it will rename most class and method names (i.e. anything >> that doesn't need to be externally visible) to meaningless names so >> MyClass.MyMethod becomes something like a.a. It can also generate a mapping >> file so that when bug reports / crashes occur, the developer can map the >> gibberish names back to the original names. Before the obfuscation phase, >> it has optimization and shrinking phases to eliminate code that doesn't need >> to be included for release (debugging code etc.) >> > > so, what prevents others from writing de-obfuscating tool and then > read nice sources? De-obfuscating what? The reverse mapping resides with the developer. So a determined hacker can see that class 'a' has methods 'a', 'b', 'c' and has instance vars 'a', 'b', 'c', 'd', and 'e'. (Literally, that's what the names get turned into) Granted, there are some clues left behind (a few classes/methods that need to be externally referenced and classes/methods that your code calls out to), but *your* code has essentially been turned into high-level undocumented assembly code that won't be that much more obvious than what can be produced by a good disassembler. One weakness of ProGuard obfuscation is that it is fairly static in its mapping (though even if they randomized it a bit, it probably wouldn't be that hard to do a structure-diff of the code to figure out how the latest release mapped to an older release using a tool like Moose)... i.e. you get a bit of naming drift as the number of classes and methods change, but the order of mapping is static. > > no matter what you do, as long as you distribute executable code to > masses, it can be reverse-engineered. You can only make it harder. > But there is good way to prevent this from happening: stop selling > binary files, > start selling real support for your software, ship updates regularly, > make customers happy. > Then you will be immune from any piracy, because nobody will think > pirating your software, > because it is useless without your support. > I agree that it does nothing to prevent reverse-engineering by someone who's dedicated and getting support provides significant value. The situation is no different with with languages that emit true binary code: if it can be run on the users machine, it can be cracked/reverse-engineered. However, it does make the effort quite a bit more tedious without intention revealing names. I've decompiled several of my own obfuscated Java apps and come to the conclusion that if I were attempting to reverse-engineer my own stuff without the knowledge of why things ended up as they did, I'd have a much easier time just reimplementing it as knowing what I did doesn't help me at all with the 'why'. Sure, if one had a highly valued application a group of like-minded individuals could figure it out in short order... but ah, what a problem to have :-) Anyway, I was just trying to address the question of how Java apps address the issue. > > > -- > Best regards, > Igor Stasenko. > Thanks, Phil
