編譯、反編譯、反反編譯

盜版」的行爲,天天都在我們的周遭上演,所以今年五月由 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,而不將軟體賣到客戶手上,這纔是上策。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章