pe結(jié)構(gòu)參考模板

1、輸入表可執(zhí)行文件使用來(lái)自于其他DLL的代碼或數(shù)據(jù)時(shí)，稱為輸入。當(dāng)PE文件裝載時(shí)，Windows加載器的工作之一就是定位所有被輸入函數(shù)和數(shù)據(jù)，并且讓正在被裝載入的文件可以使用那些地址。這個(gè)過(guò)程通過(guò)PE文件的輸入表（Import Table）來(lái)完成的，輸入表中保存的是函數(shù)名和其駐留的DLL名等動(dòng)態(tài)鏈接所需要的信息，輸入表在軟件外殼技術(shù)上的地位非常重要，我這里會(huì)重點(diǎn)講解的！當(dāng)應(yīng)用程序調(diào)用一個(gè)DLL的代碼和數(shù)據(jù)時(shí)，那它正在隱含鏈接到DLL，這個(gè)過(guò)程完全由Windows加載器完成，另外一種是運(yùn)行期的顯示鏈接，這意味著必須確定目標(biāo)DLL已經(jīng)被加載，然后尋找API地址，這幾乎總是通過(guò)調(diào)用LoadLibrar

2、y和GetProcAddress來(lái)完成的。當(dāng)隱含地鏈接一個(gè)API 時(shí)，類似LoadLibrary和GetProcAddress的代碼始終在執(zhí)行，只不過(guò)這是Windows裝載器自動(dòng)完成的。裝載器還保證PE文件所需要的任何附加的DLL都已載入。在PE文件內(nèi)，有一組數(shù)據(jù)結(jié)構(gòu)，它們分別對(duì)應(yīng)著每個(gè)被輸入的DLL。每一個(gè)這樣結(jié)構(gòu)都給出了被輸入的DLL的名稱并指向一組函數(shù)指針。這組函數(shù)指針被稱為輸入地址表(Import Address Table)簡(jiǎn)稱IAT，每一個(gè)被引入的API在IAT里都有它自己保留的位置，在那里它將被Windows加載器寫(xiě)入輸入函數(shù)的地址，最后一點(diǎn)是特別重要的：一旦模塊被裝入，IAT中

3、包含所要調(diào)用輸入函數(shù)的地址。把所有輸入函數(shù)放在IAT中同一個(gè)地方是很有意義的，這樣無(wú)論代碼中多少次調(diào)用一個(gè)輸入函數(shù)，都會(huì)通過(guò)IAT中的同一個(gè)函數(shù)指針來(lái)完成。調(diào)用輸入表函數(shù)方法：高效：CALL DWORD PTR 00402010直接調(diào)用00402010中的函數(shù)，地址00402010h位于IAT里低效：CALL 00401164.:00401164 jmp dword ptr 00402010這種情況，CALL把控制權(quán)轉(zhuǎn)到一個(gè)子程序，子程序中的JMP指令跳轉(zhuǎn)到位于IAT中的00402010h。簡(jiǎn)單的說(shuō)它使用5個(gè)字節(jié)的額外代碼，并且由額外的JMP將花費(fèi)更多的時(shí)間去執(zhí)行。為什么要使用這種低效的方法？

4、因?yàn)榫幾g器無(wú)法區(qū)別輸入函數(shù)的調(diào)用與普通函數(shù)調(diào)用，對(duì)于每一個(gè)函數(shù)調(diào)用，編譯器使用同樣形式的CALL指令：CALL XXXXXXXXXXXXXXXX是一個(gè)由鏈接器填充的實(shí)際的地址。注意指令不是從函數(shù)指針而是代碼中實(shí)際地址而來(lái)的，為了因果平衡，鏈接器必須表示產(chǎn)生一塊代碼來(lái)取代XXXXXXXX，簡(jiǎn)單位的方法是像上面那樣調(diào)用一個(gè)JMP Stub。我們可以通過(guò)使用修飾來(lái)優(yōu)化我們的低效調(diào)用方式，可以用修飾函數(shù)的_declspec(dllimport)來(lái)告訴編譯器，這個(gè)函數(shù)來(lái)自另一個(gè)DLL中，這樣編譯器就會(huì)產(chǎn)生這樣的指令：CALL DWORD PTR XXXXXXXX而不是CALL XXXXXXXX，編譯器將

