JAVA的編譯、反編譯、反反編譯

atfa

編譯、反編譯、反反編譯

http://www.oreilly.com.tw/column_sleepless.php?id=j020

「盜版」的行為，天天都在我們的周遭上演，所以今年五月由 BSA（商業軟體聯盟）和法務部發起的「反盜版」活動，著實讓大家風聲鶴唳了好一陣子。但是，即使在這樣詭譎的氣氛之下，由大專院校學生為主的「反反盜版」活動，到也振振有詞，轟轟烈烈地攻佔媒體版面。有「盜版」，就有「反盜版」；有「反盜版」，就有「反反盜版」，這個世界就是這麼一回事。

同樣的道理，有「編譯」（compile），就有「反編譯」（decompile）；有「反編譯」，就有「反反編譯」。對於 Java 和 .NET 這種虛擬機器的中間碼來說，尤其明顯。

Java 程式編譯後的結果是 Java Bytecode，而 .NET 編譯後的結果是 CIL（Common Intermediate Language），兩者都具有下列的特性：
同為堆疊式（stack-based）指令集。
同為高階物件導向機器語言。
和平台無關。
Code Validation
Symbolic Link
上述任何一點特色，都可以讓程式變得更容易反編譯，全部五點結合起來更是不得了。所以要反編譯 Java 和 .NET 可以說是相當容易的。網路上就到處流傳著 Java 的反編譯器（decompiler），可以把編譯後的檔案反推出原始碼，相信不久之後 .NET 也會遇到一樣的問題。（至少，喜歡搞破壞的我就正嘗試著寫一個 .NET decompiler。）

試想，如果你將辛辛苦苦開發出來的 Java 和 .NET 程式交給別人（蔡學鏞？），他只要透過反編譯器，就可以推出原始碼，你的智慧財產很可能會受到侵犯。

想要保護自己，你必須在 Java 或 .NET 軟體出貨前，進行反反編譯，這個動作通常稱為混淆（obfuscate）。被混淆過的程式碼，依然遵照原來的檔案格式和指令集，所以依然可以執行，執行結果也和混淆前一樣。只是被混淆過的程式碼變得更亂，更不容易被反編譯成功。

有的 Java 開發工具（例如 JBuilder）有內附混淆器（obfuscator），或者你也可以購買功能更強大的混淆器。這些商業的混淆器通常只做三件事：
將每一個 method 內部用更亂的方式組織。
將 Java Constant Pool，或 .NET metadata 內可以消除的 Symbolic Data 消除（例如 private method 的名字）。
將 debug 資訊（例如 Java 的 LocalVariableTable 與 LineNumberTable）全部刪除。
Obfuscator 的作用如果只是如同上述一般，只有 method 局部的作用，效果不大。欲大幅度地增加反編譯的難度，必須搭配下列的方式：
Class 內的混淆：將 class 內的 method 互相混淆。
Class 之間的混淆：將 class 之間的關係混淆，例如將父類別和子類別合併或拆解等。
有一些學術論文有對上述兩點做出研究，但成效仍然不大，而且必須手動調整，無法由軟體自動處理。這方面值得大家投入更深入的研究。

混淆過的程式會遇到下面的問題：
通常效率會變差。
可能無法執行。我遇過這樣的情況，有可能是混淆器的錯，也有可能是 JVM 的錯。
如果進行「Class 之間的混淆」，稍有不慎，就很可能會無法執行。例如：Java 程式中如果有用到 instanceof，或者 C# 程式中有用到 is，就要很小心的進行「Class 之間的混淆」，否則後果不堪設想。

混淆的目的有兩個層次：
讓程式無法被自動反編譯：例如做出一些特殊的跳躍（goto），讓程式區塊（block）的關係無法被找出特定的 pattern。
讓程式就算被反編譯成功，也不容易被程式員閱讀理解：想辦法加入一些不易被識破的程式碼來欺騙程式員。
Obfuscator 不是萬靈丹，如果遇上了一個精通 obfuscating 技術的人，佐以 profiling 工具，原始碼還是會落入他的手中。所以，使用 obfuscator 時，你必須有這樣的心理準備：「防君子，不妨小人；防笨蛋，不防聰明人」。盡可能將軟體放在 server 改為提供 service，而不將軟體賣到客戶手上，這才是上策。



本文作者：蔡學鏞
張貼日期：08/05/2002

wolf0403

呵呵，台湾风格的语言有够可爱