How to protect Java codes against decompiler?

Question

As we know , there are a lot of java decompiler tools which can convert .class to .java file.

Therefore,we need to protect our .java files against decompiler. I know this is a big topic,and maybe there is no ending.

Usually, there are two ways : obfuscator and customized classloader.

Is there any mature solution or open source framework, which combined those two ways ?

Another aspect is related with exe4j, which package jars to exe file,seems like it can protect java codes , because what we can see is exe file instead of jars or class files. But indeed, when it runs, it decompose all jars files into temporary directories, that means it is easy to get class files for decompiler. So any considerations for protecting java codes from the aspect of exe4j ?

Thanks for your comments and suggests.

Updating

Thanks everyone for your suggest or experience share. That is helpful to me. To make a conclusion, I will give up any obfuscator or customized classloader with encryption things. Because finally Java codes can be disclosed before clever hackers.

I will remove some core codes during compiler time using tricks like "#ifdef" in C language. In Java, static and final boolean class variable can be used to do the same job. Then the compilered class file will not contain need-protected java codes.

Solution 1

You can't protect the class files from a decompiler and from malicious users. However the output of the decompiler may not be valid java.

The best method is to document your API (assuming this is available for your customers to use) and application very very well. And have your support personnel be able to resolve API and application issues. Then your customers will have no reason to want to use a decompiler to explore why things are not working correctly.

Solution 2

1. You can use an obfuscator, like ProGard or Ygard, but it is not too complex to decrypt strings and rename classes, fields and methods.
2. You can encrypt your classes with a private key, and use a custom classloader to decrypt your classes with a public key before loading into memory, but it is not too complex to modify the classloader to save onto a disc all the classes loaded.
3. You can try crash decompilers. JAD is one of the best decompilers but if you add corrupted entries in the constant pools, all products powered by JAD crash. However, some decompilers are still working.

The only way to protect your software, is to deploy it in a SaaS/PaaS.

But keep one's head: most people use a decompiler because they have a technical problem and the documentation is poor or nonexistent. Write a good documentation and use a solid EULA is the better solution.

Solution 3

Software as a Service.

Solution 4

The only way that's particularly effective is to offer your program as a web service of some kind, so that the compiled code is never even available on an end-user machine.

The next most effective solution, which is one that is widely used in practice, is to make your program so terrible that no-one wants to use it or spend the time reverse engineering it in the first place. I suspect that when this happens it is typically accidental, however.

Solution 5

My advice is that if you are really serious about this, you should only release the demo software to people who have signed a legally binding non-disclosure agreement. And be prepared to go to court if they breach the agreement.

By all means, obfuscate your demo application, etc as well, but don't imagine that this will stop a determined hacker from discovering the "secret sauce" in your application. It is not possible to prevent this, in theory and in practice. Piracy is inevitable if you use the pay-for-license model of monetizing your software.

(Actually, it is theoretically possible, but only with a totally secured platform like TPM. And that ain't an option for you. Trust me.)

View more solutions

Comments

[KCL]

Indeed. SaaS seems to be really popular these days. Some have even envisioned that most applications will be provided as Saas in a few years. And with tools like GWT, Vaadin or ICE Faces one can make really nice user interfaces for their applications.

[Forrest]

We just want to provide free demo version for anyone to try. But afraid that hacker can decompiler and get java codes. Therefore, first step is to remove some core data or core codes using this trick:stackoverflow.com/questions/1813853/ifdef-ifndef-in-ja‌​va Second step will consider some anti-decompiler methods. Well I will give up any anti-decompiler solution after hearing you said"You can't protect the class files from a decompiler and from malicious users."

[Kosi2801]

"You can't protect the class files from a decompiler and from malicious users." :) It's not possible to protect your classfiles in a way that it's not interpretable by a decompiler. If it were, it would also be protected from running in the Java-VM and therefore useless, as you cannot distinguish interpretation from decompiling (from the standpoint of the classfile).

[Forrest]

For the core logic, C++ can be used to generate dll file, then Java wraps it with JNIWrapper.

[Dan Dyer]

Doesn't work (see javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.htm‌​l). The classes have to be decrypted to run them, so you can just grab the unencrypted versions at that point.