My only lamentation of QEMU is their rapid development. (I did say “only”).
We had an open source CPU emulator (of many CPU arch) called “Unicorn” that was a heavy test instrumentation points inserted widely throughout and into QEMU 4.0. I spent 2 solid years on these dynamic API bindings of Unicorn into QEMU.
It was an awesome piece of SW that allowed us to recreate the behavior of malware.
Asking the QEMU team to insert some 50-odd test points into the QEMU code was proved to be a maintenance nightmare.
Even if it just an #ifdef of C language, it was too “cluttery”, it was still an awesome automated detection of code generation of just the affected malware portion.
I still believe this approach to be a significant tangential vector of prime investing for a startup.
The upstream now has TCG plugins (https://qemu.readthedocs.io/en/latest/devel/tcg-plugins.html) which allow for a degree of instrumentation. The implementation is architecture agnostic and also tested within the code base. There are still features missing but it does provide a base for dynamic analysis of guest code.
The plugins have access to the instruction stream to make architecture specific decisions. What I meant by architecture independent is that it doesn't involve per-guest annotations in the frontends to handle - any guest using the common translator loop (which is all of them now) can be instrumented by plugins.
However I absolutely agree its not currently as full featured as we would like. The next step when I get time is re-factoring the handling of register values in the core QEMU code so we can expose them to the plugins in a clean API.
// shameless ad, mods please delete if it's not permitted //
> It was an awesome piece of SW that allowed us to recreate the behavior of malware.
If you have experience w/QEMU and you are interested in working on it more, my team is doing work with QEMU. For the most part we have tended to focus on architecture-specific stuff but trying to grow our expertise.
We had an open source CPU emulator (of many CPU arch) called “Unicorn” that was a heavy test instrumentation points inserted widely throughout and into QEMU 4.0. I spent 2 solid years on these dynamic API bindings of Unicorn into QEMU.
It was an awesome piece of SW that allowed us to recreate the behavior of malware.
Asking the QEMU team to insert some 50-odd test points into the QEMU code was proved to be a maintenance nightmare.
Even if it just an #ifdef of C language, it was too “cluttery”, it was still an awesome automated detection of code generation of just the affected malware portion.
I still believe this approach to be a significant tangential vector of prime investing for a startup.
https://github.com/unicorn-engine/unicorn