轉自：https://blog.csdn.net/evileagle/article/details/12886949
（一）基本概念
PE（Portable Execute）文件是Windows下可執行文件的總稱，常見的有DLL，EXE，OCX，SYS等，事實上，一個文件是否是PE文件與其擴展名無關，PE文件可以是任何擴展名。那Windows是怎麼區分可執行文件和非可執行文件的呢？我們調用LoadLibrary傳遞了一個文件名，系統是如何判斷這個文件是一個合法的動態庫呢？這就涉及到PE文件結構了。
PE文件的結構一般來說如下圖所示：從起始位置開始依次是DOS頭，NT頭，節表以及具體的節。
DOS頭是用來兼容MS-DOS操作系統的，目的是當這個文件在MS-DOS上運行時提示一段文字，大部分情況下是：This program cannot be run in DOS mode.還有一個目的，就是指明NT頭在文件中的位置。
NT頭包含windows PE文件的主要信息，其中包括一個‘PE’字樣的簽名，PE文件頭（IMAGE_FILE_HEADER）和PE可選頭（IMAGE_OPTIONAL_HEADER32），頭部的詳細結構以及其具體意義在PE文件頭文章中詳細描述。
節表：是PE文件後續節的描述，windows根據節表的描述加載每個節。
節：每個節實際上是一個容器，可以包含代碼、數據等等，每個節可以有獨立的內存權限，比如代碼節默認有讀/執行權限，節的名字和數量可以自己定義，未必是上圖中的三個。
當一個PE文件被加載到內存中以後，我們稱之爲“映象”（image），一般來說，PE文件在硬盤上和在內存裏是不完全一樣的，被加載到內存以後其佔用的虛擬地址空間要比在硬盤上佔用的空間大一些，這是因爲各個節在硬盤上是連續的，而在內存中是按頁對齊的，所以加載到內存以後節之間會出現一些“空洞”。
因爲存在這種對齊，所以在PE結構內部，表示某個位置的地址採用了兩種方式，針對在硬盤上存儲文件中的地址，稱爲原始存儲地址或物理地址表示距離文件頭的偏移；另外一種是針對加載到內存以後映象中的地址，稱爲相對虛擬地址（RVA），表示相對內存映象頭的偏移。
然而CPU的某些指令是需要使用絕對地址的，比如取全局變量的地址，傳遞函數的地址編譯以後的彙編指令中肯定需要用到絕對地址而不是相對映象頭的偏移，因此PE文件會建議操作系統將其加載到某個內存地址（這個叫基地址），編譯器便根據這個地址求出代碼中一些全局變量和函數的地址，並將這些地址用到對應的指令中。例如在IDA裏看上去是這個樣子：
這種表示方式叫做虛擬地址（VA）。
也許有人要問，既然有VA這麼簡單的表示方式爲什麼還要有前面的RVA呢？因爲雖然PE文件爲自己指定加載的基地址，但是windows有茫茫多的DLL，而且每個軟件也有自己的DLL，如果指定的地址已經被別的DLL佔了怎麼辦？如果PE文件無法加載到預期的地址，那麼系統會幫他重新選擇一個合適的基地址將他加載到此處，這時原有的VA就全部失效了，NT頭保存了PE文件加載所需的信息，在不知道PE會加載到哪個基地址之前，VA是無效的，所以在PE文件頭中大部分是使用RVA來表示地址的，而在代碼中是用VA表示全局變量和函數地址的。那又有人要問了，既然加載基址變了以後VA都失效了，那存在於代碼中的那些VA怎麼辦呢？答案是：重定位。系統有自己的辦法修正這些值，到後續重定位表的文章中會詳細描述。既然有重定位，爲什麼NT頭不能依靠重定位採用VA表示地址呢（十萬個爲什麼）？因爲不是所有的PE都有重定位，早期的EXE就是沒有重定位的。
我們都知道PE文件可以導出函數讓其他的PE文件使用，也可以從其他PE文件導入函數，這些是如何做到的？PE文件通過導出表指明自己導出那些函數，通過導入表指明需要從哪些模塊導入哪些函數。導入和導出表的具體結構會在單獨的文章中詳細解釋。
（二）可執行文件頭
在PE文件結構詳解（一）基本概念裏，解釋了一些PE文件的一些基本概念，從這篇開始，將詳細講解PE文件中的重要結構。
瞭解一個文件的格式，最應該首先了解的就是這個文件的文件頭的含義，因爲幾乎所有的文件格式，重要的信息都包含在頭部，順着頭部的信息，可以引導系統解析整個文件。所以，我們先來認識一下PE文件的頭部格式。還記得上篇裏的那個圖嗎？
DOS頭和NT頭就是PE文件中兩個重要的文件頭。
一、DOS頭
DOS頭的作用是兼容MS-DOS操作系統中的可執行文件，對於32位PE文件來說，DOS所起的作用就是顯示一行文字，提示用戶：我需要在32位windows上纔可以運行。我認爲這是個善意的玩笑，因爲他並不像顯示的那樣不能運行，其實已經運行了，只是在DOS上沒有幹用戶希望看到的工作而已，好吧，我承認這不是重點。但是，至少我們看一下這個頭是如何定義的：
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;
我們只需要關注兩個域：
e_magic：一個WORD類型，值是一個常數0x4D5A，用文本編輯器查看該值位‘MZ’，可執行文件必須都是'MZ'開頭。
e_lfanew：爲32位可執行文件擴展的域，用來表示DOS頭之後的NT頭相對文件起始地址的偏移。
二、NT頭
順着DOS頭中的e_lfanew，我們很容易可以找到NT頭，這個纔是32位PE文件中最有用的頭，定義如下:
typedef struct _IMAGE_NT_HEADERS {
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;
下圖是一張真實的PE文件頭結構以及其各個域的取值：
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;
每個域的具體含義如下：
Machine：該文件的運行平臺，是x86、x64還是I64等等，可以是下面值裏的某一個。
#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：該PE文件中有多少個節，也就是節表中的項數。
TimeDateStamp：PE文件的創建時間，一般有連接器填寫。
PointerToSymbolTable：COFF文件符號表在文件中的偏移。
NumberOfSymbols：符號表的數量。
SizeOfOptionalHeader：緊隨其後的可選頭的大小。
Characteristics：可執行文件的屬性，可以是下面這些值按位相或。
#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加載器加載時用到，如果加載器發現PE文件頭中定義的一些屬性不滿足當前的運行環境，將會終止加載該PE。
另一個重要的頭就是PE可選頭，別看他名字叫可選頭，其實一點都不能少，不過，它在不同的平臺下是不一樣的，例如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：代碼段的長度，如果有多個代碼段，則是代碼段長度的總和。
SizeOfInitializedData：初始化的數據長度。
SizeOfUninitializedData：未初始化的數據長度。
AddressOfEntryPoint：程序入口的RVA，對於exe這個地址可以理解爲WinMain的RVA。對於DLL，這個地址可以理解爲DllMain的RVA，如果是驅動程序，可以理解爲DriverEntry的RVA。當然，實際上入口點並非是WinMain，DllMain和DriverEntry，在這些函數之前還有一系列初始化要完成，當然，這些不是本文的重點。
BaseOfCode：代碼段起始地址的RVA。
BaseOfData：數據段起始地址的RVA。
ImageBase：映象（加載到內存中的PE文件）的基地址，這個基地址是建議，對於DLL來說，如果無法加載到這個地址，系統會自動爲其選擇地址。
SectionAlignment：節對齊，PE中的節被加載到內存時會按照這個域指定的值來對齊，比如這個值是0x1000，那麼每個節的起始地址的低12位都爲0。
FileAlignment：節在文件中按此值對齊，SectionAlignment必須大於或等於FileAlignment。
MajorOperatingSystemVersion、MinorOperatingSystemVersion：所需操作系統的版本號，隨着操作系統版本越來越多，這個好像不是那麼重要了。
MajorImageVersion、MinorImageVersion：映象的版本號，這個是開發者自己指定的，由連接器填寫。
MajorSubsystemVersion、MinorSubsystemVersion：所需子系統版本號。
Win32VersionValue：保留，必須爲0。
SizeOfImage：映象的大小，PE文件加載到內存中空間是連續的，這個值指定佔用虛擬空間的大小。
SizeOfHeaders：所有文件頭（包括節表）的大小，這個值是以FileAlignment對齊的。
CheckSum：映象文件的校驗和。
Subsystem：運行該PE文件所需的子系統，可以是下面定義中的某一個：
#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：運行時爲每個線程棧保留內存的大小。
SizeOfStackCommit：運行時每個線程棧初始佔用內存大小。
SizeOfHeapReserve：運行時爲進程堆保留內存大小。
SizeOfHeapCommit：運行時進程堆初始佔用內存大小。
LoaderFlags：保留，必須爲0。
NumberOfRvaAndSizes：數據目錄的項數，即下面這個數組的項數。
DataDirectory：數據目錄，這是一個數組，數組的項定義如下：
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
VirtualAddress：是一個RVA。
Size：是一個大小。
這兩個數有什麼用呢？一個是地址，一個是大小，可以看出這個數據目錄項定義的是一個區域。那他定義的是什麼東西的區域呢？前面說了，DataDirectory是個數組，數組中的每一項對應一個特定的數據結構，包括導入表，導出表等等，根據不同的索引取出來的是不同的結構，頭文件裏定義各個項表示哪個結構，如下面的代碼所示：
#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
看到這麼多的定義，大家估計要頭疼了，好不容易要把PE文件頭學習完了，又“從天而降”一大波的結構。不用緊張，有了前面的知識，後面的部分就迎刃而解了。下一篇開始將沿着這個數據目錄分解其餘部分，繼續關注哦~
（三）PE導出表
上篇文章 PE文件結構詳解（二）可執行文件頭 的結尾出現了一個大數組，這個數組中的每一項都是一個特定的結構，通過函數獲取數組中的項可以用RtlImageDirectoryEntryToData函數，DataDirectory中的每一項都可以用這個函數獲取，函數原型如下：
PVOID NTAPI RtlImageDirectoryEntryToData(PVOID Base, BOOLEAN MappedAsImage, USHORT Directory, PULONG Size);
Base：模塊基地址。
MappedAsImage：是否映射爲映象。
Directory：數據目錄項的索引。
#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：對應數據目錄項的大小，比如Directory爲0，則表示導出表的大小。
返回值表示數據目錄項的起始地址。
這次來看看第一項：導出表。
導出表是用來描述模塊中的導出函數的結構，如果一個模塊導出了函數，那麼這個函數會被記錄在導出表中，這樣通過GetProcAddress函數就能動態獲取到函數的地址。函數導出的方式有兩種，一種是按名字導出，一種是按序號導出。這兩種導出方式在導出表中的描述方式也不相同。模塊的導出函數可以通過Dependency walker工具來查看：
上圖中紅框位置顯示的就是模塊的導出函數，有時候顯示的導出函數名字中有一些符號，像 ??0CP2PDownloadUIInterface@@QAE@ABV0@@Z，這種是導出了C++的函數名，編譯器將名字進行了修飾。
下面看一下導出表的定義吧：
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;
結構還算比較簡單，具體每一項的含義如下：
Characteristics：現在沒有用到，一般爲0。
TimeDateStamp：導出表生成的時間戳，由連接器生成。
MajorVersion，MinorVersion：看名字是版本，實際貌似沒有用，都是0。
Name：模塊的名字。
Base：序號的基數，按序號導出函數的序號值從Base開始遞增。
NumberOfFunctions：所有導出函數的數量。
NumberOfNames：按名字導出函數的數量。
AddressOfFunctions：一個RVA，指向一個DWORD數組，數組中的每一項是一個導出函數的RVA，順序與導出序號相同。
AddressOfNames：一個RVA，依然指向一個DWORD數組，數組中的每一項仍然是一個RVA，指向一個表示函數名字。
AddressOfNameOrdinals：一個RVA，還是指向一個WORD數組，數組中的每一項與AddressOfNames中的每一項對應，表示該名字的函數在AddressOfFunctions中的序號。
第一次接觸這個結構的童鞋被後面的5項搞暈了吧，理解這個結構比結構本身看上去要複雜一些，文字描述不管怎麼說都顯得晦澀，所謂一圖勝千言，無圖無真相，直接上圖：
在上圖中，AddressOfNames指向一個數組，數組裏保存着一組RVA，每個RVA指向一個字符串，這個字符串即導出的函數名，與這個函數名對應的是AddressOfNameOrdinals中的對應項。獲取導出函數地址時，先在AddressOfNames中找到對應的名字，比如Func2，他在AddressOfNames中是第二項，然後從AddressOfNameOrdinals中取出第二項的值，這裏是2，表示函數入口保存在AddressOfFunctions這個數組中下標爲2的項裏，即第三項，取出其中的值，加上模塊基地址便是導出函數的地址。如果函數是以序號導出的，那麼查找的時候直接用序號減去Base，得到的值就是函數在AddressOfFunctions中的下標。
用代碼實現如下：
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導入表
PE文件結構詳解（二）可執行文件頭的最後展示了一個數組，PE文件結構詳解（三）PE導出表中解釋了其中第一項的格式，本篇文章來揭示這個數組中的第二項：IMAGE_DIRECTORY_ENTRY_IMPORT，即導入表。
也許大家注意到過，在IMAGE_DATA_DIRECTORY中，有幾項的名字都和導入表有關係，其中包括：IMAGE_DIRECTORY_ENTRY_IMPORT，IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT，IMAGE_DIRECTORY_ENTRY_IAT和IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT這幾個導入都是用來幹什麼的，他們之間又是什麼關係呢？聽我慢慢道來。
IMAGE_DIRECTORY_ENTRY_IMPORT就是我們通常所知道的導入表，在PE文件加載時，會根據這個表裏的內容加載依賴的DLL，並填充所需函數的地址。
IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT叫做綁定導入表，在第一種導入表導入地址的修正是在PE加載時完成，如果一個PE文件導入的DLL或者函數多那麼加載起來就會略顯的慢一些，所以出現了綁定導入，在加載以前就修正了導入表，這樣就會快一些。
IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT叫做延遲導入表，一個PE文件也許提供了很多功能，也導入了很多其他DLL，但是並非每次加載都會用到它提供的所有功能，也不一定會用到它需要導入的所有DLL，因此延遲導入就出現了，只有在一個PE文件真正用到需要的DLL，這個DLL纔會被加載，甚至於只有真正使用某個導入函數，這個函數地址纔會被修正。
IMAGE_DIRECTORY_ENTRY_IAT是導入地址表，前面的三個表其實是導入函數的描述，真正的函數地址是被填充在導入地址表中的。
舉個實際的例子，看一下下面這張圖：
這個代碼調用了一個RegOpenKeyW的導入函數，我們看到其opcode是FF 15 00 00 19 30氣質FF 15表示這是一個間接調用，即call dword ptr [30190000] ;這表示要調用的地址存放在30190000這個地址中，而30190000這個地址在導入地址表的範圍內，當模塊加載時，PE 加載器會根據導入表中描述的信息修正30190000這個內存中的內容。
那麼導入表裏到底記錄了那些信息，如何根據這些信息修正IAT呢？我們一起來看一下導入表的定義：
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，會得到一個如上結構的指針，實際上指向一個上述結構的數組，每個導入的DLL都會成爲數組中的一項，也就是說，一個這樣的結構對應一個導入的DLL。
Characteristics和OriginalFirstThunk：一個聯合體，如果是數組的最後一項Characteristics爲0，否則OriginalFirstThunk保存一個RVA，指向一個IMAGE_THUNK_DATA的數組，這個數組中的每一項表示一個導入函數。
TimeDateStamp：映象綁定前，這個值是0，綁定後是導入模塊的時間戳。
ForwarderChain：轉發鏈，如果沒有轉發器，這個值是-1。
Name：一個RVA，指向導入模塊的名字，所以一個IMAGE_IMPORT_DESCRIPTOR描述一個導入的DLL。
FirstThunk：也是一個RVA，也指向一個IMAGE_THUNK_DATA數組。
既然OriginalFirstThunk與FirstThunk都指向一個IMAGE_THUNK_DATA數組，而且這兩個域的名字都長得很像，他倆有什麼區別呢？爲了解答這個問題，先來認識一下IMAGE_THUNK_DATA結構：
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是轉發用的，暫時不用考慮，Function表示函數地址，如果是按序號導入Ordinal就有用了，若是按名字導入AddressOfData便指向名字信息。可以看出這個結構體就是一個大的union，大家都知道union雖包含多個域但是在不同時刻代表不同的意義那到底應該是名字還是序號，該如何區分呢？可以通過Ordinal判斷，如果Ordinal的最高位是1，就是按序號導入的，這時候，低16位就是導入序號，如果最高位是0，則AddressOfData是一個RVA，指向一個IMAGE_IMPORT_BY_NAME結構，用來保存名字信息，由於Ordinal和AddressOfData實際上是同一個內存空間，所以AddressOfData其實只有低31位可以表示RVA，但是一個PE文件不可能超過2G，所以最高位永遠爲0，這樣設計很合理的利用了空間。實際編寫代碼的時候微軟提供兩個宏定義處理序號導入：IMAGE_SNAP_BY_ORDINAL判斷是否按序號導入，IMAGE_ORDINAL用來獲取導入序號。
這時我們可以回頭看看OriginalFirstThunk與FirstThunk，OriginalFirstThunk指向的IMAGE_THUNK_DATA數組包含導入信息，在這個數組中只有Ordinal和AddressOfData是有用的，因此可以通過OriginalFirstThunk查找到函數的地址。FirstThunk則略有不同，在PE文件加載以前或者說在導入表未處理以前，他所指向的數組與OriginalFirstThunk中的數組雖不是同一個，但是內容卻是相同的，都包含了導入信息，而在加載之後，FirstThunk中的Function開始生效，他指向實際的函數地址，因爲FirstThunk實際上指向IAT中的一個位置，IAT就充當了IMAGE_THUNK_DATA數組，加載完成後，這些IAT項就變成了實際的函數地址，即Function的意義。還是上個圖對比一下：
上圖是加載前。
上圖是加載後。
最後總結一下：
導入表其實是一個IMAGE_IMPORT_DESCRIPTOR的數組，每個導入的DLL對應一個IMAGE_IMPORT_DESCRIPTOR。
IMAGE_IMPORT_DESCRIPTOR包含兩個IMAGE_THUNK_DATA數組，數組中的每一項對應一個導入函數。
加載前OriginalFirstThunk與FirstThunk的數組都指向名字信息，加載後FirstThunk數組指向實際的函數地址。
（五）延遲導入表
PE文件結構詳解（四）PE導入表講了一般的PE導入表，這次我們來看一下另外一種導入表：延遲導入（Delay Import）。看名字就知道，這種導入機制導入其他DLL的時機比較“遲”，爲什麼要遲呢？因爲有些導入函數可能使用的頻率比較低，或者在某些特定的場合纔會用到，而有些函數可能要在程序運行一段時間後纔會用到，這些函數可以等到他實際使用的時候再去加載對應的DLL，而沒必要再程序一裝載就初始化好。
這個機制聽起來很誘人，因爲他可以加快啓動速度，我們應該如何利用這項機制呢？VC有一個選項，可以讓我們很方便的使用到這項特性，如下圖所示：
在這一項後面填寫需要延遲導入的DLL名稱，連接器就會自動幫我們將這些DLL的導入變爲延遲導入。
現在我們知道如何使用延遲導入了，那這個看上去很厲害的機制是如何實現的呢？接下來我們來探索一番。在IMAGE_DATA_DIRECTORY中，有一項爲IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT，這一項便延遲導入表，IMAGE_DATA_DIRECTORY.VirtualAddress就指向延遲導入表的起始地址。既然是表，肯定又是一個數組，每一項都是一個ImgDelayDescr結構體，和導入表一樣，每一項都代表一個導入的DLL，來看看定義：
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：用來區分版本，1是新版本，0是舊版本，舊版本中後續的rvaxxxxxx域使用的都是指針，而新版本中都用RVA，我們只討論新版本。
rvaDLLName：一個RVA，指向導入DLL的名字。
rvaHmod：一個RVA，指向導入DLL的模塊基地址，這個基地址在DLL真正被導入前是NULL，導入後纔是實際的基地址。
rvaIAT：一個RVA,表示導入函數表，實際上指向IAT，在DLL加載前，IAT裏存放的是一小段代碼的地址，加載後纔是真正的導入函數地址。
rvaINT：一個RVA，指向導入函數的名字表。
rvaUnloadIAT：延遲導入函數卸載表。
dwTimeStamp：延遲導入DLL的時間戳。
定義知道了，那他是怎麼被處理的呢？前面提到了，在延遲導入函數指向的IAT裏，默認保存的是一段代碼的地址，當程序第一次調用到這個延遲導入函數時，流程會走到那段代碼，這段代碼用來幹什麼呢？請看一個真實的延遲導入函數的例子：
.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
這段代碼其實只有兩行彙編，第一行把導入函數IAT項的地址放到eax中，然後用一個jmp跳轉走，那麼他跳轉到哪裏了呢？我們繼續跟蹤：
__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了一個__DELAY_IMPORT_DESCRIPTOR_WININET，這個就是上文中看到的ImgDelayDescr結構，他的DLL名字是wininet.dll。之後，CALL了一個__delayLoadHelper，在這個函數裏，執行了加載DLL，查找導出函數，填充導入表等一系列操作，函數結束時IAT中已經是真正的導入函數的地址，這個函數同時返回了導入函數的地址，因此之後的eax裏保存的就是函數地址，最後的jmp eax就跳轉到了真實的導入函數中。
這個過程很完美，也很靈巧，但是如果仔細觀察就會發現什麼地方有點不對勁，你發現了嗎？__delayLoadHelper的參數中只有IAT項的偏移和整個模塊的延遲導入描述__DELAY_IMPORT_DESCRIPTOR_WININET，但是參數中並沒有要導入函數的名字。也許你說，名字在__DELAY_IMPORT_DESCRIPTOR_WININET的名字表中，是的，那裏確實有名字，但是別忘了，那是個表，裏面存的是所有要從該模塊導入的函數名字，而不是“當前”這個被調用函數的函數名。或許你覺得參數中應該有個索引號，用來表示名字列表中的第幾項是即將被導入的那個函數的名字，不幸的是我們也沒有看到參數中有這樣的信息存在，那Windows執行到這裏是如何得到名字的呢？MS在這裏使用了一個巧妙的辦法：__DELAY_IMPORT_DESCRIPTOR_WININET中有一項是rvaIAT，前面提到了，這裏實際上就是指向了IAT，而且是該模塊第一個導入函數的IAT的偏移，現在我們有兩個偏移，即將導入的函數IAT項的偏移（記作RVA1）和要導入模塊第一個函數IAT項的偏移（記作RVA0），(RVA1-RVA0)/4 = 導入函數IAT項在rvaIAT中的下標，rvaINT中的名字順序與rvaIAT中的順序是相同的，所以下標也相同，這樣就能獲取到導入函數的名字了。有了模塊名和函數名，用GetProcAddress就可以獲取到導入函數的地址了。
上述流程用一張圖來總結一下：
最後還有兩點要提醒大家：
延遲導入的加載只發生在函數第一次被調用的時候，之後IAT就填充爲正確函數地址，不會再走__delayLoadHelper了。
延遲導入一次只會導入一個函數，而不是一次導入整個模塊的所有函數。
（六）重定位
前面兩篇 PE文件結構詳解（四）PE導入表 和 PE文件結構詳解（五）延遲導入表 介紹了PE文件中比較常用的兩種導入方式，不知道大家有沒有注意到，在調用導入函數時系統生成的代碼是像下面這樣的：
在這裏，IE的iexplorer.exe導入了Kernel32.dll的GetCommandLineA函數，可以看到這是個間接call，00401004這個地址的內存裏保存了目的地址，根據圖中顯示的符號信息可知，00401004這個地址是存在於iexplorer.exe模塊中的，實際上也就是一項IAT的地址。這個是IE6的exe中的例子，當然在dll中如果導入其他dll中的函數，結果也是一樣的。這樣就有一個問題，代碼裏call的地址是一個模塊內的地址，而且是一個VA，那麼如果模塊基地址發生了變化，這個地址豈不是就無效了？這個問題如何解決？
答案是：Windows使用重定位機制保證以上代碼無論模塊加載到哪個基址都能正確被調用。聽起來很神奇，是怎麼做到的呢？其實原理並不很複雜，這個過程分三步：
1.編譯的時候由編譯器識別出哪些項使用了模塊內的直接VA，比如push一個全局變量、函數地址，這些指令的操作數在模塊加載的時候就需要被重定位。
2.鏈接器生成PE文件的時候將編譯器識別的重定位的項紀錄在一張表裏，這張表就是重定位表，保存在DataDirectory中，序號是 IMAGE_DIRECTORY_ENTRY_BASERELOC。
3.PE文件加載時，PE 加載器分析重定位表，將其中每一項按照現在的模塊基址進行重定位。
以上三步，前兩部涉及到了編譯和鏈接的知識，跟本文的關係不大，我們直接看第三步，這一步符合本系列的特徵。
在查看重定位表的定義前，我們先了解一下他的存儲方式，有助於後面的理解。按照常規思路，每個重定位項應該是一個DWORD，裏面保存需要重定位的RVA，這樣只需要簡單操作便能找到需要重定位的項。然而，Windows並沒有這樣設計，原因是這樣存放太佔用空間了，試想一下，加入一個文件有n個重定位項，那麼就需要佔用4*n個字節。所以Windows採用了分組的方式，按照重定位項所在的頁面分組，每組保存一個頁面其實地址的RVA，頁內的每項重定位項使用一個WORD保存重定位項在頁內的偏移，這樣就大大縮小了重定位表的大小。
有了上面的概念，我們現在可以來看一下基址重定位表的定義了：
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：表示該分組保存了幾項重定位項。
TypeOffset：這個域有兩個含義，大家都知道，頁內偏移用12位就可以表示，剩下的高4位用來表示重定位的類型。而事實上，Windows只用了一種類型IMAGE_REL_BASED_HIGHLOW 數值是 3。
好了，有了以上知識，相信大家可以很容易的寫出自己修正重定位表的代碼，不如自己做個練習驗證一下吧。
本文 by evil.eagle 轉載的時候請註明出處。http://blog.csdn.net/evileagle/article/details/12886949
最後，還是總結一下，哪些項目需要被重定位呢？
1.代碼中使用全局變量的指令，因爲全局變量一定是模塊內的地址，而且使用全局變量的語句在編譯後會產生一條引用全局變量基地址的指令。
2.將模塊函數指針賦值給變量或作爲參數傳遞，因爲賦值或傳遞參數是會產生mov和push指令，這些指令需要直接地址。
3.C++中的構造函數和析構函數賦值虛函數表指針，虛函數表中的每一項本身就是重定位項，爲什麼呢？大家自己考慮一下吧，不難哦~