首 頁 關於德錡 試用申請    
   
解釋、編譯與反編譯

說到軟體的加密就不得不提提與之相關的各種編程語言,在大多數的時候我們並不關心我們所使用的編程語言所編制出來的程序是如何執行的,但如果你設計了一種特有的算法又不希望別人知道的情況下,所採用的加密手段往往同你的編程語言有很大的關系。

 

在大學裡面學習過編譯原理課程的人都知道,我們現在所使用的語言無非是兩種,一種是解釋執行的,另一種就是編譯後才能夠執行的語言。解釋執行的語言因為解釋器不需要直接同機器碼打交道所以實現起來較為簡單、而且便于在不同的平台上面移植,這一點從現在的編程語言解釋執行的居多就能看出來,如Visual Basic、Visual Foxpro、Power Builder、Java...。編譯執行的語言因為要直接同CPU的指令集打交道,具有很強的指令依賴性和系統依賴性,但編譯后的程序執行效率要比解釋語言要高的多,象現在的Visual C/C++、Delphi等都是很好的編譯語言。

 

對于解釋語言與編譯語言所編制出來的代碼安全性上而言,可以說是各有優缺點。曾經在Windows下跟蹤調式過VB3或VB4程序的朋友一般都知道,程序代碼99%的時間里都是在VBRUNxx里轉來轉去,根本看不出一個所以然來。這是因為你跟蹤的是VB的解釋器,要從解釋器中看出代碼的目的是什么是相當困難的。但解釋語言有一個致命的弱點,那就是解釋語言的程序代碼都是以偽碼的方式存放的,一旦被人找到了偽碼與源碼之間的對應關系,就很容易做出一個反編譯器出來,你的源程序等于被公開了一樣。而編譯語言因為直接把用戶程序編譯成機器碼,再經過優化程序的優化,很難從程序返回到你的源程序的狀態,但對于熟悉匯編語言的解密者來說,也很容易通過跟蹤你的代碼來確定某些代碼的用途。

 

下面我根據我的了解對各種具有反編譯器的語言進行一下簡單的介紹:

 

1、Visual Basic:據我所知VB3、VB4都有相應的反編譯器存在。而VB5、VB6不再是單純的解釋程序了,雖然里面還有解釋執行的部分,但起碼主程序部分是真正編譯的,沒有人做出VB5以上的反編譯器了。

 

2、Foxpro:這種語言是反編譯器的主要市場,我几乎見到過所有版本FoxPro的反編譯器,不管是DOS版的還是Windows版的。其代碼的安全性十分令人擔憂。另外提一句,現在的外殼加密程序對它也是毫無幫助的,因為大多數的外殼程序都不會對程序中的偽碼部分進行處理,外殼程序加密的只是其解釋器部分。

 

3、Cliper:DOS下的一種數據庫語言,不知道現在是否還有人在使用它,但至少我看到過它的反編譯器。

 

4、Java:我至少見到過3-4種Java語言的反編譯器,據使用過的人說,其中有些反編譯器效果極好,能把那些.class結尾的文件反的一點不差。看來我至少要等到有編譯版本的Java出來后再考慮學習這種時髦的語言了。

 

5、Install Shield:我沒寫錯,Install Shield其實也是一種解釋語言,雖然它僅僅是為了做安裝程序用的,但有很多人用它來編寫序列號的檢查部分,其實它的偽碼都是放在setup.ins中,而且我看到了這個偽碼的反編譯程序,看來以后用Install Shield做安裝程序的朋友們要小心了。

 

6、C:這種語言還是令人放心的,網絡上雖然有個叫做EXE to C的程序,但用過的人沒有不說上當的。

 

那么是不是用C語言編寫的程序就可以令人放心了呢?這個問題不是太好回答,主要看你程序的魅力有多大,如果你有一個能印制人民幣的程序給我,我兩個月就能搞出份源程序給你(一笑)。其實C語言的反編譯也不是不可能的,但需要反編譯者對照匯編程序一行行的寫出來,其工作量之巨大可想而知。而且現有的反匯編程序如IDA Pro、Sourcer等反匯編出來的程序沒有一個能夠直接編譯回去的,它反編譯的結果主要是給人看的,而不是給人用的。如果你真有一個印制人民幣的程序要編的話,我在這里給你提點建議:

 

1、千萬不能編制功能強大的子程序,如過你程序的一個子程序就能印錢的化,我就不需要看別的了。

2、多用全局變量,最好是全局的臨時變量,這個變量在每個子程序中的用法都不一樣,程序結構可能不太好,但能造成牽一發動全身的效果。

3、如果能用C++的化,盡量用C++來編程,最好把你的算法全用類來實現,哪怕是一個加法減法也給它定義個類,再從子類上面繼承繼承再繼承。

4、編譯后的程序不能小于500K.

Copyright © 2000-2003 德錡實業有限公司