1 基本概念

下表描述了贯穿于本文中的一些概念：

2 概览

x86都是32位的，IA-64都是64位的。64位 Windows需要做的只是修改PE格式的少数几个域。这种新的格式被称为PE32+。它并没有增加任何新域，仅从PE格式中删除了一个域。其余的改变就 是简单地把某些域从32位扩展到64位。在大部分情况下，你都能写出同时适用于32位和64位PE文件的代码。

EXE文件与DLL文件的区别完全是语义上的。它们使 用的是相同的PE格式。惟一的不同在于一个位，这个位用来指示文件应该作为EXE还是DLL。甚至DLL文件的扩展名也完全也是人为的。你可以给DLL一 个完全不同的扩展名，例如.OCX控件和控制面板小程序（.CPL）都是DLL。

图1 解释了Microsoft PE可执行文件格式：

PE文件总体上分为“头”和“节”。“头”是“节”的描述、简化、说明，“节”是“头”的具体化。

3 文件头

PE文件的头分为DOS头、NT头、节头。注意，这是本人的分法，在此之前并没有这种分法。这样分法会更加合理，更易理解。因为这三个部分正好构成SizeOfHeaders所指的范围，所以将它们合为“头”。这里的3个头与别的文章的头的定义会有所区别。

节头紧跟在NT头后面。

3.1 DOS头（PE文件签名的偏移地址就是大小）

用记事本打开任何一个镜像文件，其头2个字节必为字符串“MZ”，这是Mark Zbikowski的姓名缩写，他是最初的MS-DOS设计者之一。然后是一些在MS-DOS下的一些参数，这些参数是在MS-DOS下运行该程序时要用到的。在这些参数的末尾也就是文件的偏移0x3C（第60字节）处是是一个4字节的PE文件签名的偏移地址。该地址有一个专用名称叫做“E_lfanew”。这个签名是“PE00”（字母“P”和“E”后跟着两个空字节）。紧跟着E_lfanew的是一个MS-DOS程序。那是一个运行于MS-DOS下的合法应用程序。当可执行文件（一般指exe、com文件）运行于MS-DOS下时，这个程序显示“This program cannot be run in DOS mode（此程序不能在DOS模式下运行）”这条消息。用户也可以自己更改该程序，有些还原软件就是这么干的。同时，有些程序既能运行于DOS又能运行于Windows下就是这个原因。Notepad.exe整个DOS头大小为224个字节，大部分不能在DOS下运行的Win32文件都是这个值。MS-DOS程序是可有可无的，如果你想使文件大小尽可能的小可以省掉MS-DOS程序，同时把前面的参数都清0。

3.2 NT头（244或260个字节）

紧跟着PE文件签名之后，是NT头。NT头分成3个部分，因为第2部分在32与64位系统里有区别，第3部分虽然也是头，但实际很不像“头”。

第1部分（20个字节）

第2部分（96或112个字节）

第3部分数据目录（128个字节）

3.2.1 机器类型

Machine域可以取以下各值中的一个来指定CPU类型。镜像文件仅能运行于指定处理器或者能够模拟指定处理器的系统上。

3.2.2 特征

Characteristics域包含镜像文件属性的标志。以下加粗的是常用的属性。当前定义了以下值（由低位往高位）：

Windows子系统

为NT头第2部分的Subsystem域定义了以下值以确定运行镜像所需的Windows子系统（如果存在）：

DLL特征

为NT头的DllCharacteristics域定义了以下值：

每个数据目录给出了Windows使用的表或字符串的地址和大小。这些数据目录项全部被被加载进内存以备系统运行时使用。数据目录是按照如下格式定义的一个8字节结构：

typedef struct
  DWORD VirtualAddress;  //数据的RVA
  DWORD Size;            //数据的大小
typedef ENDS

第1个域——VirtualAddress，实际上是表的RVA。相对镜像基址偏移地址。NT头第2部分的ImageBase
第2个域给出了表的大小（以字节计）。数据目录组成了NT头的最后一部分。

Certificate Table域指向属性证书表。它的第一个域是一个文件指针，而不是通常的RVA。

3.3 节头

在镜像文件中，每个节的RVA值必须由链接器决定。这样能够保证这些节位置相邻且按升序排列，并且这些RVA值必须是NT头中SectionAlignment域的倍数。

每个节头（节表项）格式如下，共40个字节：

3.3.1 节标志

节头中的Characteristics标志指出了节的属性。（以下加粗的是常用的属性值）

第25标志表明节中重定位项的个数超出了节头中为每个节保留的16位所能表示的范围（也就是65535个函数）。如果设置了此标志并且节头中的NumberOfRelocations域的值是0xffff，那么实际的重定位项个数被保存在第一个重定位项的VirtualAddress域（32位）中。如果设置了第25标志但节中的重定位项的个数少于0xffff，则表示出现了错误。

4 一些注意信息

1.PE头是怎么计算的？

SizeOfHeaders所指的头是从文件的第1个字节开始算起的，而不是从PE标记开始算起的。快速的计算方法是从文件的偏移0x3C（第59字节）处获得一个4字节的PE文件签名的偏移地址，这个偏移地址就是本文所定义的DOS头的大小。NT头在32位系统是244字节，在64位系统是260字节。节头的大小由NT头的第1部分的NumberOfSections（节的数量）*40字节（每个节头是40字节）得出。如此，DOS头、NT头、节头3个头的大小加起来并向上舍入为FileAlignment（文件对齐）的正整数倍的最小值就是SizeOfHeaders（头大小）值。

2.节数量的问题

Windows读取NumberOfSections的值然后检查节表里的每个结构，如果找到一个全0结构就结束搜索，否则一直处理完NumberOfSections指定数目的结构。没有规定节头必须以全0结构结束。所以加载器使用了双重标准——全0、达到NumberOfSections数量就不再搜索了。

3.未初始化问题

①未初始化数据在文件中是不占空间的，但在内存里还是会占空间的，它们依然依据指定的大小存在内存里。所以说未初始化数据只在文件大小上有优势，在内存里与已初始化数据是一样的。
②未初始化数据的方法有2种：1是通过节头的VirtualSize>SizeOfRawData。未初始化数据的大小就是VirtualSize-SizeOfRawData的值。2是节特征的标志置为“此节包含未初始化的数据”，这时SizeOfUninitializedData才会非0。现在 都使用第1种，把它们集成到.data里面可以加快速度。

4.已初始化问题

数据目录里面所对应的块中除了属性证书表、调试信息和几个废除的目录项外，全都属于SizeOfInitializedData（已初始化数据大小）范围。当然，已初始化数据不只这些，还可以是常见的代码段等等。

5.节对齐的问题

如果NT头的SectionAlignment域的值小于相应操作系统（有些资料说是根据CPU来的，这不一定。因为CPU本身就允许改分页大小，只是大部分时候操作系统是用CPU默认值的。x86平台默认页面大小是4K。IA-64平台默认页面大小是8K。MIPS平台默认页面大小是4K。Itanium平台默认页面大小是8K。）平台的页面大小，那么镜像文件有一些附加的限制。对于这种文件，当镜像被加载到内存中时，节中数据在文件中的位置必须与它在内存中的位置相等，因此节中数据的物理偏移与RVA相同。

6.镜像大小

SizeOfImage所代表的内存镜像大小没有包含属性证书表和调试信息，这是因为加载器并不将属性证书和调试信息映射进内存。同时加载器规定，属性证书和调试信息必须被放在镜像文件的最后，并且属性证书表在调试信息节之前。

7.数据的组织

CPU的段主要分为4个：代码段、数据段、堆栈段、附加段。而操作系统给程序员留下只有代码段和数据段，堆栈段和附加段就由系统自行处理了，我们不用管。PE文件的数据组织方式是以BaseOfCode、BaseOfData为基准，以节为主体，以数据目录为辅助。
①BaseOfCode、BaseOfData是与后面相应的代码节、数据节的VirtualAddress一致。（这里的数据节是狭义的数据节，是特指代码段、数据目录所指定的数据除外的那一部分，也就是我们编程时定义的常量、变量、未初始化数据等）
②所有的代码、数据都必须在节里面，否则就算是代码基址、数据基址、数据目录都有指定，而节头里没有指定，加载器也会报错，不能运行
③导入函数、导出函数、资源、重定位表等是为了辅助程序主体的，这些都由系统负责处理

