C++如何检测程序是否被调试 _ IsDebuggerPresent用法【实战】-C++-PHP中文网

isdebuggerpresent不可靠，仅检测peb->beingdebugged字节，易被patch、peb篡改或单步异常绕过；需结合ntglobalflag检查和异常触发等多维度组合检测。

c++如何检测程序是否被调试 _ isdebuggerpresent用法【实战】

单靠 IsDebuggerPresent 基本没用，它只读一个字节，一 patch 就失效。 真实场景里，调试器早就不动声色地绕过它了——比如改写返回值、篡改 PEB、或用单步异常触发而不挂起进程。要真起作用，得组合多个信号，且得避开容易暴露的调用痕迹。

为什么 `IsDebuggerPresent` 一查就崩

它本质就是读取 PEB->BeingDebugged（x64 下是 gs:[60h] + 2），这个字节被设为 1 仅表示“系统认为你在被调试”，但：

调试器启动后可立刻用 WriteProcessMemory 把这个字节改回 0
入口前 hook LdrInitializeThunk，直接伪造整个 PEB 结构
用 SetThreadContext 开 TF 位单步执行，IsDebuggerPresent 完全感知不到
静态分析时，IsDebuggerPresent 在导入表里明晃晃列着，逆向第一眼就盯上

怎么写才不容易被绕过（x64 实战）

关键不是“多加几个检查”，而是让检测逻辑难定位、难模拟、带副作用。推荐这三步 inline asm 组合：

C++ 算法竞赛自动化测试数据生成与校验框架

根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。

下载

用 gs:[60h] 手动取 PEB 地址，不调 API，避免导入表泄露
读 [rax+2]（BeingDebugged）和 [rax+0bch]（NtGlobalFlag），后者若含 0x70（FLG_HEAP_ENABLE_TAIL_CHECK | FLG_ENABLE_CSRDEBUG）基本坐实
在关键校验点插一句 __debugbreak()，配合 SEH：如果进了 __except 块，说明有调试器接管了异常——但注意 Release 下它不会中断，只对已附加的调试器生效

示例片段（无导入、无符号、SEH 可选）：

__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，也没法提前预判。一旦漏掉一个上下文，整套逻辑就形同虚设。