Volatility 3: memory forensics from a RAM image, and what the install actually costs

What Volatility 3 reads, and who ends up running it

Volatility 3 extracts digital artifacts from volatile memory samples. The README states that the extraction techniques are performed completely independent of the system being investigated, which is the whole point: you analyse a RAM image without booting the machine it came from. The framework is aimed at people learning the techniques and complexities of memory artifact extraction, and it also serves as a platform for further research.

The audience is narrower than the topic list suggests. If you do incident response, malware analysis or digital investigation and you already have a memory capture, this is the tool that turns that capture into process lists, loaded modules and other runtime state. If you do not have a capture, this project does not give you one. Nothing in the README describes acquisition; it describes extraction from samples you supply with -f or --single-location.

The 2019 rewrite is the reason the current code base exists at all. The README says Volatility 3 was written to address technical and performance challenges that became apparent in the original code base over the previous ten years, and that the rewrite allowed release under the Volatility Software License instead of the earlier terms. Two consequences follow. First, plugins and internal APIs differ from Volatility 2, so old habits and old scripts do not carry over unchanged. Second, the licence question is not cosmetic, and it is covered further down.

How vol loads an image and why symbols decide what you can see

The entry point is the vol script, declared in pyproject.toml as volatility3.cli:main. A plugin is selected by name after the image argument, so the command shape is vol -f <image> <plugin>. The README notes that -f or --single-location is not strictly required, but most plugins expect a single sample, and that some plugins take additional options discoverable with vol <plugin> -h.

Symbol tables are the mechanism that makes a plugin work on a given image. The README distributes packs for Windows, Mac and Linux as separate zip files, and states that the zip files must be placed, as named, into the volatility3/symbols directory, or into a symbols directory next to the executable file. Windows symbols that cannot be found are queried, downloaded, generated and cached. Mac and Linux symbol tables must be produced manually by a tool such as dwarf2json.

That asymmetry is the most important architectural fact for a new user. On Windows the framework can fill gaps for you. On Mac and Linux it cannot, because the README explains that Linux kernels are easy to compile and cannot be uniquely distinguished, so an exhaustive set of Linux symbol tables cannot easily be supplied. If you analyse Linux memory, symbol production is part of your workflow, not an afterthought. The README also warns that the first run against new symbol files requires the cache to be updated, that the packs contain a large number of files, and that this may take some time. It only needs to run once per new symbol file, and if interrupted it restarts on the next run.

Installing Volatility 3 and running a first plugin

The published package is volatility3 on PyPI, and it requires Python 3.8.0 or later. The README's install line is:

pip install volatility3

After that, the installed console script is vol. The README's quick start uses an editable install of the full dependency set for development work:

pip install --user -e ".[full]"

The [full] extra pulls in the optional dependencies listed in pyproject.toml: yara-python, capstone, pycryptodome, leechcorepyc (not on macOS), and pillow. If you only need the core, the base package depends on pefile alone.

Confirm the tool responds before touching an image:

vol -h

Then identify the sample. The README recommends windows.info as the check that Volatility supports a given Windows image type:

vol -f /home/user/samples/stuxnet.vmem windows.info

What you should see is basic operating system information for the sample, which tells you whether symbol resolution worked. If it did not, the symbol pack is the first thing to check. For the development branch, the README's clone path uses a virtual environment and the dev extra:

git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3/
python3 -m venv venv && . venv/bin/activate
pip install -e ".[dev]"

Note the branch detail in the README: the latest stable version is always the stable branch, while the default branch is develop. If you want stable behaviour, do not clone the default branch by reflex.

Where Volatility 3 will not help you

The first limitation is stated plainly by the framework's own scope. Volatility 3 extracts artifacts from volatile memory samples. It is not an acquisition tool, and the README does not document capturing memory from a running host. If your problem is getting the image in the first place, this project is the wrong end of the pipeline.

The second is symbol coverage. The README describes the Windows, Mac and Linux packs as representative and complete up to the point of creation. A kernel newer than the pack, or a Linux build that dwarf2json cannot resolve cleanly, leaves you producing symbols yourself before any plugin returns useful output. Windows has the automatic query and cache fallback; the other two do not.

The third is first-run cost. The cache update on new symbol files can take some time, and the README does not document a way to skip it. On a constrained machine or a shared analyst workstation, that is a real scheduling constraint rather than a footnote.

The fourth is plugin behaviour. Because -f is not strictly required but most plugins expect a single sample, command lines that work for one plugin can behave differently for another. The README points to vol <plugin> -h rather than documenting each plugin's options centrally, so discovering what a plugin accepts is part of using it.

Finally, the documentation model. The README says the framework is documented through doc strings and can be built with sphinx, with a generated copy at volatility3.readthedocs.io. That means the README is not the reference; the docstrings are. Anyone expecting a task-oriented manual in the repository will be reading source.

Volatility 2 versus Volatility 3: what actually changed

The most direct alternative to Volatility 3 is Volatility 2, and the difference is not a version bump. Volatility 3 is a complete rewrite released by the Volatility Foundation in 2019, written to address technical and performance challenges in the original code base that had become apparent over ten years. The rewrite also changed the licence, moving to the Volatility Software License, which the README describes as more aligned with the goals of the Volatility community.

In practice the split matters in two places. Volatility 2 has years of third-party plugins and community write-ups behind it; Volatility 3 has a different plugin interface, so that ecosystem does not transfer directly. And the symbol story differs: Volatility 3 ships downloadable symbol packs and, on Windows, can query, download, generate and cache missing symbols, whereas Mac and Linux tables are produced with dwarf2json. If your existing tooling and notes are all Volatility 2 shaped, migrating is a rewrite of your workflow, not a rename of the binary.

The other axis is the interface. Volatility 3 is a command line tool invoked as vol, with volshell available as a separate console script for interactive work. The README does not describe a graphical interface, so anyone searching for one should treat the shell and the plugin CLI as the interface.

Licence, releases and the cost of keeping up

Volatility 3 is released under the Volatility Software License, version 1.0, linked from the README and identified in pyproject.toml as license = { text = "VSL" }. The pyproject metadata is not the licence text, and the repository's LICENSE.txt is the file to read. The README states that the rewrite allowed release under a custom licence more aligned with the community's goals, which is a hint that the terms differ from a permissive licence in ways that matter to commercial redistribution and internal deployment. That is a question for your own legal review; the project's own documentation is where the terms live, and the README does not summarise them.

On maintenance, the repository is not archived, and the last push was on 2026-09-17. Releases are tagged with both a Volatility 3 version and a framework version: v2.28.2 on 2026-09-17, v2.28.0 on 2026-04-30, and v2.27.0 on 2026-01-29. The cadence implied by those three tags is a few months between minor releases, with patch releases in between.

Upgrade cost is dominated by symbols rather than by the package. A new release may need a newer symbol pack, and the README's cache warning applies again on the first run against new symbol files. API_CHANGES.md exists at the top level, which is the file to read before upgrading if you maintain plugins against the internal API. The README does not document a rollback procedure.

Editorial conclusion

Adopt Volatility 3 if you already hold RAM images and need to inspect them without booting the source system, and if your use fits the Volatility Software License. Do not adopt it as a live acquisition tool: the README describes extraction from samples, not capture. Before committing, verify three things: that Python 3.8.0 or later is available, that the symbol packs for your target operating system are in place, and that the first-run cache build finishes on your hardware, since the README warns it may take some time. The Windows path is the least manual; Mac and Linux symbol tables have to be produced with a tool such as dwarf2json.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. volatilityfoundation/volatility3 on GitHub