5 特殊的节

下表描述了保留的节以及它们的属性，后面是对出现在可执行文件中的节的详细描述。这些节是微软的编译产品所定义的不是系统定义的，实际可以不拘泥于此。

5.1 .edata节

文件A的函数K被文件B调用时，函数K就称为导出函数。导出函数通常出现在DLL中，也可以是exe文件。

下表描述了导出节的一般结构。

当其它镜像文件通过名称导入函数时，Win32加载器通过导出名称指针表来搜索匹配的字符串。如果找到，它就查找导出序数表中相应的成员（也就是说，将找到的导出名称指针表的索引作为导出序数表的索引来使用）来获取与导入函数相关联的序数。获取的这个序数是导出地址表的索引，这个索引对应的元素给出了所需函数的实际位置。每个导出函数都可以通过序数进行访问。

当其它镜像文件通过序数导入函数时，就不再需要通过导出名称指针表来搜索匹配的字符串。因此直接使用序数效率会更高。但是导出名称容易记忆，它不需要用户记住各个符号在表中的索引。

5.1.1 导出目录表

导出目录表是导出函数信息的开始部分，它描述了导出函数信息中其余部分的内容。

5.1.2 导出地址表（Export Address Table，EAT）

导出地址表的格式为下表所述的两种格式之一。如果指定的地址不是位于导出节（其地址和长度由NT头给出）中，那么这个域就是一个Export RVA；否则这个域是一个Forwarder RVA，它给出了一个位于其它DLL中的符号的名称。

Forwarder RVA导出了其它镜像中定义的函数，使它看起来好像是当前镜像导出的一样。因此对于当前镜像来说，这个符号同时既是导入函数又是导出函数。

例如对于Windows XP系统中的Kernel32.dll文件来说，它导出的“HeapAlloc”被转发到“NTDLL.RtlAllocateHeap”。这样就允许应用程序使用Windows XP系统中的Ntdll.dll模块而不需要实际包含任何相关的导入信息。应用程序的导入表只与Kernel32.dll有关。

导出地址表的的值有时为0，此时表明这里没有导出函数。这是为了能与以前版本兼容，省去修改的麻烦。

5.1.3 导出名称指针表

导出名称指针表是由导出名称表中的字符串的地址（RVA）组成的数组。二进制进行排序的，以便于搜索。

只有当导出名称指针表中包含指向某个导出名称的指针时，这个导出名称才算被定义。换句话说，导出名称指针表的值有可能为0，这是为了能与前面版本兼容。

5.1.4 导出序数表

导出序数表是由导出地址表的索引组成的一个数组，每个序数长16位。必须从序数值中减去Ordinal Base域的值得到的才是导出地址表真正的索引。注意，导出地址表真正的索引真正的索引是从0开始的。由此可见，微软弄出Ordinal Base是找麻烦的。导出序数表的值和导出地址表的索引的值都是无符号数。

导出名称指针表和导出名称序数表是两个并列的数组，将它们分开是为了使它们可以分别按照各自的边界（前者是4个字节，后者是2个字节）对齐。在进行操作时，由导出名称指针这一列给出导出函数的名称，而由导出序数这一列给出这个导出函数对应的序数。导出名称指针表的成员和导出序数表的成员通过同一个索引相关联。

5.1.5 导出名称表（Export Name Table，ENT）

导出名称表的结构就是长度可变的一系列以NULL结尾的ASCII码字符串。 导出名称表包含的是导出名称指针表实际指向的字符串。这个表的RVA是由导出名称指针表的第1个值来确定的。这个表中的字符串都是函数名称，其它文件可以通过它们调用函。

5.1.6 举例

①用序数调用
当可执行文件用序数调用函数时，该序数就是导出函数地址表的真实索引。如果索引是错误的就有可能出现不可预知的错误。最著名的例子就是Windows XP在升级Server 2补丁之后，有很多程序都不能运行就是这个原因。微软用序数这种方法被大多数危险程序（病毒、木马）所引用，同样的微软自己也用这种方法来使用一些隐含的函数。最后受害者还是广大的用户，因为使用序数方法的绝大部分程序是有着不可告人的目的的。

