Volatility 3 and MemProcFS for Memory Forensics

Two tools, and most people learn them wrong

Memory forensics has two mainstream open-source tools in 2026, and the most common way to learn them is the wrong way. Volatility 3 replaced Volatility 2 in 2020, but a large share of the tutorials, courses, and reference posts you will find by searching still teach Volatility 2. People run V2 commands against V3, get nothing, and fall back to whichever version a working tutorial happened to use. MemProcFS, the newer filesystem-view tool that many senior practitioners reach for first on triage, is barely taught at all, so it stays in the "figure it out eventually" pile.

The cost is paid on every investigation: time lost to tutorials that do not apply, commands that fail quietly, and a tool choice driven by which guide you found rather than which tool fits the question. This sub fixes the landscape. Volatility 3 is your primary structural-analysis framework; MemProcFS is the complementary filesystem view that accelerates specific workflows; and there is a clear decision rule for which to reach for. After this you stop searching "volatility" and getting six-year-old answers, because you know what each tool is and when each is right.

# Volatility 2 (most old tutorials) -> will NOT run on V3
vol.py -f mem.raw --profile=Win10x64_19041 pslist
# Volatility 3 (current)
vol -f mem.raw windows.pslist     # OS-qualified name, no --profile

Volatility 3: a symbol-driven analysis engine

Volatility 3 is a Python framework that reads a memory image and reconstructs operating-system structures from it. Its defining design choice, and the source of most of the V2-versus-V3 confusion, is that it is symbol-driven. Volatility 2 used hand-maintained "profiles," a fixed catalogue of OS versions baked into the tool, and you had to pass --profile=Win10x64_19041 by hand. Volatility 3 dropped profiles entirely. Instead it reads structure layouts from symbol files (ISF JSON) keyed to the exact kernel build, and for Windows it fetches matching symbols automatically from a public symbol server. You no longer name the profile; the tool identifies the build and loads the right symbols, which is exactly what you watched windows.info do in MF0.3.

The practical consequences follow from that one choice. Plugin names are fully qualified by OS: windows.pslist, windows.malfind, linux.pslist, linux.bash, where V2 used bare names like pslist. There is no --profile flag. The first run on a new image may pause to download symbols, and an air-gapped analysis workstation needs the symbol packs staged in advance. The migration also changed output and behavior in ways that matter when you lean on an old reference: some V2 plugins were renamed or split, a few were merged, and the exact fields a plugin prints have shifted across releases. A command that ran cleanly in a 2018 write-up may produce different columns, or none, today, which is why the habit this sub presses, confirm the tool version and the date of any guide before trusting it, is not pedantry but the difference between an hour of progress and an hour of confusion. Get the V3 model straight and the whole tool becomes legible; keep reaching for V2 muscle memory and every command fights you.

A little more of the model pays off later. Volatility 3 organizes everything around a context: the image plus the symbols plus the configuration that says how to interpret it, and plugins run against that context to produce their output. Symbols are the heart of it. An ISF symbol file is a description of where every field sits inside every kernel structure for one exact build, and it is what lets a plugin say "the ImageFileName field is at this offset inside EPROCESS" without guessing. When the build and the symbols match, offsets are exact and output is trustworthy; when they do not, the plugin reads the right shape at the wrong offsets and produces plausible nonsense, which is the failure MF0.3's Identify phase exists to catch. On an internet-connected workstation the matching Windows symbols download automatically on first use; on an air-gapped analysis machine, which serious casework often requires, you stage the symbol packs in advance, and an analyst who forgets this discovers it the hard way when the first plugin stalls with no network to fetch from.

The plugin library itself is broad and OS-scoped. For Windows you have the process family (pslist, psscan, pstree), the memory and injection plugins (malfind, vadinfo, dlllist), the network plugin (netscan), credential and registry plugins, and the kernel plugins (modules, ssdt, callbacks) for rootkit work, with Linux equivalents under the linux. prefix. You do not memorize them all; you learn the handful each module needs and recognize that the naming is systematic, so a plugin you have never run is still legible from its name.

MemProcFS: browse the image as a filesystem

MemProcFS takes a different approach to the same image. Instead of running a plugin and parsing its output, it mounts the memory image as a virtual filesystem: a drive you browse with cd, ls, and a file explorer, where every process is a folder and every artifact is a file. Open /name/powershell.exe-4872/ and you find that process's modules, handles, memory regions, and command line as files you read directly. There is no query to compose; you navigate to the evidence.

