gdb
Ensure your system generates core dumps on crash (segfault):
Start hacking, the program won't start yet, to be able to configure stuff in gdb first (like breakpoints):
$ gdb program
> start
We can also provide a core dump:
$ gdb program core.dump
We can also start a ASCII UI, to display the source code in a small window, if available:
$ gdb --tui ...
b
function: break(point) on this particular functionThen we can run the program:
r
args: run the program nowWhen we break, we can:
bt
: backtrace, show the stacktrace
si
: step one instruction ahead
step
: step over
next
: step into
c
: continue
list
[function]: display the source code of the given function
i
: info!
i r
: print all the registries and their valuei b
: print all the breakpoints setcond 1 $rdi==0x0
: add a condition on a breakpoint (the value 1 comes from i b)
p
: print!
p/a
[address]: the value at that addressp/x
[register]: the value of the register, as hexset
: set the value of the thing
ret
: returns! "alter" the code by returning now
disas
: dissamble!
disas/s
: with the sourcerecord
: record all the changes to registries from now. Later (on a break, or a crash), it's possible to step backwards and know registries values:
reversestepi
command [n]
: do some command when breakpoint n
is triggered. for instance > record
> continue
> end
rc
: (reverse continue) continue a program being debugged but run it in reverse, need to be record
ed first
Notes:
By default, a lot of symbols won't be known "??".
apt-get install python-dbg
: this provides symbols in gdb, "py-bt", the python stack-trace (instead of the assembly one), "py-list" for the code..Google: "gdb [language]" to find the symbol
It's possible to use python in gdb:
> python print(gdb.breakpoints())