深入剖析Win32可移植可执行文件格式资源-CSDN文库

共2个文件

pdf：2个

需积分: 10 112 浏览量 2010-05-10 11:24:03 上传评论收藏 416KB RAR 举报

资源推荐

资源详情

资源评论

收起资源包目录

深入剖析Win32可移植可执行文件格式.rar （2个子文件）

An In-Depth Look into the Win32 Portable Executable File Format-part 1.pdf 238KB

An In-Depth Look into the Win32 Portable Executable File Format-part 2.pdf 240KB

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

第二部分

作者：Matt Pietrek

上个月在本文的第一部分中，我首先对可移植可执行文件进行了全面的介绍。我讲了 PE 文

件的历史和组成 PE 文件头的数据结构，还讲了节表。PE 文件头和节表告诉你在可执行文件中都

包含什么类型的代码和数据，以及在哪里能找到它们。

本月我要讲一下常见的节。最后讲一下我的最新的经过彻底改进的PEDUMP程序，它可以在

2002 年 2 月的专栏中

下载。如果你不熟悉PE文件的基本概念，应该首先读一下本文的第一部分。

上个月我讲了节是怎样的一个逻辑上属于一起的代码或数据块。例如可执行文件的所有导入

信息都在一个节中。现在让我们来看一下在可执行文件和 OBJ 文件中经常遇到的一些节。除非特

别说明，否则下表中的节名都来自 Microsoft 的工具。

名称描述

.text 默认的代码节。

.data 默认的可读/可写数据节。全局变量通常在这个节中。

.rdata 默认的只读数据节。字符串常量和 C++/COM 虚表就放在这个节中。

.idata 导入表。实际上，链接器经常把.idata 节合并到其它节中（或者是明确指定的，或者是通

过链接器的默认行为）。默认情况下，链接器仅在创建发行版的程序时才把.idata 节合并

到其它节中。

.edata 导出表。当创建要导出函数或数据的可执行文件时，链接器会创建一个.EXP 文件。这个.EXP

文件包含一个.edata 节，这个节被添加到最后的可执行文件中。与.idata 节一样，.edata

节也经常被合并到.text 节或.rdata 节中。

.rsrc 资源节。这个节是只读的。它不应该被命名为其它名称，也不应该被合并到其它节中。

.bss 未初始化的数据节。在最新的链接器创建的可执行文件中很少见到。链接器扩展可执行文件

的.data 节的 VirtualSize 域以便容纳未初始化的数据。

.crt 添加到可执行文件中的数据，用来支持C++运行时库（CRT）。一个比较好的例子就是用于调

用静态C++对象的构造函数和析构函数的指针。要获取更详细的信息，可以参考

2001 年 1 月

的Under The Hood专栏。

.tls 这个节中的数据用来支持使用__declspec(thread)语法创建的线程局部存储变量。它包括数

据的初始值，以及运行时需要的附加变量。

.reloc 可执行文件中的基址重定位节。通常 DLL 需要基址重定位信息而 EXE 并不需要。在创建发行

版的程序时，链接器并不为 EXE 文件生成基址重定位信息。可以使用/FIXED 链接器选项移

除基址重定位信息。

.sdata 通过全局指针（Global Pointer）相对寻址的“短（Short）”可读/可写数据。用于 IA-64

和其它使用全局指针寄存器的平台上。IA-64 平台上正常大小的全局变量在这个节中。

.srdata 通过全局指针相对寻址的“短（Short）”只读数据。用于 IA-64 和其它使用全局指针寄存

器的平台上。

.pdata 异常表。它包含一个 IMAGE_RUNTIME_FUNCTION_ENTRY 结构数组，这个结构与平台体系结构

相关。数据目录中索引为 IMAGE_DIRECTORY_ENTRY_EXCEPTION 的项指向它。用于使用基于表

的异常处理的平台，例如 IA-64。惟一不使用基于表的异常处理的平台是 x86（它使用的是

名称描述

基于堆栈的异常处理）。

.debug$S OBJ 文件中的 Codeview 格式的调试符号（Symbol）信息。这是一列可变长度的 CodeView 格

