• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is obfuscated code can be decompiled easily?

 
Leonardo Carreira
Ranch Hand
Posts: 494
Eclipse IDE Java Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I'm highly curious about the decompiling Java byte code. Is it possible to decompile the obfuscated code, which have been obfuscated by proguard?
I have a plan to distribute my Swing application, i want to make my application can't be reversed or hacked.
What's the best way to achieve this?

Thanks for sharing.

Leonardo
 
Tim Cooke
Sheriff
Posts: 3297
153
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can decompile byte code using tools such as, the now dead, JAD project. However any time I have tried to do it just out of interest the resulting Java code is not pretty. At all.

If you are keen on using Java for your application then a combination of a licence declaration in your source files and some obfuscation would probably suffice. While it would be possible to decompile your code, it would be extremely difficult and unpleasant. Enough so that apart from the seriously die hard, most would not bother to make the effort.

A stronger method to prevent reverse engineering or hacking would be to choose to write your application in a compiled language rather than an interpreted language.
 
Leonardo Carreira
Ranch Hand
Posts: 494
Eclipse IDE Java Postgres Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@Tim

So, does it mean that no matter how much effort to obfuscate our byte code, the byte code could still be reversed engineered?
Sorry, could you please explain in detail about license declaration that you mentioned?


A stronger method to prevent reverse engineering or hacking would be to choose to write your application in a compiled language rather than an interpreted language.


So, this means that i will have to choose other programming language, doesn't it?

If i embed some codes for crucial things in JNI such as database access or GUI design, and the other codes are only obfuscated, will it help me much to protect my code against reverse engineering?

 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Leonardo Carreira wrote:So, this means that i will have to choose other programming language, doesn't it?

I wouldn't say that. But you need to be aware that the code can be decompiled, and the algorithms behind it can be discovered. If the classes have been obfuscated, this is a lot harder than it would be without obfuscaton. But still, it can be done by someone who is sufficiently motivated. So if parts of the algorithm are a trade secret, then it simply can not be part of the application. But that's true for native code as well. Running that code on the server, and having the client connect to it would be an alternative is such cases.

But you would have to ask yourself if it's worth it - who would go to the length of trying to make sense of obfuscated code, and what would the damage be if they did. It's a engineering tradeoff to be considered like any other.
 
Tim Cooke
Sheriff
Posts: 3297
153
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Technically yes. Your class files are essentially just text (not necessarily readable text) containing instructions for the JVM. It's the JVM's job to interpret that into machine language. So given that we know the spec of the bytecode in relation to the Java code, which we do, then it will always be possible to reverse the compilation process and get back to Java code.

Now, what the obfuscation tools do is to jig around with the Java code and make it as unreadable as possible while maintaining the functionality. it'll do things like turn your meaningful variable names into meaningless, essentially random, names. Remove all indentation and whitespace. Replace looping structures with some other structure that looks nothing like a loop but still is one. You get the idea. The purpose being that even if you were to decompile the bytecode back into Java perfectly (unlikely) then it still would make little sense. It would force the hacker to then try and un-obfuscate the Java code, adding another level of complexity to the task.

What I meant about the licence thing was to just add a Copyright declaration to the top of all your source files. While not adding any technical security it does add some legal security. So when your system gets decompiled and resold by some unscrupulous person you can take them to court for Copyright theft.

I would imagine it would be harder to decompile an application created with a compiled language as you are working with binary files containing machine code. It's probably not impossible but just much more difficult.

The decision of how far you take this should depend on just how much at risk you think your application is of being hacked. For example, if your application solves the remaining 6 Millenium Prize Problems then I would imagine it would be at significant risk of people wanting to reverse engineer it to obtain the formula, and thus go claim the $6m prize. On the other hand, if your application tracks parts through a warehouse then the risk of hacking is quite low so the extra effort to lock it down probably wouldn't be worth it.

With regards to using JNI. You would be adding an enormous amount of complexity to your system making it very difficult to develop and maintain. I can not advise you do that.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!