|
第四十一章-神马是AntiDump 这里我们仍然采用最后一次异常法定位到OEP处。 好了,现在我们到达了假的OEP处,接着我们单击鼠标右键选择Search for-All intermodular calls,查看API函数的调用列表。 这里我们随便选择一个,选中并双击之。 这里我们可以看到该API函数的入口地址位于460D38这个内存单元中的,也就是说460D38为IAT的其中一项。好,在数据窗口中定位到该地址。 我们可以看到这部分IAT项是正确的,我们往上看,定位IAT的起始位置。 这里很明显460818为IAT的起始位置,因为上面的项,查看参考引用的话,会发现没有参考引用处,并且也不属于系统DLL的区段。 这里很幸运,IAT项都是正确的,没有被重定向,所以我们并不需要修复重定向,接下来,我们来定位IAT的结束位置。 这里灰色的部分没有问题,但是460F24这一项就是比较可疑了,这一项没有参考引用。灰色的这部分是属于ole32.dll的代码段的。 这里我们选中属于该DLL的某些项,会发现也没有参考引用。 我们回到OEP处,可以看到该JMP指令将要跳转的一个地址为Axxxxx(在我的机器上为这种形式,在其他的机器上可能会不一样)的形式,该地址不属于exe所在的区段,我们来看一看区段列表。 我们知道原始程序在OEP附近是太可能跳转到exe之外的区段的,那么Axxxxx所在的这个区段很可能是通过VirtualAlloc或者类似的函数创建的,所以这个区段很可能是壳创建的。 在这个区段中壳可能会将IAT的中某些值取出来加以变换就转化为API函数的调用了。下面我们来对OD的调试选项加以配置。 以上就是壳创建的一个区段,我们来查看一下460F24这一项的参考引用。 依然是什么也没有,别灰心。我们继续看下面一个区段。 也看不出什么端倪。 我们回头再看看A80000这个区段,我们注意到A8003D这处CALL [460930],其对应的机器码为FF15 30094600,也就是说如果CALL [460F24]的话,其对应的机器码应该是FF15 240F4600,也就是说可以通过这种方式来调用API。 好了,下面我们搜索一下FF15 240F4600这串二进制串。 单击工具栏上面的M按钮打开区段列表窗口,选中第一个区段,单击鼠标右键选择-Search。 在16进制编辑框中写入FF15240F4600字节序列,单击OK,会发现,什么也没找到,说明有可能不是通过间接CALL,我们去掉前面的FF15,再次搜索。 正好定位到了壳创建的这个区段,我们其反汇编代码是什么。 这里我们可以看到是通过JMP来调用的,而并非CALL,所以机器码为FF25,并非FF15。也就是说460F24也是IAT中的一项。 所以说IAT的结束位置为460F28。 IAT的长度 = 结束位置 - 起始位置 = 460F28 - 460818 = 710 因此: OEP的RVA = 271B0 IAT起始地址的RVA = 60818 现在我们可以看到IAT项都是正确的了,我们回到假的OEP处,将stolen bytes填充上。 stolen bytes是55 8B EC 6A FF 68 60 0E 45 00 68 C8 92 42 00 64 A1 00 00 00 00 50 64 89 25 00 00 00 00 83 C4 A8 53 56 57 89 65 E8 。 我们在数据窗口中定位到4271B0处,按照第39章介绍的方式将stolen bytes填充好。 现在我们来dump,将OEP指定为4271B0。 这里我们把OEP修正了。去掉Rebuild Import的对勾,我们不使用OllyDump的重建输入表的功能。 将dump出来的文件命名为dumppeado pelock,现在我们来修复IAT,打开IMP REC,将OEP修正。 将IAT的信息填好,接着单击Get Imports按钮。 我们可以看到提示有无效的项,但是并没有经过重定向,只是每个DLL的IAT项原本应该是用零间隔开的,这里壳使用垃圾数据将零覆盖掉了。我们来看一看。 这里应该为零,用IMP REC修复很容易,我们单击Show Invalid即可。 这里我们可以看到advapi32.dll与comctl32.dll的项之间被垃圾数据隔开了,选中这些无效的项,单击鼠标右键选择Cut thunk(s),剪切掉这些无效的项。 我们可以看到剪切掉这些无效的项后,显示的项都标识为有效的了。 接着我们单击Fix Dump按钮来修复刚刚dump出来的文件。 修复后的文件被重命名为了dumpeado pelock_.exe。如果我们运行它的话,会提示错误。 下面我们需要用到LordPe来修复。 此时我们处在正确的入口点处,我们来看看IAT。 我们可以看到这里IMP REC已经把IAT都修复了,各个DLL中的IAT项中间的间隔也由垃圾数据替换为了零。但是为什么运行起来还报错呢? 这就是我们接下来要讨论的一个话题,在修复了IAT,以及stolen bytes以后,很多壳还会有AntiDump。 有很多类型的AntiDump,简单一点的AntiDump会校验映像的大小或者区段的个数,我们这个例子的AntiDump是壳创建了几个区段,在运行时会对原程序做一些处理,如果dump出来的程序不包含这些区段,那么程序就不能正常运行,我们来到入口点处。 当程序运行到4271D6处的JMP指令处的时候就会报错。 如果我们按F7键,会跳转到一个不存在的区段。 我们来看一看未脱壳的程序,会发现将跳转到壳运行时创建的一个区段中。 单击鼠标右键选择Follow,就能够跟随到壳创建的区段中。 这里我们可以看到是调用了一个API函数,接着返回到主程序代码段,有很多方法可以解决这个问题,最简单的方法就是给dump出来的文件添加一个相同的区段,我们来看看。 首先添加报错的这个区段,如果添加了以后还报错,再次添加其他缺失的区段。 这里我们需要用到PUPE这款工具来dump缺失的区段。 选中Pelock所在的进程,单击鼠标右键选择BOX OF TOOLS。 单击Mapa(即MAP)按钮打开区段列表窗口,定位到报错的区段。 我们还记得报错的区段的起始地址为A80000,我们一起来看一看。 我们单击Volcar(PS:西班牙语译为DUMP)按钮,将其命名为seccion(PS:西班牙语译为section)。 现在我们打开PEditor,将该区段添加到dump文件中。 通过PEditor打开dump出来的文件。 单击sections按钮。 这里我们可以看到IMP REC在为了修复IAT也给该程序添加了一个区段,名称为.mackt,我们将缺失的区段添加到最后。 在.mackt这个区段上面单击鼠标右键选择copy a section from HD to EOF。接着我们将新添加区段的起始地址修改为A80000。 我们来计算一下该新区段的相对虚拟地址 = A80000 - 400000 = 680000。 也就是说新区段的起始地址RVA = 680000。 下面我们通过LordPe来重建该PE就大功告成了。 正常运行,我们用OllyDbg打开它。 查看一下区段列表。 我们可以看到起始地址为A80000新添加的区段。 我们定位到4271D6地址处JMP指令,单击鼠标右键选择Follow。 跳转到了缺失的区段中。 我们来对比一下未脱壳和脱完壳并修复后的区段。 未脱壳的区段: 脱完壳修复后的区段: 本章就到这里。(PS:后面一点总结部分,作者讲的有误,这里就略去了)
本系列文章汉化版转载看雪论坛
感谢原作者:RicardoNarvaja(西班牙人)
感谢热心翻译的朋友： 1~3章译者:BGCoder 4~58章译者:安于此生
全集配套程序下载地址：
| 
|RSS|手机版|小黑屋|帮助|吾爱汇编
( 
京公网安备11011502005403号 , 京ICP备20003498号-6 )|网站地图
窥视卡
雷达卡
看了别人的提到了antidump，特意过来查询
