13.PE文件格式

PE文件是Windows操作系统下使用的可执行文件格式。它是微软在UNIX平台的COFF（Common　Object　File　Format），通用对象文件格式）基础上制作而成的。最初（正如Portable这个单词所代表的那样）设计用来提高程序在不同操作系统上的移植性，但实际上这种文件格式仅用在Windows系列的操作系统下。
PE文件是指32位的可执行文件，也称为PE32。64位的可执行文件称为PE+或PE32+，是PE（PE32）文件的一种扩展形式（请注意不是PE64)。　

严格地说，OBJ（对象）文件之外的所有文件都是可执行的。DLL、SYS文件等虽然不能直接在Shell（Explorer.exe）中运行，但可以使用其他方法（调试器、服务等）执行。

然后我们用010打开记事本，
图中是 notepad.exe 文件的起始部分，也是PE文件的头部分（PEheader)。notepad.exe文件运行需要的所有信息就存储在这个PE头中。如何加载到内存、从何处开始运行、运行中需要的DLL有哪些、需要多大的栈/堆内存等，大量信息以结构体形式存储在PE头中。
换言之，学习PE文件格式就是学习PE头中的结构体。

从DOS头（DOSheader）到节区头（Section header）是PE头部分，其下的节区合称PE体。文件中使用偏移（offset)，内存中使用VA（VirtualAddress，虚拟地址）来表示位置。文件加载到内存时，情况就会发生变化（节区的大小、位置等）。

文件的内容一般可分为代码（.text）、数据(.data)、资源（.rsrc）节，分别保存。

各节区头定义了各节区在文件或内存中的大小、位置、属性等。

PE头与各节区的尾部存在一个区域，称为NULL填充（NULLpadding)。计算机中，为了提高处理文件、内存、网络包的效率，使用“最小基本单位”这一概念，

PE文件中也类似。文件/内存中节区的起始位置应该在各文件/内存最小单位的倍数位置上，空白区域将用NULL填充（看图，可以看到各节区起始地址的截断都遵循一定规则）。

PE头内部信息大多以RVA形式存在。原因在于，PE文件（主要是DLL）加载到进程虚拟内
存的特定位置时，该位置可能已经加载了其他PE文件（DLL)。此时必须通过重定位（Relocation）将其加载到其他空白的位置，若PE头信息使用的是VA，则无法正常访问。因此使用RVA来定位信息，即使发生了重定位，只要相对于基准位置的相对地址没有变化，就能正常访问到指定信息，不会出现任何问题。

PE头由许多结构体组成

微软创建PE文件格式时，人们正广泛使用DOS文件，所以微软充分考虑了PE文件对DOS文件的兼容性。其结果是在PE头的最前面添加了一个 IMAGE_DOS_HEADER 结构体，用来扩展已有的DOS EXE头。
如图

IMAGE_DOS_HEADER 结构体的大小为 0x40个字节。 主要由两个重要成员

如果我们修改这两处任意一个值，都会发现程序无法运行（因为根据PE规范，它已经不是PE文件了）

DOS存根（stub）在DOS头下方，是个可选项，且大小不固定（即使没有DOS存根，文件也能正常运行）。DOS存根由代码与数据混合而成

其中40-4D处的16进制是一串16位的汇编指令，32位的windowsOS中不会运行此命令（由于被识别为PE文件，所以完全忽视该代码）
如果在DOS环境中运行记事本，或者使用调试器运行，就会输出 This program cannot be run in DOS mode 然后就退出

NT头 IMAGE_NT_HEADERS 结构体由3个成员组成

文件头 IMAGE_FILE_HEADERS 结构体中有如下4种重要成员（若它们设置不正确，将导致文件无法正常运行)。

1.Machine
每个CPU都拥有唯一的Machine码，兼容32位Intelx86芯片的Machine码为14C。

2.NumberOfSections
前面提到过，PE文件把代码、数据、资源等依据属性分类到各节区中存储。
NumberOfSections 用来指出文件中存在的节区数量。该值一定要大于0，且当定义的节区数量与实际节区不同时，将发生运行错误。

3 .SizeOfOptionalHeader
IMAGE_NT_HEADER结构体的最后一个成员为IMAGE_OPTIONAL_HEADER32结构体。
SizeOfOptionalHeader成员用来指出IMAGE_OPTIONAL_HEADER32结构体的长度

