首页 > 数据库技术 > 详细

Ollydbg中F8的Bug

时间:2017-08-19 12:20:12      阅读:511      评论:0      收藏:0      [点我收藏+]

用Ollydbg调试以下代码,可以展示出其F8单步步过所存在的一个Bug:

#include <windows.h>

int main()
{
    CONTEXT ctx;
    ctx.ContextFlags = CONTEXT_FULL | CONTEXT_DEBUG_REGISTERS;
    GetThreadContext(GetCurrentThread(), &ctx);
    ctx.Dr7 = 0x101;
    ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
    SetThreadContext(GetCurrentThread(), &ctx);

    return 0;
}

代码中会调用SetThreadContext设置调试寄存器dr0有效(并未指定dr0的值)。

如果你用Od在call SetThreadContext处F8,程序基本上将会跑飞,不会停在下一条指令处。

 

这和Od的F8的原理有关。

重启程序,来到call GetThreadContext后按F8,如下图:

技术分享

内存区0x0012FC80是局部变量ctx的地址,内容是刚刚从GetThreadContext获得的。右边是当前调试寄存器的值。

可以看到内存偏移0x0012FC84处,即ctx.Dr0的值为0x00401023,与右边寄存器窗口中DR0的值相等。

 

Od的F8原理,若当前指令为call,则会在call指令的下一条指令即返回指令处设置一个一次性的硬件断点。

也就说,cCall GetThreadContext即0x0040101D处按F8,Od会在下一条指令即0x00401023处设置一个硬件断点,当前使用dr0存放地址。

设置硬件断点的方法是调用SetThreadContext,使得右边寄存器窗口的DR0变成0x00401023。

之后被调试程序调用GetThreadContext,得到的其实是用SetThreadContext设置过的内容,局部变量ctx.Dr0也就变成了0x00401023。

 

基于上面的道理,下面F8步过 call esi 就会导致右边窗口DR0的值发生改变,这里不要让它改变,让它依旧保持为0x00401023。

直接F9来到SetThreadContext处,先别按F8,而是按回车进入SetThreadContext内部,在第一条指令处下断。

这样做的目的是为了在SetThreadContext处按F8后能先进入其内部,而非直接运行函数。

按F8断在SetThreadContext的开头处:

技术分享

打开硬件断点列表,发现Od记录了一个一次性硬件断点,地址为0x00401041,与右边调试寄存器内DR0的值相同。

这正好是call SetThreadContext的下一条指令的地址(call SetThreadContext的返回地址)。

这印证了前面所说在call处F8会在返回地址处设硬件断点。

 

关键的来了。

如果接着在call NtSetContextThread处F8,或者不在SetThreadContext内部下断而直接在call SetThreadContext处F8,程序就会跑飞。

 

原因是这样的:

在call SetThreadContext按F8时,根据前面所述原理,Od会在下一条指令即0x00401041处设硬件断点,以期望程序运行到那里断下来。

那样就会形成我们平常见到的效果,在call处F8,接着断在下一行。

Od是这样想的,但是此时调用的函数是SetThreadContext,该函数也会设置一遍寄存器的值,会把Od设置过的内容覆盖掉。

本来Od设置了DR0为0x00401041,而被调试程序调用SetThreadContext,将DR0设置成了局部变量ctx中的内容,即0x00401023。

这使得0x00401041断点无效,程序之后将不能断在0x00401041,如果后面没有其他断点,程序将一直跑下去。

结果就是跑飞了,完全没有平常F8见到的效果。

 

但是Od很傻,它的硬件断点列表中还记录着自己设置的内容,并不是调试寄存器的真实值。

重启程序,在call SetThreadContext之后的 pop esi 处下断,然后在call SetThreadContext处按F8,会发现程序直接断在了 pop esi 处。

技术分享

就像按了F9一样。程序没有停在call SetThreadContext的下一条指令xor eax, eax处,可见Od设置的DR0失效了。

可是Od的硬件断点列表中依然有指令xor eax, eax的地址0x00401041,和右边寄存器窗口中的真实值不符。

 

接着再按F8,会发现Od又将自己硬件断点列表中的值写回调试寄存器了。

技术分享

 

这个Bug不仅Od原版存在,而且各种加插件版本的Od也有。

归根结底,这是Od内部源码设计的问题,没有考虑周全,最终变成了一种反调试的行为。

Ollydbg中F8的Bug

原文:http://www.cnblogs.com/rdt2017/p/7395981.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!