pe文件格式

PE文件格式详解（一）――基础知识

什么是PE文件格式：

我们知道所有文件都是一些连续（当然实际存储在磁盘上的时候不一定是连续的）的数据组织起来的，不同类型的文件肯定组织形式也各不相同；PE文件格式便是一种文件组织形式，它是32位Wind ow系统中的可执行文件EXE以及动态连接库文件DLL的组织形式。为什么我们双击一个EXE文件之后它就会被Window运行，而我们双击一个DOC文件就会被Word打开并显示其中的内容；这说明文件中肯定除了存在那些文件的主体内容（比如EXE文件中的代码，数据等，DOC文件中的文件内容等）之外还存在其他一些重要的信息。这些信息是给文件的使用者看的，比如说EXE文件的使用者就是Window，而DOC文件的使用者就是Word。Window可以根据这些信息知道把文件加载到地址空间的那个位置，知道从哪个地址开始执行；加载到内存后如何修正一些指令中的地址等等。那么PE文件中的这些重要信息都是由谁加入的呢？是由编译器和连接器完成的，针对不同的编译器和连接器通常会提供不同的选项让我们在编译和

联结生成PE文件的时候对其中的那些Window需要的信息进行设定；当然也可以按照默认的方式编译连接生成Window中默认的信息。例如：WindowNT默认的程序加载基址是0x40000；你可以在用VC连接生成EXE文件的时候使用选项更改这个地址值。在不同的操作系统中可执行文件的格式是不同的，比如在Linux上就有一种流行的ELF格式；当然它是由在Linux上的编译器和连接器生成的，

所以编译器、连接器是针对不同的CPU架构和不同的操作系统而涉及出来的。在嵌入式领域中我们经常提到交叉编译器一词，它的作用就是在一种平台下编译出能在另一个平台下运行的程序；例如，我们可以使用交叉编译器在跑Linux的X86机器上编译出能在Arm上运行的程序。

程序是如何运行起来的：

一个程序从编写出来到运行一共需要那些工具，他们都对程序作了些什么呢？里面都涉及哪些知识需要学习呢？先说工具：编辑器－》编译器－》连接器－》加载器；首先我们使用编辑器编辑源文件；然后使用编译器编译程目标文件OBJ，这里面涉及到编译原理的知识；连接器把OBJ文件和其他一些库文件和资源文件连接起来生成EXE文件，这里面涉及到不同的连接器的知识，连接器根据OS的需要生成EXE文件保存着磁盘上；当我们运行EXE文件的时候有W indow的加载器负责把EXE文件加载到线性地址空间，加载的时候便是根据上一节中说到的PE文件格式中的哪些重要信息。然后生成一个进程，如果进程中涉及到多个线程还要生成一个主线程；此后进程便开始运行；这里面涉及的东西很多，包括：PE文件格式的内容；内存管理（CPU内存管理的硬件环境以及在此基础上的OS内存管理方式）；模块，进程，线程的知识；只有把这些都弄清楚之后才能比较清楚的了解这整个过程。下面就让我们先来学习PE文件格式吧。

PE文件的总体结构：

下图便是PE文件的一个总体结构：注意，图2是在图1的基础上进一步细化了，不过图2的顺序是从下向上代表文件的从头到尾的顺序。

DOS MZ Header

DOS stub

PE header

Section table

Section 1

Section 2

Section ...

Section n

图一

图2

我们的EXE文件在磁盘上就是按照上面的格式顺序存储的，当运行的时候它就很容易被加载器加载到线性地址空间；但是在线性空间中和在磁盘上不同，在线性空间中各个部分不一定是占据连续的线性地址空间。下面对PE文件格式的介绍就按照上图中对从头到尾对每个部分进行介绍。好的，今天刚去医院回来有些累了，就先写到这儿吧。嗯，不行，还有几个重要而又基础的概念需要在这儿先澄清一下，否则后面就会出乱子了。

几个重要的基本概念：

