Project 62: Linux Memory Safety Lab

Module: Module 7: Wireless, Systems & Mobile Security  |  Level: Intermediate  | 
Primary tool: GDB + pwndbg + ASLR/NX checks  |  Estimated time: 75–120 minutes

Objective: Observe how modern mitigations (ASLR, NX, stack canaries) change exploitability.

Free lab environment

exploit.education (Phoenix/Nebula, free downloadable VM) — https://exploit.education/

exploit.education provides free, purpose-built virtual machines specifically designed to teach memory-corruption and exploit-mitigation concepts step by step, from the people behind the well-known ‘Nebula’ and ‘Phoenix’ exercise sets. Run entirely offline in a local VM.

Lab workflow

  1. Set up exploit.education’s free VM — a purpose-built, offline exploit-education VM — and confirm it boots and is reachable only from your host.
  2. Using GDB + pwndbg + ASLR/NX checks, work through the exercise with the specific goal of learning to observe how modern mitigations (ASLR, NX, stack canaries) change exploitability.
  3. At every step, write down what you expected to happen before running the command, then what actually happened — the gap between the two is where the real learning is.
  4. Once you reach the milestone (a crash, an offset, a confirmed mitigation), capture the exact evidence before moving on.
  5. Explain, in your own words and without copying documentation, why the underlying mechanism works the way it does.
  6. Note explicitly which mitigations were enabled or disabled for this exercise, and how that changed the difficulty.

Evidence & screenshot requirements

Submit the following with your report (see this module’s practical assignment for exact upload details):

  • `checksec` output for the target binary showing which mitigations are enabled
  • your written explanation of how each enabled mitigation specifically blocks a classic stack-overflow exploit

Expected deliverable

A concise lab-report entry containing: scope/target, exact commands or payloads used, your key
observation, the required screenshots above, and — where applicable — the specific remediation for what
you found. Vague answers (“sanitize input”, “use a firewall”) without naming the exact mechanism will not
receive full credit.

Safety & authorization

Only test the specific free lab target named above, or infrastructure you personally own. Do not target
third-party systems, real user accounts, or production services without explicit written authorization.
Never deploy anything from this project outside an isolated lab environment.