使用ollydbg從零開始cracking第三十四章

第三十四章-手脫UPX,我們在上一章中給大家介紹了T導(dǎo)入表T輸入函數(shù)地址表,我們只是想修復(fù)T呀,并不需要知道T的具體原理以及它是如何被填充的吧?不是有現(xiàn)成的T自動修復(fù)工具嗎?可以很明確的告訴大家,了解操作系統(tǒng)是如何填充T的過程非常有必要的。因?yàn)楹芏鄽z測這些常用的T修復(fù)工具,致其不能正常運(yùn)行,在這種情況下,我們就需要自己進(jìn)行相應(yīng)的手工修復(fù)。本章我們還是用最簡單的CRACKMEUPX作為例子,對其進(jìn)行脫殼以及修復(fù)IAT,讓其能正常運(yùn)行。首先第一步我們來定位OEP,我們用OD加載CRACKMEUPX。這里我們用ESP定律來定位OEP,現(xiàn)在我們停在了點(diǎn)處,單擊F7鍵執(zhí)行PUSHAD在ESP寄存器值上面單擊鼠標(biāo)右鍵選擇-FollowinDump就可以在數(shù)據(jù)窗口中定位到剛剛PUSHAD指令保存到堆棧中的寄存器環(huán)境了,我們選中前4個字節(jié),我們通過單擊鼠標(biāo)右鍵選Breakpoint-Hardware,onaccess-Dword給這4個字節(jié)設(shè)置硬件斷點(diǎn)運(yùn)行起來,馬上就斷在了JMPOEP指令處我們直接按F7鍵單步到OEP處好了,現(xiàn)在我們處于OEP處,原程序區(qū)段已經(jīng)完畢,我們現(xiàn)在可以進(jìn)行dump了前面已經(jīng)提到過,有很多dump的工具,OD有一個款插件OllyDumpdump效果也不錯。上一章中我們使用LordPE來進(jìn)行,這里我們來使用另外一個工具PETOOLS來進(jìn)行dump。我們用PE-TOOLS定位到CRACKMEUPX所在的進(jìn)程。這里這個crackmeexe就是,因?yàn)槲彝税涯莻€重命名的CRACKMEUPX放到哪里去了,所以我又重新弄了一個新的,忘了改名字,直接命名為原來的名字crackmeexe了,當(dāng)前這個crackmeexe進(jìn)程停在了OEP處。單擊鼠標(biāo)右鍵選擇-DumpFull這里,我們就dump完畢了,接下來我們來修復(fù)IAT,關(guān)閉PETOOLS,將PETOOLS 下的dumpedexe拷貝一份到CRACKMEUPX所在的 我們知道沒有修復(fù)IAT,是不能運(yùn)行的,我們雙擊Dumpedexe看看會發(fā)生什么提示無效的win32程序,我們需要修復(fù)IAT,我們需要用到一個工具,名字叫做ImportREConstructor,不要關(guān)閉OD,將讓其斷在處,ImportREConstructor需要用到它運(yùn)行ImportREConstructor,定位到CRACKMEUPX所在的進(jìn)程這里很多初學(xué)者可能會有疑問如何定位T的起始位置和結(jié)束位置呢?我們知道當(dāng)前該CRCMEPX進(jìn)程停在了EP處,此時殼已經(jīng)將導(dǎo)入表破壞了,我們知道ID項(xiàng)的第段為動態(tài)庫名稱字符串的指針,第五個字段為其對應(yīng)T項(xiàng)第一個元素的地址,這些已經(jīng)被殼破壞了,我們需要通過其他方式來定位。我們知道API函數(shù)的調(diào)用通常是通過間接跳轉(zhuǎn)或者間接CALL來實(shí)現(xiàn)的。JMP[XXXXXXX]orCALL上一章我們已經(jīng)介紹過了,這樣是直接調(diào)用IAT中保存的API函數(shù)地址。我們來看看CRACKMEUPX這里我們看到第二CALL指令,OD提示調(diào)用的是Kernel32dll中的GetModuleHandleA,是個間接跳轉(zhuǎn),我們選中這一行,單擊這里我們定IAT中函數(shù)地址的跳轉(zhuǎn)表,這里就是該程序?qū)⒁{(diào)用到的一些API函數(shù),我們可以看到這些跳轉(zhuǎn)指令的都是以機(jī)器碼FF25開頭的,有些里面說直接搜索二進(jìn)制FF25就可以快速的定位該跳表。其實(shí),并不是所有的程序都通過這種間接跳轉(zhuǎn)來調(diào)用API函數(shù),所以直接搜索FF25這種方法有時候會失敗,而通過定位某個函數(shù)的調(diào)用處,然后Follow到跳表是這種方式才是一直有效的。這里我們看到JMP[403238]:403238是IAT的其中一個元素,里面保存的是GetModuleHandleA這個API函數(shù)的地址,我們dump出來的程序的IAT部分跟這里是一樣的,我們來看看IAT的起始位置和結(jié)束位置分別在哪兒。其實(shí),大家可以通過跳轉(zhuǎn)表中最小的地址和最大的地址算出T的起始位置和結(jié)束位置,但是比較慢,比較好的做法是,直接將數(shù)據(jù)窗口往上滾動,我們知道T的每個元素中都保存了一個AI函數(shù)的地址,比如這里的7C80B529,在數(shù)據(jù)窗口中顯示的形式為29B5807C(小端,顯示列數(shù)調(diào)整為兩列,這樣看起來更方便一些。這里我們看到的就是整個IAT了,我們直接下拉到IAT的尾部,我們知道屬于同一個動態(tài)庫的API函數(shù)地址都是連續(xù)存放的,不同有一些殼會將這部分全部填零,使得我們的IAT重建工作變得異常,這里由于原程序還需要調(diào)用這些API函數(shù),所以該殼沒有將這部分填零,我們現(xiàn)在來看看其中一個動態(tài)庫的IAT項(xiàng),如下:這里顯示了該DLL中的三個API函數(shù),地址都是7CXXXXXX的形式,然后緊接著是一個零。我們單擊中的M按鈕看看7C開頭的地址是屬于哪個DLL的。我們可以看到這幾個地址處于kernel32dll的代碼段范圍內(nèi)當(dāng)然在的機(jī)器上kernel32dll可能在別的地址處,但在我的機(jī)器上,這幾個函數(shù)地址是屬于kernel32dll的屬于kernel32dll中的函數(shù)地址這里我用粉紅色標(biāo)注出來了,我們再來看看77DXXXXX這類地址是屬于哪個DLL的這里我們可以看到77DXXXXX這類地址是屬于user32dll的,我也用粉紅色標(biāo)注出來了我們可以看到user32dll的這些函數(shù)地址項(xiàng)上面是全零的,表示IAT的起始地址為403184,403184中存放的了IAT中的第一個元這里我們用紅線標(biāo)注出來了,40314是T的起始地址。有些強(qiáng)殼可能會將T前后都填充上數(shù)據(jù),讓我們定位T的起始位置和結(jié)束位置更加。但是我們知道T中的數(shù)值都是屬于某個動態(tài)庫代碼段范圍內(nèi)的,如果我們發(fā)現(xiàn)某數(shù)值不屬于任何一個動態(tài)庫的代碼段的話,就說明該數(shù)值是數(shù)據(jù)。現(xiàn)在我們知道了IAT開始于403184,我們現(xiàn)在來看一看IAT的結(jié)束位置在哪里后面我們會遇到有些殼會將IAT重定向到殼的例程中去,然后再跳轉(zhuǎn)到API函數(shù)的處,這樣的話,上面這樣定位IAT的起始和這里我們可以看到IAT的最后一個元素的地址形式為76XXXXXX,我們來看看它是屬于哪個DLL的這里我們可以看到其是屬于COMDLG32DLL的,后面全是零了,所以40328CIAT的結(jié)束位置。好了,現(xiàn)在我們知道了IAT的起始位置和結(jié)束位置。ImportREConstructor重建IAT需要三項(xiàng)指標(biāo)IAT的起始地址,這里是403184,減去映像基址400000就得到了3184(RVA:相對虛擬地址)IAT的大IAT的大小40328C403184108(十六進(jìn)制3)OEP401000(虛擬地址)-映像基址4000001000(OEPRVA)這三條數(shù)據(jù)輸入到ImportREConstructor中我們單擊GetImports我們看到potREContutor找到了T中的每項(xiàng)元素,并且valid顯示的都是E,表示這些項(xiàng)都是有效的,那么無效的是什么情況呢,有些殼會將這些值進(jìn)行重定向,并不是直接調(diào)用AI函數(shù),就會導(dǎo)致IpotREContuctor定位出來的項(xiàng)都是無效的,好了現(xiàn)在這些項(xiàng)都是有效的,我們就可以進(jìn)行dup了。在dump之前我們先來看看User32dll這個項(xiàng)中內(nèi)容是什么,選中該項(xiàng),單擊左邊的+號就可以展開好了,我們可以看到每個I函數(shù)名稱字符串的指針都顯示出來了,該程序調(diào)用的第一個I函數(shù)etModuleadleA這一項(xiàng)在哪里呢?大家應(yīng)該還記得,IAT的中的第一項(xiàng)值為403238,減去映像基址400000就等于3238,位于kernel32dll中我們單擊kernel32dll這一項(xiàng)左邊的+號可以看到3238對應(yīng)的正好是GetModuleHandleA好了,現(xiàn)在我們就可以對之前dump出來的程序的IAT進(jìn)行修復(fù)了,我們FixDump按鈕。選中之前dump出來的文件我們可以看到修復(fù)完畢了,修復(fù)過的文件被重命名為了dumped_exe。我們來看一看我們雙擊它,看看能不能正常運(yùn)行我們可以看到還是提示無效的win32程序,嘿嘿,為什么呢?別擔(dān)心,通常修復(fù)了IAT以后,都會出現(xiàn)這種狀況。我們現(xiàn)在來打開PE我們選擇菜單項(xiàng)中的RebuildPE(重建PE),我們找到剛剛的dumped_exe,重建之,運(yùn)行,發(fā)現(xiàn)可以正常運(yùn)行了,嘿嘿大家將這個程序拿到其它機(jī)器上運(yùn)行也是沒有問題的dumped_exe加載到OD中。這里OD提示點(diǎn)位于代碼段之外,因?yàn)閁PX殼將代碼段指定到了第三個區(qū)段。這個問題可以修復(fù)。我們下面來修復(fù)它我們單擊OK,停在了點(diǎn)處,我們在數(shù)據(jù)窗口中定位到400000地址處將數(shù)據(jù)窗口的顯示模式切換為PE頭模式往下拉可以看到PE頭的相對虛擬地址(RVA)為80,即虛擬地址(VA)為400080這里我們看到BaseofCode=9000,表示代碼段的相對虛擬地址為9000,我們需要將代碼段的相對虛擬地址修改為1000我們選中BaseOfCode這一行,單擊鼠標(biāo)右鍵選擇-Modifyinteger修改完畢以后所做的修改保存到文件我們再次加載修復(fù)過的程序,可以看到OD沒有彈出警告窗口了。我們單擊中M按鈕看看各個區(qū)段的描述信息我們可以看到這里多出了一個區(qū)段,名字mackt,這是ImportREConstructor給該程序添加的一個新的區(qū)段,專門用來存放新的導(dǎo)入表。我們在數(shù)據(jù)窗口中看一看導(dǎo)入表的情況(PE頭顯示模式)。我們可以看到導(dǎo)入表的相對虛擬地址為B000,即虛擬地址為40B000,剛好ImportREConstructor添加的那個區(qū)段。我們在數(shù)據(jù)窗口中定位到導(dǎo)入表40B000地址處這里我們可以看到第一個IID,第段為DLL名稱字符串的指針,這里是B078(RVA),即40B078(VA)指向的是user32dll第五個字段DLLIAT項(xiàng)的起始地址的RVA,這里是3184,IAT中的第一個元素的地址為403184這里我們可以看到IAT中保存的各個API函數(shù)的地址。我們定位到可執(zhí)行文件中對應(yīng)IAT的偏移處,看看各個API