直接检测调试器仅为第一道防线，需结合干扰混淆与系统防护；Windows用IsDebuggerPresent和NtQueryInformationProcess易被绕过，Linux/Android推荐读/proc/self/status的TracerPid并交叉验证；辅以/GS、/guard:cf等编译保护及检测后降级策略。
直接检测调试器不是防动态跟踪的终点，而是第一道防线——它本身容易被绕过，必须配合干扰、混淆和系统级防护才能起效。
Windows 下用 IsDebuggerPresent 和 NtQueryInformationProcess 检测是否被附加
这两个 API 是最常用也最容易失效的起点。IsDebuggerPresent 只查 PEB 的 BeingDebugged 字段，patch 一条指令就能 bypass；NtQueryInformationProcess 查 ProcessDebugPort（信息类 ID 为 7）更隐蔽，但依然可被 hook 或伪造返回值。
- 调用前建议先校验函数地址是否被篡改（比如比对模块内存页的原始字节）
-
NtQueryInformationProcess是未导出函数，需手动解析ntdll.dll获取地址，否则静态链接会暴露意图 - 不要只依赖单次检测——连续多次调用并加入随机延迟，避免被静态 patch 一锅端
Linux/Android 中读取 /proc/self/status 的 TracerPid
这是 Android Native 层最可靠的检测方式之一。只要进程被 ptrace 附加，TracerPid 就非零；即使调试器 detach，该字段也不会立刻清零（内核行为），所以有短暂窗口可捕获。
- 注意路径权限：Android 8.0+ 对
/proc/[pid]/下多数文件做了 SELinux 限制，需确保进程有proc_read权限 - 不能只读一次：攻击者可在你读完后立刻 detach，建议结合
ptrace(PTRACE_TRACEME, ...)主动触发失败来交叉验证 - 别用
system()执行 shell 命令去读——开子进程太重且易被监控，直接open("/proc/self/status", O_RDONLY)+read更稳妥
C++ 编译时加 /guard:cf 和 /GS 阻断常见劫持路径
这些不是“检测”，而是让动态跟踪更难落地。CFG（Control Flow Guard）强制间接调用目标必须在编译期注册的合法跳转表中，/GS 插入栈 cookie 防止 return address 被覆盖——两者都让 shellcode 注入、IAT Hook、inline hook 失效概率大幅上升。
立即学习“C++免费学习笔记（深入）”；
-
/guard:cf必须搭配/DYNAMICBASE和/HIGHENTROPYVA才能发挥效果，单独开启意义有限 - 启用后需用
dumpbin /headers /loadconfig确认二进制中存在Guardsection 和CF Instrumentedflag - 注意性能损耗：CFG 检查在 hot path 上可能引入额外分支预测失败，关键循环里慎用
检测到调试器后，别急着 exit(1)
直接退出等于告诉攻击者“这里有问题”，反而暴露关键逻辑位置。更有效的做法是让程序继续运行，但逐步污染数据流或降级功能。
- 返回伪造的加密密钥、空的 license 结构体、或固定哈希值代替真实计算结果
- 插入无害但耗时的 dummy 循环（如反复调用
rdtsc并校验时间差），拖慢动态分析节奏 - 避免日志输出调试痕迹——
printf("debug detected")这类语句会被 strings 扫出来，改用内存内状态标记 + 条件分支控制后续行为
真正难防的不是检测本身，而是检测逻辑如何不被静态识别、不被动态绕过、不因优化被删掉——这意味着符号要混淆、字符串要加密、关键路径要拆散，还得留一手反 dump 机制。否则，一个 objdump -t 就能定位所有 IsDebuggerPresent 调用点。
