直接读取PEB->BeingDebugged会失败，因其为易伪造的弱信号：调试器常清零该字段，且受HVCI/CFG等保护机制干扰；须配合NtGlobalFlag、CheckRemoteDebuggerPresent等交叉验证，并注意x64用__readgsqword(0x60)、x86用__readfsdword(0x30)安全获取PEB地址。
直接读取 PEB->BeingDebugged 会失败吗？
会，而且非常容易踩坑。Windows 的 PEB 地址在用户态是可读的，但 BeingDebugged 字段（位于偏移 0x2）本身是单字节，且现代系统（尤其是启用 CFG、HVCI 或 PatchGuard 保护的系统）可能让该字段被内核动态修改或影子 PEB 干扰。更关键的是：如果进程已被调试器附加，BeingDebugged 可能早已被调试器清零（比如 x64dbg 默认就抹掉它），导致检测失效。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不要只依赖
BeingDebugged单一标志，它只是“弱信号” - 必须配合其他检查（如
NTGlobalFlag、ProcessHeap->Flags & HEAP_IS_DEBUGGING、CheckRemoteDebuggerPresent）交叉验证 - 读取前先用
GetModuleHandleA(NULL)确保当前模块已加载，避免在 DLL_PROCESS_ATTACH 早期读取未初始化的 PEB
怎么安全获取当前进程的 PEB 地址？
不能硬编码或假设地址。32 位和 64 位下获取方式不同，且受编译器优化影响（比如 /GS 可能干扰栈帧）。推荐用内联汇编（x86）或 __readgsqword（x64）+ 编译器内置函数组合。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- x64 下：用
__readgsqword(0x60)读取 GS 段基址 + 0x60 偏移（对应NT_TIB->Self后的 PEB 指针） - x86 下：用
__readfsdword(0x30)（FS 段偏移 0x30） - 务必加
#ifdef _M_X64/#ifdef _M_IX86分支，混用会导致崩溃 - 读取后做空指针检查：
if (!peb || !IsBadReadPtr(peb, sizeof(void*)))，避免访问非法内存
BeingDebugged 字段读出来是 0 就一定没被调试？
不一定。常见误判场景包括：
- 调试器主动清零（如 OllyDbg 插件 “Hide Debugger”、x64dbg 的 “Hide from debugger” 选项）
- 进程以
CREATE_SUSPENDED启动后被调试器附加，此时BeingDebugged可能仍为 0 - 某些反调试框架（如 ScyllaHide）会 Hook
NtQueryInformationProcess，伪造返回值
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 读取
peb->BeingDebugged后，立即再读peb->NtGlobalFlag（偏移0xBC），检查是否包含0x70（FLG_HEAP_ENABLE_TAIL_CHECK | FLG_HEAP_ENABLE_FREE_CHECK | FLG_HEAP_VALIDATE_PARAMETERS），这是典型调试器注入特征 - 调用
CheckRemoteDebuggerPresent(GetCurrentProcess(), &isDebugged)作为辅助验证，注意它返回TRUE不代表正在被调试，只是“远程调试器存在” - 避免在主线程入口反复轮询——会被行为分析识别为反调试模式
为什么 Release 模式下检测经常失效？
编译器优化（尤其是 /O2）可能导致 PEB 指针被寄存器缓存、指令重排，甚至整个检测逻辑被 LTO 删除。另外，ASLR 和 CFG 会影响内联汇编的合法性。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对反调试函数加
__declspec(noinline)和#pragma optimize("", off)禁用优化 - 避免使用
volatile修饰 PEB 指针——它不解决内存屏障问题，反而误导编译器 - 在 x64 下慎用内联汇编（MSVC 已废弃），优先用
__readgsqword等 intrinsic 函数 - 测试时关闭 CFG（项目属性 → 高级 → 控制流防护 = 否），否则
NtGlobalFlag检查可能触发异常
真正难的不是读一个字节，而是让这个读操作在各种调试器、各种 Windows 版本、各种编译配置下都不被绕过或误报。多数人栽在没意识到 BeingDebugged 是个“易伪造字段”，而不是开关。
