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
• [ ] 步驟可重現 — 讀者能依照報告重現解法
• [ ] 程式碼可執行 — 漏洞利用腳本包含所有 import、正確變數名稱與註解
• [ ] 無敏感資料 — 無真實憑證、API 金鑰或私有基礎設施細節
• [ ] 長度簡潔 — 報告夠短，便於快速審查
• [ ] 工具與版本已註明 — 若行為依賴特定版本，請提及
• [ ] 適當歸屬 — 致謝隊友、參考的報告或關鍵工具
• [ ] 語法與格式正確 — 標題層級一致，程式碼區塊有語言標籤

品質指引

務必：

• 僅解釋足以快速驗證的內容
• 包含一條完整的解題路徑，而非多種替代路線
• 包含一個從頭到尾取得最終 flag 的完整腳本
• 顯示實際輸出（若很長可截斷）以證明方法有效
• 為程式碼區塊加上語言標籤（python、bash、sql 等）
• 將主要路徑放在前面，讓讀者能快速驗證

避免：

• 未經解釋直接貼上原始終端輸出
• 貼上多個片段，迫使讀者自行拼湊最終解法
• 在最終報告中留下佔位文字
• 包含與解法無關的離題內容
• 假設讀者了解特定題目的設定

題目

$ARGUMENTS