What a RAM Capture Proves That a Disk Image Cannot

A disk image tells you what was written down. A memory image tells you what was running. Only RAM holds decrypted content, code that never touched the filesystem, the arguments a process was actually launched with, and the sockets it had open. The price is that a memory capture is unrepeatable, non-atomic, and evidence of one instant only — and those three limits shape everything you can say about it.

What does a RAM capture contain that a disk image does not?

Seven categories, in rough order of how often they decide a matter.

Decrypted content. If a volume, container or database was unlocked at the time of capture, its plaintext — and often the key material itself — is resident. This is the single most common reason to capture memory from a running system rather than pulling the plug. Once the machine is off, the same drive is a block of noise.

Code with no file behind it. Reflectively loaded modules, process-hollowed images, shellcode in private memory, and script interpreted from a string all exist only as mapped pages. A disk image of the same machine shows a clean filesystem, because there was never a file to find.

Process context. The command line a process was started with, its environment block, its parent process id, its loaded modules, its open handles, its security token and privileges, its threads and their start addresses. Almost all of this is reconstructible from memory and none of it is on disk unless something logged it — and process command-line logging is off by default on Windows.

Network state. Connection and socket objects with local and remote endpoints, state, and owning process. A firewall log tells you a flow existed; the memory image tells you which process on the host owned it.

Volatile user artifacts. Clipboard contents, typed command history, in-memory registry hives including volatile keys that are never written to disk, unsaved document buffers, and the contents of file writes that had not yet been flushed.

Credential material. Cached hashes, tickets, tokens and, depending on configuration and version, plaintext secrets held by authentication subsystems. This is also why a memory image is itself sensitive and needs to be handled as such.

Unpacked malware. A packed or obfuscated binary on disk is a dead end until you unpack it. In memory it has already unpacked itself. For anything in Practical Malware Analysis territory, the memory image is where you start.

How does a memory capture actually get taken, and why does that matter?

Memory acquisition on a running system requires privileged access to physical memory, which in practice means a signed kernel driver on Windows, a loadable kernel module or a supported kernel interface on Linux. That has two consequences you must be able to state.

The acquisition tool is in the image. It loaded, allocated, and wrote. Your image contains evidence of your own intervention, and the correct response is to document it — tool, version, the fact of driver load, start and end times — not to pretend otherwise. Live acquisition is an accepted technique precisely because the alternative is losing the data entirely; ISO/IEC 27037 frames the decision as one about priority among volatile sources, and NIST SP 800-86 sets the same expectation within an incident response process.

The capture is not atomic. The system keeps executing while you read. Pages acquired at the start and the end are seconds or minutes apart, so data structures can be torn: a linked list whose pointer you read before the node was freed, or a process that exited mid-capture. This is usually called smear, and it explains a genuine class of implausible results. A plugin that returns a process with a nonsensical parent, or a page table walk that lands nowhere, is often smear and not tampering.

On Linux, acquisition typically depends on a module built against the running kernel, so a mismatched kernel version is a hard stop rather than a degraded result. On current macOS — particularly on Apple Silicon — full physical memory acquisition is not generally available, and vendor claims here deserve testing rather than trust. Plan the collection around what you can actually get.

The secondary sources on disk

Disk holds three derivatives of memory, and they are worth checking when live capture was impossible:

• pagefile.sys and swapfile.sys — pages evicted from RAM. No structure, no reliable timestamps, but real content, and bulk_extractor will pull recognisable strings and patterns from them.
• hiberfil.sys — a compressed image of memory at hibernation, which is a genuine point-in-time capture from whenever the machine last hibernated. Framework support for hibernation files varies by version and by Windows release; verify with the build you are using rather than assuming your framework reads it.
• Crash dumps — a complete memory dump is a memory image; the more common kernel or small dumps are not.

These are worth something. They are not a substitute, because none of them gives you the whole address space of every running process at a known moment.

How do you analyse a memory image without guessing?

Volatility 3 is the reference framework, and the practical hurdle is symbols. Volatility 3 needs a symbol table — an intermediate symbol file — matching the exact kernel build of the subject system, generated from Microsoft's debug symbols on Windows or from DWARF on Linux and macOS. A great many "Volatility doesn't work on my image" problems are symbol problems. Resolve that first; nothing downstream is meaningful until the profile is right.

MemProcFS takes a different approach, mounting the image as a filesystem so processes, handles, registry and network state are browsable directories. It is not a competitor so much as a second independent parser, which matters: when a finding is going to be contested, having two tools built on different code reach the same conclusion is worth more than any amount of confidence in one.

The analytical spine is documented in The Art of Memory Forensics, which is still the book, and it will make far more sense alongside Windows Internals — because memory analysis is applied operating system internals and nothing else. You are reading kernel structures. If you do not know what an EPROCESS is for, the plugin output is just words.

A defensible first pass looks like this, and the order is deliberate:

1. Verify the image — its size against the system's installed RAM, and its hash, recorded at capture.
2. Establish the kernel build and obtain matching symbols.
3. Enumerate processes two ways — by walking the active process list and by scanning for process objects — and compare. A process found by scanning but not by list-walking is either exited, or unlinked deliberately.
4. Pull command lines and parentage before anything else, because that is where most of the story is.
5. Enumerate network objects and map them to owning processes.
6. Look at mapped memory regions with executable permissions that have no backing file.
7. Extract what you will analyse separately — dumped modules, registry hives, files from cache — and hash each on extraction.
8. Only then correlate to disk.

Where the question is what the code does rather than what was running, the extracted image goes to static and dynamic analysis; Ghidra and the reverse-engineering track — GREM covers this ground formally — is the next stop, not more plugins.

For collection at scale, Velociraptor can acquire memory across an estate rather than one machine at a time, which changes what is feasible in a live incident. And for practice material, the Volatility Foundation's training resources and the challenge images on CyberDefenders give you known answers to check yourself against.

What can a memory image not establish?

This section is the reason a memory finding survives or collapses.

It is one instant. Everything you find was true at capture. A memory image cannot tell you when a process started being malicious, how long a connection had been open before you looked, or what ran yesterday. Process creation times are an exception worth knowing — they are recorded in the process object — but they are a timestamp from the subject system's clock, with all the caveats that carries.

Absence proves only non-residence at capture. "Volatility found no evidence of tool X" means tool X was not resident, in a form your plugins recognise, at that one moment. It does not mean tool X never ran. A program that executed and exited an hour earlier may have left nothing but freed pages.

Freed pages usually cannot be dated. You will routinely find strings, fragments and whole structures in memory that no longer belong to any live process. They are real content, but there is generally no reliable way to establish when they were written or by what. Reporting a recovered string without acknowledging that you cannot date it is an overstatement waiting to be dismantled.

It says nothing about persistence. Whether the code would have survived a reboot is a question about services, scheduled tasks, run keys, WMI subscriptions and launch agents — which is a registry and filesystem question. Memory tells you what was running, not whether it would run again.

A socket is not a payload. A connection object with a remote address establishes that a socket existed with that endpoint. It does not establish what traversed it, how much, or in which direction. If the claim is exfiltration, you need network records, and you need to say which source supports which half of the claim.

It is not user attribution. A process running under an account is a process running under an account. Memory contains no more evidence of who was at the keyboard than a disk image does.

Verification means something narrower here than on disk. You hash a memory image at capture, and thereafter the hash proves it has not changed. It cannot prove the capture was faithful, because there is nothing to re-acquire and compare against — memory is gone. This is the sharpest illustration of what a hash does and does not guarantee, and it is a question you should expect on cross: the answer is that faithfulness rests on a tested tool, a documented procedure and a contemporaneous log, not on the digest.

How do you present it?

The authentication route for machine-generated output is ordinary: Federal Rule of Evidence 901(b)(9) covers evidence describing a process or system and showing it produces an accurate result, and Rules 902(13) and 902(14) allow that to be done by certification rather than live testimony. Reliability of the method is the Daubert and Kumho Tire question, and it is answered with tool testing records and known-answer validation, not with the tool's reputation. Courts do not always demand a hearing — in Jones v. Riot Hospitality Group the Ninth Circuit upheld admission of a forensic specialist's report without one — but you should never build a case on the assumption that yours will go unexamined.

Two habits carry most of the weight. Write down, at capture time, what you did and what state the machine was in. And separate, in the report, what the memory image shows from what you inferred by combining it with something else. Eoghan Casey's work on error and uncertainty and on expressing evaluative opinions is the shortest route to doing that well, and the discipline it teaches — state the strength of the inference, not just the conclusion — is what distinguishes a memory analysis that is believed from one that is merely impressive.