To acquire memory from a VM, you can run one of the aforementioned software tools within the guest OS (VM) or you can perform the acquisition from the hypervisor. This section focuses on VM memory collected from the hypervisor. This technique is typically less invasive (when you perform it without pausing or suspending the VM), because it’s harder for malicious code lurking on the VM to detect your presence. At the end of this section, we’ll also discuss Actaeon, which allows you to perform memory forensics of the actual hypervisor (i.e., analyzing a guest OS directly within the memory of the host).
VMware
If you’re using a desktop product such as VMware Workstation, Player, or Fusion, you just need to suspend/pause or create a snapshot of the VM. As a result, a copy of the VM’s memory writes to a directory on the host’s file system, relative to the .vmx configuration.
If you’re using VMware Server or ESX, you can do this from a vSphere GUI console or on command-line with the scriptable vmrun command (see https://www.vmware.com/pdf/
Part I: An Introduction to Memory Forensics
102
vix160_vmrun_command.pdf). In a cloud environment, the memory dump will likely write to a storage area network (SAN) or Network File System (NFS) data store.
NOTE
Be aware that pausing or suspending a VM is not without consequence. For example, active SSL/TLS connections cannot easily resume after being “frozen.” Thus, although you’re acquiring from the hypervisor, you’re still causing (limited) changes within the VM’s memory.
Depending on the VMware product/version and how the memory dump was created, you might need to recover more than one file for memory analysis. In some cases, the VM’s memory is entirely contained in a single.vmem file (the raw schema). In other cases, instead of a .vmem, you’ll get a .vmsn (snapshots) or .vmss (saved state), which are propri-etary file formats containing memory and metadata (the combined schema). Luckily, Nir Izraeli documented the format well enough to produce an address space for Volatility (see his initial work here: http://code.google.com/p/vmsnparser).
To slightly complicate matters, Sebastian Bourne-Richard recently noticed that VMware products often create a .vmem and one of the structured metadata files (the split schema).
An entirely new address space needed to be written for Volatility to support this schema, because the .vmem contains physical memory runs, but the metadata file indicates how to piece them back together to create an accurate representation of the guest’s memory. In other words, when acquiring memory from VMware systems, make sure to recover all files with .vmem, .vmsn, and .vmss extensions—because it is not easy to know beforehand which ones(s) contain the required evidence.
At offset zero of the metadata files, you will find a _VMWARE_HEADER structure that looks like this:
>>> dt("_VMWARE_HEADER") '_VMWARE_HEADER' (12 bytes)
0x0 : Magic ['unsigned int']
0x8 : GroupCount ['unsigned int']
0xc : Groups ['array', lambda x : x.GroupCount, ['_VMWARE_GROUP']]
For the file to be considered valid, there’s a Magic value that must be 0xbed2bed0,
0xbad1bad1, 0xbed2bed2, or 0xbed3bed3. The Groups member specifies an array of
_VMWARE_GROUP structures that look like this:
>>> dt("_VMWARE_GROUP") '_VMWARE_GROUP' (80 bytes)
0x0 : Name ['String', {'length': 64, 'encoding': 'utf8'}]
0x40 : TagsOffset ['unsigned long long']
Memory Acquisition
103
Each group has a Name that allows the metadata components to be categorized and a
TagsOffset that specifies where you can find a list of _VMARE_TAG structures. A tag looks like this:
>>> dt("_VMWARE_TAG") '_VMWARE_TAG' (None bytes)
0x0 : Flags ['unsigned char']
0x1 : NameLength ['unsigned char']
0x2 : Name ['String',
{'length': lambda x : x.NameLength, 'encoding': 'utf8'}]
These tag structures are the key to finding the physical memory data within the meta-data file. If the VM has less than 4GB of RAM, a single physical memory run is stored in a group named “memory” and a tag named “Memory.” For systems with more than 4GB of RAM, there are multiple runs, also in a group named “memory,” but including tags named “Memory,” “regionPPN,” “regionPageNum,” and “regionSize.” The address space within Volatility (see volatility/plugins/addrspaces/vmware.py) parses these tags in order to rebuild the view of physical memory.
VirtualBox
VirtualBox does not automatically save a full RAM dump to disk when you suspend or pause a virtual machine (as other virtualization products do). Instead, you must create a memory dump using one of the following techniques:
•
The vboxmanage debugvm commands. This method creates an ELF64 core dump binary with custom sections that represent the guest’s physical memory. For more infor-mation, see: http://www.virtualbox.org/manual/ch08.html#vboxmanage-debugvm.•
Use the --dbg switch when starting a VM and then the .pgmphystofile command.This method outputs a raw memory dump. For more information, see https://
www.virtualbox.org/ticket/10222.
•
Use the VirtualBox Python API (vboxapi) to create your own memory dumping utility. A user also attached a Python script named vboxdump.py to the aforemen-tioned ticket #10222 showing an example.The second and third methods produce raw memory dumps, which are natively sup-ported by Volatility. However, the first method generates an ELF64 core dump, which requires special support. Philippe Teuwen (see http://wiki.yobi.be/wiki/RAM_analysis) performed the initial research into this file format and created a Volatility address space that supported them. As a result, Cuckoo Sandbox was able to integrate the ability to save memory dumps from VirtualBox VMs in ELF64 core dump format.
Part I: An Introduction to Memory Forensics
104
The ELF64 files have several custom program header segments. One of them is a
P T _ N O T E (e l f 6 4 _ n o t e) whose name is V B C O R E. The note segment contains a
DBGFCOREDESCRIPTOR structure, which is shown in the following code:
>>> dt("DBGFCOREDESCRIPTOR") 'DBGFCOREDESCRIPTOR' (24 bytes)
0x0 : u32Magic ['unsigned int']
0x4 : u32FmtVersion ['unsigned int']
0x8 : cbSelf ['unsigned int']
0xc : u32VBoxVersion ['unsigned int']
0x10 : u32VBoxRevision ['unsigned int']
0x14 : cCpus ['unsigned int']
This structure contains the VirtualBox magic signature (0xc01ac0de), the version infor-mation, and number of CPUs for the target system. If you continue to iterate through the file’s program headers, you’ll find various PT_LOAD segments (elf64_phdr). Each segment’s
p_paddr member is a starting physical memory address. The p_offset member tells you where in the ELF64 file you can find the chunk of physical memory. Finally, the p_memsz
tells you how big the chunk of memory is (in bytes).
NOTE
For more information on the VirtualBox ELF64 core dump format, see the following web pages:
•
ELF64 core dump format: http://www.virtualbox.org/manual/ch12 .html#guestcoreformat•
VirtualBox source code header file: http://www.virtualbox.org/svn/vbox/trunk/include/VBox/vmm/dbgfcorefmt.h
•
C source code that creates the ELF64 core dump files: http://www.virtualbox .org/svn/vbox/trunk/src/VBox/VMM/VMMR3/DBGFCoreWrite.cppQEMU
QEMU is very similar to VirtualBox in that it saves VM memory in the ELF64 core dump format. In fact, the only major difference is that the PT_NOTE name is CORE rather than
VBCORE. You can create these dumps by using virsh, a command-line interface to libvirt (http://libvirt.org/index.html). There’s also a Python API, which Cuckoo Sandbox (http://www.cuckoosandbox.org/) currently uses to create memory dumps of infected QEMU VMs.
Memory Acquisition
105
Xen/KVM
The LibVMI project (https://github.com/bdpayne/libvmi) is a VM introspection library that supports the Xen and KVM hypervisors. In other words, you can perform real-time analysis of running VMs without executing any code inside the VM. This is a powerful capability for live antivirus and rootkit scanning, as well as general system monitoring.
As an added bonus, the project includes a Python API (pyvmi) and a Volatility address space (PyVmiAddressSpace) for analyzing the memory.