1）节：PE文件的真正内容划分成块，称之为sections（节）。每节是一块拥有共同属性的数据，比如代码/数据、读/写等。我们可以把PE文件想象成一逻辑磁盘，PE header 是磁盘的boot扇区，而se ctions就是各种文件，每种文件自然就有不同属性如只读、系统、隐藏、文档等等。值得我们注意的是---- 节的划分是基于各组数据的共同属性: 而不是逻辑概念。重要的不是数据/代码是如何使用的，如果PE文件中的数据/代码拥有相同属性，它们就能被归入同一节中。不必关心节中类似于"data", "code"或其他的逻辑概念: 如果数据和代码拥有相同属性，它们就可以被归入同一个节中。（节名称仅仅是个区别不同节的符号而已，类似"data", "code"的命名只为了便于识别，惟有节的属性设置决定了节的特性和功能）如果某块数据想付为只读属性，就可以将该块数据放入置为只读的节中，当PE装载器映射节内容时，它会检查相关节属性并置对应内存块为指定属性。下面是常见的节名及作用：

节名作用

.arch 最初的构建信息(Alpha Architecture Informatio

n)

.bss 未经初始化的数据

.CRT C运行期只读数据

.data 已经初始化的数据

.debug 调试信息

.didata 延迟输入文件名表

.edata 导出文件名表

.idata 导入文件名表

.pdata 异常信息(Exception Information)

.rdata 只读的初始化数据

.reloc 重定位表信息

.rsrc 资源

.text .exe或.dll文件的可执行代码

.tls 线程的本地存储器

.xdata 异常处理表

注意：上面已经说过了“节的划分是基于各组数据的共同属性: 而不是逻辑概念。重要的不是数据/代码是如何使用的，如果PE文件中的数据/代码拥有相同属性，它们就能被归入同一节中”所以上面表中列出的节并不一定单独成节，也就是说即使存在上面表中的某一节，在节表（section table）(后面会讲到)中也不一定就有于之对应的项，因为它可能和别的具有共同属性的节共同组成了一节。比如 .idata 可以和 .text 合成一节而命名为 .text，而在节表中只有和 .text 对应的项。这也就是后面的optional header中数据目录（DataDirectory）存在的作用，因为很多有用的节被合并了，因此

加载器无法通过节表来定位它们，所以这就是数据目录（DataDirec tory）发挥作用的时候了（具体作用后面会讲到）。

２)虚拟地址：虚拟地址即程序中使用的地址，也就是从程序员的角度看到的地址，有时也叫逻辑地址；通常使用段地址：偏移量的形式表示，不过在32位系统中使用的是平坦（Flat）内存模式(1.它的数据段和代码段是32位的，所以能访问4G的内存。2.在“平坦内存模式”，cs、ds、es的值不需你操心，也不必知道它们的值是多少，它们的值是相等的),所以我们可以不用管段地址，只考虑32位的偏移量即可，认为32位的偏移量就是虚拟地址,这样一来程序员就可以认为他是在一个段中写程序，这个段的大小是２^32 = 4G的容量，当然这部分地址空间是程序和OS共享的，程序员可以利用的大约有2G（具体可以参考Win98和WinNT的内存布局）；所以我们平时在写程序申请内存的时候实际上申请的就是这2G的线性地基空间，由于所有的4G线性地址空间都被OS作为资源来管理（这4G的线性地址空间是通过页表来表现出来的，OS分配线性地址空间給进程也就是分配相应的页表給进程），所以我们无论用什么方式使用内存最终都是转换为OS为我们分配线性地址空间，至于分配的线性地址空间又如何被映射为真正的物理内存完全是有OS负责的（更详细资料参见“Windows 内存管理”），程序员不必操心。

３)相对虚拟地址：「相对虚拟地址（Relative Virtual Address，R VA）」即相对于上面的基地址的偏移量。PE 文件中的许多字段内容

都是以RVA 表示，一个RVA 是某一资料项的offset（偏移）值-- 从文件被映像进来的起点（即基地址）算起。举个例子，我们说Win dows加载器把一个PE 文件映像到虚拟地址空间的0x400000 处，如果此image 有一个表格开始于0x401464，那么这个表格的RVA 就是0x1464：虚拟地址0x401464 - 基地址0x400000 = RVA 0x1464只要把RVA 加上基地址，RVA 就可以被转换为一个有用的指针。在PE文件中大多数地址多是RVA 而 RVA只有当PE文件被PE装载器装入内存后才有意义。如果我们直接将文件映射到内存而不是通过PE装载器载入，那么我们就不能直接使用那些RVA。必须先将那些RVA转换成文件偏移量，RVAToOffset函数就起到这个作用。