IMAGE_OPTIONAL_HEADER32 结构体由C语言编写而成，故其大小已经确定。但是Windows的PE装载器需要查看 IMAGE_FILE_HEADER 的 SizeOfOptionalHeader 值，从而识别出 IMAGE_OPTIONAL_HEADER32 结构体的大小。

PE32+格式的文件中使用的是 IMAGE_OPTIONAL_HEADER64 结构体，而不是 IMAGEOPTIONAL_HEADER32 结构体。2个结构体的尺寸是不同的，所以需要 SizeOfOptionalHeader 成员中明确指出结构体的大小。

4.CHaracteristics
该字段用于标识文件的属性，文件是否是可运行的形态、是否为DLL文件等信息，以bitOR形式组合起来。
以下是定义在 winnt.h 文件中的Characteristics值（请记住0002h与2000h这两个值）

另外，PE文件中Characteristics的值可以不是0002h（不可执行的），比如类似*.obj的object文件及resourceDLL文件等。

5. 不影响文件运行的 TimeDateStampA 成员
该成员的值不影响文件运行，用来记录编译器创建此文件的时间。但是有些开发工具（VB、VC++）提供了设置该值的工具，而有些开发工具（Delphi）则未提供（且随所用选项的不同而不同）

IMAGE_OPTIONAL_HEADER32 是PE头结构体中最大的。
在 IMAGE_OPTIONAL_HEADER32 结构体中需要关注下列成员。这些值是文件运行必需的，设置错误将导致文件无法正常运行。

1.Magic
为 IMAGE_OPTIONAL_HEADER32 结构体时，Magic码为 10B
为 IMAGE_OPTIONALHEADER64 结构体时，Magic码为 20B

2 .AddressOfEntryPoint
AddressOfEntryPoint持有EP的RVA值。该值指出程序最先执行的代码起始地址，相当重要。

3 .ImageBase
进程虚拟内存的范围是0~FFFFFFFF（32位系统)。PE文件被加载到如此大的内存中时，ImageBase指出文件的优先装人地址。

EXE、DLL文件被装载到用户内存的0~7FFFFFFF中，SYS文件被载人内核内存的80000000~FFFFFFFF中。一般而言，使用开发工具（VB/VC++/Delphi）创建好EXE文件后，其ImageBase的值为00400000，DLL文件的ImageBase值为10000000（当然也可以指定为其他值）。执行PE文件时，PE装载器先创建进程，再将文件载人内存，然后把EIP寄存器的值设置为ImageBase+AddressOfEntryPoint。

4. SectionAlignment, FileAlignment
PE文件的Body部分划分为若干节区，这些节存储着不同类别的数据。FileAlignment指定了节区在磁盘文件中的最小单位，而SectionAlignment则指定了节区在内存中的最小单位（一个文件中，FileAlignment与SectionAlignment的值可能相同，也可能不同）。
磁盘文件或内存的节区大小必定为FileAlignment或SectionAlignment值的整数倍。

5 . SizeOfImage
加载PE文件到内存时，SizeOfImage指定了PEImage在虚拟内存中所占空间的大小。一般而言，文件的大小与加载到内存中的大小是不同的（节区头中定义了各节装载的位置与占有内存的大小）

6 .SizeOfHeader
SizeOfHeader用来指出整个PE头的大小。该值也必须是FileAlignment的整数倍。第一节区所在位置与SizeOfHeader距文件开始偏移的量相同。

7 .Subsystem
该Subsystem值用来区分系统驱动文件（*.sys)与普通的可执行文件(*.exe,*.dll)。Subsystem成员可拥有的值如表所示。

