PE文件格式详解

作者：titilima/CSDN
摘要

　　Windows NT 3.1引入了一种名为PE文件格式的新可执行文件格式。PE文件格式的规范包含在了MSDN的CD中（Specs and Strategy, Specifications, Windows NT File Format Specifications），但是它非常之晦涩。

　　然而这一的文档并未提供足够的信息，所以开发者们无法很好地弄懂PE格式。本文旨在解决这一问题，它会对整个的PE文件格式作一个十分彻底的解释，另外，本文中还带有对所有必需结构的描述以及示范如何使用这些信息的源码示例。

　 　我为了获得PE文件中所包含的重要信息，编写了一个名为PEFILE.DLL的动态链接库，本文中所有出现的源码示例亦均摘自于此。这个DLL和它的源 代码都作为PEFile示例程序的一部分包含在了CD中（译注：示例程序请在MSDN中寻找），你可以在你自己的应用程序中使用这个DLL；同样，你亦可 以依你所愿地使用并构建它的源码。在本文末尾，你会找到PEFILE.DLL的函数导出列表和一个如何使用它们的说明。我觉得你会发现这些函数会让你从容 应付PE文件格式的。Windows操作系统家族最近增加的Windows NT为开发环境和应用程序本身带来了很大的改变，这之中一个最为重大的当属PE文件格式了。新的PE文件格式主要来自于UNIX操作系统所通用的COFF 规范，同时为了保证与旧版本MS-DOS及Windows操作系统的兼容，PE文件格式也保留了MS-DOS中那熟悉的MZ头部。

　　在本文之中，PE文件格式是以自顶而下的顺序解释的。在你从头开始研究文件内容的过程之中，本文会详细讨论PE文件的每一个组成部分。

　 　许多单独的文件成分定义都来自于Microsoft Win32 SDK开发包中的WINNT.H文件，在这个文件中你会发现用来描述文件头部和数据目录等各种成分的结构类型定义。但是，在WINNT.H中缺少对PE文 件结构足够的定义，在这种情况下，我定义了自己的结构来存取文件数据。你会在PEFILE.DLL工程的PEFILE.H中找到这些结构的定义，整套的 PEFILE.H开发文件包含在PEFile示例程序之中。

　　本文配套的示例程序除了PEFILE.DLL示例代码之外，还有一个单独 的Win32示例应用程序，名为EXEVIEW.EXE。创建这一示例目的有二：首先，我需要测试PEFILE.DLL的函数，并且某些情况要求我同时查 看多个文件；其次，很多解决PE文件格式的工作和直接观看数据有关。例如，要弄懂导入地址名称表是如何构成的，我就得同时查看.idata段头部、导入映 像数据目录、可选头部以及当前的.idata段实体，而EXEVIEW.EXE就是查看这些信息的最佳示例。

　　闲话少叙，让我们开始吧。

PE文件结构

　　PE文件格式被组织为一个线性的数据流，它由一个MS-DOS头部开始，接着是 一个是模式的程序残余以及一个PE文件标志，这之后紧接着PE文件头和可选头部。这些之后是所有的段头部，段头部之后跟随着所有的段实体。文件的结束处是 一些其它的区域，其中是一些混杂的信息，包括重分配信息、符号表信息、行号信息以及字串表数据。我将所有这些成分列于图1。

图1.PE文件映像结构

　　从MS-DOS文件头结构开始，我将按照PE文件格式各成分的出现顺序依次对其进行讨论，并且讨论的大部分是以示例代码为基础来示范如何获得文件的信息的。所有的源码均摘自PEFILE.DLL模块的PEFILE.C文件。

　　这些示例都利用了Windows NT最酷的特色之一——内存映射文件，这一特色允许用户使用一个简单的指针来存取文件中所包含的数据，因此所有的示例都使用了内存映射文件来存取PE文件中的数据。
　　注意：请查阅本文末尾关于如何使用PEFILE.DLL的那一段。
上一节我们已经了解了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_lfnew跳过DOS Stub直接转到PE Header , DOS MZ header 和 DOS Stub的贡献仅此而已。
２. PE Header:
当加载器跳到PE Header后，根据里面的各个域首先检查这是不是有效的PE文件格式，能否在当前的CPU架构下运行，优先加载基址是多少，一共有几个节（section），这是一个EXE文件还是DLL文件等总体信息，有了这些总体信息之后加载器就会跳到下面的Section table。
３．Section table：
有了上面从PE Header获得的总体信息后，加载器并不能准确的加载文件，因为要准确的加载文件，加载器还需要一些关于每一节的更具体的信息，比如：每一节在磁盘文件上的起始位置、大小，应该被加载的线性地址空间的哪一部分，这一节是代码还是数据，读写属性如何等等。所有这些信息都保存在Section table里面，Section table是一个结构数组，数组里面的每一个结构对应PE文件中的一个节。PE加载器就会遍历这个结构数组把PE文件的每一节准确的加载到线性地址空间。（这里还要注意两点：一是PE加载器把PE文 件的每一节加载到线性地址空间并不是说把磁盘上的文件调入物理内存；而只是为它分配线性地址空间，分配线性地址空间意味着申请本进程需要的页表，并把相应 的信息添入页表中。线性地址空间也可以看作是一种资源，它是通过页表来体现的，当一个页表被添入相应的信息被占用之后那么这个页表对应的那块线性地址空间 也就被分配出去了。需要注意的另一点是PE加载器对每一节采用文件映射的方式把相应的磁盘文件映射到内存，而不是把整个PE文件采用文件映射的方法把磁盘文件映射到内存。更具体的解释我会在“Windows 内存管理”中提到。）
４．Sections:
PE文件最后的部分就是各个节了，比如.text , .data , .idata等等，各种节的作用后面会有一个简要介绍。

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

