Module 05 — Memory Corruption Primer¶
Type 1 · Concept Autopsy — dissect how a stack-based buffer overflow hijacks execution by overwriting the saved return address, demonstrated against a vulnerable program in your lab. (Secondary: Misconception Reveal — ASLR/canary/NX as the arms-race answer, not a cure.) Go to the hands-on lab →
Last reviewed: 2026-06
Offensive Security — why a program crashes is often why it gets exploited.
In 60 seconds
Memory corruption is different from injection: it's about hijacking the program's own control flow by writing where you shouldn't. The canonical case — overflow a stack buffer, overwrite the saved return address, and the CPU jumps wherever you wrote. Out-of-bounds writes sit at #1 on the CWE most-dangerous list for exactly this reason. You don't need to become an exploit developer, but you need this model so "buffer overflow" stops being a magic phrase and becomes a mechanism — the bedrock under "RCE" in the scariest CVEs.
Why this matters¶
Memory-corruption bugs — buffer overflows and their relatives — are the root of a huge share of the most severe CVEs, and out-of-bounds writes sit at the very top of the CWE "most dangerous weaknesses" list. You don't need to become an exploit developer, but you do need to understand why writing past a buffer hands an attacker control, so a vulnerability class like "stack overflow" stops being a magic phrase.
Objective¶
Explain how a stack-based buffer overflow hijacks execution, and demonstrate one against a simple vulnerable program in your lab.
The core idea¶
Most vulnerability classes so far have been about data crossing a boundary (injection). Memory corruption is different: it's about the program's own control flow being hijacked by writing where you shouldn't. The canonical case: a function keeps its return address on the stack right next to a local buffer; overflow the buffer and you overwrite that saved return address; when the function returns, the CPU jumps wherever you wrote. That's the entire magic trick — "smash the stack" demystified into "overwrite the saved instruction pointer and the processor executes your address." Out-of-bounds writes sit at #1 on the CWE most-dangerous list for exactly this reason.
The mental model
You don't need to become an exploit developer, but you need this model so "buffer overflow" stops being a magic phrase and becomes a mechanism you can reason about — and so you understand why memory-safe languages (Rust, Go) exist and what the mitigations are defending. The practitioner payoff: this is the bedrock under "RCE" in the scariest CVEs. When you read "remote code execution via a heap overflow," this is what's happening underneath — now a mechanism, not a headline.
The gotcha
The mitigations are an arms race, not a cure: ASLR randomises addresses so you don't know where to jump, stack canaries plant a guard value that detects the overwrite, NX marks the stack non-executable. Each raised the bar, which is why modern exploitation is largely about bypassing them — and why real exploits chain several tricks rather than just overflowing a buffer.
AI caveat
A model is a patient tutor for the assembly and the stack diagram (ask it to annotate a disassembly or explain a canary), but generated exploit code for memory bugs is fiddly and version-specific: you will debug it by hand, and that debugging is exactly where the understanding forms.
Learn (~4 hrs)¶
Concept, then hands-on - Intro to Binary Exploitation — Buffer Overflows #0: Intro / Basics / Setup (video) — a beginner-friendly start to how stack overflows work. - pwn.college (Arizona State, free) — work the Memory Errors / Program Security modules; the best free hands-on path into binary exploitation.
Why it matters at scale - MITRE CWE-787 — Out-of-bounds Write — consistently the #1 most dangerous software weakness; the class you're learning.
Key concepts¶
- The stack, the saved return address, and control flow
- What "overflow the buffer" actually overwrites
- Why this hands the attacker the instruction pointer
- Modern mitigations (ASLR, stack canaries, NX) — at a high level
- Memory-corruption classes (overflow, use-after-free, out-of-bounds write)
AI acceleration¶
A model is a patient tutor for the concepts and the assembly — ask it to annotate a disassembly or explain a stack canary. But generated exploit code for memory bugs is fiddly and version-specific; expect to debug it yourself, which is exactly where the understanding forms.
Check yourself
- When you overflow a stack buffer, what exactly gets overwritten that hands you control of execution?
- What does each of ASLR, stack canaries, and NX defend against — and why don't they make a program safe?
- Why is "buffer overflow" a different class of bug from SQL injection?
Comments
Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).