Why memory matters, and acquisition

A disk image shows what a system stored; a memory image shows what it was doing: which programs ran with which arguments, who was logged on, where the machine was connected and which secrets were unlocked. Most of this disappears at power-off. This lesson covers what lives only in RAM, what to collect first, and how to acquire memory from Windows, Linux and virtual machines so the capture can be analyzed and defended. CFX practical memory tasks use a Linux capture, so the Linux symbol table problem gets special attention.

What lives only in RAM

Random access memory (RAM) holds the working state of the operating system and every running program. Some of it is written to disk later, in the page file, hibernation file or a crash dump (Lesson 5.4), but much of it never is:

• Processes and their command lines. The full command line, for example powershell.exe -enc <Base64>, often exists only in the process's memory.
• Network connections. Open sockets, listening ports and remote addresses, plus the ARP cache and routing table.
• Logged-on sessions. Interactive, remote desktop and service sessions, with their access tokens. On Windows the Local Security Authority process (lsass.exe) holds credential material for logged-on users.
• Decrypted data and encryption keys. While a BitLocker volume is unlocked or a VeraCrypt container is mounted, the master key that decrypts it is in RAM. Recovering it can be the only way to read the encrypted disk later (Module 7 covers encrypted volumes).
• Clipboard contents, including text that was copied but never saved.
• Injected or fileless code. Malware that is loaded straight into another process or runs as an in-memory script may leave no executable on disk (Lesson 5.3).
• Unsaved documents and editor buffers.
• Private-browsing remnants. Private modes avoid writing history to disk, but URLs, page text and form data remain in the browser's process memory.

Memory also corroborates disk evidence: Prefetch proves a program ran at some time, while a process in a memory image proves it was running at capture time, with a start time, parent process and user.

The order of volatility

RFC 3227, Guidelines for Evidence Collection and Archiving (2002), tells the collector to proceed from the most volatile evidence to the least volatile. Its list is:

1. Registers and cache
2. Routing table, ARP cache, process table, kernel statistics, memory
3. Temporary file systems
4. Disk
5. Remote logging and monitoring data relevant to the system
6. Physical configuration and network topology
7. Archival media

Registers and cache change in nanoseconds and are almost never collected, so in practice the memory image comes first. The routing table, ARP cache and process table all live in RAM: a full memory image preserves them, while running live commands such as netstat or ps first changes memory. Temporary file systems such as Linux tmpfs (/dev/shm, and /tmp on some distributions) are RAM-backed and vanish at power-off. Remote logs survive the incident but rotate by retention policy, so request them early.

Deciding to capture, and documenting the footprint

If a system is found running, the default is to capture memory before shutting it down or pulling the power. Shutting down first destroys the RAM evidence and may lock a mounted encrypted volume for good. Reasons to act differently, such as malware that is actively wiping data, must be weighed and written down.

Every live acquisition changes the system. The tool runs as a process, loads a driver or module or opens device files, and overwrites memory pages that may have held freed but recoverable data. You cannot avoid this footprint, so you minimize and document it. ISO/IEC 27037 covers live acquisition and expects each action to be justified and documented, and NIST SP 800-86 advises collecting volatile data in order of volatility with trusted tools and awareness of their effect. Record the tool name, version and hash, the exact command, the account used, start and end times in UTC with their time source, and every console action.

Windows acquisition

Windows memory tools need administrator rights because they load a kernel driver to read physical memory. Run the tool from external media and write the output to a prepared external drive or network share. Never write a capture to the evidence system's own disk: it would overwrite unallocated clusters that may hold deleted files. Hash the output as soon as it is complete.

Common output formats are raw (a flat copy of physical memory, named .raw, .mem or .img), the Microsoft crash dump format (.dmp, a header followed by memory pages) and AFF4 (Advanced Forensic Format 4, a container with compression and metadata). Volatility 3 reads raw and crash dump files directly but not AFF4, so export an AFF4 capture to raw first.

Two Windows features complicate analysis. Paged-out data: pages moved to pagefile.sys are not in the RAM image, leaving gaps; collect the page file too where possible (Lesson 5.4). Memory compression: since Windows 10, the memory manager compresses rarely used pages in RAM instead of paging them out; in current Windows 10 and 11 releases the compression store belongs to a process named Memory Compression. That data is in the image but compressed, and only tools that support the compression store can read it.

Virtual machines

A hypervisor can save guest memory without running anything inside the guest, so there is no tool footprint, and a suspended VM is stopped, so its saved memory is consistent.

• VMware: guest memory is written to a .vmem file when the VM is suspended (with a .vmss state file) or when a snapshot includes memory (with a .vmsn snapshot file). Collect the .vmem with its matching .vmss or .vmsn: the state file describes how guest memory is laid out in the .vmem, and Volatility 3 uses it.
• Hyper-V: since Windows Server 2016 and Windows 10, saved state and checkpoints are stored in .vmrs runtime state files; older versions used .bin (memory) and .vsv (saved state) files. Neither is a raw image: convert it with a tool that understands the format, such as Microsoft's saved-state dump tooling, and test the result.