5、給函數(shù)加上_imp_前綴，然后直接送給鏈接器，這樣可以直接把_imp_xxx送到IAT，就不需要JMP Stub了。下面簡(jiǎn)單分析一個(gè)實(shí)例，看看是怎么回事？程序被執(zhí)行的時(shí)候是怎樣使用導(dǎo)入函數(shù)的呢？先寫(xiě)個(gè)簡(jiǎn)單的Hello World程序反匯編一把，看看調(diào)用導(dǎo)入函數(shù)的指令都是什么樣子的，需要反匯編的兩句源代碼如下(呵呵，這個(gè)代碼我就不寫(xiě)了）： invoke MessageBox,NULL,offset szText,offset szCaption,MB_OK invoke ExitProcess,NULL當(dāng)使用W32Dasm反匯編以后，這兩句代碼變成了以下的指令，如圖所示：1 / 10反匯編后，對(duì)

6、MessageBox和ExitProcess函數(shù)的調(diào)用變成了對(duì)0040101A和00401020地址的調(diào)用，但是這兩個(gè)地址顯然是位于程序自身模塊而不是在DLL模塊中的，實(shí)際上，這是由編譯器在程序所有代碼的后面自動(dòng)加上的Jmp dword ptr xxxxxxxx類型的指令，這個(gè)指令是一個(gè)間接尋址的跳轉(zhuǎn)指令，xxxxxxxx地址中存放的才是真正的導(dǎo)入函數(shù)的地址。在這個(gè)例子中，00402000地址處存放的就是ExitProcess函數(shù)的地址。那么在沒(méi)有裝載到內(nèi)存之前，PE文件中的00402000地址處的內(nèi)容是什么呢？用PEID工具查得結(jié)果如圖所示由于鏡像基址為00400000h,所以0040200

7、0h地址實(shí)際上處于RVA為2000h的地方，再看看各個(gè)節(jié)的虛擬地址，可以發(fā)現(xiàn)2000h開(kāi)始的地方位于.rdata節(jié)內(nèi)，而這個(gè)節(jié)的Raw_偏移項(xiàng)目為600h,也就是說(shuō)00402000h地址內(nèi)容實(shí)際上對(duì)應(yīng)PE文件偏移600h處的數(shù)據(jù)。我們就看看文件0600h處的內(nèi)容是什么？用UE打開(kāi)程序，如圖所示：查看的結(jié)果是00002076h，這顯然不會(huì)是內(nèi)存中的ExitProcess函數(shù)的地址，慢著！將它作為RVA看會(huì)怎么樣呢？查看節(jié)表可以發(fā)現(xiàn)RVA地址00002076h也處于.rdata節(jié)內(nèi)，減去節(jié)的起始地址00002000h后得到這個(gè)RVA相對(duì)于節(jié)首的偏移是76h，也就是說(shuō)它對(duì)應(yīng)文件0676h開(kāi)始的地方，

8、接下來(lái)可以驚奇地發(fā)現(xiàn)，0676h再過(guò)去兩個(gè)字節(jié)的內(nèi)容正是函數(shù)名字符串“ExitProcess”！這都有點(diǎn)搞糊涂了，Call ExitProcess指令被編譯成了Call aaaaaaaa類型的指令，而aaaaaaaa處的指令是Jmp dword ptr xxxxxxxx，而xxxxxxxx地址的地方只是一個(gè)似乎是指向函數(shù)名字符串的RVA地址，這一系列的指令顯然是無(wú)法正確執(zhí)行的！但如果告訴你，當(dāng)PE文件被裝載的時(shí)候，Windows裝載器會(huì)根據(jù)xxxxxxxx處的RVA得到函數(shù)名，再根據(jù)函數(shù)名在內(nèi)存中找到函數(shù)地址，并且用函數(shù)地址將xxxxxxxx處的內(nèi)容替換成真正的函數(shù)地址，那么所有的疑惑就迎刃而

9、解了。呵呵，這樣講解之后，你對(duì)輸入表是否有的更新的認(rèn)識(shí)呢？怎樣獲取輸入表呢？導(dǎo)入表的位置和大小可以從PE文件頭中IMAGE_OPTIONAL_HEADER32結(jié)構(gòu)的數(shù)據(jù)目錄字段中獲取，對(duì)應(yīng)的項(xiàng)目是DataDirectory字段的第2個(gè)IMAGE_DATA_DIRECTORY結(jié)構(gòu)從IMAGE_DATA_DIRECTORY結(jié)構(gòu)的VirtualAddress字段得到的是導(dǎo)入表的RVA值，如果在內(nèi)存中查找導(dǎo)入表，那么將RVA值加上PE文件裝入的基址就是實(shí)際的地址；如果在PE文件中查找導(dǎo)入表，需要將RVA轉(zhuǎn)換成File Offset。導(dǎo)入表由一系列的IMAGE_IMPORT_DESCRIPTOR結(jié)構(gòu)組成

10、，結(jié)構(gòu)的數(shù)量取決于程序要使用的DLL文件的數(shù)量，每個(gè)結(jié)構(gòu)對(duì)應(yīng)一個(gè)DLL文件，例如，如果一個(gè)PE文件從10個(gè)不同的DLL文件中引入了函數(shù)，那么就存在10個(gè)IMAGE_IMPORT_DESCRIPTOR結(jié)構(gòu)來(lái)描述這些DLL文件，在所有這些結(jié)構(gòu)的最后，由一個(gè)內(nèi)容全為0的IMAGE_IMPORT_DESCRIPTOR結(jié)構(gòu)作為結(jié)束。每個(gè)被PE文件隱式地鏈接進(jìn)來(lái)的DLL都有一個(gè)IID。在這個(gè)數(shù)組中，沒(méi)有字段指出該結(jié)構(gòu)數(shù)組的項(xiàng)數(shù)，但它的最后一個(gè)單元是NULL，可以由此計(jì)算出該數(shù)組的項(xiàng)數(shù)。IMAGE_IMPORT_DESCRIPTOR STRUCT union Characteristics dd ? Ori

11、ginalFirstThunk dd ? ends TimeDateStamp dd ? ForwarderChain dd ? Name1 dd ? FirstThunk dd ?IMAGE_IMPORT_DESCRIPTOR ENDS結(jié)構(gòu)中的Name1字段（使用Name1作為字段名同樣是因?yàn)镹ame一詞和MASM的關(guān)鍵字沖突）是一個(gè)RVA，它指向此結(jié)構(gòu)所對(duì)應(yīng)的DLL文件的名稱，這個(gè)文件名是一個(gè)以NULL結(jié)尾的字符串。OriginalFirstThunk字段和FirstThunk字段的含義現(xiàn)在可以看成是相同的（使用“現(xiàn)在”一詞的含義馬上會(huì)見(jiàn)分曉），它們都指向一個(gè)包含一系列IMAGE_THUN