②用函数名调用
当可执行文件用函数名调用时，加载器会通过AddressOfNames以2进制的方法找到第一个相同的函数名。假如找到的是第X个函数名，则在AddressOfNameOrdinals中取出第X个值，该值再减去Ordinal Base则为函数地址的真实索引。

5.2.idata节

首先，您得了解什么是导入函数。一个导入函数是被某模块调用的但又不在调用者模块中的函数，因而命名为“import（导入）”。导入函数实际位于一个或者更多的DLL里。调用者模块里只保留一些函数信息，包括函数名及其驻留的DLL名。现在，我们怎样才能找到PE文件中保存的信息呢? 转到 data directory 寻求答案吧。

文件中导入信息的典型布局如下：

典型的导入节布局

5.2.1 导入目录表

导入目录表是由导入目录项组成的数组，每个导入目录项对应着一个导入的DLL。最后一个导入目录项是空的（全部域的值都为NULL），用来指明目录表的结尾。

每个导入目录项的格式如下：

5.2.2 导入查找表

导入查找表是由长度为32位(PE32)或64位(PE32+)的数字组成的数组。其中的每一个元素都是位域，其格式如下表所示。在这种格式中，位31(PE32)或位63(PE32+)是最高位。这些项描述了从给定的DLL导入的所有函数。最后一个项被设置为0(NULL)，用来指明表的结尾。

5.2.3 提示/名称表

提示/名称表中的每一个元素结构如下：

5.2.4 导入地址表

导入地址表的结构和内容与导入查找表完全一样，直到文件被绑定。在绑定过程中，用导入函数的32位(PE32)或64位(PE32+)地址覆盖导入地址表中的相应项。这些地址是导入函数的实际内存地址，尽管技术上仍把它们称为“虚拟地址”。加载器通常会处理绑定。

5.3 .pdata节（可有可无，谁也不希望自己的函数出问题的吧！）

.pdata节是由用于异常处理的函数表项组成的数组。NT头中的Exception Table（异常表）域指向它。在将它们放进最终的镜像文件之前，这些项必须按函数地址（下列每个结构的第一个域）排序。下面描述了函数表项的3种格式，使用哪一种取决于目标平台。

对于32位的MIPS镜像来说，其函数表项格式如下：

对于ARM、PowerPC、SH3和SH4 Windows CE平台来说，其函数表项格式如下：

对于x64和Itanium平台来说，其函数表项格式如下：

5.4 .reloc节

基址重定位表包含了镜像中所有需要重定位的内容。NT头中的数据目录中的Base Relocation Table（基址重定位表）域给出了基址重定位表所占的字节数。基址重定位表被划分成许多块，每一块表示一个4K页面范围内的基址重定位信息，它必须从32位边界开始。

5.4.1 基址重定位块

每个基址重定位块的开头都是如下结构：

Block Size域后面跟着数目不定的Type/Offset位域。它们中的每一个都是一个WORD（2字节），其结构如下：

为了进行基址重定位，需要计算镜像的首选基地址与实际被加载到的基地址之差。如果镜像本身就被加载到了其首选基地址，那么这个差为零，因此也就不需要进行基址重定位了。

5.4.2 基址重定位类型

5.5 加载配置结构（不清楚，大概又是多余的吧）

加载配置结构最初用于Windows NT操作系统自身几种非常有限的场合——在镜像文件头或NT头中描述各种特性太困难或这些信息尺寸太大。当前版本的Microsoft链接器和Windows XP以及后续版本的Windows使用的是这个结构的新版本，将之用于包含保留的SEH技术的基于x86的32位系统上。它提供了一个安全的结构化异常处理程序列表，操作系统在进行异常派送时要用到这些异常处理程序。如果异常处理程序的地址在镜像的VA范围之内，并且镜像被标记为支持保留的SEH，那么这个异常处理程序必须在镜像的已知安全异常处理程序列表中，否则操作系统将终止这个应用程序。这是为了防止利用“x86异常处理程序劫持”来控制操作系统，它在以前已经被利用过。

