| name | pwntools-debug-operator |
| description | Use this when a Codex agent needs to debug a pwn challenge by writing or editing a pwntools exploit script, inserting gdb.attach() at chosen points, and operating the autopwn-session CLI to start, bind, observe, debug, release, and stop tmux-backed pwndbg sessions. |
| metadata | {"short-description":"Operate autopwn-session for pwntools debugging"} |
Pwntools Debug Operator
Use this skill when the task is to actually debug a binary with the installed autopwn-session tool, not to redesign the platform.
Core workflow
- Start with
references/quickstart.md for the minimal end-to-end flow.
- Before writing the script, confirm the real execution target with
ldd and readelf -l. If the binary is already patched to local ld or libc, prefer running the binary directly instead of wrapping it manually.
- If you need to write or patch the exploit script, copy the pattern from
assets/autopwn_bridge.py and the marker contract from references/script-contract.md. Default to an early attach point: gdb.attach() first, then hold("pre"), then drive scripted actions, then hold("post") for inspection.
- Start the exploit with
autopwn-session start.
- Wait until the script reaches the early attach point, then run
autopwn-session bind-debug.
- Use
autopwn-session observe to inspect both tmux panes before sending more commands.
- Set PIE breakpoints with
*$rebase(offset) after the process is live instead of guessing absolute addresses.
- Use
autopwn-session debug-cmd for targeted gdb/pwndbg commands, but prefer stage boundaries and autopwn-session release over long chains of live interactive steering.
- Use
autopwn-session release to unblock hold(tag) gates in the script.
- Stop the session with
autopwn-session stop when the task is done.
What to read when
Extension rule
Do not keep piling logic into repeated debug-cmd calls when the same observation pattern is needed over and over.
Promote it to a structured command when:
- Codex repeatedly sends the same gdb command sequence
- downstream reasoning only needs parsed fields, not raw pane text
- a command should return stable JSON such as registers, memory words, backtrace frames, or current stop location
Prefer adding a new CLI subcommand or session action over teaching every Codex instance to parse free-form gdb text again.