Re: [PATCH v12 5/7] plugins: Add memory hardware address read/write API

[Rowan Hart <rowanbhart@gmail.com>]

> My main concern about the long list of caveats for writing memory is the
> user will almost certainly cause weird things to happen which will then
> be hard to debug. I can see the patcher example however it would be
> useful to know what other practical uses this interface provides.
>
Of course! My main personal intent here is to facilitate introspection 
and manipulation of guest state for security analysis. Some examples of 
why the memory/register R/W primitives are necessary here include:

Fuzzing:
- Read registers and memory for tracing control flow, comparison 
operands, and profiled values (e.g. memcmp arguments)
- Write memory to inject test cases into the guest (for me and other 
fuzzer developers, this is the biggest reason!)
- Write registers to reset execution or skip over complex checks like 
checksums
- Read and write memory, and read and write registers, to do basic 
snapshot/restore by tracking dirty pages and resetting them

Virtual Machine Introspection (for malware analysis and reverse 
engineering):
- Read memory and registers to find kernel, analyze kernel structures, 
and retrieve info like process lists, memory mappings
- Read memory and registers to quickly trace malware execution in VM
- Write memory and registers to test behavior under various conditions, 
like skipping into checks (motivating example: what happens if you skip 
into the kill switch statement for WannaCry)

Runtime patching (as in the example):
- Writing memory to patch critical legacy code in production often can 
no longer be built or patched via means other than by applying binary 
patches (this is a real problem for e.g. the government, to the point 
where DARPA ran a program 
https://www.darpa.mil/research/programs/assured-micropatching to work on 
it!)
- Writing registers to skip over broken code, redirect to patch code, etc.

Ultimately, the caveats boil down to "don't modify stuff that's touched 
by currently executing code". I personally don't think that's 
unreasonable (as long as it's in the doc-strings) because for any plugin 
that needs to write memory, ensuring the write consistency is probably 
the easiest problem to solve and people working in this space are used 
to having way worse and jankier workarounds. These plugin functions make 
life way easier for them. I have been in touch with 20+ people from 
various companies and projects (including Microsoft, where I work, as 
well as other big and small tech) all working on plugins that could be 
better if this feature existed, so there is definitely a user-base and 
appetite for it!

The last cool use-case is that this moves us a long way towards cleaning 
up the large number of QEMU forks out there designed for RE and security 
testing like QEMU-Nyx, qemuafl, symqemu, and many more. Instead of 
maintaining forks of QEMU (many of these are based on 4.2.0 or older!) 
folks can just maintain a plugin, which lets them take advantage of 
updates and fixes without giant rebases. My goal is to kill these forks 
and have these projects write small, maintainable plugins instead, and 
the authors are on board :)