File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Code obfuscation

 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I decompiled my own class files recently to find that the decompile was quite close to the original code i had written. Even after obfuscation by retro guard i find that the code decompiles great with the only difference being that the variable names are some what obscure. Is there an obfuscator out there that renames and rearranges the code enough to confuse the decompilers without sacrificing performance !? I have also tried jobfuscate. Please voice out your opinions on this and name a few obfuscators that you know of.
 
Scott Johnson
Ranch Hand
Posts: 518
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Traditional obfuscators only go so far. They make the code somewhat harder to understand, but the logic is still there and with some domain knowledge the code can be understood fairly easily.

One option may be to use gcj which can compile your classes to machine code.

Or you could encrypt all of your classes and write a custom ClassLoader to decrypt them at run time.

None of these are foolproof, but they may help deter more casual snoopers.
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I gave encrypting the class files a thought but that wont be fool proof like you mentioned. This is the first time i am hearing about gcj. I ll give gcj a shot tonight and look at how well the decompiler can reverse engineer it. Thanks
 
Tony Morris
Ranch Hand
Posts: 1608
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The vmspec. is easy to read. All one need to do is become capable of emulation of a JVM through spatial experiment - a trivial task. The most extreme obfuscation only requires more spatial ability. It is futile at best and self-referential falsification at worst.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I find that most code is obfuscated by the programmer to a degree no software tool could match purely by that programmer's ideas of how to be clever (and/or his ignorance and/or laziness).
 
Jeremy Botha
Ranch Hand
Posts: 125
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would have to agree with Jeroen.

A friend of mine and I came up with the term 'Forensic Debugging' on one particularly well-obfuscated project we had the misluck of being assigned.

Some people should not be allowed near editors.

Jeremy
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So would you say that the best way to write code would be to obfuscate it when you write it and then run it through an obfuscator to make life hell for the guy thats trying to read it ? Sounds good if we cant prevent the class from being decompiled to begin with.
 
Jeremy Botha
Ranch Hand
Posts: 125
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Security through obscurity always fails.

I always advocate writing clean code, and then making sure that all IP claims and copyright terms are specified in the license. There is no way to stop a determined enough person from reverse engineering your code. If, however, your contract specifies that to do so is grounds for legal action, you are safe. And you make the life of maintenance developers that much more pleasant.

J
 
Tony Morris
Ranch Hand
Posts: 1608
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by John Meyers:
Sounds good if we cant prevent the class from being decompiled to begin with.

It is possible (though not necessarily desirable) to create a theorem prover that proves that it is impossible to "prevent the class from being decompiled to begin with" - so what now?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic