Does ZathuraDbg Support Syscalls and OS-Level APIs?
No — not fully. ZathuraDbg's own FAQ states that it "does not fully support a ton of syscalls and OS-level APIs," though implementation for common syscalls is under development. If your goal is to trace a program that depends heavily on OS services (file I/O, process management, networking), ZathuraDbg is not yet the right tool for that job. If you're learning assembly by stepping through self-contained code, the limitation rarely gets in your way.
Why the gap exists
ZathuraDbg is an emulation-based debugger, powered by the Icicle emulator along with the Capstone and Keystone engines. It executes instructions inside its own emulated environment rather than running them on your actual operating system.
That design choice explains the syscall situation:
- A real syscall is a request from your program to the host OS kernel — open a file, allocate memory, write to a socket.
- In an emulator, there is no kernel on the other end of that instruction unless the debugger explicitly intercepts the call and fakes a response.
- Each syscall needs its own emulated handler, which is why support arrives incrementally rather than all at once.
The same architecture also explains a related limitation in the FAQ: ZathuraDbg does not currently debug binaries. It works on assembly code you load into the emulator, not on compiled executables that expect a full OS runtime.
What this means in practice
| Your task | Works well today? |
|---|---|
| Stepping through hand-written assembly to learn instructions | Yes |
| Watching registers, stack, and memory change as code runs | Yes |
| Editing memory live with the built-in hex editor | Yes |
| Stepping backward through execution (time travel debugging) | Yes |
| Running code that opens files or makes network calls | Not reliably |
| Debugging a compiled binary | No |
The emulation model is also what makes ZathuraDbg's other features possible — time travel debugging with only a few megabytes of overhead, and no setup required to start debugging. You trade OS integration for a controlled, replayable environment.
If you need syscall behavior
Two practical options:
- Check for updates. The FAQ frames common syscall support as "under development," so this is a moving target. The project is open source and ships updates (version 1.0 is out), so the supported set can grow between releases.
- Use a native debugger for OS-dependent work. If your exercise depends on real syscalls, a debugger that runs your program on the actual OS will handle them by definition. ZathuraDbg is aimed at the learning and assembly-editing use case, not at reproducing a full OS environment.
Quick check before you commit
Before building a workflow around ZathuraDbg, ask whether your code needs the OS at all. Pure register/stack/instruction exercises: go ahead. Anything that calls into the kernel: verify the specific syscall you need is handled, or plan on a different tool.