深入剖析Win32可移植可执行文件格式 1
深入理解Win32PE文件格式
深⼊理解Win32PE⽂件格式深⼊理解 Win32 PE ⽂件格式Matt Pietrek这篇⽂章假定你熟悉C++和Win32。
概述理解可移植可执⾏⽂件格式（PE）可以更好地了解操作系统。
如果你知道DLL和EXE中都有些什么东西，那么你就是⼀个知识渊博的程序员。
这⼀系列⽂章的第⼀部分，讨论最近这⼏年PE格式所发⽣的变化。
这次更新后，作者讨论了PE格式如何适应于⽤.NET开发的应⽤程序，包括PE节，RVA，数据⽬录，以及导⼊函数。
附录中包含了相关的映像头结构以及它们的描述。
很早以前，我为微软系统期刊（现在叫做MSDN）写了⼀篇⽂章。
那篇⽂章“Peering Inside the PE: A Tour of the Win32 Portable Executable File Format”⽐我所期望的更受⼈欢迎。
直到现在，我仍然能收到使⽤那篇⽂章的⼈（甚⾄Microsoft⾥的⼈）的来信，那篇⽂章在MSDN中仍然能够找到。
不幸的是，那篇⽂章中存在⼀些问题。
这⼏年Win32发⽣了很⼤变化，那篇⽂章已经过时了。
从这个⽉开始我将在⼀篇分成两部分的⽂章中改正那些问题。
你也许会奇怪为什么应该关⼼可执⾏⽂件的格式呢。
答案还和过去⼀样：⼀个操作系统可执⾏⽂件的格式和数据结构揭⽰了这个底层操作系统的许多东西。
通过理解EXE和DLL中到底有些什么，你会成为⼀个知识更加渊博的程序员。
当然，你从微软的规范中也能学到我所告诉你的许多东西。
然⽽，微软的规范为了涵盖全⾯⽽牺牲了可读性。
⽽我这篇⽂章的焦点主要就是讨论 PE ⽂件的格式，填补了不适合出现在正式的说明规范中的部分。
另外，在这篇⽂章中也有⼀些在任何微软官⽅⽂档中都没有的好东西。
Bridging the Gap先给出⼏个⾃从1994年我写了那篇⽂章之后 PE ⽂件格式都发⽣了哪些变化的例⼦。
由于16位的 Windows 已经成为历史，所以没有必要再和 Win16 可执⾏⽂件格式进⾏⽐较了。
PE文件格式
WORD e_crlc; // Relocations
WORD e_cparhdr; // Size of header in paragraphs
么正确的开始地址是0x401560。如果可执行程序调入0x100000处，则开始地址为0x101560。
因为PE文件的每一个段不必按同样的边界对齐方式调入，因此RVA地址的计算变得比较复
杂。例如，在文件中每一个段往往按512个字节的方式对齐，而在内存中可能以4096字节的方
式对齐。这方面的介绍可见下面的“SectionAlignment”、“FileAlignment”。举个例子，
typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header
WORD e_magic; // Magic number
WORD e_cblp; // Bytes on last page of file
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;
三、文件头（File Header）
通过DOS头，你可以找到一个叫做IMAGE_FILE_HEADER的结构，如下；下面我分别介绍一
下。
typedef struct _IMAGE_FILE_HEADER {
中只有大约100个字节的代码，只输出一个诸如“this program needs windows NT ”之类的
信息。
你可以通过一个叫做IMAGE_DOS_HEADER的结构来识别一个合法的DOS头。这个结构的头两
个字节一定是“MZ”（#define IMAGE_DOS_SIGNATURE "MZ"）。怎么才能找到PE开始的标志呢
Windows可执行文件简述
Windows可执行文件简述操作系统中的文件是一种抽象的机制，提供了一种在磁盘上保存信息而且方便以后读取的方法。
在Windows操作系统中，一个用户可以最直接体会到的文件的形式就是以.exe、.dll等为扩展名的可执行文件。
伴随着Windows操作系统的不断进步，其可执行文件的格式也发生了巨大变化。
这期间主要有4个过程：DOS中出现的最简单的以.com为扩展名的可执行文件和以.exe为扩展名的MZ格式（MZ是MZ格式的主要作者Mark Zbikowski的名字的缩写）的可执行文件，Win 3.x下出现的NE（New Executable：分段可执行文件）格式的.exe和.dll文件，Win 3.x 和Win9x所专有的LE（Linear Executable：线性可执行文件，专用于VxD文件），Win9x和Win NT/2000/XP下的32位的可执行文件PE （Portable Executable：可移动的可执行文件）。
这里面com、MZ和NE 属于Win16，PE属于Win32，LE可以兼容Win16和Win32。
在一个操作系统中，可执行的代码最终被装入内存执行之前是以文件的方式存放在磁盘中的，也就是以可执行文件的方式。
下面是Microsoft Windows操作系统中的可执行文件的概述。
1．com格式Windows下最简单的可执行文件就是DOS下的以.com为扩展名的com 文件。
com文件是旧有的只有64kb内存的cp/m机器的产物。
com格式文件最大64K，com文件内含16位程序的二进制代码映像，没有重定位信息。
com文件包含程序的二进制代码的一个绝对映像。
也就是说，为了运行程序准确的处理器指令和内存中的数据，MS-DOS通过直接把该映像从文件拷贝到内存而加载com程序；它不作任何改变。
为加载一个com程序，MS-DOS首先试图分配内存，因为com程序必须位于一个64K的段中，所以com文件的大小不能超过65,024（64K 减去用于PSP的256字节和用于一个起始堆栈的至少256字节）。
Win32可执行文件格式探讨及软件汉化
要作 者 ＭａｋＺ ｉｏ ｋ 的名字 的缩 写） ｒ ｂｋ ｗｓ ｉ 的可执 行 文件 ； Ｗ ｉ ３ Ｘ 出现 的 ＮＥ ｎ ｗ ｅ ｅ ｕａ ｌ： ② ｎ ．下 （ ｅ ｘ ｃ ｔｂｅ
直接 体会 到 的文 件 形 式 就 是 以． ｘ ，ｄｌ 为 扩 ｅｅ． ｌ等
展名 的 可执行 文件 。 本 文首 先 对 所 有 基 于 Ｗｉ ２系 统 （ Ｗ ｉ ｎ３ 如 ｎ ９ ， ｎ ＮＴ， ｎ ２ ） 可 移 植 、 执 行 文 件 ｘ Ｗｉ Ｗｉ ｘ 的 可 （ ｏｔｂｅｅ ｅｕａ ｌ，Ｐ 格式 做详 细介 绍 ； 后 ｐ ｒａ ｌ ｘ ｃ ｔｂｅ Ｅ） 然
主要 经历 了 ４个过 程 的变化 ： Ｄ ① ＯＳ中 出现 的是
最 简单 的 以． ｏ 为 扩 展 名 的 可 执 行 文 件 和 以 ｃｍ
．
法 。而其 可执行 文件 格式 在很多 方 面是这 个系统
的一 面镜 子 。在 Ｗ ｉｄ ｗ 操 作 系统 中 ， ｎｏ ｓ 用户 可 以
ｅｅ ｘ 为扩 展名 的 ＭＺ格 式 （ ＭＺ是 ＭＺ格 式 的 主
Ｖ ｏｌ ７ ＮＯ ｜１ ．３
第 １ 卷 第 ３ ７ 期
Ｗ ｉ ２可 执 行 文 件 格 式 探 讨 及 软 件 汉 化 ｎ３
宇文 静 波 刘 树 贤 ，
（ ．装 备 指 挥 技 术 学 院 装 备 指 挥 系 ， 京 １ １ １ ； ２ １ 北 ０４６ ．装 备 指 挥 技 术 学 院 研 究 生 管理 大 队 ， 京 １ １ １ ） 北 ０ ４ ６
维普 技 术 学 院 学 报
Ｊ ｕ ｎ ｌｏ ｈ ａ ｅ ｆＥ ｕｐ ｎ ｍｍａ ｄ ＆ Ｔｅ ｈ ｏｏ ｙ ｏ ｒ ａ ｆｔ ｅＡｃ ｄ ｍｙｏ ｑ ｉｍｅ ｔＣｏ ｎ ｃ ｎ ｌｇ
可执行文件分析
这里讨论的可执行文件分析不包括反汇编和逆向工程中涉及的内容，仅仅是一般管理员和调查人员分析的一般手法。
静态分析：
所谓的静态分析就是在不运行可执行文件的前提下对文件进行分析，收集信息的方法的统称。一般情况下用文本打开一个只执行文件，会出下一堆的乱码，但是可执行文件也有自己的格式，符合一定得规律，完全可以从windows可执行文件找到信息。
IMAGE_FILE_LINE_NUMS_STRIPPED
0x0004
COFF line numbers have been removed. This flag is deprecated and should be zero.
IMAGE_FILE_LOCAL_SYMS_STRIPPED
0x0008
每个数据目录结构由一个相对虚地址（RVA）和有关数据长度两项数据构成，并且遵循严格的顺序排列。上图中PEview给出了每个结构在PE文件中的偏移地址（如0x100）、有关数据加载的相对虚地址（如0x2FC0），以及每个结构体所代表的含义。
提示：
在可执行文件被加载到内存中时，一般不能使用硬件编码的地址，而要使用其中定义的相对虚地址（RVA）这是因为可执行文件不可能在每个系统中加载到同样的内存地址。RVA用来指定独立于文件的内存加载地址，也就是内存中文件加载地址的相对偏移地址。计算RVA的公式如下：
IMAGE_NT_HEADERS结构在文件中的偏移量应该是0xB8（也就是十进制的184）。它包括一个签名和IMAGE_FILE _HEADER及IMAGE_OPTIONAL_HEADER两个结构.PE签名很简单就是字母PE再加上两个0（是个DWORD，共4B，可以表示为PE\00\00）。
接下来IMAGE_FILE_HEADER结构，紧接在PE签名之后，包含20B。这个结构中有几个值对调查取证时很有用处的。
LCC-Win32介绍C语言编译器
LCC-Win32介绍LCC-Win32原来是一个免费的WIN32编译器，包含一个很好用的IDE，用起来很爽，但是最近的版本是要付费的了（40美圆）。
详情请见LCC-Win32官方网站。
它的免费版本可以在国内得到，到云风工作室看一下，你会有所收获。
简介其实所谓的简介这个部分的内容趋向取决于作者。
但是我所读过的一些指南都是由一个“简介”开始的，这部分的内容通常都是在重复读者会在下面看到的东西，但是也有的简介只是作者的一些想法。
仔细的想一下，其实这个介绍并不是一件简单的事情。
首先，如果你要是开门见山的直奔主题，这是不礼貌的，而且基于web的指南也不应该有超大个的简介，不应该让读者在这个东西上浪费时间和金钱。
看来我的废话也够多的了，让我们切入正题。
这个指南是单页的，建议你等浏览器下载完毕后保存一份拷贝来离线阅读。
编译器的安装编译器的安装简单极了，只要把您下载的文件运行一下就OK了，应该不会遇到什么问题。
但是注意安装的最后要编译库文件，可能要花点时间，要视你的机器速度而定。
Lcc-Win32的一些基本概念Lcc-Win32编译系统是由多个文件构成的。
它们的共同的任务是把文本格式的源代码编译位可以运行的二进制格式。
优良个重要的文件分别是编译器（lcc.exe）和连接器（lcclnk.exe）。
编译器是用来把你编写的文本翻译成处理器可以执行的格式的程序。
连接器用来转换编译器生成的二进制文件（通常叫做目标文件），并添加操作系统用来把程序调入内存并执行所需要的信息它可以把多个目标文件链接为一个单独的程可执行程序，这样就可以使你可以把一个程序的代码文档分割为几个模块，这个能力在你开发大型程序时是很重要的。
虽然这些听起来好像十分的简单，但是实际上并不是这个样子的。
编辑器和链接器需要你在命令行方式下键入你要建立的程序的所有信息，这将需要你记住大量的命令行参数和各种各样的开关，这时就需要IDE——集成开发环境(edit.exe）来提供方便了。
win32错误报告
win32错误报告在使用计算机的日常生活中，我们难免会遇到各种各样的问题和错误。
其中之一就是Win32错误，它常常会弹出一个错误报告窗口，让人困惑和烦恼。
在本文中，我们将深入探讨Win32错误的原因、常见类型和解决方法，帮助读者更好地理解和应对这一问题。
Win32错误是指一种特定的错误类型，通常与Windows操作系统相关。
它可能在程序运行时发生，也可能在安装软件或驱动程序时出现。
Win32错误报告中列出了错误代码和简短的描述，让用户对错误有初步的了解。
然而，对于大多数用户来说，代码和描述只是一堆晦涩的符号和名词，很难理解其含义。
因此，我们有必要深入了解Win32错误并寻找解决办法。
首先，让我们来看看Win32错误的几种常见类型。
最常见的类型是文件相关错误。
当您尝试打开、读取或写入文件时，可能会遇到错误代码2（文件未找到）或错误代码5（拒绝访问）。
这意味着您所指定的文件路径不正确或您没有足够的权限来访问该文件。
另一个常见类型是内存错误，其中错误代码常见为异常代码0xc0000005。
这可能是由于程序访问了未分配的内存，或者试图读取或写入受保护的内存区域。
此外，网络相关错误也是常见的Win32错误类型。
当您的计算机无法连接到互联网或无法访问特定的网络资源时，错误代码常见为12002或12007。
这通常由于网络设置错误、防火墙设置等引起。
这只是Win32错误的一小部分，每种类型都有特定的错误代码和描述。
那么，当我们遇到Win32错误时该怎么办呢？首先，我们应该尝试理解错误报告中的代码和描述。
虽然有时它们可能会使人感到困惑，但它们提供了一些有关错误的线索。
比如，错误代码2（文件未找到）意味着您需要检查文件路径是否正确，或者确保文件是否被删除或移动。
错误码5（拒绝访问）则提示您缺乏足够的权限来访问文件。
其次，我们可以尝试重启计算机。
有时，Win32错误可能只是一次临时问题，通过重新启动计算机，许多错误可能就会自行解决。
什么是Win32
什么是Win32Win32是指你现在所使用的操作系统是32位的windows环境．编辑本段Win32的重要意义从单进程单线程到多进程多线程是操作系统发展的一种必然趋势，当年的DOS系统属于单任务操作系统，最优秀的程序员也只能通过驻留内存的方式实现所谓的"多任务"，而如今的Win32操作系统却可以一边听音乐，一边编程，一边打印文档。
理解多线程及其同步、互斥等通信方式是理解现代操作系统的关键一环，当我们精通了Win32多线程程序设计后，理解和学习其它操作系统的多任务控制也非常容易。
许多程序员从来没有学习过嵌入式系统领域著名的操作系统VxWorks，但是立马就能在上面做开发，大概要归功于平时在Win32多线程上下的功夫。
因此，学习Win32多线程不仅对理解Win32本身有重要意义，而且对学习和领会其它操作系统也有触类旁通的作用。
编辑本段进程与线程先阐述一下进程和线程的概念和区别，这是一个许多大学老师也讲不清楚的问题。
概念进程（Process）是具有一定独立功能的程序关于某个数据集合上的一次运行活动，是系统进行资源分配和调度的一个独立单位。
程序只是一组指令的有序集合，它本身没有任何运行的含义，只是一个静态实体。
而进程则不同，它是程序在某个数据集上的执行，是一个动态实体。
它因创建而产生，因调度而运行，因等待资源或事件而被处于等待状态，因完成任务而被撤消，反映了一个程序在一定的数据集上运行的全部动态过程。
线程（Thread）是进程的一个实体，是CPU调度和分派的基本单位。
线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制。
二者关系线程和进程的关系是：线程是属于进程的，线程运行在进程空间内，同一进程所产生的线程共享同一内存空间，当进程退出时该进程所产生的线程都会被强制退出并清除。
线程可与属于同一进程的其它线程共享进程所拥有的全部资源，但是其本身基本上不拥有系统资源，只拥有一点在运行中必不可少的信息(如程序计数器、一组寄存器和栈)。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
深入剖析W in32 可移植可执行文件格式第一部分作者：Matt Pietrek很久以前，我开始为Microsoft Systems Journal（现在的MSDN® Magazine）写文章，其中有一篇名为“探索PE文件内幕——Win32 可移植可执行文件格式之旅”的文章很受欢迎，大大超出了我的意料。
直到现在，我还听说有人（甚至在Microsoft）仍然在使用那篇文章，它依旧被收录在MSDN Library中。
不幸的是，文章的最大问题是它们是静止的。
但是Win32®的世界在这些年已经发生了很大的变化，因此那篇文章已经严重过时了。
我要从本月开始用两部分系列的文章来补救这种情况。
你可能想知道为什么要关注可执行文件的格式。
答案永远是：操作系统的可执行文件格式和数据结构展现了操作系统内部许多信息。
通过理解E XE 和D LL 的内部情况，你会发现你已经变成你周围一个更优秀的程序员。
当然，通过阅读M icrosoft 的P ECOFF 规范你可以获得许多我将要告诉你的内容。
但是与大多数规范一样，它更注重完整性而不是可读性。
在本文中，我把精力集中于解释整个故事中最重要的部分，同时填补那些并不适合出现在官方规范中的怎么样（How）以及为什么（Why）的问题。
另外，在本文中我还会讲到一些非常有用的内容，它们并未出现在任何M icrosoft 官方文档中。
让我先举一些例子来说明自从1994 年我写那篇文章以来有关可执行文件方面都发生了哪些变化。
由于16 位W indows®已经成为历史，因此没有必要再与W in16 的N E（New Executable）格式相比较了。
另一个已经脱离人们视野的是Win32s®。
在Windows 3.1 上运行Win32 程序非常不稳定是最令人讨厌的事。
回到当时，Windows 95（当时代号为“Chicago”）甚至还未发行。
Windows NT®还是3.5 版。
Microsoft 链接器还未进行非常有效地优化。
值得一提的是当时已经在MIPS 和DEC Alpha 上实现了W indows NT。
自从那篇文章以来都出现了什么新内容呢？64 位Windows 引进了它自己的变种的PE 文件格式。
Windows CE 添加了许多的新型处理器。
诸如DLL 延迟加载、节合并以及绑定之类的优化已经铺天盖地。
有许多新东西要加入到这个故事中。
让我们不要忘了Microsoft® .NET。
该把它放在什么位置呢？对于操作系统来说，.NET 可执行文件只不过是普通的Win32 可执行文件。
但是.NET 运行时能够识别出这些可执行文件中的数据并把它作为元数据（metadata）和中间语言（Intermediate Language，IL），它们对.NET 来说非常重要。
在本文中，我要敲开.NET 元数据结构的大门，但把对它全部光彩的彻底挖掘留给下一篇文章。
如果Win32 世界中的所有这些加加减减还不足以成为我重新写那篇文章的理由的话，那么我只有列出原来那篇文章中的一些令我害怕的错误了。
例如我对线程局部存储（TLS）支持情况的描述是错误的。
同样，通篇我对日期/时间戳这个D WORD 的描述仅在太平洋时区才是精确的！另外，有许多内容在当时是正确的，但现在已经不正确了。
我说过.rdata 节并没有太大的作用。
今天，诚然是这样。
我也说过.idata 节是可读/可写的节，但现在却有许多试图拦截API的人发现它在很多情况下都是不正确的。
伴随着在这篇文章中完全更新P E 文件格式的故事，我也对用于显示P E 文件内容的P EDUMP 程序进行了彻底修改。
PEDUMP 现在可以在x86 和I A-64 平台上编译和运行，并且能够转储32 位和64 位P E 文件。
最重要的是，PEDUMP 的源代码可以从本文开头的链接处下载。
这样，你就有了一个用这里讲的概念和数据结构实际工作的例子。
PE 文件格式概览Microsoft 引进了P E 文件格式，更经常被称为P E 格式，作为最初的W in32 规范的一部分。
然而P E 文件源自V AX/VMS 上早期的通用目标文件格式（Common Object File Format，COFF）。
这是由于许多最初的W indows NT 开发团队的成员都来自数字设备公司（Digital Equipment Corporation，DEC）。
这些开发者很自然就使用现有的代码以便快速开始新的W indows NT 平台。
之所以选择术语“可移植可执行”是打算要在所有支持的CPU 上的所有版本的Windows 上使用相同的可执行文件格式。
从大的方面来说，这个目标已经实现，因为Windows NT 及其后继操作系统、Windows 95 及其后继操作系统以及W indows CE 都使用相同的可执行文件格式。
Microsoft 编译器生成的OBJ 文件也使用COFF 格式。
从COFF 格式的一些域使用的竟然是八进制编码你就能知道它是多么老。
COFF 格式的O BJ 文件中有许多数据结构和枚举类型与P E 文件相同，后面我会提到。
64 位W indows 需要做的只是修改P E 格式的少数几个域。
这种新的格式被称为P E32+。
它并没有增加任何新域，仅从P E 格式中删除了一个域。
其余的改变就是简单地把某些域从32 位扩展到64 位。
在大部分情况下，你都能写出同时适用于32 位和64 位P E 文件的代码。
Windows 头文件有这种魔力可以使这些区别对于大多数基于C++的代码都不可见。
EXE 文件与DLL 文件的区别完全是语义上的。
它们使用的是相同的PE 格式。
惟一的不同在于一个位，这个位用来指示文件应该作为EXE 还是DLL。
甚至DLL 文件的扩展名也完全也是人为的。
你可以给D LL 一个完全不同的扩展名，例如.OCX 控件和控制面板小程序（.CPL）都是D LL。
PE 文件一个非常好的地方就是它的数据结构在磁盘上与在内存中一样。
加载一个可执行文件到内存（例如通过调用LoadLibrary 函数）主要就是把PE 文件中的某个部分映射到地址空间中。
因此像IMAGE_NT_HEADERS（后面我会讲到）这样的数据结构在磁盘上和在内存中是一样的。
如果你知道如何在一个PE 文件中找到某些内容，你几乎可以确定当文件被加载进内存时可以找到同样的信息。
注意到PE 文件并不是作为单一的内存映射文件被映射进内存的这一点非常重要。
相反，Windows 加载器查看PE 文件并确定文件中的哪些部分需要被映射。
当映射进内存时，文件中的高偏移相对于内存中的高地址。
某项内容在磁盘文件中的偏移可能与它被加载进内存之后的偏移不同，但是将磁盘文件中的偏移转换成内存偏移需要的所有信息都存在（见下图）。
当PE 文件由Windows 加载器加载进内存时，它在内存中被称为模块（module）。
文件被映射到的内存的起始地址被称为HMODULE。
这是需要记住的一点：给你一个HMODULE，你就知道在那个地址处到底有什么样的数据结构，并且你可以根据PE 文件的知识找到内存中所有其它的数据结构。
这个强大的功能可以被用作其它用途，例如拦截A PI。
（说得再准确一点，在W indows CE上H MODULE 与加载地址并不相同，但那不是今天要讨论的内容。
）内存中的模块代表一个进程所需的可执行文件中的所有代码、数据和资源。
PE 文件中的其它部分可能会被读取，但并不被映射进内存（例如重定位节）。
一些部分可能根本就不被映射，例如放在文件末尾的调试信息。
PE 文件头中的一个域告诉系统将这个可执行文件映射进内存时需要占用多少内存。
不被映射的数据放在文件末尾，位于所有需要被映射的部分之后。
描述PE 文件（和COFF 文件）的关键位置是WINNT.H 文件。
在这个头文件中，你能找到几乎所有结构的定义、枚举类型以及使用PE 文件或它在内存中的等价结构所需的定义。
当然在其他地方有这方面的文档，例如MSDN 中有“Microsoft 可移植可执行文件和通用目标文件格式文件规范”（2001 年十月M SDN 的S pecifications 下）。
但是W INNT.H 确定了P E 文件最终的样子。
有许多工具可以用来查看PE文件。
Visual Studio附带的Dumpbin和Platform SDK附带的Depends就是其中的两个。
我特别喜欢Depends，它以一种非常简洁的方式查看文件的导入表和导出表。
另一个很好的PE文件查看工具是由Smidgeonsoft（）发行的PEBrowse Professional。
本文中包含的PEDUMP程序也是一个非常全面的工具，几乎能做 Dumpbin 所能做到的一切。
从A PI 的观点来看，M icrosoft 提供的读取和修改P E 文件的主要途径是I MAGEHLP.DLL 文件。
在开始看P E 文件的细节之前，先复习一下贯穿于整个P E 文件方面的几个基本概念是非常值得的。
在以下的部分中，我将讨论P E 文件的节（section）、相对虚拟地址（RVA）、数据目录（Data Directory）以及如何导入函数。
PE 文件的节PE 文件的节代表代码或某些类型的数据。
虽然代码只能是代码，但数据却有许多种不同类型。
除了可读/可写的程序数据（例如全局变量）外，节中其它类型的数据包括函数导入表和导出表、资源以及重定位信息等。
每个节都有它自己的一组内存属性，其中包括节中是否包含代码，是只读的还是可读/可写的以及节中的数据是否在所有使用这个可执行文件的进程中是共享的等等。
一般说来，一个节中的所有代码和数据在逻辑上是相关的。
通常一个PE 文件中至少有两个节，一个是代码节，另一个是数据节。
一般在PE 文件中至少还有一种其它类型的数据节。
我将在下个月本文的第二部分中具体描述各种节。
每个节都有一个惟一的名字。
它通常用来表示节的用途。
例如一个名为.rdata 的节表明它是一个只读数据节。
使用节名只是为了方便人们处理文件，它对操作系统来说无关紧要。
一个名为F OOBAR 的节可能实际上是一个代码节，就像.text 节一样。
Microsoft 通常在它们的节名前加一个圆点，但这并不是必须的。
多少年来，Borland 链接器使用的节名都是C ODE 和D ATA。
虽然编译器生成的节都有标准设置，但那并没有什么神奇的。
你可以创建和命名你自己的节，链接器很乐意把它们包含进可执行文件中。
在Visual C++中，你可以告诉编译器把代码或数据插入到你使用#pragma 语句命名的节中。
例如以下语句#pragma data_seg( "MY_DATA" )导致所有数据都被V isual C++放入一个称为M Y_DATA 的节中，而不是默认的.data 节。