PE文件结构

PE文件结构

现在让我们开始挖掘PE文件的实际格式吧。我要从文件的开头处开始，描述存在于所有PE文件中的数据结构。然后我会描述PE文件的节中具体的数据结构（例如导入表与资源）。下面我要讨论的所有数据结构都被定义在WINNT.H文件中，除非我特别声明。

在许多情况下，32位和64位数据结构都是成对出现的——例如IMAGE_NT_HEADERS32和IMAGE_NT_HEADERS64。这些结构几乎总是一样的，除了相应的64位结构中一些域的数据宽度更宽。如果你想编写可移植的代码，在WINNT.H文件中有相应的宏，这些宏可以选择合适的32位或64位结构，并且把它们用一个不能表明大小的别名来代替（在上面的例子中，它就是IMAGE_NT_HEADERS）。结构的选择依赖于你想在何种模式下编译（具体来说就是是否定义了_WIN64）。只有在你所需编译成的PE文件的大小属性与你正在编译的平台的大小属性不同时才需要使用具体的32位或64位结构。

MS-DOS文件头

每一个PE文件都以一个小的MS-DOS®可执行文件开始。早期的Windows需要这个小占位程序，因为那时很多用户还未使用Windows。当可执行文件在没有安装Windows的机器上运行时，这个程序至少可以输出一条消息，用来指明它需要运行在Windows平台上。

PE文件开头是传统的MS-DOS文件头，其中前面的一部分被称为IMAGE_DOS_HEADER。此结构中最重要的两个域是e_magic和e_lfanew。e_lfanew域保存的是真正的PE文件头的偏移。e_magic域需要被设置成0x5A4D。它被定义为IMAGE_DOS_SIGNATURE。如果用ASCII码表示，0x5A4D就是“MZ”，这是Mark Zbikowski的姓名缩写，他是最初的MS-DOS设计者之一。

IMAGE_NT_HEADERS文件头

IMAGE_NT_HEADERS结构是存储PE文件细节的主要位置。它的偏移由文件开头的IMAGE_DOS_HEADER结构的e_lfanew域给出。实际有两种版本的IMAGE_NT_HEADER结构，一种供32位可执行文件使用，另一种供64位使用。它们之间的差别非常小，因此我在讨论中把它们看作相同的结构。区别这两种结构惟一正确的、由Microsoft官方认可的方法是通过IMAGE_OPTION_HEADER结构（很快就会讲到）的Magic域。

