使用OllyDbg从零开始Cracking 第五十六章-EXECryptor v2.2.50.b脱壳
第五十六章-EXECryptor v2.2.50.b脱壳本章我们来看UnPackMe_ExeCryptor2.2.50.b.exe这个程序。我们直接运行该程序,看看效果。我们可以看到ExeCryptor UnPackMe的等级B稍微要难一点-Aggressive(译为:咄咄逼人的,这里译为强力的较为恰当)模式开启了,(PS:吓唬人吗?我好怕呀)我们直接用上一章调试等级A的OD(无需修改OllyAdvanced反反调试插件里面的选项)来加载这个UnPackMe_ExeCryptor2.2.50.b.exe。这里我们可以看到断在了系统断点处,我们打开断点列表窗口,删除里面的一次性断点。这里我们删除掉这两个一次性断点,接着跟上一章一样对代码段设置break -on-execute断点。(PS:我的OllyBone插件不好使,我上一章节中已经介绍了定位OEP的方法,这里就不再赘述了,详情请查阅上一章节)这个Set break-on-execute右键菜单项是OllyBone插件的一个选项,大家应该还记得吧。现在我们运行起来。到这里为止,基本上跟上一章的步骤没什么区别,现在我们删除掉break-on-execute断点(PS:我定位OEP的方法并没有用到OllyBone插件,所以并不需要删除break-on-execute断点),继续。如果大家足够细心的话,就会发现与上一章中的UnPackMe_ExeCryptor2.2.50.a.exe相比,这次我们断在OEP处时,多出了很多线程。很显然,这些线程是用来做检测用的,如果检测到自己正在被调试,就直接退出进程。如果我们直接运行起来的话,会发现程序直接退出了,这里我们将这些线程都挂起(除了红色标记的主线程以外)。这里我们依次在每个线程上单击鼠标右键选择Suspend(挂起)(除了以红色标记的主线程以外)。我们直接运行起来,会发现OD右下角的状态已经变成了Running,说明程序已经运行起来了,但是程序的主界面并没有弹出来。好,现在我们在挂起的线程中任意挑选一个出来,查看一下其调用堆栈,我们可以看到调用了ntdll.dll中的ZwWaitForSingleObject,也就说上层实际调用了WaitForSingleObject这个API函数,说明该线程在等待某个信号量,当前不会继续往下执行了。下面我们任选一个挂起的线程,这里我选择了第一个挂起的线程,单击鼠标右键选择Resume,让其恢复运行。我们可以看到OD右下角状态仍然是Running,但是程序的主界面还是没有弹出来,所以我们再次将该线程挂起,继续恢复下一个线程,如果下一个线程被恢复后,程序的主界面还是没有弹出来,我们继续将其挂起,继续恢复下一项,直到某挂起的线程被恢复以后,程序的主界面弹出来为止。我这里当恢复Entry的值为270000的这个线程(不同的机器上这个地址可能不一样)的时候,程序的主界面弹出来了。我们定位到270000地址处看看。我们对起始地址为270000的这个区段设置一个内存访问断点。接着运行起来,发现并没有断下来,所以我们需要改变一下策略了。我们没有必要再深入探究这个线程的细节了,我们的主要目的还是为了修复IAT,既然断不下来,说明该线程涉及到修复IAT的可能性比较小,现在我们重启OD,再次断到OEP处。下面我们来验证一下是不是仅仅只需要主线程以及线程函数入口地址为270000的这两个线程该程序就能正常运行起来了,如果是的话,那就最好不过了,如果不是的话,我们就还需要定位让程序正常运行必需的第三个或者更多的线程。好,下面我们将这两个线程以外的其他线程都挂起。另外,我们注意一下现在这两个线程的优先级,我们会发现线程函数入口地址为270000的这个线程的优先级与主线程的优先级是一样的,而其他线程的优先级比它们两个都低。我们运行起来看看会发生什么。也就是说该程序要想正常运行,只需要这两个线程即可。这里我给大家一些小小的建议:在脱一些强壳的时候,大家没有必要按照一些教程的步骤来生搬硬套,大家要学会灵活变通。有时候,看到网上的一些教程的脱壳步骤(譬如:按5次F8,3次F7就可以到达OEP处了+_+),说实话这种教程有点滑稽可笑,不免有误人子弟之嫌。这里就拿我当前的这个脱壳方案来说吧,说不定换了一台机器就行不通了也说不定。不可控的因素太多了,有时候可能同一款壳在不同的机器上,反反调试插件选项的配置上可能也会不同,琳琳种种的这些东西可能会花费我们大量的时间,所以大家在平时脱壳的过程中要善于总结经验,活学活用。好了,废话不多说,我们继续。上一章中的UnPackMe_ExeCryptor2.2.50.a.exe这个程序,我们是用内存写入断点来定位修复IAT项的指令的,同理,这里我们还是来尝试对OEP下面调用的第一个API函数对应的IAT项设置内存写入断点,接着利用OD的Trace into功能来进行自动跟踪,自动跟踪的时间大约要花费5分钟左右,大家耐心等待一下吧(自动跟踪的记录文本见附件)。大家应该还记得上一章中有一条所有待修复的IAT项都会执行的指令吧,这里我们在自动跟踪的指令序列中也可能找到它,只不过地址比上一章节中那个地址稍微要高一点。这次MOV EAX,DWORD PTR SS:这条指令的地址为483420,好,下面我们对上一章中编写的那个脚本进行相应的修改,我们将要设置硬件执行断点的地址修改为483423,当断到这条指令处时,EAX中已经保存正确的API函数地址。上一章中的脚本如下:----------------------------------------------------------------------------------------------------------------------------------------------------------------------var tablevar content mov table,460818 start: cmp table,460F28 ja final cmp ,50000000 ja ToSkip mov content, cmp content,0 je ToSkip log content log table mov eip,content bphws 47691F,"x" mov ,0 mov ,0 cob ToRepair runToRepair: cmp eip,7C91E88E je ToSkip log eax mov ,eax runToSkip: add table,4 jmp startfinal: ret大家应该还记得上一章中MOV EAX,DWORD PTR SS:这条指令的地址吧,执行了这指令后,EAX中将会保存待修复IAT项对应的API函数地址。0047691C Main MOV EAX,DWORD PTR SS: ; EAX=77DA6BF00047691F Main MOV ESP,EBP ; ESP=0012FFB0 而本章这里:00483420 > 8B45 F4 MOV EAX,DWORD PTR SS: ; kernel32.GetVersion00483423 . |8BE5 MOV ESP,EBP所以我们这里需要将该脚本中的47691F替换成483423。----------------------------------------------------------------------------------------------------------------------------------------------------------------------var tablevar content mov table,460818 start: cmp table,460F28 ja final cmp ,50000000 ja ToSkip mov content, cmp content,0 je ToSkip log content log table mov eip,content bphws 483423,"x" mov ,0 mov ,0 cob ToRepair runToRepair: cmp eip,7C91E88E je ToSkip log eax mov ,eax runToSkip: add table,4 jmp startfinal: ret 这里我对做了修改的地址用红色标注出来了,像IAT的起始地址以及结束地址这些我未做修改的地址以及常量值我用蓝色标注出来了。50000000这个常量值是用来判断IAT项是否被重定向的依据,而7C91E88E这个地址是我这里ZwTerminateProcess这个API函数的入口地址,大家应该还记得吧?我们继续。好了,现在我们重启OD,再次断到OEP处,别忘了删除掉break-on-execute断点,还有就是去掉忽略内存访问异常这个选项的对勾。接下来,将主线程以及线程函数入口地址为270000的这两个线程以外的其他线程都挂起,然后执行脚本。我们可以看到脚本确实是在修复IAT,但是我们会发现部分修复后的值是错误的。我们查看一下日志信息会发现从46099C这一项开始,修复后的值都是错误的。从日志信息中我们可以看到从这个地址开始,读取880045这个内存单元中的值的时候发生了异常。如果我们将脚本修改为如下形式:ToRepair:cmp eip,483423jne to ToSkiplog eaxmov ,eaxrun这样的话,当发生异常时,就会跳转到ToSkip标签处继续遍历下一个IAT项,这样做的话就不会保存这些错误的值了。这里我们执行该脚本,会发现还是出错。到底是哪里的问题呢?我们单步调试该脚本会发现:上一章中我们利用了发生异常时,程序会调用ZwTerminateProcess来结束进程这一特征。但是这里我们会发现发生异常时该程序并没有调用ZwTerminateProcess,难道是这里我们需要忽略内存访问异常吗?好,我们忽略掉内存访问异常试试。诶,我们会发现现在发生了异常以后,会调用ZwTerminateProcess了,也就是说这里我们应该忽略掉内存访问异常。好,现在我们勾选上忽略内存访问异常这个选项,然后再次执行脚本,看看效果。我们可以看到这次就没有问题了。完整的脚本如下:----------------------------------------------------------------------------------------------------------------------------------------------------------------------var tablevar content mov table,460818 start: cmp table,460F28 ja final cmp ,50000000 ja ToSkip mov content, cmp content,0 je ToSkip log content log table mov eip,content bphws 483423,"x" mov ,0 mov ,0 cob ToRepair runToRepair: cmp eip,483423 jne ToSkip log eax mov ,eax runToSkip: add table,4 jmp startfinal: ret这里大家要记住在执行该脚本之前,需要手动在ZwTerminateProcess这个API函数入口处设置一个硬件执行断点,还要勾选上忽略内存访问异常的选项,还没完,被忘了挂起线程。好,我们重启OD,断到OEP处,删除掉break-on-execute断点,接着执行该脚本。我们可以看到IAT项都被修复了。下面我们用OllyDump插件来进行dump,接着打开IMP REC。我们可以看到获取的IAT项都是有效的,接下来我们修复dump文件。接下来我们需要修复TLS,我们用OD加载修复后的dump文件,定位到PE头。将TLS Table address和TLS Table size这两个字段的值修改为零。保存修改到文件。直接双击运行,我们可以看到完美运行。好了,本章到此结束。本系列文章汉化版转载看雪论坛
感谢原作者:RicardoNarvaja(西班牙人) 原作者个人主页：http://www.ricardonarvaja.info/
感谢热心翻译的朋友：1~3章译者:BGCoder4~58章译者:安于此生
全集配套程序下载地址：
链接: http://pan.baidu.com/s/1eQzTWfo 密码: vytv
膜拜大神，学习了
@jojaajj 工作量巨大，忙了一天把这个发布到论坛，为了方便大家学习
这刷的也幸苦
Shark恒 发表于 2015-1-20 20:44
@jojaajj 工作量巨大，忙了一天把这个发布到论坛，为了方便大家学习
{:5_117:}鲨鱼叔辛苦了~~~您这也是为了我们这些爱好者，辛苦辛苦{:5_189:}
浩大工程，学习了。感谢老师分享！ 感谢楼主分享。
[快捷回复]-软件反汇编逆向分析，软件安全必不可少！ [吾爱汇编论坛52HB.COM]-做的不错哦，楼主加油，期待更好的作品！
页:
[1]
2