漏洞分析方法

一个下午，漏洞我盯着屏幕上的分析方法十六进制转储，咖啡已经凉透。漏洞目标程序在特定输入下崩溃了，分析方法但崩溃点离真正的漏洞漏洞源头隔了七层调用。这种挫败感每个做安全的分析方法人都不陌生——漏洞分析不是看 crash 在哪，而是漏洞问为什么在那。

先说最笨也最可靠的分析方法方法：补丁对比。厂商发了个安全更新，漏洞你拿旧版本和新版本二进制文件做 diff。分析方法不用猜，漏洞直接看代码改了什么。分析方法某次我分析一个开源 FTP 服务器的漏洞漏洞，补丁只加了一行长度检查，分析方法但就是漏洞这行缺失让攻击者能溢出堆缓冲区。对比完你就知道漏洞长什么样，然后顺着调用链往回追，找到触发条件。这个方法效率极高，前提是你得有新旧两个版本的文件。

没有补丁可对比？那就上模糊测试（fuzzing）。但瞎喂随机数据是浪费电。真正的做法是先做代码覆盖率分析，用工具（比如 AFL 或 libFuzzer）记录哪些分支被走到，然后针对性地变异输入。我见过一个案例，测试人员对 PDF 解析器跑了三天三夜，最后崩溃样本出现在一个处理 JPEG2000 图像的子模块里——那模块没人注意过，但它的错误处理代码用了不安全的 `sprintf`。模糊测试的价值不在于找到崩溃，而在于给你一个可复现的起点。

拿到崩溃样本后，别急着开调试器。先做静态分析。用 IDA 或 Ghidra 看反汇编代码，找危险的函数调用：`strcpy`、`memcpy`、`sprintf`、`malloc` 后直接使用。这些是经典漏洞温床。但静态分析有个陷阱——编译器优化会改变代码结构，你看到的汇编可能和源码逻辑差很远。这时候要结合动态调试，下断点看寄存器状态，确认哪些变量是攻击者可控的。

有个技巧很多人忽略：污点追踪。把输入数据标记为“污点”，然后在程序执行过程中跟踪这些数据流向哪些内存地址、哪些运算。如果污点数据到达了程序计数器（PC）或者函数指针，恭喜，你找到了可利用的漏洞。现代工具如 Pin 或 DynamoRIO 能自动化这个过程，但手动做一遍更能理解细节。一次我分析网络服务漏洞，污点数据从 socket 接收开始，经过 base64 解码，最终到达一个跳转表索引——攻击者能控制跳转目标，这就是任意代码执行。

别忘了逻辑漏洞。这类漏洞没有内存破坏，纯粹是业务逻辑缺陷。比如支付流程里，你先加购物车，再改价格参数，服务器没校验。分析这类漏洞不能靠调试器，得靠读代码和画流程图。我见过一个电商平台，优惠券使用次数在服务端 session 里计数，但攻击者每次请求都新建 session，优惠券永远不过期。这种漏洞用自动化工具扫不出来，得人肉去理解状态管理。

最后一个建议：分析漏洞时记录每一步假设和验证结果。我习惯用文本文件随手记，不整理格式。假设 A，验证——失败；假设 B，验证——部分成功，但边界条件不对。这些笔记在写报告和复现时价值巨大。

漏洞分析本质上是逆向思维训练——你得像攻击者一样思考，但用工程师的方法论去验证。工具会过时，但思路不会：先找差异，再找入口，然后追踪数据流，最后确认影响。做到第六个漏洞的时候，你会开始觉得这些步骤自然而然，不需要刻意套用。那时候，你才算真正入门了。