Linux Memory Forensics: Acquisition & Analysis

Everything a program actually does happens in memory. The disk only holds what got saved; RAM holds what is happening right now — and that gap is where the best evidence lives.

Think of it this way: disk is the filing cabinet, memory is the desk mid-work. The cabinet shows you what was filed away — files, logs, installed packages. The desk shows you the documents spread open this second: the half-written letter, the calculator still on, the page someone is reading. A thief can empty the filing cabinet and shred everything in it, but while they're standing there working, they can't hide what's open on the desk in front of them.

Concretely, memory — and only memory — reliably holds:

• Decrypted data: passwords, keys, and TLS session material that exist as ciphertext (or not at all) on disk.
• Injected code: malware that lives only in another process's address space and never touches the filesystem.
• Unlinked-but-running programs: a binary deleted from disk after launch keeps running from RAM (the (deleted) trick from process forensics).
• Live network connections: sockets and the peer addresses a process is talking to.
• The true process list: the kernel's real task list, which a userland rootkit's trojaned ps hides from you.

Your instinct from file forensics is to dd the evidence to a file. For memory the obvious target would be /dev/mem (raw physical RAM) or /dev/kmem (kernel virtual memory) — and on an old box you could. On a modern kernel you cannot, by design.

Two kernel hardening features stand in the way. `CONFIG_STRICT_DEVMEM` restricts /dev/mem to a tiny window of legacy device ranges, so reading general RAM through it just fails. `/dev/kmem` is gone entirely on current kernels (CONFIG_DEVKMEM removed). These exist because unrestricted raw-memory access is itself a devastating attack primitive — the same power you want for forensics is the power an attacker wants to read everyone's secrets.

So memory acquisition needs a tool that runs inside kernel context to read all of physical RAM legitimately. Three approaches matter:

• LiME (Linux Memory Extractor): a loadable kernel module you insert with insmod. Because it runs in the kernel, it can read all of physical memory and write it out as a clean image. The forensic standard for Linux.
• AVML (Acquire Volatile Memory for Linux): a portable userspace tool from Microsoft that reads memory via the available source (/proc/kcore, /dev/crash, or /dev/mem) without needing you to compile a module per-kernel. Great when you can't build a module on the target.
• `/proc/kcore`: the running kernel's memory exposed as a virtual ELF core file. Older and more limited, but it's already there — no module, no install — which makes it a useful fallback and a live-analysis surface.

A raw memory image is just a few gigabytes of undifferentiated bytes. To turn it into processes, sockets, and command lines, the analysis tool needs a map of where the kernel keeps its structures in that specific build — a symbol table / profile. Get the map even slightly wrong and the structures don't line up, so every plugin either errors out or prints garbage.

Analogy: the memory image is a city with no street signs. The symbol table is the map that labels which block is the process list and which is the socket table. A map for the wrong city — a kernel that differs by even a point release — points you at the wrong addresses, and nothing makes sense.

That map is keyed to the exact kernel version and build. So before (or right after) acquisition, you record it. This is one line, and forgetting it is the number-one reason a memory capture becomes unanalyzable.

Now the payoff. With the image and matching symbols loaded into Volatility (the de-facto memory analysis framework), you run plugins — each reconstructs one kind of evidence from the raw bytes. The first and most important pair is two different ways to enumerate processes, and the gap between them is where hidden malware appears.

• `pslist` walks the kernel's linked list of active tasks — the same list ps reads. Fast, but anything unlinked from that list (a classic rootkit move: splice your own task out of the doubly-linked list so ps can't see it) is invisible to it.
• `psscan` ignores the linked list and scans all of physical memory for process structures by their signature — pool tag / type pattern. It finds processes even if they were unlinked, and even some that have already exited but whose structures linger in RAM.

This is the exact discrepancy-detection technique from rootkit hunting — /proc vs ps — but now applied to a frozen memory image where the attacker can't keep lying to you in real time. A process in `psscan` but missing from `pslist` is a hidden process.

Having found PID 6613, you interrogate it the way /proc let you interrogate a live process — except now from the frozen image, so the suspect can't react.

• Dump the process (pslist --dump / proc.Maps + extraction) to carve its memory and executable image out for static analysis.
• Find injected code with a malfind-style scan: look for memory regions that are both writable and executable (RWX) and not backed by any file on disk. Legitimate code is mapped from a file and is read-execute, not write-execute. An anonymous RWX region holding machine code is the signature of process injection — malware running inside a host process with no file to find on disk.
• Recover network connections with `netscan`, which carves socket structures out of memory to rebuild who was talking to whom — including connections that had already closed but still linger in RAM.

Sometimes you can't do a full RAM capture — no external media big enough, no ability to build a LiME module, or you just need a fast live look before the formal capture arrives. The kernel already exposes a live window into process memory through `/proc`, and it lets you do a meaningful subset of the analysis above without any tooling.

• `/proc/<pid>/maps` — the process's memory map: every region, its permissions, and what file (if any) backs it. This is your manual `malfind`: scan for an rwxp region with no pathname.
• `/proc/<pid>/mem` — the process's actual memory contents, readable (with the right access) at the offsets maps gives you. This is the manual process dump.
• `/proc/<pid>/exe` — the symlink to the real backing binary (and the (deleted) tell from process forensics).
• `/proc/kcore` — the running kernel's memory as a virtual ELF core; a live, kernel-wide surface some tools can analyze in place.

It's an approximation, not a forensic image — it's live, so it changes as you read it, and it's per-process rather than a single consistent snapshot. But it surfaces the same indicators: unbacked executable regions, deleted binaries, the real maps.

You have a real root shell. Full RAM capture and Volatility aren't in this sandbox — those run on the Phase-2 DFIR lab image, which ships with the memory tooling and a provided memory snapshot to analyze. What you can do here, safely and read-only, is the acquisition pre-flight and the /proc approximation: the exact moves you'd make on a real host before and around a capture. Nothing below changes the system.