DECAF (short for Dynamic Executable Code Analysis Framework) is a binary analysis platform based on QEMU. This is also the home of the DroidScope dynamic Android malware analysis platform. DroidScope is now an extension to DECAF.
Hello! I built your code with --enable-vmi on Ubuntu 18.04 64-bit and I see a few DLLs successfully scanned for exports when booting Windows 7 SP1 32-bit, so VMI seems to be working. It appears however that snapshots of the running guest do not work properly.
I tried also changing the disk caching policy to unsafe and disabling the USB tablet pointer with no effect. So when I try to capture a snapshot with savevm mysnap and then load it later with command-line option -loadvm mysnap the display is eventually restored correctly (and some VMI info on libraries is displayed) but the machine is left unresponsive. Checking with info cpus I can see the instruction pointer changing, so perhaps it's not totally frozen but I have no clue of what is going on.
To rule out QEMU known problems, I downloaded the tarball for version 1.0.0 that apparently you use in DECAF and compiled it with --target-list=i386-softmmu --disable-docs --disable-kvm --disable-libiscsi --disable-xen (basically I disabled all the components that led to compilation failures on my machine; I also added LIBS+=-lrt to Makefile.target to get around a linking error). Snapshots can be saved and restored correctly for the same image within vanilla QEMU. I tried restoring a QEMU snapshot into DECAF with no luck (guest still unresponsive), while for the other way around QEMU legitimately complains about the DECAF section:
(qemu) Unknown savevm section or instance 'DECAF' 0
qemu-system-i386: Error -22 while loading VM state
Hello! I built your code with
--enable-vmion Ubuntu 18.04 64-bit and I see a few DLLs successfully scanned for exports when booting Windows 7 SP1 32-bit, so VMI seems to be working. It appears however that snapshots of the running guest do not work properly.I run my VM with the following options:
I tried also changing the disk caching policy to
unsafeand disabling the USB tablet pointer with no effect. So when I try to capture a snapshot withsavevm mysnapand then load it later with command-line option-loadvm mysnapthe display is eventually restored correctly (and some VMI info on libraries is displayed) but the machine is left unresponsive. Checking withinfo cpusI can see the instruction pointer changing, so perhaps it's not totally frozen but I have no clue of what is going on.To rule out QEMU known problems, I downloaded the tarball for version 1.0.0 that apparently you use in DECAF and compiled it with
--target-list=i386-softmmu --disable-docs --disable-kvm --disable-libiscsi --disable-xen(basically I disabled all the components that led to compilation failures on my machine; I also addedLIBS+=-lrttoMakefile.targetto get around a linking error). Snapshots can be saved and restored correctly for the same image within vanilla QEMU. I tried restoring a QEMU snapshot into DECAF with no luck (guest still unresponsive), while for the other way around QEMU legitimately complains about the DECAF section: