Ollydbg中F8的Bug

Posted 2020-10-03

用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内部源码设计的问题，没有考虑周全，最终变成了一种反调试的行为。