４)基地址：「基地址（base address）」是一个重要概念，用来描述被映像到内存中的EXE 或DLL 的起始地址。为了方便，Windows NT 和Windows 95 都以模块的基地址做为模块的instance handle （HINSTANCE,实例句柄）。Windows95加载器把一个PE 文件映像到虚拟地址空间的0x400000 处;而WindowNT加载器把一个PE 文件映像到虚拟地址空间的0x10000 处。

５)文件偏移量：文件中的地址与内存中表示不同，它是用偏移量(F ile offset)来表示的，文件中的第一个字节的偏移量是0,后面的字节依次递增。在SoftICE和W32Dasm下显示的地址值是内存线性地址，或称之为虚拟地址（Virual Address，VA）。而十六进制工具里，如：Hiew、Hex Workshop等显示的地址就是文件地址，称之为偏移量（F

ile offset) 或物理地址(RAW offset，注意这个物理地址不是内存寻址中说到的物理地址 )。

６)模块：「模块（module）」一词表示一个EXE 或DLL 被加载内存后的程序代码、数据和资源（就是被加载到内存后的EXE或DLL整体，包括代码、数据和资源，而不是说代码、数据、资源分别都是模块）。除了程序代码和数据是你的程序直接使用的之外，模块还内含一些支持性数据，Windows 用它来决定程序代码和数据放在内存的什么地方，在Win32，这些信息保留在PE头部（即图1中的PE header，实际上它是一个IMAGE_NT_HEADERS 结构）中。

７)逻辑地址：见“虚拟地址”

８)线性地址：线性地址是由虚拟地址（逻辑地址）转换来的，转换需要CPU和OS共同合作来完成；里面涉及到全局描述符表GDT和局部描述符表LDT；不过由于32位的Window系统采用flat内存模式，所以我们可以认为虚拟地址就是线性地址，即我们可以认为逻辑地址中的32位偏移量就是线性地址。

９)物理地址：即最终发往地址总线上的地址，它对应着实际的物理内存，在32位的Window存储管理中它是通过页表由线性地址转换出来的。

１０)实际地址：即“物理地址”。

其中前面的６个概念是学习PE文件格式需要知道的，后面的几个主要在内存管理里面提到，在这里为了便于区别一起列了出来。

PE文件格式详解（二）――PE格式总览

上一节我们已经了解了PE文件格式的作用和其总体结构，从这节开始我们就开始按照上一节中的总体结构从上到下来解析PE文件各个部分的具体结构和作用，当然我不会对每个部分的每一个字段都详细描述它的作用，因为讲解PE文件格式的资料很多，讲解的都很详细，所以我在这里只是按照程序执行的线索和基本原理把那些最重要的字段讲解一下，为了让我们对PE文件格式有个比较清楚的宏观认识，在具体讲解每一部分之前先让我们大概了解一下各部分的作用。

１．DOS MZ header 和 DOS Stub：

如果在DOS下执行PE格式文件就会执行后面的DOS Stub，显示字符串"This program cannot run in DOS mode"，如果在Window 下执行PE格式文件，PE加载器就会根据DOS MZ header中的最后一个域 e_lfanew跳过DOS Stub直接转到PE Header , DOS MZ heade r 和 DOS Stub的贡献仅此而已。

２. PE Header:

当加载器跳到PE Header后，根据里面的各个域首先检查这是不是有效的PE文件格式，能否在当前的CPU架构下运行，优先加载基址是多少，一共有几个节（section），这是一个EXE文件还是DLL 文件等总体信息，有了这些总体信息之后加载器就会跳到下面的Sec tion table。

３．Section table：

