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?

zetavolt
  • 1,213
  • 11
  • 12
  • 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. – zetavolt 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
  • @PeterAndersson: voted to reopen. Yes, I think debuggers and their underlying technology in the form of dynamic analysis are indeed part of reverse engineering as a whole and RCE specifically. – 0xC0000022L Mar 25 '13 at 18:27
  • @0xC0000022L, while it is of interest it isn't really reverse engineering imho. I personally find it interesting but I'd probably ask on the GDB mailing list. – Peter Andersson Mar 25 '13 at 19:44
  • 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. – zetavolt 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 'SO- stop being evil' Mar 25 '13 at 21:34

1 Answers1

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
Community
  • 1
Igor Skochinsky
  • 36,553
  • 7
  • 65
  • 115