12、K_DATA結(jié)構(gòu)的數(shù)組，數(shù)組中的每個(gè)IMAGE_THUNK_DATA結(jié)構(gòu)定義了一個(gè)導(dǎo)入函數(shù)的信息，數(shù)組的最后以一個(gè)內(nèi)容為0的IMAGE_THUNK_DATA結(jié)構(gòu)作為結(jié)束。一個(gè)IMAGE_THUNK_DATA結(jié)構(gòu)實(shí)際上就是一個(gè)雙字，之所以把它定義成結(jié)構(gòu)，是因?yàn)樗诓煌臅r(shí)刻有不同的含義，結(jié)構(gòu)的定義如下：IMAGE_THUNK_DATA STRUCT union u1 ForwarderString dd ? Function dd ? Ordinal dd ? AddressOfData dd ? endsIMAGE_THUNK_DATA ENDS一個(gè)IMAGE_THUNK_DATA結(jié)構(gòu)如何用來(lái)

13、指定一個(gè)導(dǎo)入函數(shù)呢？當(dāng)雙字（就是指結(jié)構(gòu)！）的最高位為1時(shí)，表示函數(shù)是以序號(hào)的方式導(dǎo)入的，這時(shí)雙字的低位就是函數(shù)的序號(hào)。讀者可以用預(yù)定義值IMAGE_ORDINAL_FLAG32（或80000000h）來(lái)對(duì)最高位進(jìn)行測(cè)試，當(dāng)雙字的最高位為0時(shí)，表示函數(shù)以字符串類型的函數(shù)名方式導(dǎo)入，這時(shí)雙字的值是一個(gè)RVA，指向一個(gè)用來(lái)定義導(dǎo)入函數(shù)名稱的IMAGE_IMPORT_BY_NAME結(jié)構(gòu)，此結(jié)構(gòu)的定義如下：IMAGE_IMPORT_BY_NAME STRUCT Hint dw ? Name1 db ?IMAGE_IMPORT_BY_NAME ENDS結(jié)構(gòu)中的Hint字段也表示函數(shù)的序號(hào)，不過(guò)這個(gè)字段是可

