OEP寻踪

作者: Justin_901e | 来源:发表于2019-07-26 14:50 被阅读0次

    1)搜索JMP或者CALL指令的机器码(即一步直达法,只适用于少数壳,包括UPX,ASPACK)

      对于一些简单的壳可以用这种方式来定位OEP,但是对于像AsProtect这类强壳(PS:AsProtect在04年算是强壳了,嘿嘿)就不适用了,我们可以直接搜索长跳转JMP(0E9)或者CALL(0E8)这类长转移的机器码,一般情况下(理想情况)壳在解密完原程序各个区段以后,需要一个长JMP或者CALL跳转到原程序代码段中的OEP处开始执行原程序代码。

    下面我们将上一章中加了UPX壳的那个CrueHead的CrackMe加载到OD中:

    这里我们按CTRL+B组合键搜索一下JMP的机器码E9,看看有没有这样一个JMP跳转到原程序的代码段。

    这个JMP是跳转到第一个区段的,我们在这条指令处设置一个断点,断在这里时,我们按F7键就可以单步跳转到OEP处。

    除了搜索JMP指令的机器码以外,大家还可以尝试搜索CALL EAX,CALL EBX,JMP EAX等指令的机器码,因为很多壳是将OEP的值存放在寄存器中,然后通过CALL 某寄存器或者JMP 某寄存器来跳往OEP的。OllyBbg提供了搜索ALL COMMANDS的功能,我们可以通过单击鼠标右键选择-Search for-All Commands来搜索,然后各个指令处依次设置断点,下面我们来看个例子。

    2)堆栈平衡法(ESP定律法)

      这种方法适用于一些古老的壳。这些壳首先会使用PUSHAD指令保存寄存器环境,在解密各个区段完毕,跳往OEP之前,会使用POPAD指令恢复寄存器环境。

    这里我们来看看CRACKME UPX。

    我们可以看到第一条指令就是PUAHAD,有的情况下保存寄存器环境可能不是第一条指令,但也在附近了,还有些情况下,有些壳不使用PUSHAD,而是逐一PUSH各个寄存器(例如:PUSH EAX,PUSH EBX等等),总而言之,在解密完区段,跳往OEP之前会恢复寄存器环境。

    这里我们按F7键执行PUSHAD:

    可以看到各个寄存器的初始值被压入到堆栈中了,这里我们可以对这些初始值设置内存或者硬件访问断点,当解密例程读取这些初始值的时候就会断下来,断下来处基本上就在OEP附近了。

    这里我们可以通过在ESP寄存器值上面单击鼠标右键选择-Follow in dump在数据窗口中定位到这些寄存器的初始值。

    数据窗口中显示的堆栈内容如下:

    这里我们可以对这些初始值的第一个字节或者前4个字节设置硬件访问断点

    选择字节,字,双字都可以,只要解密例程在读取这些值的时候断下来就OK,运行起来。

    我们可以断在了POPAD指令的下一行,当壳的解密例程读取该值的时候断了下来,紧接着下面就是跳往OEP处,说明这个方法起作用了。

    3)VB应用程序定位OEP(Native 或者 P-CODE)

    定位VB程序的OEP比较容易,因为VB应用程序都有一个特点-开始都是一个PUSH指令,紧接着一个CALL指令调用一个VB API函数。我们可以使用Patch过的OD,首先定位到VB的动态库,接着给该动态库的代码段设置内存访问断点,

    当壳的解密例程解密完原程序各个区段,接着就会断在VB DLL的第一条指令处,接着我们可以在堆栈中定位到返回地址,就可以来到OEP的下一条指令处。这里我们也可以使用前面介绍的方法-跟逐一给各个区段设置内存访问断点(使用Patch过的OD),但是很多壳会检测这种方法,所以大家可能根据需要不同的情况来尝试这不同的方法。这种方法很容易理解,我就不举例子了,以后大家如果遇到了VB程序可以试试这种方法。

    4) 最后一次异常法

      如果我们在脱壳的过程中发现目标程序产生大量异常的话,就可以使用最后一次异常法,我们来看一个例子,名字叫做”bitarts_evaluations.c”。

    我们还是使用Patch过的OD来加载它,并且配置好反反调试插件。

    然后将EXCEPTIONS菜单项中的忽略各个异常的选项都勾选上,运行起来。

    我们可以看到程序运行起来了,我们单击工具栏中L按钮打开日志窗口。

    这里我们可以看到产生了好几处异常,但是都不是位于第一个区段,说明这些异常不是在原程序运行期间发生的,是在壳的解密例程执行期间产生的异常,最后一次是46e88f处的这个异常。

    好,现在我们重新启动OD,将EXCEPTIONS菜单项中忽略的异常选项的对勾都去掉,仅保留Ignore memory access violations in KERNEL32这个选项的对勾。

    我们运行起来,产生异常断了下来,我们直接按SHIFT + F9忽略异常继续运行。直到停在了46E88F处为止。

    这里不是,我们按SHIFT + F9忽略异常继续运行,我们知道最后一次异常是46E88F处的INT 3指令引发的。

    这里是壳的解密例程执行过程中产生的最后一次异常,接着就是执行原程序的代码了。

    5)利用应用程序调用的第一个API函数来定位OEP

    这种方法就是直接给应用程序调用的第一个API函数设置断点,比如说,很多程序(VC++)一开始会调用GetVersion,GetModuleHandleA,对于bitarts_evaluations.c来说我们可以断GetVersion,对于CRACKME UPX来说我们可以断GetModuleHandleA。这里是bitarts_evaluations.c,所以我们给GetVersion设置断点。

    运行起来。

    这里我们断在了GetVersion的入口点处,从堆栈中我们可以看到返回地址位于第一个区段。我们直接在返回地址上面单击鼠标右键选择-Follow in Disassembler。

    里我们又定位到了OEP。以上就给大家演示的如何利用应用程序调用的第一个API函数来定位OEP了。如果我们遇到有的壳检测GetVersion入口处的INT 3断点的话,我们可以尝试在该API函数的返回指令RET处下断。

    其实还有很多适用于特定壳定位OEP的方法,这里就不给大家一一介绍了,基本上也是根据上面的这些基本方法变通来的,所以说大家掌握好上述这些基本的定位OEP的方法和原理就即可。

    这里给大家留一个小程序练习,名字叫做UnPackMe_tElock0.98。大家尝试定位其OEP。这个壳专门采取了一些技巧来干扰利用上述方法定位OEP,所以说如果直接利用上述这些方法的话,就不能奏效了,大家可以好好琢磨一下这个壳。

    大家记住,如果壳检测INT 3断点或者硬件断点的话,你使用ESP定律给堆栈中的寄存器初始值设置硬件断点也是不起作用的,只能换其他方法。

    相关文章

      网友评论

          本文标题:OEP寻踪

          本文链接:https://www.haomeiwen.com/subject/sgzrrctx.html