How to create encrypted Jar file? [closed]

Answer 1

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.