After PortSwigger Academy: where to go for binary work
You've finished the Web Security Academy and want to learn binary exploitation. The honest version of what you'll need to relearn, and the cleanest paths in.
PortSwigger Academy is one of the better self-study courses in security, full stop. By the time you've cleared most of the labs you have a real working theory of how requests get parsed, where trust boundaries get crossed, and what it feels like to spot a bug. That instinct travels. The mechanics, mostly, do not.
Binary work runs on a different stack. You're no longer poking at a server response and reading its mind from the outside; you're sitting inside a process, looking at the registers it had a microsecond ago and trying to plan a sequence of bytes that will rearrange those registers in your favour. The skill jump is real. People underestimate it because the surface vocabulary overlaps. The words "buffer", "input", and "overflow" mean entirely different things in the two worlds, and the underlying primitives have nothing in common. So let's name what's actually missing and what to do about it.
The skills nobody mentioned to you
Three things have to come online together. Without all three, you'll bounce off the first serious binary challenge and assume the field is gatekept. The gatekeeping is mostly imagined. The trio is real.
Assembly. Specifically x86_64 and ARM64, in that order. You don't need to write it from scratch on day one. You need to read it confidently — to glance at fifty instructions in IDA or Ghidra and hold a model of what the function is doing in your head. That's a separate skill from "knowing what mov does". It comes from reading thousands of lines of disassembly and recognising the shapes: the function prologue, the loop, the switch table, the indirect call through a vtable.
A working memory model. Stack frames, calling conventions, the heap, mmap regions, the GOT and PLT. None of this is intellectually hard. All of it has to be loaded into your fingers, because every exploit primitive lives in this geography. If a bug gives you an arbitrary write of one qword, you should already be sketching where to point it before you've finished reading the prompt. That instinct only develops after you've internalised the layout.
Debugger fluency. GDB with pwndbg or gef. The fluency target is being able to stop a program at any instruction, walk the stack, decode a heap chunk by hand, and not feel like you're fighting the tool. Debugger work is to binary exploitation what Burp Repeater is to web — the place where you actually do the thinking.
The web pentester equivalent of all this is roughly: HTTP, the request/response model, and Burp. You spent months getting comfortable there. Budget similar time here. People who try to skip it tend to memorise specific exploit recipes and never learn to write their own.
Why CTFs first, not real software
Real binaries are messy. They have many bugs, most of them irrelevant; they have mitigations stacked on mitigations; they have layers of code you don't need to understand. CTF binaries are the opposite. One bug, one path, one objective. The mitigations are dialled in deliberately so that exactly the technique the challenge wants to teach is the one that works.
That's not a weakness. It's how you learn. The same way the Academy taught you SSRF on a machine that wasn't trying to be realistic, a good CTF challenge teaches you a ret2libc on a binary whose only job is to teach you ret2libc. You'll graduate to messier targets soon enough.
Where to actually start
The honest list, ordered roughly by ramp:
pwn.college. The first few modules (Computing 101, Assembly Crash Course, Program Misuse, and the early Reverse Engineering set) are the closest thing to a structured intro that exists. The author wrote them while teaching ASU's CSE 466, and it shows. Free, open, and the difficulty climbs at a humane rate. If you do nothing else from this post, do this.
picoCTF binary challenges. Aimed at younger students, which makes the early ones almost gentle, but the later sets are not. Useful for picking up small primitives in isolation: a single format string, a single ret2win, a single canary leak. The platform is permanent; old challenges remain playable, so you can grind at your own pace.
HTB starting-point boxes with a binary component. Less curated, more variable in quality, but they put you in front of something that has to be solved end-to-end — recon, foothold, pivot, exploit. The binary tasks are usually simple, sometimes embarrassingly so, but the workflow is the right one. If you've been using Burp for years, the rhythm of "enumerate, hypothesise, test" will feel familiar.
ROP Emporium. Single-purpose, focused on return-oriented programming specifically. Skip until you've got at least basic stack overflows under your belt, then run through it in a long evening. It's the cleanest available demonstration of what a ROP chain is and how you build one from scratch.
You don't need to do all four. You need to do enough of one of them that the third bug in a row stops feeling like magic and starts feeling like applying a recipe you've half-internalised.
What the curve actually looks like
For a competent web tester, the first month is rough. You'll spend a lot of it staring at gdb prompts, trying to remember which command lists registers in your particular plugin. Then somewhere in the second or third month a switch flips and you stop reading assembly and start reading what the assembly means. After that the pace picks up considerably.
The thing nobody warns you about is that the difficulty isn't conceptual; the concepts are mostly small. The difficulty is the volume of small details you have to keep paged in. Calling conventions for x86_64 SysV vs Windows x64. The exact layout of a glibc tcache chunk. Which mitigations affect which technique. None of it is calculus. All of it is a hundred little things you have to know.
Be patient with yourself. The web hunters who make this transition successfully are the ones who treat the first ninety days as language acquisition rather than coursework.
Where this fits in
If you want a structured walkthrough rather than the wild west of forum posts, the Foundations track covers the model: number bases, registers, instruction sets, the operational mental picture that lets the rest land. The Memory & Systems track covers stack frames, calling conventions, the heap, virtual memory, and the layout you'll spend the rest of your career navigating. Treat them as the long version of this post, with code you can run and break.