Dynamic instrumentation tools which support reverse execution

Question

I am trying to analyze some execution crash information, and to better identify the root cause of memory access error, I would like to reverse execute the program from the crash point.

For example, to identify the root cause of memory access error below, I would like to reversely execute from the third line, and by leveraging some data flow analysis techniques, I should be able to identify the root cause at the first line.

mov    -0x18(%rbp),%rax       <---- root cause is at memory -0x18(%rbp)
add    %rdx,%rax
mov    (%rax),%eax            <--- crash when reading (%rax)

So here is my question, is there any dynamic analysis tool/debugger that can support reverse execution? I prefer Pin, but I am not aware that Pin can do this..

Answer 1

Have a Look at http://rr-project.org The website says it supports reverse execution. Yet, I am not a 100% sure if this is exactly the same you are talking about.

rr also provides efficient reverse execution under gdb. Set breakpoints and data watchpoints and quickly reverse-execute to where they were hit.

See also the gdb record and replay feature here

On some platforms, gdb provides a special process record and replay target that can record a log of the process execution, and replay it later with both forward and reverse execution commands.

Answer 2

In previous versions of Pin, there was APIs for checkpoint/re-execution; but they are not supported in recent versions. They are instead moved to a more complete framework, called PinPlay.

You can also implement an ad-hoc reverse execution using existing API(s) (e.g. Pin_ExecuteAt, Pin_SaveContext, etc). The naive idea is to track the memory writing and store the original value. I have implemented actually such an engine (sorry for the self-advertisement).

Answer 3

If you have access to IDA, you can use the trace replayer. It doesn't exactly support reverse execution, but I wrote it with the idea to help in the problem you have: check why a crash happened by replaying recorded executions traces. The program is not executing but rather replaying the execution trace, however, in most cases, that is more than enough.