1

Our commercial jar which is run with batch files (java -jar ..) is distributed with our signature. It is NOT triggered with JNLP. It also contains additional 3rd party libraries. If any malicious person replaces any java class, the jar stops running because signature mismatch. But if he removes the MANIFEST files from the jar there is no check anymore. How can we prevent the program running when any class is replaced, changed? One option could be checking the manifest files in the java source as stated Verifying Jar Signature and How to verify a jar signed with jarsigner programmatically such as

jarFile jar = new JarFile(new File("path/to/your/jar-file"));

// This call will throw a java.lang.SecurityException if someone has tampered
// with the signature of _any_ element of the JAR file.
// Alas, it will proceed without a problem if the JAR file is not       signed at all
InputStream is = jar.getInputStream(jar.getEntry("META-INF/MANIFEST.MF"));
Manifest manifest = new Manifest(is);

and also checking the CodeSigners etc.

manifest.getCodeSigners();

But what happens when the person who is trying to break the jar, performs decompilation (using jad for example)? To prevent decompilation we applied some obfuscators, but when decompiled, we can see the logic even if the method names has been changed. So the obfuscation is not enough.

What is your suggestion? Is it a good approach writing the sign checking code complicated such as with reflect api, adding garbled data, some spagetti code with goto, or can you advice a different procedure to prevent manifest tampering as well as making decompilers unsuccessful? I checked the options in the obfuscator, but what can we do in the code writing phase to improve and strengten the obfuscation step?

Community
  • 1
  • 1
benchpresser
  • 2,171
  • 2
  • 23
  • 41
  • 1
    One thing I've done is embed my public key into the code and check the signatures using that public key. Again it isn't perfect, nothing is, but it's stronger, and it does rely on the manifest and the certificates being there. – user207421 Jun 03 '16 at 07:18

1 Answers1

1

As long as I know, there is no perfect solution for this problem until now. You can read this, the problem is alike. So far, obfuscation is probably the best+easy effort. I mean, not only by using code obfuscator, but you code such that weird logic to hide your algorithm so the cracker cannot trace the logic and method calls easily.

fikr4n
  • 3,250
  • 1
  • 25
  • 46