運用加密技術保護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，稍微增加了一些工作量。
【編輯推薦】