有了上面从PE Header获得的总体信息后，加载器并不能准确的加载文件，因为要准确的加载文件，加载器还需要一些关于每一节的更具体的信息，比如：每一节在磁盘文件上的起始位置、大小，应该被加载的线性地址空间的哪一部分，这一节是代码还是数据，读写属性如何等等。所有这些信息都保存在Section table里面，Section table是一个结构数组，数组里面的每一个结构对应PE文件中的一个节。PE加载器就会遍历这个结构数组把PE文件的每一节准确的加载到线性地址空间。(这里还要注意两点：一是PE加载器把PE文件的每一节加载到线性地址空间并不是说把磁盘上的文件调入物理内存；而只是为它分配线性地址空间，分配线性地址空间意味着申请本进程需要的页表，并把相应的信息添入页表中。线性地址空间也可以看作是一种资源，它是通过页表来体现的，当一个页表被添入相应的信息被占用之后那么这个页表对应的那块线性地址空间也就被分配出去了。需要注意的另一点是PE加载器对每一节采用文件映射的方式把相应的磁盘文件映射到内存，而不是把整个PE文件采用文件映

射的方法把磁盘文件映射到内存。更具体的解释我会在“Windows 内存管理”中提到。)

４．Sections:

PE文件最后的部分就是各个节了，比如.text , .data , .idat a等等，各种节的作用后面会有一个简要介绍。

思考一下：既然加载器不一定把程序加载到PE头中指定的优先加载基址，那么如果在没有加载到PE头中指定的优先加载基址的情况下，指令中的地址是不是都要依次修改呢？首先我们要明确的一点是程序指令中的地址分两大类，其中一类是在编译过程就可以确定的，这类地址采用的是相对虚拟地址（RVA），所以即使程序没有被加载到希望的基址这些地址也无需修改。另一类地址是编译过程和连接过程都无法确定的，比如那些引用外部库的函数地址，因为外部库之后在被加载器加载后里面的函数地址才能确定下来，所以程序中的这类地址要在程序被加载后进行修改。那么编译器和连接器对这类无法确定的地址是如何处理的呢？加载器又是根据什么如何来对它们进行修改的呢？个人感觉PE文件格式学习中这一部分内容有些繁杂，所以希望大家读后面各节的时候最好时常思考一下这两个问题。从下一节开始我们将对PE文件的各个部分作更为详尽的讲解。重点部分会放在对上面两个问题的解决上。

PE文件格式详解（三）――DOS Header & PE Header

上一节中我们对PE文件的各个部分的作用有了一个总体的认识，从这节起我们会对PE文件的每个部分作更进一步的解释，当然别忘记了上一节中我提出的两个问题。

1.DOS MZ header 和 DOS Stub：

所有 PE文件(甚至32位的 DLLs) 必须以一个简单的 DOS MZ header 开始。我们通常对此结构没有太大兴趣。有了它，一旦程序在DOS下执行，DOS就能识别出这是有效的执行体，然后运行紧随 MZ header 之后的 DOS stub。DOS stub实际上是个有效的 EXE，在不支持 PE文件格式的操作系统中，它将简单显示一个错误提示，类似于字符串 "This program requires Windows" 或者程序员可根据自己的意图实现完整的 DOS代码。通常我们也不对 DOS stub 太感兴趣: 因为大多数情况下它是由汇编器/编译器自动生成。通常，它简单调用中断21h服务9来显示字符串"This program cannot ru n in DOS mode"。在Window95下运行32位程序的时候这个部分并不会被加载器映射的线性地址空间，当Win32 加载器把一个PE 文件映像到内存，内存映像文件（memory mapped file）的第一个字节对应到DOS Stub 的第一个字节。WINNT.H 为DOS stub 表头DOS MZ hea der定义了一个结构，第一个域 e_magic ，被称为魔术数字，它被用于表示一个MS-DOS兼容的文件类型，其作用类似于PE header中的Signature域，所有MS-DOS兼容的可执行文件都将这个值设为0x 5A4D，表示ASCII字符MZ。MS-DOS头部之所以有的时候被称为MZ头

部，就是这个缘故。还有许多其它的域对于MS-DOS操作系统来说都有用，但是对于Windows NT来说，这个结构中只有一个有用的域——最后一个域 e_lfanew ，PE头部就是由它定位的。循此我们将非常容易找到PE头部，它是一个相对偏移值（或说是RVA），指向真正的PE头部(PE header)。为了获得指针，你必须为RVA 加上imag e 的基地址：

