DISQUS

Matasano Chargen: UndoDB, My head hurts.

  • Josh Daymont · 3 years ago
    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 · 3 years ago
    I call Shenanigans. SHENANIGANS! What about system calls and other irreversable side-effects buried in libraries?
  • Josh Daymont · 3 years ago
    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 · 3 years ago
    "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 · 3 years ago
    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 · 3 years ago
    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 · 3 years ago
  • Richard Johnson · 3 years ago
    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.
  • sohbet · 4 months ago