深入研究JAVA字节码反编译的方法

核心提示：问：假如我把我的class文件加密，在运行时用指定的类加载器(class loader)装入并解密它，深入研究JAVA字节码反编译的方法，这样子能防止被反编译吗？答：防止java字节码反编译这个问题在java语言雏形期就有了，尽管市面上存在一些反编译的工具可以利用，面是一个简单的类编码器： 为了阐明这种思想，我采用了一

　　问：
　　假如我把我的class文件加密，在运行时用指定的类加载器(class loader)装入并解密它，这样子能防止被反编译吗？
　　答：
　　防止java字节码反编译这个问题在java语言雏形期就有了，尽管市面上存在一些反编译的工具可以利用，但是JAVA程序员还是不断的努力寻找新的更有效的方法来保护他们的聪明结晶。在此，我将具体给大家解释这一直来在论坛上有争议的话题。
　　
　　Class文件能被很轻松的重构生成JAVA源文件与最初JAVA字节码的设计目的和商业交易有紧密地联系。另外，JAVA字节码被设计成简洁、平**立性、网络灵活性，并且易于被字节码解释器和JIT (just-in-time)/HotSpot 编译器所分析。可以清楚地了解程序员的目的, Class文件要比JAVA源文件更易于分析。
　　假如不能阻止被反编译的话，至少可以通过一些方法来增加它的困难性。例如: 在一个分步编译里，你可以打乱Class文件的数据以使其难读或者难以被反编译成正确的JAVA源文件，前者可以采用极端函数重载，后者用操作控制流建立控制结构使其难以恢复正常次序。有更多成功的商业困惑者采用这些或其他的技术来保护自己的代码。
　　不幸的是，哪种方法都必须改变JVM运行的代码，并且许多用户害怕这种转化会给他们的程序带来新的Bug。而且，方法和字段重命名会调用反射从而使程序停止工作，改变类和包的名字会破坏其他的JAVA APIS（JNDI, URL PRoviders, etc）,除了改变名字，假如字节码偏移量和源代码行数之间的关系改变了，在恢复这有异常的堆栈将很困难。
　　于是就有了一些打乱JAVA源代码的选项，但是这将从本质上导致一系列问题的产生。
　　
　　加密而不打乱
　　或许上述可能会使你问，假如我把字节码加密而不是处理字节码，并且JVM运行时自动将它解密并装入类加载器，然后JVM运行解密后的字节码文件，这样就不会被反编译了对吗？
　　考虑到你是第一个提出这种想法的并且它又能正常运行，我表示遗憾和不幸，这种想法是错误的。
　　
　　面是一个简单的类编码器：
　　
　　为了阐明这种思想，我采用了一个实例和一个很通用的类加载器来运行它，该程序包括两个类：
　　
　　 public class Main
　　{
　　　　public static void main (final String [] args)
　　　　{　
　　　　　　System.out.println ("secret result = " + MySecretClass.mySecretAlgorithm ());
　　　　}
　　
　　} // End of class
　　
　　
　　package my.secret.code;
　　
　　import java.util.Random;
　　
　　public class MySecretClass
　　{
　　　　/**
　　　　 * Guess what, the secret algorithm just uses a random number generator...
　　　　 */
　　　　public static int mySecretAlgorithm ()
　　　　{
　　　　　　return (int) s_random.nextInt ();
　　　　}
　　
　　　　private static final Random s_random = new Random (System.currentTimeMillis ());
　　
　　} // End of class
　　我想通过加密相关的class文件并在运行期解密来隐藏my.secret.code.MySecretClass的执行。用下面这个工具可以达到效果（你可以到这里下载Resources）：
　　
　　public class EncryptedClassLoader extends URLClassLoader
　　{　　
　　　　public static void main (final String [] args)
　　　　　　throws Exception
　　　　{　　　　
　　　　　　if ("-run".equals (args [0]) && (args.length >=　3))
　　　　　　{
　　　　　　　　// Create a custom loader that will use the current loader as
　　　　　　　　// delegation parent:
　　　　　　　　final ClassLoader appLoader =
　　　　　　　　　　new EncryptedClassLoader (EncryptedClassLoader.class.getClassLoader (),
　　　　　　　　　　new File (args [1]));
　　　　　　　　
　　　　　　　　// Thread context loader must be adjusted as well:
　　　　　　　　Thread.currentThread ().setContextClassLoader (appLoader);
　　　　　　　　
　　　　　　　　final Class app = appLoader.loadClass (args [2]);
　　　　　　　　
　　　　　　　　final Method appmain = app.getMethod ("main", new Class [] {String [].class});
　　　　　　　　final String [] appargs = new String [args.length - 3];
　　　　　　　　System.arraycopy (args, 3, appargs, 0, appargs.length);
　　　　　　　　
　　　　　　　　appmain.invoke (null, new Object [] {appargs});
　　　　　　}
　　　　　　else if ("-encrypt".equals (args [0]) && (args.length >= 3))
　　　　　　{
　　　　　　　　... encrypt specified classes ...
　　　　　　}
　　　　　　else
　　　　　　　　throw new IllegalArgumentException (USAGE);　　　　
　　　　}
　　　　
　　　　/**
　　　　 * Overrides java.lang.ClassLoader.loadClass() to change the usual parent-child
　　　　 * delegation rules just enough to be able to "snatch" application classes
　　　　 * from under system classloader's nose.
　　　　 */
　　　　public Class loadClass (final String name, final boolean resolve)
　　　　　　throws ClassNotFoundException
　　　　{
　　　　　　if (TRACE) System.out.println ("loadClass (" + name + ", " + resolve + ")");
　　　　　　
　　　　　　Class c = null;
　　　　　　
　　　　　　// First, check if this class has already been defined by this classloader
　　　　　　// instance:
　　　　　　c = findLoadedClass (name);
　　　　　　
　　　　　　if (c == null)
　　　　　　{
　　　　　　　　Class parentsVersion = null;
　　　　　　　　try
　　　　　　　　{
　　　　　　　　　　// This is slightly unorthodox: do a trial load via the
　　　　　　　　　　// parent loader and note whether the parent delegated or not;
　　　　　　　　　　// what this accomplishes is proper delegation for all core
　　　　　　　　　　// and extension classes without my having to filter on class name:
　　　　　　　　　　parentsVersion = getParent ().loadClass (name);
　　　　　　　　　　
　　　　　　　　　　if (parentsVersion.getClassLoader () !