How Time Travel Debugging Works in ZathuraDbg

ZathuraDbg implements time travel debugging by recording execution state as you step through a program, so you can step backward through instructions while keeping memory and stack contents intact. According to the project, this works with only a few megabytes of overhead. It applies to programs you run inside ZathuraDbg's emulation-based environment — not to live processes or arbitrary binaries, since the debugger does not currently support debugging binaries at all.

The mechanism in plain terms

ZathuraDbg is an emulation-based debugger built on the Icicle emulator, with Capstone for disassembly and Keystone for assembly. Because execution happens inside an emulator rather than on the real CPU, the debugger controls every state change. That control is what makes backward stepping possible: instead of only moving the instruction pointer forward, it can restore a previously recorded state.

The three properties the project highlights map directly onto this design:

• Step backward through execution — you can reverse past instructions you have already executed, rather than restarting the program to reach an earlier point.
• Memory and stack integrity preserved — when you step back, the memory and stack contents are restored along with the instruction position, so the earlier state is consistent rather than partially rewound.
• A few megabytes of overhead — the recorded state is kept small enough that time travel does not require a large memory budget.

What this looks like in practice

A typical use case is tracking down where a register or memory location took on a wrong value. For example, you step forward through a loop, notice a value is incorrect, and then step backward instruction by instruction to find the exact point where it changed — without setting a breakpoint in advance or re-running from the start. The built-in hex editor complements this: you can edit memory live while code runs and observe the effect, then step back if the edit produces an unexpected result.

Conditions and limits to keep in mind

The binary and syscall limitations matter for time travel specifically: because ZathuraDbg emulates assembly rather than attaching to a running program, the backward-stepping feature is scoped to code you load and run inside the emulator. If your goal is to reverse through a real process or a system call-heavy program, the current feature set will not cover it.

When to choose it

ZathuraDbg's time travel debugging is a good fit if you are learning assembly or reverse engineering small assembly programs and want to move backward through execution without re-running. It is a poor fit if you need to debug compiled binaries, rely on OS-level APIs, or work on an architecture outside the four currently supported.