【转】PE文件结构详解--（完整版）
（一）基本概念
PE（Portable Execute）文件是Windows下可執(zhí)行文件的總稱，常見的有DLL，EXE，OCX，SYS等，事實(shí)上，一個(gè)文件是否是PE文件與其擴(kuò)展名無關(guān)，PE文件可以是任何擴(kuò)展名。那Windows是怎么區(qū)分可執(zhí)行文件和非可執(zhí)行文件的呢？我們調(diào)用LoadLibrary傳遞了一個(gè)文件名，系統(tǒng)是如何判斷這個(gè)文件是一個(gè)合法的動態(tài)庫呢？這就涉及到PE文件結(jié)構(gòu)了。
PE文件的結(jié)構(gòu)一般來說如下圖所示：從起始位置開始依次是DOS頭，NT頭，節(jié)表以及具體的節(jié)。
DOS頭是用來兼容MS-DOS操作系統(tǒng)的，目的是當(dāng)這個(gè)文件在MS-DOS上運(yùn)行時(shí)提示一段文字，大部分情況下是：This program cannot be run in DOS mode.還有一個(gè)目的，就是指明NT頭在文件中的位置。
NT頭包含windows PE文件的主要信息，其中包括一個(gè)‘PE’字樣的簽名，PE文件頭（IMAGE_FILE_HEADER）和PE可選頭（IMAGE_OPTIONAL_HEADER32），頭部的詳細(xì)結(jié)構(gòu)以及其具體意義在PE文件頭文章中詳細(xì)描述。
節(jié)表：是PE文件后續(xù)節(jié)的描述，windows根據(jù)節(jié)表的描述加載每個(gè)節(jié)。
節(jié)：每個(gè)節(jié)實(shí)際上是一個(gè)容器，可以包含代碼、數(shù)據(jù)等等，每個(gè)節(jié)可以有獨(dú)立的內(nèi)存權(quán)限，比如代碼節(jié)默認(rèn)有讀/執(zhí)行權(quán)限，節(jié)的名字和數(shù)量可以自己定義，未必是上圖中的三個(gè)。
當(dāng)一個(gè)PE文件被加載到內(nèi)存中以后，我們稱之為“映象”（image），一般來說，PE文件在硬盤上和在內(nèi)存里是不完全一樣的，被加載到內(nèi)存以后其占用的虛擬地址空間要比在硬盤上占用的空間大一些，這是因?yàn)楦鱾€(gè)節(jié)在硬盤上是連續(xù)的，而在內(nèi)存中是按頁對齊的，所以加載到內(nèi)存以后節(jié)之間會出現(xiàn)一些“空洞”。
因?yàn)榇嬖谶@種對齊，所以在PE結(jié)構(gòu)內(nèi)部，表示某個(gè)位置的地址采用了兩種方式，針對在硬盤上存儲文件中的地址，稱為原始存儲地址或物理地址表示距離文件頭的偏移；另外一種是針對加載到內(nèi)存以后映象中的地址，稱為相對虛擬地址（RVA），表示相對內(nèi)存映象頭的偏移。
然而CPU的某些指令是需要使用絕對地址的，比如取全局變量的地址，傳遞函數(shù)的地址編譯以后的匯編指令中肯定需要用到絕對地址而不是相對映象頭的偏移，因此PE文件會建議操作系統(tǒng)將其加載到某個(gè)內(nèi)存地址（這個(gè)叫基地址），編譯器便根據(jù)這個(gè)地址求出代碼中一些全局變量和函數(shù)的地址，并將這些地址用到對應(yīng)的指令中。例如在IDA里看上去是這個(gè)樣子：
這種表示方式叫做虛擬地址（VA）。
也許有人要問，既然有VA這么簡單的表示方式為什么還要有前面的RVA呢？因?yàn)殡m然PE文件為自己指定加載的基地址，但是windows有茫茫多的DLL，而且每個(gè)軟件也有自己的DLL，如果指定的地址已經(jīng)被別的DLL占了怎么辦？如果PE文件無法加載到預(yù)期的地址，那么系統(tǒng)會幫他重新選擇一個(gè)合適的基地址將他加載到此處，這時(shí)原有的VA就全部失效了，NT頭保存了PE文件加載所需的信息，在不知道PE會加載到哪個(gè)基地址之前，VA是無效的，所以在PE文件頭中大部分是使用RVA來表示地址的，而在代碼中是用VA表示全局變量和函數(shù)地址的。那又有人要問了，既然加載基址變了以后VA都失效了，那存在于代碼中的那些VA怎么辦呢？答案是：重定位。系統(tǒng)有自己的辦法修正這些值，到后續(xù)重定位表的文章中會詳細(xì)描述。既然有重定位，為什么NT頭不能依靠重定位采用VA表示地址呢（十萬個(gè)為什么）？因?yàn)椴皇撬械腜E都有重定位，早期的EXE就是沒有重定位的。
我們都知道PE文件可以導(dǎo)出函數(shù)讓其他的PE文件使用，也可以從其他PE文件導(dǎo)入函數(shù)，這些是如何做到的？PE文件通過導(dǎo)出表指明自己導(dǎo)出那些函數(shù)，通過導(dǎo)入表指明需要從哪些模塊導(dǎo)入哪些函數(shù)。導(dǎo)入和導(dǎo)出表的具體結(jié)構(gòu)會在單獨(dú)的文章中詳細(xì)解釋。
（二）可執(zhí)行文件頭
在PE文件結(jié)構(gòu)詳解（一）基本概念里，解釋了一些PE文件的一些基本概念，從這篇開始，將詳細(xì)講解PE文件中的重要結(jié)構(gòu)。
了解一個(gè)文件的格式，最應(yīng)該首先了解的就是這個(gè)文件的文件頭的含義，因?yàn)閹缀跛械奈募袷?#xff0c;重要的信息都包含在頭部，順著頭部的信息，可以引導(dǎo)系統(tǒng)解析整個(gè)文件。所以，我們先來認(rèn)識一下PE文件的頭部格式。還記得上篇里的那個(gè)圖嗎？
DOS頭和NT頭就是PE文件中兩個(gè)重要的文件頭。
一、DOS頭
DOS頭的作用是兼容MS-DOS操作系統(tǒng)中的可執(zhí)行文件，對于32位PE文件來說，DOS所起的作用就是顯示一行文字，提示用戶：我需要在32位windows上才可以運(yùn)行。我認(rèn)為這是個(gè)善意的玩笑，因?yàn)樗⒉幌耧@示的那樣不能運(yùn)行，其實(shí)已經(jīng)運(yùn)行了，只是在DOS上沒有干用戶希望看到的工作而已，好吧，我承認(rèn)這不是重點(diǎn)。但是，至少我們看一下這個(gè)頭是如何定義的：
?
typedef struct _IMAGE_DOS_HEADER { ? ? ?// DOS .EXE header
? ? WORD ? e_magic; ? ? ? ? ? ? ? ? ? ? // Magic number
? ? WORD ? e_cblp; ? ? ? ? ? ? ? ? ? ? ?// Bytes on last page of file
? ? WORD ? e_cp; ? ? ? ? ? ? ? ? ? ? ? ?// Pages in file
? ? WORD ? e_crlc; ? ? ? ? ? ? ? ? ? ? ?// Relocations
? ? WORD ? e_cparhdr; ? ? ? ? ? ? ? ? ? // Size of header in paragraphs
? ? WORD ? e_minalloc; ? ? ? ? ? ? ? ? ?// Minimum extra paragraphs needed
? ? WORD ? e_maxalloc; ? ? ? ? ? ? ? ? ?// Maximum extra paragraphs needed
? ? WORD ? e_ss; ? ? ? ? ? ? ? ? ? ? ? ?// Initial (relative) SS value
? ? WORD ? e_sp; ? ? ? ? ? ? ? ? ? ? ? ?// Initial SP value
? ? WORD ? e_csum; ? ? ? ? ? ? ? ? ? ? ?// Checksum
? ? WORD ? e_ip; ? ? ? ? ? ? ? ? ? ? ? ?// Initial IP value
? ? WORD ? e_cs; ? ? ? ? ? ? ? ? ? ? ? ?// Initial (relative) CS value
? ? WORD ? e_lfarlc; ? ? ? ? ? ? ? ? ? ?// File address of relocation table
? ? WORD ? e_ovno; ? ? ? ? ? ? ? ? ? ? ?// Overlay number
? ? WORD ? e_res[4]; ? ? ? ? ? ? ? ? ? ?// Reserved words
? ? WORD ? e_oemid; ? ? ? ? ? ? ? ? ? ? // OEM identifier (for e_oeminfo)
? ? WORD ? e_oeminfo; ? ? ? ? ? ? ? ? ? // OEM information; e_oemid specific
? ? WORD ? e_res2[10]; ? ? ? ? ? ? ? ? ?// Reserved words
? ? LONG ? e_lfanew; ? ? ? ? ? ? ? ? ? ?// File address of new exe header
? } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
我們只需要關(guān)注兩個(gè)域：
e_magic：一個(gè)WORD類型，值是一個(gè)常數(shù)0x4D5A，用文本編輯器查看該值位‘MZ’，可執(zhí)行文件必須都是'MZ'開頭。
e_lfanew：為32位可執(zhí)行文件擴(kuò)展的域，用來表示DOS頭之后的NT頭相對文件起始地址的偏移。
二、NT頭
順著DOS頭中的e_lfanew，我們很容易可以找到NT頭，這個(gè)才是32位PE文件中最有用的頭，定義如下:
typedef struct _IMAGE_NT_HEADERS {
? ? DWORD Signature;
? ? IMAGE_FILE_HEADER FileHeader;
? ? IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;
下圖是一張真實(shí)的PE文件頭結(jié)構(gòu)以及其各個(gè)域的取值：
Signature：類似于DOS頭中的e_magic，其高16位是0，低16是0x4550，用字符表示是'PE‘。
IMAGE_FILE_HEADER是PE文件頭，c語言的定義是這樣的：
typedef struct _IMAGE_FILE_HEADER {
? ? WORD ? ?Machine;
? ? WORD ? ?NumberOfSections;
? ? DWORD ? TimeDateStamp;
? ? DWORD ? PointerToSymbolTable;
? ? DWORD ? NumberOfSymbols;
? ? WORD ? ?SizeOfOptionalHeader;
? ? WORD ? ?Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;
每個(gè)域的具體含義如下：
Machine：該文件的運(yùn)行平臺，是x86、x64還是I64等等，可以是下面值里的某一個(gè)。
#define IMAGE_FILE_MACHINE_UNKNOWN ? ? ? ? ? 0
#define IMAGE_FILE_MACHINE_I386 ? ? ? ? ? ? ?0x014c ?// Intel 386.
#define IMAGE_FILE_MACHINE_R3000 ? ? ? ? ? ? 0x0162 ?// MIPS little-endian, 0x160 big-endian
#define IMAGE_FILE_MACHINE_R4000 ? ? ? ? ? ? 0x0166 ?// MIPS little-endian
#define IMAGE_FILE_MACHINE_R10000 ? ? ? ? ? ?0x0168 ?// MIPS little-endian
#define IMAGE_FILE_MACHINE_WCEMIPSV2 ? ? ? ? 0x0169 ?// MIPS little-endian WCE v2
#define IMAGE_FILE_MACHINE_ALPHA ? ? ? ? ? ? 0x0184 ?// Alpha_AXP
#define IMAGE_FILE_MACHINE_SH3 ? ? ? ? ? ? ? 0x01a2 ?// SH3 little-endian
#define IMAGE_FILE_MACHINE_SH3DSP ? ? ? ? ? ?0x01a3
#define IMAGE_FILE_MACHINE_SH3E ? ? ? ? ? ? ?0x01a4 ?// SH3E little-endian
#define IMAGE_FILE_MACHINE_SH4 ? ? ? ? ? ? ? 0x01a6 ?// SH4 little-endian
#define IMAGE_FILE_MACHINE_SH5 ? ? ? ? ? ? ? 0x01a8 ?// SH5
#define IMAGE_FILE_MACHINE_ARM ? ? ? ? ? ? ? 0x01c0 ?// ARM Little-Endian
#define IMAGE_FILE_MACHINE_THUMB ? ? ? ? ? ? 0x01c2
#define IMAGE_FILE_MACHINE_AM33 ? ? ? ? ? ? ?0x01d3
#define IMAGE_FILE_MACHINE_POWERPC ? ? ? ? ? 0x01F0 ?// IBM PowerPC Little-Endian
#define IMAGE_FILE_MACHINE_POWERPCFP ? ? ? ? 0x01f1
#define IMAGE_FILE_MACHINE_IA64 ? ? ? ? ? ? ?0x0200 ?// Intel 64
#define IMAGE_FILE_MACHINE_MIPS16 ? ? ? ? ? ?0x0266 ?// MIPS
#define IMAGE_FILE_MACHINE_ALPHA64 ? ? ? ? ? 0x0284 ?// ALPHA64
#define IMAGE_FILE_MACHINE_MIPSFPU ? ? ? ? ? 0x0366 ?// MIPS
#define IMAGE_FILE_MACHINE_MIPSFPU16 ? ? ? ? 0x0466 ?// MIPS
#define IMAGE_FILE_MACHINE_AXP64 ? ? ? ? ? ? IMAGE_FILE_MACHINE_ALPHA64
#define IMAGE_FILE_MACHINE_TRICORE ? ? ? ? ? 0x0520 ?// Infineon
#define IMAGE_FILE_MACHINE_CEF ? ? ? ? ? ? ? 0x0CEF
#define IMAGE_FILE_MACHINE_EBC ? ? ? ? ? ? ? 0x0EBC ?// EFI Byte Code
#define IMAGE_FILE_MACHINE_AMD64 ? ? ? ? ? ? 0x8664 ?// AMD64 (K8)
#define IMAGE_FILE_MACHINE_M32R ? ? ? ? ? ? ?0x9041 ?// M32R little-endian
#define IMAGE_FILE_MACHINE_CEE ? ? ? ? ? ? ? 0xC0EE
NumberOfSections：該P(yáng)E文件中有多少個(gè)節(jié)，也就是節(jié)表中的項(xiàng)數(shù)。
TimeDateStamp：PE文件的創(chuàng)建時(shí)間，一般有連接器填寫。
PointerToSymbolTable：COFF文件符號表在文件中的偏移。
NumberOfSymbols：符號表的數(shù)量。
SizeOfOptionalHeader：緊隨其后的可選頭的大小。
Characteristics：可執(zhí)行文件的屬性，可以是下面這些值按位相或。
?
#define IMAGE_FILE_RELOCS_STRIPPED ? ? ? ? ? 0x0001 ?// Relocation info stripped from file.
#define IMAGE_FILE_EXECUTABLE_IMAGE ? ? ? ? ?0x0002 ?// File is executable ?(i.e. no unresolved externel references).
#define IMAGE_FILE_LINE_NUMS_STRIPPED ? ? ? ?0x0004 ?// Line nunbers stripped from file.
#define IMAGE_FILE_LOCAL_SYMS_STRIPPED ? ? ? 0x0008 ?// Local symbols stripped from file.
#define IMAGE_FILE_AGGRESIVE_WS_TRIM ? ? ? ? 0x0010 ?// Agressively trim working set
#define IMAGE_FILE_LARGE_ADDRESS_AWARE ? ? ? 0x0020 ?// App can handle >2gb addresses
#define IMAGE_FILE_BYTES_REVERSED_LO ? ? ? ? 0x0080 ?// Bytes of machine word are reversed.
#define IMAGE_FILE_32BIT_MACHINE ? ? ? ? ? ? 0x0100 ?// 32 bit word machine.
#define IMAGE_FILE_DEBUG_STRIPPED ? ? ? ? ? ?0x0200 ?// Debugging info stripped from file in .DBG file
#define IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP ? 0x0400 ?// If Image is on removable media, copy and run from the swap file.
#define IMAGE_FILE_NET_RUN_FROM_SWAP ? ? ? ? 0x0800 ?// If Image is on Net, copy and run from the swap file.
#define IMAGE_FILE_SYSTEM ? ? ? ? ? ? ? ? ? ?0x1000 ?// System File.
#define IMAGE_FILE_DLL ? ? ? ? ? ? ? ? ? ? ? 0x2000 ?// File is a DLL.
#define IMAGE_FILE_UP_SYSTEM_ONLY ? ? ? ? ? ?0x4000 ?// File should only be run on a UP machine
#define IMAGE_FILE_BYTES_REVERSED_HI ? ? ? ? 0x8000 ?// Bytes of machine word are reversed.
可以看出，PE文件頭定義了PE文件的一些基本信息和屬性，這些屬性會在PE加載器加載時(shí)用到，如果加載器發(fā)現(xiàn)PE文件頭中定義的一些屬性不滿足當(dāng)前的運(yùn)行環(huán)境，將會終止加載該P(yáng)E。
另一個(gè)重要的頭就是PE可選頭，別看他名字叫可選頭，其實(shí)一點(diǎn)都不能少，不過，它在不同的平臺下是不一樣的，例如32位下是IMAGE_OPTIONAL_HEADER32，而在64位下是IMAGE_OPTIONAL_HEADER64。為了簡單起見，我們只看32位。
typedef struct _IMAGE_OPTIONAL_HEADER {
? ? WORD ? ?Magic;
? ? BYTE ? ?MajorLinkerVersion;
? ? BYTE ? ?MinorLinkerVersion;
? ? DWORD ? SizeOfCode;
? ? DWORD ? SizeOfInitializedData;
? ? DWORD ? SizeOfUninitializedData;
? ? DWORD ? AddressOfEntryPoint;
? ? DWORD ? BaseOfCode;
? ? DWORD ? BaseOfData;
? ? DWORD ? ImageBase;
? ? DWORD ? SectionAlignment;
? ? DWORD ? FileAlignment;
? ? WORD ? ?MajorOperatingSystemVersion;
? ? WORD ? ?MinorOperatingSystemVersion;
? ? WORD ? ?MajorImageVersion;
? ? WORD ? ?MinorImageVersion;
? ? WORD ? ?MajorSubsystemVersion;
? ? WORD ? ?MinorSubsystemVersion;
? ? DWORD ? Win32VersionValue;
? ? DWORD ? SizeOfImage;
? ? DWORD ? SizeOfHeaders;
? ? DWORD ? CheckSum;
? ? WORD ? ?Subsystem;
? ? WORD ? ?DllCharacteristics;
? ? DWORD ? SizeOfStackReserve;
? ? DWORD ? SizeOfStackCommit;
? ? DWORD ? SizeOfHeapReserve;
? ? DWORD ? SizeOfHeapCommit;
? ? DWORD ? LoaderFlags;
? ? DWORD ? NumberOfRvaAndSizes;
? ? IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER32, *PIMAGE_OPTIONAL_HEADER32;
Magic：表示可選頭的類型。
#define IMAGE_NT_OPTIONAL_HDR32_MAGIC ? ? ?0x10b ?// 32位PE可選頭
#define IMAGE_NT_OPTIONAL_HDR64_MAGIC ? ? ?0x20b ?// 64位PE可選頭
#define IMAGE_ROM_OPTIONAL_HDR_MAGIC ? ? ? 0x107 ?
MajorLinkerVersion和MinorLinkerVersion：鏈接器的版本號。
SizeOfCode：代碼段的長度，如果有多個(gè)代碼段，則是代碼段長度的總和。
SizeOfInitializedData：初始化的數(shù)據(jù)長度。
SizeOfUninitializedData：未初始化的數(shù)據(jù)長度。
AddressOfEntryPoint：程序入口的RVA，對于exe這個(gè)地址可以理解為WinMain的RVA。對于DLL，這個(gè)地址可以理解為DllMain的RVA，如果是驅(qū)動程序，可以理解為DriverEntry的RVA。當(dāng)然，實(shí)際上入口點(diǎn)并非是WinMain，DllMain和DriverEntry，在這些函數(shù)之前還有一系列初始化要完成，當(dāng)然，這些不是本文的重點(diǎn)。
BaseOfCode：代碼段起始地址的RVA。
BaseOfData：數(shù)據(jù)段起始地址的RVA。
ImageBase：映象（加載到內(nèi)存中的PE文件）的基地址，這個(gè)基地址是建議，對于DLL來說，如果無法加載到這個(gè)地址，系統(tǒng)會自動為其選擇地址。
SectionAlignment：節(jié)對齊，PE中的節(jié)被加載到內(nèi)存時(shí)會按照這個(gè)域指定的值來對齊，比如這個(gè)值是0x1000，那么每個(gè)節(jié)的起始地址的低12位都為0。
FileAlignment：節(jié)在文件中按此值對齊，SectionAlignment必須大于或等于FileAlignment。
MajorOperatingSystemVersion、MinorOperatingSystemVersion：所需操作系統(tǒng)的版本號，隨著操作系統(tǒng)版本越來越多，這個(gè)好像不是那么重要了。
MajorImageVersion、MinorImageVersion：映象的版本號，這個(gè)是開發(fā)者自己指定的，由連接器填寫。
MajorSubsystemVersion、MinorSubsystemVersion：所需子系統(tǒng)版本號。
Win32VersionValue：保留，必須為0。
SizeOfImage：映象的大小，PE文件加載到內(nèi)存中空間是連續(xù)的，這個(gè)值指定占用虛擬空間的大小。
SizeOfHeaders：所有文件頭（包括節(jié)表）的大小，這個(gè)值是以FileAlignment對齊的。
CheckSum：映象文件的校驗(yàn)和。
Subsystem：運(yùn)行該P(yáng)E文件所需的子系統(tǒng)，可以是下面定義中的某一個(gè)：
#define IMAGE_SUBSYSTEM_UNKNOWN ? ? ? ? ? ? ?0 ? // Unknown subsystem.
#define IMAGE_SUBSYSTEM_NATIVE ? ? ? ? ? ? ? 1 ? // Image doesn't require a subsystem.
#define IMAGE_SUBSYSTEM_WINDOWS_GUI ? ? ? ? ?2 ? // Image runs in the Windows GUI subsystem.
#define IMAGE_SUBSYSTEM_WINDOWS_CUI ? ? ? ? ?3 ? // Image runs in the Windows character subsystem.
#define IMAGE_SUBSYSTEM_OS2_CUI ? ? ? ? ? ? ?5 ? // image runs in the OS/2 character subsystem.
#define IMAGE_SUBSYSTEM_POSIX_CUI ? ? ? ? ? ?7 ? // image runs in the Posix character subsystem.
#define IMAGE_SUBSYSTEM_NATIVE_WINDOWS ? ? ? 8 ? // image is a native Win9x driver.
#define IMAGE_SUBSYSTEM_WINDOWS_CE_GUI ? ? ? 9 ? // Image runs in the Windows CE subsystem.
#define IMAGE_SUBSYSTEM_EFI_APPLICATION ? ? ?10 ?//
#define IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER ?11 ? //
#define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER ? 12 ?//
#define IMAGE_SUBSYSTEM_EFI_ROM ? ? ? ? ? ? ?13
#define IMAGE_SUBSYSTEM_XBOX ? ? ? ? ? ? ? ? 14
#define IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION 16
DllCharacteristics：DLL的文件屬性，只對DLL文件有效，可以是下面定義中某些的組合：
#define IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE 0x0040 ? ? // DLL can move.
#define IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY ? ?0x0080 ? ? // Code Integrity Image
#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT ? ?0x0100 ? ? // Image is NX compatible
#define IMAGE_DLLCHARACTERISTICS_NO_ISOLATION 0x0200 ? ? // Image understands isolation and doesn't want it
#define IMAGE_DLLCHARACTERISTICS_NO_SEH ? ? ? 0x0400 ? ? // Image does not use SEH. ?No SE handler may reside in this image
#define IMAGE_DLLCHARACTERISTICS_NO_BIND ? ? ?0x0800 ? ? // Do not bind this image.
// ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x1000 ? ? // Reserved.
#define IMAGE_DLLCHARACTERISTICS_WDM_DRIVER ? 0x2000 ? ? // Driver uses WDM model
// ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?0x4000 ? ? // Reserved.
#define IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE ? ? 0x8000
SizeOfStackReserve：運(yùn)行時(shí)為每個(gè)線程棧保留內(nèi)存的大小。
SizeOfStackCommit：運(yùn)行時(shí)每個(gè)線程棧初始占用內(nèi)存大小。
SizeOfHeapReserve：運(yùn)行時(shí)為進(jìn)程堆保留內(nèi)存大小。
SizeOfHeapCommit：運(yùn)行時(shí)進(jìn)程堆初始占用內(nèi)存大小。
LoaderFlags：保留，必須為0。
NumberOfRvaAndSizes：數(shù)據(jù)目錄的項(xiàng)數(shù)，即下面這個(gè)數(shù)組的項(xiàng)數(shù)。
DataDirectory：數(shù)據(jù)目錄，這是一個(gè)數(shù)組，數(shù)組的項(xiàng)定義如下：
?
typedef struct _IMAGE_DATA_DIRECTORY {
? ? DWORD ? VirtualAddress;
? ? DWORD ? Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
VirtualAddress：是一個(gè)RVA。
Size：是一個(gè)大小。
這兩個(gè)數(shù)有什么用呢？一個(gè)是地址，一個(gè)是大小，可以看出這個(gè)數(shù)據(jù)目錄項(xiàng)定義的是一個(gè)區(qū)域。那他定義的是什么東西的區(qū)域呢？前面說了，DataDirectory是個(gè)數(shù)組，數(shù)組中的每一項(xiàng)對應(yīng)一個(gè)特定的數(shù)據(jù)結(jié)構(gòu)，包括導(dǎo)入表，導(dǎo)出表等等，根據(jù)不同的索引取出來的是不同的結(jié)構(gòu)，頭文件里定義各個(gè)項(xiàng)表示哪個(gè)結(jié)構(gòu)，如下面的代碼所示：
#define IMAGE_DIRECTORY_ENTRY_EXPORT ? ? ? ? ?0 ? // Export Directory
#define IMAGE_DIRECTORY_ENTRY_IMPORT ? ? ? ? ?1 ? // Import Directory
#define IMAGE_DIRECTORY_ENTRY_RESOURCE ? ? ? ?2 ? // Resource Directory
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION ? ? ? 3 ? // Exception Directory
#define IMAGE_DIRECTORY_ENTRY_SECURITY ? ? ? ?4 ? // Security Directory
#define IMAGE_DIRECTORY_ENTRY_BASERELOC ? ? ? 5 ? // Base Relocation Table
#define IMAGE_DIRECTORY_ENTRY_DEBUG ? ? ? ? ? 6 ? // Debug Directory
// ? ? ?IMAGE_DIRECTORY_ENTRY_COPYRIGHT ? ? ? 7 ? // (X86 usage)
#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE ? ?7 ? // Architecture Specific Data
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR ? ? ? 8 ? // RVA of GP
#define IMAGE_DIRECTORY_ENTRY_TLS ? ? ? ? ? ? 9 ? // TLS Directory
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG ? ?10 ? // Load Configuration Directory
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT ? 11 ? // Bound Import Directory in headers
#define IMAGE_DIRECTORY_ENTRY_IAT ? ? ? ? ? ?12 ? // Import Address Table
#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT ? 13 ? // Delay Load Import Descriptors
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14 ? // COM Runtime descriptor
看到這么多的定義，大家估計(jì)要頭疼了，好不容易要把PE文件頭學(xué)習(xí)完了，又“從天而降”一大波的結(jié)構(gòu)。不用緊張，有了前面的知識，后面的部分就迎刃而解了。下一篇開始將沿著這個(gè)數(shù)據(jù)目錄分解其余部分，繼續(xù)關(guān)注哦~
?
（三）PE導(dǎo)出表
上篇文章?PE文件結(jié)構(gòu)詳解（二）可執(zhí)行文件頭?的結(jié)尾出現(xiàn)了一個(gè)大數(shù)組，這個(gè)數(shù)組中的每一項(xiàng)都是一個(gè)特定的結(jié)構(gòu)，通過函數(shù)獲取數(shù)組中的項(xiàng)可以用RtlImageDirectoryEntryToData函數(shù)，DataDirectory中的每一項(xiàng)都可以用這個(gè)函數(shù)獲取，函數(shù)原型如下：
PVOID NTAPI RtlImageDirectoryEntryToData(PVOID Base, BOOLEAN MappedAsImage, USHORT Directory, PULONG Size);
Base：模塊基地址。
MappedAsImage：是否映射為映象。
Directory：數(shù)據(jù)目錄項(xiàng)的索引。
#define IMAGE_DIRECTORY_ENTRY_EXPORT ? ? ? ? ?0 ? // Export Directory
#define IMAGE_DIRECTORY_ENTRY_IMPORT ? ? ? ? ?1 ? // Import Directory
#define IMAGE_DIRECTORY_ENTRY_RESOURCE ? ? ? ?2 ? // Resource Directory
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION ? ? ? 3 ? // Exception Directory
#define IMAGE_DIRECTORY_ENTRY_SECURITY ? ? ? ?4 ? // Security Directory
#define IMAGE_DIRECTORY_ENTRY_BASERELOC ? ? ? 5 ? // Base Relocation Table
#define IMAGE_DIRECTORY_ENTRY_DEBUG ? ? ? ? ? 6 ? // Debug Directory
// ? ? ?IMAGE_DIRECTORY_ENTRY_COPYRIGHT ? ? ? 7 ? // (X86 usage)
#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE ? ?7 ? // Architecture Specific Data
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR ? ? ? 8 ? // RVA of GP
#define IMAGE_DIRECTORY_ENTRY_TLS ? ? ? ? ? ? 9 ? // TLS Directory
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG ? ?10 ? // Load Configuration Directory
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT ? 11 ? // Bound Import Directory in headers
#define IMAGE_DIRECTORY_ENTRY_IAT ? ? ? ? ? ?12 ? // Import Address Table
#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT ? 13 ? // Delay Load Import Descriptors
#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14 ? // COM Runtime descriptor
Size：對應(yīng)數(shù)據(jù)目錄項(xiàng)的大小，比如Directory為0，則表示導(dǎo)出表的大小。
返回值表示數(shù)據(jù)目錄項(xiàng)的起始地址。
這次來看看第一項(xiàng)：導(dǎo)出表。
導(dǎo)出表是用來描述模塊中的導(dǎo)出函數(shù)的結(jié)構(gòu)，如果一個(gè)模塊導(dǎo)出了函數(shù)，那么這個(gè)函數(shù)會被記錄在導(dǎo)出表中，這樣通過GetProcAddress函數(shù)就能動態(tài)獲取到函數(shù)的地址。函數(shù)導(dǎo)出的方式有兩種，一種是按名字導(dǎo)出，一種是按序號導(dǎo)出。這兩種導(dǎo)出方式在導(dǎo)出表中的描述方式也不相同。模塊的導(dǎo)出函數(shù)可以通過Dependency walker工具來查看：
上圖中紅框位置顯示的就是模塊的導(dǎo)出函數(shù)，有時(shí)候顯示的導(dǎo)出函數(shù)名字中有一些符號，像 ??0CP2PDownloadUIInterface@@QAE@ABV0@@Z，這種是導(dǎo)出了C++的函數(shù)名，編譯器將名字進(jìn)行了修飾。
下面看一下導(dǎo)出表的定義吧：
typedef struct _IMAGE_EXPORT_DIRECTORY {
? ? DWORD ? Characteristics;
? ? DWORD ? TimeDateStamp;
? ? WORD ? ?MajorVersion;
? ? WORD ? ?MinorVersion;
? ? DWORD ? Name;
? ? DWORD ? Base;
? ? DWORD ? NumberOfFunctions;
? ? DWORD ? NumberOfNames;
? ? DWORD ? AddressOfFunctions; ? ? // RVA from base of image
? ? DWORD ? AddressOfNames; ? ? ? ? // RVA from base of image
? ? DWORD ? AddressOfNameOrdinals; ?// RVA from base of image
} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;
結(jié)構(gòu)還算比較簡單，具體每一項(xiàng)的含義如下：
Characteristics：現(xiàn)在沒有用到，一般為0。
TimeDateStamp：導(dǎo)出表生成的時(shí)間戳，由連接器生成。
MajorVersion，MinorVersion：看名字是版本，實(shí)際貌似沒有用，都是0。
Name：模塊的名字。
Base：序號的基數(shù)，按序號導(dǎo)出函數(shù)的序號值從Base開始遞增。
NumberOfFunctions：所有導(dǎo)出函數(shù)的數(shù)量。
NumberOfNames：按名字導(dǎo)出函數(shù)的數(shù)量。
AddressOfFunctions：一個(gè)RVA，指向一個(gè)DWORD數(shù)組，數(shù)組中的每一項(xiàng)是一個(gè)導(dǎo)出函數(shù)的RVA，順序與導(dǎo)出序號相同。
AddressOfNames：一個(gè)RVA，依然指向一個(gè)DWORD數(shù)組，數(shù)組中的每一項(xiàng)仍然是一個(gè)RVA，指向一個(gè)表示函數(shù)名字。
AddressOfNameOrdinals：一個(gè)RVA，還是指向一個(gè)WORD數(shù)組，數(shù)組中的每一項(xiàng)與AddressOfNames中的每一項(xiàng)對應(yīng)，表示該名字的函數(shù)在AddressOfFunctions中的序號。
第一次接觸這個(gè)結(jié)構(gòu)的童鞋被后面的5項(xiàng)搞暈了吧，理解這個(gè)結(jié)構(gòu)比結(jié)構(gòu)本身看上去要復(fù)雜一些，文字描述不管怎么說都顯得晦澀，所謂一圖勝千言，無圖無真相，直接上圖：
在上圖中，AddressOfNames指向一個(gè)數(shù)組，數(shù)組里保存著一組RVA，每個(gè)RVA指向一個(gè)字符串，這個(gè)字符串即導(dǎo)出的函數(shù)名，與這個(gè)函數(shù)名對應(yīng)的是AddressOfNameOrdinals中的對應(yīng)項(xiàng)。獲取導(dǎo)出函數(shù)地址時(shí)，先在AddressOfNames中找到對應(yīng)的名字，比如Func2，他在AddressOfNames中是第二項(xiàng)，然后從AddressOfNameOrdinals中取出第二項(xiàng)的值，這里是2，表示函數(shù)入口保存在AddressOfFunctions這個(gè)數(shù)組中下標(biāo)為2的項(xiàng)里，即第三項(xiàng)，取出其中的值，加上模塊基地址便是導(dǎo)出函數(shù)的地址。如果函數(shù)是以序號導(dǎo)出的，那么查找的時(shí)候直接用序號減去Base，得到的值就是函數(shù)在AddressOfFunctions中的下標(biāo)。
用代碼實(shí)現(xiàn)如下：
?
DWORD* CEAT::SearchEAT( const char* szName)
{
? ? if (IS_VALID_PTR(m_pTable))
? ? {
? ? ? ? bool bByOrdinal = HIWORD(szName) == 0;
? ? ? ? DWORD* pProcs = (DWORD*)((char*)RVA2VA(m_pTable->AddressOfFunctions));
? ? ? ? if (bByOrdinal)
? ? ? ? {
? ? ? ? ? ? DWORD dwOrdinal = (DWORD)szName;?
? ? ? ? ? ? if (dwOrdinal < m_pTable->NumberOfFunctions && dwOrdinal >= m_pTable->Base)
? ? ? ? ? ? {
? ? ? ? ? ? ? ? return &pProcs[dwOrdinal-m_pTable->Base];
? ? ? ? ? ? }
? ? ? ? }
? ? ? ? else
? ? ? ? {
? ? ? ? ? ? WORD* pOrdinals = (WORD*)((char*)RVA2VA(m_pTable->AddressOfNameOrdinals));
? ? ? ? ? ? DWORD* pNames = (DWORD*)((char*)RVA2VA(m_pTable->AddressOfNames));
? ? ? ? ? ? for (unsigned int i=0; i<m_pTable->NumberOfNames; ++i)
? ? ? ? ? ? {
? ? ? ? ? ? ? ? char* pNameVA = (char*)RVA2VA(pNames[i]);
? ? ? ? ? ? ? ? if (strcmp(szName, pNameVA) != 0)
? ? ? ? ? ? ? ? {
? ? ? ? ? ? ? ? ? ? continue;
? ? ? ? ? ? ? ? }
? ? ? ? ? ? ? ? return &pProcs[pOrdinals[i]];
? ? ? ? ? ? }
? ? ? ? }
? ? }
? ? return NULL;
}
（四）PE導(dǎo)入表
PE文件結(jié)構(gòu)詳解（二）可執(zhí)行文件頭的最后展示了一個(gè)數(shù)組，PE文件結(jié)構(gòu)詳解（三）PE導(dǎo)出表中解釋了其中第一項(xiàng)的格式，本篇文章來揭示這個(gè)數(shù)組中的第二項(xiàng)：IMAGE_DIRECTORY_ENTRY_IMPORT，即導(dǎo)入表。
也許大家注意到過，在IMAGE_DATA_DIRECTORY中，有幾項(xiàng)的名字都和導(dǎo)入表有關(guān)系，其中包括：IMAGE_DIRECTORY_ENTRY_IMPORT，IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT，IMAGE_DIRECTORY_ENTRY_IAT和IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT這幾個(gè)導(dǎo)入都是用來干什么的，他們之間又是什么關(guān)系呢？聽我慢慢道來。
IMAGE_DIRECTORY_ENTRY_IMPORT就是我們通常所知道的導(dǎo)入表，在PE文件加載時(shí)，會根據(jù)這個(gè)表里的內(nèi)容加載依賴的DLL，并填充所需函數(shù)的地址。
IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT叫做綁定導(dǎo)入表，在第一種導(dǎo)入表導(dǎo)入地址的修正是在PE加載時(shí)完成，如果一個(gè)PE文件導(dǎo)入的DLL或者函數(shù)多那么加載起來就會略顯的慢一些，所以出現(xiàn)了綁定導(dǎo)入，在加載以前就修正了導(dǎo)入表，這樣就會快一些。
IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT叫做延遲導(dǎo)入表，一個(gè)PE文件也許提供了很多功能，也導(dǎo)入了很多其他DLL，但是并非每次加載都會用到它提供的所有功能，也不一定會用到它需要導(dǎo)入的所有DLL，因此延遲導(dǎo)入就出現(xiàn)了，只有在一個(gè)PE文件真正用到需要的DLL，這個(gè)DLL才會被加載，甚至于只有真正使用某個(gè)導(dǎo)入函數(shù)，這個(gè)函數(shù)地址才會被修正。
IMAGE_DIRECTORY_ENTRY_IAT是導(dǎo)入地址表，前面的三個(gè)表其實(shí)是導(dǎo)入函數(shù)的描述，真正的函數(shù)地址是被填充在導(dǎo)入地址表中的。
舉個(gè)實(shí)際的例子，看一下下面這張圖：
這個(gè)代碼調(diào)用了一個(gè)RegOpenKeyW的導(dǎo)入函數(shù)，我們看到其opcode是FF 15 00 00 19 30氣質(zhì)FF 15表示這是一個(gè)間接調(diào)用，即call dword ptr?[30190000] ;這表示要調(diào)用的地址存放在30190000這個(gè)地址中，而30190000這個(gè)地址在導(dǎo)入地址表的范圍內(nèi)，當(dāng)模塊加載時(shí)，PE 加載器會根據(jù)導(dǎo)入表中描述的信息修正30190000這個(gè)內(nèi)存中的內(nèi)容。
那么導(dǎo)入表里到底記錄了那些信息，如何根據(jù)這些信息修正IAT呢？我們一起來看一下導(dǎo)入表的定義：
?
typedef struct _IMAGE_IMPORT_DESCRIPTOR {
? ? union {
? ? ? ? DWORD ? Characteristics; ? ? ? ? ? ?// 0 for terminating null import descriptor
? ? ? ? DWORD ? OriginalFirstThunk; ? ? ? ? // RVA to original unbound IAT (PIMAGE_THUNK_DATA)
? ? } DUMMYUNIONNAME;
? ? DWORD ? TimeDateStamp; ? ? ? ? ? ? ? ? ?// 0 if not bound,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? // -1 if bound, and real date\time stamp
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? // ? ? in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND)
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? // O.W. date/time stamp of DLL bound to (Old BIND)
?
? ? DWORD ? ForwarderChain; ? ? ? ? ? ? ? ? // -1 if no forwarders
? ? DWORD ? Name;
? ? DWORD ? FirstThunk; ? ? ? ? ? ? ? ? ? ? // RVA to IAT (if bound this IAT has actual addresses)
} IMAGE_IMPORT_DESCRIPTOR;
typedef IMAGE_IMPORT_DESCRIPTOR UNALIGNED *PIMAGE_IMPORT_DESCRIPTOR;
使用RtlImageDirectoryEntryToData并將索引號傳1，會得到一個(gè)如上結(jié)構(gòu)的指針，實(shí)際上指向一個(gè)上述結(jié)構(gòu)的數(shù)組，每個(gè)導(dǎo)入的DLL都會成為數(shù)組中的一項(xiàng)，也就是說，一個(gè)這樣的結(jié)構(gòu)對應(yīng)一個(gè)導(dǎo)入的DLL。
Characteristics和OriginalFirstThunk：一個(gè)聯(lián)合體，如果是數(shù)組的最后一項(xiàng)Characteristics為0，否則OriginalFirstThunk保存一個(gè)RVA，指向一個(gè)IMAGE_THUNK_DATA的數(shù)組，這個(gè)數(shù)組中的每一項(xiàng)表示一個(gè)導(dǎo)入函數(shù)。
TimeDateStamp：映象綁定前，這個(gè)值是0，綁定后是導(dǎo)入模塊的時(shí)間戳。
ForwarderChain：轉(zhuǎn)發(fā)鏈，如果沒有轉(zhuǎn)發(fā)器，這個(gè)值是-1。
Name：一個(gè)RVA，指向?qū)肽K的名字，所以一個(gè)IMAGE_IMPORT_DESCRIPTOR描述一個(gè)導(dǎo)入的DLL。
FirstThunk：也是一個(gè)RVA，也指向一個(gè)IMAGE_THUNK_DATA數(shù)組。
既然OriginalFirstThunk與FirstThunk都指向一個(gè)IMAGE_THUNK_DATA數(shù)組，而且這兩個(gè)域的名字都長得很像，他倆有什么區(qū)別呢？為了解答這個(gè)問題，先來認(rèn)識一下IMAGE_THUNK_DATA結(jié)構(gòu)：
?
typedef struct _IMAGE_THUNK_DATA32 {
? ? union {
? ? ? ? DWORD ForwarderString; ? ? ?// PBYTE?
? ? ? ? DWORD Function; ? ? ? ? ? ? // PDWORD
? ? ? ? DWORD Ordinal;
? ? ? ? DWORD AddressOfData; ? ? ? ?// PIMAGE_IMPORT_BY_NAME
? ? } u1;
} IMAGE_THUNK_DATA32;
typedef IMAGE_THUNK_DATA32 * PIMAGE_THUNK_DATA32;
ForwarderString是轉(zhuǎn)發(fā)用的，暫時(shí)不用考慮，Function表示函數(shù)地址，如果是按序號導(dǎo)入Ordinal就有用了，若是按名字導(dǎo)入AddressOfData便指向名字信息?？梢钥闯鲞@個(gè)結(jié)構(gòu)體就是一個(gè)大的union，大家都知道union雖包含多個(gè)域但是在不同時(shí)刻代表不同的意義那到底應(yīng)該是名字還是序號，該如何區(qū)分呢？可以通過Ordinal判斷，如果Ordinal的最高位是1，就是按序號導(dǎo)入的，這時(shí)候，低16位就是導(dǎo)入序號，如果最高位是0，則AddressOfData是一個(gè)RVA，指向一個(gè)IMAGE_IMPORT_BY_NAME結(jié)構(gòu)，用來保存名字信息，由于Ordinal和AddressOfData實(shí)際上是同一個(gè)內(nèi)存空間，所以AddressOfData其實(shí)只有低31位可以表示RVA，但是一個(gè)PE文件不可能超過2G，所以最高位永遠(yuǎn)為0，這樣設(shè)計(jì)很合理的利用了空間。實(shí)際編寫代碼的時(shí)候微軟提供兩個(gè)宏定義處理序號導(dǎo)入：IMAGE_SNAP_BY_ORDINAL判斷是否按序號導(dǎo)入，IMAGE_ORDINAL用來獲取導(dǎo)入序號。
這時(shí)我們可以回頭看看OriginalFirstThunk與FirstThunk，OriginalFirstThunk指向的IMAGE_THUNK_DATA數(shù)組包含導(dǎo)入信息，在這個(gè)數(shù)組中只有Ordinal和AddressOfData是有用的，因此可以通過OriginalFirstThunk查找到函數(shù)的地址。FirstThunk則略有不同，在PE文件加載以前或者說在導(dǎo)入表未處理以前，他所指向的數(shù)組與OriginalFirstThunk中的數(shù)組雖不是同一個(gè)，但是內(nèi)容卻是相同的，都包含了導(dǎo)入信息，而在加載之后，FirstThunk中的Function開始生效，他指向?qū)嶋H的函數(shù)地址，因?yàn)镕irstThunk實(shí)際上指向IAT中的一個(gè)位置，IAT就充當(dāng)了IMAGE_THUNK_DATA數(shù)組，加載完成后，這些IAT項(xiàng)就變成了實(shí)際的函數(shù)地址，即Function的意義。還是上個(gè)圖對比一下：
上圖是加載前。
上圖是加載后。
最后總結(jié)一下：
導(dǎo)入表其實(shí)是一個(gè)IMAGE_IMPORT_DESCRIPTOR的數(shù)組，每個(gè)導(dǎo)入的DLL對應(yīng)一個(gè)IMAGE_IMPORT_DESCRIPTOR。
IMAGE_IMPORT_DESCRIPTOR包含兩個(gè)IMAGE_THUNK_DATA數(shù)組，數(shù)組中的每一項(xiàng)對應(yīng)一個(gè)導(dǎo)入函數(shù)。
加載前OriginalFirstThunk與FirstThunk的數(shù)組都指向名字信息，加載后FirstThunk數(shù)組指向?qū)嶋H的函數(shù)地址。
（五）延遲導(dǎo)入表
PE文件結(jié)構(gòu)詳解（四）PE導(dǎo)入表講了一般的PE導(dǎo)入表，這次我們來看一下另外一種導(dǎo)入表：延遲導(dǎo)入（Delay Import）?？疵志椭?#xff0c;這種導(dǎo)入機(jī)制導(dǎo)入其他DLL的時(shí)機(jī)比較“遲”，為什么要遲呢？因?yàn)橛行?dǎo)入函數(shù)可能使用的頻率比較低，或者在某些特定的場合才會用到，而有些函數(shù)可能要在程序運(yùn)行一段時(shí)間后才會用到，這些函數(shù)可以等到他實(shí)際使用的時(shí)候再去加載對應(yīng)的DLL，而沒必要再程序一裝載就初始化好。
這個(gè)機(jī)制聽起來很誘人，因?yàn)樗梢约涌靻铀俣?#xff0c;我們應(yīng)該如何利用這項(xiàng)機(jī)制呢？VC有一個(gè)選項(xiàng)，可以讓我們很方便的使用到這項(xiàng)特性，如下圖所示：
?
在這一項(xiàng)后面填寫需要延遲導(dǎo)入的DLL名稱，連接器就會自動幫我們將這些DLL的導(dǎo)入變?yōu)檠舆t導(dǎo)入。
現(xiàn)在我們知道如何使用延遲導(dǎo)入了，那這個(gè)看上去很厲害的機(jī)制是如何實(shí)現(xiàn)的呢？接下來我們來探索一番。在IMAGE_DATA_DIRECTORY中，有一項(xiàng)為IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT，這一項(xiàng)便延遲導(dǎo)入表，IMAGE_DATA_DIRECTORY.VirtualAddress就指向延遲導(dǎo)入表的起始地址。既然是表，肯定又是一個(gè)數(shù)組，每一項(xiàng)都是一個(gè)ImgDelayDescr結(jié)構(gòu)體，和導(dǎo)入表一樣，每一項(xiàng)都代表一個(gè)導(dǎo)入的DLL，來看看定義：
[cpp]?view plaincopy
typedef?struct?ImgDelayDescr?{??
????DWORD???????????grAttrs;????????//?attributes??
????RVA?????????????rvaDLLName;?????//?RVA?to?dll?name??
????RVA?????????????rvaHmod;????????//?RVA?of?module?handle??
????RVA?????????????rvaIAT;?????????//?RVA?of?the?IAT??
????RVA?????????????rvaINT;?????????//?RVA?of?the?INT??
????RVA?????????????rvaBoundIAT;????//?RVA?of?the?optional?bound?IAT??
????RVA?????????????rvaUnloadIAT;???//?RVA?of?optional?copy?of?original?IAT??
????DWORD???????????dwTimeStamp;????//?0?if?not?bound,??
????????????????????????????????????//?O.W.?date/time?stamp?of?DLL?bound?to?(Old?BIND)??
}?ImgDelayDescr,?*?PImgDelayDescr;??
typedef?const?ImgDelayDescr?*???PCImgDelayDescr;??
grAttrs：用來區(qū)分版本，1是新版本，0是舊版本，舊版本中后續(xù)的rvaxxxxxx域使用的都是指針，而新版本中都用RVA，我們只討論新版本。
?
rvaDLLName：一個(gè)RVA，指向?qū)隓LL的名字。
rvaHmod：一個(gè)RVA，指向?qū)隓LL的模塊基地址，這個(gè)基地址在DLL真正被導(dǎo)入前是NULL，導(dǎo)入后才是實(shí)際的基地址。
rvaIAT：一個(gè)RVA,表示導(dǎo)入函數(shù)表，實(shí)際上指向IAT，在DLL加載前，IAT里存放的是一小段代碼的地址，加載后才是真正的導(dǎo)入函數(shù)地址。
rvaINT：一個(gè)RVA，指向?qū)牒瘮?shù)的名字表。
rvaUnloadIAT：延遲導(dǎo)入函數(shù)卸載表。
dwTimeStamp：延遲導(dǎo)入DLL的時(shí)間戳。
定義知道了，那他是怎么被處理的呢？前面提到了，在延遲導(dǎo)入函數(shù)指向的IAT里，默認(rèn)保存的是一段代碼的地址，當(dāng)程序第一次調(diào)用到這個(gè)延遲導(dǎo)入函數(shù)時(shí)，流程會走到那段代碼，這段代碼用來干什么呢？請看一個(gè)真實(shí)的延遲導(dǎo)入函數(shù)的例子：
?
[cpp]?view plaincopy
.text:75C7A363?__imp_load__InternetConnectA@32:????????;?InternetConnectA(x,x,x,x,x,x,x,x)??
.text:75C7A363?????????????????mov?????eax,?offset?__imp__InternetConnectA@32??
.text:75C7A368?????????????????jmp?????__tailMerge_WININET??
這段代碼其實(shí)只有兩行匯編，第一行把導(dǎo)入函數(shù)IAT項(xiàng)的地址放到eax中，然后用一個(gè)jmp跳轉(zhuǎn)走，那么他跳轉(zhuǎn)到哪里了呢？我們繼續(xù)跟蹤：
?
[cpp]?view plaincopy
__tailMerge_WININET?proc?near?????????????
.text:75C6BEF0?????????????????push????ecx??
.text:75C6BEF1?????????????????push????edx??
.text:75C6BEF2?????????????????push????eax??
.text:75C6BEF3?????????????????push????offset?__DELAY_IMPORT_DESCRIPTOR_WININET??
.text:75C6BEF8?????????????????call????__delayLoadHelper??
.text:75C6BEFD?????????????????pop?????edx??
.text:75C6BEFE?????????????????pop?????ecx??
.text:75C6BEFF?????????????????jmp?????eax??
.text:75C6BEFF?__tailMerge_WININET?endp??
?
其中最重要的是push了一個(gè)__DELAY_IMPORT_DESCRIPTOR_WININET，這個(gè)就是上文中看到的ImgDelayDescr結(jié)構(gòu)，他的DLL名字是wininet.dll。之后，CALL了一個(gè)__delayLoadHelper，在這個(gè)函數(shù)里，執(zhí)行了加載DLL，查找導(dǎo)出函數(shù)，填充導(dǎo)入表等一系列操作，函數(shù)結(jié)束時(shí)IAT中已經(jīng)是真正的導(dǎo)入函數(shù)的地址，這個(gè)函數(shù)同時(shí)返回了導(dǎo)入函數(shù)的地址，因此之后的eax里保存的就是函數(shù)地址，最后的jmp eax就跳轉(zhuǎn)到了真實(shí)的導(dǎo)入函數(shù)中。
這個(gè)過程很完美，也很靈巧，但是如果仔細(xì)觀察就會發(fā)現(xiàn)什么地方有點(diǎn)不對勁，你發(fā)現(xiàn)了嗎？__delayLoadHelper的參數(shù)中只有IAT項(xiàng)的偏移和整個(gè)模塊的延遲導(dǎo)入描述__DELAY_IMPORT_DESCRIPTOR_WININET，但是參數(shù)中并沒有要導(dǎo)入函數(shù)的名字。也許你說，名字在__DELAY_IMPORT_DESCRIPTOR_WININET的名字表中，是的，那里確實(shí)有名字，但是別忘了，那是個(gè)表，里面存的是所有要從該模塊導(dǎo)入的函數(shù)名字，而不是“當(dāng)前”這個(gè)被調(diào)用函數(shù)的函數(shù)名?；蛟S你覺得參數(shù)中應(yīng)該有個(gè)索引號，用來表示名字列表中的第幾項(xiàng)是即將被導(dǎo)入的那個(gè)函數(shù)的名字，不幸的是我們也沒有看到參數(shù)中有這樣的信息存在，那Windows執(zhí)行到這里是如何得到名字的呢？MS在這里使用了一個(gè)巧妙的辦法：__DELAY_IMPORT_DESCRIPTOR_WININET中有一項(xiàng)是rvaIAT，前面提到了，這里實(shí)際上就是指向了IAT，而且是該模塊第一個(gè)導(dǎo)入函數(shù)的IAT的偏移，現(xiàn)在我們有兩個(gè)偏移，即將導(dǎo)入的函數(shù)IAT項(xiàng)的偏移（記作RVA1）和要導(dǎo)入模塊第一個(gè)函數(shù)IAT項(xiàng)的偏移（記作RVA0），(RVA1-RVA0)/4 = 導(dǎo)入函數(shù)IAT項(xiàng)在rvaIAT中的下標(biāo)，rvaINT中的名字順序與rvaIAT中的順序是相同的，所以下標(biāo)也相同，這樣就能獲取到導(dǎo)入函數(shù)的名字了。有了模塊名和函數(shù)名，用GetProcAddress就可以獲取到導(dǎo)入函數(shù)的地址了。
上述流程用一張圖來總結(jié)一下：
最后還有兩點(diǎn)要提醒大家：
延遲導(dǎo)入的加載只發(fā)生在函數(shù)第一次被調(diào)用的時(shí)候，之后IAT就填充為正確函數(shù)地址，不會再走_(dá)_delayLoadHelper了。
延遲導(dǎo)入一次只會導(dǎo)入一個(gè)函數(shù)，而不是一次導(dǎo)入整個(gè)模塊的所有函數(shù)。
（六）重定位
前面兩篇?PE文件結(jié)構(gòu)詳解（四）PE導(dǎo)入表?和?PE文件結(jié)構(gòu)詳解（五）延遲導(dǎo)入表?介紹了PE文件中比較常用的兩種導(dǎo)入方式，不知道大家有沒有注意到，在調(diào)用導(dǎo)入函數(shù)時(shí)系統(tǒng)生成的代碼是像下面這樣的：
在這里，IE的iexplorer.exe導(dǎo)入了Kernel32.dll的GetCommandLineA函數(shù)，可以看到這是個(gè)間接call，00401004這個(gè)地址的內(nèi)存里保存了目的地址，根據(jù)圖中顯示的符號信息可知，00401004這個(gè)地址是存在于iexplorer.exe模塊中的，實(shí)際上也就是一項(xiàng)IAT的地址。這個(gè)是IE6的exe中的例子，當(dāng)然在dll中如果導(dǎo)入其他dll中的函數(shù)，結(jié)果也是一樣的。這樣就有一個(gè)問題，代碼里call的地址是一個(gè)模塊內(nèi)的地址，而且是一個(gè)VA，那么如果模塊基地址發(fā)生了變化，這個(gè)地址豈不是就無效了？這個(gè)問題如何解決？
答案是：Windows使用重定位機(jī)制保證以上代碼無論模塊加載到哪個(gè)基址都能正確被調(diào)用。聽起來很神奇，是怎么做到的呢？其實(shí)原理并不很復(fù)雜，這個(gè)過程分三步：
1.編譯的時(shí)候由編譯器識別出哪些項(xiàng)使用了模塊內(nèi)的直接VA，比如push一個(gè)全局變量、函數(shù)地址，這些指令的操作數(shù)在模塊加載的時(shí)候就需要被重定位。
2.鏈接器生成PE文件的時(shí)候?qū)⒕幾g器識別的重定位的項(xiàng)紀(jì)錄在一張表里，這張表就是重定位表，保存在DataDirectory中，序號是?IMAGE_DIRECTORY_ENTRY_BASERELOC。
3.PE文件加載時(shí)，PE 加載器分析重定位表，將其中每一項(xiàng)按照現(xiàn)在的模塊基址進(jìn)行重定位。
以上三步，前兩部涉及到了編譯和鏈接的知識，跟本文的關(guān)系不大，我們直接看第三步，這一步符合本系列的特征。
在查看重定位表的定義前，我們先了解一下他的存儲方式，有助于后面的理解。按照常規(guī)思路，每個(gè)重定位項(xiàng)應(yīng)該是一個(gè)DWORD，里面保存需要重定位的RVA，這樣只需要簡單操作便能找到需要重定位的項(xiàng)。然而，Windows并沒有這樣設(shè)計(jì)，原因是這樣存放太占用空間了，試想一下，加入一個(gè)文件有n個(gè)重定位項(xiàng)，那么就需要占用4*n個(gè)字節(jié)。所以Windows采用了分組的方式，按照重定位項(xiàng)所在的頁面分組，每組保存一個(gè)頁面其實(shí)地址的RVA，頁內(nèi)的每項(xiàng)重定位項(xiàng)使用一個(gè)WORD保存重定位項(xiàng)在頁內(nèi)的偏移，這樣就大大縮小了重定位表的大小。
有了上面的概念，我們現(xiàn)在可以來看一下基址重定位表的定義了：
?
typedef struct _IMAGE_BASE_RELOCATION {
? ? DWORD ? VirtualAddress;
? ? DWORD ? SizeOfBlock;
// ?WORD ? ?TypeOffset[1];
} IMAGE_BASE_RELOCATION;
typedef IMAGE_BASE_RELOCATION UNALIGNED * PIMAGE_BASE_RELOCATION;
VirtualAddress：頁起始地址RVA。
SizeOfBlock：表示該分組保存了幾項(xiàng)重定位項(xiàng)。
TypeOffset：這個(gè)域有兩個(gè)含義，大家都知道，頁內(nèi)偏移用12位就可以表示，剩下的高4位用來表示重定位的類型。而事實(shí)上，Windows只用了一種類型IMAGE_REL_BASED_HIGHLOW ?數(shù)值是 3。
好了，有了以上知識，相信大家可以很容易的寫出自己修正重定位表的代碼，不如自己做個(gè)練習(xí)驗(yàn)證一下吧。
本文?by evil.eagle 轉(zhuǎn)載的時(shí)候請注明出處。http://blog.csdn.net/evileagle/article/details/12886949
最后，還是總結(jié)一下，哪些項(xiàng)目需要被重定位呢？
1.代碼中使用全局變量的指令，因?yàn)槿肿兞恳欢ㄊ悄K內(nèi)的地址，而且使用全局變量的語句在編譯后會產(chǎn)生一條引用全局變量基地址的指令。
2.將模塊函數(shù)指針賦值給變量或作為參數(shù)傳遞，因?yàn)橘x值或傳遞參數(shù)是會產(chǎn)生mov和push指令，這些指令需要直接地址。
3.C++中的構(gòu)造函數(shù)和析構(gòu)函數(shù)賦值虛函數(shù)表指針，虛函數(shù)表中的每一項(xiàng)本身就是重定位項(xiàng)，為什么呢？大家自己考慮一下吧，不難哦~
---------------------?
作者：evileagle?
來源：CSDN?
原文：https://blog.csdn.net/evileagle/article/details/12886949?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！
總結(jié)
以上是生活随笔為你收集整理的【转】PE文件结构详解--（完整版）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【转】深入浅出图解C#堆与栈 C# He
- 下一篇： Office Web Apps安装部署(