IMAGE_NT_HEADER结构由三个域组成：
typedef struct _IMAGE_NT_HEADERS {
   DWORD Signature;
    IMAGE_FILE_HEADER FileHeader;
    IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;
在一个合法的PE文件中，Signature域被设置成0x00004550。用ASCII码表示为“PE\0\0”。它被定义为IMAGE_NT_SIGNATURE。第二个域是一个类型为IMAGE_FILE_HEADER的结构，这个结构在PE文件出现之前就已经出现了。它包含了关于文件的一些基本信息。最重要的是，其中有一个域指明了跟在这个结构后面的可选文件头的大小。在PE文件中，这个可选文件头是必须的，但它仍然被称为IMAGE_OPTIONAL_HEADER。

下表列出了IMAGE_FILE_HEADER结构的各个域及相应的描述。这个结构也可以在COFF格式的OBJ文件开头找到。

 

大小	域	描述
WORD	Machine	目标平台CPU的类型。常用的值有： IMAGE_FILE_MACHINE_I386    0x014c // Intel 386 IMAGE_FILE_MACHINE_IA64    0x0200 // Intel 64
WORD	NumberOfSections	指示节表中节的数目。节表紧跟着IMAGE_NT_HEADERS结构。
DWORD	TimeDateStamp	指示文件创建时间。这个值是从格林尼治时间（GMT）1970年1月1日00:00以来的总秒数。它比文件系统所指明的日期/时间更精确。使用_ctime函数可以很容易地把这个值转换成可读性比较好的字符串（这个函数与时区相关）。另一个可用于这个值的函数gmtime也比较有用。
DWORD	PointerToSymbolTable	COFF符号表的文件偏移。Microsoft的PECOFF规范5.4节描述了COFF符号表。COFF符号表在PE文件中非常少见，因为新的调试符号格式已经取代了它。在Visual Studio .NET之前，可以使用/DEBUGTYPE:COFF这个链接器选项来指定创建COFF符号表。它总是存在于OBJ文件中。如果不存在符号表的话，将它设置为0。
DWORD	NumberOfSymbols	符号表中的符号数（如果存在的话）。COFF符号是一个大小固定的结构，这个域用来定位COFF符号表的结尾。紧跟着COFF符号表的是一个字符串表，它用来保存长符号名。
WORD	SizeOfOptionalHeader	IMAGE_FILE_HEADER结构后面的可选数据的大小。在PE文件中，这个可选数据就是IMAGE_OPTIONAL_HEADER。这个大小在32位和64位文件中是不同的。对于32位PE文件来说，它通常是224；对于64位PE32+文件来说，它通常是240。但是，它们只是最小值，可能有更大的值。
WORD	Characteristics	指示文件属性的一组位标志。这些标志的合法值就是WINNT.H文件中定义的IMAGE_FILE_xxx值。一些常见的值列于下表。

下表列出了常用的IMAGE_FILE_xxx值：

标志	描述
IMAGE_FILE_RELOCS_STRIPPED	重定位信息已经从文件中移除。
IMAGE_FILE_EXECUTABLE_IMAGE	文件是可执行映像。
IMAGE_FILE_AGGRESSIVE_WS_TRIM	让操作系统尽量减小工作集（working set）。
IMAGE_FILE_LARGE_ADDRESS_AWARE	此应用程序可以处理大于2GB的地址。
IMAGE_FILE_32BIT_MACHINE	需要字长为32位的机器。
IMAGE_FILE_DEBUG_STRIPPED	调试信息已经被移到.DBG文件中。
IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP	如果可执行映像在可移动媒体上，把它复制到交换文件中并从交换文件中运行。
IMAGE_FILE_NET_RUN_FROM_SWAP	如果可执行映像在网络上，把它复制到交换文件中并从交换文件中运行。
IMAGE_FILE_DLL	文件是DLL。
IMAGE_FILE_UP_SYSTEM_ONLY	只能运行于单处理器机器上。

 

 

 

 

 

 

 

   下表列出了IMAGE_OPTIONAL_HEADER结构的成员：

大小	域	描述
WORD	Magic	一个特征字，用于表明文件头的类型。两个常用的值为： IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x10b IMAGE_NT_OPTIONAL_HDR64_MAGIC 0x20b
BYTE	MajorLinkerVersion	用于创建这个可执行文件的链接器的主版本号。对于由Microsoft链接器生成的可执行文件来说，这个版本号对应于Visual Studio的版本号（例如Visual Studio 6.0就是版本6）。
BYTE	MinorLinkerVersion	用于创建这个可执行文件的链接器的次版本号
DWORD	SizeOfCode	带有IMAGE_SCN_CNT_CODE 属性的所有节的总大小。
DWORD	SizeOfInitializedData	所有由已初始化的数据组成的节的总大小。
DWORD	SizeOfUninitializedData	所有由未初始化的数据组成的节的总大小。它通常是0，因为链接器经常把未初始化的数据添加到正常的数据节的末尾。
DWORD	AddressOfEntryPoint	文件中首先被执行的代码的第一个字节的RVA。对于DLL来说，入口点在进程初始化和退出期间，以及线程创建和退出期间都会被调用。在大多数可执行文件中，这个地址并不是直接指向main、WinMain或者DllMain，而是指向调用上述函数的运行时库代码。对于DLL来说，这个域可以设为0，这样它就接收不到前面说的四个通知。/NOENTRY链接器选项可以将这个域设置为0
DWORD	BaseOfCode	加载进内存之后代码的第一个字节的RVA。
DWORD	BaseOfData	理论上这是加载进内存之后数据的第一个字节的RVA。但是这个域的值在不同版本的Microsoft链接器间是不一致的。64位可执行文件中并不存在这个域。
DWORD	ImageBase	这个文件在内存中的首选加载地址。如果有可能的话（也就是说这个内存当前并未被占用，并且它是对齐的，同时是一个合法的地址等等），加载器尽量把PE文件加载到这个地址。如果可执行文件被加载到这个地址，加载器就可以跳过基址重定位（将在本文的第二部分中描述）。对于EXE来说，默认的ImageBase为0x400000；对于DLL来说，它是0x10000000。可以在链接时使用/BASE选项或者以后使用REBASE工具来设定此值。
DWORD	SectionAlignment	加载进内存之后节的对齐值。这个对齐值必须大于或等于文件对齐值（下面将要讲到）。默认的对齐值是目标平台的页面大小。对于运行于Windows 9x或Windows Me上的用户模式的可执行文件来说，最小的对齐值是一个页面（4KB）。这个域的值可以使用/ALIGN链接器选项来设定。
DWORD	FileAlignment	节在PE文件中的对齐值。对于x86可执行文件来说，它或者是0x200，或者是0x1000。不同版本的Microsoft链接器的默认值不一样。这个值必须是2的幂，并且如果SectionAlignment域的值小于CPU的页面大小，这个值必须与SectionAlignment域的值匹配。链接器选项/OPT:WIN98将x86平台上的可执行文件的对齐值设为0x1000，而/OPT:NOWIN98选项将它设为0x200。
WORD	MajorOperatingSystemVersion	所需的操作系统的主版本号。随着众多版本Windows的到来，这个域已失去了它最初的意义。
WORD	MinorOperatingSystemVersion	所需的操作系统的次版本号。
WORD	MajorImageVersion	此文件的主版本号。系统并未使用这个域，可以设置为0。使用/VERSION链接器选项可以设定这个域的值。
WORD	MinorImageVersion	此文件的次版本号。
WORD	MajorSubsystemVersion	可执行文件所需的子系统的主版本号。以前相对于旧版本的Windows NT界面来说，用它来指明需要新的Windows 95或Windows NT 4.0用户界面。现在由于Windows版本繁多，这个域已经不使用了，通常被设为4。使用链接器选项/SUBSYSTEM可以设置这个域的值。
WORD	MinorSubsystemVersion	可执行文件所需的子系统的次版本号。
DWORD	Win32VersionValue	一个从来不用的域，通常设为0。
DWORD	SizeOfImage	SizeOfImage包含了假设存在于最后一个节之后的那个节的RVA。这等效于把此文件加载进内存时系统需要保留的内存数量。这个域的值必须是节的对齐值的倍数。
DWORD	SizeOfHeaders	MS-DOS文件头、PE文件头和节表的总大小。在PE文件中，这些内容出现于任何代码或数据节之前。这个域的值被向上舍入到文件对齐值的倍数。
DWORD	CheckSum	映像的校验和。IMAGEHLP.DLL中的CheckSumMappedFile API可以计算这个值。对于内核模式的驱动程序和一些系统DLL来说，校验和是必须的。否则这个域被设置为0。当使用/RELEASE链接器选项时，校验和会被放在文件中。
WORD	Subsystem	指示可执行文件所需子系统（用户界面类型）的一个枚举值。在EXE文件中这个值比较重要。一些重要的值如下： IMAGE_SUBSYSTEM_NATIVE // 不需要子系统 IMAGE_SUBSYSTEM_WINDOWS_GUI // 使用Windows GUI IMAGE_SUBSYSTEM_WINDOWS_CUI // 控制台应用程序。当它运行时，操作系统为其创一 // 个控制台并提供stdin、stdout和stderr文件句柄。
WORD	DllCharacteristics	指示DLL特征的标志。这些值对应于WINNT.H文件中的IMAGE_DLLCHARACTERISTICS_xxx定义。当前值如下： IMAGE_DLLCHARACTERISTICS_NO_BIND // 不绑定映像 IMAGE_DLLCHARACTERISTICS_WDM_DRIVER // 使用WDM模型的驱动程序 IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE // 当终端服务器加载一个并没有准备运行于终端服务 // 器上的应用程序时，它同时加载包含兼容代码的DLL
DWORD	SizeOfStackReserve	在EXE文件中，它表示进程中的线程堆栈最初可以增长到的最大值。默认是1MB。并不是初始化时就提交这里指定的所有内存。
DWORD	SizeOfStackCommit	在EXE文件中，它表示初始化时提交的堆栈的大小。默认是4KB。
DWORD	SizeOfHeapReserve	在EXE文件中，它表示最初为默认进程堆保留的内存数量。默认是1MB。然而对于当前版本的Windows，在没有用户干预的情况下，堆可以超过这个值。
DWORD	SizeOfHeapCommit	在EXE文件中，它表示提交的堆的大小。默认是4KB。
DWORD	LoaderFlags	此域已经废弃不用。
DWORD	NumberOfRvaAndSizes	在IMAGE_NT_HEADERS结构末尾处是一个IMAGE_DATA_DIRECTORY结构数组。这个域包含了这个数组的元素数目。由于以前发行的Windows NT的原因，它被设置为16。
IMAGE_ DATA_ DIRECTORY	DataDirectory[16]	IMAGE_DATA_DIRECTORY结构数组。每个结构包含可执行文件中一些重要部分（例如导入表、导出表以及资源等）的RVA和大小。

IMAGE_OPTIONAL_HEADER结构末尾的DataDirectory数组就像是可执行文件中重要位置的地址簿。DataDirectory的每个元素结构如下：

typedef struct _IMAGE_DATA_DIRECTORY {

    DWORD   VirtualAddress;     // 数据的RVA

    DWORD   Size;               // 数据的大小

} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

节表section table

紧跟着IMAGE_NT_HEADERS结构的是节表（section table）。节表是一个IMAGE_SECTION_HEADER结构数组。此结构提供了与它相关的节的信息，其中包括位置、长度和属性。下表给出了对此结构的描述。节表中此结构的数目由IMAGE_NT_HEADERS.FileHeader.NumberOfSections给出。

大小	域	描述
BYTE	Name[8]	节的名称（ASCII码）。节名并不保证以NULL结尾。如果你指定的节名大于8个字节，链接器在生成可执行文件时将其截断为8个字符。在OBJ文件中存在一种机制可以让节名更长。节名通常以圆点开始，但这并不是必需的。对于带有$字符的节名链接器会特殊对待。如果几个节名中$字符以前的部分相同，那么这些节会被合并。它们按$字符后面的部分在字母表中的顺序出现于最终的节中。关于节名中带有$字符的节和它们如何被合并方面还有很多内容，但对它的详细讨论已经超出了本文的范围。
DWORD	VirtualSize	指示节实际占用的内存大小。这个域的值可能比SizeOfRawData域的值大或小。如果大，SizeOfRawData域表示可执行文件中已初始化的数据的大小，VirtualSize域比它大的部分用0填充。在OBJ文件中，此域的值为0。
DWORD	VirtualAddress	在可执行文件中，它表示在内存中节的起始RVA。在OBJ文件中它被设置为0。
DWORD	SizeOfRawData	可执行文件或OBJ文件中的节中存储的数据的大小（以字节计）。对于可执行文件来说，它必须是PE文件头中给出的文件对齐值的倍数。如果它被设置为0，表示这个节中是未初始化的数据。
DWORD	PointerToRawData	节中数据起始的文件偏移。对于可执行文件来说，它必须是PE文件头中给出的文件对齐值的倍数。
DWORD	PointerToRelocations	节的重定位信息的文件偏移。它只用于OBJ文件，在可执行文件中它被设置为0。在OBJ文件中，如果它不为0，那么它指向一个IMAGE_RELOCATION结构。
DWORD	PointerToLinenumbers	节中COFF行号信息的文件偏移。如果它不为0，那么它指向一个IMAGE_LINENUMBER结构。
WORD	NumberOfRelocations	PointerToRelocations域指向的重定位信息的数目。在可执行文件中应该为0。
WORD	NumberOfLinenumbers	PointerToLinenumbers域指向的行号信息的数目。只有当生成COFF行号信息时才使用。
DWORD	Characteristics	指示节属性的标志（可以用“或”连接）。这些标志中的大部分可以使用链接器的/SECTION选项来设置。常用的值列于下表。

下表列出了常用的节属性标志：

标志	描述
IMAGE_SCN_CNT_CODE	节中包含代码。
IMAGE_SCN_MEM_EXECUTE	节是可执行的。
IMAGE_SCN_CNT_INITIALIZED_DATA	节中包含已初始化的数据。
IMAGE_SCN_CNT_UNINITIALIZED_DATA	节中包含未初始化的数据。
IMAGE_SCN_MEM_DISCARDABLE	这个节在最终的可执行文件中可以被丢弃。用于保存链接器使用的信息，包括.debug$节。
IMAGE_SCN_MEM_NOT_PAGED	这个节不能被交换到页面文件中，因此它应该总是存在于物理内存中。经常用于内核模式驱动程序。
IMAGE_SCN_MEM_SHARED	包含这个节的物理页面将在加载这个可执行文件的所有进程之间共享。因此每个进程看到的这个节中的数据的值完全一样。对于在进程的所有实例之间共享全局变量比较有用。要共享某个节，使用/SECTION:节名,S链接器选项。
IMAGE_SCN_MEM_READ	节是可读的。几乎总是设置这个值。
IMAGE_SCN_MEM_WRITE	节是可写的。
IMAGE_SCN_LNK_INFO	节中包含链接器使用的信息。仅存在于OBJ文件中。
IMAGE_SCN_LNK_REMOVE	这个节中的内容将不成为最终的映像的一部分。仅用于OBJ文件。
IMAGE_SCN_LNK_COMDAT	节中的内容是公共数据（comdat）。公共数据（Communal data）是可以被定义在多个OBJ文件中的数据（或代码）。链接器只将其中的一份副本包含进最终的可执行文件中。Comdats对于支持C++的模板函数和函数级的链接至关重要。它仅存在于OBJ文件中。
IMAGE_SCN_ALIGN_xBYTES	这个节中的数据在最终的可执行文件中的对齐值。有各种各样的值（_4BYTES，_8BYTES，_16BYTES等）。如果不指定，默认为16字节。仅在OBJ文件中才设置这些标志。

可执行文件中的节在文件中的对齐值对文件的大小有重要影响。在Visual Studio 6.0中，链接器默认的节对齐值是4KB，除非使用/OPT:NOWIN98选项或/ALIGN选项。对于Visual Studio .NET链接器，虽然仍是默认使用/OPT:NOWIN98选项，但它要确定可执行文件是否小于某一固定值，如果小于的话，它将使用0x200字节的对齐值。

另一个比较有用的对齐值来自.NET文件规范。这个规范说.NET可执行文件在内存中的对齐值应该为8KB，而不是x86上的4KB。这是为了确保用x86入口点代码创建的.NET可执行文件可以运行在IA-64中。如果在内存中节的对齐值为4KB，那么IA-64将不能加载这个文件，因为在64位Windows上页面是按8KB对齐的

我们来看一下在可执行文件和OBJ文件中经常遇到的一些节。除非特别说明，否则下表中的节名都来自Microsoft。

名称	描述
.text	默认的代码节。
.data	默认的可读/可写数据节。全局变量通常在这个节中。
.rdata	默认的只读数据节。字符串常量和C++/COM虚表就放在这个节中。
.idata	导入表。实际上，链接器经常把.idata节合并到其它节中（或者是明确指定的，或者是通过链接器的默认行为）。默认情况下，链接器仅在创建发行版的程序时才把.idata节合并到其它节中。
.edata	导出表。当创建要导出函数或数据的可执行文件时，链接器会创建一个.EXP文件。这个.EXP文件包含一个.edata节，这个节被添加到最后的可执行文件中。与.idata节一样，.edata节也经常被合并到.text节或.rdata节中。
.rsrc	资源节。这个节是只读的。它不应该被命名为其它名称，也不应该被合并到其它节中。
.bss	未初始化的数据节。在最新的链接器创建的可执行文件中很少见到。链接器扩展可执行文件的.data节的VirtualSize域以便容纳未初始化的数据。
.crt	添加到可执行文件中的数据，用来支持C++运行时库（CRT）。一个比较好的例子就是用于调用静态C++对象的构造函数和析构函数的指针。要获取更详细的信息，可以参考
.tls	这个节中的数据用来支持使用__declspec(thread)语法创建的线程局部存储变量。它包括数据的初始值，以及运行时需要的附加变量。
.reloc	可执行文件中的基址重定位节。通常DLL需要基址重定位信息而EXE并不需要。在创建发行版的程序时，链接器并不为EXE文件生成基址重定位信息。可以使用/FIXED链接器选项移除基址重定位信息。
.sdata	通过全局指针（Global Pointer）相对寻址的“短（Short）”可读/可写数据。用于IA-64和其它使用全局指针寄存器的平台上。IA-64平台上正常大小的全局变量在这个节中。
.srdata	通过全局指针相对寻址的“短（Short）”只读数据。用于IA-64和其它使用全局指针寄存器的平台上。
.pdata	异常表。它包含一个IMAGE_RUNTIME_FUNCTION_ENTRY结构数组，这个结构与平台体系结构相关。数据目录中索引为IMAGE_DIRECTORY_ENTRY_EXCEPTION的项指向它。用于使用基于表的异常处理的平台，例如IA-64。惟一不使用基于表的异常处理的平台是x86（它使用的是基于堆栈的异常处理）。
.debug$S	OBJ文件中的Codeview格式的调试符号（Symbol）信息。这是一列可变长度的CodeView格式的调试符号记录。
.debug$T	OBJ文件中的Codeview格式的调试类型（Type）记录。这是一列可变长度的CodeView格式的调试类型记录。
.debug$P	可以在使用预编译头（Precompiled Headers）生成的OBJ文件中找到这个节。
.drectve	这个节包含链接器指令，并且只存在于OBJ文件中。这些指令是传递到链接器命令行的ASCII码字符串，例如：-defaultlib:LIBC。指令之间用空格分开。
.didat	延迟加载导入数据。可以在非发行版本的可执行文件中找到。在发行版本中，延迟加载数据被合并到其它节中。

 

导出表

当一个EXE或DLL导出函数或变量时，其它EXE或DLL就可以使用这些导出的函数或变量。为了简单起见，我把导出的函数和导出的变量统称为“符号”。当导出一些符号时，最起码导出符号的地址需要能够以一种已定义好的方式被获取。每个导出的符号都有一个与之关联的序数，它可以用来查找这个符号。同时，几乎总有一个ASCII码格式的字符串名称与这个导出的符号关联。一般来说，导出的符号名与源文件中的符号名是一样的，尽管它们可以被修改的不一样。

通常，当可执行文件导入符号时，它使用的是符号的名称而不是它的序号。但是当通过名称导入时，系统仅使用这个名称去查找所需符号对应的导出序数，然后根据这个序数值去获取相应的地址。如果先使用的是序数值的话查找过程会快一点。通过名称导出和导入只是为了让程序员使用方便罢了。

在.DEF文件中的Exports节中使用ORDINAL关键字可以告诉链接器创建一个导入库，这个导入库强制函数只能通过序数导入而不能通过名称导入。

我首先介绍IMAGE_EXPORT_DIRECTORY结构，如下表所示：

大小	域	描述
DWORD	Characteristics	导出标志。当前未定义任何值。
DWORD	TimeDateStamp	导出数据的创建时间。这个域的定义与IMAGE_NT_HEADERS.FileHeader.TimeDateStamp相同（从GMT时间1970年1月1日00:00以来的总秒数)。
WORD	MajorVersion	导出数据的主版本号。未用，设置为0。
WORD	MinorVersion	导出数据的次版本号。未用，设置为0。
DWORD	Name	与导出符号相关的DLL的名称ASCII字符串的RVA（例如KERNEL32.DLL）。
DWORD	Base	这个域包含了这个可执行文件的导出符号所使用的序数值的起始值。通常情况下这个值为1，但并不总是这样。当通过序数查找导出符号时，将序数值减去这个域的值就得到了这个导出符号在导出地址表（Export Address Table ，EAT）中的索引。
DWORD	NumberOfFunctions	EAT中的元素数。注意EAT中的某些元素可能为0，这表明没有 代码/数据使用那个序数值导出。
DWORD	NumberOfNames	导出名称表（Export Names Table，ENT）中的元素数。这个域的值总是小于或等于NumberOfFunctions域的值。当某些符号仅使用序数导出时，它就小于那个域的值。如果导出序数之间有间隔，它同样也小于那个域的值。这个域的值也是导出序数表的大小（见下文）。
DWORD	AddressOfFunctions	EAT的RVA。EAT中的每个元素都是一个RVA。其中每个非0的RVA都对应一个导出符号。
DWORD	AddressOfNames	ENT的RVA。ENT中的每个元素都是一个ASCII码字符串的RVA。其中的每个ASCII码字符串都对应一个由名称导出的符号。这些字符串是按一定顺序排列的。这就使得加载器在查找导出符号时可以进行二进制搜索。名称字符串的排序是按二进制（与C++运行时库函数strcmp类似），而不是与位置相关的字母表顺序。
DWORD	AddressOfNameOrdinals	导出序号表的RVA。这个表是一个WORD类型的数组。它将ENT中的索引映射到导出地址表中相应的元素上。

