逆向工程报告撰写：漏洞报告模板、分析报告结构、证据链整理
做逆向分析这么多年，我见过太多人栽在最后一步——报告撰写上。你辛辛苦苦逆向了一个App，找到了漏洞，结果报告写得乱七八糟，开发看不懂，领导不满意，甚至漏洞被驳回。说白了，报告写得好不好，直接决定了你的工作价值能不能被认可。
我个人习惯把报告撰写看作「证据链的最终呈现」。你想想看，逆向分析就像破案，你找到了线索，推理出了真相，但如果没有一份清晰的报告，谁能信服？今天我就把这几年的经验梳理一下，给你一套可以直接用的模板和思路。
一、漏洞报告模板：让开发一眼看懂
漏洞报告的核心目标是什么？是让开发人员能快速复现、理解并修复。我见过最糟糕的报告，就一句话「发现一个漏洞」，连个截图都没有。嗯，这种报告基本等于白写。
下面是我常用的漏洞报告模板，你直接拿去用：
# 漏洞标题：[严重程度] [漏洞类型] - [模块/功能]
## 基本信息
- 漏洞编号：VULN-2024-XXXX
- 发现时间：2024-XX-XX
- 应用版本：vX.X.X (build XXXX)
- 测试环境：Android 14 / iOS 17.2
- 漏洞类型：SQL注入 / 越权访问 / 敏感信息泄露 / ...
## 漏洞描述
（用一两句话说明漏洞是什么，能造成什么影响）
示例：登录接口未对用户输入做过滤，导致SQL注入攻击，可获取所有用户信息。
## 复现步骤
1. 打开App，进入登录页面
2. 在用户名输入框输入：' OR 1=1 --
3. 密码随意输入
4. 点击登录，成功绕过认证
## 影响范围
- 受影响接口：/api/user/login
- 受影响版本：v1.0.0 - v2.3.1
- 潜在影响：用户数据泄露、账户被盗
## 修复建议
- 对用户输入进行参数化查询
- 添加输入校验和过滤
- 建议使用ORM框架
## 附件
- 截图：login_bypass.png
- 抓包数据：login_request.pcap
- 视频演示：exploit_demo.mp4
关键点：复现步骤一定要写清楚，最好精确到「点击哪个按钮」「输入什么内容」。我曾经因为少写了一步「先点击设置再返回」，开发复现了半小时没成功，最后发现是操作顺序问题。
二、分析报告结构：从入口到结论
分析报告和漏洞报告不一样。漏洞报告是「点」，分析报告是「面」。一份完整的逆向分析报告，应该让读者跟着你的思路走一遍，最后得出和你一样的结论。
我习惯把分析报告分成这几个部分：
- 概述：一句话说明分析目标、分析范围、主要发现
- 分析环境：工具、设备、系统版本
- 分析过程：从入口到关键逻辑的完整路径
- 关键发现：每个漏洞/问题的详细说明
- 证据链：截图、代码片段、抓包数据
- 总结与建议：整体风险评估和修复优先级
举个例子，我之前分析一个金融类App，报告结构是这样的：
# 某金融App逆向安全分析报告
## 1. 概述
目标：分析XX金融App v3.2.1的登录模块安全性
范围：登录流程、Token管理、本地存储
主要发现：发现3个高危漏洞，2个中危漏洞
## 2. 分析环境
- 设备：Pixel 6 (Android 14)
- 工具：Frida 16.0, Jadx 1.5, Burp Suite 2024
- 抓包方式：VPN + 代理
## 3. 分析过程
### 3.1 入口分析
从登录页面开始，抓取登录请求...
### 3.2 Token生成逻辑
通过Frida Hook发现Token生成算法...
### 3.3 本地存储检查
发现SharedPreferences中存储了明文密码...
## 4. 关键发现
### 4.1 高危：密码明文存储
- 位置：/data/data/com.xx.app/shared_prefs/login.xml
- 证据：截图 + 代码片段
- 影响：设备被root后可直接读取密码
### 4.2 中危：Token未设置过期时间
- 位置：登录接口返回的Token字段
- 证据：抓包数据
- 影响：Token泄露后可永久使用
## 5. 证据链整理
（见下一节）
## 6. 总结与建议
- 立即修复：密码加密存储
- 建议修复：Token添加过期时间
- 长期建议：引入安全加固方案
我的习惯：在写分析过程时，我会把每一步的「为什么这么做」也写进去。比如「为什么先Hook这个函数？因为从抓包数据看，Token是在这里生成的」。这样读者能理解你的分析思路，而不是只看结果。
三、证据链整理：让结论无可辩驳
证据链是报告的灵魂。没有证据链，你的分析就是空口无凭。我见过有人写「发现一个漏洞」，结果连个截图都没有，开发直接回了一句「无法复现」就把报告打回来了。
证据链应该包含哪些东西？我列个清单：
| 证据类型 | 具体内容 | 示例 |
|---|---|---|
| 截图 | 关键页面的操作截图、漏洞触发后的效果 | 登录绕过后的后台页面 |
| 抓包数据 | 请求/响应的完整内容，包括Header和Body | 包含Token的HTTP请求 |
| 代码片段 | 反编译后的关键代码，标注出漏洞位置 | SQL注入点的SQL语句拼接 |
| 日志输出 | Frida Hook的输出、Logcat日志 | Hook到的函数参数值 |
| 视频演示 | 完整的漏洞复现过程（可选） | 从打开App到漏洞触发的全过程 |
整理证据链时，我有个原则：每个结论至少要有两个独立证据支撑。比如你说「密码明文存储」，那就要有截图证明文件位置，还要有代码片段证明存储逻辑。
避坑指南：我曾经在整理证据链时，只截了一张图，结果开发说「你这个截图可能是PS的」。从那以后，我每次都会加上抓包数据的原始时间戳，或者录个短视频。证据越原始越好，越完整越好。
四、知识体系图：报告撰写的核心逻辑
下面这张图是我总结的报告撰写核心流程。说白了，就是从「发现漏洞」到「呈现证据」再到「推动修复」的完整链路。
五、实战经验：我踩过的坑
最后分享几个我踩过的坑，希望能帮你少走弯路：
- 别偷懒不截图：我曾经觉得「这个漏洞很明显，不用截图了吧」，结果开发说「我没看到啊」。从那以后，我每个步骤都截图，哪怕只是点了一个按钮。
- 证据要带时间戳：截图和抓包数据最好带上系统时间，这样能证明你是「实时」发现的，不是事后编造的。
- 代码片段要标注行号：反编译后的代码可能很长，你直接贴一大段，开发根本不想看。标注出关键行，比如「第45行存在SQL注入」，开发一眼就能定位。
- 修复建议要具体：别写「请修复这个漏洞」，要写「建议使用参数化查询，参考OWASP的SQL注入防护方案」。开发看了就知道怎么改。
我的小技巧：写报告时，我会先写「证据链」部分，再写「漏洞描述」。因为证据链是客观事实，先整理好证据，漏洞描述自然就清晰了。反过来写容易漏掉关键证据。
好了，关于报告撰写就聊这么多。记住一句话：报告不是写给自己看的，是写给开发、领导、客户看的。让他们能看懂、能复现、能修复，你的报告才算合格。
公众号:蓝海资料掘金营，微信deep3321