重建 PE 文件的输入表 TiTi

标题:重建 PE 文件的输入表

原著:TiTi/BLiZZARD

翻译:Sun Bird [CCG]

日期:2000年5月24日


1. 前言
=======

大家好 :) 我之所以写这篇短文,是由于我在 Dump 时发现,很多加压、加密软件都使得输入表(Import Table)不可用,所以 Dump 出的可执行文件必须要重建输入表。而在普通的讲授 Win32 汇编的站点上我没有找到这样的介绍,所以如果你对此感兴趣,那么这篇短文对你会有些帮助。

例如,为了让从内存中 Dump 出的经 PETite v2.1 压缩过的可执行文件正常运行,必须重建输入表。(对于 ASPack、PEPack、PESentry……也同样)这就是所有 Dump 软件都具备重建输入表功能的原因(例如 G-RoM/UCF 制作的 Phoenix Engine(ProcDump 内含),或者由 Virogen/PC 和我制作的 PE Rebuilder)。

鉴于这个问题十分特殊,而且比较复杂,所以我假定你已经了解了 PE 文件结构。(你需要阅读有关 PE 文件的文档)

2. 预备知识
===========

首先是一些关于输入表和 RVA/VA 的简介。

输入表的相对虚拟地址(RVA)储存在 PE 文件头部的相应目录入口(它的偏移量为[ PE 文件头偏移量+80h ])。由于是虚拟偏移量,所以它和文件输入表中的偏移量(VA)是不匹配的(除非文件纯粹是刚刚从内存中 Dump 出来的)。于是我们首先要做的事情是,找到 PE 文件的输入表,将 RVA 转换为相应的 VA。为此,我们可以采用不同的办法:你可以自行编制软件来分析块(Sections)目录并计算 VA,但最简单的办法是使用专门为此设计的应用程序接口(API)。这个 API 包括在 IMAGEHLP.DLL(Win9X 和 NT 系统都使用的一个库)中,名为 ImageRvaToVa。下面是对它的描述(完整的内容详见 MSDN 库):

# LPVOID ImageRvaToVa(
# IN PIMAGE_NT_HEADERS NtHeaders,
# IN LPVOID Base,
# IN DWORD Rva,
# IN OUT PIMAGE_SECTION_HEADER *LastRvaSection
#);
#
# 参数:
#
# NtHeaders
#
# 指示一个 IMAGE_NT_HEADERS 结构。通过调用 ImageNtHeader 函数可以获得这个结构。
#
# Base
#
# 指定通过调用 MapViewOfFile 函数映射入内存的一个映象的基址(Base Address)。
#
# Rva
#
# 指定相对虚拟地址的位置。
#
# LastRvaSection
#
# 指向一个指定的最终 RVA 块的 IMAGE_SECTION_HEADER 结构。这是一个可选参数。当被#指定时,它指向一个变量,该变量包含指定映象的最后块值,以便将 RVA 转换为 VA。

就这么简单。你只需要将 PE 文件映射入内存,然后调用这个函数就能够得到输入表的正确 VA。

注意,下面我会忽略所有的 RVA/VA 注释,但是,当你对重建的 PE 文件进行读出或写入RVAs 操作时,不要忘记它们之间的转换。

3. 完整说明
===========

这里是一个完整改变输入表的例子(这个 PE 文件的输入表已经被 PETite v2.1 压缩过,并且是直接从内存中 Dump 出来的):

我们用“`”表示 00,用“-”表示非字符串

0000C1E8h : 00 00 00 00 00 00 00 00 00 00 00 00 BA C2 00 00 ````````````----
0000C1F8h : 38 C2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ----````````````
0000C208h : C5 C2 00 00 44 C2 00 00 00 00 00 00 00 00 00 00 --------````````
0000C218h : 00 00 00 00 D2 C2 00 00 54 C2 00 00 00 00 00 00 ````--------````
0000C228h : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ````````````````
0000C238h : 7F 89 E7 77 4C BC E8 77 00 00 00 00 E6 9F F1 77 --------````----
0000C248h : 1A 38 F1 77 10 40 F1 77 00 00 00 00 4F 1E D8 77 --------````----
0000C258h : 00 00 00 00 00 00 4D 65 73 73 61 67 65 42 6F 78 ``````MessageBox
0000C268h : 41 00 00 00 77 73 70 72 69 6E 74 66 41 00 00 00 A```wsprintfA```
0000C278h : 45 78 69 74 50 72 6F 63 65 73 73 00 00 00 4C 6F ExitProcess```Lo
0000C288h : 61 64 4C 69 62 72 61 72 79 41 00 00 00 00 47 65 adLibraryA````Ge
0000C298h : 74 50 72 6F 63 41 64 64 72 65 73 73 00 00 00 00 tProcAddress````
0000C2A8h : 47 65 74 4F 70 65 6E 46 69 6C 65 4E 61 6D 65 41 GetOpenFileNameA
0000C2B8h : 00 00 55 53 45 52 33 32 2E 64 6C 6C 00 4B 45 52 ``USER32.dll`KER
0000C2C8h : 4E 45 4C 33 32 2E 64 6C 6C 00 63 6F 6D 64 6C 67 NEL32.dll`comdlg
0000C2D8h : 33 32 2E 64 6C 6C 00 00 00 00 00 00 00 00 00 00 32.dll``````````

正如你看到的,这个输入表被分成三个主要部分:

- C1E8h - C237h:IMAGE_IMPORT_DESCRIPTOR 结构部分,对应着每一个需要输入的动态链接库(DLL)。这部分以关键字 00 结束。

