# 安全/逆向/渗透技术文档模板

本文件提供逆向工程、渗透测试、漏洞分析等安全类项目的文档模板。任务完成后，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（如果某部分确实未完成，标注"待补充"并说明原因）
- 关键发现必须有证据支撑（命令输出、截图描述、代码片段）
- 复现步骤必须让第三方能独立重现