GDB with pwndbg for Pwn Challenges

Plain gdb is a fully capable debugger, but its default output is built for reading C source line-by-line, not for exploit development — no live memory layout, no stack visualization, none of the context a pwn challenge actually needs. pwndbg is a gdb plugin that replaces the default display with exactly that context, shown automatically every time execution stops.

1. Installing it

pwndbg installs itself into your existing gdb config:

git clone https://github.com/pwndbg/pwndbg
cd pwndbg
./setup.sh

From then on, every gdb session automatically loads it — no extra flags needed.

2. What changes immediately

Set a breakpoint and run, and instead of a bare prompt, pwndbg prints a full context view every time execution stops: the next instructions, register values with pointers resolved to what they point at, and a chunk of the stack — all in one screen:

gdb ./challenge
pwndbg> break main
pwndbg> run

That context view is the entire point — you see registers, disassembly, and stack simultaneously instead of querying each with a separate plain-gdb command.

3. Commands built for exploitation

pwndbg adds commands plain gdb doesn't have, tuned specifically for binary exploitation:

vmmap          # show the process's memory map and permissions
cyclic 200     # generate a De Bruijn pattern to find an overflow offset
cyclic -l 0x6161616c   # find that offset from a crashed value
checksec       # show the binary's protections: NX, PIE, canary, RELRO

checksec in particular is usually the first command worth running on any new pwn binary — knowing whether a stack canary or NX is enabled changes which exploitation technique is even possible before you write a single line of exploit code.

4. Finding the crash offset

A classic buffer overflow workflow: generate a cyclic pattern, feed it to the binary, let it crash, then ask pwndbg exactly how far into the pattern the crash happened:

pwndbg> cyclic 200
pwndbg> run <<< $(python3 -c "print('A'*200)")
# after the crash:
pwndbg> cyclic -l $rsp

That number is the exact byte offset where your input starts overwriting the value at that address — usually the return address you're trying to control.

Wrapping up

pwndbg turns gdb from a generic source debugger into something built for exploit development: automatic context, memory-aware register display, and commands like cyclic and checksec that map directly onto the pwn workflow. Pair it with pwntools for scripting the actual exploit once you've found the offset, and see our writeups for full pwn walkthroughs.

← Back to Blog