导出目录（Export Directory）指向三个数组和一个ASCII码字符串表。其中只有导出地址表是必需的，它是一个由指向导出函数的指针组成的数组。导出序数是这个数组的索引（见下图）。

让我们通过例子来看一下导出表的工作原理。下图显示了KERNEL32.DLL导出表的部分内容：

exports table:

Name:            KERNEL32.dll

Characteristics: 00000000

TimeDateStamp:   3B7DDFD8 -> Fri Aug 17 23:24:08 2001

Version:         0.00

Ordinal base:    00000001

# of functions: 000003A0

# of Names:      000003A0

 

Entry Pt   Ordn  Name

00012ADA     1  ActivateActCtx

000082C2     2  AddAtomA

•••remainder of exports omitted

 

假设你调用GetProcAddress来获取KERNEL32中的AddAtomA这个API的地址。这时系统开始查找KERNEL32的IMAGE_EXPORT_DIRECTORY结构。它从那里获取了导出名称表的起始地址，知道了在这个数组中有0x3A0个元素，它通过二进制搜索来查找字符串“AddAtomA”。

假设加载器发现AddAtomA是这个数组中的第二个元素。然后它从导出序数表（Export Ordinal Table）中读取相应的第二个值。这个值就是AddAtomA的导出序数。将这个导出序数作为EAT的索引（加上Base域的值），它最终获取AddAtomA的相对虚拟地址（RVA）是0x82C2。将此值与KERNEL32的加载地址相加就得到了AddAtomA的实际地址。

