现在我们已经了解了IAT的的工作原理，现在我们来一起学习手动修复IAT，一方面是深入了解运行过程一方面是为了避免遇到有些阻碍自动修复IAT的壳时不知所措。

首先我们用ESP定律找到加了UPX壳后的OEP，现在我们处于OEP处,原程序区段已经解密完毕,我们现在可以进行dump了。

前面已经提到过,有很多dump的工具,OD有一个款插件OllyDump的dump效果也不错，这里我们来使用另外一个工具PE TOOLS来进行dump。

PE TOOLS的界面是这样的，我们用PE-TOOLS定位到CRACKME UPX所在的进程。单击鼠标右键选择-Dump Full。、

这里,我们就dump完毕了,接下来我们来修复IAT,关闭PE TOOLS,将dump后的dumped.exe保存到CRACKME UPX所在的目录中。

我们知道没有修复IAT,是不能运行的,我们双击Dumped.exe看看会发生什么。

提示无效的win32程序,我们需要修复IAT,我们需要用到一个工具,名字叫做Import REConstructor,不要关闭OD,将让其断在OEP处,Import REConstructor需要用到它。

运行Import REConstructor,定位到CRACKME UPX所在的进程。

这里很多初学者可能会有疑问-如何定位IAT的起始位置和结束位置呢?我们知道当前该CRACKME UPX进程停在了OEP处,此时壳已经将导入表破坏了,我们知道IID项的第四个字段为动态库名称字符串的指针,第五个字段为其对应IAT项第一个元素的地址,这些已经被壳破坏了,我们需要通过其他方式来定位。

我们知道API函数的调用通常是通过间接跳转或者间接CALL来实现的。

即

JMP [XXXXXXX] or CALL [XXXXXX]

上一章我们已经介绍过了,这样是直接调用IAT中保存的API函数地址。我们来看看CRACKME UPX。

这里我们看到第二行的CALL指令,OD提示调用的是Kernel32.dll中的GetModuleHandleA,是个间接跳转,我们选中这一行,单击鼠标右键选择-Follow。

这里我们定位到获取IAT中函数地址的跳转表,这里就是该程序将要调用到的一些API函数,我们可以看到这些跳转指令的都是以机器码FF 25开头的,有些教程里面说直接搜索二进制FF 25就可以快速的定位该跳表。

其实,并不是所有的程序都通过这种间接跳转来调用API函数,所以直接搜索FF 25这种方法有时候会失败,而通过定位某个API函数的调用处,然后Follow到跳表是这种方式才是一直有效的。

这里我们看到JMP [403238]:

403238是IAT的其中一个元素,里面保存的是GetModuleHandleA这个API函数的入口地址,我们dump出来的程序的IAT部分跟这里是一样的,我们来看看IAT的起始位置和结束位置分别在哪儿。

其实,大家可以通过跳转表中最小的地址和最大的地址算出IAT的起始位置和结束位置,但是比较慢,比较好的做法是,直接将数据窗口往上滚动,我们知道IAT的每个元素中都保存了一个API函数的入口地址,比如这里的76861245,在数据窗口中显示的形式为45 12 86 76 (小端存储),我们将显示列数调整为两列,这样看起来更方便一些。

这里我们看到的就是整个IAT了,我们直接下拉到IAT的尾部,我们知道属于同一个动态库的API函数地址都是连续存放的,不同的动态库函数地址列表是用零隔开的。

有一些壳会将这部分全部填零,使得我们的IAT重建工作变得异常困难,这里由于原程序还需要调用这些API函数,所以该壳没有将这部分填零,我们现在来看看其中一个动态库的IAT项,如下:

这里显示了该DLL中的三个API函数,入口地址都是7C XXXXXX的形式,然后紧接着是一个零。

我们单击工具栏中的M按钮看看7C开头的地址是属于哪个DLL的。

我们可以看到这几个地址处于kernel32.dll的代码段范围内。

当然在你们的机器上kernel32.dll可能在别的地址处,但在我的机器上,这几个函数地址是属于kernel32.dll的。

属于kernel32.dll中的函数地址这里我用粉红色标注出来了,我们再来看看77DXXXXX这类地址是属于哪个DLL的。

这里我们可以看到77DXXXXX这类地址是属于user32.dll的,我也用粉红色标注出来了。

我们可以看到user32.dll的这些函数地址项上面是全零的,表示IAT的起始地址为403184,403184中存放的了IAT中的第一个元素。

这里我们用红线标注出来了,403184是IAT的起始地址。有些强壳可能会将IAT前后都填充上垃圾数据,让我们定位IAT的起始位置和结束位置更加困难。但是我们知道IAT中的数值都是属于某个动态库代码段范围内的,如果我们发现某数值不属于任何一个动态库的代码段的话,就说明该数值是垃圾数据。

现在我们知道了IAT开始于403184,我们现在来看一看IAT的结束位置在哪里。

后面我们会遇到有些壳会将IAT重定向到壳的例程中去,然后再跳转到API函数的入口处,这样的话,上面这样定位IAT的起始和结束位置的做法就行不通了。该如何应对这样情况,我们后面再来介绍。

这里我们可以看到IAT的最后一个元素的地址形式为76XXXXXX,我们来看看它是属于哪个DLL的。

这里我们可以看到其是属于COMDLG32.DLL的,后面全是零了,所以40328C是IAT的结束位置。

好了,现在我们知道了IAT的起始位置和结束位置。

begin:403184

end:40328c

 ===========================================================================================================

Import REConstructor重建IAT需要三项指标:

1)IAT的起始地址,这里是403184,减去映像基址400000就得到了3184(RVA:相对虚拟地址)。

2)IAT的大小，IAT的大小 = 40328C - 403184 = 108(十六进制)

3)OEP = 401000(虚拟地址)- 映像基址400000 = 1000(OEP的RVA)。

手动修复IAT