14、選的，有些編譯器總是將它設(shè)置為0，Name1字段定義了導(dǎo)入函數(shù)的名稱字符串，這是一個(gè)以0為結(jié)尾的字符串。整個(gè)過(guò)程聽(tīng)起來(lái)很復(fù)雜，其實(shí)看下面的圖示，可執(zhí)行文件導(dǎo)入了Kernel32.dll中的ExitProcess,ReadFile,WriteFile和lstcmp函數(shù)的情況，其中，前面3個(gè)函數(shù)按照名稱方式導(dǎo)入，最后lstrcmp函數(shù)按照序號(hào)導(dǎo)入，這四個(gè)函數(shù)分別是02f6h,0111h,002bh和0010h。導(dǎo)入表中IMAGE_IMPORT_DESCRIPTOR結(jié)構(gòu)的Name1字段指向字符串“Kernel32.dll”，表明當(dāng)前要從Kernel32.dll文件中導(dǎo)入函數(shù)，OriginalFirs

15、tThunk和FirstThunk字段指向兩個(gè)同樣的IMAGE_THUNK_DATA數(shù)組，由于要導(dǎo)入的是4個(gè)函數(shù)，所以數(shù)組中包含4個(gè)有效項(xiàng)目并以最后一個(gè)內(nèi)容為0的項(xiàng)目作為結(jié)束。第4個(gè)函數(shù)lstrcmp函數(shù)是以序號(hào)導(dǎo)入的，與其對(duì)應(yīng)的IMAGE_THUNK_DATA結(jié)構(gòu)的最高位等于1，和函數(shù)的序號(hào)0010h組合起來(lái)的數(shù)值就是80000010h，其余的3個(gè)函數(shù)采用的是以函數(shù)名導(dǎo)入的方式，所以IMAGE_THUNK_DATA結(jié)構(gòu)的數(shù)值是一個(gè)RVA，分別指向3個(gè)IMAGE_IMPORT_BY_NAME結(jié)構(gòu)，每個(gè)IMAGE_IMPORT_BY_NAME結(jié)構(gòu)的第一個(gè)字段是函數(shù)的序號(hào)，后面就是函數(shù)的字符串名稱