8 .NumberOfRvaAndSizes
NumberOfRvaAndSizes用来指定DataDirectory(IMAGE_OPTIONAL_HEADER32结构体的最后一个成员）数组的个数。虽然结构体定义中明确指出了数组个数为IMAGE_NUMBEROF_DIRECTORY_ENTRIES(16)，但是PE装载器通过查看NumberOfRvaAndSizes值来识别数组大小，换言之，数组大小也可能不是16。

9 .DataDirectory
DataDirectory是由IMAGE_DATA_DIRECTORY结构体组成的数组，数组的每项都有被定义的值。 其中最重要的是 EXPORT/IMPORT/RESOURCE、TLSDirection。特别需要注意的是IMPORT与EXPORT Directory（导出表与导入表）

节区头是由IMAGE_SECTION_HEADER结构体组成的数组，每个结构体对应一个节区。

节区头中定义了各节区属性。看节区头之前先思考一下：前面提到过，PE文件中的code（代码）、data（数据入、resource（资源）等按照属性分类存储在不同节区，设计PE文件格式的工程师们之所以这样做，一定有着某些好处。

如可以保证程序的安全性。若把code与data放在一个节区中相互纠缠（实际上完全可以这样做）很容易引发安全问题，即使忽略过程的烦琐。
假如向字符串data写数据时，由于某个原因导致溢出（输人超过缓冲区大小时），那么其下的code（指令）就会被覆盖，应用程序就会崩溃。因此，PE文件格式的设计者们决定把具有相似属性的数据统一保存在一个被称为“节区”的地方，然后需要把各节区属性记录在节区头中（节区属性中有文件/内存的起始位置、大小、访问权限等）。

VirtualAddress与PointerToRawData不带有任何值，分别由（定义在IMAGE_OPTIONAL_HEADER32中的)SectionAlignment与FileAlignment确定。

VirtualSize与SizeOfRawData一般具有不同的值，即磁盘文件中节区的大小与加载到内存中的节区大小是不同的。

Name成员不像C语言中的字符串一样以NULL结束，并且没有“必须使用ASCI值”的限制。PE规范未明确规定节区的Name，所以可以向其中放人任何值，甚至可以填充NULL值。所以节区的Name仅供参考，不能保证其百分之百地被用作某种信息（数据节区的名称也可叫做.code)。

理解了节区头后，下面继续讲解有关PE文件从磁盘到内存映射的内容。
PE文件加载到内存时，每个节区都要能准确完成内存地址与文件偏移间的映射。这种映射一般称为RVA to RAW
方法如下。
(1)查找RVA所在节区。
(2)使用简单的公式计算文件偏移（RAW)。
根据IMAGE_SECTION_HEADER结构体，换算公式如下：

首先查看RVA所在的节区
RVA 5000处于第一个节区.text（假设imageBase为 01000000）
使用公式计算

13314处于第三个节区 .rsrc
公式计算

ABA8处于第二给节区 .data

IAT（Import Address Table，导人地址表)。IAT保存的内容与Windows操作系统的核心进程、内存、DLL结构等有关。
换句话说，只要理解了IAT，就掌握了Windows操作系统的根基。简言之，IAT是一种表格，用来记录程序正在使用哪些库中的哪些函数。

16位的DOS时代不存在DLL这一概念，只有“库”（Library)一说。比如在C语言中使用 printf() 函数时，编译器会先从C库中读取相应函数的二进制代码，然后插人（包含到）应用程序。也就是说，可执行文件中包含着 printf 函数的二进制代码。WindowsOS支持多任务，若仍采用这种包含库的方式，会非常没有效率。Windows操作系统使用了数量庞大的库函数（进程、内存、窗口、消息等）来支持32位的Windows环境。同时运行多个程序时，若仍像以前一样每个程序运行时都包含相同的库，将造成严重的内存浪费（当然磁盘空间的浪费也不容小觑）。因此，WindowsOS设计者们根据需要引入了DLL这一概念，DLL描述如下。

加载DLL的两种方式

使用OD打开 notepad.exe，然后查看IAT,比如我们要查看程序如何调用位于 kernel32.dll 中 CreateFileW() 函数
在 所有模块间的引用中找到对应的函数

调用 CreateFileW() 函数时并非是直接调用，而是通过获取 01001104 地址处的值来实现的（所有API都采用这种方式）

地址 01001104 是 notepad.exe 中 .text 节区的内存区域（更确切说是IAT内存区域）。此处的值是 756833E0，而地址 756833E0 即是加载到进程内存中的 CreateFileW() 函数（位于 Kernel32.dll 库中）的地址。

IMAGE_IMPORT_DESCRIPTOR结构体中记录着PE文件要导人哪些库文件。

