How to create encrypted Jar file? [closed]

Answer 1

You could use the CipherOutputStream and CipherInputStream to serialize Java objects to disk in an encrypted format. This may an option open for saving data.

Answer 2

Another option would be to make a custom JVM that decrypted the JAR on the fly. But the same problem remains: at some point the JAR Java classes have to be decrypted to be run by the JVM, and at that point they can be captured and de-compiled.

Not to mention that having a custom JVM would then require all your users to download that JVM as well.

Answer 3

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 4

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 5

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.

Answer 6

In general, there is no way to do this in a secure fashion, if you want the app and its data to be self-contained. However, you can certainly encrypt the files and decript them with a key buried in the code. A determined hacker can get it, but if that's not what you are worried about, then fine. If you do this, remember that encypted data cannot be compressed, so compress first, then encrypt.

If you genuinely need the data to be secure (eg, confidential data), you will need to encrypt the data with a key and supply that key to the app my some external means, such as putting it on a thumbdrive and getting that to the user by means of a secure courier.

Another possibility it to make the data (or the key) available over SSL, and use a good authentication method to verify who your user is.

In general - it's not possible for any system to be perfectly secure, but it's also not nessesary. A system only needs to be secure enough to discourage the attackers that you think will be trying to crack it.