UndoDB, My head hurts.

Dave G. | May 25th, 2006 | Filed Under: Reversing

UndoDB: a debugger that runs C/C++ code bidirectionally. Forwards and backwards. Backwards and forwards. Please dont be a hoax.

UndoDB uses the ubiquitous gdb as its front-end […] gdb has been complemented with a few new commands which work just like gdb’s existing commands, only they step the program backwards in time, rather than forwards. […] UndoDB also compliments gdb’s next, until, finish, stepi and nexti commands with their backwards counterparts: bnext, buntil, bfinish, bstepi and bnexti, respectively.

My plan: run this on itself and cause a rift in the space-time continuum.

8 Comments so far

  • Josh Daymont

    May 26th, 2006 10:14 am

    Great news, it’ll be really interesting to see if these new features are compatible with gdb scripting, which has got to be the most powerful (and underused) feature in the debugger. I can’t imagine why it wouldn’t be compatible but who knows. Hopefully it is only a matter of time before someone adds the same to Ollydbg.

  • Thomas Ptacek

    May 26th, 2006 6:46 pm

    I call Shenanigans. SHENANIGANS! What about system calls and other irreversable side-effects buried in libraries?

  • Josh Daymont

    May 30th, 2006 11:11 am

    Linked in code is linked in code, there’s nothing in a library that will keep someone from journaling the execution of a program and implementing an Ctrl-Z style undo command. As for system calls, the results from these can be stored and “played back” as well. Obviously the jury is still out on whether thes folks have actually done a complete job of building a forwards backwards debugger, but nothing they claim to have done is intractable by any stretch.

    You want something complex? Read up on some of the instruction pipelining that goes into CPU’s these days. It makes this stuff look like child’s play.

    Now will such a debugger require 10times or more the memory of a typical gdb process? I’d be surprised if it didn’t, but even at a 10x bloat factor it is still a very usable program.

    A really cool feature would be to wipe out the forward instruction memory; so that I can run an application to point X, step backwards three instructions, then instead of re-executing forwards in exactly the same way using the cached results, i clear all execution traces forward (but not backward), re-set some variables and let it go off in a totally different direction.

  • jacob

    May 30th, 2006 5:57 pm

    “As for system calls, the results from these can be stored and “played back” as well.”

    Um, no. There’s a bit more involved than saving return values. Tell me, for instance, how you would rewind a call to read() on a socket?

    Perhaps while you’re reading about all of your complex pipelining you should read up on how an operating system works.

  • Greg Law

    May 31st, 2006 5:36 am

    Hi,

    I’m one of the developers of UndoDB, and just stumbled across this log. I can assure you, it’s not shenanigans :-) I’d encourage you to go download a trial version from http://undo-software.com/ and see for yourself.

    It uses less memory than you might image (though exactly how much varies quite a lot, depending largely on how much I/O your program does).

    Cheers,

    Greg

  • Josh Daymont

    June 2nd, 2006 3:01 pm

    Jacob: Rather than respond directly I will let your argument rest on its merits.

    I stand by what I said, storing the inputs and ouputs of a system call, such as ‘read’ or, if you want to get really fancy, something like ’select’, or ‘mmap’, is easily done in the context of fully journaling the execution of a program.

  • blah

    June 6th, 2006 3:44 am
  • Richard Johnson

    June 7th, 2006 7:03 pm

    Note the ‘Other bidirectional debuggers’ section on their website. Simics is an emulator and reverse execution is certainly easier and more ideally implemented when you can easily instrument the processor and devices on the system. There is a whole set of programs currently working on the aspects of how to restore the system’s internal state of a running process - checkpointing - and this is typically accomplished with aid of a kernel module. cryopid is one notable software that actually works most of the time and continues to be maintained.

  • Leave a reply