|
級別: 初級
俞良鬆, 軟件工程師,獨立顧問和自由撰稿人
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,稍微增加了一些工作量。
每一個運行着的JVM已經擁有一個ClassLoader。這個默認的ClassLoader根據CLASSPATH環境變量的值,在本地文件系統中尋找合適的字節碼文件。
應用定製ClassLoader要求對這個過程有較爲深入的認識。我們首先必須創建一個定製ClassLoader類的實例,然後顯式地要求它裝入另外一個類。這就強制JVM把該類以及所有它所需要的類關聯到定製的ClassLoader。Listing 1顯示瞭如何用定製ClassLoader裝入類文件。
如前所述,定製ClassLoader只需先獲取類文件的數據,然後把字節碼傳遞給運行時系統,由後者完成餘下的任務。
ClassLoader有幾個重要的方法。創建定製的ClassLoader時,我們只需覆蓋其中的一個,即loadClass,提供獲取原始類文件數據的代碼。這個方法有兩個參數:類的名字,以及一個表示JVM是否要求解析類名字的標記(即是否同時裝入有依賴關係的類)。如果這個標記是true,我們只需在返回JVM之前調用resolveClass。
Listing 2顯示了一個簡單的loadClass實現。代碼中的大部分對所有ClassLoader對象來說都一樣,但有一小部分(已通過註釋標記)是特有的。在處理過程中,ClassLoader對象要用到其他幾個輔助方法:
Java加密擴展即Java Cryptography Extension,簡稱JCE。它是Sun的加密服務軟件,包含了加密和密匙生成功能。JCE是JCA(Java Cryptography Architecture)的一種擴展。
JCE沒有規定具體的加密算法,但提供了一個框架,加密算法的具體實現可以作爲服務提供者加入。除了JCE框架之外,JCE軟件包還包含了SunJCE服務提供者,其中包括許多有用的加密算法,比如DES(Data Encryption Standard)和Blowfish。
爲簡單計,在本文中我們將用DES算法加密和解密字節碼。下面是用JCE加密和解密數據必須遵循的基本步驟:
前面介紹瞭如何加密和解密數據。要部署一個經過加密的應用,步驟如下:
1. 步驟1:創建應用。我們的例子包含一個App主類,兩個輔助類(分別稱爲Foo和Bar)。這個應用沒有什麼實際功用,但只要我們能夠加密這個應用,加密其他應用也就不在話下。
2. 步驟2:生成一個安全密匙。在命令行,利用GenerateKey工具(參見GenerateKey.java)把密匙寫入一個文件:
3.
4. 步驟3:加密應用。在命令行,利用EncryptClasses工具(參見EncryptClasses.java)加密應用的類:
5.
該命令把每一個.class文件替換成它們各自的加密版本。 6. 步驟4:運行經過加密的應用。用戶通過一個DecryptStart程序運行經過加密的應用。DecryptStart程序如Listing 6所示。
7.
對於未經加密的應用,正常執行方式如下:
8.
對於經過加密的應用,則相應的運行方式爲:
9.
DecryptStart有兩個目的。一個DecryptStart的實例就是一個實施即時解密操作的定製ClassLoader;同時,DecryptStart還包含一個main過程,它創建解密器實例並用它裝入和運行應用。示例應用App的代碼包含在App.java、Foo.java和Bar.java內。Util.java是一個文件I/O工具,本文示例多處用到了它。完整的代碼請從本文最後下載。
我們看到,要在不修改源代碼的情況下加密一個Java應用是很容易的。不過,世上沒有完全安全的系統。本文的加密方式提供了一定程度的源代碼保護,但對某些攻擊來說它是脆弱的。
雖然應用本身經過了加密,但啓動程序DecryptStart沒有加密。攻擊者可以反編譯啓動程序並修改它,把解密後的類文件保存到磁盤。降低這種風險的辦法之一是對啓動程序進行高質量的模糊處理。或者,啓動程序也可以採用直接編譯成機器語言的代碼,使得啓動程序具有傳統執行文件格式的安全性。
另外還要記住的是,大多數JVM本身並不安全。狡猾的黑客可能會修改JVM,從ClassLoader之外獲取解密後的代碼並保存到磁盤,從而繞過本文的加密技術。Java沒有爲此提供真正有效的補救措施。
不過應該指出的是,所有這些可能的攻擊都有一個前提,這就是攻擊者可以得到密匙。如果沒有密匙,應用的安全性就完全取決於加密算法的安全性。雖然這種保護代碼的方法稱不上十全十美,但它仍不失爲一種保護知識產權和敏感用戶數據的有效方案。
|