GSoC (Google Summer of Code) Phase1 has been finished. This post is to outline the work completed during
the Phase1 period and show you an overview of radare2 Timeless Debugger.
Project link: Timeless Debugging Support for radare2 project
To illustrate the architecture of r2 Timeless Debugger, Firstly I need to explain, “What is Timeless Debugging?”.
Timeless Debugging is a new paradigm of debugging, that is very similar to Reverse debugging or Record and Replay. It observes a binary at any point of its execution state by saving entire execution log. For example, QIRA execute every operations, like
mov rax, [0x1000] by QEMU and records each logs like,
Write [0x1000] to rax. After all recordings, user can restore each program states at any point of binary by using these records.
r2 Timeless Debugger
In GSoC term, I’m working on full scratch implementation of r2 Timeless Debugger.
This section show you an overview of r2 Timeless Debugger and what I have done during the past four weeks.
Record and Replay
The architecture of r2 Timeless Debugger is fundamentally based on traditional debugging concept, Record and Replay (RnR). In RnR, firstly you need to run debuggee process and record non-deterministic behavior.
NOTE: Only non deterministic events need to be recorded, because deterministic events can be reproduced by running actual program.
After that, you can restore execution state at any point of the program. That’s how, traditional RnR functions like,
reverse-continue of gdb are working correctly.
r2 Record and Replay
At first, I’ve implemented r2 recording functions for deterministic events. r2 has now new command
dts, that saves current state of memory and register (named “trace session”). And you can also use new command
dsb for debug step back, same as
reverse-next in gdb, by restoring previous trace session saved by
dts and execute forward from it to desired point. That’s how all deterministic events can be replayed and seek program counter one step to backward correctly.
Now Let’s see the actual usage.
At first, you need to save trace session at any points you like by
OK. Now, a trace session at
0x00400526 point is saved. You can seek back and forward in the code area after this address.
Diff-style format for recording
Trace session can saved any time you like by
dts+. Each session have memory and register state at the point in which it’s saved.
dts+ command doesn’t save entire memory dump for each session. Instead, it saves only different memory pages from previous trace session, called diff-style format.
(Trace session architecture internal.)
Let’s see this feature.
You can use
dts command to show the all list of trace sessions.
(Using same program above.)
As you can see the result of
dts, session 1 saves only different pages from previous session 0.
It saves memory space.
If you run
dsb command just after long loop, you would find that perfomance become very slow. :(
So I’ve implemented simple checkpoint system, that can automatically save trace sessions among long execution.
But it’s WIP and feature work…
Following tasks are what’s in for the upcoming weeks.
- Write more tests for
- Export trace sessions as a database
- Add debug continue back command