|
第二十四章-OllyDbg反调试之综合练习 在我们介绍异常处理之前,我们先把上一章留下的antisocial1这个反调试的综合练习讲解一下。 这是一个加过壳的程序,当然,我们还没有介绍壳的相关知识点,我们只需要知道该程序加载到内存中以后,壳会解密原区段的各个区段的数据,然后跳转到原入口点(OEP)处执行原程序的代码。当外壳程序解密/解压还原并跳转到OEP处,此时的内存映像就是已解压/解密过的程序,这个时候将内存映像抓取并保存为文件即可(该过程称之为Dump)。 首先我们用之前重命名过的OD,并且带上之前介绍过的所有插件,运行起来,我们会发现程序会终止,我们来尝试修复它。 好了,现在我们用重命名过的OD加载antisocial,将反反调试插件的选项都勾选上。 该提示表明该程序可能被加壳了,我们选择”是”按钮,然后就停在了入口点处。 这里我们会看到一些奇怪的东西,POPAD指令,该指令是从堆栈中恢复各个寄存器的值。正常情况下,应该是首先PUSHAD保存各个寄存器的值,而这里并没有执行PUSHAD指令,就比较可疑了。 我们运行起来看看会发生什么。 这里 这里提示错误-PUSH指令尝试压栈,但是这里没有写权限,但是通常来说堆栈应该是具有写权限的。我们来看一看堆栈。 当前栈顶指针指向的是130000,我们重新启动程序。 我们可以看到当前各个区段的情况,我的机器上堆栈是从12C000开始,到12FFFF结束。而现在操作是以130000起始的内存,它并不是堆栈,并没有写权限,所以会报错。 我们再次来到发生错误的地方。 我们可以看到该程序执行了另一个POPAD指令,接着就是条件跳转指令JNZ跳转到产生异常的PUSH的指令处,我们给POPAD指令这一行设置一个断点。 现在,我们重新运行该程序让其断在该断点处。 我们现在来看下堆栈。 当前栈顶指针还属于堆栈的范围,紧接着执行POPAD指令。 当前栈顶指针已经超出了堆栈的范围,这是由刚刚的POPAD指令导致的,正常情况下来说应该是一开始执行PUSHAD指令将各个寄存器的值保存到堆栈中,然后才是执行POPAD指令将堆栈的值恢复到各个寄存器中。好了,我们现在将开始处的POPAD指令替换成PUSHAD指令看看会发生什么,我们重新启动该程序。 我们按下空格键。 我们输入PUSHAD。 现在我们运行起来,断在了第二个POPAD指令处。 但此时的堆栈情况如下: 此时执行POPAD指令堆栈并不会越界,我们按F8键单步看看。 我们可以看到堆栈并没有越界。 我们到达了PUSH指令处,紧接着是RET,我们按F8键单步步过PUSH和RET指令。 好了,这里的OD分析有点问题,OD将这部分代码当做数据解释了。 这里,我们单击鼠标右键选择Analysis-Removeanalysis from module。现在代码开起来正常了吧,我们运行起来看看会发生什么。 程序终止了。我们查看一下日志信息,可以看到一些有趣的东西。 我们可以看到断在了POPAD指令处,然后就发生了异常。 我们重新启动程序,重复前面的步骤再次来到这里。 为了让程序发生异常可以停下来,我们去掉忽略所有异常的选项,第一个选项还是保持勾选。 运行起来。 就像刚刚日志中描述的一样,发生异常停了下来。 INT 68指令是少数OD无法处理的异常之一。我们直接使用NOP指令填充即可。 另外,该程序里面可能还存在其他INT68指令会对我们进行干扰,我们直接搜索INT 68指令,将其填充为NOP即可。 我们可以看到找到了另一个INT 68指令,我们直接NOP掉。 再次搜索,又找到了一个,继续NOP掉。 我们继续CTRL + L搜索,提示搜索结束,找不到其他的INT 68指令了,我们运行起来。 以上是我们使用了带反反调试插件的OllyDbg调试的情况,现在我们尝试使用不带插件的原版的OllyDbg 1.0来调试,手动来绕过该反调试。 (PS:odbg110FINAL sin plugins:表示不带插件的OllyDbg) 我们打开不带反反调试插件的OllyDbg,由于命令栏插件我们还是需要的,所以我们将插件目录指定为只包含命令栏插件的目录。 我们可以看到这里面只有一个命令栏插件,我们运行OD。 还是跟之前一样,将POPAD指令替换成PUSHAD指令。 我们还是给后面的POPAD指令设置断点,运行起来看看是否会断下来。 我们到了壳解压完毕处。 我们清空掉所有的忽略异常的选项,当我们运行起来,遇到INT 68指令时,将其NOP掉。而并不是使用SHIFT + F9忽略异常。 现在我们来看看程序中使用了哪些API函数。 还有一点就是别忘了勾选这个选项: 选择了该选项后,就会显示我们当前所在区段的相关信息。 该列表中显示没有几个API函数,并没有看到什么可疑的,但是这里有个GetProcAddress,该程序可以通过GetProcAddress函数来加载其他API函数,我们给该函数设置一个断点。 我们运行起来。 这个函数没什么可疑的,我们继续运行,直到断在了比较可疑的函数处。 这里我们看到了第一个可疑的API函数CreateToolhelp32Snapshot,该函数给当前运行的所有进程创建快照。我们执行到返回,这时,EAX保存的就是CreateToolhelp32Snapshot函数的首地址了,我们接着使用BP EAX命令给该API函数设置断点。 别忘了给该API函数添加上注释。 好了,我们继续运行。 这里是Toolhelp32ReadProcessMemory这个函数,跟CreateToolhelp32Snapshot类似,同上,我们给该函数也设置一个断点。 继续运行。 给Process32First这个函数也设置一个断点。 同上。 现在断在了创建进程快照处,我们知道该处的检测OD是基于这个进程快照的,该进程快照包含了进程列表中所有进程的相关信息,我们可以尝试patch这个函数,让该函数返回的快照句柄为空,现在我们来到CreateToolhelp32Snapshot这个函数的返回处。 我们可以看到这里有一些空余的空间,我们可以在返回之前将EAX赋值为零。 这样CreateToolhelp32Snapshot这个函数返回的快照句柄就为空了,该程序就不能通过进程快照来检测OD了。当然我们还有另一种方式-修改主程序中的代码,而并不修改CreateToolhelp32Snapshot的实现代码。 按F8键单步跟踪,我们可以看到这里有个JNZ条件跳转指令会跳转至TerminateProcess处结束掉OD进程。OD的进程句柄在之前通过OpenProcess获取。我们可以看到这里有五个分支判断。 这里我们将这几处JNZ指令修改为JMP指令,这样就可以避免程序执行TerminateProcess结束掉OD进程。 这样反调试的第一个部分我们就搞定了,现在我们来解决反调试的第二个部分,我们运行起来。 我们停在了INT 68指令处,我们将该INT 68指令用NOP指令填充掉,然后运行起来会发生程序终止了。 如果我们加载HideDebugger1.23f插件,并勾选上FindWindows/EnumWindows选项,然后重复之前的步骤会发现运行的很正常。 刚刚导致OD终止的地方是这里。 我们跟进都这个CALL 4047F0里面。 这里,我们可以看到比较指令。 这里当比较出是OllyDbg的话,就会终止掉当前进程。这里我们为了避免JNZ条件跳转指令不成立进而去调用下面的CALL 4532CC结束掉进程,我们将该JNZ指令修改为JMP指令。 这里将该关键跳转修改为JMP指令。 我们再来看看我们绕过的第二个CALL指令里面具体是怎么结束进程的。 该CALL指令里面是调用PostQuitMessage退出主线程。 好了,现在你可能会问了,你是怎么定位上面那个JNZ 473305关键跳转的呢?很简单。 我们按照之前的步骤干掉了该反调试的第一部分以后,就可以给PostQuitMessage这个API函数设置一个断点。 断在了该API函数处,我们看下堆栈,看看该调用来至哪里。 堆栈中信息显示该调用来至于4532D7处,我们定位到该地址。 这里说明前面的JE指令跳转没有发生,进而调用PostQuitMessage,这里如果我们继续执行PostQuitMessage话,程序就退出了,所以这里我们直接在堆栈中查看返回地址是多少。 这里我们可以看到返回地址为473305。 好了,这里我们就比较熟悉了,我们可以将4732F7处的JNZ指令修改为JMP指令,避免让该程序执行下面的CALL中PostQuitMessage结束掉进程。这样我们就手工的解决这个反调试,并没有借助反反调试插件。
本系列文章汉化版转载看雪论坛
感谢原作者:RicardoNarvaja(西班牙人)
感谢热心翻译的朋友： 1~3章译者:BGCoder 4~58章译者:安于此生
全集配套程序下载地址：
| 
|RSS|手机版|小黑屋|帮助|吾爱汇编
( 
京公网安备11011502005403号 , 京ICP备20003498号-6 )|网站地图
窥视卡
雷达卡
