Debuggers are implemented as IO plugins. Therefore, rizin can handle different URI types for spawning, attaching and controlling processes. The complete list of IO plugins can be viewed with
rizin -L. Those that have "d" in the first column ("rwd") support debugging. For example:
r_d debug Debug a program or pid. dbg:///bin/ls, dbg://1388 (LGPL3) rwd gdb Attach to gdbserver, 'qemu -s', gdb://localhost:1234 (LGPL3)
There are different backends for many target architectures and operating systems, e.g., GNU/Linux, Windows, MacOS X, (Net,Free,Open)BSD and Solaris.
Process memory is treated as a plain file. All mapped memory pages of a debugged program and its libraries can be read and interpreted as code or data structures.
Communication between rizin and the debugger IO layer is wrapped into
system() calls, which accept a string as an argument, and executes it as a command. An answer is then buffered in the output console, its contents can be additionally processed by a script. Access to the IO system is achieved with
=!. Most IO plugins provide help with
=!help. For example:
$ rizin -d /bin/ls ... [0x7fc15afa3cc0]> =!help Usage: =!cmd args =!ptrace - use ptrace io =!mem - use /proc/pid/mem io if possible =!pid - show targeted pid =!pid <#> - select new pid
In general, debugger commands are portable between architectures and operating systems. Still, as rizin tries to support the same functionality for all target architectures and operating systems, certain things have to be handled separately. They include injecting shellcodes and handling exceptions. For example, in MIPS targets there is no hardware-supported single-stepping feature. In this case, rizin provides its own implementation for single-step by using a mix of code analysis and software breakpoints.
To get basic help for the debugger, type 'd?':
Usage: d # Debug commands | db[?] Breakpoints commands | dbt[?] Display backtrace based on dbg.btdepth and dbg.btalgo | dc[?] Continue execution | dd[?] File descriptors (!fd in r1) | de[-sc] [perm] [rm] [e] Debug with ESIL (see de?) | dg <file> Generate a core-file (WIP) | dH [handler] Transplant process to a new handler | di[?] Show debugger backend information (See dh) | dk[?] List, send, get, set, signal handlers of child | dL[?] List or set debugger handler | dm[?] Show memory maps | do[?] Open process (reload, alias for 'oo') | doo[args] Reopen in debug mode with args (alias for 'ood') | doof[file] Reopen in debug mode from file (alias for 'oodf') | doc Close debug session | dp[?] List, attach to process or thread id | dr[?] Cpu registers | ds[?] Step, over, source line | dt[?] Display instruction traces | dw <pid> Block prompt until pid dies | dx[?] Inject and run code on target process (See gs)
To restart your debugging session, you can type
oo+, depending on desired behavior.
oo reopen current file (kill+fork in debugger) oo+ reopen current file in read-write