Linux acquisition

LiME (Linux Memory Extractor) is a loadable kernel module. A kernel accepts a module only if it was built for that exact kernel release and configuration, so LiME must be compiled against the running kernel's headers, on a separate clean system with the same distribution and kernel, not on the evidence system. The build produces lime-<release>.ko, loaded with, for example, insmod lime-6.1.0-18-amd64.ko "path=/mnt/usb/mem.lime format=lime". The format parameter accepts raw, padded or lime. The lime format writes a 32-byte header before each physical memory range, starting with the magic value 0x4C694D45, which appears in the file as the ASCII bytes EMiL. LiME can also serve the capture over the network with path=tcp:<port>, avoiding any local write. With Secure Boot and enforced module signing, an unsigned LiME module is refused.

AVML (Acquire Volatile Memory for Linux) is Microsoft's alternative: a static userland program that needs no per-kernel build. It reads through /dev/crash, /proc/kcore or /dev/mem, whichever is available, and writes LiME format, optionally compressed (Volatility 3 reads the compressed file if the snappy library is installed; otherwise convert it with avml-convert).

/proc/kcore presents kernel virtual memory as an ELF core file. It is not a ready-made physical image: its apparent size reflects the kernel's address space (about 128 TiB on typical x86-64 systems), kernel lockdown may restrict it, and copying it with dd does not produce a file analysis tools expect. /dev/mem is not a practical source either: with the kernel's STRICT_DEVMEM option, enabled on most distributions, it cannot read ordinary RAM (current x86 kernels return zeros even for RAM in the first 1 MiB).

The table summarizes the acquisition options in this lesson.

The symbol table problem

To analyze a Linux image, Volatility 3 needs a symbol table for the exact kernel build: an ISF (Intermediate Symbol Format) JSON file describing the kernel's structures and symbol addresses. It is built with dwarf2json from a vmlinux file that contains DWARF debug information plus the matching System.map, for example dwarf2json linux --elf vmlinux-6.1.0-18-amd64 --system-map System.map-6.1.0-18-amd64 > debian12-6.1.0-18.json. On Debian the debug vmlinux comes from the linux-image-<release>-dbg package. Volatility 3 matches the symbol file to the image by the kernel banner string, and its banners plugin shows which banner an image contains. A capture without matching symbols may be unusable, so record uname -a at acquisition: it tells the analyst exactly which kernel to obtain symbols for.

Integrity, smear and timing

Hash the capture immediately, typically with SHA-256. The hash proves the file is unchanged since acquisition, but it cannot be checked against the source: memory changes constantly, so two captures of the same running system never hash the same.

Memory also changes while it is being read: pages copied at the end of a capture reflect a later state than pages copied at the start. This smear can produce inconsistent structures, such as a list entry pointing to a process that has already exited. A capture is not a perfect snapshot, so corroborate odd results.

Worked example: a Linux server acquisition

A running Debian 12 web server must be preserved. A LiME module was built in advance on a lab system with the identical kernel. The acquisition record reads:

Sizing. RAM sizes are binary: 8 GiB = 8 × 1,073,741,824 = 8,589,934,592 bytes. Drive speeds are decimal: 200 MB/s = 200,000,000 bytes per second. Time = 8,589,934,592 ÷ 200,000,000 ≈ 42.9 s, about 43 seconds. Treating 8 GiB as 8,000,000,000 bytes gives 40 s, a 7% underestimate. The recorded 46 seconds matches the estimate plus module loading. A 64 GiB server at the same speed needs 68,719,476,736 ÷ 200,000,000 ≈ 344 s, almost six minutes of smear. The lime file is not exactly 8 GiB either: LiME copies only the ranges the kernel lists as System RAM in /proc/iomem and adds 32 bytes per range.

Authority and privacy

Memory holds passwords, private messages and data of people outside the investigation. Confirm that your authority (a warrant, owner consent or an incident response mandate) covers live acquisition, stay within scope, and protect the capture as sensitive data.

Exam focus: Expect questions that apply the order of volatility to a scenario, ask what a memory image holds that a disk image does not, and test why a memory capture's hash cannot be re-verified against the live system. For the practical part, know that Volatility 3 Linux analysis depends on an ISF symbol file matching the exact kernel banner, and state values such as the kernel release exactly.

Key points

• RAM holds running processes, command lines, connections, sessions, encryption keys and fileless code that never reach the disk.
• Collect from most to least volatile (RFC 3227): capture memory before shutdown, and document the tool's unavoidable footprint.
• Run Windows tools as administrator from external media, write to external media, and hash the output immediately.
• LiME must be built for the exact running kernel; AVML is a userland alternative; /proc/kcore is not a ready physical image.
• Record uname -a: without an ISF symbol table for that exact kernel, Volatility 3 may not be able to analyze the capture.
• Smear, paged-out pages and Windows memory compression mean a capture is never a complete, consistent snapshot.