In Part 1 of this series, we examined at a very high level the purpose and benefits of memory forensics, and then took a look at how these types of artifacts appear in BlackLight. In this follow-up entry, we’d like to take a deep dive into issues surrounding memory image acquisition.
Considerations to Keep in Mind
While acquisition/imaging of a hard drive is pretty straightforward in the common case - in a nutshell, removing the drive, attaching to a write-blocker, and making a copy of the stream of bits on the device to some other storage medium - memory acquisition is anything but straightforward. Acquiring a memory image requires more careful consideration of many things, to include the following: the OS involved; the power state of the machine; whether the machine is virtual or physical; access to an account on the machine with root privileges; what output formats are supported by the memory analysis program being used; and the risks inherent in the acquisition. Acquiring a snapshot from a live machine involves reading RAM through some method while the machine is running and constantly changing. In fact, the act of acquiring memory can actually crash the machine!
Early memory acquisition tools were relatively simple. With root/admin privileges, the Linux kernel offered the "/dev/mem" device that could be read from and was equivalent to reading directly from physical memory. Windows previously offered a similar device, "\Device\PhysicalMemory." Over time, access to these devices was removed as it presented significant security concerns.
Modern acquisition tools most often load a driver into the OS kernel, which uses a range of kernel APIs, or other information the system makes available to create a device like "/dev/mem" for reading physical memory from userland. While this may seem simple, it is not. One of the complications is that peripheral device memory is mapped into the system memory address space. This means if you read from certain addresses of "/dev/mem" you may be issuing reads not to system RAM, but to video card memory, PCI ROM memory, or memory areas on other connected peripheral devices. The danger here is that just reading some of these memory ranges can crash the running machine, corrupting the memory image and potentially causing other havoc (e.g., effectively deleting full disk encryption keys stored in memory, or leaving the disk file system in a bad state by corrupting file system metadata). Finding or building safe tools is difficult given the changing landscape of OS architectures at each new OS version release (or patch, or service pack). Because of this, memory analysis examiners must constantly test the performance of the acquisition tools they use - and leverage a suite of tools and related techniques for acquisition depending on the situation.
Many acquisition tools can output a memory image in multiple formats, or provide the ability to convert between formats, and work only on certain OSs. Next we will take a look at common formats, how they are generated, and the advantages and disadvantages of each. Note that this list is not exhaustive.
Memory Image Formats
Raw (or dd)
File Name: user-selected
Common Extensions: .raw, .bin, .dd, .mem
Description: This is the simplest version of an uncompressed byte-for-byte copy of physical memory of a system. Most acquisition tools support this format, and it is basically equivalent to what is captured by copying the "/dev/mem" device of a running system (e.g., using dd). For reasons beyond the scope of this document, the size of the resultant file is often larger than the size of physical RAM installed on the machine that the acquisition came from.
Advantages: All analysis tools can ingest raw images. Because it is an uncompressed raw image, other general purpose utilities can be used for analysis (e.g., strings and grep).
Disadvantages: These images can be very large in some cases. They contain no metadata about the system they came from, like the source machine, or image hash.
Notes: These types of files are not often found lying around on suspects' hard drives, since they must be manually generated by special purpose memory acquisition tools.
File Name: hiberfil.sys (in root of system volume by default)
Common Extensions: .sys
Description: When Windows machines, most often laptops, go into hibernation mode, a copy of RAM is written to the hiberfil.sys file on disk. The file format is somewhat complex, with some parts of the file compressed and some not.
Advantages: These can be created easily with access to a running machine. A dead machine may still have a hibernation file from some point in the past. As it is built-in Windows functionality, it is unlikely to crash the machine.
Disadvantages: The act of hibernating the machine causes Windows to do some cleanup, like closing network connections, making it so that analysis tools cannot show which connections were open at the time of hibernation. The compression makes it so that general purpose file processing utilities are largely useless. Some methods of generating hibernation files could overwrite data on disk (e.g., if hibernation was not previously enabled, then generating a new hibernation file will write to previously unallocated disk space.) Hibernation files past Windows 7 are undocumented, and no tools can currently parse them (although, see this for a glimmer of hope).
File Name: user-generated
Common Extensions: .dmp
Description: Windows contains a kernel and application debugging facility that can be used to generate "crashdumps," which are a dump of physical RAM. These are somewhat similar to raw files in that they are uncompressed, but they additionally contain metadata about the system they came from. Depending on how a crashdump is created, it can store all of physical memory, just kernel memory, or just the memory regions for a specific process (a.k.a. "minidump.")
Advantages: Because Windows generates crashdumps when applications or the kernel crashes (blue screen), there may be historical versions found stored on drives under investigation.
Disadvantages: Not all tools can ingest crashdumps. Some methods of generating crashdumps could overwrite data on disk.
OS: any (guest OS)
File Name: VMWare-generated
Common Extensions: .vmem, .vmss
Description: VMWare virtual machines (and other virtualization technologies that will not be discussed here) have a facility for "snapshotting" a virtual machine instance. When this occurs the entire running state of the system is saved to the VM host, including a snapshot of RAM (to be used on resuming).
Advantages: There is little chance of crashing the running VM instance. It does not require additional software. Also, it does not require software to be run inside the guest OS at all.
Disadvantages: The machine to acquire memory from must already be a virtual machine. The file format for the memory images is proprietary, but many types are documented.
Common Extensions: .aff4
Description: AFF4 is a generic container format based on .zip. When used for memory images, they can contain multiple streams within the single file holding metadata about the contents, and multiple subfiles, and support sparse regions (which exist often in system memory layouts).
Advantages: The files contain metadata about the memory image files themselves, can contain multiple image files (e.g., all the files for a case), and support fast Snappy compression.
Disadvantages: Only a few tools generate or analyze this file type. They are compressed, so standard file-based tools cannot be used to process them.
Filename: pagefile.sys (in root of system volume by default)
Common Extensions: .sys
Description: Though not a copy of RAM per se, Windows uses the pagefile.sys file on disk as swap space, or to temporarily store some pages of memory when a system allocates more memory than will fit in physical RAM. This makes it useful for most of the reasons described in Part One of this series, but it cannot be parsed in the same way.
Advantages: This file exists by default on all Windows systems. Also, by default the file is never cleared (there is a Registry setting to clear on shutdown that is not enabled by default). As it is a disk file, acquisition is perfectly safe. It is uncompressed, so general purpose tools can be used for analysis, and indeed they must be used.
Disadvantages: The file is effectively a random sampling of pages from RAM, without metadata about where the pages came from, processes they belong to, etc., which makes any deep analysis (e.g., parsing out process structures, or full process or kernel memory space) impossible.
Notes: While it may seem that we could find processes, network connections, DLLs, etc., in the Pagefile, many of these types of kernel objects are allocated in the "non-paged pool," which just means they are allocated in memory regions that are never paged out to disk, and thus cannot appear in the Pagefile.
Acquisition in Practice
As we alluded to above there are a number of questions that must be answered to determine the best method of acquiring an image of memory for any given situation. Just a few of the issues include:
- Is the machine currently booted? If not, trying to take a live sample is futile, but there may be crashdumps, or a hibernation file if the machine runs Windows. If the machine was a virtual instance, was it suspended or shut down? A suspended VM may store a copy of RAM as part of the suspend process.
- If the machine is booted, can it be snapshotted or suspended? These methods are less invasive and more stable than loading a tool into the guest OS and trying to take a like RAM capture.
- If the machine is booted and not a virtual instance, what OS and version thereof is it running? Make sure your tool of choice supports that OS/version combination.
- Does the acquisition tool you are about to use output in a format that is compatible with your analysis tool? If not, do you have the proper tools to convert the resultant image?
- Have you/are you able to test the tool/OS/version (and hardware) combination before using it on the live machine you’re investigating?
- If you don’t have physical access to the machine, do you have network access? Some tools can provide the ability to remotely image RAM.
There are a large number of commonly used acquisition tools. Each supports some subset of the formats described above on some subset of OSs and specific OS versions. Some are free, some are open-source, some are expensive, and some are proprietary. Unfortunately, there is no one ring to rule them all. An exhaustive discussion of each is beyond the scope of this article, but some are listed below. You may wish to download multiple tools, explore the differences in functionality, and create your own toolset.
KNTDD: http://www.gmgsystemsinc.com/knttools/ (commercial, non-free, one of the best for Windows memory acquisition)
PMEM: http://www.rekall-forensic.com/docs/Tools/ (free, open-source, works across Windows Linux and OS X, uses AFF4 by default)
FTK Imager also does memory acquisition: http://accessdata.com/product-download (commercial, free, Windows only)
Passmark OSForensics: http://www.osforensics.com/ (commercial, free [trial], can generate crashdumps)
F-Response: https://www.f-response.com/ (can expose physical memory as a readable device across the network)
Imagecopy https://github.com/volatilityfoundation/volatility (a tool from the Volatility framework that can convert many of the above types to other types to support different analysis tools)
MacQuisition: https://www.blackbagtech.com/software-products/macquisition.html (our favorite tool for grabbing OS X memory images, obviously!)
If you haven't already done so, give BlackLight a try for analyzing Windows memory images. The tool's memory functionality is only expected to increase and improve with future releases, so there are more riches to look forward to.
And if you have any further questions about working with memory images, or other aspects of digital forensics, feel free to reach out to the BlackBag training team for assistance.