第16章反调试技术（一）

课程目录第16章反调试技术（一）

第十六章反调试技术（一）：IsDebuggerPresent、NtGlobalFlag、PEB标志位检测

反调试，是逆向工程里绕不开的一道坎。说白了，就是程序在跟你玩捉迷藏——它想知道自己是不是被调试器附身了。如果发现有人在偷看，它就换个路径跑，甚至直接自杀。

我个人习惯把反调试分成两大类：用户态检测和内核态检测。这一章我们先啃用户态里最基础的三个：IsDebuggerPresent、NtGlobalFlag 和 PEB 标志位检测。别小看它们，很多商业保护壳的底层逻辑，就是从这几个点衍生出来的。

核心知识点速览

IsDebuggerPresent：Windows 提供的官方 API，检测是否被调试
NtGlobalFlag：PEB 中的一个标志位，调试器会修改它
PEB.BeingDebugged：最直接的标志位，手动读取 PEB 绕过 API

1. IsDebuggerPresent：最直白的检测

这个 API 是 Windows 官方提供的。你调用它，它返回一个布尔值——告诉你当前进程是否在被调试。实现方式很简单：它去读取 PEB 结构里的 BeingDebugged 字段。

代码写起来就一行：

BOOL bDebugged = IsDebuggerPresent();
if (bDebugged) {
    // 有人在调试我，跑路！
    ExitProcess(-1);
}

嗯，这里要注意。很多新手觉得这玩意儿太简单，随便一个 NOP 掉就完事了。但我在项目中遇到过，有些恶意软件会把这个调用放在几十个不同的分支里，你 patch 了一个还有下一个。

绕过思路：

直接修改 EAX 返回值（在 call 之后 mov eax, 0）
Hook kernel32!IsDebuggerPresent，让它永远返回 0
修改 PEB.BeingDebugged 标志位（后面会讲）

2. NtGlobalFlag：调试器留下的痕迹

这个就有点意思了。Windows 内核在创建进程时，如果检测到有调试器附着，会在 PEB 的 NtGlobalFlag 字段（偏移 0x68）设置一些标志位。正常程序这个字段是 0，被调试时它会被设为 0x70。

为什么会这样？因为调试器在加载进程时，会调用 NtQueryInformationProcess 之类的内核函数，这些函数会顺手把标志位改了。说白了，这是调试器的一个「副作用」。

检测代码可以这样写：

// 手动读取 PEB 中的 NtGlobalFlag
#ifdef _WIN64
    PPEB pPeb = (PPEB)__readgsqword(0x60);
#else
    PPEB pPeb = (PPEB)__readfsdword(0x30);
#endif

DWORD dwFlag = *(PDWORD)((PBYTE)pPeb + 0x68);
if (dwFlag & 0x70) {
    // 检测到调试器痕迹
    MessageBox(NULL, "Debugger detected!", "Alert", MB_OK);
}

我记得有一次逆向一个加壳的样本，它就是用 NtGlobalFlag 做第一层检测。我当时在 x64dbg 里直接改了内存值，结果它还有第二层校验——它不光检查标志位，还检查标志位的变化时间戳。嗯，那又是另一个故事了。

注意：NtGlobalFlag 检测有一个坑——某些杀毒软件或系统监控工具也会修改这个标志位，导致误报。所以有些恶意软件会先检查这个标志位，如果发现异常，它不直接退出，而是走一条「假路径」来迷惑分析人员。

3. PEB.BeingDebugged：最底层的标志位

前面两个检测，本质上都是读 PEB 里的同一个字段——BeingDebugged（偏移 0x02）。区别只是读取方式不同。

直接读 PEB 的好处是：不依赖任何 API，不会被 Hook。你想想看，如果程序自己从 TEB 找到 PEB，再读偏移，调试器想拦截都难。

代码示例：

// 32位下读取 PEB.BeingDebugged
__asm {
    mov eax, fs:[0x30]  ; 获取 PEB 地址
    movzx eax, byte ptr [eax + 0x02]  ; 读取 BeingDebugged
    mov bDebugged, eax
}

// 64位下用内联汇编不行了，得用 intrinsics
#ifdef _WIN64
    PPEB pPeb = (PPEB)__readgsqword(0x60);
#else
    PPEB pPeb = (PPEB)__readfsdword(0x30);
#endif
BYTE bDebugged = *(PBYTE)((PBYTE)pPeb + 0x02);

实战技巧：

我在分析一个勒索软件时，发现它用了三层检测：

第一层：调用 IsDebuggerPresent（容易被 Hook）
第二层：手动读 PEB.BeingDebugged（绕过 API Hook）
第三层：用 NtGlobalFlag 做交叉验证（防止你只改一个地方）

三层都过了，它才执行真正的加密逻辑。我当时直接在内存里把 PEB 的 BeingDebugged 字段改成 0，然后 NtGlobalFlag 也清掉，才顺利跑过反调试。

4. 三种检测的对比

检测方式	实现难度	绕过难度	常见场景
IsDebuggerPresent	低（直接调用 API）	低（NOP 或改返回值）	入门级保护、快速检测
NtGlobalFlag	中（需要读 PEB 偏移）	中（需要修改内存）	加壳程序、恶意软件
PEB.BeingDebugged	中（手动解析 PEB）	中（需要定位并修改）	商业保护、反逆向框架

5. 绕过策略总结

我个人习惯的绕过流程是这样的：

第一步：在调试器里搜索 IsDebuggerPresent 的调用，直接 patch 掉。用 x64dbg 的「搜索当前模块中的符号」功能，很快就能定位。
第二步：如果程序没调用 API，那就搜 fs:[0x30] 或 gs:[0x60] 的读取指令。这是手动读 PEB 的特征。
第三步：如果上面都没找到，检查 NtGlobalFlag 的读取。这个特征码是 mov eax, dword ptr [eax+0x68] 之类的。
第四步：实在不行，直接在调试器启动后，手动修改 PEB 的 BeingDebugged 为 0。x64dbg 里可以用命令 eb <PEB地址+0x02> 0。

避坑指南：

我曾经遇到过一个程序，它在检测到调试器后不直接退出，而是假装正常运行，但会在加密算法里故意用错密钥。你绕过了反调试，但解出来的数据全是乱的。所以，绕过之后还要验证程序行为是否正常——别光顾着过检测，忘了看结果。

好了，这一章的内容就到这里。三种检测方式，说白了都是围绕 PEB 里的同一个标志位做文章。理解了这一点，你就能举一反三——以后遇到任何基于 PEB 的反调试，都知道该从哪里下手。