- Having a single script to automatically run the binary, attach gdb, re-set breakpoints every time you restart your debugging session.
- The main idea is to run your debugging processes on different Tmux panes and let the controller script (also running on another tmux pane) send keystrokes to automate activities on those panes.
- tmux
- If you run your tmux session as non-root user, the system configuration
/proc/sys/kernel/yama/ptrace_scope
should be set to 0 (i.e. runningecho 0 > /proc/sys/kernel/yama/ptrace_scope
as root) to allow attaching gdb to an existing process as non-root user.
- Use
controller.rb
script as the template to orchestrate your debug/exploit development process. You need to execute it in the same tmux session where you plan to run your runner and gdb. - Update CONFIGURATIONS section of the script to match with your setup:
* RUNNER: either the path to the binary being debugged or the wrapper script (see example).
- BINARY_NAME: name of the binary being debugged, it is mainly used by
pgrep
to find the exact PID of running process. - RUNNER_TMUX_PANE and GDB_TMUX_PANE: the identities of tmux panes (in format of
<window_index>.<pane_index>
used for runnning binary and gdb respectively. In the current setup, they are running on the first panes of my first two tmux windows. You are free to organize the panes in your own way (e.g. two panes split vertically on the same window) and update these configurations accordingly. - GDB_STARTUP_COMMANDS: the set of commands you want to run after gdb starts.
- BINARY_NAME: name of the binary being debugged, it is mainly used by