逆向里最扫兴的事，是程序突然知道你在调试它
逆向做到一定阶段，你会遇到一种特别扫兴的情况：调试器刚挂上，程序「啪」地退了，或者行为突然变得跟正常跑完全不一样。不是你操作错了，是目标程序本身就在主动探测自己是不是正被调试。这层互相试探，就是所谓「反调试」。
Windows 上最经典的一招
进程控制块（PEB）里有个字段 BeingDebugged，操作系统在程序被调试时会把它置 1。程序自己读一下就知道。Windows 甚至给了个现成包装：
#include <windows.h>
if (IsDebuggerPresent()) {
ExitProcess(0); // 发现被调试，直接退出
}
就这么几行，就能劝退大部分随手挂调试器的人。对抗它的办法也直接：在调试器里把 PEB 的 BeingDebugged 改回 0，或者 patch 掉这条判断的分支。但道高一尺——对方可以不止查一次，可以隔几秒查一次，甚至可以读 PEB 的 NtGlobalFlag、堆头部标记这些更隐蔽的痕迹。
Linux 下靠 ptrace 自我占位
Linux 程序常用的套路是用 ptrace 把自己「占上」：
if (ptrace(PTRACE_TRACEME, 0, 0, 0) == -1) {
// 已经被别人 trace 了（比如调试器），退出
exit(1);
}
一个进程只能被一个调试器 attach。程序启动时先对自己发一个 TRACEME，如果返回 -1，说明已经有调试器在上面了。这是很低成本的一招，所以很多加固壳都这么干。破解方式通常是在更早的入口（或借助调试器本身的特性）绕过，或者在 loader 阶段把这段调用 nop 掉。
还有几类"软"检测
除了上面硬核的，还有些靠「间接证据」反调试的：
- 时间差：调试时单步执行会让某段代码运行时间异常长。程序在关键逻辑前后取时间戳，差太多就怀疑被调试。
- 断点痕迹：软件断点本质是改指令首字节为 0xCC（int3）。扫描自己的代码段有没有 0xCC，能发现下断点的位置。
- 父进程检查：正常双击运行的程序，父进程是 explorer；被调试器启动时父进程是调试器，查一下就能分辨。
反调试不是单行防线，而是一张网。你 patch 掉 IsDebuggerPresent 的检查，它可能还有时间差、还有断点扫描。所以抗反调试往往不是「改一处」，而是「把这张网里你能发现的节点一个个拔掉」，或者用硬件断点、内核级调试器来规避软件层的探测。
说到底，反调试和抗反调试是场没终点的猫鼠游戏。你永远不知道对面还藏了几手，只能一边被「啪」地踢出来，一边在失败后回头找：这次它又是靠哪根弦发现我的。每一次成功绕过，都是对操作系统运行机制更深的那么一点理解。
