這里向大家描述一下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運行解密后的字節碼文件，這樣就不會被反編譯了對嗎？
　　
　　考慮到你是第一個提出這種想法的并且它又能正常運行，我表示遺憾和不幸，這種想法是錯誤的。

【編輯推薦】

1. JAVA字節碼文件操作技巧
2. IBM發布Java字節碼配置工具包BIPTK
3. JVM.dll裝載過程與源代碼分析
4. 巧解使Eclipse崩潰的JVM terminated問題
5. 解決JVM Terminated.ExitCode=-1問題行之有效的方法