日韩性视频-久久久蜜桃-www中文字幕-在线中文字幕av-亚洲欧美一区二区三区四区-撸久久-香蕉视频一区-久久无码精品丰满人妻-国产高潮av-激情福利社-日韩av网址大全-国产精品久久999-日本五十路在线-性欧美在线-久久99精品波多结衣一区-男女午夜免费视频-黑人极品ⅴideos精品欧美棵-人人妻人人澡人人爽精品欧美一区-日韩一区在线看-欧美a级在线免费观看

歡迎訪問 生活随笔!

生活随笔

當前位置: 首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【转】PE文件结构详解--(完整版)

發布時間:2023/12/10 编程问答 49 豆豆
生活随笔 收集整理的這篇文章主要介紹了 【转】PE文件结构详解--(完整版) 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

(一)基本概念

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,來看看定義:

  • [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:用來區分版本,1是新版本,0是舊版本,舊版本中后續的rvaxxxxxx域使用的都是指針,而新版本中都用RVA,我們只討論新版本。

    ?

    rvaDLLName:一個RVA,指向導入DLL的名字。

    rvaHmod:一個RVA,指向導入DLL的模塊基地址,這個基地址在DLL真正被導入前是NULL,導入后才是實際的基地址。

    rvaIAT:一個RVA,表示導入函數表,實際上指向IAT,在DLL加載前,IAT里存放的是一小段代碼的地址,加載后才是真正的導入函數地址。

    rvaINT:一個RVA,指向導入函數的名字表。

    rvaUnloadIAT:延遲導入函數卸載表。

    dwTimeStamp:延遲導入DLL的時間戳。

    定義知道了,那他是怎么被處理的呢?前面提到了,在延遲導入函數指向的IAT里,默認保存的是一段代碼的地址,當程序第一次調用到這個延遲導入函數時,流程會走到那段代碼,這段代碼用來干什么呢?請看一個真實的延遲導入函數的例子:

    ?

  • [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??


  • 這段代碼其實只有兩行匯編,第一行把導入函數IAT項的地址放到eax中,然后用一個jmp跳轉走,那么他跳轉到哪里了呢?我們繼續跟蹤:

    ?

  • [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了一個__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++中的構造函數和析構函數賦值虛函數表指針,虛函數表中的每一項本身就是重定位項,為什么呢?大家自己考慮一下吧,不難哦~


    ---------------------?
    作者:evileagle?
    來源:CSDN?
    原文:https://blog.csdn.net/evileagle/article/details/12886949?
    版權聲明:本文為博主原創文章,轉載請附上博文鏈接!

    創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎

    總結

    以上是生活随笔為你收集整理的【转】PE文件结构详解--(完整版)的全部內容,希望文章能夠幫你解決所遇到的問題。

    如果覺得生活随笔網站內容還不錯,歡迎將生活随笔推薦給好友。