式的调试符号记录。

.debug$T OBJ 文件中的 Codeview 格式的调试类型（Type）记录。这是一列可变长度的 CodeView 格式

的调试类型记录。

.debug$P 可以在使用预编译头（Precompiled Headers）生成的 OBJ 文件中找到这个节。

.drectve 这个节包含链接器指令，并且只存在于 OBJ 文件中。这些指令是传递到链接器命令行的 ASCII

码字符串，例如：-defaultlib:LIBC。指令之间用空格分开。

.didat 延迟加载导入数据。可以在非发行版本的可执行文件中找到。在发行版本中，延迟加载数据

被合并到其它节中。

导出表

当一个 EXE 或 DLL 导出函数或变量时，其它 EXE 或 DLL 就可以使用这些导出的函数或变量。

为了简单起见，我把导出的函数和导出的变量统称为“符号”。当导出一些符号时，最起码导出

符号的地址需要能够以一种已定义好的方式被获取。每个导出的符号都有一个与之关联的序数，

它可以用来查找这个符号。同时，几乎总有一个 ASCII 码格式的字符串名称与这个导出的符号关

联。一般来说，导出的符号名与源文件中的符号名是一样的，尽管它们可以被修改的不一样。

通常，当可执行文件导入符号时，它使用的是符号的名称而不是它的序号。但是当通过名

称导入时，系统仅使用这个名称去查找所需符号对应的导出序数，然后根据这个序数值去获取相

应的地址。如果先使用的是序数值的话查找过程会快一点。通过名称导出和导入只是为了让程序

员使用方便罢了。

在.DEF 文件中的 Exports 节中使用 ORDINAL 关键字可以告诉链接器创建一个导入库，这个

导入库强制函数只能通过序数导入而不能通过名称导入。

我首先介绍 IMAGE_EXPORT_DIRECTORY 结构，如下表所示：

大小域描述

DWORD Characteristics 导出标志。当前未定义任何值。

DWORD TimeDateStamp 导出数据的创建时间。这个域的定义与

IMAGE_NT_HEADERS.FileHeader.TimeDateStamp 相同（从 GMT 时间 1970

年 1 月 1 日 00:00 以来的总秒数)。

WORD MajorVersion 导出数据的主版本号。未用，设置为 0。

WORD MinorVersion 导出数据的次版本号。未用，设置为 0。

DWORD Name 与导出符号相关的 DLL 的名称 ASCII 字符串的 RVA（例如

KERNEL32.DLL）。

DWORD Base 这个域包含了这个可执行文件的导出符号所使用的序数值的起始值。

通常情况下这个值为 1，但并不总是这样。当通过序数查找导出符号时，

将序数值减去这个域的值就得到了这个导出符号在导出地址表

（Export Address Table ，EAT）中的索引。

大小域描述

DWORD NumberOfFunctions EAT 中的元素数。注意 EAT 中的某些元素可能为 0，这表明没有

代码/数据使用那个序数值导出。

DWORD NumberOfNames 导出名称表（Export Names Table，ENT）中的元素数。这个域的值总

是小于或等于 NumberOfFunctions 域的值。当某些符号仅使用序数导

出时，它就小于那个域的值。如果导出序数之间有间隔，它同样也小

于那个域的值。这个域的值也是导出序数表的大小（见下文）。

DWORD AddressOfFunctions EAT 的 RVA。EAT 中的每个元素都是一个 RVA。其中每个非 0 的 RVA 都

对应一个导出符号。

DWORD AddressOfNames ENT 的 RVA。ENT 中的每个元素都是一个 ASCII 码字符串的 RVA。其中

的每个 ASCII 码字符串都对应一个由名称导出的符号。这些字符串是

按一定顺序排列的。这就使得加载器在查找导出符号时可以进行二进

制搜索。名称字符串的排序是按二进制（与 C++运行时库函数 strcmp

类似），而不是与位置相关的字母表顺序。

DWORD AddressOfNameOrdinals 导出序号表的 RVA。这个表是一个 WORD 类型的数组。它将 ENT 中的索