pNTHeader = dosHeader + dosHeader->e_lfanew;

有了这个指向PE Header的指针我们就可以取得很多有用的信息了，既然我们研究的是PE文件格式，因此PE Header才是我们研究的重点。总之，DOS MZ header和 DOS Stub之间的关系相当于PE heade r和 EXE或者DLL之间的关系。

2.PE Header：

PE header 是PE相关结构 IMAGE_NT_HEADERS 的简称，其中包含了许多PE装载器用到的重要域。当我们更加深入研究PE文件格式后，将对这些重要域耳目能详。执行体在支持PE文件结构的操作系统中执行时，PE装载器将从 DOS MZ header 中找到 PE header 的起始偏移量。因而跳过了 DOS stub 直接定位到真正的文件头 P E header。PE头部整个是个IMAGE_NT_HEADERS 结构，定义于WINNT. H。这个结构正是Windows 95 的module database（“模块”的概念在第一节中说过了，操作系统就是利用这个结构感知“模块”的存在、

获得“模块”的信息等；这个结构我会在以后的“模块”学习当中提及）。每一个被载入的EXE 或DLL 都以一个IMAGE_NT_HEADERS 结构表现出来。此结构有一个DWORD 和两个子结构：

DWORD Signature;

IMAGE_FILE_HEADER FileHeader;

IMAGE_OPTIONAL_HEADER OptionalHeader;

（１）对于PE格式的文件Signature 字段内容应该是ASCII 的P E\0\0。

（２） IMAGE_FILE_HEADER FileHeader：

Field name Meanings

Machine 该文件运行所要求的CPU。对于Intel平台，该值是IMAGE_FILE_MACHINE_I386 (14Ch)。我们尝试了LUE

VELSMEYER的pe.txt声明的14Dh和14Eh，但Windo

ws不能正确执行。看起来，除了禁止程序执行之外，

本域对我们来说用处不大。

NumberOfSect ions 文件的节数目。如果我们要在文件中增加或删除一个节，就需要修改这个值。

TimeDateStam

p

文件创建日期和时间。我们不感兴趣。

PointerToSym

bolTable

用于调试。

NumberOfSymb

ols

用于调试。

SizeOfOption alHeader 指示紧随本结构之后的 OptionalHeader 结构大小，必须为有效值。

Characterist

ics

关于文件信息的标记，比如文件是exe还是dll。

IMAGE_FILE_HEADER结构比较简单，也比较容易理解，在此不做过多的解释；简言之，只有三个域对我们有一些用: Machine, NumberOfSections 和Characteristics。通常不会改变Machine 和Characteristics 的值，但如果要遍历节表就得使用NumberOfSecti ons。

（３）比较复杂也更有趣的是第三个东东即：IMAGE_OPTIONAL _HEADER，现在我们学习IMAGE_NT_HEADERS 中的最后成员o ptional header 结构，它包含了PE文件的逻辑分布信息。该结构共有31个域，一些是很关键，另一些不太常用。这里只介绍那些真正有用的域。

Field Meanings

AddressOfEnt PE装载器准备运行的PE文件的第一个指令的RVA。

ryPoint 若您要改变整个执行的流程，可以将该值指定到新的RVA，这样新RVA处的指令首先被执行。ImageBase PE文件的优先装载地址。比如，如果该值是400000 h，PE装载器将尝试把文件装到虚拟地址空间的400

000h处。字眼"优先"表示若该地址区域已被其他模

块占用，那PE装载器会选用其他空闲地址。

SectionAlign ment 内存中节对齐的粒度。例如，如果该值是4096 (100 0h)，那么每节的起始地址必须是4096的倍数。若第一节从401000h开始且大小是10个字节，则下一节必定从402000h开始，即使401000h和402000h之间还有很多空间没被使用。

FileAlignmen t 文件中节对齐的粒度。例如，如果该值是(200h),，那么每节的起始地址必须是512的倍数。若第一节从文件偏移量200h开始且大小是10个字节，则下一节必定位于偏移量400h: 即使偏移量512和1024之间还有很多空间没被使用/定义。

