ctf-writeup

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CTF Write-up Generator

CTF解题报告生成器

Generate a standardized submission-style CTF writeup for a solved challenge.
Default behavior:
  • During an active competition, optimize for speed, clarity, and reproducibility
  • Keep writeups short enough that a teammate or organizer can validate the solve quickly
  • Always produce a
    submission
    -style writeup
  • Prefer one complete solve script from challenge data to final flag
为已解决的CTF挑战生成标准化的提交风格解题报告。
默认行为:
  • 比赛进行中时,优先保证速度、清晰度与可复现性
  • 解题报告需简洁,便于队友或主办方快速验证解法
  • 始终生成
    submission
    风格的解题报告
  • 优先提供从挑战数据到最终flag的完整解题脚本

Workflow

工作流程

Step 1: Gather Information

步骤1:收集信息

Collect the following from the current session, challenge files, and user input:
  1. Challenge metadata — name, CTF event, category, difficulty, points, flag format
  2. Solution artifacts — exploit scripts, payloads, screenshots, command output
  3. Timeline — key steps taken, dead ends, pivots
bash
undefined
从当前会话、挑战文件和用户输入中收集以下内容:
  1. 挑战元数据 — 名称、CTF赛事、类别、难度、分值、flag格式
  2. 解法产物 — 利用脚本、 payload、截图、命令输出
  3. 时间线 — 关键步骤、尝试失败的方向、思路转变
bash
undefined

Scan for exploit scripts and artifacts

扫描利用脚本和相关产物

find . -name '.py' -o -name '.sh' -o -name 'exploit*' -o -name 'solve*' | head -20
find . -name '.py' -o -name '.sh' -o -name 'exploit*' -o -name 'solve*' | head -20

Check for flags in output files

在输出文件中查找flag

grep -rniE '(flag|ctf|eno|htb|pico){' . 2>/dev/null
undefined
grep -rniE '(flag|ctf|eno|htb|pico){' . 2>/dev/null
undefined

Step 2: Generate Write-up

步骤2:生成解题报告

Write the writeup file as
writeup.md
(or
writeup-<challenge-name>.md
) using the submission template below.

使用下方的提交模板将解题报告保存为
writeup.md
(或
writeup-<challenge-name>.md
)。

Templates

模板

Submission Format

提交格式

markdown
---
title: "<Challenge Name>"
ctf: "<CTF Event Name>"
date: YYYY-MM-DD
category: web|pwn|crypto|reverse|forensics|osint|malware|misc
difficulty: easy|medium|hard
points: <number>
flag_format: "flag{...}"
author: "<your name or team>"
---
markdown
---
title: "<Challenge Name>"
ctf: "<CTF Event Name>"
date: YYYY-MM-DD
category: web|pwn|crypto|reverse|forensics|osint|malware|misc
difficulty: easy|medium|hard
points: <number>
flag_format: "flag{...}"
author: "<your name or team>"
---

<Challenge Name>

<Challenge Name>

Summary

摘要

<1-2 sentences: what the challenge was and the core technique. Keep it direct.>
<1-2句话:挑战内容及核心技巧。直接明了。>

Solution

解法

Step 1: <Action>

步骤1:<操作>

<Explain the key observation in 3-8 short lines. Keep it direct.>
```python <one complete solving script from provided challenge data to printing the final flag> ```
<用3-8行短句说明关键发现。直接明了。>
python
<从给定挑战数据到输出最终flag的完整解题脚本>

Step 2: <Action> (optional)

步骤2:<操作>(可选)

<Only add this when a second short step genuinely helps readability, such as separating the core observation from final verification.>
<仅当第二个简短步骤确实有助于可读性时添加,例如将核心发现与最终验证分离。>

Step 3: <Action> (optional)

步骤3:<操作>(可选)

<Use only if the challenge really needs it. Keep the total number of steps small.>
<仅在挑战确实需要时使用。保持总步骤数量较少。>

