How to create encrypted Jar file? [closed]

Question

I am working on project that must need to protect data (revealing code is not main problem) files. We are using Java + Netbeans. Is there any facility that will create jar in encrypted format? We are also using sqlite for database - so putting text file in encrypted format is not proper option for us too.

Answer 1

Creating encrypted JARs is not possible, since the executing JavaVM has to somehow be able to read the data it wants to execute. And similar to a VM it would be possible for anyone with the proper tools and know-how to extract all data from the JAR.

If it would be possible to encrypt the JAR, you would also have to provide some decryption-key or facility to the client which wants to execute the JAR which defeats the purpose of encryption at all.

The best you can get is obfuscation, but that's no real security or hurdle for the ambitious attacker.

Answer 2

Kosi2801 is pretty much right on. The only thing I can think of you could do is the following, but it's ugly.

1. Ship a small standard JAR and an encrypted data file.
2. When the JAR runs, it decrypts (some) of the encrypted data file into memory (like the directory of where data is in the JAR, basically a simple in-memory file system of pointer/length pairs)
3. Set up your own class loader that, when called, gets the right encrypted bytes from the JAR (using the pseudo-FS table described in #2), decrypts it, and then loads the class data from there

This would let you load the classes. You could do the same thing (without the class loader) to load other resources.

While fun to implement (for those who like a challenge) there are a few problems with this:

1. You'd need to be able to decrypt the stuff, so the user would either have to enter a password every time or something similar. If the JAR knows enough to decrypt it's self, then anyone can look at it and figure out how to decrypt things. This could be mitigated by contacting a known-good server over the Internet to ask for the decryption key (as long as you make that process secure). Of course this requires an active 'net connection any time someone wants to run the program.
2. Everything ends up in memory. Without a custom JVM that handle tiny bits of encrypted byte code (as Cameron McKay mentioned) the classes will end up decrypted sitting in main memory at some point. Unless you rely on the OS to prevent other people from reading that memory, you've already lost the battle to anyone with a little time on their hands. Same issue for resources (such as images/fonts/etc) that you try to read out of some encrypted store.

So you can give people the run-around and make things harder, but in the situation you've given all you can do is try to make it not worth the time the other person will have to invest.

Software protection is tough, especially in something like Java that can easily be decompiled and can't alter it's own code like C/Assembly could. There is a reason some of the most expensive software out there requires hardware dongles or comes locked to a certain CPU or other hardware.

Answer 3

I agree with Kosi2801. Class file encryption is just imitation of security (see http://www.excelsior-usa.com/articles/java-obfuscators.html) Use of custom ClassLoader's can break the application, e.g. in Application Servers.

There is the better way: use encryption of String constants in a class files. The most of commercial obfuscators have this function, for example Allatori, Stringer Java Obfuscation Toolkit, Zelix KlassMaster, Smokescreen, DashO (super expensive). The Stringer Java Obfuscator has call context check and integrity control features which makes protection really hard to hack.

The most secure way is to store and execute parts of bytecode on an external device like JavaCard.

N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.