16、了，一切就是這么簡(jiǎn)單！這里有個(gè)問(wèn)題：為什么要用兩個(gè)并行的指針數(shù)組指向IMAGE_IMPORT_BY_NAME結(jié)構(gòu)呢？答安：當(dāng)PE文件被裝入內(nèi)存的時(shí)候，其中一個(gè)數(shù)組的值將被改作他用，還記得前面分析Hello World程序時(shí)提到的，Windows裝載器會(huì)將指令JMP DWORD PTR XXXXXXXX指定的XXXXXXXX處的RVA替換成真正的函數(shù)地址，其實(shí)XXXXXXXX地址正是由FirstThunk字段指向的那個(gè)數(shù)組中的一員。實(shí)際上，當(dāng)PE文件被裝載入內(nèi)存后，內(nèi)存中的映像就被Windows裝載器修正成了如下圖所示的樣子，其中由FirstThunk字段指向的那個(gè)數(shù)組中的每個(gè)雙字都被替換成了真

17、正的函數(shù)入口地址，之所以在PE文件中使用兩份IMAGE_THUNK_DATA數(shù)組的拷貝并修改其中的一份，是為了最后還可以留下一份拷貝用來(lái)反過(guò)來(lái)查詢地址所對(duì)應(yīng)的導(dǎo)入函數(shù)名。輸入表實(shí)例分析這里我就用老羅書(shū)上的那個(gè)FirstWindows作為實(shí)例進(jìn)行分析，因?yàn)榭囱┥夏莻€(gè)PE.EXE被我的360刪了，我也不知道，不管了，反正也要重新分析一遍，這樣更加深記憶！數(shù)據(jù)目錄表第二成員指向輸入表，該指針具體位置在PE文件頭的80h偏移處。該文件的PE文件頭起始位置是C0h,輸入表地址就是整個(gè)文件的C0h+80h=140h處，因此在140h處可以發(fā)現(xiàn)四字節(jié)指針90200000，倒過(guò)來(lái)是00002090，即輸入表在

18、內(nèi)存中偏移量是為2090h的地方，當(dāng)然，這個(gè)2090h是RVA值，需要將其轉(zhuǎn)換為磁盤(pán)文件的絕對(duì)偏移量，才能夠在十六進(jìn)制編輯器中找到輸入表。具體如下圖所示：大家可以通過(guò)計(jì)算來(lái)實(shí)現(xiàn)RVA到File Offset的轉(zhuǎn)換，這里我了節(jié)省篇幅，我就直接用LoadPE來(lái)計(jì)算了，如圖所示，我們要計(jì)算的RVA地址為00002090h，得到File Offset的地址為690h,如下圖所示：得到文件偏移地址之后，我們用UE打開(kāi)FirstWindow程序，跳到偏移為690h處，這里就是輸入表的內(nèi)容，每個(gè)IID包含5個(gè)雙字，用來(lái)描述一個(gè)引入的DLL文件，最后以NULL結(jié)束。如圖所示：將圖中所列的輸入表的IID數(shù)組整理

19、到下面的表中。每個(gè)IID包含了一個(gè)DLL的描述信息，現(xiàn)在有兩個(gè)IID，因此這里引入了兩個(gè)DLL，第三個(gè)IID全為0，作為結(jié)束標(biāo)志。每個(gè)IID中的第四個(gè)字段是指向DLL名稱的指針，這里第一個(gè)IID中的第四個(gè)字段是0E220000，翻轉(zhuǎn)過(guò)來(lái)也就是RVA地址0000220Eh，用上面的方法轉(zhuǎn)換得到File Offset為80Eh,還有下面那個(gè)IID中的第四個(gè)字段也是指向DLL名稱的指，RVA地址為0000224Ch,轉(zhuǎn)換得到File Offset為84Ch,這樣我們就得到輸入表中所使用的兩個(gè)DLL的名稱，所圖所示：由上圖可知EXE文件中偏移量為80Eh處的字符是user32.dll,84Ch處的字符

