The question:
Suppose I am working on a Java project and want to distribute it to others for different purposes (testing, release, etc.) Usually, I’d build a JAR file and then share it. Being platform-independent, it can run on any OS. Downfall is, the JAR archive can easily be extracted and from there, anyone can decompile the .class files and retrieve the source code. Is there a way out of this?
[ On another note, compiling a C++ program generates .exe/.out files which can be executed by the respective OS. Using Launch4J I can convert JAR to EXE. But for Linux, I haven’t found any such solution (except writing a script and executing the JAR through it) ]
— by Ataf Fazledin Ahamed
The answer
There are different ways depending upon which satisfactory level it is
1. Obfuscating the source code: It’s basically going through the source code and replacing the variables+function names in just plain a/b/c/d, so when decompiled, they look like zombies had written that code. The decompiled version is a perfectly working java code, which, with enough motivation one can find out code logics. You can use proguard like tool to do the obfuscation and it has a way to keep a mapping of which symbol means what.
2. Converting java jar to exe/binary: This is again an encoding procedure, just on totally different machine level code.
#1 only gives you basic level of protection, because there are already decompilation software (i.e. JD Decompiler), you just drag&drop your jar file, it shows source code, organized by packages
#2 is a bit hard to reverse engineer, takes lot of toil, though it exposes the execution sequences once reverse engineered. I would say it is a decent enough way to guard the source code.
There is another way, which is encryption.
3. Encrypting the byte codes, store the encryption key in a secure place. And then use an installer to get that key, decrypt the source and put it somewhere in the destination computer. Or use an executor which does the same thing at runtime, leaving no persistence trace of decompiled source codes.
Now to keep the encryption key secure, obviously you don’t distribute it with the jar itself. Rather you probably keep it in a server, and then when someone buys your licence, you deliver the key. You can also generate encrypted bytecodes based on your customer and ensure per customer encryption.
There is another way, which is more secure to manage key. You know there is a tiny chip in our sim card/credit card/national smart id card. It’s basically a secure element based usb token. This chips are made in a way that information extraction is really hard unless proper pin is matched. You can take this token and store your software license key inside that secure hardware token. This way, when the usb token is inserted, your software will read the key from usb(given a valid pin), and decrypt the bytecodes, load the java classes on the fly. And all this happen in operating system runtime memory, so it’s harder for novice developer to hack in. I did it back in 2013 and it’s a lot fun to play with bytecodes.
But then again, engineers with customized operating system can still read you decrypted bytecode from memory and get your code. That’s why, this type of solution is normally used in Bank, where a lot of security standards are followed and maintains complied legal laws. Basically such kind of companies where security is extremely essential and your client themselves guard the source code.
So you see, depending upon how much valuable your source code is, you spend your effort on securing it. Starting from hobbist projects, to business project, to nationwide govt security projects, this effort varies.
Efficiently managing license keys is like catching thieves. Delivering desktop installer is like 90s way. You release a version and then it chases you until your death because now you wanna add new feature, fix bugs, need to release new versions, do crush analytics and deprecate old versions. That’s why more and more companies going to software as a service model to avoid the whole chain of software distribution. Also not all distribution pipeline fit all customers. Hence we still have softwares distributed with full installer. The most common question that businesses have to answer “Is this source code worthy of the effort to keep it secure?” None the less, software distribution itself could be an interesting topic 🙂