Java安全：用加密技术保护Java源代码

　　为什么要加密?

　　对于传统的C或C++之类的语言来说，要在Web上保护源代码是很容易的，只要不发布它就可以。遗憾的是，Java程序的源代码很容易被别人偷看。只要有一个反编译器，任何人都可以分析别人的代码。Java的灵活性使得源代码很容易被窃取，但与此同时，它也使通过加密保护代码变得相对容易，我们唯一需要了解的就是Java的ClassLoader对象。当然，在加密过程中，有关Java Cryptography Extension(JCE)的知识也是必不可少的。

　　有几种技术可以“模糊”Java类文件，使得反编译器处理类文件的效果大打折扣。然而，修改反编译器使之能够处理这些经过模糊处理的类文件并不是什么难事，所以不能简单地依赖模糊技术来保证源代码的安全。

　　我们可以用流行的加密工具加密应用，比如PGP(Pretty Good Privacy)或GPG(GNU Privacy Guard)。这时，最终用户在运行应用之前必须先进行解密。但解密之后，最终用户就有了一份不加密的类文件，这和事先不进行加密没有什么差别。

　　Java运行时装入字节码的机制隐含地意味着可以对字节码进行修改。JVM每次装入类文件时都需要一个称为ClassLoader的对象，这个对象负责把新的类装入正在运行的JVM。JVM给ClassLoader一个包含了待装入类(比如java.lang.Object)名字的字符串，然后由ClassLoader负责找到类文件，装入原始数据，并把它转换成一个Class对象。

　　我们可以通过定制ClassLoader，在类文件执行之前修改它。这种技术的应用非常广泛――在这里，它的用途是在类文件装入之时进行解密，因此可以看成是一种即时解密器。由于解密后的字节码文件永远不会保存到文件系统，所以窃密者很难得到解密后的代码。

　　由于把原始字节码转换成Class对象的过程完全由系统负责，所以创建定制ClassLoader对象其实并不困难，只需先获得原始数据，接着就可以进行包含解密在内的任何转换。

　　Java 2在一定程度上简化了定制ClassLoader的构建。在Java 2中，loadClass的缺省实现仍旧负责处理所有必需的步骤，但为了顾及各种定制的类装入过程，它还调用一个新的findClass方法。

　　这为我们编写定制的ClassLoader提供了一条捷径，减少了麻烦：只需覆盖findClass，而不是覆盖loadClass。这种方法避免了重复所有装入器必需执行的公共步骤，因为这一切由loadClass负责。

　　不过，本文的定制ClassLoader并不使用这种方法。原因很简单。如果由默认的ClassLoader先寻找经过加密的类文件，它可以找到;但由于类文件已经加密，所以它不会认可这个类文件，装入过程将失败。因此，我们必须自己实现loadClass，稍微增加了一些工作量。