Lion Cipher Lab
Leak libc and pop a shell with ret2libc
- Penetration Testing / Red Team
- Advanced
- ~90 min
- Free · no account required
Why it matters
The ROP lab left you with a chain that only worked because the target handed you a friendly win() and a -no-pie binary, so every address was fixed. Real targets almost never give you both. There is usually no win() at all — but there is always libc, the C standard library every program loads, and libc contains system() and the string "/bin/sh". So you reuse libc: point the first argument at "/bin/sh" and return into system(). That is ret2libc, and it is the technique the ROP lab named as the next rung. The catch is the whole lesson: ASLR (Address Space Layout Randomisation) loads libc at a…
What you'll learn
- understanding WHY a return-into-your-own-binary chain stops working the moment there is no win() and the code you need lives in libc, whose base ASLR randomises on every run
- the two-stage shape of a real ret2libc exploit: a LEAK stage that prints a runtime libc address, then a SECOND stage built against the now-known addresses -- and why one open connection must span both
- building the leak chain by hand: `pop rdi ; ret` to set puts@plt's argument to puts@got, calling puts to print the RUNTIME address of puts, then returning to main to run the overflow a second time
- turning a leaked function address into the libc base with base = leaked_puts - puts_offset, where the offset comes from the exact libc the process loaded (pwntools' ELF, or readelf on libc.so.6)
- assembling the ret2libc stage: `pop rdi ; ret` -> address of the "/bin/sh" string inside libc -> system(), so NX is never in play because you only ever run code that was always executable
- diagnosing and fixing the classic 64-bit movaps SIGSEGV inside system() by inserting one extra bare `ret` gadget to restore 16-byte stack alignment before the call
- the judgment: when you can skip the leak (a win()/one_gadget), when ret2libc is the right tool, and why full ASLR + PIE, Full RELRO, CET/shadow stacks and FORTIFY are what make this hard on real targets
Steps in this lab
- Read this first: still your own machine, still authorized-only
- Where the ROP lab left you — and why that chain now breaks
- The plan: leak an address, do arithmetic, then ret2libc
- Get Linux and the exploit tooling
- Write the vulnerable program — deliberately WITHOUT a win()
- Compile with NX on, canary/PIE off — ASLR LEFT ON
- Find the offset and the gadgets
- Stage 1: leak the runtime address of puts
- Stage 2 and the full exploit: pop a shell with ret2libc
- The shortcut and where it goes further: one_gadget, ret2csu, SROP
- The defenses that make this hard — and clean up