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:
reversestepicommand [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 recorded 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())