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 文件结构。
2. 预备知识
首先是一些关于输入表和 RVA/VA 的简介。
输入表的相对虚拟地址(RVA)储存在 PE 文件头部的相应目录入口(它的偏移量为[ PE 文件头偏移量+80h ])。由于是虚拟偏移量,所以它和文件输入表中的偏移量(VA)是不匹配的(除非文件纯粹是刚刚从内存中 Dump 出来的)。于是我们首先要做的事情是,找到 PE 文件的输入表,将 RVA 转换为相应的 VA。为此,我们可以采用不同的办法:你可以自行编制软件来分析块(Sections)目录并计算 VA,但最简单的办法是使用专门为此设计的应用程序接口(API)。这个 API 包括在 IMAGEHLP.DLL(Win9X 和 NT 系统都使用的一个库)中,名为 ImageRvaToVa。下面是对它的描述(完整的内容详见 MSDN 库):
|
就这么简单。你只需要将 PE 文件映射入内存,然后调用这个函数就能够得到输入表的正确 VA。
注意,下面我会忽略所有的 RVA/VA 注释,但是,当你对重建的 PE 文件进行读出或写入RVAs 操作时,不要忘记它们之间的转换。
3. 完整说明
这里是一个完整改变输入表的例子(这个 PE 文件的输入表已经被 PETite v2.1 压缩过,并且是直接从内存中 Dump 出来的):
我们用“`”表示 00,用“-”表示非字符串
|
正如你看到的,这个输入表被分成三个主要部分:
- C1E8h - C237h:IMAGE_IMPORT_DESCRIPTOR 结构部分,对应着每一个需要输入的动态链接库(DLL)。这部分以关键字 00 结束。
|
- 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。它允许你得到给定函数的地址。这里是它的描述:
|
所以,对于每一个被破坏的 IAT,在 GetProcAddress 返回我们寻找的函数地址之前,只需要分析包含在输入表第三部分的所有函数名。
- hModule 参数是 DLL 模块的句柄(也就是说,模块映象在内存中的基址),我们可以通过 GetModuleHandleA API 得到:
|
(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 被正常调入内存后才能够这样做。对于其他情况,你需要将它们调入,或者你需要仔细研究它们的输出表才能找到正确的函数地址。 http://www.hacker.cn/News/xtaq/2007-2/12/0721208422615678_3.shtml