导出转发

导出表一个特别聪明的地方是它能将一个导出函数转发（Forwarding）到其它DLL。例如在Windows NT®、Windows® 2000和Windows XP中，KERNEL32中的HeapAlloc函数被转发到了NTDLL导出的RtlAllocHeap函数上。转发是在链接时通过.DEF文件中的EXPORTS节中的一种特殊语法形式来实现的。对于HeapAlloc这个例子，KERNEL32的.DEF文件一定包含下面的内容：
        EXPORTS
        •••
        HeapAlloc = NTDLL.RtlAllocHeap

怎样才能区别转发的函数与正常导出的函数呢？这需要一些技巧。通常EAT中包含的是导出符号的RVA。但是如果这个RVA位于导出表中（通过相应的DataDirectory中的VirtualAddress域和Size域进行判断），那么它就是转发的。

 

当转发一个符号时，它的RVA很明显不能是当前模块中的代码或数据的地址。实际上，它的RVA指向一个由DLL和转发到的符号名称组成的字符串。在前面的例子中，这个字符串就是NTDLL.RtlAllocHeap。

导入表

与导出函数或变量相反的就是导入它们。为了与前面保持一致，我仍然使用“符号”这个术语来指代导入的函数和变量。

导入数据被保存在IMAGE_IMPORT_DESCRIPTOR结构中。对应着导入表的数据目录项就指向由这个结构组成的数组。每个IMAGE_IMPORT_DESCRIPTOR结构都与一个导入的可执行文件对应。这个数组的最后一个元素的所有域都被设置为0。下表是这个结构的内容：

大小	域	描述
DWORD	OriginalFirstThunk	这个域的命名太不恰当。它包含导入名称表的RVA。导入名称表是一个IMAGE_THUNK_DATA结构数组。这个域被设置为0表示IMAGE_IMPORT_DESCRIPTOR结构数组的结尾。
DWORD	TimeDateStamp	如果可执行文件并未绑定导入的DLL，这个域的值为0。当使用老的绑定类型进行绑定（参考“绑定”一节）时，这个域包含日期/时间戳。当使用新的绑定类型进行绑定时，这个域的值为-1。
DWORD	ForwarderChain	这是首个转发的函数的索引。如果没有转发的函数，这个域被设置为-1。它仅用于老的绑定类型，因为那种绑定类型不能很有效地处理转发的函数。
DWORD	Name	导入的DLL名称字符串（ASCII码格式）的RVA。
DWORD	FirstThunk	导入地址表的RVA。IAT是一个IMAGE_THUNK_DATA结构数组。

每个IMAGE_IMPORT_DESCRIPTOR结构指向两个数组，这两个数组实际上是一样的。它们有好几种叫法，但最常用的名称是导入地址表（Import Address Table，IAT）和导入名称表（Import Name Talbe，INT）。下图显示的是可执行文件从USER32.DLL中导入一些API时的情况。

 

    这两个数组的元素均为IMAGE_THUNK_DATA类型的结构，这个结构是一个与指针大小相同的共用体（或者称为联合）。每个IMAGE_THUNK_DATA结构对应着从可执行文件中导入的一个函数。这两个数组最后都以一个值为0的IMAGE_THUNK_DATA结构作为结尾。这个共用体（实际是一个DWORD值）可以有如下几种含义：

DWORD ForwarderString;// 转发函数字符串的RVA（见上文）

DWORD Function;       // 导入函数的内存地址

DWORD Ordinal;        // 导入函数的序数

DWORD AddressOfData; // IMAGE_IMPORT_BY_NAME和导入函数名称的RVA（见下文）

 

IAT中的IMAGE_THUNK_DATA结构的用途可以分为两种。在可执行文件中，它们或者是导入函数的序数，或者是一个IMAGE_IMPORT_BY_NAME结构的RVA。IMAGE_IMPORT_BY_NAME结构只是一个WORD类型的值，它后面跟着导入函数的名称字符串。这个WORD类型的值是一个“提示（hint）”，它提示加载器导入函数的序号可能是什么。当加载器加载可执行文件时，它用导入函数的实际地址来覆盖IAT中的每个元素。这一点是理解下文的关键。我强烈建议你读一读本期杂志中Russell Osterlund的文章——

 

