使用OllyDbg从零开始Cracking 第三十四章手脱UPX修复IAT.docx

使用OllyDbg从零开始Cracking 第三十四章手脱UPX修复IAT.docx

《使用OllyDbg从零开始Cracking 第三十四章手脱UPX修复IAT.docx》由会员分享，可在线阅读，更多相关《使用OllyDbg从零开始Cracking 第三十四章手脱UPX修复IAT.docx（21页珍藏版）》请在冰点文库上搜索。

使用OllyDbg从零开始Cracking第三十四章手脱UPX修复IAT

第三十四章-手脱UPX,修复IAT

我们在上一章中给大家介绍了IT（导入表）,IAT（输入函数地址表）的相关概念以及原理。

有的人可能会认为,我们只是想修复IAT呀,并不需要知道IAT的具体原理以及它是如何被填充的吧?

不是有现成的IAT自动修复工具吗?

可以很明确的告诉大家,了解操作系统是如何填充IAT的过程非常有必要的。

因为很多壳会检测这些常用的IAT修复工具,致其不能正常运行,在这种情况下,我们就需要自己进行相应的手工修复。

本章我们还是用最简单的CRACKMEUPX作为例子,我们将对其进行脱壳以及修复IAT,让其能正常运行。

首先第一步我们来定位OEP,我们用OD加载CRACKMEUPX。

这里我们用ESP定律来定位OEP,现在我们停在了入口点处,单击F7键执行PUSHAD。

在ESP寄存器值上面单击鼠标右键选择-FollowinDump。

就可以在数据窗口中定位到刚刚PUSHAD指令保存到堆栈中的寄存器环境了,我们选中前4个字节,我们通过单击鼠标右键选择Breakpoint-Hardware,onaccess-Dword给这4个字节设置硬件访问断点。

运行起来,马上就断在了JMPOEP指令处。

我们直接按F7键单步到OEP处。

好了,现在我们处于OEP处,原程序区段已经解密完毕,我们现在可以进行dump了。

前面已经提到过,有很多dump的工具,OD有一个款插件OllyDump的dump效果也不错。

上一章中我们使用LordPE来进行dump的,这里我们来使用另外一个工具PETOOLS来进行dump。

我们用PE-TOOLS定位到CRACKMEUPX所在的进程。

这里这个crackme.exe就是,因为我忘了把那个重命名的CRACKMEUPX放到哪里去了,所以我又重新弄了一个新的,忘了改名字,直接命名为原来的名字crackme.exe了,当前这个crackme.exe进程停在了OEP处。

单击鼠标右键选择-DumpFull。

这里,我们就dump完毕了,接下来我们来修复IAT,关闭PETOOLS,将PETOOLS目录下的dumped.exe拷贝一份到CRACKMEUPX所在的目录中。

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

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

运行ImportREConstructor,定位到CRACKMEUPX所在的进程。

这里很多初学者可能会有疑问-如何定位IAT的起始位置和结束位置呢?

我们知道当前该CRACKMEUPX进程停在了OEP处,此时壳已经将导入表破坏了,我们知道IID项的第四个字段为动态库名称字符串的指针,第五个字段为其对应IAT项第一个元素的地址,这些已经被壳破坏了,我们需要通过其他方式来定位。

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

即

JMP[XXXXXXX]orCALL[XXXXXX]

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

我们来看看CRACKMEUPX。

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

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

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

这里我们看到JMP[403238]:

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

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

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

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

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

我们单击工具栏中的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

ImportREConstructor重建IAT需要三项指标:

1）IAT的起始地址,这里是403184,减去映像基址400000就得到了3184（RVA:

相对虚拟地址）。

2）IAT的大小

IAT的大小=40328C-403184=108（十六进制）

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

我们将这三条数据输入到ImportREConstructor中。

我们单击GetImports。

