How to Lock Compiled Java Classes to Prevent Decompilation

How to lock compiled Java classes to prevent decompilation?

Some of the more advanced Java bytecode obfuscators do much more than just class name mangling. Zelix KlassMaster, for example, can also scramble your code flow in a way that makes it really hard to follow and works as an excellent code optimizer...

Also many of the obfuscators are also able to scramble your string constants and remove unused code.

Another possible solution (not necessarily excluding the obfuscation) is to use encrypted JAR files and a custom classloader that does the decryption (preferably using native runtime library).

Third (and possibly offering the strongest protection) is to use native ahead of time compilers like GCC or Excelsior JET, for example, that compile your Java code directly to a platform specific native binary.

In any case You've got to remember that as the saying goes in Estonian "Locks are for animals". Meaning that every bit of code is available (loaded into memory) during the runtime and given enough skill, determination and motivation, people can and will decompile, unscramble and hack your code... Your job is simply to make the process as uncomfortable as you can and still keep the thing working...

How to protect compiled Java classes?

First if you're targeting "only" the Windows market there's a very easy to prevent the ".class to .java" decompilation: use a tool like Excelsior Jet that will transform the .jar in an .exe.

This is foolproof: it is impossible to get the .java file back if you use Excelsior Jet (so long for all the people saying "it's impossible to prevent decompilation of a .class file"). Sure, an attacker could launch SoftIce and try to trace your .exe but that will prove a bit trickier than using JAD to decompile the .class to a .java and it certainly won't allow to find the .java file back.

Now maybe you're targetting OS X and Linux too or you don't have $$$ to shell off for Excelsior Jet.

I'm writing a commercial software written in Java. That software only makes sense if there's an Internet connection. Hence we "protect" our software, amongst other, by having part of the computation happening on the server side: we have several .class that won't work unless they're generated from the server side and we send them down the wire (and what is sent on the wire is always different: we're generating unique, one-off .class files on the server side).

This requires an Internet connection but if the user doesn't like how our software works then he's free to buy one our competitor's inferior product ;)

Decompiling will not do much good: you actively need to crack the software (ie reproduce what is happening on the server side) or you won't be able to use it.

We use our own "string obfuscation" before we use Proguard. We also do source code instrumentation (we could have done bytecode instrumenation as well) where we remove lots of things from the code (like the "assert" that we comment out) and introduce some random "code flow obfuscation" [the software can take different paths yet obtain the same result, this is something that really makes the software hard to trace]).

Then we use Proguard (which is free) to flatten all our OO hierarchy and to obfuscate the already-code-flow-and-string-obfuscated code.

So our flow is:

• string obfuscation
• random code flow obfuscation
• Proguard
• final .jar that depends on .class that are (differently) dynamically generated on the server side.

In addition to that we release very regular (and automated) update which always make sure to modify a bit our client/server protection scheme (so that with each release an hypotethical attacker has to start mostly from scratch).

Of course it's easier to throw the towel in and to think: "there's nothing I can do to make an attacker's life harder because JAD can find back the .java file anyway" (which is more than very debatable and blatantly wrong in the case where you use a .class to .exe converter to protect your .class from decompiling).

How to protect Java codes against decompiler?

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.

How to protect a Jar file from being decompiled?

As Java preserves most of the "metadata" during compilation (which allows dynamic loading and reflection), it is a straight forward to decompile (not only disassemble) the compiled class files. That's why the recovered code is very similar to the original.

While not perfect, your probably only option is to use an obfuscator, such as ProGuard.

If all the bytecode which compiled from java sources can be decompiled to java sources?

I wonder if all the bytecode which comes from java (not other JVM language) can be decompiled to java sources again?

The answer is No.

Decompilers aren't guaranteed to work for all Java bytecodes:

• A good obfuscator will deliberately rearrange the bytecodes in such a way that the common decompilers won't produce readable source code ... and probably won't produce valid source code.

• Many decompilers out there have problems dealing with newer Java constructs.

• Many decompilers have problems with bytecodes compiled from "complicated" source code.

• Even if they generate compilable code, there is no guarantee that the code will be correct.

The bottom line is that a decompiler is only as good as the intelligence and diligence of its author can make it. I've never heard of a perfect one.

Java - Are there any ways to obfuscate/hide strings to prevent against decompilation?

You can put them in a resource file and encrypt it using AES (for example). Then on the application initialization extract the data.

---

Related Topics