MajorSubsyst emVersion MinorSubsyst emVersion win32子系统版本。若PE文件是专门为Win32设计的，该子系统版本必定是4.0否则对话框不会有3维立体感。

SizeOfImage 内存中整个PE映像体的尺寸。它是所有头和节经过节对齐处理后的大小。

SizeOfHeader s 所有头+节表的大小，也就等于文件尺寸减去文件中所有节的尺寸。可以以此值作为PE文件第一节的文件偏移量。（这里的描述是正确的，参考http://bb https://www.360docs.net/doc/012632246.html,/showthread.php?t=19072）

Subsystem NT用来识别PE文件属于哪个子系统。对于大多数W in32程序，只有两类值: Windows GUI 和 Windows

CUI (控制台)。

SizeOfStackR

eserve

线程初始堆栈的保留大小。

SizeOfStackC ommit 一开始即被提交（committed）给线程初始堆栈的内存数量。

SizeOfHeapRe

serve

保留给最初的process heap 的虚拟内存数量。

SizeOfHeapCo mmit 一开始即被提交（committed）给process heap 的内存数量。

DataDirector y IMAGE_DATA_DIRECTORY 结构数组。每个结构给出一个重要数据结构的RVA，比如引入地址表等。

上面表格里最难理解的也是很重要的一个域是最后一个，即：Da taDirectory；它是一个结构数组，它一共包含１６个元素即共含１６个结构；每一个结构对应于一个section（注意这里的section是按照第一节中按作用进行划分的section逻辑节，不是最终生成的P

E文件中包含的节）,结构中的两个域分别描述了该section的 RVA 和 SIZE; 这样一来加载器就能够通过这个数组迅速在image 中找到特定的section，后面讲到的导入表，引出表都要用到这个数组中相应的元素，到时候还会有进一步的解释。

PE文件格式详解（四）――Section Table（节表）

到本节为止，我们已经学了许多关于 DOS header 和 PE head er 的知识。接下来就该轮到 section table（节表）了。节表其实就是紧挨着 PE header 的一结构数组，它的作用我们在前面已经说过了。该数组成员的数目由 file header (IMAGE_FILE_HEADER) 结构中 NumberOfSections 域的域值来决定。节表结构又命名为 IMAG E_SECTION_HEADER。我们把它的主要成员列表如下：

Field Meanings

Name1 事实上本域的名称是"name"，只是"name"已被MASM用作关键字，所以我们只能用"Name1"代替。这儿的节名长不超过

8字节。记住节名仅仅是个标记而已，我们选择任何名字

甚至空着也行，注意这里不用null结束。命名不是一个A

SCIIZ字符串，所以不用null结尾。

Virtual Address 本节的RVA（相对虚拟地址）。PE装载器将节映射至内存时会读取本值，因此如果域值是1000h，而PE文件装在地址400000h处，那么本节就被载到401000h。

SizeOfR awData 经过文件对齐处理后节尺寸，PE装载器提取本域值了解需映射入内存的节字节数。（译者注: 假设一个文件的文件对齐尺寸是0x200，如果前面的 VirtualSize域指示本节长度是0x388字节，则本域值为0x400，表示本节是0x40 0字节长）。

Pointer ToRawDa ta 这是节基于文件的偏移量，PE装载器通过本域值找到节数据在文件中的位置。

Charact eristic s 包含标记以指示节属性，比如节是否含有可执行代码、初始化数据、未初始数据，是否可写、可读等。

好的，现在PE文件的前半部分结构我们已经了解的差不多了，下面就让我们模拟一下加载器加载PE文件的过程吧：

加载器加载PE文件的主要步骤:

1.当PE文件被执行，PE装载器检查 DOS MZ header 里的 PE he

ader 偏移量。如果找到，则跳转到 PE header。

2.PE装载器检查 PE header 的有效性。如果有效，就跳转到PE

header的尾部。

3.紧跟 PE header 的是节表。PE装载器读取其中的节信息，并

采用文件映射方法将这些节映射到内存，同时付上节表里指定的节属性。