What can be done to secure JAR files besides obfuscation?

Question

I'm concerned about the security of Java executables. They offer little protection against decompilation. With tools like Java Decompiler even a kid can decompile the class files to get the original code.

Apart from code obfuscation what can be done to protect a class file? Is the Encrypted Class Loader still a myth?

Keble

Write Open Source Software, and you wont have that problem. :-D – Elan

possible duplicate of (Why) should I use obfuscation? – Massingill

Write code worth paying for and those that will pay for it will pay, those that wouldn't pay anyway are not a concern. – Massingill

Answer 1

In a previous company we had such questions, mainly driven by management paranoia.

First of all, you have to understand that absolute security is only a myth: As long as your program is run on untrusted hardware, it can be decompiled, no matter what language you use. The only thing you can change is the cost of an attacker to understand your software/algorithm/data.

Concerning obfuscation: it can be considered a first level of protection, as it makes the Java code totally unreadable. Good obfuscators like ProGuard use forbidden characters in variables/methods names, preventing execution of decompiled code. Now, one can consider it a good enough security measure, as decompiling code is not as simple as running Jad or other decompilers and having perfectly working Java code. However, it is possible to understand most of the algorithms exposed in such code (as readable code is very different from compilable code).

Additional security measures include:

• Running sensitive code on a server by using some kind of web-service to send results and grab results (using REST/SOAP/YouNameIt)
• Loading sensitive code from a remote server using HTTPS and (maybe) additional security layers.

From those two security measures, I would honestly choose the first. Indeed, the second can be subverted by typical HTTPS attacks (man in the middle, logging proxies, and so on, ...), and has the major inconvenience of putting the code on untrusted hardware, which makes it possibly borrowable from there.

Duna

We too had such a requirement by paranoid managment. The proposed solution is to go full web app instead of desktop. A thin client can be made from java if absolutely required but I personally spend the effort into a web 2.0 interface. – Armond

@Armond In our case, it was an advanced trading application, which required huge amounts of displays, totally unthinkable (from my Java/Swing developper history at least) using even the best HTML5 sub-technologies (I mean, even SVG at its best won't do the job, without even thinking about the browser ecosystem hell) – Duna

Answer 2

Basically, there are four things you can do with your bytecode to protect it against Java decompilers:

• obfuscation
• software encryption
• hardware encryption
• native compilation

all covered in my article Protect Your Java Code - Through Obfuscators And Beyond

Zoom

Answer 3

You can write all your code with in native. The reverse engineering can be done anyway. But is harder.

Ok, this is not a strictly java solution.

As nfechner said in a comment write open source application.

Falchion