How to write a CTF writeup people actually learn from

A CTF writeup is a post-event explanation of how you solved a capture the flag challenge. A good one states the challenge and your result up front, walks through your reasoning (dead ends included), gives the minimum commands or code needed to reproduce the solve, and ends with lessons learned. Publish it only after the event officially ends.

Here are two opening lines for the same beginner crypto challenge, where the "encrypted" note turned out to be ROT13 wrapped in Base64 (the encoder and decoder and cipher toolkit reproduce both layers):

# Weak
Used base64 then rot13, got the flag.

# Useful
TL;DR: not encryption at all. The trailing "=" padding pointed to Base64.
The decoded text kept its spaces and word lengths, which pointed to a
letter-substitution cipher, and ROT13 was the first one worth trying.

Both are accurate. Only the second teaches a reader, or you in six months, how to recognize the next one. The rest of this guide is about writing the second kind.

New to writeups? Our beginner's guide covers how to read them without spoiling your own learning. This page is about writing them well. If you're a challenge author, see writing the author writeup instead.

Why writing CTF writeups is worth the effort

A writeup takes 30 to 90 minutes per challenge. Most of that time comes back later:

• You remember the technique. Explaining a solve forces you to understand why it worked.
• You build a searchable notebook. New challenges often look like old ones, and your own writeup is the fastest reference you have.
• The community improves. Writeups are how other players learn what they missed, and how authors discover unintended paths.
• Employers see how you think. A rank says you scored. A writeup shows your method and judgment (see writeups as a portfolio).

The structure of a great CTF writeup

Most strong writeups follow the same shape, whatever the category. Readers skim first and dive second, so put the answer near the top and the detail below it.

Write the TL;DR last, place it first

You only know the real key insight once the writeup is done. Write the TL;DR at the end and put it at the top. "The flag was in the JPEG's EXIF comment as base64" is a TL;DR. "This was a fun forensics challenge" is not.

Show your reasoning, not a transcript

Commands with no context teach nothing. Before each step, write one sentence on why: what you observed and what you expected. After it, say what the output told you. Readers can reuse the reasoning even when your exact commands don't apply to their next challenge. When a step identifies a hash, name the type and say how you knew; the hash identifier shows the same length and character-set reasoning.

Keep the dead ends, but briefly

Dead ends are the most underrated part of a writeup: they show which obvious ideas fail and why. Keep each to a line or two, plus what made you abandon it.

Credit people

Name the challenge author if the event published it, credit teammates, and link any writeup or blog post that gave you the key trick. Credit costs nothing and keeps the community sharing.

Copy-ready CTF writeup template (Markdown)

This template follows the structure above. It's plain Markdown, so it renders on GitHub, most static site generators and blogging platforms. Replace everything in {curly braces} and delete sections that don't apply.

# {Challenge name} ({Category}, {points} pts): {Event name} {year}

| Field      | Value |
|------------|-------|
| Event      | {Event name and edition}, {date range} |
| Category   | {web / crypto / pwn / reverse / forensics / OSINT / misc} |
| Points     | {final points} ({static / dynamic}) |
| Solves     | {number, if published} |
| Author     | {challenge author, if credited} |
| Solved by  | {your handle} ({team name}) |
| Status     | {Solved during event / Upsolved after event} |

## TL;DR
{One or two sentences: the bug class or trick, and the key insight.}

## Challenge
> {Paste the challenge description exactly as given.}

- Files: `{filename}` (sha256: `{hash}`)
- Service: `{chal.example.lab:port}` (event infrastructure, now offline)

## First look
{What you checked first and why. Paste key output as text, trimmed.}

```
{command}
{trimmed output}
```

