Damon pointed
me to an interesting article written by a fellow AustinJUG member Vladimir Roubtsov
on Cracking
Java byte-code encryption. (Vlad, if you are out there,
congratulations on the articles. I noticed you started writing for
JavaWorld back in November, right after Michael Yuan and I gave our
java authors technotizer at ajug. I don't know if there is any
correlation between the two events, but it's a cool thought
nonetheless)
The article is well done and worth a read. Another technique is
presented as a side point in an old JDJ
article by Paul McLachlan. Basically, it explains how the JVM has
hooks built in to intercept the classes.
All these methods are quite interesting, but there is an important
theme throughout this: I own the JVM. It's that simple. When
you are running an application in my JVM I can see and control each
and every bit. In the JVM, I'm Neo. (whoa!)
In the case of encryption, eventually the class has to be
decrypted and run by the JVM. If the JVM can see it, I can see it.
Sealing jars won't keep me out of your packages. I can modify your
private variables and extend your final classes. I can even rewrite
your classes as they are loaded.
I own the JVM.
You can't count on any of the JVM security features to help you
either. Remember, the JVM security features are there to protect
me from your code, not to protect your code from me. That's an
important distinction that a lot of people just don't seem to get. If
you want to keep me out of your classes, the only solution is to run
them on your own JVM.
But don't take that as bad news. It's actually good news. It's
means you can stop worrying that someone might be able to see your
classes. They can, and no matter how much snake-oil you buy, that is
not going to change. Learn to love it.
Previous Topic
