How to lock compiled Java Classes to prevent decompilation

Question

I know this must be very well discussed topic on Internet but I could not come to any conclusion after referring them.

Many people do suggest obfuscator but they just do rename classes / methods / fields with tough to remember character sequences but what about sensitive constant values ?

For example, you have developed the encryption / decryption component based on Password Based encryption technique. Now in this case any average Java person can use JAD (http://www.kpdus.com/jad.html) to decompile the class file and easily retrieve the password value (defined as constant) as well as SALT and in turn can decrypt the data by writing small independent program !

Or you suggest to build such sensitive components in Native code (e.g. VC++) and call them via JNI.

Answer 1

No matter what you do, it can be 'decompiled'. Heck, you can just disassemble it. Or look at a memory dump to find your constants. You see, the computer needs to know them, so your code will need to too.

What to do about this?

Try not to ship the key as a hardcoded constant in your code: Keep it as a per-user setting. Make the user responsible for looking after that key.

Answer 2

Hi Daren,

Ok let me be bit specific. What if I have distributed the encrypted license file with Application to client. The person at client side can decrypt it, change the conditions and encrypt back ! There must be some way to achieve this.

Hope you got my point.

Answer 3

@jatanp, disclaimer: I am not a security expert.

This sounds like a bad Idea: You are letting someone encrypt stuff with a 'hidden' key that you give him. I don't think this can be made secure.

Maybe asymmetrical keys could work:

• deploy encrypted license with public key to decrypt
• let customer create a new license and send it to you for encryption
• send new license back to client.

I'm not sure, but I believe the client can actually encrypt the license key with the public key you gave him. You can then decrypt it with your private key and re-encrypt as well.

You could keep a separate public/private key pair per customer to make sure you actually are getting stuff from the right customer - now you are responsible for the keys...

Answer 4

@jatanp: or better yet, they can decompile, remove the licensing code, and recompile. With Java, I don't really thing there is a proper, hack-proof solution to this problem. Not even an evil little dongle could prevent this with Java.

My own biz managers worry about this, and I think too much. But then again, we sell our application into large corporates who tend to abide by licensing conditions--generally a safe environment thanks to the bean counters and lawyers. The act of decompiling itself can be illegal if your license is written correctly.

So, I have to ask, do you really need hardened protection like you are seeking for your application? What does your customer base look like? (Corporates? Or the teenage gamer masses, where this would be more of an issue?)

Answer 5

As long as they have access to both the encrypted data and the software that decrypts it, there is basically no way you can make this completely secure. Ways this has been solved before is to use some form of external black box to handle encryption/decryption, like dongles, remote authentication servers, etc. But even then, given that the user has full access to their own system, this only makes things difficult, not impossible -unless you can tie your product directly to the functionality stored in the "black box", as, say, online gaming servers.

Answer 6

Hi Stu,

You are right. Such things can be protected by law and lawyers. Currently we are planning to develop some kind of business app mostly targeted to mid-scale / large-scale corporations.

Answer 7

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 jars 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 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...

Answer 8

Take a look at this JavaWorld article by Vladimir Roubtsov. It explains why encryption of class files is mostly pointless.

Answer 9

If you're looking for a licensing solution, you can check out truelicense api. It's based on use of asymmetrical keys. However, it doesn't mean your application cannot be cracked. Every application can be cracked with enough effort. What really important is, as Stu answered, figuring out how strong protection you need.

Answer 10

I don't think that exists any efective offline antipiracy method. The videogame industry has tried to found that many times and they programs has allways been cracked. The only solution is the program must be runned online connected with your servers, so that you can verify the lincense key, and that there is only one active conexion by lincense at a time. This is how World of Warcraft or Diablo works.

Said that, i don't believe that mid/large corporations use illegal copied software, because the cost of the license for them is minimal (perhaps, i don't know how much you are goig to charge for your program) compared to the cost of a trial