引映射到导出地址表中相应的元素上。

导出目录（Export Directory）指向三个数组和一个 ASCII 码字符串表。其中只有导出地

址表是必需的，它是一个由指向导出函数的指针组成的数组。导出序数是这个数组的索引（见下

图）。

让我们通过例子来看一下导出表的工作原理。下图显示了 KERNEL32.DLL 导出表的部分内容：

exports table:

Name: KERNEL32.dll

Characteristics: 00000000

TimeDateStamp: 3B7DDFD8 -> Fri Aug 17 23:24:08 2001

Version: 0.00

Ordinal base: 00000001

# of functions: 000003A0

# of Names: 000003A0

Entry Pt Ordn Name

00012ADA 1 ActivateActCtx

000082C2 2 AddAtomA

•••remainder of exports omitted

假设你调用 GetProcAddress 来获取 KERNEL32 中的 AddAtomA 这个 API 的地址。这时系统开

始查找 KERNEL32 的 IMAGE_EXPORT_DIRECTORY 结构。它从那里获取了导出名称表的起始地址，知

道了在这个数组中有 0x3A0 个元素，它通过二进制搜索来查找字符串“AddAtomA”。

假设加载器发现 AddAtomA 是这个数组中的第二个元素。然后它从导出序数表（Export

Ordinal Table）中读取相应的第二个值。这个值就是 AddAtomA 的导出序数。将这个导出序数作

为 EAT 的索引（加上 Base 域的值），它最终获取 AddAtomA 的相对虚拟地址（RVA）是 0x82C2。

将此值与 KERNEL32 的加载地址相加就得到了 AddAtomA 的实际地址。

导出转发

导出表一个特别聪明的地方是它能将一个导出函数转发（Forwarding）到其它 DLL。例如

在 Windows NT®、Windows® 2000 和 Windows XP 中，KERNEL32 中的 HeapAlloc 函数被转发到了

NTDLL 导出的 RtlAllocHeap 函数上。转发是在链接时通过.DEF 文件中的 EXPORTS 节中的一种特

殊语法形式来实现的。对于 HeapAlloc 这个例子，KERNEL32 的.DEF 文件一定包含下面的内容：

EXPORTS

•••

HeapAlloc = NTDLL.RtlAllocHeap

怎样才能区别转发的函数与正常导出的函数呢？这需要一些技巧。通常 EAT 中包含的是导

出符号的 RVA。但是如果这个 RVA 位于导出表中（通过相应的 DataDirectory 中的 VirtualAddress

域和 Size 域进行判断），那么它就是转发的。

当转发一个符号时，它的 RVA 很明显不能是当前模块中的代码或数据的地址。实际上，它

的 RVA 指向一个由 DLL 和转发到的符号名称组成的字符串。在前面的例子中，这个字符串就是

NTDLL.RtlAllocHeap。

导入表

与导出函数或变量相反的就是导入它们。为了与前面保持一致，我仍然使用“符号”这个

术语来指代导入的函数和变量。

导入数据被保存在 IMAGE_IMPORT_DESCRIPTOR 结构中。对应着导入表的数据目录项就指向

由这个结构组成的数组。每个 IMAGE_IMPORT_DESCRIPTOR 结构都与一个导入的可执行文件对应。

这个数组的最后一个元素的所有域都被设置为 0。下表是这个结构的内容：

大小域描述

DWORD OriginalFirstThunk 这个域的命名太不恰当。它包含导入名称表的 RVA。导入名称表是一个

IMAGE_THUNK_DATA 结构数组。这个域被设置为 0 表示

IMAGE_IMPORT_DESCRIPTOR 结构数组的结尾。

大小域描述

DWORD TimeDateStamp 如果可执行文件并未绑定导入的 DLL，这个域的值为 0。当使用老的绑定

类型进行绑定（参考“绑定”一节）时，这个域包含日期/时间戳。当使

用新的绑定类型进行绑定时，这个域的值为-1。

DWORD ForwarderChain 这是首个转发的函数的索引。如果没有转发的函数，这个域被设置为-1。

它仅用于老的绑定类型，因为那种绑定类型不能很有效地处理转发的函