PE可选头部　　PE可执行文件中接下来的224个字节组成了PE可选头部。虽然它的名字是“可选头部”，但是请确信：这个头部并非“可选”，而是“必需”的。

OPTHDROFFSET宏可以获得指向可选头部的指针：
PEFILE.H
#define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \
((PIMAGE_DOS_HEADER)a)->e_lfanew + \
SIZE_OF_NT_SIGNATURE + \
sizeof(IMAGE_FILE_HEADER)))
　　可选头部包含了很多关于可执行映像的重要信息，例如初始的堆栈大小、程序入口点的位置、首选基地址、操作系统版本、段对齐的信息等等。

IMAGE_OPTIONAL_HEADER结构如下：
WINNT.H
typedef struct _IMAGE_OPTIONAL_HEADER {
//
// 标准域
//
USHORT Magic;
UCHAR MajorLinkerVersion;
UCHAR MinorLinkerVersion;
ULONG SizeOfCode;
ULONG SizeOfInitializedData;
ULONG SizeOfUninitializedData;
ULONG AddressOfEntryPoint;
ULONG BaseOfCode;
ULONG BaseOfData;
//
// NT附加域
//
ULONG ImageBase;
ULONG SectionAlignment;
ULONG FileAlignment;
USHORT MajorOperatingSystemVersion;
USHORT MinorOperatingSystemVersion;
USHORT MajorImageVersion;
USHORT MinorImageVersion;
USHORT MajorSubsystemVersion;
USHORT MinorSubsystemVersion;
ULONG Reserved1;
ULONG SizeOfImage;
ULONG SizeOfHeaders;
ULONG CheckSum;
USHORT Subsystem;
USHORT DllCharacteristics;
ULONG SizeOfStackReserve;
ULONG SizeOfStackCommit;
ULONG SizeOfHeapReserve;
ULONG SizeOfHeapCommit;
ULONG LoaderFlags;
ULONG NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory [IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;

　　如你所见，这个结构中所列出的域实在是冗长得过分。为了不让你对所有这些域感到厌烦，我会仅仅讨论有用的——就是说，对于探究PE文件格式而言有用的。

　　标准域

　　首先，请注意这个结构被划分为“标准域”和“NT附加域”。所谓标准域，就是和UNIX可执行文件的COFF格式所公共的部分。虽然标准域保留了COFF中定义的名字，但是Windows NT仍然将它们用作了不同的目的——尽管换个名字更好一些。

　　·Magic。我不知道这个域是干什么的，对于示例程序EXEVIEW.EXE示例程序而言，这个值是0x010B或267（译注：0x010B为.EXE，0x0107为ROM映像，这个信息我是从eXeScope上得来的）。

　　·MajorLinkerVersion、MinorLinkerVersion。表示链接此映像的链接器版本。随Window NT build 438配套的Windows NT SDK包含的链接器版本是2.39（十六进制为2.27）。

　　·SizeOfCode。可执行代码尺寸。
　　·SizeOfInitializedData。已初始化的数据尺寸。
　　·SizeOfUninitializedData。未初始化的数据尺寸。
　 　·AddressOfEntryPoint。在标准域中，AddressOfEntryPoint域是对PE文件格式来说最为有趣的了。这个域表示应用 程序入口点的位置。并且，对于系统黑客来说，这个位置就是导入地址表（IAT）的末尾。以下的函数示范了如何从可选头部获得Windows NT可执行映像的入口点。

PEFILE.C
LPVOID WINAPI GetModuleEntryPoint(LPVOID lpFile)
{
PIMAGE_OPTIONAL_HEADER poh;
poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile);
if (poh != NULL)
return (LPVOID)poh->AddressOfEntryPoint;
else
return NULL;
}
　　·BaseOfCode。已载入映像的代码（“.text”段）的相对偏移量。
　　·BaseOfData。已载入映像的未初始化数据（“.bss”段）的相对偏移量。
----后面找不到了。