我们看到ImportREConstructor找到了IAT中的每项元素,并且valid显示的都是YES,表示这些项都是有效的,那么无效的是什么情况呢,有些壳会将这些值进行重定向,并不是直接调用API函数,就会导致ImportREConstructor定位出来的项都是无效的,好了现在这些项都是有效的,我们就可以进行dump了。

在dump之前我们先来看看User32.dll这个项中内容是什么,选中该项,单击左边的+号就可以展开。

好了,我们可以看到每个API函数名称字符串的指针都显示出来了,该程序调用的第一个API函数GetModuleHandleA这一项在哪里呢?

大家应该还记得,IAT的中的第一项值为403238,减去映像基址400000就等于3238,位于kernel32.dll中。

我们单击kernel32.dll这一项左边的+号。

可以看到3238对应的正好是GetModuleHandleA。

好了,现在我们就可以对之前dump出来的程序的IAT进行修复了,我们单击FixDump按钮。

选中之前dump出来的文件。

我们可以看到修复完毕了,修复过的文件被重命名为了dumped_.exe。

我们来看一看。

我们双击它,看看能不能正常运行。

我们可以看到还是提示无效的win32程序,嘿嘿,为什么呢?

别担心,通常修复了IAT以后,都会出现这种状况。

我们现在来打开PETOOLS。

我们选择菜单项中的RebuildPE（重建PE）,我们找到刚刚的dumped_.exe,重建之,运行,发现可以正常运行了,嘿嘿。

大家将这个程序拿到其它机器上运行也是没有问题的。

我们将dumped_.exe加载到OD中。

这里OD提示入口点位于代码段之外,因为UPX壳将代码段指定到了第三个区段。

这个问题可以修复。

我们下面来修复它。

我们单击OK,停在了入口点处,我们在数据窗口中定位到400000地址处。

将数据窗口的显示模式切换为PE头模式。

往下拉:

可以看到PE头的相对虚拟地址（RVA）为80,即虚拟地址（VA）为400080。

这里我们看到BaseofCode=9000,表示代码段的相对虚拟地址为9000,我们需要将代码段的相对虚拟地址修改为1000。

我们选中BaseOfCode这一行,单击鼠标右键选择-Modifyinteger。

修改完毕以后我们将所做的修改保存到文件。

我们再次加载修复过的程序,可以看到OD没有弹出警告窗口了。

我们单击工具栏中M按钮看看各个区段的描述信息。

我们可以看到这里多出了一个区段,名字叫做mackt,这是ImportREConstructor给该程序添加的一个新的区段,专门用来存放新的导入表。

我们在数据窗口中看一看导入表的情况（PE头显示模式）。

我们可以看到导入表的相对虚拟地址为B000,即虚拟地址为40B000,刚好就是ImportREConstructor添加的那个区段。

我们将数据窗口的显示模式切换为正常模式。

我们在数据窗口中定位到导入表40B000地址处。

这里我们可以看到第一个IID,第四个字段为DLL名称字符串的指针,这里是B078（RVA）,即40B078（VA）。

指向的是user32.dll。

第五个字段为该DLLIAT项的起始地址的RVA,这里是3184,即IAT中的第一个元素的地址为403184。

这里我们可以看到IAT中保存的各个API函数的入口地址。

我们定位到可执行文件中对应IAT的偏移处,看看各个API函数名称字符串指针的情况如何。

我们可以看到IAT项中的值为B084,即40B084,指向的刚好是KillTimer这个API函数名称字符串。

这样我们就通过ImportREConstructor完成IAT的重建工作,操作系统在程序启动的时候就可以根据IAT中API函数名称字符串通过调用GetProcAddress获取到相应API函数地址,然后重新填充到IAT中。

本章我们就完成了第一个IAT的修复工作,虽然不是很难,但是也算是对我们前面章节知识点的一个汇总吧。

大家要好好理解本章的内容。

本章我们没有介绍AntiDump,等我们后面遇到了再介绍。