20、是kernel32.dll，所以此程序調(diào)用了兩個(gè)DLL。上面的表格轉(zhuǎn)換成RVA地址，如下所示：再查找USER32.dll中被調(diào)用的函數(shù)，在第一個(gè)IID中，查看第一個(gè)字段OrignalFirstThunk，它指向一個(gè)數(shù)據(jù)，這個(gè)數(shù)組的元素都是指針，分別指向引入函數(shù)名的ASCII字符串。有些程序的OriginalFirstThunk的值為0，所以這時(shí)就要看FirstThunk，它在程序運(yùn)行時(shí)初始化。這時(shí)我就分析一個(gè)IID，第二個(gè)IID留著讀者自己去分析！USER32.DLL這個(gè)IID結(jié)構(gòu)中的OriginalFirstThunk的字段的值為000020DC，轉(zhuǎn)化為File Offset為：6DC，所以

21、在偏移6DCh處就是IMAGE_THUNK_DATA數(shù)組，它存儲(chǔ)的是指向IMAGE_IMPORT_BY_NAME結(jié)構(gòu)的地址，以一串00結(jié)束。可得到如下表所示的IMAGE_THUNK_DATA的數(shù)組。具體的位置如下圖所示：再來(lái)看看同一個(gè)IID結(jié)構(gòu)中FirstThunk情況，USER32.dll所在IID的FirstThunk字段值是2010h,然后轉(zhuǎn)換得到File Offset為610h，在偏移610h處就是IMAGE_THUNK_DATA數(shù)組，其數(shù)據(jù)與OrignalFirstThunk字段所指的完全一樣，如下圖所示：通常一個(gè)完整的程序就這些，現(xiàn)在有15個(gè)IMAGE_THUNK_DATA，表示有

22、15個(gè)函數(shù)調(diào)用，先選擇一個(gè)分析一下：4E210000翻轉(zhuǎn)后為0000214E，然后轉(zhuǎn)換為File Offset為74Eh，會(huì)發(fā)現(xiàn)在偏移74Eh處的字符串為DestroyWindow。你也許注意到了，計(jì)算出來(lái)的偏移量并不剛好指向函數(shù)名的ASCII字符串，而是前面還有兩個(gè)字節(jié)的空缺，這是作為函數(shù)名(Hint)引用的，可以為0。第一個(gè)IID指向的API函數(shù)表如下：如上圖是FirstWindow文件運(yùn)行前第一個(gè)IID的結(jié)構(gòu)示意圖，在程序運(yùn)行前，它的FirstThunk字段值是指向一個(gè)地址串，而且和OrignalFirstThunk字段值指向的INT是重復(fù)的，系統(tǒng)在程序初始化時(shí)根據(jù)OrignalFirs

23、tThunk的值找到函數(shù)名，調(diào)用GetProcAddress函數(shù)（或類似功能的系統(tǒng)代碼）且根據(jù)函數(shù)名取得函數(shù)的入口地址，然后用函數(shù)入口地址取代FirstThunk指向的地址串中對(duì)應(yīng)的值(IAT)。其內(nèi)部結(jié)構(gòu)如下圖所示，圖片來(lái)源加密與解密第三版下面利用加密與解密第三版上的實(shí)例dumped.exe講解PE文件映射到內(nèi)存的狀態(tài)，找開(kāi)映象文件，由于在內(nèi)存中區(qū)塊的對(duì)齊值與內(nèi)存頁(yè)相同，因此此時(shí)其文件偏移地址與相對(duì)虛擬地址（RVA）的值相等。輸入表的RVA地址是2040h，具體見(jiàn)下圖：由于00002040處的值為8C200000，翻轉(zhuǎn)為0000208C，再看208C處的IMAGE_THUNK_DATA和值為沒(méi)有映射到內(nèi)存中的是一樣的，但是FirstThunk的值為2010h,，該處指向的輸入表IAT，將這張表與沒(méi)有映射之前的比較，可以發(fā)現(xiàn)完全不同了。具體情況如下圖所示：內(nèi)存中第一個(gè)IID結(jié)構(gòu)的輸入地址表（IAT）表中各地址都是USER32.dl鏈連庫(kù)的相關(guān)輸出函數(shù)，反匯編USER3