What Live Memory Acquisition Changes While It Reads

Reading physical memory is not a passive observation. The tool that reads it is a process competing for the same memory it is measuring, its page tables are walked by the same kernel that manages the target’s, and its allocations displace or coalesce pages that belonged to something else. A memory image is therefore a snapshot of the system taken while the system was also executing the code that took the snapshot.

The perturbation is not diffuse noise. It is concentrated in specific structures: page tables, the kernel’s own allocator bookkeeping, process and thread objects for the acquisition tool itself, and the buffer the tool uses to stage data. Knowing where it lands is what allows an analyst to distinguish an artifact of capture from evidence of the intrusion.

The address space does not correspond to the device

Physical memory is not one contiguous range as seen by software. Firmware carves out regions for its own use and reports them through the UEFI memory map; device MMIO windows are mapped into the physical address space and read as either all-ones, all-zeros, or bus error depending on the platform; the top of usable RAM is below the top of the address space. A naive loop from 0 to the highest physical address will attempt to read several gigabytes of nothing at all, and the reads may return data that looks like content but is meaningless.

The firmware provides a memory map to the booting kernel, and that map is the correct source of the region list: on BIOS systems it arrives as the E820 call’s table, on UEFI systems as the memory map from the boot services, and in both cases it distinguishes usable RAM from reserved ranges, ACPI reclaim memory, MMIO, and firmware-reserved regions. Acquisition tools that honor the map produce an image with holes, and the analysis tool must be given the same map to interpret offsets. An image acquired without a map, or analyzed with a different map, misaligns every structure after the first hole.

On Windows, the loader records the physical memory ranges it received from firmware in a block that the kernel exports for debugging, and that block describes the usable ranges along with their lengths; several ranges exist on machines with memory-mapped device apertures. On Linux, /proc/iomem reports the same partitioning in text form. Neither is authoritative on a system where firmware misreports, which is one source of the discrepancies between captures from nominally identical hardware.

Reading with or without the operating system’s cooperation

Two classes of acquisition exist, and they differ in exactly which structures remain valid in the result.

An agent-based acquisition runs inside the target OS, typically as a kernel driver that maps physical memory by way of the OS’s own allocation primitives and copies it to external storage. It is portable and needs no special hardware, but the driver’s own mappings, buffers, and pool allocations appear in the image, and the OS may move or evict pages during the copy.

A hardware-based acquisition reads memory by way of a bus that bypasses the CPU’s memory management: a PCIe device using bus-master DMA, or a bus analyzer attached to the memory bus. Because the CPU’s translation is bypassed, the read sees physical addresses directly and the acquisition tool contributes no mappings of its own to the image. It also cannot see what the OS has already written to disk or to compressed memory.

Between the two lies the ordering question. An agent-based acquisition is inherently inconsistent: page A is copied before the attacker’s process runs and page B after, so structures spanning both may be torn: a list head pointing to a node that has since been freed, a page table entry updated between the walk and the read. Depending on the platform, the kernel offers a “capture” or “snapshot” primitive that briefly freezes non-essential execution, but the freeze is bounded in duration and cannot cover an entire multi-gigabyte copy.

The order that minimizes loss

Given that the copy cannot be atomic, the useful rule is to copy what changes fastest first, and what is most likely to vanish entirely before anything else.

The standard ordering places the acquisition artifact records first (the memory map, the tool’s own log, the timestamp), then the most volatile structures: CPU registers and the run queues; network connection state, which the kernel may purge on a timer; process and thread objects; open handles and file objects; then the bulk of user-space pages; then cached file content, which is the least volatile because it is a copy of something on disk.

Cached file content illustrates the trade sharply. Page cache pages may be evicted at any time, but their content is also recoverable from the file system image. Copying them costs time that could go to pages whose content exists nowhere else. A memory-only artifact such as a decrypted credential, a key that was never written down, or a process that never touched disk is unrecoverable if it is lost, which is why kernel memory and non-paged pool are prioritized ahead of the bulk user-space pages.

Symbols, and why the image alone is not enough

A raw physical image is a byte stream with no type information. Locating a process list requires knowing where the kernel stores its list head, which is a symbol address that varies by kernel build. Tools resolve these against symbol files: Microsoft publishes PDB symbols for Windows kernels through its symbol server, and Linux kernels may be built with debug information or have their symbols recovered from a matching build.

Version mismatch is the dominant failure. A structure’s field offsets change between builds; even service-pack-level updates can shift offsets within the structures an analysis tool walks. A tool that uses a wrong profile does not fail loudly: it produces plausible garbage, translating a random word into a “process name” and a random pointer into a “parent pid”. The symptom is a process tree with implausible names and parentage that does not match the execution records described in process start records. Cross-checking the two is the cheapest way to detect a bad profile.

Artifacts the capture itself creates

Every agent-based acquisition leaves its own traces, and they can be mistaken for intrusion activity. A new kernel driver loaded shortly before the image was taken will appear with a load time and a module list entry. The tool’s user-space process will appear in the process list with its command line. Large sections of recently touched memory will hold the copied content itself, which is a duplicate of data that also appears at its original location, and if the acquisition staged data through an OS buffer, the staged copy and the source may both be present with different contents where a page changed mid-copy.

The practical mitigation is documentary rather than technical: the acquisition record names the tool, its version, the order in which regions were read, and the time each phase began. Given that record, a later analyst can discount the tool’s own footprint without guessing. Without it, every conclusion drawn about the moments immediately preceding capture carries an unquantified error, the same class of problem as timeline assembly across hosts where the recording clock is also part of the system under study.