在可执行文件被加载之前，是否存在一种方法能够区分IMAGE_THUNK_DATA结构中到底包含的是导入函数的序数呢，还是IMAGE_IMPORT_BY_NAME结构的RVA呢？答案在IMAGE_THUNK_DATA结构的最高位。如果它为1，那么低31位（在64位可执行文件中是低63位）中是导入函数的序数。如果最高位为0，那么IMAGE_THUNK_DATA结构的值就是IMAGE_IMPORT_BY_NAME结构的RVA。

 

另一个数组INT，本质上与IAT是一样的。它也是一个IMAGE_THUNK_DATA结构数组。关键的区别在于当加载器将可执行文件加载进内存时，它并不覆盖INT。为什么对于从DLL中导入的每组API都需要有两个并列的数组呢？答案在于一个称为绑定（binding）的概念。当在绑定过程（后面我会讲到）中覆盖可执行文件的IAT时，需要以某种方式保存原来的信息。而作为这个信息的副本的INT，正是这个用途。

 

INT对于可执行文件的加载并不是必需的。但是如果它不存在的话，那么这个可执行文件就不能被绑定。Microsoft链接器总是生成INT，但是长期以来，Borland链接器（TLINK）都不生成它。这样，由Borland链接器生成的可执行文件就不能被绑定。

 

在早期的Microsoft链接器中，导入节并不是专门针对于链接器的。组成可执行文件导入节的所有数据都来自导入库。你可以对一个导入库文件运行DUMPBIN或PEDUMP来看一下。你会发现一些节名类似于.idata$3和.idata$4的节。链接器只是简单地遵守它的规则来组合节，所有的结构和数组就神奇般地各就其位了。几年前Microsoft引进了一种新的导入库格式，这种导入库特别小，以便让链接器能在创建导入数据时更具主动性。

绑定

当可执行文件被绑定时（例如通过Bind程序），其IAT中的IMAGE_THUNK_DATA结构中是导入函数的实际地址。也就是说，磁盘上的可执行文件的IAT中存储的就是其导入的DLL中的函数在内存中的实际地址。当加载一个被绑定的可执行文件时，Windows加载器可以跳过查找每个导入函数并覆盖IAT这一步。因为IAT中已经是正确的地址了。但是这只有正确对齐时才行。我在

你也许会怀疑将可执行文件绑定是否保险。你可能会想，如果绑定了可执行文件，但它导入的DLL发生了变化，这时怎么办呢？当这种情况发生时，IAT中的地址已经失效了。加载器会检查这种情况并随机应变。如果IAT中的地址已经失效，加载器会根据INT中的信息重新解析导入函数的地址。

在安装程序时对其进行绑定应该是最可能发生的情况了。Windows Installer中的BindImage这个动作可以替你做这件事。同样，IMAGEHLP.DLL中也提供了BindImageEx这个API。不管用哪一种方法，绑定都是个比较好的做法。如果加载器确定绑定信息是有效的，那么可执行文件就会被加载的更快。如果绑定信息失效，它也并不会比不绑定效果差。

对加载器来说，使绑定生效的一个关键步骤是确定IAT中的绑定信息是否有效。当可执行文件被绑定时，有关它导入的DLL的信息也被放在可执行文件中。加载器检查这个信息以快速确定绑定的有效性。在绑定的最初实现中并未添加这个信息，因此可执行文件可能按老的绑定方式进行绑定，或者按新的绑定方式进行绑定。我在这里讲的是新的绑定方式。

确定绑定信息有效性的一个关键数据结构是IMAGE_BOUND_IMPORT_DESCRIPTOR。被绑定的可执行文件中有一个此结构的列表。每个IMAGE_BOUND_IMPORT_DESCRIPTOR结构表示一个绑定到的DLL的日期/时间戳。这个列表的RVA由数据目录中索引为IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT的元素给出。IMAGE_BOUND_IMPORT_DESCRIPTOR结构中的成员如下：

• TimeDateStamp，这是包含导入的DLL的日期/时间戳的一个DWORD类型的值。
• OffsetModuleName，这是包含导入的DLL的名称字符串偏移地址的一个WORD类型的值。这个域是相对于首个IMAGE_BOUND_IMPORT_DESCRIPTOR结构的偏移（而不是RVA）。
• NumberOfModuleForwarderRefs，这是一个WORD类型的值，它包含紧跟在这个结构后面的IMAGE_BOUND_FORWARDER_REF结构的数目。除了最后一个WORD类型的成员（NumberOfModuleForwarderRefs）是保留的外，IMAGE_BOUND_FORWARDER_REF结构与IMAGE_BOUND_IMPORT_DESCRIPTOR结构一样。

一般情况下，每个导入的DLL对应的IMAGE_BOUND_IMPORT_DESCRIPTOR结构简单地组成一个数组。但是当绑定的API转发到了另一个DLL上时，这个转发到的DLL的有效性也需要检查。在这种情况下，IMAGE_BOUND_FORWARDER_REF结构就与IMAGE_BOUND_IMPORT_DESCRIPTOR结构交叉在了一起。下面举一个例子来说明。

 

假设你链接到了KERNEL32.DLL中的HeapAlloc这个API上，而它实际上被转发到了NTDLL中的RtlAllocateHeap上，然后你绑定这个可执行文件。那么在这个可执行文件中，对应于KERNEL32.DLL这个导入的DLL就有一个相应的IMAGE_BOUND_IMPORT_DESCRIPTOR结构，同时它后面是一个对应于NTDLL.DLL的IMAGE_BOUND_FORWARDER_REF结构。紧跟在它们后面的可能是与你导入并绑定到的其它DLL对应的IMAGE_BOUND_IMPORT_DESCRIPTOR结构。

延迟加载数据

前面我已经讲过延迟加载（Delayload）一个DLL就是隐含导入与通过LoadLibrary和GetProcAddress显式导入这两种方式的混合。现在让我们来看一下延迟加载所需的数据结构以及它的工作原理。

一定要记住延迟加载并不是操作系统的功能。它完全是由链接器和运行时库添加的附加代码和数据来实现的。正因为如此，WINNT.H中并没有几个地方涉及到延迟加载。但是你会发现延迟加载数据和正常导入数据二者的定义是平行的。

DataDirectory中的IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT元素指向延迟加载数据。这个元素中实际是一个ImgDelayDescr结构数组的RVA，这个结构被定义在Visual C++的DelayImp.H文件中。下表是这个结构的内容。对应于每一个导入的DLL都有一个相应的ImgDelayDescr结构。

大小	域	描述
DWORD	grAttrs	此结构的属性。当前惟一定义的标志是dlattrRva（值为1）。这个标志表明此结构中的地址域是RVA，而不是虚拟地址。设置这个标志表明延迟加载描述符是VC7.0或其后续版本。
RVA	rvaDLLName	导入的DLL的名称字符串的RVA。这个字符串被传递给LoadLibrary函数。
RVA	rvaHmod	一块HMODULE大小的内存的RVA。当延迟加载的DLL被加载进内存时，它的HMODULE被存储在这个位置。
RVA	rvaIAT	此DLL的导入地址表的RVA。它的格式与正常的IAT相同。
RVA	rvaINT	此DLL的导入名称表的RVA。它的格式与正常的INT相同。
RVA	rvaBoundIAT	可选的绑定IAT的RVA。它是此DLL的导入地址表的一个绑定副本的RVA。它的格式与正常的IAT相同。当前这个IAT副本并未绑定，但这个功能可能被添加到将来的BIND程序中。
RVA	rvaUnloadIAT	原始的IAT的可选副本的RVA。它是此DLL的导入地址表的一个未绑定的副本的RVA。它的格式与正常的IAT相同。当前总是设置为0。
DWORD	dwTimeStamp	延迟加载导入的DLL的日期/时间戳。通常设置为0。

