volatility error: no suitable address space mapping

[John Floren]

I compiled qemu with the libvmi patch, and now volatility works much better--I get a process list in a few seconds instead of 90 seconds. However, it seems that after running volatility a few times, it just stops working:

john@vigo:~/volatility-2.0$ time sudo python vol.py --profile=Win7SP1x86 -l vmi://testwin7 pslist
Volatile Systems Volatility Framework 2.0
No suitable address space mapping found
Tried to open image as:
 WindowsHiberFileSpace32: No base Address Space
 WindowsCrashDumpSpace32: No base Address Space
 JKIA32PagedMemory: No base Address Space
 JKIA32PagedMemoryPae: No base Address Space
 IA32PagedMemoryPae: Module disabled
 IA32PagedMemory: Module disabled
 PyVmiAddressSpace - EXCEPTION: Init failed
 FileAddressSpace: Location is not of file scheme


real    0m4.516s
user    0m2.620s
sys     0m0.116s

Prior to this point, I had run "pslist" and "netscan". If I shut down the VM and restart it, volatility will work a few more times. I recall a mention in the README that the qemu patch can be unstable; is this what I'm seeing?



John Floren

[Bryan D. Payne]

> I recall a mention in
> the README that the qemu patch can be unstable; is this what I'm seeing?

Is the VM (or the qemu device model) crashing? This is what I've
typically seen with the stability problems.
-bryan

[John Floren]

No, the VM stays up

> --
> You received this message because you are subscribed to the Google Groups "vmitools" group.
> To post to this group, send email to vmit...@googlegroups.com.
> To unsubscribe from this group, send email to vmitools+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/vmitools?hl=en.
>

[John Floren]

I'm not using the latest version from the repo, rather, I'm on
libvmi-0.8. I will fetch the newest version and try that as well

[Bryan D. Payne]

> I'm not using the latest version from the repo, rather, I'm on
> libvmi-0.8. I will fetch the newest version and try that as well

It's hard to say what's happening without seeing more debug output.
But, I suspect that this is related to the instability of the qemu
patch. I'd really like to get a better mechanism in place for KVM
access. If this is something you'd like to work on, please let me
know! :-)

-bryan

[John Floren]

> --
> You received this message because you are subscribed to the Google Groups "vmitools" group.
> To post to this group, send email to vmit...@googlegroups.com.
> To unsubscribe from this group, send email to vmitools+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/vmitools?hl=en.
>

I enabled the debugging output, here's what shows up:

john@vigo:~/volatility-2.0$ sudo python vol.py --profile=Win7SP1x86 -l
vmi://win7-2 pslist
[sudo] password for john:

Volatile Systems Volatility Framework 2.0

LibVMI Version 0.9_alpha
--found KVM
LibVMI Mode 4
--got id from name (win7-2 --> 7)
**set image_type = win7-2
--libvirt version 9011
--qmp: virsh qemu-monitor-command win7-2 '{"execute": "pmemaccess",
"arguments": {"path": "/tmp/vmiWKikpn"}}'
--kvm: using custom patch for fast memory access
--connect() failed to /tmp/vmiWKikpn

No suitable address space mapping found
Tried to open image as:
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
JKIA32PagedMemory: No base Address Space
JKIA32PagedMemoryPae: No base Address Space
IA32PagedMemoryPae: Module disabled
IA32PagedMemory: Module disabled
PyVmiAddressSpace - EXCEPTION: Init failed
FileAddressSpace: Location is not of file scheme

I'm working on chasing this down, the specified socket certainly
exists... but for some reason after a VM has been booted, once I run
volatility a few times, I start to get this error.

[Bryan D. Payne]

> --qmp: virsh qemu-monitor-command win7-2 '{"execute": "pmemaccess",
> "arguments": {"path": "/tmp/vmiWKikpn"}}'
> --kvm: using custom patch for fast memory access
> --connect() failed to /tmp/vmiWKikpn

This says to me that qemu crashed. Or, at least the thread running
the libvmi memory access stuff.

-bryan

[John Floren]

Well, the VM is still running, and QEMU seems ok, so I'd guess it's
just the handler thread. I *did* have to make a few little tweaks to
the patch to get it to compile with the current qemu, but I don't
remember anything that might cause this. I'll double-check, then I
guess it's time to break out gdb.


John

[Bryan D. Payne]

> Well, the VM is still running, and QEMU seems ok, so I'd guess it's
> just the handler thread. I *did* have to make a few little tweaks to
> the patch to get it to compile with the current qemu, but I don't
> remember anything that might cause this. I'll double-check, then I
> guess it's time to break out gdb.

I'm confident that this is nothing you did. The code is buggy right now.
-bryan

[John Floren]

An interesting new thing I noticed: I boot up a VM, the system is at a
pretty low load. Once I run volatility, say to do a "pslist", two QEMU
threads jump to 100% CPU time and stay that way until the machine is
shut down.

john