IMAGE_IMPORT_DESCRIPTOR struct
OriginalFirstThunk dd 0 ;原拆分 IAT 的 RVA
TimeDateStamp dd 0 ;没有使用
ForwarderChain dd 0 ;没有使用
Name dd 0 ;DLL 名字符串的 RVA
FirstThunk dd 0 ;IAT 部分的 RVA
IMAGE_IMPORT_DESCRIPTOR ends

- C238h - C25Bh:这部分双字(DWord) 称作“IAT”,由 IMAGE_IMPORT_DESCRIPTOR结构中的 FirstThunk 部分指明。这部分每一个 DWord 对应一个输入函数。

- C25Ch - C2DDh : 这里是输入函数和 DLL 文件的名称。问题是,这些是没有规定顺序的:有时候 DLL 文件在函数前面,有时候正好相反,另外一些时候它们混在一起。

输入表的简介
------------

OriginalFirstThunk 是 IAT 的一部分,它是 PE 文件引导时首先要搜索的。如果存在,PE文件的引导部分将使用它来纠正在 FirstThunk IAT 部分的问题。当调入内存后,FirstThunk的每一个 Dword (包含有函数名字符串的 RVA),将被 RVA 替换为函数的真实地址(当调用这些函数时,它们调入内存的位置将被执行)。所以,只要 OriginalFirstThunk 没有被改变,基本上这里不存在输入表的问题。

下面来看我们的问题
------------------

好了,经过简单描述后,下面来看我们的问题。如果你试图运行包含上面显示的输入表的可执行文件,它不会被调入,Windows 会显示一个错误信息。为什么?很简单,因为OriginalFirstThunk 被删除了。事实上,你应该注意到,在这个输入表的每一个IMAGE_IMPORT_DESCRIPTOR 结构,OriginalFirstThunk 的内容都是 00000000h。嗯,所以我们可以推测出,当我们运行这个可执行程序时,PE 文件的引导部分试图从 FirstThunk 部分获得输入函数的名字。但是,正象你注意到的,这部分根本没有包含函数名字符串的 RVA,但是函数地址的 RVA 在内存中。

我们需要怎么做
--------------

现在,为了让这个可执行文件运行,我们需要重建 FirstThunk 部分的内容,让它们指向我们在输入表第三部分看到的函数名字符串。这不是一项很困难的任务,但是,我们需要知道哪个IAT 对应哪个函数,而函数字符串和 FirstThunk 内容并不采用同样的存储方法。所以,对于每
一个 IAT,我们需要验证它对应的是哪个函数名(事实上,根据 IMAGE_IMPORT_
DESCRIPTOR.Name DWord 我们已经有了 DLL 名称,这些并没有被改变)。

如何验证每一个函数
------------------

正向我们上面所见到的,在内存中,每一个被破坏的 IAT 都有一个函数地址的 RVA。这些地址并没有被破坏,所以,我们只要重新找回指向错误 IAT 的函数地址,把它们指向函数名字符串。
为此,在 Kernel32.dll 中有一个非常有用的 API:GetProcAddress。它允许你得到给定函数的地址。这里是它的描述:

GetProcAddress(

HMODULE hModule, // DLL 模块的句柄
LPCSTR lpProcName // 函数名
);

所以,对于每一个被破坏的 IAT,在 GetProcAddress 返回我们寻找的函数地址之前,只需要分析包含在输入表第三部分的所有函数名。

- hModule 参数是 DLL 模块的句柄(也就是说,模块映象在内存中的基址),我们可以通过 GetModuleHandleA API 得到:

HMODULE GetModuleHandle(LPCTSTR lpModuleName // 返回模块名地址句柄);

(lpModuleName 只需要指向我们从 IMAGE_IMPORT_DESCRIPTOR.Name 部分得到的 DLL 文件名字符串)

- lpProcName 仅指向函数名字符串。

注意,有时候函数是按序号输入的。这些序号是在每个 [ 函数名偏移量-2 ] 处的单字(WORDS)。
所以,你在分析程序时需要检查函数是按名称还是按序号输入的。

使用上面输入表的实例
--------------------

针对上面输入表的例子,我将说明如何修复第一个输入 DLL 的第一个输入函数。

1. 我们来看第一个 IMAGE_IMPORT_DESCRIPTOR 结构部分(C1E8h),.Name 部分(C1E4h,指向C1BAh)指出了 DLL 名。我们看到,那是 USER32.dll。

2. 我们来看 .FirstThunk 部分,它们指向 IAT 部分;每个对应一个这个 DLL(user32.dll)的输入函数。在这里是 C1F8h,指向 C238h。所以,在 C238h,我们可以修复被破坏的 IATs。(你会注意到,这个 IAT 部分包含二个 DWords,所以,这个 DLL 有二个函数输入)

3. 我们得到了第一个被破坏的 IAT。它的值是 77E7897Fh。这是函数在内存中的地址。

4. 对每一个输入表第三部分中的函数,我们调用 GetProcAddress API。当该 API 返回 7E7897Fh时就意味着,我们到达了正确的函数。所以我们让被破坏的 IAT 指向正确函数名(在本例中为 'wsprintfA')。

5. 现在我们只需要将 IAT 指向:偏移量(函数名字符串)-2。为什么是 -2 ?因为有时候使用了函数序列。
所以在本例中,我们改变地址 C238h,让它指向 C26Ah(以代替 77E7897Fh)。

6. 就这样,这个函数被修复了,下面你只需要对所有的 IATs 重复这个过程就可以了。

后记
----

我描述的是一般的操作过程。当然只有在 DLLs 被正常调入内存后才能够这样做。对于其他情况,你需要将它们调入,或者你需要仔细研究它们的输出表才能找到正确的函数地址。

 

你可能感兴趣的:(Technology_PC)