180306 逆向-反调试技术（1）BeingDebugged

1625-5 王子昂 总结《2018年3月6日》 【连续第521天总结】
A. 反调试技术（1）
B.

BeingDebugged

Win32API为程序提供了IsDebuggerPresent来判断自己是否处于调试状态，懒惰的程序员使用这个API来自欺欺人

实现源码为：

IsDebuggerPresent(VOID)
{
    return NtCurrentPeb()->BeingDebugged;
}

这个函数读取了当前进程PEB中的BeingDebugged标志
PEB(Process Environment Block，进程环境块)是每个进程都拥有的一个结构，其中包含了大量的进程相关标志
它的地址存放在TEB(Thread Environment Block, 线程环境块)之中，而TEB的地址会被该线程的FS段寄存器存储

换句话说，该API只是通过内存中的一个标志位来判断进程是否被调试……调试器改内存是手到擒来的事情，甚至OD还有插件可以免去手工操作的繁琐。
因此使得这个API沦为鸡肋。。。
真的是这样吗？

才不会这么简单~

在PEB中的BeingDebugged被设为True后，还会有一些其他的变化产生。

1. 加载时会将PEB中的NtGlobalFlag中的一个位改变，使其值为0x70，而正常状态下不是
2. 在WRK中有一个宏也会随着NtGlobalFlag的改变而在RtlCreateHeap中用RtlDebugCreateHeap创建调试堆。这个调试堆中含有大量的标志（例如0xBAAD0F0D和0xFEEEFEEE等），而正常情况下这个地址中却没有有意义的数据。

单纯的修改BeingDebugged标志位而忘记清除其他痕迹时，经常会被有所防备的壳、反调等程序捕捉到，例如Themida

从源头解决

上述三个标志全部清除也是可以的，不过相对而言比较麻烦
究其根源都是由于BeingDebugged被设为True导致的，因此如果找到一个时机，在NtGlobalFlag改变之前就设BeingDebugged为False即可绕过所有问题

但是如果把BeingDebugged设为False，就不会在系统断点处触发中断了。因此还需要有技巧的设置：

DebugEventCode	Count	PEB BeingDebugged	Note
LOAD_DLL_DEBUG_EVENT	0	FALSE
LOAD_DLL_DEBUG_EVENT	1	TRUE
EXCEPTION_DEBUG_EVENT	0	FALSE	EXCEPTION_BREAKPOINT

1. 在第一次触发LOAD_DLL_DEBUG_EVENT的时候将BeingDebugged设为False，绕过NtGlobalFlag的改变
2. 在第二次触发LOAD_DLL_DEBUG_EVENT的时候将BeingDebugged设为True，使系统中断正常触发
3. 系统中断以后再将BeingDebugged清除掉

C. 明日计划
反调试（2）