## Dead ends
- {Idea}: {what happened} -> {why it didn't work}
- {Idea}: {what happened} -> {why it didn't work}

## Solution
### Step 1: {what this step achieves}
{Why you took this step, what you expected, what you saw.}

### Step 2: {what this step achieves}
{Reasoning first, then the minimum command or code.}

```{language}
# solve script: minimal, commented, no hardcoded secrets
{code}
```

![{Describe what the screenshot shows}](img/{file}.png)

## Flag
`CTF7{...}`  {or: "Omitted at the organizer's request."}

## Lessons learned
- {What you'd check first next time}
- {Tool or technique you learned}
- {What made the challenge click}

## References
- {Docs, papers, other writeups that helped, with links}
- Thanks to {author} for the challenge and {teammates} for {help}.

What a good writeup looks like: a short example

Here's the same solve written two ways. The challenge is fictional: Holiday Snap (Forensics, 100 pts). "Our admin posted a holiday photo. Nothing to see here." Attachment: holiday.jpg.

The weak version

Ran exiftool, got base64, decoded it. Flag: CTF7{exif_keeps_secrets}. Easy.

Accurate and useless: nobody learns why you checked metadata first, so they can't adapt it to the next challenge.

The strong version (excerpt)

TL;DR: The flag was base64 text in the JPEG's EXIF Comment field. Checking metadata before reaching for stego tools found it in one command.

First look. The photo looked normal, and file reported a standard JPEG with EXIF data. Running strings showed a long base64-looking string near the start of the file, which is where EXIF metadata lives, so metadata was the first lead.

Dead end. Before that, I tried steghide with an empty passphrase, because "nothing to see here" sounded like hidden data. No embedded file came out, and the challenge gave no passphrase hint, so I moved on.

Solution. Read the comment field, then decode it:

player~/holiday-snap❯exiftool -Comment holiday.jpg
Comment                         : Q1RGN3tleGlmX2tlZXBzX3NlY3JldHN9
player~/holiday-snap❯exiftool -s3 -Comment holiday.jpg | base64 -d
CTF7{exif_keeps_secrets}

Lessons. Check metadata before steganography tools; exiftool -a -G1 lists every tag with its group. The trailing characters and alphabet of the string marked it as base64 before I decoded anything. Writing up a real vulnerability rather than a puzzle? Add a severity with the CVSS calculator.

Same flag, but now the reader has a triage order for any image challenge. More in the forensics and steganography sections of the categories guide.

Screenshots and code etiquette

Screenshots

• Paste text when it's text. Terminal output, HTTP requests and source code belong in code blocks that readers can search, copy and have read aloud by a screen reader.
• Screenshot what's visual: a rendered page, a waveform, a disassembly graph, an image with hidden detail.
• Crop and annotate. Cut to the relevant area and box the important detail.
• Write alt text and captions. Say what the image shows and why it matters, for example "Ghidra decompiler view of the license check comparing input length to 16".
• Redact before you publish: session cookies, API tokens, real IP addresses, your email and other players' usernames.

Code and commands

• Show the minimum that reproduces the solve. Trim noisy output to the lines that matter, and mark cuts with ....
• Comment the why. A comment like # server reuses the nonce, so the keystream repeats is worth more than ten lines of uncommented code.
• Use placeholders for event infrastructure, such as chal.example.lab:31337. The servers will be gone in a week anyway.
• Note versions when the solve depends on them: "works with pwntools 4.x, Python 3.12".
• Tag code blocks with a language (```python, ```bash) so they render with syntax highlighting.
• Put long scripts in a repo and link them, with a short excerpt in the writeup itself.

Stay inside the CTF

A writeup documents an intentionally vulnerable challenge built to be attacked within the event's rules. Keep it there: don't describe attacks on the scoring platform or other players, and don't turn it into a guide for attacking real systems. If you found a genuine bug in the platform itself, report it privately to the organizer. On CTF7, use the bug report page.

Writeup embargo: when you can publish

Never publish a writeup while the event is running. A public solution during the competition is flag sharing, and most rules treat it as grounds for disqualification. The CTF7 code of conduct says the same: publish your own writeups only after the event ends.

Extended embargoes are real. Some events reuse challenges and ask for no publication at all. When in doubt, ask the organizers in the official channel before posting.

A writeup you send privately to organizers, for example to verify prize eligibility, is not publishing: the public embargo still applies. Organizers can set all of this up front with our CTF rules template.

Where to publish your CTF writeups

Many players keep the canonical copy somewhere they control and link to it from everywhere else.

Practice on Ouroboros CTF, then write it up. Find events to write about on the events page. Whatever you choose, use a consistent naming scheme (2026/event-name/category/challenge-name) and a README index per event with your final rank and links. If you play with a regular team, keep a shared writeups repo; our guide to building a CTF team covers how to organize one.

Writeups as a hiring portfolio

Writeups are evidence of hands-on skill in written form. A hiring manager reading one sees how you approach an unfamiliar problem, whether you explain technical work clearly, and whether you know when to change approach. That's most of the job in pentesting, application security and incident response.

• Curate. Pick five to eight of your best writeups across at least three categories, and link them from a pinned GitHub repo or a portfolio page.
• Lead with your strongest work. One hard challenge explained well beats twenty easy ones explained badly.
• Show range. Add one or two report-style pieces: a vulnerability report convinces a reader to fix something, where a writeup teaches. Our vulnerability report template shows the format, and report-based formats like Raw Ops let you practice it under competition conditions.
• Link it everywhere. Resume, LinkedIn and job applications on the CTF7 job board.
• Expect to discuss it. Interviewers may ask you to walk through any writeup, so understand every step.

Writeups also show up in hiring itself: an organizer running a hiring CTF can also request a short writeup of two or three solves alongside the score. We explain why in hiring security talent with CTFs and MCQ tests vs live labs.

Common CTF writeup mistakes

1. Publishing during the event. The one mistake that can get your team disqualified.
2. Commands with no reasoning. A transcript is not a writeup.
3. Screenshots of terminal text. Unsearchable, uncopyable and inaccessible.
4. Leaking secrets. Session tokens, personal IPs, API keys left in a screenshot or script.
5. Hiding an unintended solution. If your path wasn't the intended one, say so.
6. No credit. Forgetting the author, teammates or the writeup that gave you the hint.
7. Waiting too long. Write within a few days, while you still remember the dead ends.

For organizers: getting great writeups after your event

Writeups are the best long-term record of your event. To get more of them:

• State the embargo clearly in your rules and announce the moment it lifts.
• Publish your own author writeups and challenge source, ideally prepared before the event (see author writeups).
• Give writeups a home: a hashtag, a channel, and, for public events, a CTFtime listing so players can find your event.
• Reward them. A "best writeup" prize costs little. Our guide to hosting a CTF covers prizes and the post-event checklist.

Planning an event? Tell us about it and we'll help you set it up on CTF7.