In this module
MF0.5 Volatility 3 and MemProcFS — The Analysis Framework
From MF0.1-0.4 you know why memory forensics matters, what lives in memory, how the six-phase workflow runs, and how addressing works. What you don't know yet is which tools you'll be running every step of the workflow with. This sub establishes the two that matter: Volatility 3 as the primary structural-analysis framework, and MemProcFS as the complementary filesystem-view tool.
Memory forensics has two mainstream open-source tools in 2026 and most practitioners learn them incorrectly. Volatility 3 replaced Volatility 2 in 2020, but the majority of online tutorials, courses, and reference material still teach Volatility 2 — leading practitioners to run V2 commands against V3, be confused when nothing works, and fall back to whichever version they found a working tutorial for.
MemProcFS is the newer filesystem-view approach that many senior practitioners rate as faster for initial triage than Volatility 3, but institutional DFIR training rarely teaches it at all, leaving it as something practitioners "figure out eventually" rather than learn systematically. The consequence is wasted time on every investigation — tutorials that don't apply, commands that fail silently, tool choices made from which tutorial the practitioner found rather than which tool fits the task.
This subsection establishes the correct tool landscape for 2026: Volatility 3 as the primary structural-analysis framework, MemProcFS as the complementary filesystem-view tool that accelerates specific workflows, and the decision logic for choosing between them on any given question. The practitioner completing this subsection stops googling "volatility" and getting six-year-old tutorials; they know what each tool does, when each is correct, and how to use them in combination.
Volatility 3 and MemProcFS are not competitors. They're complementary projections of the same memory image. Volatility 3 answers structured questions (the plugin you ran produced the CSV you needed). MemProcFS lets you navigate the image as a filesystem, which is faster for browsing-style triage. Mature practitioners use both on the same case.
A memory image is just bytes until a tool gives the bytes structure. The two mainstream open-source tools that do this in 2026 are Volatility 3 and MemProcFS, and they take radically different approaches. Volatility 3 is a plugin framework — you ask a specific question (windows.pslist, windows.malfind, windows.netscan) and the plugin runs, parses the relevant kernel structures, and produces structured output. MemProcFS is a filesystem projection — it mounts the memory image as a virtual drive and presents processes, files, handles, and kernel objects as folders and files that any filesystem-aware tool can read. The mental model for Volatility 3 is "query the memory." The mental model for MemProcFS is "browse the memory." Both mental models produce correct answers on the same image; each is faster than the other for specific questions.
The first thing to get right about Volatility is that Volatility 3 is not Volatility 2. They share a name, an origin, and a philosophy, but they are architecturally different tools with different command syntax, different plugin names, and different capabilities. Volatility 2 (released 2007–2020) required a separate "profile" per target OS — downloadable profile packs for every Windows build, custom-built profiles for Linux kernels. Volatility 3 (released 2020, actively developed) replaced profiles with symbol-based analysis, pulling debug symbols from Microsoft's symbol server or generating them from Linux kernel debug packages. The command structure changed from volatility -f image --profile=Win10x64_19041 pslist (V2) to vol -f image windows.pslist (V3). Every V2 tutorial showing the first form produces an error on V3. The majority of search results when you google "volatility" still point to V2 tutorials, which is why practitioners starting now waste hours on non-working commands before realising what happened.
Volatility 3's architecture — contexts, symbols, requirements, plugins
Volatility 3 operates on four concepts that every investigation uses whether the practitioner knows about them or not. Contexts are the runtime environment — the memory image, the symbol table, the OS identification, the configuration state. Every plugin execution creates a context. Symbols are the structure definitions (field names, offsets, sizes) for the specific OS version the image was captured from; Volatility 3 pulls them automatically for Windows and generates them from debug info for Linux. Requirements are the parameters a plugin needs (a memory image path, an optional PID filter, an optional output directory for dumps); plugins declare their requirements and the framework validates them. Plugins are the executable units of analysis — windows.pslist, windows.malfind, linux.pstree, and so on. Every plugin operates within a context, uses symbols to parse memory, accepts its declared requirements, and produces structured output.
For practical use, the investigator cares about two of these: which plugin to run, and whether the symbols resolve correctly. The other two operate transparently. Plugin selection is covered in depth in later modules — MF3 covers process-memory plugins, MF4–MF6 cover Windows-specific plugins, MF7–MF8 cover Linux-specific plugins. For MF0 the key point is that Volatility 3's plugin catalogue is organised by OS (windows., linux., mac.*) and by structure type within OS (windows.pslist, windows.psscan, windows.netscan). Running vol --help lists every available plugin; running vol windows.pslist --help documents the specific plugin's requirements.
Volatility 3's output model is command-line structured text by default — human-readable tables that tools like awk, grep, and jq can post-process. Adding -r csv or -r json produces machine-readable output for automated analysis. The scriptability matters for documentation: an investigation whose commands were run with -r csv | tee phase3-pslist.csv produces saveable evidence that becomes part of the case file exactly as the plugin reported it. An investigator who ran plugins interactively and then transcribed results into their notes has introduced a transcription layer that opposing experts can challenge. Command-and-output redirection eliminates that layer.
MemProcFS's model — filesystem projection, browse rather than query
MemProcFS takes a completely different architectural approach. Instead of providing plugins that answer specific questions, it mounts the memory image as a virtual filesystem (on Windows: a drive letter; on Linux: a FUSE mount point). Every running process becomes a folder under name/. Every file the process has open becomes a file under that process's folder. Kernel objects, registry hives, network connections, loaded DLLs, handles — all appear as navigable filesystem entries. The practitioner examines memory by running cd, ls, cat, and type, not by recalling plugin names.
The practical difference shows up in triage speed. Asking "what's in this memory image" in Volatility 3 means knowing which plugins to run and remembering their names — windows.pslist, windows.netscan, windows.cmdline, windows.malfind, windows.dlllist, and so on. The plugin names are the vocabulary you need, and missing a plugin means missing the evidence. Asking "what's in this memory image" in MemProcFS means navigating the filesystem tree under M:/ (or wherever you mounted it) — no vocabulary needed, everything that exists is visible as folders. An investigator unfamiliar with the memory image can explore it in MemProcFS the way they'd explore an unfamiliar disk: by walking the directory structure and opening files that look interesting.
Concretely, here is the same analytical question — "what command line was PID 4872 launched with?" — answered both ways. In Volatility 3:
# Must know the plugin name (windows.cmdline) and the required argument (--pid)
$ vol -f NE-FIN-014-mem.raw windows.cmdline --pid 4872
# Expected output:
#
# PID Process Args
# 4872 powershell.exe powershell.exe -nop -w hidden -enc JABjAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAE4A...Plugin-driven query. The investigator needed to know that windows.cmdline is the plugin name, that --pid is how you filter to a specific process, and that the output would be command-line text. If they'd forgotten any of these, they'd have needed to look them up.
The same question in MemProcFS:
# Mount the image once; browse like a filesystem.
$ MemProcFS.exe -device NE-FIN-014-mem.raw -mount M:
# Navigate to the process. Every running process is a folder under M:/name/
$ cat /mnt/M/name/powershell.exe-4872/cmdline.txt
# Expected output (contents of the file):
#
# powershell.exe -nop -w hidden -enc JABjAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAE4A...Browse-driven discovery. The investigator navigated to the process folder (which appeared in the filesystem tree once the image was mounted) and read the command-line value as if it were a text file. No plugin name to remember; the information was exposed as a file the investigator could see by listing the directory.
Same answer from both tools. The difference is the cognitive model: Volatility 3 is faster when the investigator already knows what to ask; MemProcFS is faster when the investigator is exploring to find what's there. Both tools use the same underlying kernel structures, so there is no "more accurate" option. There is only "better fit for the current question."
When each tool is correct
The decision between Volatility 3 and MemProcFS rarely comes down to "which is better." It comes down to "which is better for this question." Four patterns cover most investigations.
Use Volatility 3 when the question is specific and structured. "Extract all injected code from the image." "Reconstruct the PE of the DLL at virtual address 0x7ff8a2100000." "Dump the handle table for PID 4872 and parse the file handles." These are plugin-shaped questions with plugin-shaped answers. The output is saveable to CSV, forms part of the documentation record, and produces exactly the structural depth the later phases of the investigation need.
Use MemProcFS when the question is exploratory or filesystem-shaped. "What's in this memory image?" "Browse the process tree and open anything interesting." "Show me this process's open file handles — just let me see them, don't dump them." These are browse-shaped questions. MemProcFS gets you to the answer faster because you don't need to know the plugin name in advance.
Use both in parallel when the investigation is multi-phase. MemProcFS mounted in one window for quick orientation; Volatility 3 running in another window for dedicated analysis tasks. The two tools share no state — both operate on the same read-only image — so running both simultaneously is safe. Many senior practitioners work this way by default: MemProcFS for "what about..." questions, Volatility 3 for "now dump this specific region..." tasks.
Use Volatility 3 exclusively when the output needs to be reproducible documentation. MemProcFS sessions are interactive and stateful; you cannot easily record what you did as a replayable script. Volatility 3 commands are exactly the reverse — every analysis is a command-line invocation that can be captured, replayed, and cited in the case record. For investigations heading for court, regulatory review, or HR proceedings, Volatility 3's command-line-first approach gives you the audit trail. MemProcFS is still valuable for exploration during those investigations, but the final documented analysis should use Volatility 3 commands whose output is captured as evidence files.
The point of running Volatility 3 and MemProcFS against the same question isn't redundancy — it's confirming both tools are installed correctly and producing coherent output. This procedure uses a single question (list processes in a memory image) to exercise both tool pipelines end to end. Paper-based: the synthetic output below represents what each tool would show against a clean Windows 11 capture.
With both tools producing coherent output for the same image, the workstation is ready for course exercises. Volatility 3 handles the structured-query workflow; MemProcFS handles the exploratory-browse workflow. Real investigations typically run both in parallel on the same image.
The situation. Your senior analyst asks for "a quick extract — what's interesting in that image — I need to brief the CISO in 40 minutes." You have both tools installed. The tempting choice is to reach for MemProcFS because it's faster for "what's interesting" questions — mount the image, browse the process tree, click into the suspicious process, open its handles, show the analyst what you find.
The choice. MemProcFS for speed, Volatility 3 for documented commands, or both in a mixed workflow.
The correct call. Ask first where the brief ends. For an internal note that never leaves the IR team, MemProcFS alone is fine — explore, screenshot what matters, write the note. For an executive summary the CISO might file internally, produce the answers in MemProcFS but reproduce the key findings with Volatility 3 commands so the documentation record contains reproducible commands alongside the screenshots. For a report heading for the incident register (logged, retained, potentially disclosed), use Volatility 3 from the start — every finding should have a cited vol -f ... command as the evidence source, and MemProcFS exploration is documented as "orientation, not reportable findings."
The operational lesson. Time pressure doesn't change the rule; it changes the narrative you give back. "40 minutes with a reportable output means I'll show you MemProcFS findings with Volatility 3 corroboration for the three things that actually matter; everything else stays in exploration mode." The senior analyst gets the brief they need, the record gets the reproducibility it needs, and you haven't silently downgraded the documentation standard under time pressure.
The myth. Volatility 2 and Volatility 3 both analyse memory images. The fundamentals are the same. A tutorial for V2 can be followed with V3 just by adjusting the syntax. Most memory analysis techniques work on either version.
The reality. Volatility 2 has been in maintenance-only status since 2020. It receives no new plugins, no new OS version support, and no new features. Any tutorial written for V2 is at best five years out of date on the attacker techniques and operating system versions it covers.
The plugin names, command syntax, profile system, and output format are different between V2 and V3 — not superficially different, but architecturally different. A practitioner who follows a V2 tutorial on a V3 installation either hits errors immediately (the command syntax doesn't parse) or, worse, hits silent behaviour mismatches where the V3 plugin with a similar name does something subtly different.
V3 is the tool currently maintained, and V3 is what this course teaches. The 2026 reality is that the majority of top-ranked search results for "volatility tutorial" still point to V2-era material because that material accumulated pagerank over a decade. Ignore it. The authoritative V3 documentation is at volatilityfoundation.github.io/volatility3/, and any training material written since 2021 that uses --profile rather than auto-symbol-resolution is teaching from outdated foundations.
Try it — Verify both tools operate coherently against the same image
Setup. Install Volatility 3 via pip install volatility3 into a fresh Python virtualenv. Install MemProcFS from the ufrisk/MemProcFS GitHub releases page (Windows) or from your package manager / source build (Linux). Pick a small test image — capture your own workstation with WinPmem if nothing else is available, or use any memory sample from the Volatility Foundation or your own Target-Win clean baseline.
Task. Run three checks. (1) vol -f testimage.raw windows.info — confirm the OS identification resolves correctly and the KernelFileVersion field is populated. (2) vol -f testimage.raw windows.pslist | head -20 — confirm the process listing returns rows. (3) Mount the same image with MemProcFS (MemProcFS.exe -device testimage.raw on Windows, or memprocfs -device testimage.raw -mount /mnt/mem on Linux), navigate to the pid/ folder, and open any process's folder to see its structure exposed as files.
Expected result. Volatility 3's windows.info identifies the OS with a populated kernel version. windows.pslist returns a tabular listing with headers and rows. MemProcFS mounts without warnings and the pid/ folder contains one subfolder per running process, each with name.txt, cmdline.txt, handles/, and related per-process files accessible as normal filesystem entries.
If your result doesn't match. If windows.info hangs on "downloading symbols," internet access is blocked or the workstation is air-gapped — see the extended artifact footer for the pre-staging procedure. If windows.pslist returns zero rows, Volatility 3 couldn't locate the kernel (check KernelFileVersion from windows.info). If MemProcFS reports "unsupported OS" or shows empty pid/ folders, the image is either corrupt (re-verify acquisition hash) or the MemProcFS version predates support for the target Windows build (update from the GitHub releases page).
You should be able to do the following without referring back to this sub. If you can't, the sections to re-read are noted.
You've set up the lab and captured your first clean baselines.
MF0 built the three-VM lab and established the memory forensics landscape. MF1 taught acquisition with WinPmem and LiME, integrity verification, and chain of custody. From here, you execute attacks and investigate what they leave behind.
- 8 attack modules (MF2–MF9) — process injection, credential theft, fileless malware, persistence, kernel drivers, Linux rootkits, timeline construction, and a multi-stage capstone
- You run every attack yourself — from Kali against your target VMs, then capture memory and investigate your own attack's artifacts with Volatility 3
- MF9 Capstone — multi-stage chain (initial access → privilege escalation → credential theft → persistence → data staging), three checkpoint captures, complete investigation report
- The lab pack — PoC kernel driver and LKM rootkit source code, setup scripts, 21 exercises, 7 verification scripts, investigation report templates
- Cross-platform coverage — Windows and Linux memory analysis in one course, with the timeline module integrating evidence from both
Cancel anytime