How to Use This Course
This course has a lot of technical detail and will require a lot of time to go through correctly. Give this page a quick read through to decide if you’re ready or not. I highly recommend against trying to beat your way through this course if you don’t have a decent technical background. You’ll get frustrated, confused, and spend way more time than necessary trying to figure it out. I have an earlier course called Systems Foundations that is a better place to start if you’re new to computer systems, and you can come back here and start once you’ve worked through that.
Start here, or start one course earlier
Section titled “Start here, or start one course earlier”You should arrive able to move around a Linux system, read and compile small C programs, read small Python scripts, and understand what a process, an ELF file, virtual memory, registers, the stack, the heap and a system call are. You should also be able to open a C program in GDB, stop it somewhere useful, look at the state in the right frame, work out where a value went wrong, and check that a fix did what you claimed.
You don’t have to be great at any of that, but you should at a minimum have an intuitive understanding of those basics.
If a few items on that list feel shaky, go back to the module rather than the whole course:
- Linux Foundations for the shell, files, processes and pipelines.
- Programming Foundations for Python, and for C through pointers and memory.
- How Programs Work for the execution model: processes, ELF, virtual memory, registers, the stack, the heap and system calls.
- Debugging Foundations for GDB and for explaining a failure with evidence.
If you’d rather test yourself than re-read, the Program Investigation Capstone lets you try the main skills together if you want a refresher.
The machine
Section titled “The machine”Everything here runs on a vanilla Ubuntu Desktop 24.04.4 x86-64 virtual machine. There’s no custom image to download and nothing to install from me. You build the same VM Systems Foundations built, and if you still have that one, you’re already done.
The reason to stay on that exact build is that the numbers in this course were measured on it. Chunk
sizes, the offset between a buffer and the stack canary, which malformed values free() rejects and
which it quietly accepts: those come from this GCC and this glibc. On a different distribution some
of them change, and you’ll spend your evening working out whether you made a mistake or your
allocator is simply a different version.
You don’t need those allocator and canary details before starting. They are examples of the measurements that later lessons will explain; the point here is simply that compiler and library versions can change them.
Pick the setup guide that matches your host:
- What Is a Virtual Machine? if the idea is new.
- VMware Workstation Pro on a Windows host.
- Hyper-V on Windows Pro, Enterprise or Education.
- UTM for macOS on either kind of Mac.
- Prepare Your Course Workspace once Ubuntu is up.
On an Apple Silicon Mac the UTM guide will tell you to emulate x86-64 instead of running a much faster ARM64 VM. Take the slow path anyway. Every program, every disassembly listing and every address in this course is x86-64, and an ARM64 VM will look perfectly healthy right up until the first lesson where the instructions you’re reading aren’t the ones running.
Keep a snapshot of the VM in a working state, and take a fresh one once you’ve got it set up the way you like. Some of the labs here deliberately corrupt a running program’s memory. None of them damage the machine, but a snapshot costs nothing and can save you an afternoon of reinstalling.
Create the course folders in the Ubuntu terminal. This also works if you already made some of them during Systems Foundations; mkdir -p leaves their contents alone:
mkdir -p ~/underdunn-course/{exercises,labs,notes,downloads,writeups}Using AI
Section titled “Using AI”I assume you’re here because you want to learn how to write exploits for computer programs. Making Claude do it is fun, but Claude already knows all of this. You don’t. Rather than burning the rainforest making Claude solve these challenges for the thousandth time, you may as well do something more useful like going outside and touching grass. That said, this is a self paced free course with no grading. Cheat if you want.
In your job in industry, you will likely have to use AI at some point. Remember that AI is itself a multiplier of productivity. The better your base ability is, the better results you will be able to get with AI. I highly recommend against leaning on it for this course, except in the case where you are having it explain a complicated concept you didn’t quite get or the output of a command that you’re having trouble parsing.
When you get stuck
Section titled “When you get stuck”The first useful move is working out which kind of stuck you are, because the two need opposite things.
“I don’t know what to try next.” Go back to the last result you actually understood and work out what it showed. Usually the gap turns out to be one specific thing you skimmed, and it is much easier to spot from a known-good position than from the middle of a failing experiment.
“I know what to try and it isn’t doing what I expected.” This is the good kind, and it’s most of the job. A few things that help:
- Make the failing thing smaller. Cut the input in half, drop a step, remove the part you’re confident about. A failure you can reproduce in three lines is a failure you can explain.
- Check the thing you’re certain about. Wrong offsets, wrong assumptions about where a variable lives and wrong beliefs about what a function does are the usual causes, and certainty is exactly what stops you looking. Go and measure it instead of remembering it.
- Read the whole error rather than the first line of it. The C library in particular is specific about what it objected to, and the difference between two of its messages is often the answer.
- Compare what you expected with what happened before changing anything. A quick note can help if you are juggling several possibilities.
- Give it a limit. If you’ve been on one thing for an hour without learning anything new about it, go and do something else, then come back. That isn’t giving up; it’s the cheapest way to get a fresh reading of the same evidence.
If you get a result that disagrees with what a page says, check your build and input. You may have found a real difference between your build and the one the lesson was measured on. If you think you have one of those, feel free to let me know. My contact info is on the main blog site.
Check as you go
Section titled “Check as you go”Use the expected output, short questions and flag checks to see whether the work did what you expected. If it didn’t, compare the first difference with the example or open a hint.
Notes and writeups are optional. Keep the source and input files you need to run your work again, and jot down anything useful to you. There are no reports to submit or independence scores to earn.