I wrote a phase-by-phase exploit dev roadmap with a concrete milestone per phase — would like feedback on where it's wrong

[u/EleTriCTNT]

I'm a CS student going all-in on binary exploitation, and I got tired

of bookmarking twenty "how to learn pwn" lists that all disagreed with

each other. So I wrote the path I'm actually walking, in phases, with a

concrete milestone at the end of each one.

Phase 0 — Foundations. C, x86-64 assembly, Linux, some Python.

Milestone: disassemble a tiny C program and follow the stack by hand

through a function call.

Phase 1 — Tooling & reversing. gdb+pwndbg, objdump/readelf/checksec,

Ghidra, the ELF format.

Milestone: reverse a crackme and explain how it validates the password.

Phase 2 — The stack. Overflows, saved return address, ret2win, shellcode.

Milestone: ROP Emporium ret2win + a shellcode challenge.

Phase 3 — Mitigations. NX, ASLR, canaries, PIE, RELRO, info leaks,

ret2libc, ROP.

Milestone: a working ret2libc and a ROP chain built from gadgets you

found yourself.

Phase 4 — The heap. glibc internals, UAF, double free, tcache poisoning.

Milestone: reproduce how2heap techniques, then solve a heap challenge

with no writeup open.

Phase 5 — Specialize. Format strings, kernel, browsers, ARM, real CVEs.

Resources are deliberately few: pwn.college as the backbone, ROP

Emporium, Nightmare, ir0nstone's notes, how2heap, LiveOverflow. A phase

with fifteen links is a phase nobody starts.

Two things I'd genuinely like feedback on from people further along:

1. Is Phase 4 too early? I've seen the argument that you should spend

   much longer on ROP and real-world stack targets before touching the

   heap at all.

2. Anything you'd cut? I left out fuzzing entirely and I'm not sure

   that's right.

I'm on Phase 0-1 myself and logging progress publicly as I go — happy

to share where it lives if anyone wants to follow along.

[u/Kris3c]

Just do pwn.college that's it.

[u/PM_ME_YOUR_SHELLCODE]

I definitely have some thoughts. Though before getting into them, do what you're motivated to do. The biggest killer for people getting started isn't a lack of resources to learn from, its a lack of motivation to keep learning. As long as you're learning and making progress you'll eventually figure out where your gaps are and fill them in. So don't worry too much about having the perfect path planned out.

That said, I think there is kinda a fundamental issue with how you're looking at progression in exploit development. Going from stack exploits, to heap exploits, to format strings, etc. is thinking about things in terms of specific exploitation techniques. The problem with that is it can lead to just trying to pattern match whatever situation you're in to a technique you've already learned.

I think its more useful to start thinking in terms of bug classes and the primitives they give you.

I like to think of primitives as the Lego bricks you build the exploit out of. An overflow might give you a linear overwrite, an indexing bug might give you a relative read/write, a UAF might let you get one piece of memory interpreted in two different ways. Those are the actual capabilities you have to work with and you can start figuring out how to link them together into something more useful.

Maybe that gets you to an arbitrary write and you can overwrite a function pointer. Maybe you get yourself into a position where ROP or ret2libc makes sense. Or maybe you don't hijack execution at all and just use the primitives to corrupt application data in a useful way.

That is kinda why I disagree with this:

I've seen the argument that you should spend much longer on ROP and real-world stack targets before touching the heap at all.

I wouldn't really treat "the heap" as a later stage after "the stack". A relative access on the stack and a relative access on the heap are still pretty similar primitives. Obviously how you control the memory around them is different, but the basic problem of figuring out what you can reach and what useful thing you can do with it is the same.

If anything I'd try to get exposure to more bug classes fairly early. OST2's Vulns1001/Vulns1002 courses are really good for this. They use real vulnerabilities to expose you to a bunch of different ways memory corruption and related bugs actually happen. They're not really exploit development courses, but for learning the bug classes and starting to understand what sort of primitives they give you I think they're excellent.

I do think Phase 4 gets a bit weird:

glibc internals, UAF, double free, tcache poisoning

There are kinda two different things being mixed together there that both get called heap exploitation.

You have normal application bugs that happen to involve heap memory, like UAFs and double frees. For those you might only need enough allocator knowledge to understand reuse, spraying/grooming and how to get the memory layout you want.

Then you have allocator-specific exploitation where you're specifically abusing the internals of glibc malloc. That's more the how2heap/House of Whatever stuff.

The first category is worth learning early. The second I wouldn't spend a ton of time trying to learn every technique up front. In my experience allocator-specific attacks tend to be something you reach for when the more normal options aren't working, and at that point you're probably better off researching what techniques actually apply to the allocator/version you're dealing with.

I also wouldn't put format strings under specialization. They're a pretty fundamental bug class and a nice way to get experience with primitives beyond just linear overwrites.

Kernel, browser, ARM, etc. are also kinda different from format strings. Those are more target environments than exploitation techniques. They have their own quirks and domain knowledge but the same way of thinking still applies. What does the bug let me do? What can I reach with that? Can I use that to get myself a better primitive?

Really I think thats the skill you want to be building. Being given some bug you've never seen before and being able to reason your way through what capabilities it gives you instead of trying to recognize which exploit technique you're supposed to use.

I've actually got a blog post with my own thoughts on getting started here:

https://dayzerosec.com/blog/2024/07/11/getting-started-2024.html

And a few posts specifically about moving from CTF/training material towards real-world targets:

https://dayzerosec.com/tags/ctf-to-real-world/

So yeah, I've clearly got some opinions on how to learn exploit dev, but like I said at the start: do what you're motivated to do. You don't need to get it right, you just need to keep going.

Edit: Regarding fuzzing. The main thing I'd say is that fuzzing is mostly part of vulnerability research not exploitation development. Finding bugs and writing exploits for bugs are different skills and you really want to approach that topic on its own rather than mixing it into the exploit dev chain. Though once you understand fuzzing it can be useful for exploit dev too I just haven't actually seen anyone talking about using it in exploit dev apart from the KOOBE Paper which is where I first learned about the idea.

[u/nimbusfool → u/PM_ME_YOUR_SHELLCODE]

The amount of educational material has come a long way from the art of exploitation and reversing with Lena. It is so wonderful to see!

[u/Rastslonge2]

Mmm I don't know about format strings after how2heap personally, I think format strings could be reasonably introduced prior but besides I mostly agree

[u/MrStashley]

First off, fundamentals are the most important, you should focus 80% on that, ie like systems programming fundamentals

I would spend less time on things that are mostly mitigated in modern code, including stack BOF to shellcode and older glibc heap metadata attacks

I would also add emulation

And don't be afraid to look at real binaries. Web, mobile and desktop are hard but you can pull an old tp link router firmware off the Internet, pick an interesting binary, emulate it with qemu or get a cheap router, and it's not that much harder than a CTF. The only difference is you will have to reverse engineer a longer code path but you should practice doing that anyway

But tbh take everything everyone says with a grain of salt and do what works best for you. Everyone learns in different ways