What techniques could I use to make my "jar" file Reverse Engineer proof?
+5
A:
There is no such thing as hacker proof. Sorry.
EDIT FOR COMMENT:
The unfortunate truth is that no matter what barricade you put in the way, if the honestly want in, they'll get in. Simply because if they're persistent enough they'll be looking at your code from an Assembly level. Not a thing on earth you can do about it.
What you can look at doing is Obfuscating code, packing the jar and merging all externals packages into a single to make life harder. However no matter how high the hurdle, my comment in the previous paragraph still applies.
Kyle Rozendo
2009-09-05 15:13:11
What is the nearest that I can get on this planet?
Kevin Boyd
2009-09-05 15:14:43
+16
A:
You can't make it reverse engineer proof. If the java runtime can read the instructions, so can the user.
There are obfuscators which make the disassembled code less readable/understandable to make reverse engineering it harder, but you can't make it impossible.
sepp2k
2009-09-05 15:13:23
Much like you cannot make machine-compiled code "hacker proof" - you can simply obfuscate it.
aperkins
2009-09-05 15:17:19
There is one way -- make sure that the user never has access to the .jar file in the first place. For example, some applications download only a "client" to the user, and in order to access the Super Secret Algorithm, the client has to send processing requests to a server (which is owned by the developer, and hopefully well-secured) which runs the Secret Code on the client's data and sends back the results.
Jeremy Friesner
2009-09-05 15:54:08
@aaron: yes, but you only need to update it, or change a compromised key - you dont have shipped products that you cant control the execution of.
Chii
2009-10-01 15:10:16
+3
A:
I think this is more about hardening the access path to the jar, more than anything else.
- Try to determine what user context will actually be executing the code that will access the .jar. Lock down access to the jar to read-only access from only that user. How you do this will depend on if you're using the jar from a web app or a desktop .exe, and it will also depend on the operating system you're running under.
- If possible -- sign the jar and validate the signature from the executable code. This will at least tell you if the .jar has been tampered with. You can then have some logic to stop the executing application from using the .jar (and log and display an error). See jarsigner docs for more information.
Dan Esparza
2009-09-05 15:35:00
What are the current technologies for jar protection apart from obfuscation?
Kevin Boyd
2009-09-05 15:38:29
+3
A:
I have seen one case where a company wrote a custom classloader, that could decrypt an encrypted jar file. The classloader itself used compiled JNI code, so that the decryption key and algorithm were fairly deeply obfuscated in the binary libary.
Paul McGuire
2009-09-05 15:36:04
This seems like a terrible solution, though, as it would shoot your portability to hell.
Imagist
2009-09-05 16:23:25
Everything is a compromise. In this case, the company wanted to get their product to market on a selected platform, while still protecting their IP, and let portability issues get resolved if and when a paying customer needed their product on another platform. And this classloader was the only JNI thing they had, the rest of the code was plain Java. So yes, "terrible" in that it tied them to a particular platform, but no, not so "terrible" in that they got their product out and still felt secure they weren't giving away the secret sauce.
Paul McGuire
2009-09-05 17:12:53
"... and still felt secure ...". Feeling secure and being secure are quite different things :-)
Stephen C
2009-09-06 10:01:52
+1
A:
Definitely avoid placing any sensitive data in the code. For example:
- passwords
- database connection strings
One option would be to encrypt these (using industry-standard encryption routines; avoid rolling your own) and place them in an external configuration file or database.
As others have stated, any algorithms in deployed code can be reverse-engineered.
Sensitive algorithms could be placed in a web service or other server-side code if desired.
TrueWill
2009-09-05 15:38:19
See http://stackoverflow.com/questions/118374/what-techniques-do-you-use-when-writing-your-own-cryptography-methods - skip the accepted answer and read through the others. (The accepted answer is basically "do it for fun" - but not for production code.) Most people fall into the trap of security-through-obscurity - and, as mentioned above, your algorithms can be reverse-engineered.
TrueWill
2009-09-05 15:53:15
+1
A:
You are looking for an "obfuscator" (if you want to ship jars) . Many exist:
http://java-source.net/open-source/obfuscators
You should be aware that many obfuscation techniques removes information you may want to keep for troubleshooting purposes - think of the value of a stack trace from an irreproducible situation - or actual debugging sessions. Regardless of what you do, your quality testing should be done on the jars-to-be-shipped since the obfuscator may introduce subtle bugs.
If you really want to hide things, consider compiling to an native binary with gcj.
Thorbjørn Ravn Andersen
2009-09-05 17:00:06