数。

DWORD Name 导入的 DLL 名称字符串（ASCII 码格式）的 RVA。

DWORD FirstThunk 导入地址表的 RVA。IAT 是一个 IMAGE_THUNK_DATA 结构数组。

每个 IMAGE_IMPORT_DESCRIPTOR 结构指向两个数组，这两个数组实际上是一样的。它们有

好几种叫法，但最常用的名称是导入地址表（Import Address Table，IAT）和导入名称表（Import

Name Talbe，INT）。下图显示的是可执行文件从 USER32.DLL 中导入一些 API 时的情况。

这两个数组的元素均为 IMAGE_THUNK_DATA 类型的结构，这个结构是一个与指针大小相同的

共用体（或者称为联合）。每个 IMAGE_THUNK_DATA 结构对应着从可执行文件中导入的一个函数。

这两个数组最后都以一个值为 0 的 IMAGE_THUNK_DATA 结构作为结尾。这个共用体（实际是一个

DWORD 值）可以有如下几种含义：

DWORD ForwarderString;// 转发函数字符串的 RVA（见上文）

DWORD Function; // 导入函数的内存地址

DWORD Ordinal; // 导入函数的序数

DWORD AddressOfData; // IMAGE_IMPORT_BY_NAME 和导入函数名称的 RVA（见下文）

IAT中的IMAGE_THUNK_DATA结构的用途可以分为两种。在可执行文件中，它们或者是导入函

数的序数，或者是一个IMAGE_IMPORT_BY_NAME结构的RVA。IMAGE_IMPORT_BY_NAME结构只是一个

WORD类型的值，它后面跟着导入函数的名称字符串。这个WORD类型的值是一个“提示（hint）”，

它提示加载器导入函数的序号可能是什么。当加载器加载可执行文件时，它用导入函数的实际地

址来覆盖IAT中的每个元素。这一点是理解下文的关键。我强烈建议你读一读本期杂志中Russell

Osterlund的文章——

揭开Windows加载器的神秘面纱，这篇文章详细讲述了Windows加载器的行

为。

在可执行文件被加载之前，是否存在一种方法能够区分 IMAGE_THUNK_DATA 结构中到底包含

的是导入函数的序数呢，还是 IMAGE_IMPORT_BY_NAME 结构的 RVA 呢？答案在 IMAGE_THUNK_DATA

评论收藏

内容反馈

danxuezx

粉丝: 273
资源: 82

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

探索PE文件内幕 —— Win32可移植可执行文件格式之旅

PortEx:Java库，用于分析可移植的可执行文件，特别侧重于恶意软件分析和PE格式不正确的鲁棒性

Win32可执行文件格式探讨及软件汉化 (2006年)

Microsoft可移植可执行文件和通用目标文件格式文件规范_V8.1

Microsoft 可移植可执行文件和通用目标文件格式文件规范

Microsoft 可移植可执行文件和通用目标文件格式文件规范8.0

(翻译可移植的可执行文件格式全接触(附注释).doc

win32 程序移植到linux上

深入剖析ASP.NET组件设计-黄忠成著-pdg格式

记事本源码java-pecoff4j:PE/COFF4J是一个用于可移植可执行文件的Java工程库，Windows使用的格式

pecoff4j-maven:pecoff4j 是一个用于可移植可执行文件的 Java 工程库，Windows 使用的格式

将Cocos2dx从win32移植到android平台 不用cygwin

esp32Lvgl移植文件

《Microsoft 可移植可执行文件和通》及tls方面的资料

OpenSSH的Win32移植Win32-OpenSSH.zip

PE详解(windows 可移植的执行体)

cocos2d-x win32项目移植到Android平台

PE文件格式剖析——解剖PE格式文件

Apache APR可移植运行库 Win32

cocos2d-x的win32工程移植到Android

软件移植，从win32到x64

PE文件格式详解.pdf

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

GD32替换STM32注意事项.pdf

最新资源

将Cocos2dx从win32移植到android平台不用cygwin

Qt 5实现串口调试助手（源工程文件、0积分下载）