This post originated from an RSS feed registered with Java Buzz
by Vlad Roubtsov.
Original Post: Java class encryption: don't trust it
Feed Title: Java Curiosity Shop
Feed URL: http://www.blog-city.com/bc/
Feed Description: Java esoterics: things from "don't try this at home" category
The article on breaking lame Java code protection schemes based on class encryption generated quite a bit of reader feedback.
A few people understand that once a JVM can see your unencrypted and [very] decompilable bytecode, so can your users. Encrypting .class files on disk accomplishes next to nothing, as it is straighforward to hook into Java classloading and intercept bytecode after the decryption has been done.
Others have attempted to defend class encryption by working around the defineClass() exploit in various ways. I believe none of the suggestions is really workable. JavaWorld might publish some of my rebuttals as Letters to the Editor.
The one suggestion I liked the most was to move all classloading to a native classloader that makes use of JNI DefineClass() method. This seems to move the encryption/decryption into native code (with a much higher barrier against decompilation). However, JNI DefineClass() delivers the same unencrypted byte array to the JVM when all is set and done. Furthermore, class definitions done by JNI code still generate JVMPI events and so the scheme falls through because it is just as easy to grab .class content via a simple JVMPI_EVENT_CLASS_LOAD_HOOK agent.
It is amazing that there commercial kits out there that promise "intellectual property protection" via encryption that cost from $200 to several thousand dollars.
Previous Topic
