My original point was to build something a bit more powerful and generic than a PTRACE system call for Linux platforms. The problem with PTRACE is that it only run on your own system and architecture.

An idea would be to run a virtual machine (or, better, an emulator) with a different operating system and a (possibly) different architecture on it.

While looking for the ideal candidates, I found the QEmu monitor interface and several projects using QEmu as OS/architecture emulator to collect traces:

The features I want are similar to the PTRACE interface (freeze execution, step by step runs, memory and registers read and write, ...) all with several OSes and several architectures.

My questions:

  • Did I forgot some similar projects in my list ?
  • Can the QEmu monitor interface provide a system/architecture agnostic PTRACE interface just as I want ? And, if not, what are the main issues I might run into while implementing it inside QEmu ?
  • Did you implement this? Can you update on your experience with this?
    – Phani
    Commented Oct 29, 2014 at 3:51

2 Answers 2


PANDA developer here. I think that actually most of the things you want are supported by QEMU's native gdbstub. If you start QEMU with the -s -S options, it will listen on port 1234 for incoming connections, and provide the functionality you want, including:

  • Single-step using the si command
  • Register get/set using info reg and (for example) set $edi = 0x40c8c39
  • Reading memory contents with the x command
  • Modify memory using set *(char *) 0x1a5f2c0 = 0xd9
  • Breakpoints using (e.g.) break *0x826e2671

So using some gdb scripting, I think you should be able to get the capabilities you want with plain gdb and QEMU.

All this was just tested using a Windows 7 32-bit VM and gdb using the target remote :1234 command.

  • Can this setup tell me if an instruction reads from, or modifies memory (and the value that is read/written?). I guess PANDA could do it, right? Commented Mar 15, 2016 at 19:51
  • You can set memory or instruction breakpoints, as you normally would with gdb. You wouldn't be able to watch every memory read with this approach, but you could with PANDA. Commented Mar 15, 2016 at 20:21
  • I posted a related question (regarding PANDA) here: reverseengineering.stackexchange.com/questions/12313/… Commented Apr 1, 2016 at 8:35

Past TEMU user here. Perhaps you should attempt to understand TEMU more (which I don't), to prevent duplicating the work already done. PTRACE only records syscall transitions, but if you go under QEMU, a better granularity is basic blocks. Not sure if TEMU has the capacity to do that, the idea is the each basic block can uniquely identify part of the path taken, without going into lower level of details at the registers/values level. ie, less noise, but more refined than syscall. Knowing the the full state of the registers at each entry and exit point of the basic block, can almost deterministically decide what is the path the entire execution trace will look like, minus all the intermediate registers values, which can be derived if need to. ("almost", because asynchronous event like interrupt can happened).


There is another option: QEmu + Lttng, but since default Qemu does not provide that feature, you have to download the QEMU source code, and compile it to enable lttn-ust tracing.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.