That model makes MemProcFS fast for two things in particular. The first is initial triage, getting an overview of what is on a system in seconds by browsing the process folders rather than running and reading a sequence of plugins. The second is interactive exploration, following a lead by clicking into the relevant folder rather than constructing the next command. Many experienced analysts start a fresh image in MemProcFS to orient, then switch to Volatility for the precise structural work. It also exposes a forensic mode that builds a timeline and a SQLite database of the image, useful for the correlation phase. That forensic mode is worth knowing about specifically because it front-loads work the correlation phase needs: pointed at an image, it enumerates processes, files, network artifacts, and registry data into a timeline and a queryable database, so that when you reach phase 5 and need to line memory findings up against a sequence of events, a chronological view already exists. It does not replace the deliberate, documented correlation the workflow demands, but it accelerates getting to it. Where it is weaker is exactly where Volatility is strong: scripted, repeatable, plugin-level analysis and the deep structural manipulation that anti-forensic cases demand.

# mount the image, then explore it like any directory tree
$ memprocfs -device NE-FIN-014-mem.raw -mount /mnt/mem
$ ls /mnt/mem/name/
System-4  ...  powershell.exe-4872  explorer.exe-1816
$ ls /mnt/mem/name/powershell.exe-4872/
cmdline  handles  modules  vmemd  threads  token
$ cat /mnt/mem/name/powershell.exe-4872/cmdline
powershell -nop -w hidden -enc JABjAD0ATgBldy...

The same fact you pulled with windows.cmdline in MF0.2 is here a file you cat. Neither approach is more correct; they are different ergonomics over the same underlying structures, and a capable analyst uses both.

When each tool is correct

The two are complementary, and the choice is driven by the question, not by preference. Reach for MemProcFS when you are orienting on an unfamiliar image, triaging quickly to decide whether a system is worth deeper work, or following a lead interactively where browsing beats composing commands. Reach for Volatility 3 when you need a specific structural answer, a repeatable scripted analysis you will document and defend, reconciliation across multiple discovery methods, or the deep manipulation that detecting a sophisticated rootkit requires. A common and effective pattern is to triage in MemProcFS, identify the processes and regions that matter, then switch to Volatility 3 for the verified, documented analysis that goes in the report. The two strengths are almost mirror images. MemProcFS optimizes for the human exploring an unfamiliar image: low friction, immediate overview, click-to-follow. Volatility 3 optimizes for the analysis you have to defend: a command you can record verbatim, re-run, and cite, with output you can diff between discovery methods. Triage rewards the first; reporting demands the second. An analyst who only knows one tool either loses time composing commands during exploration or produces a report they cannot reproduce on demand, and the cost of learning both is small against the cost of either gap.

There is also a reliability reason to keep both in reach. The tools parse the same structures through different code, so when a finding is surprising, confirming it in the second tool is a cheap independent check: if MemProcFS shows a process in its folder listing and Volatility's pslist does not, that disagreement is a lead, exactly the kind of multi-method signal MF0.2 described, and having both tools turns it into evidence rather than a question mark.

What this means for the course

Throughout the course, Volatility 3 is the framework the worked examples use, because it produces the scripted, documented, defensible analysis the workflow in MF0.3 demands. MemProcFS appears where it earns its place: rapid triage at the start of an investigation and interactive exploration when you are chasing a lead. You will install both in the lab build, and the orientation sub later in this module walks the first commands of each against a real capture so the tools are in your hands before MF1 has you acquiring your own images.

Both tools, in the end, are doing what MF0.4 described: walking page tables to translate virtual addresses, reading kernel structures from the physical image, and presenting the result. Volatility hands you the result of a query; MemProcFS hands you a filesystem over the same structures. Understanding the layer beneath them, which the last sub built, is what lets you tell when either tool is wrong. That is the throughline of this module's tool subs: the tool is a lens over the structures, and a lens can distort. The analyst who knows only the lens trusts whatever it shows; the analyst who knows the structures underneath, the physical-to-virtual translation from MF0.4, the categories from MF0.2, can look at a plugin's output and ask whether it is consistent with how the structure actually works. When MF6 confronts a rootkit that feeds Volatility false output by corrupting the structures it reads, that question, does this output match what the structure should contain, is the entire game, and it is unanswerable for someone who treats the tool as an oracle. The next sub adds the tool you reach for when both of these cannot settle the question: WinDbg, the kernel debugger, for validation and for the cases a rootkit defeats at the plugin level.