9

A curious and useful feature of GDB is process recording, allowing an analyst to step forwards and backwards through execution, writing a continuous log of the changes to program state that allow for remarkably accurate playback of program code.

Although we can all safely say the process recording log contains the executable's changes to the various data and control registers, the functionality is much more than keeping some serialized representation of the current continuation. For example, I've been able to reify the state of an executable that uses threads to modify shared memory.

Certainly we can't expect time dependent code to work, but if threading code modifying shared state can, in general, be stepped through backwards and still work reliably again, what limitations does process recording have beyond the purely architectural challenges (i.e displaced stepping) specified in the documentation?

  • Is this really reverse engineering? It seems to me that it relates more to forward engineering and reading code as the GDB source is open. – Peter Andersson Mar 24 '13 at 17:59
  • Point taken, I believe the topic is certainly of interest to reverse engineers so I was banking on it being considered appropriate. – ŹV - Mar 24 '13 at 18:00
  • AFAIK it is based on a relatively new CPU feature in Intel x86 CPUs. It is the same feature that is used for "recording" in VMware. – 0xC0000022L Mar 24 '13 at 22:39
  • 2
    I think we can all agree that the question (generally) is of immediate interest to reverse engineers. Additionally, the chance of receiving a thoughtful and intelligent response relating to this particular question is much greater here than on StackOverflow, which I think merits your consideration Peter. – ŹV - Mar 25 '13 at 19:51
  • 2
    While this question isn't directly about doing RE, it's of particular interest to people doing RE and it's about understanding a tool of RE in a way that helps understand RE techniques. So I think it is on-topic on this site. – Gilles Mar 25 '13 at 21:34
7

The feature is described in a bit more detail on GDB wiki:

How it works

Process record and replay works by logging the execution of each machine instruction in the child process (the program being debugged), together with each corresponding change in machine state (the values of memory and registers). By successively "undoing" each change in machine state, in reverse order, it is possible to revert the state of the program to an arbitrary point earlier in the execution. Then, by "redoing" the changes in the original order, the program state can be moved forward again.

This presentation describes even more of the internals.

In addition to above, for some remote targets GDB can make use of their "native" reverse execution by sending Remote Serial Protocol packets bc (backward continue) and bs (backward step). Such targets include:

  • moxie-elf simulator
  • Simics
  • VMware Workstation 7.0
  • the SID simulator (xstormy16 architecture)
  • chronicle-gdbserver using valgrind
  • UndoDB

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.