# MANUAL — 反调试对抗与强反调试绕过 (Anti-Debug Bypass SOP)

> 本文件是当 Agent 在 G0/G1 阶段检测到目标存在**反调试或强对抗机制**时的标准化处置手册。
> 覆盖 Windows 用户态全量反调试技法、通用补丁模板与代理 DLL 框架接入指引。
>
> 读取顺序：先通过 `seep_auto_triage` 识别壳类型 → 与本文档对比签名 → 选择对应打桩策略。

---

## 一、 快速诊断表：常见反调试信号 → 处置路由

| 检测到的信号 | 最可能机制 | 首选处置策略 |
|---|---|---|
| `IsDebuggerPresent` 出现在导入表 | PEB.BeingDebugged | NOP / 硬编码返回 0 |
| `NtQueryInformationProcess` + 0x7 | ProcessDebugPort | Syscall Stub 替换 |
| `CheckRemoteDebuggerPresent` | 同上 | Hook 返回 FALSE |
| `GetTickCount` / `QueryPerformanceCounter` 频繁调用 | 时序反调试 | 钩子固定返回值 |
| `CreateToolhelp32Snapshot` + 进程名比对 | 调试器进程名检测 | Hook 过滤快照列表 |
| `OutputDebugString` 后检测错误码 | ODS 陷阱 | 无操作（正常运行不受影响） |
| `NtSetInformationThread` 0x11 | ThreadHideFromDebugger | Hook 丢弃该调用 |
| 注册表 `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug` | AeDebug 检测 | 值打补丁 / Hook RegQueryValueEx |
| 断点扫描 / 自校验 CRC | 内存完整性自检 | 修正 CRC 或 NOP 校验逻辑 |
| 驱动 `\Device\DebuggerDetect` / ObRegisterCallbacks | 内核级反调试 | → 参考第五节：内核层对抗 |

---

## 二、 用户态 PEB 系列反调试 —— 最常见（通用补丁）

### 2.1 `IsDebuggerPresent` → 返回值强制为 0

**原理**：`kernel32!IsDebuggerPresent` 本质只读 `PEB.BeingDebugged (offset 0x2)`。

**代理 DLL / Frida 修补（推荐）**：

```javascript
// Frida 方案
Interceptor.attach(Module.getExportByName('kernel32.dll', 'IsDebuggerPresent'), {
  onLeave: function(retval) { retval.replace(0); }
});
```

```cpp
// 内联汇编补丁（静态，适用于代理 DLL）
// 定位 IsDebuggerPresent 首地址，写入：
// XOR EAX, EAX
// RET
// 原始字节（x64）通常是: 65 48 8B 04 25 60 00 00 00 → 替换前 3 字节
BYTE patch[] = { 0x33, 0xC0, 0xC3 }; // xor eax,eax; ret
WriteProcessMemory(hProc, pIsDebuggerPresent, patch, sizeof(patch), nullptr);
```

### 2.2 `NtQueryInformationProcess` 信息类 7 (ProcessDebugPort) / 30 (ProcessDebugObjectHandle)

**原理**：成功连接调试器时 Port != 0。

```javascript
// Frida 方案
const NtQIP = Module.getExportByName('ntdll.dll', 'NtQueryInformationProcess');
Interceptor.attach(NtQIP, {
  onEnter(args) { this.cls = args[1].toInt32(); this.out = args[2]; },
  onLeave(retval) {
    if (this.cls === 7 || this.cls === 30) {
      this.out.writePointer(ptr(0));  // 清零 DebugPort / DebugObject
    }
  }
});
```

### 2.3 `NtSetInformationThread` → ThreadHideFromDebugger (0x11)

调用此系统调用后，调试器事件将对该线程不可见，导致断点失效。

```javascript
const NtSIT = Module.getExportByName('ntdll.dll', 'NtSetInformationThread');
Interceptor.attach(NtSIT, {
  onEnter(args) {
    if (args[1].toInt32() === 0x11) {
      args[1] = ptr(0);  // 替换为无害的 ThreadBasicInformation
    }
  }
});
```

---

## 三、 时序反调试 —— 高频坑（修复固定返回值）

调试状态下，`GetTickCount` / `QueryPerformanceCounter` 的推进速度远慢于正常运行，常被用来识别单步调试。

```javascript
// Frida 方案：固定时钟
let baseTick = Date.now();
Interceptor.replace(Module.getExportByName('kernel32.dll', 'GetTickCount'),
  new NativeCallback(() => {
    baseTick += 15;  // 模拟正常 15ms 系统时钟步进
    return baseTick;
  }, 'uint32', [])
);
```

