Using QEmu monitor interface to extract execution traces from a binary?

Question

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:

• Avatar
• DECAF (successor of TEMU)
• PANDA
• S2E (seems to be a sub-component of Avatar?)
• TEMU (Bitblaze)

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 ?

Answer 1

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.

Answer 2

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).

Update:

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.

http://linuxmogeb.blogspot.sg/2014/08/how-to-trace-qemu-using-lttng-ust.html