Geek Answers Handbook

Hacker protecting jar file

What methods can I use to make my Reverse Engineer jar file proof?

+4
source share
7 answers

You are looking for an "obfuscator" (if you want to send jars). Many exist:

http://java-source.net/open-source/obfuscators

You should be aware that many obfuscation methods delete information that you might want to keep for troubleshooting — think about the meaning of the stack trace from an irreducible situation — or about real debugging sessions. No matter what you do, your quality testing should be done on the jars that will be shipped, as the obfuscator may introduce subtle errors.

If you really want to hide things, consider compiling to a native binary using gcj.

+2
source

You cannot do it back as an engineer. If the java runtime can read the instructions, so can the user.

There are obfuscators that make disassembled code less readable / understandable to make reversing more difficult, but you cannot make it impossible.

+21
source

Do not let it go.

+11
source

There is no such thing as proof of a hacker. Unfortunately.

EDIT COMMENT:

The unfortunate truth is that no matter what barricade you put in the way, if you honestly want to, they will enter. Just because if they are persistent enough, they will look at your code from the assembly level. You can do nothing in the world.

What you can see is code obfuscation, packing a jar and combining all external packages into one to make life more difficult. However, no matter how high the problem is, my comment in the previous paragraph still applies.

+6
source

I think that this is more due to the simplification of access to the bank, more than anything else.

  • Try to determine which user context will actually execute the code that will access the .jar. Lock down access to the bank read-only access only from this user. How you do this will depend on whether you are using the jar from a web application or the .exe desktop, and it also depends on the operating system you are working under.
  • If possible - sign the bank and confirm the signature with the executable code. It will at least tell if the .jar has been tampered with. Then you can some logic to stop the executable application from using .jar (and log and error display). See jarsigner docs for more details.
+3
source

I saw one case where a company wrote a custom classloader that can decrypt an encrypted jar file. The class loader itself used the compiled JNI code, so the key and decryption algorithm were pretty deeply confused in the binary library.

+3
source

Definitely avoid placing any sensitive data in your code. For instance:

  • Passwords
  • Database Connection Strings

One option would be to encrypt them (using standard standard encryption procedures, avoid accumulating them) and place them in an external configuration file or database.

As others have argued, any algorithms in deployed code can be reverse-engineered.

If necessary, sensitive algorithms can be placed in a web service or other server code.

+1
source

More articles:


All Articles