Microsoft的链接器自动提供一个默认的加载配置结构来包含保留的SEH数据。如果用户的代码已经提供了一个加载配置结构，那么它必须包含新添加的保留的SEH域。否则，链接器将不能包含保留的SEH数据，这样镜像文件就不能被标记为包含保留的SEH。

5.5.1 加载配置目录

对应于预保留的SEH加载配置结构的数据目录项必须为加载配置结构指定一个特别的大小，因为操作系统加载器总是希望它为这样一个特定值。事实上，这个大小只是用于检查这个结构的版本。为了与Windows XP以及以前版本的Windows兼容，x86镜像文件中这个结构的大小必须为64。

5.5.2 加载配置结构布局

用于32位和64位PE文件的加载配置结构布局如下：

5.6 .rsrc节

资源节可以看成是一个磁盘的分区，盘符是资源目录表，下面有3层目录（资源目录项），最后是文件（资源数据）。

①资源目录表是一个16字节组成的结构。其第一个字节又称为“根节点”。其前的12字节虽然有定义，但加载器并不理会，所以任何值都可以。

②第1层目录（资源目录项）是资源类型，微软已经定义了21种。其结构是一个16字节的数组。资源目录项分为名称项和ID项，这取决于资源目录表。资源目录表指出跟着它的名称项和ID项各有多少个（表中所有的名称项在所有的ID项前面）。表中的所有项按升序排列：名称项是按不区分大小写的字符串，而ID项则是按数值。第0-3字节表示资源类型的名称字符串的地址或是32位整数，第4-7字节表示第二层目录（资源目录项）相对于根节点的偏移。

一系列资源目录表按如下方式与各层相联系：每个目录表后面跟着一系列目录项，它们给出那个层（类型、名称或语言）的名称或标识（ID）及其数据描述或另一个目录表的地址。如果这个地址指向一个数据描述，那么那个数据就是这棵树的叶子。如果这个地址指向另一个目录表，那么那个目录表列出了下一层的目录项。

一个叶子的类型、名称和语言ID由从目录表到这个叶子的路径决定。第1个表决定类型ID，第2个表（由第一个表中的目录项指向）决定名称ID，第3个表决定语言ID。

.rsrc节的一般结构如下：

资源目录表

资源目录项

具体的情况是资源目录表后面紧跟着以名称项和ID项所组成的数组。资源目录表与资源目录项之间不能有空隙。名称项组成的数组在ID项组成的数组前面，且两个数组不能有空隙。

资源目录字符串

资源目录字符串区由按字边界对齐的Unicode字符串组成。这些字符串被存储在最后一个资源目录项之后、第一个资源数据项之前。这样能够使这些长度可变的字符串对长度固定的目录项的对齐情况影响最小。每个资源目录字符串格式如下：

资源数据项

每个资源数据项描述了资源数据区中一个实际单元的原始数据。资源数据项格式如下：

6 属性证书表

可以给镜像文件添加属性证书表使它与属性证书相关联。有多种不同类型的属性证书，最常用的是Authenticode签名。

属性证书表包含一个或多个长度固定的表项，可以通过NT头中的数据目录中的Certificate Table（证书表）域找到它们。这个表的每个表项给出了相应证书的开始位置和长度。存储在这个节中的每个证书都有一个相应的证书表项。证书表项的数目可以通过将证书表的大小除以证书表中每一项的大小（8）得到。注意证书表的大小仅包括它的表项，并不包括这些表项实际指向的证书。

每个表项格式如下：

注意证书总是从8进制字（从任意字节边界开始的16个连续字节）边界开始。如果一个证书的长度不是8进制字长度的偶数倍，那么就一直用0填充到下一个八进制字边界。但是证书长度并不包括这些填充的0。因此任何处理证书的软件必须向上舍入到下一个8进制字才能找到另一个证书。

证书的起始位置和长度由证书表中相应的表项给出。每个证书都有惟一一个与它对应的表项。

来源：看雪论坛http://bbs.pediy.com/showthread.php?t=145912

PE结构详解