Defender與底層操作系統(tǒng)緊密集成在一起，且它是專為在基于NT的Windows系統(tǒng)中運(yùn)行設(shè)計(jì)的。它可以在當(dāng)前所有基于NT的系統(tǒng)中運(yùn)行，包括Windows XP、Windows Server 2003、Windows 2000和Windows NT 4.0，但不能在非基于NT的操作系統(tǒng)中運(yùn)行，如Windows 98和Windows Me。
我們先運(yùn)行一下Defender.EXE程序，看看會發(fā)生什么事。需要指出的是，Defender是一個控制臺模式的應(yīng)用程序，所以通常它要在命令提示符（Command Prompt）窗口中運(yùn)行的。我之所將Defender設(shè)計(jì)成為一個控制臺模式的程序，是因?yàn)檫@大大簡化了Defender程序的編寫。當(dāng)然，我們也可以在普通的GUI應(yīng)用程序中創(chuàng)建一個同樣強(qiáng)大的保護(hù)，但寫代碼要花更長的時間。有一點(diǎn)需要指出的是，控制臺模式的應(yīng)用程序并不是DOS程序！基于NT的系統(tǒng)可以用NTVDM虛擬機(jī)運(yùn)行DOS程序，但對Defender程序不需要NTVDM虛擬機(jī)。像Defender這樣的控制臺程序是一般的32位Windows程序，它只是避開使用Windows GUI API函數(shù)（實(shí)際上它可以調(diào)用其他任何一個Win32 API函數(shù)），只使用簡單的文本窗口與用戶進(jìn)行通信。
你可以在命令提示符窗口中運(yùn)行Defender.EXE，并會收到Defender的使用方法的消息。圖11.10顯示了Defender的默認(rèn)使用方法的消息。


圖11.10 不帶命令行參數(shù)運(yùn)行Defender.EXE
Defender程序可以接收一個用戶名和一個16位的十六進(jìn)制序列號?，F(xiàn)在，我們給它輸入一些編造的值作為參數(shù)，看看會發(fā)生什么。圖11.11顯示了當(dāng)我們輸入用戶名為John Doe、序列號為1234567890ABCDEF后Defender的響應(yīng)。
毫無懸念——Defender只是簡單地報(bào)告我們的序列號是錯誤的。在做破解的時候，試試這個步驟是有必要的，至少你能看到程序在接收到錯誤的注冊信息會報(bào)告什么樣的錯誤消息。你應(yīng)該能夠在可執(zhí)行文件的某個地方找到這個錯誤消息。
我們將Defender.EXE加載到OllyDbg中看看。你要做的第一件事就是查看“Executable Modules”窗口以確定有哪些DLL靜態(tài)鏈接到了Defender。圖11.12顯示了Defender的“Executable Modules”窗口。


圖11.11 將用戶名John Doe和序列號12345678ABCDEF作為參數(shù)運(yùn)行Defender.EXE


圖11.12 （從OllyDbg中看）靜態(tài)鏈接到Defender的可執(zhí)行模塊


圖11.13 （從OllyDbg中看）Defender.EXE的導(dǎo)入與導(dǎo)出函數(shù)
這個列表非常短——只有NTDLL.DLL和KERNEL32.DLL兩項(xiàng)。記得我們前邊講的圖形用戶界面的crackme程序KeygenMe-3吧，它的可執(zhí)行模塊列表要比這個長很多，不過也難怪，Defender只是一個控制臺模式的應(yīng)用程序。我們接著看看“Names”窗口，確定一下Defender調(diào)用了哪些API函數(shù)。圖11.13顯示了Defender.EXE的“Names”窗口。
確實(shí)非常奇怪，看上去Defender.EXE只是從KERNEL32.DLL中調(diào)用了IsDebuggerPresent API函數(shù)。我們不需要太多推斷就可以得出這個不太可能是真的結(jié)論。除了調(diào)用IsDebuggerPresent外，程序一定得通過別的方式與操作系統(tǒng)進(jìn)行通信。比如說，如果沒有調(diào)用操作系統(tǒng)的函數(shù)，那么程序又是怎么在控制臺窗口上輸出信息的呢？這顯然是不可能的。我們再用DUMPBIN處理一下這個程序，看看Defender的導(dǎo)入表中有些什么。列表11.4顯示了用/IMPORTS選項(xiàng)的DUMPBIN的輸出。


列表11.4 用/IMPORTS選項(xiàng)對Defender.EXE運(yùn)行DUMPBIN的輸出


列表11.4
這兒也沒有什么新的發(fā)現(xiàn)。DUMPBIN的輸出也表明Defender.EXE只調(diào)用了IsDebuggerPresent。不過，這里還有個有趣的地方，那就是Summary段，DUMPBIN在這里列出該模塊的各個段。從這里我們發(fā)現(xiàn)Defender沒有.text段（通常PE可執(zhí)行文件中的代碼就放在.text段中）。相反，它有兩個奇怪的段：.h3mf85n和.h477w81。這并不是說程序中沒有任何代碼，這只是說明代碼很可能就躲在這兩個名字奇怪的段中。
在這個時候，聰明的做法是用/HEADERS選項(xiàng)再運(yùn)行一次DUMPBIN，來看看Defender是怎樣創(chuàng)建的（見列表11.5）。


列表11.5 用/HEADERS選項(xiàng)對Defender.EXE運(yùn)行DUMPBIN的輸出




















列表11.5
在/HEADERS選項(xiàng)條件下DUMPBIN為我們提供有關(guān)Defender.EXE程序的更多細(xì)節(jié)信息。例如，容易看出#1段（即.h3mf85n）就是代碼段。它被指定為Code，而且程序的入口點(diǎn)就在這里（入口點(diǎn)在404232，.h3mf85n從地址401000開始，到4042FF結(jié)束，所以我們知道入口點(diǎn)就在這個段內(nèi)）。另一個名字奇怪的段.h477w81看上去像是一個小型的數(shù)據(jù)段，可能包含一些變量。還需要提一下的是子系統(tǒng)標(biāo)志（subsystem flag）等于3，說明這是一個Windows控制臺用戶界面（console user interface，CUI）程序，Windows在運(yùn)行這個程序的時候會自動為它創(chuàng)建一個控制臺窗口。
所有這些奇怪的段名都說明了程序很可能是經(jīng)過了某種加殼處理（packed）。加殼程序能夠創(chuàng)建包含加殼后的代碼（packed code）或用于脫殼的代碼（unpacking code）的特殊段。有個不錯的方法——通過在PEiD中運(yùn)行程序來看它是否被一個未知的加殼程序做過加殼處理。PEiD程序可以識別常見的可執(zhí)行文件的特征碼（signatures），并顯示這個可執(zhí)行文件是否用流行的可執(zhí)行文件加殼程序或者拷貝保護(hù)產(chǎn)品做過加殼處理。你可以從下面這個網(wǎng)址下載PEiD：http://peid.has.it/。圖11.14顯示了PEiD處理Defender.EXE時的輸出。
不幸的是，PEiD報(bào)告“Nothing found”，所以可以有把握地說Defender沒有做過加殼處理，或者說是被一個未知的加殼程序做的加殼處理。我們接下來對這個程序進(jìn)行反匯編，找找“Sorry … Bad key, try again.”這條消息是從哪里來的。


圖11.14 用PEiD程序處理Defender.EXE時報(bào)告“Nothing found”

最新評論