libvmi volatility plugin does not produce compatible memory dumps with `volatility imagecopy`

[redspot]

I am using: lbvmi 0.13 libvmi-python 3.4 volatility 2.6.1

When I use volatility -l vmi://domain pslist everything works as expected. When I use volatility -l vmi://domain imagecopy -O domain.memdump.raw then do volatility -f domain.memdump.raw pslist I get an error about not finding a suitable address space, although psscan does work, which doesn't help me since I need volatility ... impscan --pid 1234.

I tested a memory dump created by virsh dump, then converted it via volatility -f virsh.dump imagecopy -O virsh.raw with KVM based VMs. and, then tried volatility -f virsh.raw pslist which works as expected.

In addition, the xenlight command xl dump-core produces elf-based memory dumps that are NOT compatible with volatility. As a matter of fact, I don't know who would ever use xl dump-core since it's not compatible with anything.

In the end, I need a way to get a memory dump from a running/paused Xen VM that is compatible with volatility. Can you help me out?

[tklengyel]

Did you try https://github.com/libvmi/libvmi/blob/master/examples/dump-memory.c?

[redspot]

I have now tried vmi-dump-memory tool, which did work. Although, it does produce dumps that are not sparse. I did make a small change: the part that writes a page of zeroes was made to instead fseek(f, SEEK_CUR, PAGE_SIZE), which makes the image sparse.

I still would like to know why the volatility plugin did not work. And, it would help future troubleshooters find answers as well. So, I wouldn't call this issue closed just yet.

[redspot]

Also, I did some performance tests using volatility imagecopy and vmi-dump-memory. volatility produced a 2.1GB sparse dump of a 4GB VM in about 21 seconds. vmi-dump-memory produces the same, with my small sparse change, in about 31 seconds. specs: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz

i did try some output buffering using setvbuf() which didn't help. Perhaps, its input bound. Any insights?

[redspot]

I created PR https://github.com/libvmi/libvmi/pull/894 for the fseek() change.

[redspot]

Any updates/insights on the Volatility integration issue?

[Wenzel]

@redspot I will take a look at this issue next week.

[Wenzel]

@redspot from what I see, imagecopy and virsh are producing 2 different dumps. imagecopy produces raw data, whereas virsh dump produces an ELF.

I just tried to do virsh dump winxp winxp.elf and then python vol.py -f winxp.elf imagecopy -O winxp.raw on Xen. It turns out that volatility can't deal with either of these files, so even without involving the VMI plugin, I can't use volatility.

Note: you might want to try https://github.com/volatilityfoundation/volatility3, it is actively maintained. I suggest opening a new issue on volatility3 asking them for support on libvirt Xen memory dumps.

I hope this helps.

[redspot]

Ok, It looks like you found out what I found out. If needed, I will follow-up with volatility3.