Encrypted class files with decryption handled by a native library

views:

answers:

Encrypted class files with decryption handled by a native library

The article "Cracking Java byte-code encryption" (javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html) explains why class file encryption using a custom class loader is pointless, because at some point you always need to call defineClass(), which passes the class file to the JVM as an unencrypted byte array.

However I've seen solutions where a slightly different approach is used; the class is decrypted by a native library and handed over to the JVM as a java.lang.Class instance through the findClass() method -- defineClass() is never called.

Does that mean that these solutions do not have this weakness? Sure, you can always extract class files by working with a debugger on the assembler level, and a determined hacker can break any protection. But at least this makes decompilation a bit more difficult than just patching defineClass() to dump unencrypted .class files to disk. Or am I overlooking something?

+1 A:

But at least this makes decompilation a bit more difficult than just patching defineClass() to dump unencrypted .class files to disk.

Only a bit. Not enough to make much difference.

Or am I overlooking something?

At some point, the native library has to decrypt the bytecodes. It wouldn't be hard to patch the native library to do snarf them at that point. Disassembly and patching binary libraries is not "rocket science".

Stephen C 2010-09-17 12:49:32

Of course, it is not rocket science. But I guess you'll concede that the universe of people that can crack native code is smaller than the universe of people that can decompile Java classes :-)

Grodriguez 2010-09-17 12:53:09

Not necessarily. There are millions of developers out there who learned some assembly language programming somewhere in their education. Machine code and bytecodes are not *that* different, when all is said and done. Either way, the "universe of people" who would capable of reverse engineering native code (given time and incentive) is still *very* large.

Stephen C 2010-09-17 13:02:34

OK, without entering a discussion on which universe is larger. Would you agree that in order to break this protection one would need to work on the assembler level? Or am I overlooking something obvious (obvious == equivalent to just intercepting calls to defineClass())

Grodriguez 2010-09-19 12:10:54

@Grodriguez - I would agree with that, though I would NOT consider it a significant impediment to reverse engineering.

Stephen C 2010-09-19 22:33:30

If you're going to require the presence of a native library, you are giving up the platform independence. At that point, you may want to investigate gcj and compile straight to an executable.

Devon_C_Miller 2010-09-17 17:19:33

Giving up platform independence -- yes and no. My application would still run in all supported platforms from the same codebase, and I would not mind including a small native library for this specific purpose. Having said that, I would certainly be willing to use gcj but currently the runtime is far for complete, especially regarding AWT and Swing support. Actually, if I could only compile my application to native but still have it use the standard JRE, that would be perfect.

Grodriguez 2010-09-17 18:50:41

ansaurus

tags:

views:

answers:

Encrypted class files with decryption handled by a native library

related questions