Question

Objective:

Secure my Java application from reverse engineering.

Idea:

1. split the program into two halves (loader and program)
2. loader will be a regular jar
3. program will be an encrypted jar file (bouncycastle, AES?)
4. loader asks secure server (https) for a key to decode program
5. loader then decodes program and loads up it’s classes

Questions:

Would number 5 be possible?
Has anyone here done this?
Do you know any library already available?
Can you spot major pitfalls / would you do it differently?

Extra

I know it is impossible to prevent full reverse engineering of the code.
I’m just looking to make it harder and more traceable.

Answer 1

This is very possible using Class Loaders. But it is still very easy to decode your program. All one would need to do is change your Loader to write all the classes to disc before it loads them into memory with your custom ClassLoader.

Update

If the Loader is something your users can execute then I would just need to decompile and replace the Loader JAR file to dump the classes to disk. Not only that I am certain there must be something that can take a memory dump of a JVM and output all of the loaded byte code.

If the Loader is on a locked machine in which users cannot obtain access, then what is the Use Case you are trying to solve?

The “solutions” to these problems are:

1. Use an advanced Obfuscator that is designed to break decompilers.
2. Prevent access to the JAR files themselves. Either through ACL’s on the machine or by employing a remote server to execute the code you want secure. This is essentially how Web Applications work. There can be a substantial amount of IP or processing that Stackoverflow does but we would never have access to the back-end processing, on the result of the User Experience output.