vol-rs

A port of the Volatility 3 memory forensics framework from Python to Rust. It reads the same memory images, runs the same plugins with the same options, and prints the same output, byte for byte, a good deal faster.

License

This project is a port of Volatility 3 and is therefore an "Addition" under the Volatility Software License 1.0, so it is published under that same license. The full text is in LICENSE and online at https://www.volatilityfoundation.org/license/vsl-v1.0. Every source file keeps the notice recording what it was derived from.

This project is not affiliated with or endorsed by the Volatility Foundation. The name Volatility is used only to say what this is a port of.

Building

Rust 1.85 or newer, then:

cargo build --release

The binary lands at target/release/vol-rs. Nothing optional is needed. Symbol decompression, RC4, DES, AES, YARA matching, x86 disassembly, PNG writing and tar archives are all built in, where the Python version reaches for pycryptodomex, yara-python, capstone and pillow.

Using it

./target/release/vol-rs -f memory.raw windows.pslist.PsList
./target/release/vol-rs -f memory.lime linux.bash.Bash
./target/release/vol-rs -f memory.raw -r csv windows.netscan.NetScan
./target/release/vol-rs windows.malfind.Malfind --help
./target/release/vol-rs --list-plugins

Every option the Python version takes is taken here too, with the same names and the same defaults, including -o, -r, -s, -c, -e, --filters, --hide-columns, --save-config, --stackers and --single-swap-locations. Each plugin's own options match as well, which the help pages show: all 197 of them are identical to the Python ones, character for character.

Symbols

Symbol packs go in $XDG_DATA_HOME/vol-rs/symbols, or ~/.local/share/vol-rs/symbols when that variable is not set. A pack somewhere else is named with --symbol-dirs or through the VOLRS_SYMBOL_PATH environment variable. A Windows kernel that no pack describes is looked up on the Microsoft symbol server, and the database found there is turned into a symbol file and kept, so the fetch happens once. The database itself is cached under ~/.cache/vol-rs and the symbol file is written beside the packs.

What has been checked

Both sides were run against the same captures and diffed, header framing and trailing newlines included:

The eight files that did not compare equal are the two cases listed under Known differences below. Seven are partial files the Python version leaves on disk after reporting that it could not dump them, which this port does not create, and one is a tarball whose contents match but whose timestamps record when each run happened.

Windows symbols are built from the database Microsoft publishes for the kernel in the image. For the capture used here that description matches the one the Python version builds from the same database exactly, across all 16 base types, 293 enumerations, 1,653 structures and 40,007 symbols.

The two plugins missing from those counts are the ones the Python version cannot finish on the test machine. windows.memmap.Memmap is killed by the out of memory killer after 7.8 million lines, and linux.pscallstack.PsCallStack is killed before it ends. In both cases every line the Python version managed to write first is reproduced exactly.

Across every plugin that runs with no arguments, the Windows sweep takes 273 seconds here against 5723 seconds, and the Linux sweep 68 seconds against 3130 seconds.

Speed

The ten widest gaps on each capture, out of every plugin that runs with no arguments:

Windows

Linux

BENCHMARKS.md has the rest: every plugin on both captures, the runs that take arguments, and the machine the numbers were measured on.

Known differences

A handful of things cannot match, and each is deliberate:

• linux.pagecache.RecoverFs stamps every file in the tarball it writes with the moment the plugin ran, so no two runs agree, not even two Python runs. The table matches and so does the unpacked tree.
• --save-config and timeliner --record-config record every setting that describes the image, but not the Python version's checks that an imported component is new enough, because this port has no such checks to record.
• linux.mountinfo --mount-format joins a Python set, so its column order changes between two Python runs. This port lists the mount options first and the filesystem options after, in the order the kernel holds them.
• frameworkinfo and isfinfo describe the tool rather than the image, so they report this port's own layers, plugins and symbol files.
• windows.dumpfiles does not leave behind the partial files the Python version creates before it discovers it cannot read them. The tables agree, the directories differ by those files.
• The line in --help naming the cache directory names this port's own cache.

To do

Everything below is ported and builds, but has not been run against real evidence yet:

• Test the 23 macOS plugins against a real Mac capture. All 23 were read line by line against the Python source, and every type, member and symbol they touch was checked against the 129 published Darwin symbol files covering 10.10 to 10.15, so the version fallbacks are known to be complete. What is left is a real Mac image to run them on.
• Test 32 bit images. All the verification so far used 64 bit captures, so the Intel32 and PAE paging paths have only unit test coverage.
• Test the other image formats. Only VMware and LiME captures have been used, so the crash dump, AVML, QEMU, ELF core and Xen layers are still unproven on real files.
• Test more kernel versions. One Windows 10 19045 and one Linux 6.8 capture is a narrow base, and plugins that read version specific structures are where a port is most likely to drift.
• Add the arrow and parquet renderers. They are accepted on the command line and refused, which is what the Python version does when its table library is missing.

Credit

Volatility 3 is the work of the Volatility Foundation and its contributors. This is a port of their design, their plugin set and their output format, and it exists because that work is open.