检测“是否被反汇编”不可行，真正可行的是检测调试器附加或可疑调试上下文；IsDebuggerPresent易被绕过，单一PEB字段检测无效，需多位置、多线程、强耦合业务逻辑的副作用检测。
单纯检测“是否被反汇编”在技术上不可行——反汇编是静态行为，不修改进程状态，也没有系统痕迹可查；你真正能检测的，是“是否正被调试器附加”或“是否处于可疑调试上下文”。
IsDebuggerPresent 为什么一用就失效
它只读 PEB->BeingDebugged（x64 下 gs:[60h] + 2），这个字节在调试器 attach 后常被立刻清零。逆向者只需在入口点前 patch 返回值、hook LdrInitializeThunk、或用 SetThreadContext 开 TF 位单步执行，IsDebuggerPresent 就完全失能。
- 调用后返回
false不代表安全，可能只是调试器更安静了 - 函数名明晃晃出现在导入表（IAT），是逆向第一眼定位点
- Release 模式下即使被调试，它也可能返回
false—— 因为调试器根本没动那个字节
绕过 PEB 字段检测的常见手法
靠读 BeingDebugged 或 NtGlobalFlag 单一字段，等同于设个门牌写“此房有人”，但贼早把门牌摘了。
-
NtGlobalFlag & 0x70确实可疑（含FLG_ENABLE_CSRDEBUG等），但现代调试器启动后常主动清除该标志 - 直接用
__readgsqword(0x60)取 PEB 地址比调 API 更隐蔽，但若调试器已篡改整个 PEB 结构，照样白读 - 用
CheckRemoteDebuggerPresent(GetCurrentProcess(), &b)多绕一层，但底层仍是读 PEB，且失败时GetLastError()可能暴露异常权限行为
真正难绕过的检测要带副作用和上下文感知
没有“银弹”，只有让检测逻辑难定位、难模拟、且触发后影响执行流。关键不是多加几条判断，而是让攻击者不敢轻易 patch 或跳过。
- 在关键校验点插
__debugbreak()，配合 SEH：__except(EXCEPTION_EXECUTE_HANDLER)捕获成功，基本说明有调试器接管了异常——注意：Release 下它不中断，但若进程已被附加，SEH 仍会进 except 块 - 用 inline asm 手动取 PEB、读
[rax+2]和[rax+0bch]，避免 IAT 泄露；但必须确保该段代码不被编译器优化掉（加#pragma optimize("", off)或volatile辅助） - RDTSC 时钟差检测有误报风险（CPU 频率波动、中断干扰），阈值设
>= 21很脆弱；更适合做辅助信号，而非主判据
最易被忽略的一点：所有检测都应在多个分散位置、不同线程、非主线程中触发，且与业务逻辑强耦合（比如解密某段关键代码前校验）。否则，逆向者一个断点跳过整个检测函数，就等于没写。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
