开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2022.09.24云南
此规范介绍操作系统Windows系列下可执行(映像)文件和对象文件的结构。这些文件分别称为可移植可执行文件(PE)和通用对象文件格式(COFF)文件。
备注
本文档旨在帮助开发用于Windows的工具和应用程序，但不能保证在所有方面都是完整的规范。Microsoft保留未经通知更改此文档的权利。
Microsoft可移植可执行文件和通用对象文件格式规范的此修订版将替换此规范的所有以前的修订。
本文档指定MicrosoftWindows操作系统系列下的可执行(映像)文件和对象文件的结构。这些文件分别称为可移植可执行文件(PE)和通用对象文件格式(COFF)文件。名称“可移植可执行文件”是指格式不是特定于体系结构的事实。
下表描述了在整个此规范中显示的某些概念：
以下列表介绍MicrosoftPE可执行文件格式，其基础位于顶部的图像标头。从MS-DOS2.0兼容EXE标头到PE标头之前未使用的分区的部分是MS-DOS2.0部分，仅用于MS-DOS兼容性。
以下列表描述了MicrosoftCOFF对象模块格式：
PE文件标头由MicrosoftMS-DOS存根、PE签名、COFF文件标头和可选标头组成。COFF对象文件标头由COFF文件标头和可选标头组成。在这两种情况下，文件标头紧随节标头。
MS-DOS存根是一个在MS-DOS下运行的有效应用程序。它放置在EXE映像的前面。链接器在此处放置默认存根，当映像在MS-DOS中运行时，输出消息“此程序不能在DOS模式下运行”。用户可以使用/STUB链接器选项指定不同的存根。
在位置0x3c，存根具有PE签名的文件偏移量。此信息使Windows能够正确执行映像文件，即使它具有MS-DOS存根。此文件偏移量放置在链接期间的位置0x3c。
MS-DOS存根后，在偏移量指定的0x3c的文件偏移量处，是一个4字节签名，用于将该文件标识为PE格式图像文件。此签名是“PE\0\0”(字母“P”和“E”，后跟两个null字节)。
在对象文件的开头或图像文件的签名之后，是采用以下格式的标准COFF文件标头。请注意，Windows加载程序将分区数限制为96。
“计算机”字段具有以下值之一，用于指定CPU类型。映像文件只能在指定计算机或模拟指定计算机的系统上运行。
“特征”字段包含指示对象或图像文件属性的标志。当前定义了以下标志：
每个图像文件都有一个可选标头，用于向加载程序提供信息。此标头是可选的，因为某些文件(具体来说，对象文件)没有它。对于图像文件，此标头是必需的。对象文件可以有一个可选的标头，但通常此标头在对象文件中没有函数，只是为了增大其大小。
请注意，可选标头的大小未固定。COFF标头中的SizeOfOptionalHeader字段必须用于验证对特定数据目录的文件探测是否超出SizeOfOptionalHeader。有关详细信息，请参阅COFF文件头(对象和图像)。
还应使用可选标头的NumberOfRvaAndSizes字段来确保不会探测特定数据目录条目超出可选标头。此外，请务必验证可选的标头magic编号，以确保格式兼容性。
可选的标头magic号确定图像是PE32还是PE32+可执行文件。
PE32+图像允许64位地址空间，同时将图像大小限制为2GB。其他PE32+修改在各自的部分中得到解决。
可选标头本身有三个主要部分。
可选标头的前八个字段是为每个COFF实现定义的标准字段。这些字段包含用于加载和运行可执行文件的常规信息。对于PE32+格式，它们保持不变。
PE32包含此附加字段，此字段在PE32+中不存在，遵循BaseOfCode。
接下来的21个字段是COFF可选标头格式的扩展。它们包含链接器和加载程序在Windows中所需的其他信息。
为可选标头的子系统字段定义的以下值确定运行映像是否需要任何)(哪个Windows子系统。
为可选标头的DllCharacteristics字段定义了以下值。
typedefstruct_IMAGE_DATA_DIRECTORY{DWORDVirtualAddress;DWORDSize;}IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY;第一个字段VirtualAddress实际上是表的RVA。RVA是加载表时相对于映像基址的表的地址。第二个字段提供大小（以字节为单位）。下表列出了构成可选标头最后一部分的数据目录。
请注意，目录数未固定。在查找特定目录之前，请检查可选标头中的NumberOfRvaAndSizes字段。
此外，不要假设此表中的RVA指向节的开头，或者包含特定表的节具有特定名称。
证书表入口指向属性证书表。这些证书不会作为映像的一部分加载到内存中。因此，此条目的第一个字段通常是RVA，而是文件指针。
节表的每一行实际上都是节标题。此表紧跟可选标头（如果有）。此定位是必需的，因为文件头不包含指向节表的直接指针。相反，节表的位置是通过计算标头后第一个字节的位置来确定的。请确保使用文件标头中指定的可选标头的大小。
节表中的条目数由文件标头中的NumberOfSections字段提供。节表中的条目从一个(1个)开始编号。代码和数据内存节条目按链接器选择的顺序。
在图像文件中，节的VA必须由链接器分配，以便它们按升序和相邻顺序分配，并且它们必须是可选标头中的SectionAlignment值的倍数。
每个节标头(节表项)具有以下格式，每个条目总共40个字节。
节标头的“特征”字段中的节标志指示节的特征。
IMAGE_SCN_LNK_NRELOC_OVFL指示分区的重定位计数超过节标头中保留的16位。如果设置了位，并且节标头中的NumberOfRelocations字段0xffff，则实际重定位计数将存储在第一次重定位的32位VirtualAddress字段中。如果设置了IMAGE_SCN_LNK_NRELOC_OVFL，并且分区中的重定位次数少于0xffff，则会出现错误。
“$”？字符(美元符号)在对象文件中的节名称中具有特殊解释。
确定将包含对象节内容的图像节时，链接器将放弃“$”？及其后面的所有字符。因此，名为..text$X实际上为图像中的.text节做出贡献。
但是，“$”后面的字符？确定对图像部分的贡献的排序。具有相同对象节名称的所有贡献在图像中连续分配，并且按对象节名称按词法顺序对贡献块进行排序。因此，在.text$W贡献和.text$Y贡献之前，具有节名称.text$X的对象文件中的所有内容最终一起。
图像文件中的节名称永远不会包含“$”？字符。
到目前为止描述的数据结构（最多包括可选标头）均位于文件开头(或PE标头的固定偏移量（如果该文件是包含MS-DOS存根)的图像）。
COFF对象或图像文件的其余部分包含不一定在任何特定文件偏移量处的数据块。相反，位置由可选标头或节标头中的指针定义。
例外情况是，对于SectionAlignment值小于体系结构的页面大小的图像，(4KforIntelx86和MIPS，以及8K表示Itanium)。有关SectionAlignment的说明，请参阅仅)的可选标头(图像。在这种情况下，节数据的文件偏移量存在约束，如第5.1节“节数据”中所述。另一个例外是，属性证书和调试信息必须放置在映像文件的末尾，并且属性证书表紧接在调试节前面，因为加载程序不会将这些信息映射到内存中。但是，有关属性证书和调试信息的规则不适用于对象文件。
节的初始化数据由简单的字节块组成。但是，对于包含所有零的分区，不需要包含节数据。
每个节的数据位于节标头中的PointerToRawData字段给出的文件偏移量处。文件中此数据的大小由SizeOfRawData字段指示。如果SizeOfRawData小于VirtualSize，则余数填充为零。
在图像文件中，节数据必须在由可选标头中的FileAlignment字段指定的边界上对齐。节数据必须按相应节的RVA值的顺序显示，(节表中的各个节标题)。
如果可选标头中的SectionAlignment值小于体系结构的页面大小，则图像文件还有其他限制。对于此类文件，文件中分区数据的位置必须与加载图像时内存中的位置匹配，以便分区数据的物理偏移量与RVA相同。
对象文件包含COFF重定位，指定在图像文件中放置并随后加载到内存中时应如何修改节数据。
图像文件不包含COFF重定位，因为所有引用的符号都已分配给平面地址空间中的地址。除非映像具有)IMAGE_FILE_RELOCS_STRIPPED属性，否则映像包含以.reloc节中基重定位的形式(形式的重定位信息。有关详细信息，请参阅.reloc节(仅)映像。
对于对象文件中的每个节，固定长度记录的数组保留该节的COFF重定位。数组的位置和长度在节标头中指定。数组的每个元素具有以下格式。
如果SymbolTableIndex字段引用的符号具有存储类IMAGE_SYM_CLASS_SECTION，则符号的地址是节的开头。该节通常位于同一文件中，除非对象文件是存档库(库)的一部分。在这种情况下，可以在存档中具有与当前对象文件相同的存档成员名称的任何其他对象文件中找到该节。(导入表的链接（即.idatasection.)）中使用与存档成员名称的关系
重定位记录的“类型”字段指示应执行哪种类型的重定位。为每个类型的计算机定义不同的重定位类型。
为x64和兼容的处理器定义以下重定位类型指示器。
为ARM处理器定义以下重定位类型指示器。
为ARM64处理器定义了以下重定位类型指示器。
为SH3和SH4处理器定义了以下重定位类型指示器。SH5特定的重定位称为SHM(SHMedia)。
为PowerPC处理器定义以下重定位类型指示器。
为Intel386和兼容的处理器定义了以下重定位类型指示器。
为IntelItanium处理器系列和兼容的处理器定义了以下重定位类型指示器。请注意，指令上的重定位使用捆绑包的偏移量和槽号进行重定位偏移。
为MIPS处理器定义了以下重定位类型指示器。
为三菱M32R处理器定义了以下重定位类型指示器。
COFF行号不再生成，将来不会使用。
COFF行号由固定长度记录数组组成。(文件偏移量的位置)和数组的大小在节标头中指定。每条行号记录的格式如下。
Type字段是两个4字节字段的联合：SymbolTableIndex和VirtualAddress。
行号记录可以将“Linenumber”字段设置为零，并指向符号表中的函数定义，也可以通过提供正整数(行号)和对象代码中的相应地址来充当标准行号条目。
一组行号条目始终以第一种格式开头：函数符号的索引。如果这是节中的第一行号记录，则如果设置了该节的COMDAT标志，则它也是函数的COMDAT符号名称。请参阅COMDAT节(对象)。符号表中函数的辅助记录具有指向此相同行号记录的Linenumber字段的指针。
标识函数的记录后跟任意数量的行号条目，这些条目提供实际行号信息(，即具有大于零)的项。这些条目是一个基于一个的，相对于函数的开头，并表示函数中除第一行以外的每个源行。
例如，以下示例的第一个行号记录将指定ReverseSign函数(ReverseSign的SymbolTableIndex和Linenumber设置为零)。然后，带有1、2和3的包含1、2和3的记录将遵循，对应于源行，如下所示：
//somecodeprecedesReverseSignfunctionintReverseSign(inti)1:{2:return-1*i;3:}COFF符号表本节中的符号表继承自传统的COFF格式。它不同于MicrosoftVisualC++调试信息。文件可以同时包含COFF符号表和VisualC++调试信息，两者保持独立。某些Microsoft工具将符号表用于有限但重要的用途，例如将COMDAT信息传达给链接器。节名称和文件名以及代码和数据符号在符号表中列出。
符号表的位置在COFF标头中指示。
符号表是一个记录数组，每18个字节长。每个记录都是标准符号或辅助符号表记录。标准记录定义符号或名称，并具有以下格式。
零个或多个辅助符号表记录立即遵循每个标准符号表记录。但是，通常不超过一条辅助符号表记录遵循标准符号表记录(，但具有长文件名的.file记录)除外。每个辅助记录的大小与标准符号表记录的大小相同，(18字节)，但不定义新符号，辅助记录提供有关定义的最后一个符号的其他信息。要使用的多种格式的选择取决于StorageClass字段。辅助符号表记录的当前定义格式显示在第5.5节“辅助符号记录”。
读取COFF符号表的工具必须忽略解释未知的辅助符号记录。这允许扩展符号表格式以添加新的辅助记录，而无需中断现有工具。
符号表中的ShortName字段包含8个字节，如果名称长度不超过8个字节，则ShortName字段将偏移到字符串表中。若要确定是否给定名称本身或偏移量，请测试前4个字节是否等于零。
根据约定，名称被视为零终止的UTF-8编码字符串。
通常，符号表项中的“节值”字段是节表中的一个基于索引的索引。但是，此字段是带符号整数，可以采用负值。以下值小于一个，具有特殊含义。
符号表项的Type字段包含2个字节，其中每个字节表示类型信息。LSB表示简单(基)数据类型，MSB表示复杂类型（如果有）：
以下值是为基类型定义的，尽管Microsoft工具通常不使用此字段并将LSB设置为0。相反，VisualC++调试信息用于指示类型。但是，此处列出了可能的COFF值，以便完成。
最重要的字节指定符号是指向、函数返回还是LSB中指定的基类型的数组的指针。Microsoft工具仅使用此字段来指示符号是否为函数，以便只有两个生成的值0x0和类型字段的0x20。但是，其他工具可以使用此字段来传达更多信息。
正确指定函数属性非常重要。增量链接需要此信息才能正常工作。对于某些体系结构，可能需要这些信息才能用于其他目的。
符号表的StorageClass字段指示符号表示的定义类型。下表显示了可能的值。请注意，StorageClass字段是一个无符号1字节整数。因此，应采用特殊值-1表示其无符号等效值，0xFF。
尽管传统的COFF格式使用许多存储类值，但Microsoft工具依赖于VisualC++调试格式来获取大多数符号信息，并且通常只使用四个存储类值：EXTERNAL(2)、STATIC(3)、FUNCTION(101)和FILE(103)。除了下面的第二列标题中，应采用“值”来表示符号记录的值字段(其解释取决于作为存储类)找到的数字。
辅助符号表记录始终遵循并应用于某些标准符号表记录。辅助记录可以识别任何格式，但必须为其分配18个字节，以便符号表作为常规大小的数组进行维护。目前，Microsoft工具识别以下类型的记录的辅助格式：函数定义、函数开始和结束符号(.bf和.ef)、弱外部、文件名和节定义。
传统的COFF设计还包括数组和结构的辅助记录格式。Microsoft工具不使用它们，而是在调试部分中将符号信息置于VisualC++调试格式中。
符号表记录将标记函数定义的开头（如果函数定义具有以下所有条件）：EXTERNAL(2)的存储类、指示它是函数(0x20)的类型值，以及大于零的节数。请注意，符号表记录的节数为UNDEFINED(0)不定义函数，并且没有辅助记录。函数定义符号记录后跟以下格式的辅助记录：
对于符号表中的每个函数定义，三个项描述了行的开始、结束和行数。每个符号都有存储类FUNCTION(101)：
名为.bf(begin函数)的符号记录。“值”字段未使用。
函数)中名为.lf的符号记录(行。“值”字段提供函数中的行数。
名为.ef(函数)末尾的符号记录。“值”字段的数字与函数定义符号记录中的“总大小”字段相同。
.bf和.ef符号记录(但不是.lf记录)后跟具有以下格式的辅助记录：
“弱外部”是对象文件的一种机制，允许在链接时灵活。模块可以包含未解析的外部符号(sym1)，但它还可以包含一个辅助记录，指示如果符号1在链接时不存在，则使用另一个外部符号(sym2)解析引用。
如果符号1的定义已链接，则通常解析对符号的外部引用。如果未链接sym1的定义，则对sym1弱外部的所有引用都指sym2。外部符号sym2必须始终链接;通常，它在模块中定义，其中包含对sym1的弱引用。
弱外部由具有EXTERNAL存储类、UNDEF节号和值为零的符号表记录表示。弱外部符号记录后跟具有以下格式的辅助记录：
请注意，“特征”字段未在WINNT中定义。H;而是使用“总大小”字段。
此格式遵循存储类FILE(103)的符号表记录。符号名称本身应为.file，后面的辅助记录提供源代码文件的名称。
此格式遵循定义节的符号表记录。此类记录具有符号名称，该符号名称是.text或.drectve)等(节的名称，并且存储类STATIC(3)。辅助记录提供有关其引用部分的信息。因此，它会复制节标头中的一些信息。
如果节是COMDAT节，则节定义辅助格式的“选择”字段适用。COMDAT节是由多个对象文件定义的节。(在节标头的“节标志”字段中设置标志IMAGE_SCN_LNK_COMDAT。)“选择”字段确定链接器解析COMDAT节的多个定义的方式。
“选择”字段的值如下所示。
紧跟COFF符号表的是COFF字符串表。可以通过在COFF标头中获取符号表地址并添加符号数乘以符号的大小来找到此表的位置。
COFF字符串表的开头是4个字节，其中包含字符串表其余部分的总大小(字节)。此大小包括大小字段本身，因此如果不存在字符串，则此位置中的值将为4。
大小之后是COFF符号表中的符号指向的以null结尾的字符串。
可以通过添加属性证书表来与映像关联属性证书。属性证书表由一组连续、四字对齐的属性证书条目组成。在文件的原始末尾和属性证书表的开头之间插入零填充，以实现此对齐。每个属性证书条目包含以下字段。
可选标头数据目录中证书表条目中的虚拟地址值是第一个属性证书条目的文件偏移量。后续条目通过从当前属性证书条目开头向上舍入到8字节倍数的dwLength字节来访问。这一点一直持续到舍入dwLength值之和等于可选标头数据目录中“证书表”条目中的Size值。如果舍入dwLength值的总和不等于Size值，则属性证书表或Size字段已损坏。
例如，如果可选标头数据目录的证书表项包含：
virtualaddress=0x5000size=0x1000第一个证书从磁盘上文件的开头偏移量0x5000开始。若要推进所有属性证书条目，请执行以下操作：
或者，可以通过在循环中调用Win32ImageEnumerateCertificates函数来枚举证书条目。有关函数引用页的链接，请参阅“引用”。
只要条目具有正确的dwLength值、唯一wRevision值和唯一wCertificateType值，属性证书表条目就可以包含任何证书类型。最常见的证书表条目类型是一种WIN_CERTIFICATE结构，该结构记录在Wintrust.h中，在本部分的其余部分进行了讨论。
WIN_CERTIFICATEwRevision成员的选项包括(，但不限于)以下内容。
WIN_CERTIFICATEwCertificateType成员的选项包括(，但不限于)下表中的项。请注意，当前不支持某些值。
如果bCertificate内容不以四字边界结尾，则从bCertificate的末尾到下一个四字边界，属性证书条目用零填充。
dwLength值是最终WIN_CERTIFICATE结构的长度，并计算为：
dwLength=offsetof(WIN_CERTIFICATE,bCertificate)+(sizeofthevariable-lengthbinaryarraycontainedwithinbCertificate)
此长度应包括用于满足每个WIN_CERTIFICATE结构的四字对齐要求的任何填充的大小：
dwLength+=(8-(dwLength&7))&7;
可选标头数据目录的“证书表”条目中指定的“证书表”大小(仅图像)-包括填充。
如上一部分所述，属性证书表中的证书可以包含任何证书类型。确保PE文件完整性的证书可能包括PE映像哈希。
在证书中包含时，映像摘要必须排除PE映像中的某些字段，例如可选标头数据目录中的校验和和证书表条目。这是因为添加证书的行为会更改这些字段，并会导致计算不同的哈希值。
Win32ImageGetDigestStream函数提供目标PE文件中用于哈希函数的数据流。向PE文件添加或删除证书时，此数据流保持一致。根据传递给ImageGetDigestStream的参数，可以从哈希计算中省略PE映像中的其他数据。有关函数引用页的链接，请参阅“引用”。
这些表已添加到映像中，以支持应用程序在首次调用该DLL之前延迟加载DLL的统一机制。表的布局与第6.4节.idata节中所述的传统导入表的布局匹配。此处只讨论一些详细信息。
延迟加载目录表与导入目录表对应。可以通过可选标头数据目录列表中的延迟导入描述符条目来检索它，(偏移量200)。表按如下所示排列：
此数据结构中引用的表组织并排序，就像其对应项用于传统导入一样。有关详细信息，请参阅.idata节。
但尚未定义任何属性标志。链接器将此字段设置为图像中的零。此字段可用于通过指示新字段的存在来扩展记录，或者可用于指示延迟或卸载帮助程序函数的行为。
要延迟加载的DLL的名称驻留在图像的只读数据部分中。它通过szName字段引用。
要延迟加载的DLL的句柄位于图像的数据部分。phmod字段指向句柄。提供的延迟加载帮助程序使用此位置将句柄存储到加载的DLL。
延迟导入地址表(IAT)由延迟导入描述符通过pIAT字段引用。延迟加载帮助程序使用实际入口点更新这些指针，以便thunk不再位于调用循环中。使用表达式pINT->u1.Function访问函数指针。
延迟导入名称表(INT)包含可能需要加载的导入的名称。它们按与IAT中的函数指针相同的方式排序。它们包含与标准INT相同的结构，并使用表达式pINT->u1.AddressOfData->Name[0]进行访问。
延迟卸载导入地址表(UIAT)是卸载代码用于处理显式卸载请求的可选IMAGE_THUNK_DATA项表。它由只读部分中的初始化数据组成，它是将代码引用到延迟加载thunk的原始IAT的确切副本。在卸载请求中，可以释放库、清除*phmod以及通过IAT编写的UIAT，以将所有内容还原到其预加载状态。
但是，某些COFF部分在对象文件或图像文件中找到时具有特殊含义。工具和加载程序会识别这些节，因为它们在节标头中设置了特殊标志，因为图像中的特殊位置可选标头指向它们，或者节名称本身表示节的特殊函数。(即使节名称本身未指示节的特殊功能，节名称也由约定决定，因此此规范的作者可以在所有情况下引用节名称。)
下表描述了保留节及其属性，后面是保存到可执行文件中的节类型的详细说明，以及包含扩展元数据的节类型。
.debug节在对象文件中用于包含编译器生成的调试信息和图像文件中，以包含生成的所有调试信息。本部分介绍在对象和图像文件中打包调试信息。
下一部分介绍调试目录的格式，该目录可以是映像中的任意位置。后续部分介绍包含调试信息的对象文件中的“组”。
链接器的默认是调试信息不会映射到图像的地址空间。仅当调试信息在地址空间中映射时，才存在.debug节。
图像文件包含可选调试目录，指示存在何种形式的调试信息及其所在位置。此目录由一组调试目录条目组成，其位置和大小在图像可选标头中指示。
调试目录可以位于可丢弃的.debug节(如果存在)，也可以包含在映像文件的任何其他部分，或者根本不包含在分区中。
每个调试目录条目标识调试信息块的位置和大小。如果节标头(未涵盖调试信息，则指定的RVA可以为零，即它驻留在映像文件中，并且不会映射到运行时地址空间)。如果映射它，则RVA是其地址。
调试目录条目具有以下格式：
为调试目录条目的Type字段定义了以下值：
如果Type字段设置为IMAGE_DEBUG_TYPE_FPO，则调试原始数据是一个数组，其中每个成员描述函数的堆栈帧。映像文件中的每一个函数都必须为其定义FPO信息，即使调试类型为FPO也是如此。假定没有FPO信息的函数具有普通堆栈帧。FPO信息的格式如下所示：
如果类型字段设置为IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS，则调试原始数据包含扩展的DLL特征位，除了可以在图像的可选标头中设置的字段之外。请参阅可选标头Windows-Specific字段(图像)部分中的DLL特征。
为扩展DLL特征位定义了以下值。
本节中的数据已被VisualC++版本7.0及更高版本取代，该数据集已发出到.debug$S子节中。
对象文件可以包含.debug$F节，其内容是一个或多个FPO_DATA记录，(帧指针遗漏信息)。请参阅调试类型中的“IMAGE_DEBUG_TYPE_FPO”。
链接器可识别这些.debug$F记录。如果正在生成调试信息，链接器会按过程RVA对FPO_DATA记录进行排序，并为其生成调试目录条目。
编译器不应为具有标准帧格式的过程生成FPO记录。
本部分包含VisualC++调试信息(符号信息)。
本部分包含visualC++调试信息(预编译信息)。这些是使用此对象生成的预编译标头编译的所有对象的共享类型。
本部分包含VisualC++调试信息(类型信息)。
若要支持调试信息，链接器：
如果节在节标头中设置了IMAGE_SCN_LNK_INFO标志，并且具有.drectve节名称，则节是指令节。链接器在处理信息后删除.drectve节，因此该节不会显示在正在链接的图像文件中。
.drectve节由可编码为ANSI或UTF-8的文本字符串组成。如果UTF-8字节顺序标记(BOM，则由0xEF、0xBB和0xBF)组成的三字节前缀解释为ANSI。指令字符串是由空格分隔的一系列链接器选项。每个选项都包含连字符、选项名称和任何适当的属性。如果某个选项包含空格，则必须用引号括住该选项。.drectve节不得具有重定位或行号。
名为.edata的导出数据部分包含有关其他图像可通过动态链接访问的符号的信息。导出的符号通常位于DLL中，但DLL也可以导入符号。
下面概述了导出部分的一般结构。描述的表通常以(所示的顺序在文件中连续，但这不是)所必需的。只有导出目录表和导出地址表才能将符号导出为序号。(序号是直接通过其导出地址表索引进行访问的导出。)名称指针表、序号表和导出名称表都存在以支持使用导出名称。
当另一个图像文件按名称导入符号时，Win32加载程序会在名称指针表中搜索匹配字符串。如果找到匹配的字符串，则通过查找序号表中的相应成员来标识关联的序号(，即与名称指针表中找到的字符串指针具有相同索引的序号表的成员)。生成的序号是导出地址表中的索引，它提供所需符号的实际位置。每个导出符号都可以按序号访问。
当另一个图像文件按序号导入符号时，无需搜索名称指针表以查找匹配字符串。因此，直接使用序号更高效。但是，导出名称更易于记住，并且不需要用户知道符号的表索引。
导出符号信息以导出目录表开头，该表描述导出符号信息的其余部分。导出目录表包含用于解析此映像中入口点的导入的地址信息。
导出地址表包含导出入口点的地址和导出的数据和绝对值。序号用作导出地址表中的索引。
导出地址表中的每个条目都是使用下表中两种格式之一的字段。如果指定的地址不在导出节中，(由可选标头)中指示的地址和长度定义，则字段是导出RVA，这是代码或数据中的实际地址。否则，该字段是一个转发器RVA，它为另一个DLL中的符号命名。
转发器RVA从一些其他映像导出定义，使其看起来就像当前映像正在导出一样。因此，符号同时导入和导出。
例如，在WindowsXP中的Kernel32.dll中，名为“HeapAlloc”的导出将转发到字符串“NTDLL”。RtlAllocateHeap。”这样，应用程序就可以使用特定于XP的Windows模块Ntdll.dll，而无需实际包含对其的导入引用。应用程序的导入表仅引用Kernel32.dll。因此，应用程序不特定于WindowsXP，可以在任何Win32系统上运行。
导出名称指针表是导出名称表中(RVA)地址数组。每个指针为32位，相对于图像基础。指针按词法排序，以允许二进制搜索。
仅当导出名称指针表包含指向它的指针时，才定义导出名称。
导出序号表是导出地址表中16位无偏差索引的数组。序号因导出目录表的序号基字段而有偏差。换句话说，必须从序号中减去序号，才能将真正的索引导出到导出地址表中。
导出名称指针表和导出序号表形成两个并行数组，以允许自然字段对齐。这两个表实际上充当一个表，其中“导出名称指针”列指向)名称导出的公共(，“导出序号”列为该公共名称提供相应的序号。导出名称指针表的成员和导出序号表的成员通过在其各自的数组中具有相同的位置(索引)关联。
因此，当搜索导出名称指针表并在位置i找到匹配字符串时，用于查找符号的RVA和偏置序号的算法为：
i=Search_ExportNamePointerTable(name);ordinal=ExportOrdinalTable[i];rva=ExportAddressTable[ordinal];biased_ordinal=ordinal+OrdinalBase;通过(偏差)序号搜索符号时，用于查找符号的RVA和名称的算法为：
ordinal=biased_ordinal-OrdinalBase;i=Search_ExportOrdinalTable(ordinal);rva=ExportAddressTable[ordinal];name=ExportNameTable[i];导出名称表导出名称表包含导出名称指针表指向的实际字符串数据。此表中的字符串是其他图像可用于导入符号的公共名称。这些公共导出名称不一定与符号在其自己的映像文件和源代码中具有的专用符号名称相同，尽管可以。
导出名称表的结构是一系列以null结尾的ASCII字符串，长度可变。
导入符号的所有图像文件（包括几乎所有可执行(EXE)文件）都具有.idata节。导入信息的典型文件布局如下：
导入信息以导入目录表开头，其中描述了导入信息的其余部分。导入目录表包含用于解析对DLL映像中入口点的修复引用的地址信息。导入目录表由一组导入目录条目组成，每个映像引用的DLL都有一个条目。最后一个目录条目为空(用null值填充)，指示目录表的末尾。
每个导入目录条目采用以下格式：
导入查找表是PE32的32位数字数组，或PE32+的64位数字数组。每个条目都使用下表中所述的位字段格式。在此格式中，位31是PE32的最大有效位，位63是PE32+的最大有效位。这些条目的集合描述了从给定DLL导入的所有导入。最后一个条目设置为零(NULL)以指示表末尾。
整个导入节的一个提示/名称表足以满足要求。提示/名称表中的每个条目具有以下格式：
导入地址表的结构和内容与导入查找表的结构和内容相同，直到文件绑定为止。在绑定期间，导入地址表中的条目被PE32)的32位(覆盖，对于要导入的符号的符号)地址，将覆盖64位(。这些地址是符号的实际内存地址，尽管从技术上讲，它们仍称为“虚拟地址”。加载程序通常处理绑定。
.pdata节包含用于异常处理的函数表项数组。它由图像数据目录中的异常表项指向。必须根据函数地址对条目进行排序，(每个结构中的第一个字段)，然后再发出到最终图像中。目标平台确定使用以下三个函数表条目格式变体中的哪一种。
对于32位MIPS图像，函数表条目的格式如下：
对于ARM、PowerPC、SH3和SH4WindowsCE平台，函数表条目的格式如下：
对于x64和Itanium平台，函数表条目的格式如下：
基本重定位表包含映像中所有基本重定位的条目。可选标头数据目录中的“基本重定位表”字段提供基重定位表中的字节数。有关详细信息，请参阅仅)(映像的可选标头数据目录。基本重定位表分为块。每个块表示4K页的基本重定位。每个块必须在32位边界上启动。
加载程序不需要处理链接器解析的基本重定位，除非无法在PE标头中指定的映像基础加载映像。
每个基本重定位块都以以下结构开头：
然后，“块大小”字段后跟任意数量的“类型”或“偏移量”字段条目。每个条目是WORD(2个字节)，具有以下结构：
若要应用基本重定位，将计算首选基址与实际加载图像的基址之间的差异。如果图像加载在其首选基础处，则差异为零，因此无需应用基本重定位。
请注意，可以使用API调用TlsAlloc、TlsFree、TlsSetValue和TlsGetValue来支持任意数量的TLS数据。PE或COFF实现是使用API的替代方法，具有从高级语言程序员的角度来看更简单的优势。此实现使TLS数据能够定义和初始化，类似于程序中的普通静态变量。例如，在VisualC++中，静态TLS变量可以定义如下，而无需使用WindowsAPI：
__declspec(thread)inttlsFlag=1;
为了支持此编程构造，PE和COFF.tls节指定以下信息：初始化数据、每个线程初始化和终止的回调例程以及以下讨论中介绍的TLS索引。
可执行代码通过以下步骤访问静态TLS数据对象：
TLS数组是系统为每个线程维护的地址数组。此数组中的每个地址都为给定模块提供TLS数据的位置，(EXE或DLL)程序中。TLS索引指示要使用的数组成员。索引是一个对标识模块的系统)有意义的数字(。
TLS目录具有以下格式：
程序可以提供一个或多个TLS回调函数，以支持TLS数据对象的其他初始化和终止。此类回调函数的典型用途是调用对象的构造函数和析构函数。
尽管通常没有多个回调函数，但回调作为数组实现，以便根据需要添加其他回调函数。如果有多个回调函数，则会按数组中显示其地址的顺序调用每个函数。null指针终止数组。如果空列表()不支持回调，那么回调数组正好具有一个成员一个null指针，这一点非常有效。
回调函数的原型(由类型PIMAGE_TLS_CALLBACK)指针指向的原型与DLL入口点函数具有相同的参数：
typedefVOID(NTAPI*PIMAGE_TLS_CALLBACK)(PVOIDDllHandle,DWORDReason,PVOIDReserved);保留参数应设置为零。Reason参数可以采用以下值：
(IMAGE_LOAD_CONFIG_DIRECTORY)负载配置结构以前用于WindowsNT操作系统本身中非常有限的情况下，用于描述各种功能太困难或太大，无法描述映像的文件头或可选标头。Microsoft链接器的最新版本和WindowsXP及更高版本的Windows将此结构的新版本用于包含保留SEH技术的基于32位x86的系统。这提供了操作系统在异常调度期间使用的安全结构化异常处理程序的列表。如果处理程序地址驻留在图像的VA范围内，并且标记为保留SEH感知(（即，IMAGE_DLLCHARACTERISTICS_NO_SEH在可选标头的DllCharacteristics字段中清晰显示），如前面)所述，则处理程序必须位于该映像的已知安全处理程序列表中。否则，操作系统将终止应用程序。这有助于防止过去用于控制操作系统的“x86异常处理程序劫持”攻击。
Microsoft链接器自动提供默认的负载配置结构，以包含保留的SEH数据。如果用户代码已提供负载配置结构，则必须包含新的保留SEH字段。否则，链接器不能包含保留的SEH数据，并且图像未标记为包含保留SEH。
预留SEH负载配置结构的数据目录条目必须指定负载配置结构的特定大小，因为操作系统加载程序始终期望它是特定值。在这方面，大小实际上只是版本检查。若要与WindowsXP和早期版本的Windows兼容，对于x86映像，大小必须为64。
负载配置结构针对32位和64位PE文件具有以下布局：
GuardFlags字段包含以下一个或多个标志和子字段的组合：
此外，WindowsSDKwinnt.h标头定义此宏，以便将GuardFlags值右移的位数调整为控制FlowGuard函数表的步幅：
#defineIMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_SHIFT28
资源由多级二进制排序树结构编制索引。常规设计可以包含2**31个级别。但是，按照约定，Windows使用三个级别：
一系列资源目录表按以下方式关联所有级别：每个目录表后跟一系列目录条目，这些条目为该级别提供名称或标识符(ID)(类型、名称或语言级别)以及数据说明或其他目录表的地址。如果地址指向数据说明，则数据是树中的叶。如果地址指向另一个目录表，则该表会在下一级别列出目录条目。
叶的类型、名称和语言ID取决于通过目录表访问叶的路径。第一个表确定类型ID，第二个表(由第一个表中的目录项指向)确定名称ID，第三个表确定语言ID。
.rsrc部分的一般结构为：
每个资源目录表的格式如下。此数据结构应被视为表的标题，因为该表实际上由第6.9.2节“资源目录条目”)和此结构中所述(目录条目组成：
资源目录字符串区域由Unicode字符串组成，这些字符串是单词对齐的。这些字符串存储在最后一个资源目录条目之后和第一个资源数据条目之前。这会最大程度地减少这些可变长度字符串对固定大小目录条目对齐的影响。每个资源目录字符串的格式如下：
每个资源数据条目描述资源数据区域中原始数据的实际单位。资源数据条目的格式如下：
CLR元数据存储在本节中。它用于指示对象文件包含托管代码。元数据的格式未记录，但可以交给CLR接口来处理元数据。
该对象的.sxdata节中列出了对象的有效异常处理程序。该部分标记为IMAGE_SCN_LNK_INFO。它包含每个有效处理程序的COFF符号索引，每个索引使用4个字节。
此外，编译器通过发出绝对符号“@feat.00”并将值字段的LSB设置为1，将COFF对象标记为已注册SEH。没有已注册SEH处理程序的COFF对象将具有“@feat.00”符号，但没有.sxdata节。
COFF存档格式提供用于存储对象文件集合的标准机制。这些集合通常称为编程文档中的库。
存档的前8个字节由文件签名组成。其余存档由一系列存档成员组成，如下所示：
存档成员标头位于每个成员之前。以下列表显示了存档的一般结构：
...
存档文件签名标识文件类型。例如，任何实用工具(，将存档文件作为输入的链接器)可以通过读取此签名来检查文件类型。签名由以下ASCII字符组成，下面每个字符按字面表示，但换行符(\n)字符除外：
!
每个成员(链接器、longname或对象文件成员)前面都有一个标头。存档成员标头采用以下格式，其中每个字段都是ASCII文本字符串，该字符串保持对齐，并用空格填充到字段末尾。这些字段中没有任何终止null字符。
每个成员标头在上一个存档成员末尾之后的第一个偶数地址开始。
“名称”字段具有下表中显示的格式之一。如前所述，这些字符串中每个字符串都保持对齐，并在16个字节的字段中用尾随空格填充：
第一个链接器成员的名称为“/”。包含第一个链接器成员以实现向后兼容性。当前链接器不使用它，但其格式必须正确。此链接器成员提供符号名称目录，与第二个链接器成员一样。对于每个符号，信息指示在何处查找包含符号的存档成员。
第一个链接器成员具有以下格式。此信息显示在标头后面：
偏移数组中的元素必须按升序排列。此事实意味着字符串表中的符号必须按照存档成员的顺序排列。例如，第一个对象文件成员中的所有符号都必须在第二个对象文件中的符号之前列出。
第二个链接器成员的名称为“/”，与第一个链接器成员一样。尽管这两个链接器成员都提供包含符号和存档成员的目录，但第二个链接器成员优先于所有当前链接器的第一个。第二个链接器成员按词法顺序包括符号名称，这样就可以更快地按名称进行搜索。
第二个成员具有以下格式。此信息显示在标头后面：
longnames成员的名称为“//”。longnames成员是存档成员名称的一系列字符串。仅当“名称”字段中的空间不足时，才会在此处显示一个名称，(16字节)。longnames成员是可选的。它可以是空的，只有一个标头，或者它完全不存在，甚至没有标头。
字符串以null结尾。每个字符串在上一个字符串中的null字节之后立即开始。
传统的导入库，即描述从一个映像导出供另一个映像使用的库，通常遵循第7节“存档(库”)文件格式中所述的布局。主要区别在于，导入库成员包含伪对象文件而不是实际文件，其中每个成员都包含生成第6.4节中所述的导入表所需的节贡献，.idata节链接器在生成导出应用程序时生成此存档。
可以从一组信息推断导入的部分贡献。链接器可以在库创建时为每个成员生成完整的详细信息，也可以只将规范信息写入库，让以后使用它生成所需的数据的应用程序。
在格式较长的导入库中，单个成员包含以下信息：
相比之下，将编写一个简短的导入库，如下所示：
这是足够的信息，以便在其使用时准确重新构造成员的全部内容。
导入标头包含以下字段和偏移量：
此结构后跟两个以null结尾的字符串，这些字符串描述导入符号的名称和传入的DLL。
为导入标头中的Type字段定义了以下值：
这些值用于确定哪些节贡献必须由使用库的工具生成（如果该工具必须访问该数据）。
以null结尾的导入符号名称紧跟其关联的导入标头。为导入标头中的“名称类型”字段定义了以下值。它们指示如何使用名称生成表示导入的正确符号：
在Authenticode签名中，文件哈希通过使用仅对文件的签名者已知的私钥进行数字签名。软件使用者可以通过计算文件的哈希值并将其与Authenticode数字签名中包含的已签名哈希值进行比较来验证文件的完整性。如果文件哈希不匹配，则已修改PE映像哈希涵盖的一部分文件。
在PE图像哈希的计算中包括所有图像文件数据是不可能的，也不需要这样做。有时，它只是(呈现不受欢迎的特征，例如，无法从公开发布的文件中删除调试信息);有时这简直是不可能的。例如，无法在Authenticode签名中包含图像文件中的所有信息，然后将包含PE图像哈希的Authenticode签名插入PE映像，然后能够再次在计算中包含所有图像文件数据来生成相同的PE图像哈希，因为该文件现在包含最初不存在的Authenticode签名。
本部分介绍如何计算PE映像哈希，以及如何修改PE映像的各个部分，而不会使Authenticode签名失效。
除以下排除范围外，分区表中指定的PE映像各节中的所有数据均按其全部哈希处理：
若要计算PE图像哈希，Authenticode按地址范围对节表中指定的节进行排序，然后对生成的字节序列进行哈希处理，并传递超过排除范围。
可以使用Windows平台SDK中提供的makecert和signtool工具来尝试创建和验证Authenticode签名。有关详细信息，请参阅下面的参考。