执行一个普通程序时往往需要导人多个库，导人多少库就存在多少个 IMAGE_IMPORT_DESCRIPTOR 结构体，这些结构体形成了数组，且结构体数组最后以NULL结构体结束。IMAGE_IMPORT_DESCRIPTOR 中的重要成员如表所示（拥有全部RVA值)。

首先明白 IMAGE_IMPORT_DESCRIPTOR 结构体数组存在于PE文件的PE体中，但是查找起位置的信息在PE头中。但查找其位置的信息在PE头中
IMAGE_OPTIONAL_HEADER32.DataDirectory[1].VirtualAddress 的值即是 IMAGE_IMPORT_DESCRIPTOR 结构体数组的起始地址(RVA值)。
IMAGE_IMPORT_DESCRIPTOR 结构体数组也被称为 IMPORT Directory Table（只有了解上述全部称谓，与他人交流时才能没有障碍）

IMAGE_OPTIONAL_HEADER32.DataDirectory[1].VirtualAddress 结构体的值如图，（第一个4字节为虚拟地址，第二个4字节为Size成员）

整理一下 IMAGE_OPTIONAL_HEADER32.DataDirectory[1].VirtualAddress 结构体数组的信息

这里我们可以计算一下 RVA＝7604 的文件偏移 RAW
图中可以知道，.text 节区的VA是 0400h SIZE是 7800H

根据公式进行计算

转到6a04处，这些都是 IMAGE_IMPORT_DESCRIPTOR 结构体数组，图中就是结构体数组的第一个元素

以 IMAGE_IMPORT_DESCRIPTOR 结构体数组的第一个结构为例，看一下其结构体的成员

RVA：7A7A 即为 RAW: 6E7A
文件偏移 6E7A 最初的2个字节值（000F）为Ordinal，是库中函数的固有编号。Ordinal的后面为函数名称字符串 PageSetupDlgW（同C语言一样，字符串末尾以 TerminatingNULL['\O'] 结束）。

如图，INT是 IMAGE_IMPORT_BY_NAME 结构体指针数组，数组的第一个元素指向函数的 Ordinal 值 000F 函数的名称为 PageSetupDlgW

IAT的RVA: 12C4 即为RAW：6C4
图中文件偏移 6C4~6EB 区域即为IAT数组区域，对应于 comdlg32.dIl 库。它与INT类似，由结构体指针数组组成，且以NULL结尾。IAT的第一个元素值被硬编码为76324906，该值无实际意义，notepad.exe文件加载到内存时准确的地址值会取代该值。

notepad.exe 的 ImageBase 的值为 01000000。comdlg32.dll.PageSetupDlgW 函数的IAT地址为 010012C4，其值为 75B46730，它是API准确的起始地址值。

进入 75B46730 地址中。可以看到这里就是 comdlg32.dll 的 PageSetupDlgW 函数的起始位置。

Windows操作系统中，“库”是为了方便其他程序调用而集中包含相关函数的文件（DLL/SYS)。Win32API是最具代表性的库，其中的 kernel32.dll 文件被称为最核心的库文件。
EAT是一种核心机制，它使不同的应用程序可以调用库文件中提供的函数。也就是说，只有通过EAT才能准确求得从相应库中导出函数的起始地址。与前面讲解的IAT一样，PE文件内的特定结构体（IMAGEEXPORT_DIRECTORY）保存着导出信息，且PE文件中仅有一个用来说明库EAT的IMAGE_EXPORT_DIRECTORY结构体。

可以在PE文件的PE头中查找到 IMAGE_EXPORT_DIRECTORY 结构体的位置。IMAGE_OPTIONAL_HEADER32.DataDirectory[O].VirtualAddress 值即是 IMAGE_EXPORT_DIRECTORY 结构体数组的起始地址（也是RVA的值）。

图中就是 kernel32.dll 文件的 IMAGE_OPTIONAL_HEADER32.DataDirectory[0]（第一个4字节为VirtualAddress，第二个4字节为Size成员

下表为 kernel32.dll 文件的 DataDirectory 数组 -Export

RVA为262C 则 文件偏移就是 1A2C

IMAGE_EXPORT_DIRECTORY 是一个 结构体。它是 PE（Portable Executable）文件格式中用于描述导出表（Export Table）的数据结构。每个 PE 文件（如 DLL 或 EXE）的导出表通常只有一个 IMAGE_EXPORT_DIRECTORY 结构体实例。

