## https://sploitus.com/exploit?id=35947CA0-5E17-5E69-983B-A11A4F4F0B82
# Binary Exploitation Mitigation Bypass Lab
A progressive, from-scratch x86-64 Linux binary exploitation lab: four
self-authored vulnerable programs, each adding exactly one more modern
memory-corruption mitigation than the last, paired with a working
exploit that defeats it. Every exploit is verified working end-to-end
(not theoretical) and documented against the published literature the
technique comes from.
| Level | Mitigations Present | Technique | Vulnerability Class |
|---|---|---|---|
| [0](levels/level0_no_protection) | None | Direct shellcode injection | Stack buffer overflow |
| [1](levels/level1_nx_ret2libc) | NX (non-executable stack) | ret2libc / ROP (`pop rdi; ret` → `system()`) | Stack buffer overflow |
| [2](levels/level2_nx_aslr_leak) | NX + ASLR | Format-string info leak → ret2libc | Format string + stack overflow |
| [3](levels/level3_canary_bruteforce) | NX + ASLR + Stack canary | Byte-by-byte canary brute force over a forking TCP server → ret2libc | Stack overflow, remote |
Background theory and references (StackGuard, ROP, PaX ASLR, and the
BROP paper this level-3 technique generalizes into): see
[`docs/mitigations-background.md`](docs/mitigations-background.md).
## Why This Structure
Each level isolates exactly one *newly added* mitigation rather than
stacking all of them at once from level 1 onward, so the connection
between "this defense exists" and "this is specifically what defeats
it" stays legible. Where a later level's exploit needs a capability
already demonstrated in an earlier one (e.g., level 3's final
ret2libc stage), it reuses that level's approach explicitly rather than
re-deriving it, and says so in comments — the new material in each
level is only the mitigation it's built to isolate.
## Requirements
```bash
pip install -r requirements.txt # pyelftools, capstone
```
Everything else is Linux + `gcc` + Python 3 standard library
(`struct`, `socket`, `subprocess`) — no `pwntools` dependency, so the
exploits run in minimal environments.
## Running a Level
```bash
cd levels/level1_nx_ret2libc
make # builds ./vuln with this level's specific compiler flags
python3 exploit.py
```
Level 3 additionally starts and stops its own TCP server as part of the
exploit script — no separate step needed.
## Repository Structure
```
binary-exploitation-mitigation-bypass-lab/
├── levels/
│ ├── level0_no_protection/ vuln.c, Makefile, exploit.py
│ ├── level1_nx_ret2libc/ vuln.c, Makefile, exploit.py, libc_utils.py
│ ├── level2_nx_aslr_leak/ vuln.c, Makefile, exploit.py
│ └── level3_canary_bruteforce/ vuln.c, Makefile, exploit.py
├── docs/
│ ├── mitigations-background.md theory + references per level
│ └── leak-calibration.md how level 2's leak slot was found empirically
├── requirements.txt
└── LICENSE
```
`libc_utils.py` (in `level1_nx_ret2libc/`, reused by levels 2 and 3) computes
gadget addresses, exported symbol offsets, and string offsets directly
from the local `libc.so.6` via `pyelftools` — nothing is hardcoded
against one specific system; only the *local* libc build is inspected
at exploit-build time.
## Related Project
The gadget/symbol/string lookup approach in `libc_utils.py` was later
generalized into a standalone, tested toolkit with a proper
capstone-based gadget scanner (rather than fixed-byte-pattern search):
[**rop-gadget-toolkit**](https://github.com/Yaswanthkobaku09/rop-gadget-toolkit).
## Disclaimer
Every vulnerable program here was authored for this repository and
runs only against itself, on `localhost`/loopback. Nothing in this
repository targets, or is intended to be pointed at, any system the
author does not own. This is an educational/portfolio project, not
production security tooling.
## Author
**Yaswanth Kobaku** — Cybersecurity Professional (Offensive Security / VAPT)