Welcome & Course Map

Start HereLesson 1 of 110 minutesModule overview

Start here for vulnerability research

Systems Foundations is the first course in a series on vulnerability research. Before we can investigate why software fails, and whether that failure matters for security, we need to understand what it does when it works. That’s what this course is for.

Suppose a program stops when it tries to read a file. That observation doesn’t tell us whether the file is missing, access was denied, or the program made a bad assumption about its input. It certainly doesn’t establish a vulnerability. Before we can ask the security question, we need to understand the behavior we’re looking at.

A computer is not magic, it’s a pile of parts following rules that are almost aggressively literal (the machine has no idea what you meant, only what you typed). The processor executes instructions, memory holds whatever instructions and data are in use at the moment, storage keeps your files around after the power goes out, and the operating system decides which program gets what and when.

An executable file holds instructions and data. When you run it, the operating system loads it into a process with its own memory and execution state. The chain below shows how those pieces fit together, and each stage gives us something we can inspect.

What happens between opening a program and seeing a result

On storageProgram fileinstructions + data

Created by the OSProcessa running program

In memoryActive workinstructions + data

On the processorExecutionone instruction at a time

You click, type, or run a commandThe computer changes something or shows a result

Linux commands, source code, executable files, memory, and machine instructions give us different views of that chain. Connecting them is the work of this course. Later in the series, we’ll use that foundation to investigate failures and their security consequences. Here, the first job is to explain what the computer actually did.

None of that has to make sense to you yet, and none of it is a prerequisite. You can start this course with no Linux experience, no programming background, and definitely no mysterious natural gift for computers. We’ll build the vocabulary, the tools, and the mental models in the order we need them.

So what do I mean by “systems foundations”?

When I say computer system, I mean more than the hardware. I mean the operating system, the files, the running processes, the languages and libraries, the executable files, memory, and all the interfaces gluing them to each other.

This is not a computer science degree crammed into a website, and I am not going to pretend otherwise. It is the practical slice of computer science you need in order to answer questions like these:

Where am I in the filesystem, and what am I allowed to change?
What is the difference between a program on disk and a process in memory?
How does data move through a small Python or C program?
What happens between compiling source code and running the result?
Why does a process have separate regions of memory?
How do function calls, registers, the stack, the heap, and system calls fit together?
What can Linux show us about what happened?
How can we pause a program, locate an incorrect value, and verify a correction?

These are the questions underneath later vulnerability investigations. A permission problem can change how a test runs. A conversion can change the value a program checks. A source-level name doesn’t tell you where its data lives during execution. We’ll make those relationships concrete with small programs you can run and inspect.

Linux gives us one consistent environment to learn in. Python lets us start following program behavior without learning a compiler at the same time. C then makes types, pointers, and storage lifetime explicit. The eventual series isn’t limited to Linux, but we need a starting point where each new layer builds on something you’ve already used.

What you’ll be able to do at the end

By the end of Systems Foundations you should be able to move around a Linux system, read and modify small Python and C programs, and explain how compiled source turns into instructions executing inside a process. You’ll also be able to pause a small C program in GDB, explain an ordinary bug, and test a correction. You’ll connect those explanations to what you can inspect: the filesystem, ELF metadata, process maps, instructions, live debugger state, and system calls.

The Program Investigation Capstone brings those skills together in one small program. After it, a short review points back to any topic you want to practice again.

That is the first milestone in the vulnerability research series, not a claim that you’re already ready to find vulnerabilities in unfamiliar software. Basic debugging belongs here; security-focused investigation, reverse engineering, and assessing security impact come later. Getting these foundations working now means we won’t have to stop those investigations to explain what a process, pointer, or debugger frame is.

The course map

We’ll work through seven stages, and each one hands the next one the vocabulary it needs. The last one asks you to put the connected model together and decide what to go practice next.

Stage	What you’ll learn	Why it matters
1. Start Here	The course workflow, and the habits we’ll use to dig into unfamiliar behavior	A deliberate process turns “it’s broken” into questions you can actually answer.
2. Lab Setup	What a virtual machine is, how to install the course VM, and how to set up its workspace	You need somewhere you can break things and roll them back.
3. Linux Foundations	Files, paths, permissions, processes, shells, streams, and the everyday command-line tools	Separate the program’s behavior from the environment it ran in, and check what actually happened.
4. Programming Foundations	Enough Python and C to read, modify, compile, and test small programs	Follow an input through the decisions and assumptions that determine a program’s result.
5. How Programs Work	Processes, executable files, virtual memory, machine instructions, function calls, the stack, the heap, and system calls	Connect a source-level explanation to the instructions and memory involved in execution.
6. Debugging Foundations	Pausing programs, inspecting live state, explaining ordinary bugs, and verifying corrections	Test your source-level explanation against what the program actually did.
7. Course Complete	The Program Investigation Capstone, a short review, and where to go next	See how the pieces fit together and choose what to explore next.

Early on we’ll name the tool and tell you what to look for. Later lessons hand you a question and expect you to choose from tools you have already used. The scaffolding fades on purpose, but it fades gradually. When a new concept arrives, we’ll give it the support it needs, even if it’s late in the course.

How the lessons and labs work

Follow the example, try the small exercise, and compare your result with the output or explanation on the page. If it differs, use the troubleshooting steps to find where things changed. Questions and hints are there to help you check your understanding.

Labs bring several skills together. Enter the values you find in the labeled answer fields on the page. The check runs in your browser without sending your answers anywhere. Use the hints whenever you need them. If an older archive asks you to assemble a flag, enter those same values in the page’s fields instead.

Notes are optional. Keep the code and working files an exercise uses, and jot down anything you want to remember. There are no reports to submit or hint-use scores. If a versioned lab archive asks for an evidence log or report, use the completion check on its course page; those older writing instructions are optional.

When something doesn’t work

Commands will fail, and programs will do something you didn’t expect. Start with the first result that differs from the example: check the input, the command, and the file you actually ran. Change one thing and try again.

If you’re still stuck, open a hint or revisit the linked explanation. Writing a quick note can help untangle a confusing problem, but you don’t need a log of every attempt.

How to actually work through this

Type the commands yourself. I’d recommend doing that even when copy and paste is sitting right there, because the typing is where most of the small mistakes get made and caught. Change the examples, and guess what the change will do before you run it. Keep notes if they help you remember a command or an idea. If a lesson is easy, clear the checks and move on, and if it’s hard, slow down and don’t file that under failure.

Whatever you do, don’t sprint through the Linux and programming material to get to the assembly. I know it’s tempting, since that’s where the interesting stuff looks like it lives. The assembly lessons use the Linux and programming skills you’ve already practiced. If those still feel uncertain, give them more time before moving on.

Nobody is handing out prizes for finishing quickly. The thing worth having is a foundation you can use in the next research course: choose an observation, understand the system that produced it, and explain what it does and doesn’t establish.

A few things worth bookmarking

The Linux Command Line by William Shotts - A free book with worked shell examples. Use it for extra practice when a Linux topic needs a second explanation.
Linux man pages online - A searchable collection of Linux manual pages. Check your installed version when the documented behavior differs. We’ll be reading plenty of these, and they get much less intimidating with practice.
pwn.college - Free security education from Arizona State. This isn’t a prerequisite for anything here, but if you finish a lesson and want more Linux practice, it’s a great place to burn an evening.

Your next step

Head to What Is a Virtual Machine?, then choose the installation guide for your computer. If you already have the supported VM, check its configuration and continue to the workspace setup.