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


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


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


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


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


列表11.4 用/IMPORTS選項對Defender.EXE運行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選項再運行一次DUMPBIN，來看看Defender是怎樣創(chuàng)建的（見列表11.5）。


列表11.5 用/HEADERS選項對Defender.EXE運行DUMPBIN的輸出




















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


圖11.14 用PEiD程序處理Defender.EXE時報告“Nothing found”