深入剖析Win32可移植可执行文件格式 1.docVIP

深入剖析 Win32 可移植可执行文件格式 第一部分 作者：Matt Pietrek 很久以前，我开始为Microsoft Systems Journal（现在的MSDN? Magazine）写文章，其中 有一篇名为“探索PE文件内幕——Win32 可移植可执行文件格式之旅”的文章很受欢迎，大大超 出了我的意料。直到现在，我还听说有人（甚至在Microsoft）仍然在使用那篇文章，它依旧被 收录在MSDN Library中。不幸的是，文章的最大问题是它们是静止的。但是Win32?的世界在这些 年已经发生了很大的变化，因此那篇文章已经严重过时了。我要从本月开始用两部分系列的文章 来补救这种情况。 你可能想知道为什么要关注可执行文件的格式。答案永远是：操作系统的可执行文件格式和 数据结构展现了操作系统内部许多信息。通过理解 EXE 和 DLL 的内部情况，你会发现你已经变成 你周围一个更优秀的程序员。 当然，通过阅读 Microsoft 的 PECOFF 规范你可以获得许多我将要告诉你的内容。但是与大 多数规范一样，它更注重完整性而不是可读性。在本文中，我把精力集中于解释整个故事中最重 要的部分，同时填补那些并不适合出现在官方规范中的怎么样（How）以及为什么（Why）的问题。 另外，在本文中我还会讲到一些非常有用的内容，它们并未出现在任何 Microsoft 官方文档中。 让我先举一些例子来说明自从 1994 年我写那篇文章以来有关可执行文件方面都发生了哪些 变化。由于 16 位 Windows?已经成为历史，因此没有必要再与 Win16 的 NE（New Executable）格 式相比较了。另一个已经脱离人们视野的是 Win32s?。在 Windows 3.1 上运行 Win32 程序非常不 稳定是最令人讨厌的事。 回到当时，Windows 95（当时代号为“Chicago”）甚至还未发行。Windows NT?还是 3.5 版。Microsoft 链接器还未进行非常有效地优化。值得一提的是当时已经在 MIPS 和 DEC Alpha 上实现了 Windows NT。 自从那篇文章以来都出现了什么新内容呢？64 位 Windows 引进了它自己的变种的 PE 文件格 式。Windows CE 添加了许多的新型处理器。诸如 DLL 延迟加载、节合并以及绑定之类的优化已 经铺天盖地。有许多新东西要加入到这个故事中。 让我们不要忘了 Microsoft? .NET。该把它放在什么位置呢？对于操作系统来说，.NET 可 执行文件只不过是普通的 Win32 可执行文件。但是.NET 运行时能够识别出这些可执行文件中的 数据并把它作为元数据（metadata）和中间语言（Intermediate Language，IL），它们对.NET 来说非常重要。在本文中，我要敲开.NET 元数据结构的大门，但把对它全部光彩的彻底挖掘留 给下一篇文章。 如果 Win32 世界中的所有这些加加减减还不足以成为我重新写那篇文章的理由的话，那么 我只有列出原来那篇文章中的一些令我害怕的错误了。例如我对线程局部存储（TLS）支持情况 的描述是错误的。同样，通篇我对日期/时间戳这个 DWORD 的描述仅在太平洋时区才是精确的！ 另外，有许多内容在当时是正确的，但现在已经不正确了。我说过.rdata 节并没有太大的 作用。今天，诚然是这样。我也说过.idata 节是可读/可写的节，但现在却有许多试图拦截 API 的人发现它在很多情况下都是不正确的。 伴随着在这篇文章中完全更新 PE 文件格式的故事，我也对用于显示 PE 文件内容的 PEDUMP 程序进行了彻底修改。PEDUMP 现在可以在 x86 和 IA-64 平台上编译和运行，并且能够转储 32 位 和 64 位 PE 文件。最重要的是，PEDUMP 的源代码可以从本文开头的链接处下载。这样，你就有 了一个用这里讲的概念和数据结构实际工作的例子。 PE 文件格式概览 Microsoft 引进了 PE 文件格式，更经常被称为 PE 格式，作为最初的 Win32 规范的一部分。 然而 PE 文件源自 VAX/VMS 上早期的通用目标文件格式（Common Object File Format，COFF）。 这是由于许多最初的 Windows NT 开发团队的成员都来自数字设备公司（Digital Equipment Corporation，DEC）。这些开发者很自然就使用现有的代码以便快速开始新的 Windows NT 平台。 之所以选择术语“可移植可执行”是打算要在所有支持的 CPU 上的所有版本的 Windows 上 使用相同的可执行文件格式。从大的方面来说，这个目标已经实现，因为 Windows NT