Welcome & Course Map

Start HereLesson 1 of 220 minutes

Learning objectives

By the end of this lesson

• Explain what vulnerability research and exploit development mean in this course.
• Describe how the course builds from Linux fundamentals to independent research.
• Explain how examples, checkpoints, labs, and flags fit together.
• Choose a sustainable way to work through difficult material.

Hacking is not magic

This is an introductory course on vulnerability research and exploit development—or “hacking,” if you are from the universe of The Matrix.

In television and movies, hacking is usually the realm of wizards and child prodigies. Someone sits down at a computer, types very quickly, announces that they are “in,” and gains control of a satellite before the progress bar finishes. The implication is that this is something you can just do if you were born with the gift.

That makes the field look almost impossible to enter. To make matters worse, there are relatively few resources that walk a completely new learner through the whole process. A lot of people learn by banging their heads against the wall for several years until a few ideas begin to leak through.

The good news is that there is no gift. Vulnerability researchers are not performing magic; they have accumulated a collection of technical skills and learned how to apply them when software behaves in an unexpected way. Those skills are difficult, but they are teachable.

This course is designed to teach them in the order you actually need them.

Key concept

The goal is not to memorize hacker commands

The goal is to develop a research process: form a question, gather evidence, update your explanation, and repeat. Tools will change. That process will remain useful whether you are investigating a small Linux program, a network service, or eventually a Windows kernel driver.

What vulnerability research means here

Vulnerability research is the process of understanding how software behaves, identifying where its assumptions break down, and deciding whether those failures create a security problem.

Exploit development is the next step: taking a vulnerability and demonstrating that it can be used to produce a controlled result. That might mean reading data that should be private, changing a program’s behavior, or gaining additional privileges on a system.

Finding a crash is not the same as understanding a vulnerability, and understanding a vulnerability is not the same as writing a reliable exploit. We will work through those distinctions rather than jumping straight to the dramatic part at the end.

The course begins with Linux because it gives us a relatively transparent environment for learning the skills that make research possible: navigating a system, reading small programs, observing execution, understanding memory, and documenting evidence. Windows material will appear later, once it adds something useful instead of burying the lesson under another mountain of terminology.

What this course is designed to do

This course assumes very little technical experience. It does not assume that you already know Linux, can write code, understand assembly, or have spent your teenage years reverse engineering video games. We will build those prerequisites as we need them.

By the end, you should be able to approach an unfamiliar program and begin answering useful questions:

• What does this program expect from its input?
• Where does that input go?
• What assumptions does the program make about its size, type, or contents?
• What happens when one of those assumptions is wrong?
• Can we reproduce the behavior and explain it with evidence?
• Does the failure give us enough control to build an exploit?

That is a long way from where we are starting. We will get there by adding one layer at a time.

The course map

The course is divided into seven stages. Each stage provides tools and mental models needed by the next one.

Stage	What you will learn	Why it matters
1. Start Here	Ethics, scope, lab safety, and how to approach the course	Research is only useful when it is authorized, reproducible, and safe.
2. Virtual Machines	Hosts, guests, hypervisors, snapshots, and creation of the course VM	A controlled and recoverable environment gives us somewhere safe to make mistakes.
3. Linux Foundations	Files, paths, permissions, processes, shells, and common command-line tools	Before investigating a system, you need to move through it without getting lost or destroying the evidence.
4. Programming Foundations	Enough Python and C to read, modify, compile, and test small programs	Source code gives us a controlled way to see how data moves and where assumptions enter a program.
5. How Programs Work	Memory, machine code, processes, executable files, and operating-system boundaries	Vulnerabilities often live in the gap between what source code appears to do and what the machine actually does.
6. Debugging & Reverse Engineering	GDB, disassembly, decompilation, breakpoints, registers, and runtime observation	These tools let us gather evidence from programs we do not fully understand—or do not have source code for.
7. Finding Bugs	Target selection, attack surfaces, crash triage, root-cause analysis, exploitability, and reporting	This is where the individual skills become a repeatable vulnerability research workflow.

Early lessons will tell you which tool to use and what to look for. Later lessons will give you a target and expect you to decide what evidence you need. The scaffolding disappears gradually; it will not vanish before you have practiced the skills underneath it.

How lessons and labs work

Most topics follow the same pattern:

1. We start with a practical question.
2. We build the smallest example that can answer it.
3. You predict what the system will do.
4. We run the example and inspect the result.
5. You explain what the evidence tells us.
6. A short exercise changes one part of the example.
7. A larger lab asks you to apply the skill to a less familiar target.

Labs contain flags in the following format:

UNDERDUNN{something_you_discovered}

The course publishes a SHA-256 hash for each expected flag. You can hash your answer locally and compare the result without sending it anywhere. A matching hash confirms that you found the expected result; your notes should explain how you found it.

Checkpoint

A flag is a checkpoint, not the whole solution

It is possible to reach the right answer for the wrong reason. Keep a short evidence log containing the commands you ran, the relevant output, what you think it means, and what you plan to test next. The habit matters more than collecting a string from a file.

Getting stuck is part of the method

You will get stuck. Commands will fail, programs will crash somewhere unexpected, documentation will make sense only after the third reading, and sometimes an entire afternoon will disappear because of one incorrect character. This is normal vulnerability research, not evidence that you are missing the gift.

When something does not behave as expected, resist the urge to immediately copy a solution. Write down:

• what you expected to happen;
• what actually happened;
• what evidence shows the difference;
• what could explain that difference;
• the smallest next test that could rule out one explanation.

If you have made several deliberate attempts and still cannot move forward, use a hint. Hints are part of the course. The important distinction is whether you use one to resume your investigation or use it to avoid investigating at all.

Key concept

Feeling stuck is part of the method

Confusion is not a detour from learning vulnerability research. Learning how to turn confusion into a specific question is one of the central skills of the field.

How to approach the course

Do not rush through the lessons to reach exploitation. The early material may feel less exciting than controlling an instruction pointer, but exploit development becomes miserable when every Linux command, line of C, and debugger message introduces a second mystery.

Type the commands yourself. Change the examples. Make predictions before running them. Keep notes in your own words. If a lesson is easy, complete the checkpoint and move on. If it is difficult, slow down without treating that as failure.

There is no prize for completing the course quickly. The useful outcome is being able to approach a program you have never seen before and know how to begin.

Knowledge check

Question 1 of 3

What is the main skill this course is trying to develop?

Memorizing a large collection of hacking commandsA repeatable process for asking questions and gathering evidenceWriting an exploit before learning how the target works

Check answer

Your next step

Continue to Don’t Get Arrested. We will define the legal and ethical boundaries for the course and make sure our experiments stay on systems that volunteered to be experimented on. After that, we will build the virtual machine used for Linux Foundations.