Hacker proofing a jar file

Question

What techniques could I use to make my "jar" file Reverse Engineer proof?

http://stackoverflow.com/questions/1146855/is-obfuscation-the-best-answer-closed — erickson, Sep 05 '09 at 16:22
I know it's impossible to make something "hacker-proof", and I understand the dangers of using such an inaccurate phrase, and I understand that many measures one might take to "hacker-proof" one's jars are bad ideas. HOWEVER, it might not be the OP's choice. Too many security questions on SO are answered with a "it's impossible" when an explanation of how one might make intrusion more difficult would be much more helpful. Yes, people need to know when full security is impossible but if that's all you have to offer that's only a partial answer. — Imagist, Sep 05 '09 at 16:29
@imagist "I understand that many measures one might take to "hacker-proof" one's jars are bad ideas" why? — Kevin Boyd, Sep 05 '09 at 16:40
Could you edit your answer to explain precisely which scenario you want to avoid? — Thorbjørn Ravn Andersen, Sep 05 '09 at 16:52
As has been stated many times before, there is nothing that can stop someone who is truly hellbent on reversing your code from reversing it. I was just reading a different question which showed me this link: http://java.decompiler.free.fr/. If you're running code on your user's machine, they have the ability to reverse it. It's just a fact of life. — MattC, Sep 05 '09 at 17:00

score 21 · Answer 1 · answered Sep 05 '09 at 15:13

21

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.

answered Sep 05 '09 at 15:13

sepp2k

363,768
54
674
675

2

Much like you cannot make machine-compiled code "hacker proof" - you can simply obfuscate it. – aperkins Sep 05 '09 at 15:17
9

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 Sep 05 '09 at 15:54
@Jeremy - given enough time even a server side algorithm can be broken. – Aaron M Sep 15 '09 at 21:10
@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 Oct 01 '09 at 15:10

score 11 · Answer 2 · answered Sep 05 '09 at 15:37

11

Don't release it.

answered Sep 05 '09 at 15:37

Brian Kelly

5,564
4
27
31

1

Almost 100%, as long as nobody gets a hold of your disk(s). Better zero that out and throw it in a fire to be completely sure. – L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳ Nov 17 '09 at 02:04
Klingons do not "release" software. Klingon software escapes, leaving a bloody trail of design engineers and quality assurance people in its path. from http://www.klingon.org/resources/klingon_code.html – stu Dec 29 '11 at 21:55

score 6 · Answer 3 · answered Sep 05 '09 at 15:13

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.

What is the nearest that I can get on this planet? – Kevin Boyd Sep 05 '09 at 15:14 — Kevin Boyd, Sep 05 '09 at 15:14

score 3 · Answer 4 · answered Sep 05 '09 at 15:35

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.

What are the current technologies for jar protection apart from obfuscation? — Kevin Boyd, Sep 05 '09 at 15:38

score 3 · Answer 5 · answered Sep 05 '09 at 15:36

3

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.

answered Sep 05 '09 at 15:36

PaulMcG

62,419
16
94
130

1

This seems like a terrible solution, though, as it would shoot your portability to hell. – Imagist Sep 05 '09 at 16:23
1

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. – PaulMcG Sep 05 '09 at 17:12
2

"... and still felt secure ...". Feeling secure and being secure are quite different things :-) – Stephen C Sep 06 '09 at 10:01

score 2 · Accepted Answer · answered Sep 05 '09 at 17:00

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.

score 1 · Answer 7 · answered Sep 05 '09 at 15:38

1

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.

answered Sep 05 '09 at 15:38

TrueWill

25,132
10
101
150

could not understand "avoid rolling your own". why? – Kevin Boyd Sep 05 '09 at 15:40
1

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 Sep 05 '09 at 15:53
Even an algorithm placed on server-side could be broken. – Aaron M Sep 15 '09 at 21:11

Hacker proofing a jar file

7 Answers7