使用OllyDbg从零开始Cracking 第四十章OllyDbg脚本的编写.docx
《使用OllyDbg从零开始Cracking 第四十章OllyDbg脚本的编写.docx》由会员分享,可在线阅读,更多相关《使用OllyDbg从零开始Cracking 第四十章OllyDbg脚本的编写.docx(12页珍藏版)》请在冰豆网上搜索。
使用OllyDbg从零开始Cracking第四十章OllyDbg脚本的编写
第四十章
本章在修复PELock的IAT,AntiDump之前,我们先来讨论知识点,第一个知识点我们上一章已经碰到了,只不过没有展开讲而已,第二个知识点就是如何绕过PELock或者类似软件对硬件断点的检测。
知识点1在上一章节我们遇到过,大家可能没有在意,大家是否还记得上一章节中,OD加载目标程序以后,直接运行起来会弹出一个错误框,提示不知道该如何处理xxx处的非法指令。
为了解决这个问题,我们需要用到Patched4这个程序(又一个打过补丁的OD),我们将其置于原OD所在的文件夹中,因为原版OD在处理非法指令的时候有个BUG,就算我们勾选上调试选项中的忽略非法指令异常,当OD遇到非法指令的时候还是会弹出一个错误框,Patched4这个OD修复了这个BUG。
大家将Patch4这个OD跟原版OD放到同一个文件夹下面,下面我们分析PELock的时候需要用到。
好,再来给大家解释一遍(PS:
老外比较细心,也比较啰嗦,嘿嘿)。
原版OD处理非法指令的时候有个BUG,勾选上调试选项中忽略非法指令异常,加载UnPackMe_PELock1.06,接着运行起来。
我们可以看到弹出了一个错误框,但是我们用Patch4这个OD来加载UnPackMe_PELock1.06的话,就可以完美运行。
我们来看看日志信息。
我们可以看到最后一次异常是一个非法指令异常,现在我们不勾选的忽略非法指令异常选项。
这里我们去掉Invaildorprivilegedinstruction这个选项的对勾,加载UnPackMe_PELock1.06,运行起来。
断在了异常处,如果我们按Shift+F9也可以继续运行下去。
也就是原版OD是就算你勾选了忽略非法指令异常这一项,OD并没有自动忽略。
如果是仅仅有一个这类异常,我们按一下Shift+F9也没什么。
但是如果目标程序会产生200或者300个这样的异常,难道我们也手工去按Shift+F9不成(PS:
连续按Shift+F9200多次,那还不得疯掉哇,哈哈)。
我们再次勾选上Invaildorprivilegedinstruction这个选项,运行起来,再次弹出了错误框。
下面我们来尝试修复OD的这个BUG,再新开一个OD。
选择新的OD主菜单中的File-Attach。
定位到弹出错误框的OD所在的进程。
定位到弹出错误框OD所在的进程,单击Attach(附加)。
断在了这里,我们运行起来。
接着我们来看一下区段列表窗口。
现在我们可以看到OllyDbg的各个区段情况,接下来我们给MessageBoxA这个API函数设置一个断点。
由于我们单击错误消息框上面的OK按钮,就到达MessageBoxA函数的RET指令处,我们给该RET指令处也设置一个断点。
弹出错误消息框后,我们单击Aceptar(OK)按钮。
就会断在MessageBoxA这个API函数的返回RET指令处,我们单击F7键单步。
下面我们查看一下字符串列表,看看有没有消息框提示的错误信息字符串。
我们看看有没有字符串里面含有bypass这个单词。
我们可以看到我们要找到字符串在这里,我们在这个字符串上面双击。
我们可以看到这里有几处JNZ可以跳过弹出错误消息框的代码,这里我们将435260处的JE修改为JMP43528D,保存到文件中。
接下来我们看看Patched4这个OD该处的代码是怎么样的。
这里我们可以看到435260处的条件跳转被修改为无条件跳转,即修改为了JMP43528D,这样就能跳过填出错误消息框的代码。
这就是Patched4修复非法指令这个BUG的原理。
大家可以自行给OD打补丁也可以直接用Patched4这个OD。
知识点2就是要给大家演示如何编写脚本,我们需要用到OllyScript0.92.dll这个插件,将其放到OD的插件目录下。
打开Patched4这个OD。
我们可以看到主菜单中出现OllyScript的插件子菜单项。
现在我们加载UnPackMe_PELock1.06,下面我们编写一个简单的脚本让该壳无法检测到我们设置的硬件断点。
关于这个插件的使用说明大家可以参考插件文件夹下面的readme.txt。
这个脚本的思路很简单:
每次异常触发后都会断在KiUserExceptionDispatcher,接下来就会由操作系统去调用异常处理函数,这个时候我们设置硬件断点可以被检测到,所以这个脚本要做的就是当前断在KiUserExceptionDispatcher时,清除掉硬件断点,当断在下面的CALLZwContinue时再将硬件断点恢复。
由于这是我们要编写的第一个脚本,所以不会让大家写太难的。
首先给KiUserExceptionDispatcher和ZwContinue分别设置断点。
现在我们开始编写脚本。
一般来说脚本都有一个开始标签:
beginning:
设置这个标签可以让我们方便的JMPbeginning,接下来我们来设置硬件断点,举个例子:
bphws12ffc4,“r”
bphws-该命令可以对指定地址设置硬件断点,这里是对12ffc4设置硬件断点,“r”表示读取,”w”表示写入,”x”表示执行。
beginning:
bphws12ffc4,“r”
work:
设置完硬件断点以后我们再来添加一个work标签。
beginning:
bphws12ffc4,“r”
work:
eobto_process
run
这里的eob,-表示在下次中断发生时,跳转到指定标签处,这里该标签是to_process,即当程序中断下来时将跳转到to_process标签处,接下来run命令表示运行起来。
这里就是关键的部分了,当前OD中断后,我们就需要检查是否断在了KiUserExceptionDispatcher入口处,所以我们在to_process标签下面来进行检查。
to_process:
cmpeip,7C91EAEC
jeto_clear
cmpeip,7C91EB03
jeto_recover
jmpto_final
我这里7C91EAEC是KiUserExceptionDispatcher的入口地址,当断在KiUserExceptionDispatcher入口处时,eip为7C91EAEC,所以跳转到to_clear标签处清除硬件断点,接下来当断在CALLZwContinue指令处时,就跳转到to_recover标签处恢复硬件断点。
清除内存断点如下:
to_clear:
bphwc12ffc4
jmpwork
当前跳转到to_clear标签以后,通过bphwc命令删除12ffc4处的硬件断点,接着跳转到work标签处继续运行程序。
另外一个to_recover标签处是当断在CALLZwContinue处时重新设置硬件断点的。
to_recover:
jmpbeginning
接下来就是直接跳转到开头beginning标签处了,也就是将重新设置硬件断点。
接下来就是程序断在硬件断点处时,也就是jmpfinal。
to_process:
cmpeip,7C91EAEC
jeto_clear
cmpeip,7C91EB03
jeto_recover
jmpfinal
最后是:
final:
MSGYN“是否继续?
”
cmp$RESULT,1
jebeginning
ret
这里的MSGYN命令会将指定消息,显示到一个对话框中,这个对话框上面有”是”,”否”按钮。
如果点击”是”,保留变量$RESULT等于1,否则保留变量$RESULT等于0。
如果我们想继续的话,就单击”是”,这样就会跳转beginning标签处继续执行脚本,如果我们不想继续,就单击”否”,这样就会直接ret,脚本就执行完毕了,OD就会停在硬件断点处。
整个脚本就是这样的:
beginning:
bphws12ffc4,“r”
work:
eobto_process
run
to_process:
cmpeip,7C91EAEC
jeto_clear
cmpeip,7C91EB03
jeto_recover
jmpto_final
to_clear:
bphwc12ffc4
jmpwork
to_recover:
jmpbeginning
final:
MSGYN“是否继续?
”
cmp$RESULT,1
jebeginning
ret
该脚本的整个执行流程,大家可以参考下图中的解释,这里我就不再赘述了。
我们将上面的脚本保存到一个txt文本中,接着用OD加载UnPackMe_PELock1.06,然后给KiUserExceptionDispatcher入口处和callZwContinue指令处分别设置一个断点,接着在主菜单中找到OllyScript插件。
这里我们看到断在了硬件断点处,如果要继续执行脚本的话,单击YES按钮。
这里我们可以看到完美运行,我们来看看硬件断点窗口。
这里我们可以看到硬件断点设置成功了,也可以正常断下来,达到了我们预期的效果。
本章到此结束,下一章我们来介绍如何编写脚本修复PELock的IAT。