下面是其中的一些重要成员

从库中获得函数地址的API为 GetProcAddress() 函数。该API引用EAT来获取指定API的地址。GetProcAddress() API拥有函数名称，下面讲解它如何获取函数地址。理解了这一过程，就等于征服了EAT。

下面进行从 kernel32.dll 文件的EAT中查找 AddAtomW 函数。上面我们计算出 kernel32.dll 中 IMAGE_EXPORT_DIRECTORY 结构体的RAW为 1A2C。利用010查看，我们直接跳到对应的位置

上图就是 IMAGE_EXPORT_DIRECTORY 结构体对应的区域，如下是此结构体各个成员的属性

看表得到 AddressOfNames 的成员值为 RVA=3538 计算出 RAW=2938。使用010查看对应的地址

此处为4字节RVA组成的数组。数组的元素个数为 NumberOfNames = 3B9 个。逐一跟随所有的RVA值即可发现函数名称字符串。

要查找的函数名称字符串为“AddAtomW”，只要在上图中找到RVA数组第三个元素的值 （RVA:4BB3-RAW:3FB3） 即可。

进人相应地址就会看到“AddAtomW”字符串，如图所示。此时“AddAtomW”函数名即是上图数组的第三个元素，数组索引为2。

下面查找“AddAtomW”函数的Ordinal值。AddressOfNameOrdinals 成员的值为 RVA:441C→RAW：381C。（ordinal数组中的各元素大小为2个字节）。

将 6.2.2. 查找指定函数名称 中求得的 index值(2) 应用到 6.2.3. Ordinal 数组 中的Ordinal数组即可求得 Ordinal(2)

最后查找 AddAtomW 的实际函数地址。AddressOfFunctions 成员的值为 RVA:2654一RAW：1A54
这部分即为4字节函数地址RVA数组，它就是 Export 函数的地址。

为了获取“AddAtomW”函数的地址，将求得的Ordinal用作数组的索引I，得到 RVA=000326D9

OD查看 kernel32.dll 的 ImageBase = 7c800000

则 AddAtomW 函数的实际地址 VA 为 7c800000+326D9 = 7c8326d9
然后OD验证一下

这里就是要找的 AddAtomW 函数。以上就是在DLL文件中查找 Export 函数地址的方法。与使用 GetProcAddress() API获取指定函数地址的方法一致

IAT/EAT相关内容是运行时压缩器（Run-timePacker、反调试、DLL注人、API钩取等多种中高级逆向主题的基础知识。
希望各位多训练使用010Editor、铅笔、纸张逐一计算IAT/EAT的地址，再找到文件/内存中的实际地址。虽然要掌握这些内容并不容易，但是由于其在代码逆向分析中占有重要地位，所以只有掌握它们，才能学到高级逆向技术。

顾名思义，PE规范只是一个建议性质的书面标准，查看各结构体内部会发现，其实有许多成员并未被使用。事实上，只要文件符合PE规范就是PE文件，利用这一点可以制作出一些脱离常识的PE文件。
PatchedPE指的就是这样的PE文件，这些PE文件仍然符合PE规范，但附带的PE头非常具有创意（准确地说，PE头纠缠放置到各处）。代码逆向分析中，PatchedPE涉及的内容宽泛而有深度，详细讲解须另立主题。
这里只介绍一点，但是足以颠覆前面对PE头的常规理解（但仍未违反PE规范）。

在下列网站制作一个名为“tiny pe”的最小PE文件。
http://blogs.securiteam.com/index.php/archives/675 （已经过期了）
它是正常的PE文件，大小只有411个字节。其IMAGE_NT_HEADERS结构体大小只有248个字节，从这一点来看，的确非常小。其他人也不断加人挑战，现在已经出现了304个字节的PE文件。有人访问上面网站后受到了刺激，制作了一个非常极端、非常荒唐的PE文件，在下列网址中可以看到。

http://www.phreedom.org/solar/code/tinype/ （过期了）
进人网站后可以下载一个97字节的PE文件，它可以在WindowsXP中正常运行。并且网站记录了PE头与tinype的制作过程，认真阅读这些内容会有很大帮助（需要具备一点汇编语言的知识）。希望各位全部下载并逐一分析，技术水平必有显著提高。

这里给一些参考项目