第五十章-再谈Recrypt v0.80脱壳(OutputDebugString的妙用) 本章我们回头再来看看Recrypt v0.80这个壳,给大家介绍了Patrick和PeSpin这两款壳以后,再回头来看Recrypt这款壳,可以说是小菜一碟了。本章我会给大家介绍OllyAdvanced这款反反调试插件的使用,首先我们用专门定位OEP的那款来OD加载UnPackMe_ReCrypt0.80.exe。 我们来配置一下这个插件,这个插件提供了一个Bugfixes(bug修复选项卡),其中就有修复NumOfRva Bug这一项。 我们直接运行起来,看看会发生什么。 这里我们可以看到UnPackMe_ReCrypt0.80区段显示都是正常的,我们剔除掉OllyAdvanced这个插件看看又会是怎么样的呢。 这里我们可以看到没有OllyAdvanced插件的话,还没有到达OEP就报错了。我们来看看区段,会发现主模块UnPackMe_ReCrypt0.80只显示了一个区段。这样的话我们只能通过PEEditor来查看代码区的起始位置以及大小,然后手动给代码段所在区域设置内存访问断点来定位OEP了,但是有了OllyAdvanced这个插件,这一切都可以省略了,嘿嘿。 下面我们直接运行起来。 嘿嘿,可以看到弹出了一个错误框,根据提示信息可以看出OD遇到了无法处理的异常。我们打开日志窗口看看出错的日志信息。 大家注意到这个Debug string:字符串没有,说明该程序调用了OutputDebugStringA这个API函数来输出调用信息。OutputDebugString函数用于向调试器发送一个格式化的字符串,Ollydbg会在底端显示相应的信息。OllyDbg存在格式化字符串溢出漏洞,非常严重,轻则崩溃,重则执行任意代码。这个漏洞是由于Ollydbg对传递给kernel32!OutputDebugString()的字符串参数过滤不严导致的,它只对参数进行那个长度检查,只接受255个字节,但没对参数进行检查,所以导致缓冲区溢出。虽然OllyAdvanced以及其他一些OD插件提供了对OutputDebugString函数的修复功能,但是我们这里还是无法正常运行。我们给OutputDebugStringA这个API函数下个断点一探究竟。 这里由于我不想给每次都手动在命令栏中一个字母一个字母的输入API函数的名称,所以这里我使用网上的朋友写的一款插件来完成这个任务,这个插件的名字叫做+BP-Olly。有了这个插件,我们只需要通过一次简单的按钮单击就可以完成对常见API函数的断点设置。 我们打开BP这个选项卡发现并没有OutputDebugStringA这个API函数,怎么办呢?不要紧,该插件有自定义功能,我们可以通过单击P(Personal:个人的)按钮将OutputDebugStringA这个API函数添加到列表当中。 我们单击Personalizar按钮,左边就多显示处一个对话框,我们输入BP OutputDebugStringA,接着单击Guardar(添加)按钮。 请注意,API函数的名称大小写要正确。下面我们再次单击P按钮。 这里我们可以看到BP OutputDebugStringA这个按钮就出现了,我们只需要单击一下BP OutputDebugStringA这个按钮,就可以给OutputDebugStringA这个API函数设置上断点。是不是很方便。嘿嘿。(PS:其实国内也有很多OD DIY的版本也提供了这个功能,譬如说吾爱破解的OD) 接着我们运行起来,会发现还是会报错。就是说简单的给OutputDebugStringA这个API函数设置INT3断点并不起作用。所以这里我们重启OD,接着在命令栏中输入HE OutputDebugStringA给该API函数设置一个硬件执行断点试试看。 删除掉刚刚设置的BP断点,接着运行起来。(PS:这里下INT3断点会报错因为反反调试插件之间存在冲突) 断了下来,我们执行到返回。 返回到了这里。 这里我们可以看到将EAX的值与零做比较,看看会发生什么。 这里我们可以看到EAX的值不等于零,接着跳转到下面将EAX的值与栈顶指针指向的内容相加。 相加以后栈顶的内容变成了: 我们继续往下跟踪,会发现下一条指令是RET,那么相加到栈顶的内容就是返回地址了。 534DF0这个地址并不存在,所以我们直接运行起来会抛出异常,而这个异常是调试器无法处理的,所以就报错了。 好了,报错的具体原因我们已经弄明白了,下面我们来修复它。 我们重启OD,运行起来,断在了OutputDebugStringA处,执行到返回,接着直接将EAX的值修改为0。 下面这个条件跳转就不会成立了,接下来EAX加1,现在EAX的值为1,下来继续将栈顶指针指向的内容加上EAX,也就是加1。 接着就是调用RET指令返回了。 现在这个返回地址是405115,这个地址是存在的,也就不会报错了。现在我们直接给主模块的代码段设置内存访问断点(这个OD是Patch过的,内存访问断点只是单单执行的时候才会断点来,读取或者写入并不会断下来,这样就方便我们定位OEP了,大家应该还记得吧),运行起来。 不一会儿就断下了OEP处。 这里我们就断在了OEP处。 我们单击鼠标右键选择Search for-All intermodular callsd搜索所有的API函数调用处。 我们可以看到只有少量的API函数调用,IAT如下: 这里我们可以看到IAT的起始地址为402000,结束地址为40201C。也就是说IAT的起始地址的RVA为2000,长度为1C。OEP的RVA为1000,下面我们将其DUMP出来,接着用IMP REC来修复其IAT。 我们打开IMP REC。 填上OEP的RVA,IAT的RVA,大小之后单击Get Imports获取导入表,接着单击Fix Dump修复刚刚dump出来的文件。 我们直接运行修复后的文件。 嘿嘿,搞定。
本系列文章汉化版转载看雪论坛
感谢原作者:RicardoNarvaja(西班牙人)
感谢热心翻译的朋友: 1~3章译者:BGCoder 4~58章译者:安于此生
全集配套程序下载地址:
|