yhc
5d73e05e89
- Map reporter six-phase malware RE flow into re-agent-workflow with IAT repair fail-fast (E-iat-repair-fail -> dynamic API breakpoints) - Equivalent import anchors for .NET; E-exports for DLL/SYS; clean IAT and sandbox no-behavior side paths - Wire radare2/ida/malware hard gates + RULES/obedience rebuttals - Add optional thin vuln report overlay (not a 3rd default full flavor) - Extend verify-routing-coherence assertions; smoke+verify x3 pass
349 lines
8.0 KiB
Markdown
349 lines
8.0 KiB
Markdown
# 安全/逆向/渗透技术文档模板
|
||
|
||
本文件提供逆向工程、渗透测试、漏洞分析等安全类项目的文档模板。任务完成后，AI 应在用户项目目录下新建文档并按对应模板输出。
|
||
|
||
---
|
||
|
||
## 0. Evidence Chain（所有安全报告 MUST 包含）
|
||
|
||
> 契约全文：`skills/ops/evidence-finding-path.md`
|
||
> Case 目录：`work/<case>/`（`case-init.ps1`）
|
||
|
||
报告正文中 **MUST** 含以下章节（可并入「核心发现」但字段不得省略）：
|
||
|
||
### 0.1 Scope 摘要
|
||
- 链到 `scope.md`：`auth` / `in_scope` / `network_profile`
|
||
- 无 scope → 不得宣称任务完成
|
||
|
||
### 0.2 Evidence
|
||
至少 1 条，字段：`E-id` / `source_ref` / `repro_command` / `content_hash|n/a`
|
||
|
||
### 0.3 Findings
|
||
每条：`F-id` / `severity|n/a_re` / `evidence_ids` / `confidence` / `location` / `status`
|
||
|
||
### 0.4 Path
|
||
至少 1 条 `P-id`：`path_type=attack|callflow|solve`，步骤可挂 E/F
|
||
|
||
### 0.5 Timeline 摘要
|
||
链到 `timeline.md` 或嵌入关键 3–10 条追加记录
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 0.6 Vendor structure overlay（专业厂商报告结构）
|
||
|
||
> 全文规则：`references/vendor-report-rules.md`（Issue #65）
|
||
> **MUST** 在生成安全类正式报告时读取并选型；**只抽结构，禁止抄录厂商原文/IOC 实例**。
|
||
|
||
| Flavor / Overlay | 场景 | 骨架一句话 |
|
||
|------------------|------|------------|
|
||
| `malware` | 明确恶意样本/普通木马/白加黑 | 火绒式：概述→流程→样本分析→应急处置→IOC |
|
||
| `apt` | APT/战役/多阶段链 | 卡巴式：摘要→感染链→调查→Interesting findings→技术分析→检测缓解→IOC |
|
||
| `flavor = null` | 普通逆向/渗透/CTF/JS 签名 | 本节任务模板 + 适用的 Base 通用元素 |
|
||
| thin `vuln` | 漏洞/补丁/CVE 技术分析（显式） | 概述→影响/复现→崩溃与补丁分析→防护建议 |
|
||
|
||
**通用元素（G1–G7）摘要**：G1 执行摘要 MUST · G2 Scope MUST · G3 E/F/P MUST · G4 IOC 仅 `malware`/`apt` MUST · G5 建议在 `malware`/`apt`/`vuln` MUST · G6 附录 SHOULD · G7 ATT&CK 在 `apt` MUST
|
||
|
||
选型与章节顺序以 `vendor-report-rules.md` 为准；与 §0.1–0.5 冲突时 **Evidence 契约优先**。
|
||
|
||
## 1. 逆向工程报告模板
|
||
|
||
```markdown
|
||
# [目标名称] 逆向分析报告
|
||
|
||
> 分析日期：YYYY-MM-DD
|
||
> 分析人员：[AI / 人工]
|
||
> 工具链：[jadx / IDA / radare2 / Frida / ...]
|
||
|
||
## 1. 目标概述
|
||
|
||
| 属性 | 值 |
|
||
|------|---|
|
||
| 文件名 | |
|
||
| 文件类型 | APK / ELF / PE / Mach-O / ... |
|
||
| 大小 | |
|
||
| MD5 | |
|
||
| SHA256 | |
|
||
| 包名/入口 | |
|
||
|
||
## 2. 分析目标
|
||
|
||
<!-- 本次逆向要回答的核心问题 -->
|
||
|
||
## 3. 静态分析
|
||
|
||
### 3.1 基本信息
|
||
<!-- 架构、编译器、保护机制、字符串特征 -->
|
||
|
||
### 3.1.1 导入表 / 依赖（二进制 MUST）
|
||
<!-- 写入 E-imports / E-triage-imports 摘要；失败也要记 Evidence，禁止跳过 -->
|
||
|
||
### 3.2 关键函数/类
|
||
<!-- 列出定位到的关键逻辑，附代码片段 -->
|
||
|
||
### 3.3 加密/签名算法
|
||
<!-- 如果涉及加密，说明算法、密钥来源、参数构造 -->
|
||
|
||
## 4. 动态分析
|
||
|
||
### 4.1 Hook 记录
|
||
<!-- Frida / xposed / 其他 hook 的目标和结果 -->
|
||
|
||
### 4.2 运行时行为
|
||
<!-- 网络请求、文件操作、进程行为 -->
|
||
|
||
## 5. 核心发现
|
||
|
||
<!-- 用编号列出关键结论 -->
|
||
|
||
1. ...
|
||
2. ...
|
||
3. ...
|
||
|
||
## 6. 复现步骤
|
||
|
||
<!-- 让其他人能重现你的分析结果 -->
|
||
|
||
```bash
|
||
# 关键命令
|
||
```
|
||
|
||
## 7. 遗留问题
|
||
|
||
<!-- 没有完全解决的点 -->
|
||
|
||
## 8. 附件
|
||
|
||
<!-- hook 脚本、解密代码、截图等 -->
|
||
```
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 1b. 恶意软件 / APT 报告（厂商 flavor）
|
||
|
||
当任务为恶意软件分析、病毒报告、APT/战役分析时，**不要**仅用上面「逆向工程」骨架交差；普通逆向任务保持原模板，不自动选择 vendor flavor：
|
||
|
||
1. 读 `vendor-report-rules.md` 选 `malware` 或 `apt`
|
||
2. 按对应章节顺序输出
|
||
3. 仍 **MUST** 含 §0 Evidence 链；`malware` / `apt` flavor 另 **MUST** 含 IOC 表
|
||
4. 二进制样本的静态分析 **MUST** 含导入表 Evidence（与 radare2/ida/malware 硬门一致）
|
||
|
||
## 1c. 漏洞技术分析报告（thin `vuln` overlay）
|
||
|
||
当任务为 **OS/组件漏洞、补丁对比、CVE 技术分析**，或用户明确要求「漏洞技术分析报告」时：
|
||
|
||
1. 读 `vendor-report-rules.md` §3b，使用 thin `vuln` 章节顺序（**不是** malware/apt 全文 flavor）
|
||
2. **MUST** 含：影响范围、授权内复现或明确 n/a、崩溃/根因或补丁差异 Evidence、防护/补丁建议
|
||
3. **MUST** 含 §0 Evidence→Finding→Path
|
||
4. **MUST NOT** 在未授权目标上扩展 PoC，或抄录外部利用武器化细节
|
||
|
||
## 2. 渗透测试报告模板
|
||
|
||
```markdown
|
||
# [目标] 渗透测试报告
|
||
|
||
> 测试日期：YYYY-MM-DD
|
||
> 测试范围：[URL / IP / 应用名]
|
||
> 授权状态：[已授权 / CTF / 学习环境]
|
||
|
||
## 1. 执行摘要
|
||
|
||
<!-- 一段话总结：测试了什么、发现了什么、风险等级 -->
|
||
|
||
## 2. 测试范围
|
||
|
||
| 项目 | 详情 |
|
||
|------|------|
|
||
| 目标 | |
|
||
| 测试类型 | 黑盒 / 灰盒 / 白盒 |
|
||
| 测试时间 | |
|
||
| 工具 | |
|
||
|
||
## 3. 发现汇总
|
||
|
||
| # | 漏洞名称 | 风险等级 | 状态 |
|
||
|---|---------|---------|------|
|
||
| 1 | | 高/中/低/信息 | 已验证/待确认 |
|
||
|
||
## 4. 漏洞详情
|
||
|
||
### 4.1 [漏洞名称]
|
||
|
||
**风险等级**：高 / 中 / 低
|
||
|
||
**描述**：
|
||
|
||
**影响**：
|
||
|
||
**复现步骤**：
|
||
|
||
1. ...
|
||
2. ...
|
||
3. ...
|
||
|
||
**证据**：
|
||
|
||
```
|
||
<!-- 请求/响应/截图/payload -->
|
||
```
|
||
|
||
**修复建议**：
|
||
|
||
## 5. 攻击路径
|
||
|
||
<!-- 如果有完整攻击链，画出路径 -->
|
||
|
||
```
|
||
入口 → 信息收集 → 漏洞利用 → 权限提升 → 目标达成
|
||
```
|
||
|
||
## 6. 工具与环境
|
||
|
||
| 工具 | 版本 | 用途 |
|
||
|------|------|------|
|
||
| | | |
|
||
|
||
## 7. 修复建议总结
|
||
|
||
| 优先级 | 建议 |
|
||
|--------|------|
|
||
| P0 | |
|
||
| P1 | |
|
||
| P2 | |
|
||
|
||
## 8. 附录
|
||
|
||
<!-- 完整 payload、脚本、配置文件等 -->
|
||
```
|
||
|
||
---
|
||
|
||
## 3. CTF Writeup 模板
|
||
|
||
```markdown
|
||
# [比赛名] - [题目名] Writeup
|
||
|
||
> 分类：Web / Reverse / Pwn / Crypto / Misc / Forensics
|
||
> 难度：Easy / Medium / Hard
|
||
> 分值：N pts
|
||
> 解题时间：
|
||
|
||
## 题目描述
|
||
|
||
<!-- 原题描述 -->
|
||
|
||
## 解题思路
|
||
|
||
### 第一步：信息收集
|
||
<!-- 观察到了什么 -->
|
||
|
||
### 第二步：漏洞/突破口
|
||
<!-- 找到了什么关键点 -->
|
||
|
||
### 第三步：利用
|
||
<!-- 怎么利用的 -->
|
||
|
||
## 关键代码/Payload
|
||
|
||
```python
|
||
# exploit code
|
||
```
|
||
|
||
## Flag
|
||
|
||
```
|
||
flag{...}
|
||
```
|
||
|
||
## 踩坑记录
|
||
|
||
<!-- 走过的弯路 -->
|
||
|
||
## 知识点
|
||
|
||
<!-- 这道题涉及的知识点，方便后续复习 -->
|
||
```
|
||
|
||
---
|
||
|
||
## 4. JS/Web 签名逆向报告模板
|
||
|
||
```markdown
|
||
# [站点/应用] 签名参数逆向报告
|
||
|
||
> 分析日期：YYYY-MM-DD
|
||
> 目标接口：[URL]
|
||
> 签名字段：[字段名]
|
||
|
||
## 1. 目标请求
|
||
|
||
```http
|
||
POST /api/xxx HTTP/1.1
|
||
Host: example.com
|
||
|
||
param1=xxx&sign=<目标字段>
|
||
```
|
||
|
||
## 2. 定位过程
|
||
|
||
### 2.1 断点/Hook 方式
|
||
<!-- 怎么找到签名生成位置的 -->
|
||
|
||
### 2.2 调用栈
|
||
<!-- 关键调用链 -->
|
||
|
||
## 3. 算法还原
|
||
|
||
### 3.1 算法类型
|
||
<!-- HMAC-SHA256 / AES / 自定义 / ... -->
|
||
|
||
### 3.2 参数构造
|
||
<!-- 哪些字段参与签名、排序规则、分隔符 -->
|
||
|
||
### 3.3 密钥来源
|
||
<!-- 硬编码 / 接口返回 / 时间戳派生 / ... -->
|
||
|
||
## 4. 本地复现代码
|
||
|
||
```javascript
|
||
// Node.js 复现
|
||
```
|
||
|
||
## 5. 验证结果
|
||
|
||
<!-- 用复现代码生成的签名与实际请求对比 -->
|
||
|
||
## 6. 反爬/风控注意事项
|
||
|
||
<!-- 频率限制、设备指纹、环境检测等 -->
|
||
```
|
||
|
||
---
|
||
|
||
## 5. 文档输出规范
|
||
|
||
### 输出位置
|
||
|
||
- 文档默认输出到**用户当前项目目录**（不是 skill 包目录）
|
||
- 文件名格式：`YYYY-MM-DD_[类型]-[目标简称]-report.md`
|
||
- 如果用户项目有 `docs/` 目录，优先放在 `docs/` 下
|
||
|
||
### 输出时机
|
||
|
||
AI 在以下时机自动调用本 skill 生成文档：
|
||
|
||
1. 逆向任务完成，已产出核心结论
|
||
2. 渗透测试完成，已发现并验证漏洞
|
||
3. CTF 题目解出，已拿到 flag
|
||
4. 用户明确要求"写一份报告/文档"
|
||
|
||
### 质量要求
|
||
|
||
- 所有代码块必须可直接运行或有明确上下文
|
||
- 不要有 placeholder/TODO（如果某部分确实未完成，标注"待补充"并说明原因）
|
||
- 关键发现必须有证据支撑（命令输出、截图描述、代码片段）
|
||
- 复现步骤必须让第三方能独立重现
|