CTF 解出题目后如何写一份标准化、可快速复核的提交式…

在 CTF 比赛解题完成后，需要把解题步骤、工具与经验整理成一份简洁、可复现、便于队友或主办方快速验证的 submission 风格 writeup。

适用场景

解决思路

1. 按默认行为产出：比赛进行中优先速度、清晰与可复现；篇幅要短到队友或主办方能快速验证；始终产出 submission 风格 writeup；优先给出从题目数据直通最终 flag 的一份完整解题脚本。
2. 第 1 步收集信息：从当前会话、题目文件和用户输入中收集题目元数据（名称、CTF 赛事、类别、难度、分值、flag 格式）。
3. 第 1 步收集信息：收集解题产物（exploit 脚本、payload、截图、命令输出）。
4. 第 1 步收集信息：收集时间线（关键步骤、走过的死胡同、思路转折点）。
5. 用 `find . -name '*.py' -o -name '*.sh' -o -name 'exploit*' -o -name 'solve*' | head -20` 扫描 exploit 脚本与产物。
6. 用 `grep -rniE '(flag|ctf|eno|htb|pico)\{' . 2>/dev/null` 在输出文件中查找 flag。
7. 第 2 步生成 writeup：把 writeup 写成 `writeup.md`（或 `writeup-<challenge-name>.md`），使用 submission 模板。
8. 模板 frontmatter 填全：title（题目名）、ctf（赛事名）、date（YYYY-MM-DD）、category（web|pwn|crypto|reverse|forensics|osint|malware|misc|ai-ml）、difficulty（easy|medium|hard）、points、flag_format（如 "flag{...}"）、author（姓名或队伍）。
9. 正文结构：`# <Challenge Name>`，下接 `## Summary`，用 1-2 句话直说题目是什么、核心技巧是什么。
10. 正文结构：`## Solution` 下用 `### Step 1: <Action>` 等小节，用 3-8 行短句说明关键观察，随后附一段完整的 python 解题脚本，从给定题目数据一路打印出最终 flag。
11. 正文结构：`### Step 2`/`### Step 3` 为可选，仅当第二个短步骤确实有助于可读性（如把核心观察与最终验证分开）或题目确实需要时才加，总步骤数保持很少。
12. 正文结构：最后用 `## Flag` 小节，在代码块中给出 flag，如 `flag{example_flag_here}`。
13. 总步骤数控制在 1-3 个短步骤。
14. 代码只保留最小的完整解题脚本。
15. 不要把「恢复密钥」「派生 key」「解密 flag」拆成多个残缺片段。
16. 脚本必须从题目数据开始、以打印 flag 结束。
17. 避免冗长的背景介绍章节。
18. 除非死胡同解释了关键转折，否则不要写死胡同。
19. 不要给多个备选解法，只挑一条最干净的路径。
20. 仅在用户明确要求时才打码 flag。
21. 定稿前对照最佳实践清单：元数据齐全（title、CTF、date、category、difficulty、points、author 均填写）。
22. 定稿前对照清单：flag 处理符合请求（除非用户要求打码，否则保留真实 flag）。
23. 定稿前对照清单：步骤可复现，读者能照着复现解法。
24. 定稿前对照清单：代码可运行，exploit 脚本包含全部 import、变量名正确、带注释。
25. 定稿前对照清单：无敏感数据，不含真实凭据、API key 或私有基础设施细节。
26. 定稿前对照清单：篇幅保持简洁，短到可以快速评审。
27. 定稿前对照清单：行为依赖版本时，注明具体工具及版本。
28. 定稿前对照清单：正确署名，致谢队友、参考的 writeup 或关键工具。
29. 定稿前对照清单：语法与格式一致，标题层级统一，代码块带语言标签。
30. 做：只解释到足以快速验证的程度。
31. 做：只给一条完整解题路径，而不是多条备选路线。
32. 做：给出一个直通最终 flag 的完整脚本。
33. 做：贴出实际输出（过长可截断）以证明方法有效。
34. 做：代码块标注语言（`python`、`bash`、`sql` 等）。
35. 做：把主路径前置，让读者能快速验证。
36. 不做：不加解释地粘贴原始终端输出。
37. 不做：粘贴多个残缺片段，迫使读者自行拼出最终解法。
38. 不做：在最终 writeup 中留下占位文本。
39. 不做：写与解法无关的题外话。
40. 不做：假设读者了解该题目的具体环境搭建方式。

适用边界 · 注意事项

• 题目尚未解出、没有解题脚本和最终 flag 时（此时无内容可写）。
• 需要展示完整探索过程、多条解法对比或深度技术教学时（本格式只保留一条干净路径且刻意压缩死胡同）。
• 非 CTF 场景的通用技术文档或漏洞报告，元数据与 flag 字段不适用。