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
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
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 9
there was a lot of interest on this topic back in the time
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