in 1999 i wrote a paper on security in set-top boxes (one of my first papers); yay. but, one approach we had was to build a custom class loader that would actually load encrypted classes.
the details of the paper are:
1999 - Security in Set-Top boxes European Multimedia, Embedded Systems and Electronic Commerce EMMSEC '99, Stockholm, SWEDEN June 21-23, 1999
there was a lot of interest on this topic back in the time:) i had a number of successful prototypes built - but, unless you build the class loader into hardware (ie: cannot access the.class file), its just another hurdle, nothing more.
I believe encryption is probably not worth the effort for most people, it's not much of a hurdle to overcome. Ultimately all custom class loader execution paths will lead to a ClassLoader.defineClass call which can either be intercepted by creating a modified system class loader or by creating a JVMPI agent which listens for JVMPI_EVENT_CLASS_LOAD_HOOK events. If you can prevent these methods from being employed then you're probably operating in a secure environment where encryption would be overkill.
The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details for doing so are detailed in the article above), at which time someone can just write the unecrypted class file out to disk (or wherever they wish). Voila! All your IP are belong to us.
> "security" in Java is so trivially easy to circumvent
Are you confusing encryption with obfuscation? If not I agree that class-level encryption has no ROI.
Obfuscation, on the other hand, is an excellent tool for protecting IP. I use Proguard http://proguard.sourceforge.net/ [sourceforge.net] via Ant and am happy with the result, having tried to grok the resulting byte code (using jad...) Good luck trying to work with that!
Nope, I'm not confusing encryption with obfuscation. In fact, I don't know where you could get that idea, since neither my post nor the one I replied to mentions obfuscation at all.... Both are quite clearly about class file encryption.
To your unrelated point however, yes, there are some obfuscators that do make it difficult, though not impossible, to comprehend decompiled byte code. Though obfuscation comes with its own array of potential issues, especially in remote applications or those that rely on
I'd agree with you that no obfuscator could really make it impossible to recreate a piece of software from the bytecode... but of course the only real aim is to make it hard enough so that it would be easier to simply purchase the software.
Though obfuscation comes with its own array of potential issues, especially in remote applications or those that rely on reflection
Obfuscators pretty much all offer you enough flexibility to exclude classes that will need to be used via reflection or with RMI... or to
I have implemented an encrypted class loader that never delivers the unencrypted bytes to the java class. The author of this article is mostly correct, and I have read this article before. He states the following:
until JVM architecture changes to, say, support class decoding inside native code...
This is already possible and I have implemented it. It involves making direct calls to the jvm libraries from JNI rather than callbacks to java from JNI. There is still a way to get the bytes, but it invo
A noble goal, to be sure, but the custom class loader itself would have to be written in *unencrypted* Java and, therefore, would be subject to decompiling. This is because the custom class loader would be loaded by the VM's native class loader.
Regardless, it is a very trivial matter to insert a proxy between the VM and the custom class loader that can intercept and persist the unencrypted class.
If source code security is really that much of a concern, you would need a custom VM that would natively read t
Their idea of an offer you can't refuse is an offer... and you'd better
not refuse.
another alternative = encrypted class files (Score:5, Interesting)
the details of the paper are:
1999 - Security in Set-Top boxes
European Multimedia, Embedded Systems and Electronic Commerce
EMMSEC '99, Stockholm, SWEDEN
June 21-23, 1999
COPY: (pdf)
http://www.ardiri.com/publications/emmsec9
there was a lot of interest on this topic back in the time
Re:another alternative = encrypted class files (Score:4, Informative)
Doesn't work (Score:5, Informative)
There are a number of papers and articles detailing why this type of approach to "IP security" is so misguided. One such article is here: http://www.javaworld.com/javaworld/javaqa/2003-05
The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details for doing so are detailed in the article above), at which time someone can just write the unecrypted class file out to disk (or wherever they wish). Voila! All your IP are belong to us.
Re:Doesn't work (Score:4, Informative)
Are you confusing encryption with obfuscation? If not I agree that class-level encryption has no ROI.
Obfuscation, on the other hand, is an excellent tool for protecting IP. I use Proguard http://proguard.sourceforge.net/ [sourceforge.net] via Ant and am happy with the result, having tried to grok the resulting byte code (using jad...) Good luck trying to work with that!
R7
Re:Doesn't work (Score:1)
To your unrelated point however, yes, there are some obfuscators that do make it difficult, though not impossible, to comprehend decompiled byte code. Though obfuscation comes with its own array of potential issues, especially in remote applications or those that rely on
Obfuscation issues (Score:2)
Though obfuscation comes with its own array of potential issues, especially in remote applications or those that rely on reflection
Obfuscators pretty much all offer you enough flexibility to exclude classes that will need to be used via reflection or with RMI... or to
Re:Doesn't work (Score:2)
until JVM architecture changes to, say, support class decoding inside native code...
This is already possible and I have implemented it. It involves making direct calls to the jvm libraries from JNI rather than callbacks to java from JNI. There is still a way to get the bytes, but it invo
Re:another alternative = encrypted class files (Score:2)
Regardless, it is a very trivial matter to insert a proxy between the VM and the custom class loader that can intercept and persist the unencrypted class.
If source code security is really that much of a concern, you would need a custom VM that would natively read t