防止JAVA字节码反编译问题解决方案-java防止反编译

这里向大家描述一下Java字节码加密问题，Class文件能被很轻松的重构生成JAVA源文件与最初JAVA字节码的设计目的和商业交易有紧密地联系。

深入Java字节码加密

　　问：

　　如果我把我的class文件加密，在运行时用指定的类加载器(classloader)装入并解密它，这样子能防止被反编译吗？
　　
　　答：

　　防止JAVA字节码反编译这个问题在java语言雏形期就有了，尽管市面上存在一些反编译的工具可以利用，但是JAVA程序员还是不断的努力寻找新的更有效的方法来保护他们的智慧结晶。在此，我将详细给大家解释这一直来在论坛上有争议的话题。
　　
　　Class文件能被很轻松的重构生成JAVA源文件与最初JAVA字节码的设计目的和商业交易有紧密地联系。另外，JAVA字节码被设计成简洁、平台独立性、网络灵活性，并且易于被字节码解释器和JIT(just-in-time)/HotSpot编译器所分析。可以清楚地了解程序员的目的,Class文件要比JAVA源文件更易于分析。
　　
　　如果不能阻止被反编译的话，至少可以通过一些方法来增加它的困难性。例如:在一个分步编译里，你可以打乱Class文件的数据以使其难读或者难以被反编译成正确的JAVA源文件，前者可以采用极端函数重载，后者用操作控制流建立控制结构使其难以恢复正常次序。有更多成功的商业困惑者采用这些或其他的技术来保护自己的代码。

　　不幸的是，哪种方法都必须改变JVM运行的代码，并且许多用户害怕这种转化会给他们的程序带来新的Bug。而且，方法和字段重命名会调用反射从而使程序停止工作，改变类和包的名字会破坏其他的JAVAAPIS（JNDI,URLproviders,etc）,除了改变名字，如果字节码偏移量和源代码行数之间的关系改变了，在恢复这有异常的堆栈将很困难。
　　
　　于是就有了一些打乱JAVA源代码的选项，但是这将从本质上导致一系列问题的产生。
　　
加密而不打乱

　　或许上述可能会使你问，假如我把字节码加密而不是处理字节码，并且JVM运行时自动将它解密并装入类加载器，然后JVM运行解密后的字节码文件，这样就不会被反编译了对吗？
　　
　　考虑到你是第一个提出这种想法的并且它又能正常运行，我表示遗憾和不幸，这种想法是错误的。

【编辑推荐】