我们从ImgDelayDescr结构中可以获取的主要内容就是它包含了DLL的IAT和INT的地址。这些表与正常情况下的表是一样的，只不过它们是由运行时库代码进行读写而不是由操作系统。当你调用延迟加载的DLL中的函数时，运行时库代码就调用LoadLibrary加载相应的DLL（如果需要的话），然后调用GetProcAddress来获取函数地址，最后将获取的地址存储在延迟加载IAT中，以便将来可以直接调用这个函数。

延迟加载所使用的数据结构在设计时有一个失误的地方需要解释一下。在Visual C++ 6.0中——这是它最初的形式，ImgDelayDescr结构中的所有包含地址的域使用的都是虚拟地址，而不是RVA。也就是说，它们包含了延迟加载数据所在位置的实际地址。这些域都是DWORD类型的，也就是x86上一个指针的大小。

现在要全面支持IA-64了。突然，4字节已经不够保存一个完整的地址了。哎呀！在这个时候，Microsoft做了一件正确的事，把包含地址的域都改为包含RVA了。如前面所示，我使用的是已经修订过的结构定义和名称。

还有一个问题就是确定ImgDelayDescr使用的是RVA还是虚拟地址。这个结构中有一个域包含了相关的标志。当grAttrs域为1时，这个结构中的成员中包含的是RVA。从Visual Studio® .NET和64位编译器开始，这是惟一选项。如果grAttrs不是1，ImgDelayDescr结构中的域包含的都是虚拟地址。

资源节

在PE文件的所有节中，在资源节中定位数据是最复杂的。在这里我只讲述一些获取诸如图标、位图以及对话框之类的资源的原始数据所需的一些数据结构。我不涉及它们的实际格式，那已经超出了本文的范围。

资源可以在一个叫做.rsrc的节中找到。DataDirectory中索引为IMAGE_DIRECTORY_ENTRY_RESOURCE的元素包含了资源的RVA和大小。由于多方面的原因，资源被组织得与文件系统类似——有目录和叶结点。

DataDirectory中的资源指针指向了一个IMAGE_RESOURCE_DIRECTORY类型的结构。这个结构中包含了目前尚未使用的Characteristics域、TimeDateStamp域以及版本号域（MajorVersion和MinorVersion）。这个结构中真正有用的域是NumberOfNamedEntries和NumberOfIdEntries。

每个IMAGE_RESOURCE_DIRECTORY结构后面是一个IMAGE_RESOURCE_DIRECTORY_ENTRY结构数组。另外，IMAGE_RESOURCE_DIRECTORY结构中的NumberOfNamedEntries和NumberOfIdEntries这两个域保存的就是这个数组中IMAGE_RESOURCE_DIRECTORY_ENTRY结构的数目。（如果你感觉这些数据结构的名称让你看得头疼，说句实在话，我将它们写下来也挺难受的！）

每个目录项（即IMAGE_RESOURCE_DIRECTORY_ENTRY结构）或者指向另一个资源目录，或者指向具体的资源数据。当它指向另一个资源目录时，这个结构中的第二个DWORD的最高位为1，其余的31位是那个资源目录的偏移。这个偏移是相对于资源节开头来说的，而不是RVA。

当它指向实际的某种资源时，第二个DWORD的最高位为0，其余的31位是具体资源（例如对话框）的偏移。同上面一样，这个偏移同样是相对于资源节开头来说的，而不是RVA。

每个目录项可以通过名称或者ID值来标识。它们就是你在.RC文件中为具体资源指定的名称或ID值。当目录项的第一个DWORD的最高位为1时，其余的31位是资源名称（字符串）的偏移；如果最高位为0，那么其低16位是资源标识（ID）的值。

理论已经足够了！现在让我们看一个实际的例子。下面是PEDUMP输出的ADVAPI32.DLL的资源节的部分内容：

Resources (RVA: 6B000)

ResDir (0) Entries:03 (Named:01, ID:02) TimeDate:00000000

    ———————————————————————————————

    ResDir (MOFDATA) Entries:01 (Named:01, ID:00) TimeDate:00000000

        ResDir (MOFRESOURCENAME) Entries:01 (Named:00, ID:01) TimeDate:00000000

            ID: 00000409 DataEntryOffs: 00000128

            DataRVA: 6B6F0 DataSize: 190F5 CodePage: 0

    ———————————————————————————————

    ResDir (STRING) Entries:01 (Named:00, ID:01) TimeDate:00000000

        ResDir (C36) Entries:01 (Named:00, ID:01) TimeDate:00000000

            ID: 00000409 DataEntryOffs: 00000138

            DataRVA: 6B1B0 DataSize: 0053C CodePage: 0

    ———————————————————————————————

    ResDir (RCDATA) Entries:01 (Named:00, ID:01) TimeDate:00000000

        ResDir (66) Entries:01 (Named:00, ID:01) TimeDate:00000000

            ID: 00000409 DataEntryOffs: 00000148

            DataRVA: 85908 DataSize: 0005C CodePage: 0

其中以“ResDir”开头的每一行对应于一个IMAGE_RESOURCE_DIRECTORY结构。“ResDir“后面的括号中是资源目录的名称。在这个例子中，资源目录的名称分别为0、MOFDATA、MOFRESOURCENAME、STRING、C36、RCDATA和66。名称后面是以名称标识的和以ID标识的资源目录的总个数（后面的括号中是它们分别的个数）。在这个例子中，顶级目录一共有3个直接的子目录，所有其它目录都只有一个下级子目录。

顶级目录类似于文件系统中的根目录。根目录下的每个子目录项（也就是第二级目录）代表资源的类型（字符串表、对话框、菜单等等）。它们下面还有第三级子目录。

对于某种具体的资源类型来说，一般有三级目录。例如如果有五个对话框，那么第二级的DIALOG目录下面将会有五个子目录项。这五个子目录项本身也都是目录。在这五个目录下面都只有一项内容，它就是具体资源的原始数据的偏移地址。很简单，不是吗？

如果你更喜欢通过读源代码来学习的话，你可以仔细看一下PEDUMP中转储资源的那部分代码（PEDUMP的源代码可以从2002年2月本文的第一部分中下载）。除了显示所有的资源目录以及它们的元素个数外，PEDUMP还可以显示几种常见的资源类型，例如对话框等。

基址重定位

在可执行文件中的许多地方，你都会发现内存地址的踪迹。当链接器在生成可执行文件时，它假定这个可执行文件会被加载到内存中的某一个地址处（即首选地址）。只有在可执行文件被加载到其首选地址时，所有这些内存地址才是正确的。这个首选地址由IMAGE_FILE_HEADER结构中的ImageBase域给出。

如果加载器由于某种原因需要把可执行文件加载到其它地址处时，所有这些地址都变成不正确的了。这将会额外增加加载器的工作量。在2000年5月的Under The Hood专栏（前面已经提到）中我已经讲过当几个DLL首选加载地址相同时会导致性能损失，以及如何使用REBASE工具来解决这个问题。

基址重定位（Base Relocations）信息告诉加载器可执行文件不能被加载到其首选地址时需要进行修改的每一个位置。对于加载器来说，幸运的是它并不需要知道地址使用的细节问题。它只知道有一个地址列表，其中的每一个地址都需要以同样的方式进行修改。

让我们来看一个x86平台上的可执行文件的例子。假设有以下指令，它将一个全局变量（地址0x0040D434）的值加载到ECX寄存器中：

00401020: 8B 0D 34 D4 40 00 mov ecx,dword ptr [0x0040D434]

这条指令在地址0x00401020处，长为6个字节。前两个字节（0x8B 0x0D）是指令的机器码。剩下的四个字节是一个DWORD值的地址（0x0040D434）。在这个例子中，这条指令实际来自一个首选地址为0x00400000的可执行文件，因此这个全局变量的RVA为0xD434。