Flag

Flag

``` flag{example_flag_here} ```

Guidance:

- Prefer 1-3 short steps total
- Keep code to the smallest complete solving script
- Do not split "recover secret", "derive key", and "decrypt flag" into separate partial snippets
- The script should start from the challenge data and end by printing the flag
- Avoid long background sections
- Avoid dead ends unless they explain a key pivot
- Avoid multiple alternative solves; pick one clean path
- Redact the flag only if the user explicitly asks for redaction

---
flag{example_flag_here}

指导原则:

- 优先保留1-3个简短步骤
- 代码应是最小的完整解题脚本
- 不要将“恢复密钥”、“推导密钥”和“解密flag”拆分为多个部分代码片段
- 脚本应从挑战数据开始,最终输出flag
- 避免冗长的背景介绍
- 除非能说明关键思路转变,否则不要提及尝试失败的方向
- 避免提供多种替代解法;选择一种清晰的路径
- 仅当用户明确要求时才隐藏flag

---

Best Practices Checklist

最佳实践检查清单

Before finalizing the writeup, verify:
  • Metadata complete — title, CTF, date, category, difficulty, points, author all filled
  • Flag handling matches request — keep the real flag unless the user asked for redaction
  • Reproducible steps — a reader can follow your writeup and reproduce the solution
  • Code is runnable — exploit scripts include all imports, correct variable names, and comments
  • No sensitive data — no real credentials, API keys, or private infrastructure details
  • Length stays concise — the writeup is short enough for fast review
  • Tools and versions noted — mention specific tool versions if behavior depends on them
  • Proper attribution — credit teammates, referenced writeups, or tools that were essential
  • Grammar and formatting — consistent heading levels, code blocks have language tags
最终确定解题报告前,请验证:
  • 元数据完整 — 标题、CTF赛事、日期、类别、难度、分值、作者均已填写
  • Flag处理符合要求 — 除非用户要求隐藏,否则保留真实flag
  • 步骤可复现 — 读者可按照报告复现解法
  • 代码可运行 — 利用脚本包含所有导入项、正确的变量名及注释
  • 无敏感数据 — 无真实凭证、API密钥或私有基础设施细节
  • 篇幅简洁 — 解题报告足够简洁,便于快速审核
  • 工具及版本已注明 — 若行为依赖特定工具版本,请注明
  • 归属正确 — 对提供关键帮助的队友、参考的解题报告或工具致谢
  • 语法与格式规范 — 标题层级一致,代码块带有语言标签

Quality Guidelines

质量准则

DO:
  • Explain just enough for fast verification
  • Include one complete solving path, not multiple alternative routes
  • Include one complete script that goes all the way to the final flag
  • Show actual output (truncated if very long) to prove the approach worked
  • Tag code blocks with language (
    python
    ,
    bash
    ,
    sql
    , etc.)
  • Keep the main path front-loaded so a reader can validate it quickly
DON'T:
  • Copy-paste raw terminal dumps without explanation
  • Paste several partial snippets that force the reader to reconstruct the final solve
  • Leave placeholder text in the final writeup
  • Include irrelevant tangents that don't contribute to the solution
  • Assume the reader knows the specific challenge setup
建议:
  • 仅提供足够用于快速验证的说明
  • 包含一条完整的解题路径,而非多种替代路线
  • 提供一个从始至终输出最终flag的完整脚本
  • 展示实际输出(若过长可截断)以证明方法有效
  • 为代码块添加语言标签(
    python
    bash
    sql
    等)
  • 将核心路径放在最前面,便于读者快速验证
避免:
  • 未经解释地复制粘贴原始终端输出
  • 粘贴多个部分代码片段,迫使读者自行拼接最终解法
  • 在最终报告中保留占位文本
  • 包含与解法无关的题外话
  • 假设读者了解特定挑战的设置

Challenge

挑战

$ARGUMENTS
$ARGUMENTS