IsDebuggerPresent不可靠，仅检测PEB->BeingDebugged字节，易被patch、PEB篡改或单步异常绕过；需结合NtGlobalFlag检查和异常触发等多维度组合检测。
单靠 IsDebuggerPresent 基本没用，它只读一个字节，一 patch 就失效。 真实场景里，调试器早就不动声色地绕过它了——比如改写返回值、篡改 PEB、或用单步异常触发而不挂起进程。要真起作用，得组合多个信号，且得避开容易暴露的调用痕迹。
为什么 IsDebuggerPresent 一查就崩
它本质就是读取 PEB->BeingDebugged（x64 下是 gs:[60h] + 2），这个字节被设为 1 仅表示“系统认为你在被调试”，但：
- 调试器启动后可立刻用
WriteProcessMemory把这个字节改回 0 - 入口前 hook
LdrInitializeThunk，直接伪造整个 PEB 结构 - 用
SetThreadContext开 TF 位单步执行，IsDebuggerPresent完全感知不到 - 静态分析时，
IsDebuggerPresent在导入表里明晃晃列着，逆向第一眼就盯上
怎么写才不容易被绕过（x64 实战）
关键不是“多加几个检查”，而是让检测逻辑难定位、难模拟、带副作用。推荐这三步 inline asm 组合：
- 用
gs:[60h]手动取 PEB 地址，不调 API，避免导入表泄露 - 读
[rax+2]（BeingDebugged）和[rax+0bch]（NtGlobalFlag），后者若含0x70（FLG_HEAP_ENABLE_TAIL_CHECK | FLG_ENABLE_CSRDEBUG）基本坐实 - 在关键校验点插一句
__debugbreak()，配合 SEH：如果进了__except块，说明有调试器接管了异常——但注意 Release 下它不会中断，只对已附加的调试器生效
示例片段（无导入、无符号、SEH 可选）：
立即学习“C++免费学习笔记（深入）”；
__try {
__debugbreak();
} __except(EXCEPTION_EXECUTE_HANDLER) {
return true; // 被捕获了
}
unsigned char being_debugged = 0;
__asm {
mov rax, gs:[60h]
mov being_debugged, byte ptr [rax+2]
}
if (being_debugged) return true;
CheckRemoteDebuggerPresent 比 IsDebuggerPresent 强在哪
它底层走 NtQueryInformationProcess(ProcessBasicInformation)，再从返回的 PEB 地址里读字段，路径更长、更难被简单 patch。但它也有硬伤：
- 需要
GetCurrentProcess()句柄，而句柄本身可能被沙箱或 EDR 限制 - 调用失败时
GetLastError()可能暴露异常行为（比如权限不足） - 仍依赖 PEB 字段，只是多绕了一层——高级调试器照样能拦截
NtQueryInformationProcess - 如果你只传
GetCurrentProcess()，那跟IsDebuggerPresent实际效果差不多；真要防远程调试，得传目标进程句柄，但这需要PROCESS_QUERY_INFORMATION权限
真正难绕过的点不在“查什么”，而在“什么时候查”和“查完怎么用”。比如在内存解密前、网络请求发包前、或关键函数内联 asm 中间插检测——这些位置没法静态 patch，也没法提前预判。一旦漏掉一个上下文，整套逻辑就形同虚设。