如果这个可执行文件被加载到了0x00400000处，这条指令当然可以正确执行。但是现在我们假设它被加载到了0x00500000处。如果真是这样，那么这条指令的最后的四个字节需要被改成0x0050D434。

那么加载器是如何做的呢？它比较首选加载地址与实际加载地址，然后计算出△（delta，音译为德耳塔，数学中的常用符号，表示差值的意思）。在这个例子中，△为0x00100000。这个△被加到变量原来的地址值（大小为DWORD）上，形成新的地址。在前面的例子中，关于地址0x00401022处，即指令中的DWORD值处，将会有一个相应的重定位信息。

简而言之，基址重定位信息只是可执行文件中的一个地址列表，当加载进内存时，这些地址中的值都要再加上△。为了提高系统性能，可执行文件的页面只有在需要时才会被加载进内存（可执行文件的加载与内存映射文件类似），基址重定位信息的格式就反映了这个特性。基址重定位信息所在的节通常被称为.reloc节，但是查找它的正确方法是通过数据目录中索引为IMAGE_DIRECTORY_ENTRY_BASERELOC的那个元素。

基址重定位信息是一些非常简单的IMAGE_BASE_RELOCATION结构。此结构中的VirtualAddress域包含了需要进行重定位的内存范围的起始RVA。SizeOfBlock域给出了重定位信息的大小，其中包括IMAGE_BASE_RELOCATION自身的大小。

紧跟着IMAGE_BASE_RELOCATION结构后面是一组可变数目的WORD值。这些WORD值的数目可以从IMAGE_BASE_RELOCATION结构的SizeOfBlock域推出。其中每个WORD值由两部分组成。高4位指明了重定位的类型，由WINNT.H中的一系列IMAGE_REL_BASED_xxx值给出。低12位是相对于IMAGE_BASE_RELOCATION结构的VirtualAddress域的偏移，这是应该进行重定位的地方。

在前面那个关于基址重定位的例子中，我把情况简化了。实际上有多种类型的重定位方式。对于x86平台上的可执行文件来说，所有的重定位类型都是IMAGE_REL_BASED_HIGHLOW。你经常会在一组重定位信息之后看到类型为IMAGE_REL_BASED_ABSOLUTE的重定位信息。它们实际上并没有什么作用，只是为了填充空间以便下一个IMAGE_BASE_RELOCATION结构能够按4字节的边界对齐。

对于IA-64平台上的可执行文件来说，重定位类型好像总是IMAGE_REL_BASED_DIR64。与x86平台一样的是，通常也会有作为填充的IMAGE_REL_BASED_ABSOLUTE类型的重定位信息。有趣的一点是，尽管IA-64平台上每个页面是8KB，但基址重定位信息仍旧是分成4KB的块。

在Visual C++ 6.0中，链接器在创建发行版的EXE文件时并不生成重定位信息。这是由于EXE文件是最先被加载到进程的地址空间中的，因此可以绝对保证它能被加载到其首选地址上。DLL就没有这么幸运了，因此DLL中总是存在基址重定位信息，除非你使用/FIXED链接器选项明确忽略它们。在Visual Studio .NET中，链接器在生成调试版和发行版的EXE文件时都不产生基址重定位信息。

调试目录

当创建可执行文件并生成相应的调试信息时，通常文件中会包含这种信息格式的细节以及它的位置。操作系统运行可执行文件时并不需要调试信息，但它对于开发工具非常有用。一个EXE文件可以包含多种格式的调试信息，调试目录（Debug Directory）结构指出哪种格式可用。

 

可以通过数据目录中索引为IMAGE_DIRECTORY_ENTRY_DEBUG的元素找到调试目录。它是由IMAGE_DEBUG_DIRECTORY结构组成的数组，其中每一个结构对应一种类型的调试信息，如下表所示。调试目录中元素的数目可以使用数据目录中的Size域计算得出。

大小	域	描述
DWORD	Characteristics	未用，设置为0。
DWORD	TimeDateStamp	调试信息的日期/时间戳。
WORD	MajorVersion	调试信息的主版本号，未用。
WORD	MinorVersion	调试信息的次版本号，未用。
DWORD	Type	调试信息的类型。以下是经常遇到的类型： IMAGE_DEBUG_TYPE_COFF IMAGE_DEBUG_TYPE_CODEVIEW      // 包含PDB文件 IMAGE_DEBUG_TYPE_FPO           // 帧指针省略 IMAGE_DEBUG_TYPE_MISC          // IMAGE_DEBUG_MISC IMAGE_DEBUG_TYPE_OMAP_TO_SRC IMAGE_DEBUG_TYPE_OMAP_FROM_SRC IMAGE_DEBUG_TYPE_BORLAND       // Borland格式
DWORD	SizeOfData	文件中调试数据的大小。不包括外部调试文件（例如.PDB文件）的大小。
DWORD	AddressOfRawData	当映射进内存时调试数据的RVA。如果调试信息不被映射，它被设置为0。
DWORD	PointerToRawData	调试数据的文件偏移（不是RVA）。

到目前为止，最流行的调试信息格式是PDB文件。PDB文件实质上是CodeView格式调试信息的发展。一个类型为IMAGE_DEBUG_TYPE_CODEVIEW的调试目录标志着PDB信息的存在。如果你检查由这个元素指向的数据，会发现一个短的CodeView格式的头部。这个调试数据主要是一个外部PDB文件的路径。在Visual Studio 6.0中，调试头开始处是一个NB10签名。在Visual Studio .NET中，这个头开始处是RSDS。

在Visual Studio 6.0中，可以使用/DEBUGTYPE:COFF链接器选项来生成COFF调试信息。Visual Studio .NET将这项功能移除了。对于经过优化的x86代码，由于函数可能没有正常的栈帧，所有使用帧指针省略（Frame Pointer Omission，FPO）调试信息。FPO数据允许调试器定位局部变量和参数。

有两种OMAP调试信息仅用于Microsoft的程序。Microsoft内部使用一种工具对可执行文件中的代码进行重新排列以减少分页。（它所做的不仅仅是Working Set Tuner所能做到的。）OMAP信息让工具可以在调试信息中的原始地址与重排后的代码中的新地址之间进行转换。

顺便说一下，DBG文件也包含了一个类似于我上面讲的调试目录。DBG文件流行于Windows NT 4.0时代，它们主要包含COFF调试信息，但是Windows XP偏爱PDB文件而将它们淘汰了。

.NET头部

对于开发工具生成的用于Microsoft .NET环境下的可执行文件来说，它们首先是PE文件。但是在大多数情况下.NET文件中正常的代码和数据是微不足道的。.NET可执行文件的主要目的是将.NET特定的信息，例如元数据和中间语言（IL），加载进内存。另外.NET可执行文件链接到了MSCOREE.DLL文件上。这个DLL是.NET进程的起点。当加载.NET可执行文件时，它的入口点通常是一个小的占位程序。这个占位程序只是跳转到MSCOREE.DLL的一个导出函数（_CorExeMain或_CorDllMain）上。从那里开始，MSCOREE获取控制权，开始使用可执行文件中的元数据和IL。这类似于（.NET版之前的）Visual Basic中的应用程序使用MSVBVM60.DLL所采用的方式。.NET信息的起点是IMAGE_COR20_HEADER结构，它当前被定义在.NET Framework SDK中的CorHDR.H文件以及最新的WINNT.H文件中。数据目录中索引为IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR的项指向IMAGE_COR20_HEADER结构。下表列出了IMAGE_COR20_HEADER结构中的域。关于IMAGE_COR20_HEADER指向的元数据、方法IL以及其它内容将在后续文件中详细讲述。

