← ALL POSTS CTF · CSAW 2025

What writing a CTF challenge taught me about breaking things.

I've played a lot of CTF. Solving challenges is how I got into security, and it's still my favorite way to stay sharp. But last year, with OSIRIS Lab, I did something different: I authored a challenge for CSAW CTF 2025 — one of the largest student-run security competitions in the world, with thousands of players across dozens of regions. Being on the other side of the flag changed how I think about the whole game.

Solving is narrow. Authoring is total.

When you solve a challenge, you only have to find one path from the prompt to the flag. When you author one, you're responsible for every path — including the ones you didn't intend to exist. That inversion is the entire lesson. A solver asks "how do I get in?" An author has to ask "what are all the ways in, and which of them do I actually want?"

The first draft of any challenge has three solutions. You designed one of them. The other two are the ones that will ruin your night.

Unintended solutions are a design failure, not bad luck

The nightmare of every author is the unintended solve — a team flags your challenge in ten minutes using a trick that skips the entire mechanism you built. It feels like getting robbed. But it's not luck; it's a leak in your threat model. Some of the ways it happens:

• A file permission you left too loose, so the flag is just readable.
• A library function that does something you forgot it could do.
• A guessy step where the "intended" insight is one of five equally plausible guesses.
• Infrastructure leaking — a debug endpoint, a verbose error, a stack trace with a path in it.

Closing these means attacking your own challenge as adversarially as the best team will. You write the intended solve script, sure — but then you spend more time trying to skip it. That mindset, "assume the smartest possible attacker with none of my assumptions," is exactly what you want when you're defending real systems. Authoring is threat-modeling with a live-fire test at the end.

Difficulty is a curve you draw on purpose

A good challenge has a shape. The first 20% should teach the player what kind of problem they're in. The middle should be the actual work. The last step should be a satisfying click, not a brick wall or an anticlimax. Get the curve wrong and you either get zero solves (frustrating, wasted challenge) or a thousand solves in the first hour (no signal, no fun).

Calibrating that is genuinely hard because you are the worst possible judge of your own challenge's difficulty — you know the answer. This is why playtesting by someone who hasn't seen it is non-negotiable. The gap between "obvious to me" and "obvious to a fresh solver" is where every difficulty misjudgment lives.

Infrastructure is the invisible half

Beyond authoring, co-running the qualifiers meant the other half of the job: hosting challenges, keeping the platform up, and moderating at scale while thousands of people actively try to break everything in front of them — sometimes including your infrastructure rather than your challenges. A CTF is a distributed system under adversarial load by definition. Isolation between challenge containers, rate limiting, and watching for teams DoS-ing a service instead of solving it are all part of shipping the event.

What it changed

• I read code differently now — I look for the unintended path first, because that's the one attackers take.
• I trust playtesting over my own intuition about difficulty and clarity.
• I think about the infrastructure around a vulnerability, not just the vulnerability, because in the real world the infra is part of the attack surface.

Solving CTF made me a better attacker. Authoring one made me a better engineer. If you run a lab or a competition and want someone who's been on both sides of the flag, let's talk.