Files

T

yhc 5d73e05e89 fix(workflow): IAT repair iron rule + vuln thin overlay (issue #65 )

- 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

2026-08-12 11:57:38 +08:00

8.0 KiB

Raw Blame History

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

本文件提供逆向工程、渗透测试、漏洞分析等安全类项目的文档模板。任务完成后，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. 逆向工程报告模板

# [目标名称] 逆向分析报告

> 分析日期：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. 附件


---

---

## 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. ...

**证据**：


**修复建议**：

## 5. 攻击路径

<!-- 如果有完整攻击链，画出路径 -->

入口 → 信息收集 → 漏洞利用 → 权限提升 → 目标达成


## 6. 工具与环境

| 工具 | 版本 | 用途 |
|------|------|------|
| | | |

## 7. 修复建议总结

| 优先级 | 建议 |
|--------|------|
| P0 | |
| P1 | |
| P2 | |

## 8. 附录

<!-- 完整 payload、脚本、配置文件等 -->

3. CTF Writeup 模板

# [比赛名] - [题目名] 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 算法类型

3.2 参数构造

3.3 密钥来源

4. 本地复现代码

// Node.js 复现

5. 验证结果

6. 反爬/风控注意事项


---

## 5. 文档输出规范

### 输出位置

- 文档默认输出到**用户当前项目目录**（不是 skill 包目录）
- 文件名格式：`YYYY-MM-DD_[类型]-[目标简称]-report.md`
- 如果用户项目有 `docs/` 目录，优先放在 `docs/` 下

### 输出时机

AI 在以下时机自动调用本 skill 生成文档：

1. 逆向任务完成，已产出核心结论
2. 渗透测试完成，已发现并验证漏洞
3. CTF 题目解出，已拿到 flag
4. 用户明确要求"写一份报告/文档"

### 质量要求

- 所有代码块必须可直接运行或有明确上下文
- 不要有 placeholder/TODO（如果某部分确实未完成，标注"待补充"并说明原因）
- 关键发现必须有证据支撑（命令输出、截图描述、代码片段）
- 复现步骤必须让第三方能独立重现

8.0 KiB Raw Blame History Unescape Escape