类型	域	描述
DWORD	cb	头部的大小（以字节计）。
WORD	MajorRuntimeVersion	运行这个程序所需的运行时组件的最小版本号。对于第一个发行的.NET Framework而言，此值为2。
WORD	MinorRuntimeVersion	次版本号，当前为0。
IMAGE_DATA_DIRECTORY	MetaData	元数据表的RVA。
DWORD	Flags	包含这个映像属性的标志。当前定义了以下值： COMIMAGE_FLAGS_ILONLY // 映像仅包含IL代码，并不需要运// 行于特定CPU上 COMIMAGE_FLAGS_32BITREQUIRED // 仅运行于32位处理器上 COMIMAGE_FLAGS_IL_LIBRARY STRONGNAMESIGNED // 映像已经用散列数据签名 COMIMAGE_FLAGS_TRACKDEBUGDATA // 让JIT或运行时组件为方法保持// 调试信息
DWORD	EntryPointToken	映像入口点的MethodDef的记号。.NET运行时调用这个方法开始托管执行。
IMAGE_DATA_DIRECTORY	Resources	.NET资源的RVA和大小。
IMAGE_DATA_DIRECTORY	StrongNameSignature	强名称散列数据的RVA。
IMAGE_DATA_DIRECTORY	CodeManagerTable	代码管理器表的RVA。代码管理器包含获取正在运行的程序的状态（例如堆栈跟踪和跟踪GC引用）所需的代码。
IMAGE_DATA_DIRECTORY	VTableFixups	需要被修正的函数指针组成的数组。用于支持非托管的C++虚表。
IMAGE_DATA_DIRECTORY	ExportAddressTableJumps	由对应于导出符号的JMP形实转换块被写入的位置（RVA）组成的数组的RVA。这些形实转换块允许托管方法被导出，这样非托管代码可以调用它们。
IMAGE_DATA_DIRECTORY	ManagedNativeHeader	在内存中供.NET运行时组件内部使用。在可执行文件中被设置为0。

TLS初始化

当使用__declspec(thread)定义线程局部变量时，编译器将它们放入一个名为.tls的节中。当系统创建新线程时，它从进程堆中分配内存来保存用于新线程的线程局部变量。这部分内存使用.tls节中的值进行初始化。系统将分配的内存的地址保存在TLS数组中，FS:[2Ch]指向这个数组（在x86平台上）。

如果数据目录中索引为IMAGE_DIRECTORY_ENTRY_TLS的元素不为0，那就表示可执行文件中存在线程局部存储（TLS）。而这个元素指向一个IMAGE_TLS_DIRECTORY结构，如下表所示。

大小	域	描述
DWORD	StartAddressOfRawData	用于在内存中初始化新线程的TLS数据的一段内存的起始地址。
DWORD	EndAddressOfRawData	用于在内存中初始化新线程的TLS数据的一段内存的结束地址。
DWORD	AddressOfIndex	当可执行文件被加载进内存时，如果它包含.tls节，加载器调用TlsAlloc给它分配一个TLS句柄，并将分配的句柄保存在这个域指定的位置处。运行时库使用这个句柄定位线程局部数据。
DWORD	AddressOfCallBacks	由PIMAGE_TLS_CALLBACK类型的函数指针组成的数组的地址。当创建或撤销线程时，这个列表中的每个函数都会被调用。最后一个元素的值为0，它标志着表的结尾。一般由Visual C++生成的可执行文件中这个表是空的。
DWORD	SizeOfZeroFill	已初始化数据中除了由StartAddressOfRawData和EndAddressOfRawData域组成的已初始化数据界限之外的大小（以字节计）。所有超出这个范围的用于单个线程的数据都被初始化为0。
DWORD	Characteristics	保留，当前被设置为0。

注意到IMAGE_TLS_DIRECTORY中的地址都是虚拟地址而不是RVA这一点很重要。因此如果可执行文件不能被加载到其首选加载地址时，它们都要进行基址重定位。同时，IMAGE_TLS_DIRECTORY结构本身并不在.tls节中，它位于.rdata节中。

程序异常数据

      一些平台（包括IA-64）并不使用x86平台上的基于帧的异常处理，它们使用的是基于表的异常处理。在这种异常处理中有一个表，它包含了可能会被异常展开（unwinding）影响到的每一个函数的信息。这些信息主要包括每个函数的开始地址、结束地址以及在哪里并如何处理异常。当发生异常时，系统搜索整个表来寻找处理它的相应项并处理。异常表是一个由IMAGE_RUNTIME_FUNCTION_ENTRY结构组成的数组。数据目录中索引为IMAGE_DIRECTORY_ENTRY_EXCEPTION的元素引向此数组。这个结构的格式因平台而异。对于IA-64平台，它的结构如下：

DWORD BeginAddress;

DWORD EndAddress;

DWORD UnwindInfoAddress;

UnwindInfoAddress数据的结构并未在WINNT.H文件中给出。但是它的具体格式可以在Intel的""一书第11章中找到。

PEDUMP程序

      现在我的PEDUMP程序与1994年时的相比已经有了很大改进。它可以显示本文中讲的所有结构，其中包括：

• IMAGE_NT_HEADERS
• 导入表/导出表
• 资源
• 基址重定位
• 调试目录
• 延迟导入表
• 绑定导入描述符
• IA-64异常处理表
• TLS初始化数据
• .NET运行时头

除了可以转储可执行文件外，PEDUMP还可以转储COFF格式的OBJ文件、COFF导入库（新格式以及老格式）、COFF符号表和DBG文件。

PEDUMP是一个命令行程序。对前面提到的各种文件运行PEDUMP时，如果不加任何选项，它默认输出的是最有用的数据结构信息。有好几个命令行选项可以用来添加其它的输出信息：

名称	描述
/A	转储所有内容
/B	显示基址重定位信息
/H	包括每个节中原始数据的十六进制形式
/I	包括导入地址表形实转换块的地址
/L	包括行号信息
/P	包括PDATA（运行时函数）
/R	包括详细的资源信息（字符串表和对话框）
/S	显示符号表

关于PEDUMP的源代码有几个地方值得注意。首先它可以按32位或64位可执行文件编译和运行。如果你手边有Itanium机器可以试一下。另外，无论PEDUMP以何种方式编译，它都可以同时转储32位和64位文件。换句话说，32位版的PEDUMP可以转储32位和64位文件，64位版的PEDUMP也可以转储32位和64位文件。

在考虑使PEDUMP可以同时处理32位和64位文件时，我想避免为32位结构和64位结构分别写一个函数。因此我使用了C++模板。

在好几个文件（特别是EXEDUMP.CPP）中，你都会发现各种模板函数。大多数情况下，模板函数的参数最终会被扩展为IMAGE_NT_HEADERS32结构或 IMAGE_NT_HEADERS64结构。当调用这些函数时，由代码自身确定是32位还是64位文件并用相应参数类型去调用相应的函数，引起相应的模板展开。

伴随PEDUMP源代码的还有一个Visual C++ 6.0工程文件。工程配置除了传统的x86 debug和 release外，还有相应的64位配置。要想使它正常工作，你需要把64位工具（当前在Platform SDK中）的路径添加到Tools | Options | Directories 选项卡最上面的Executable files路径中，同时还要设置相应的64位Include目录和Lib目录的路径。在我的机器上这个工程文件可以正常工作，但是在你的机器上可能需要进行少量修改才行。

为了使PEDUMP可以处理的内容尽可能全面，这就需要使用最新的Windows头文件。我在开发这个程序时使用的是2001年6月的Platform SDK，需要的这些文件都在.\include\prerelease和.\Include\Win64\crt目录中。在2001年8月的SDK中， WINNT.H文件已经被更新，因此也就不需要prerelease目录中的文件了。最终可以成功创建这个程序。你需要做的可能只是尽是安装最新的Platform SDK或在创建64位版的程序时对工程目录进行一些修改。

结束语

      可移植可执行文件格式是一种结构非常好且相对简单的可执行文件格式。特别好的一点是PE文件可以被直接映射进内存，这样它在磁盘上的数据结构与运行时Windows使用的结构一致。