使用OllyDbg从零开始Cracking-42第四十二章-ACProtect V1.pdfVIP

第四十二章-ACProtect V1.09脱壳 (寻找 OEP,绕过硬件断点检测,修复Stolen cod e) 本章开始,我们将讨论更加复杂的壳-ACPr otect 1.09。 我们一步步的来剖析这个壳的保护机制。 该例子的名称为UnPackMe_ACProtect 1.0 9g.f。配合好反反调试插件,用OD加载之 。 我们直接运行起来,看看会发生什么。 . 这里我用的是Parcheado_4 (西班牙语:Pat ched_4)这个OD,接着按照下图来配置Hide OD 0.12反反调试插件,这样就可以正常运 行了,该壳会使用Process32Next这类API 函数来检测OD进程,反反调试插件可以绕 过。 下面我们来定位OEP。 前面章节我们介绍了很多定位OEP的方法, 比如说可以使用OD 自带的跟踪功能就能定 位到OEP,打开主菜单项Debugging option s-SFX,选择Trace real entry blockwise (inaccurate)。接着重启OD,不一会儿断 在了这里。 现在的问题是这里是否是真正的OEP,或者 说是不是存在stolen bytes。我们来看一 看堆栈的情况。 现在我们不勾选 自动定位OEP的选项,重启 OD。 我们可以看到比开始的时候多了两个值。 一般来说,这样情况存在stolen bytes。 下面我们来定位stolen bytes。 在定位stolen bytes之前,先来给大家介 绍一下如何利用HBP.txt这个脚本来设置 硬件断点,这个方法我们在脚本的编写那 一章中介绍过了,大家应该还记得吧！通 过脚本来设置硬件断点可以绕过很多壳对 于硬件断点的检测。假如我们现在想通过 设置硬件断点让程序断在OEP处的话,我们 会发现程序并不会断下来,我们可以通过H PB.txt这个脚本来解决这个问题。下面就 来给大家详细讲解硬件断点为什么不触发 的原因,以及HPB.txt脚本如何解决这个问 题的。 下面我们再次重启OD,分别给KiUserExcep tionDispatcher以及其内部调用的ZwCont inue处设置断点。 下面我们来给OEP处设置一个硬件执行断 点。 此时在壳的入口处,单击鼠标右键选择-Go to-Expression,输入地址4271B5。 在这里我们设置一个硬件执行断点。 单击鼠标右键选择Breakpoint-Hardware, on execution,接着运行起来。 断了下来,我们来看下堆栈情况。 此时断在了KiUserExceptionDispatcher 的入口处,堆栈中偏移4的单元中存放了co ntext的指针,下面我们到数据窗口中定位 该context。 这里我暂时不解释CONTEXT结构体各个字 段的含义,等后面用到的时候再解释。 在寄存器窗口中,单击鼠标右键选择View debug registers,切换到调试寄存器显示 模式,如果没有该选项的话,说明当前已经 是调试寄存器显示模式了。 这些就是调试寄存器组,Dr0 ~ Dr7。Dr0, Dr1,Dr2,Dr3是用于设置硬件断点的,由于 只有4个硬件断点寄存器,所以同时最多只 能设置4个硬件断点。产生的异常是STATU S_SINGLE_STEP (单步异常)。Dr4,Dr5是系 统保留的。Dr7是一些控制位,用于控制断 点的方式,Dr6是用于显示哪个硬件调试寄 存器引发的断点,如果是Dr0 ~ Dr3的话, 相应位会被置1。即如果是Dr0引发的断点 ,则Dr6的第0位被置1,如果是Dr1引发的断 点,则Dr6的第1位被置1,依次类推。因为 硬件断点同时只会触发一个,所以Dr6的低 4位最多只有一位被置1,所以在进入单步 后,我们可以通过检测Dr6的低4位是否有1 的位,就可以判断该单步是否是因为硬件 断点被断下的。如果是硬件断点被断下的 ,进而可以通过Dr6的哪一位为1来判断是 由Dr0~Dr3中的哪个断点断下的。 调试控制寄存器Dr7比较重要,其32位结构 如下: 位0 L0和位1 G0:用于控制Dr0是全局断点 还是局部断点,如果G0为1则是全局断点, 如果L0为1则为局部断点。G0,L0 ~G3,L3 分别用于控制Dr1~Dr3。 LE和GE：P6 family和之后的IA32处理器 都不支持这两位。当设置时，使得处理器 会检测触发数据断点的精确的指令。当其 中一个被设置的时候，处理器会放慢执行 速度，这样当命令执行