ctf-writeup

CTF解题报告生成器

为已解决的挑战生成标准化的提交式CTF解题报告。

默认行为：

• 在比赛进行期间，优化速度、清晰度和可复现性
• 保持解题报告足够简短，以便队友或组织者快速验证解决方案
• 始终生成submission风格的解题报告
• 优先提供一个从挑战数据到最终flag的完整解决脚本

工作流程

步骤1：收集信息

从当前会话、挑战文件和用户输入中收集以下内容：

1. 挑战元数据 — 名称、CTF赛事、类别、难度、分值、flag格式
2. 解决产物 — 利用脚本、payload、截图、命令输出
3. 时间线 — 关键步骤、死胡同、转折点

# 扫描利用脚本和产物
find . -name '*.py' -o -name '*.sh' -o -name 'exploit*' -o -name 'solve*' | head -20
# 检查输出文件中的flag
grep -rniE '(flag|ctf|eno|htb|pico)\{' . 2>/dev/null

步骤2：生成解题报告

将解题报告文件写为writeup.md（或writeup-<challenge-name>.md），使用下面的提交模板。

---

模板

提交格式

---
title: "<挑战名称>"
ctf: "<CTF赛事名称>"
date: YYYY-MM-DD
category: web|pwn|crypto|reverse|forensics|osint|malware|misc
difficulty: easy|medium|hard
points: <数字>
flag_format: "flag{...}"
author: "<你的名字或团队>"
---

# <挑战名称>

## 摘要

<1-2句话：挑战内容及核心技术。保持直接。>

## 解决方案

### 步骤1：<操作>

<用3-8行简短说明关键观察。保持直接。>

\`\`\`python
<一个完整的解决脚本，从提供的挑战数据到打印最终flag>
\`\`\`

### 步骤2：<操作>（可选）

<仅在第二个简短步骤确实有助于可读性时添加，例如将核心观察与最终验证分开。>

### 步骤3：<操作>（可选）

<仅在挑战确实需要时使用。保持总步骤数较少。>

## Flag

\`\`\`
flag{example_flag_here}
\`\`\`

指导原则：

• 优先使用1-3个简短步骤
• 代码保持为最小的完整解决脚本
• 不要将“恢复秘密”、“推导密钥”和“解密flag”拆分为多个部分片段
• 脚本应从挑战数据开始，以打印flag结束
• 避免冗长的背景部分
• 除非解释关键转折点，否则避免死胡同
• 避免多个替代解决方案；选择一条清晰的路径
• 仅当用户明确要求时才编辑flag

---

最佳实践检查清单

在最终确定解题报告之前，请验证：

• [ ] 元数据完整 — 标题、CTF、日期、类别、难度、分值、作者均已填写
• [ ] flag处理符合要求 — 保留真实flag，除非用户要求编辑
• [ ] 步骤可复现 — 读者可以按照你的解题报告复现解决方案
• [ ] 代码可运行 — 利用脚本包含所有导入、正确的变量名和注释
• [ ] 无敏感数据 — 无真实凭据、API密钥或私有基础设施细节
• [ ] 长度保持简洁 — 解题报告足够简短，便于快速审阅
• [ ] 工具和版本已注明 — 如果行为依赖于特定工具版本，请注明
• [ ] 适当归属 — 致谢队友、参考的解题报告或关键工具
• [ ] 语法和格式 — 标题级别一致，代码块带有语言标签

质量指南

应做：

• 仅解释足够快速验证的内容
• 包含一个完整的解决路径，而非多个替代路线
• 包含一个完整的脚本，一直运行到最终flag
• 显示实际输出（如果很长则截断），以证明方法有效
• 为代码块添加语言标签（python、bash、sql等）
• 将主要路径放在前面，以便读者快速验证

不应做：

• 不加解释地复制粘贴原始终端转储
• 粘贴多个部分片段，迫使读者重建最终解决方案
• 在最终解题报告中留下占位文本
• 包含不相关的题外话，对解决方案无贡献
• 假设读者了解特定的挑战设置

挑战

$ARGUMENTS