动态调试的四个断点：API、内存、条件与硬件

加壳、混淆、虚拟机检测都会让静态分析失效，这时候动态调试更直接：让它跑起来，在关键位置停下。

断点的选择决定了效率：在「数据被使用的地方」下断，比在「代码入口」下断有用得多。

先说结论

优先在数据使用点下断（内存访问），其次 API 断点，最后单步。

• API 断点适合看参数与返回值
• 内存断点适合追关键数据流
• 条件断点减少无关命中
• 硬件断点可绕过部分反调试检测

漏洞是怎么产生的

动态调试的产出应该是「一条可复现的路径」：输入什么、在哪停、看到了什么。

反调试手段（IsDebuggerPresent、时间差检测、父进程检测）需要先识别再处理。

修复与验证

修复不是改一行代码，而是四件事一起做：

• 确定目标行为：登录校验、序列号、协议加密
• 定位关键 API（如字符串比较、加密函数）下断
• 在关键数据地址下内存访问断点
• 记录调用栈与寄存器，还原数据流
• 遇到反调试先识别类型，再选择绕过方式

攻击面与检测点

按影响面排序，先修影响最大的：

几个容易踩的坑

下面这些是最常见的错误做法：

• 一上来单步几千行：效率极低
• 忽略多线程：断在错误线程上
• 不保存现场：崩了要重来
• 与反调试硬碰：先识别再绕过

写在最后

动态调试是「用运行时间换理解速度」，目标始终是搞清楚逻辑，而不是炫技。

安全不是一次加固，是持续的假设：假设输入不可信、假设边界会破、假设有人会看错。