ctf-writeup

CTF 解説記事ジェネレーター

解いたチャレンジの、標準化された提出形式の CTF 解説記事を生成します。

デフォルトの動作：

• 競技の開催中は、速度、明瞭さ、再現性を優先します
• チームメイトや主催者が解法をすばやく検証できるよう、解説記事は簡潔にまとめます
• 常に「提出形式」の解説記事を作成します
• チャレンジのデータから最終的なフラグまでを一貫して処理する、完全な解法スクリプトを優先します

ワークフロー

ステップ 1：情報を収集する

現在のセッション、チャレンジのファイル、ユーザーの入力から、次の情報を収集します。

1. チャレンジのメタデータ — 名前、CTF イベント、カテゴリ、難易度、配点、フラグ形式
2. 解法に関する成果物 — エクスプロイトスクリプト、ペイロード、スクリーンショット、コマンド出力
3. タイムライン — 実施した主な手順、行き詰まった箇所、方針転換

# Scan for exploit scripts and artifacts
find . -name '*.py' -o -name '*.sh' -o -name 'exploit*' -o -name 'solve*' | head -20
# Check for flags in output files
grep -rniE '(flag|ctf|eno|htb|pico)\{' . 2>/dev/null

ステップ 2：解説記事を作成する

以下の提出テンプレートを使って、解説記事のファイルを writeup.md（または writeup-<challenge-name>.md）として作成します。

---

テンプレート

提出形式

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

# <Challenge Name>

## Summary

<1-2 sentences: what the challenge was and the core technique. Keep it direct.>

## Solution

### Step 1: <Action>

<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>
\`\`\`

### Step 2: <Action> (optional)

<Only add this when a second short step genuinely helps readability, such as separating the core observation from final verification.>

### Step 3: <Action> (optional)

<Use only if the challenge really needs it. Keep the total number of steps small.>

## Flag

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

ガイドライン：

• 合計 1～3 個の短い手順を目安にします
• コードは、解法を完結させるために必要な最小限のものにします
• 「秘密情報を復元する」「鍵を導出する」「フラグを復号する」を、複数の不完全なコード片に分割しないでください
• スクリプトはチャレンジのデータから処理を開始し、フラグを出力して終わるようにします
• 背景説明を長々と書かないでください
• 重要な方針転換を説明する場合を除き、行き詰まった箇所は含めないでください
• 複数の代替解法は避け、簡潔な解法を 1 つ選んでください
• ユーザーから明示的に指示された場合に限り、フラグを伏せてください

---

ベストプラクティスチェックリスト

解説記事を完成させる前に、次の項目を確認してください。

• メタデータがそろっている — タイトル、CTF、日付、カテゴリ、難易度、配点、作者をすべて記入
• フラグの扱いが依頼に沿っている — ユーザーが伏せるよう求めていない限り、実際のフラグを記載
• 手順を再現できる — 読者が解説記事に沿って解法を再現できる
• コードが実行できる — エクスプロイトスクリプトに必要なインポート、正しい変数名、コメントが含まれている
• 機密情報が含まれていない — 実際の認証情報、API キー、非公開のインフラ情報がない
• 簡潔にまとまっている — すばやく確認できる長さになっている
• ツールとバージョンが明記されている — 動作がバージョンに依存する場合は、具体的なツールのバージョンを記載
• 適切にクレジットを記載している — 解法に不可欠だったチームメイト、参照した解説記事、ツールに謝辞を記載
• 文法と書式が整っている — 見出しレベルが一貫しており、コードブロックに言語タグがある

品質ガイドライン

推奨事項：

• すばやく検証するのに必要な範囲で説明する
• 複数の代替手順ではなく、完全な解法を 1 つ記載する
• 最終的なフラグまで処理する完全なスクリプトを 1 つ含める
• 解法が機能したことを示すため、実際の出力を掲載する（非常に長い場合は省略可）
• コードブロックに言語（python、bash、sql など）のタグを付ける
• 読者がすばやく検証できるよう、主要な手順を先に示す

禁止事項：

• 説明なしに、ターミナルの出力をそのまま貼り付けない
• 読者が最終的な解法を組み立てる必要のある、不完全なコード片を複数貼り付けない
• 最終的な解説記事にプレースホルダーテキストを残さない
• 解法に関係しない余談を含めない
• 読者がそのチャレンジ固有の環境設定を知っている前提で書かない

チャレンジ

$ARGUMENTS