---

## 四、 进程名 / 窗口名 / 文件路径特征检测 —— 改名或 Hook 快照

目标程序扫描进程快照（`CreateToolhelp32Snapshot + Process32Next`）比对调试器进程名：
`x64dbg.exe`、`ollydbg.exe`、`ida.exe`、`ida64.exe`、`cheatengine.exe` 等。

**最简单处置**：把调试器改名为 `explorer2.exe`、`chrome_x.exe` 等。

**进阶 Hook 方案**：

```javascript
// 过滤 Process32Next 快照，抹去调试器进程条目
const blacklist = ['x64dbg.exe', 'ida64.exe', 'ollydbg.exe', 'wireshark.exe'];
const Process32Next = Module.getExportByName('kernel32.dll', 'Process32NextW');
Interceptor.attach(Process32Next, {
  onLeave(retval) {
    if (retval.toInt32() !== 0) {
      const entry = this.context.rdx;  // PROCESSENTRY32W 结构
      const exeName = entry.add(44).readUtf16String();
      if (blacklist.some(b => exeName && exeName.toLowerCase().includes(b))) {
        // 递归调用直到返回非黑名单进程（简化处理：置为无害进程名）
        entry.add(44).writeUtf16String('System');
      }
    }
  }
});
```

---

## 五、 内核级反调试对抗（Ring0 / 驱动层）

> **适用场景**：游戏反作弊（ACE/EAC/BattlEye）、强保护商业软件、带 Ring0 驱动的许可校验模块。
> **注意**：内核对抗超出 Agent 全自动范畴，以下为指导性 SOP，需结合 WinDbg + 内核调试器手工处理。

### G0 阶段主动识别信号：
- `triage` 输出中存在 `.sys` 驱动签名或服务注册（HKLM\SYSTEM\CurrentControlSet\Services）
- 导入表出现 `NtLoadDriver`、`ZwCreateSection` 等内核接口
- 运行时观察到 `ObRegisterCallbacks` / `PsSetCreateProcessNotifyRoutine` 回调注册

### 处置策略（按难度升序）：
| 方案 | 适用条件 | 操作要点 |
|---|---|---|
| **Kernel Patch Guard 绕过** | 测试用 VM / Hyper-V | 关闭 Driver Signature Enforcement，加载调试补丁驱动 |
| **VirtualBox + DKOM** | 沙箱分析 | 修改 `EPROCESS.DebugPort = NULL` 绕过内核调试器检测 |
| **全量内存 Dump + 用户态重放** | 驱动已运行 | 在内核加载完毕后 dump 进程内存，在用户态 Loader 中重放 |
| **Emulation (Unidbg/QEMU)** | 需脱离真实 OS | 在模拟环境中重跑关键算法，完全规避内核对抗 |

---

## 六、 代理 DLL 注入框架模板（统一打桩方式）

> 适用于不能直接修改宿主 EXE（如有数字签名）的场景。

所有上述 Hook 均可集成在以下代理 DLL 框架中，加载即自动注入，宿主签名完好：

```cpp
// anti_debug_patch.cpp — 代理 DLL 打桩框架（以 version.dll 为例）
#include <Windows.h>

// 实际 version.dll 导出函数转发（保留原功能）
#pragma comment(linker, "/export:GetFileVersionInfoA=C:\\Windows\\System32\\version.GetFileVersionInfoA")
// ... 其他导出

void ApplyAntiDebugPatches() {
    // 1. 清除 PEB.BeingDebugged
    __asm {
        mov eax, fs:[30h]  // PEB
        mov byte ptr [eax+2], 0  // BeingDebugged = 0
    }
    // 2. Hook NtQueryInformationProcess (如上 Frida 方案的 C++ 等效)
    // ...
}

BOOL APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID lpvReserved) {
    if (reason == DLL_PROCESS_ATTACH) ApplyAntiDebugPatches();
    return TRUE;
}
```

---

## 七、 两击熔断纪律 —— 反调试对抗的止损规则

| 情形 | 触发条件 | 处置 |
|---|---|---|
| 用户态 Hook 无效（程序仍检测到调试器）| 同构打桩 2 次失败 | 停止，升级为内核层分析 |
| 内核层方案部署失败 | 同构 2 次失败 | 停止，改用 Emulation（Unidbg/QEMU）路线 |
| Emulation 行为无法覆盖 | 无法还原算法 | 输出"该目标超出当前工具链全自动范畴"，转人工分析 |