vol-rs

Eine Portierung des Volatility-3-Frameworks für Memory-Forensik von Python nach Rust. Es liest dieselben Speicherabbilder, führt dieselben Plugins mit denselben Optionen aus und gibt dieselbe Ausgabe aus – Byte für Byte – nur ein gutes Stück schneller.

Lizenz

Dieses Projekt ist eine Portierung von Volatility 3 und daher ein „Addition“ im Sinne der Volatility Software License 1.0, weshalb es unter derselben Lizenz veröffentlicht wird. Der vollständige Text befindet sich in LICENSE und online unter https://www.volatilityfoundation.org/license/vsl-v1.0. Jede Quelldatei enthält den Hinweis, woraus sie abgeleitet wurde.

Dieses Projekt ist weder mit der Volatility Foundation verbunden noch von ihr unterstützt. Der Name Volatility wird nur verwendet, um anzugeben, wovon dies eine Portierung ist.

Erstellen

Rust 1.85 oder neuer, dann:

cargo build --release

Die Binärdatei landet unter target/release/vol-rs. Es ist nichts Optionales erforderlich. Symbol-Dekomprimierung, RC4, DES, AES, YARA-Abgleich, x86-Disassemblierung, PNG-Erstellung und Tar-Archive sind alle eingebaut, wo die Python-Version auf pycryptodomex, yara-python, capstone und pillow zurückgreift.

Verwendung

./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

Jede Option, die die Python-Version akzeptiert, wird auch hier akzeptiert – mit denselben Namen und denselben Standardwerten, einschließlich -o, -r, -s, -c, -e, --filters, --hide-columns, --save-config, --stackers und --single-swap-locations. Auch die eigenen Optionen jedes Plugins stimmen überein, wie die Hilfeseiten zeigen: Alle 197 sind mit den Python-Versionen identisch, Zeichen für Zeichen.

Symbole

Symbolpakete gehören nach $XDG_DATA_HOME/vol-rs/symbols bzw. ~/.local/share/vol-rs/symbols, wenn diese Variable nicht gesetzt ist. Ein Paket an anderer Stelle wird mit --symbol-dirs oder über die Umgebungsvariable VOLRS_SYMBOL_PATH benannt. Windows-Symbole werden bei Bedarf vom Microsoft-Symbolserver abgerufen und unter ~/.cache/vol-rs zwischengespeichert.

Was geprüft wurde

Beide Seiten wurden gegen dieselben Aufnahmen ausgeführt und verglichen, einschließlich Header-Rahmen und abschließender Zeilenumbrüche:

Die acht Dateien, die nicht gleich waren, sind die beiden unter „Bekannte Unterschiede“ unten aufgeführten Fälle. Sieben sind Teildateien, die die Python-Version auf der Festplatte hinterlässt, nachdem sie meldet, dass sie sie nicht ausgeben konnte – diese Portierung erstellt sie nicht –, und eine ist ein Tarball, dessen Inhalt übereinstimmt, dessen Zeitstempel jedoch den jeweiligen Ausführungszeitpunkt festhalten.

Die beiden Plugins, die in diesen Zählungen fehlen, sind diejenigen, die die Python-Version auf dem Testrechner nicht abschließen kann. windows.memmap.Memmap wird nach 7,8 Millionen Zeilen vom Out-of-Memory-Killer beendet, und linux.pscallstack.PsCallStack wird vor seinem Ende beendet. In beiden Fällen wird jede Zeile, die die Python-Version zuerst schreiben konnte, exakt reproduziert.

Über alle Plugins hinweg, die ohne Argumente laufen, benötigt der Windows-Durchlauf hier 273 Sekunden gegenüber 5723 Sekunden und der Linux-Durchlauf 68 Sekunden gegenüber 3130 Sekunden.

Geschwindigkeit

Die zehn größten Abstände auf jeder Aufnahme, von allen Plugins, die ohne Argumente laufen:

Windows

Linux

BENCHMARKS.md enthält den Rest: jedes Plugin auf beiden Aufnahmen, die Läufe mit Argumenten und den Rechner, auf dem die Zahlen gemessen wurden.

Bekannte Unterschiede

Eine Handvoll Dinge können nicht übereinstimmen, und jedes ist beabsichtigt:

• linux.pagecache.RecoverFs stempelt jede Datei im Tarball, den es schreibt, mit dem Zeitpunkt der Plugin-Ausführung, sodass keine zwei Läufe übereinstimmen – nicht einmal zwei Python-Läufe. Die Tabelle stimmt überein, ebenso der entpackte Baum.
• --save-config und timeliner --record-config erfassen jede Einstellung, die das Abbild beschreibt, nicht jedoch die Prüfungen der Python-Version, ob eine importierte Komponente neu genug ist, da diese Portierung keine solchen Prüfungen hat, die es aufzuzeichnen gäbe.
• linux.mountinfo --mount-format verbindet ein Python-Set, sodass sich die Spaltenreihenfolge zwischen zwei Python-Läufen ändert. Diese Portierung listet zuerst die Mount-Optionen und danach die Dateisystem-Optionen auf, in der Reihenfolge, in der der Kernel sie hält.
• frameworkinfo und isfinfo beschreiben das Tool und nicht das Abbild, daher melden sie die eigenen Layer, Plugins und Symboldateien dieser Portierung.
• windows.dumpfiles hinterlässt nicht die Teildateien, die die Python-Version erstellt, bevor sie entdeckt, dass sie sie nicht lesen kann. Die Tabellen stimmen überein, die Verzeichnisse unterscheiden sich um diese Dateien.
• Die Zeile in --help, die das Cache-Verzeichnis benennt, nennt den eigenen Cache dieser Portierung.

Noch zu tun

Alles unten ist portiert und baut, wurde aber noch nicht gegen echte Beweismittel ausgeführt:

• Testen der 23 macOS-Plugins gegen eine echte Mac-Aufnahme. Alle 23 wurden Zeile für Zeile gegen den Python-Quellcode gelesen, und jeder Typ, jedes Mitglied und jedes Symbol, das sie berühren, wurde gegen die 129 veröffentlichten Darwin-Symboldateien für 10.10 bis 10.15 geprüft, sodass die Versions-Fallbacks als vollständig bekannt sind. Was fehlt, ist ein echtes Mac-Abbild, auf dem sie ausgeführt werden können.
• Testen von 32-Bit-Abbildern. Die gesamte bisherige Verifizierung verwendete 64-Bit-Aufnahmen, daher haben die Intel32- und PAE-Paging-Pfade nur Unit-Test-Abdeckung.
• Testen der anderen Abbildformate. Es wurden nur VMware- und LiME-Aufnahmen verwendet, daher sind die Crash-Dump-, AVML-, QEMU-, ELF-Core- und Xen-Layer bei echten Dateien noch unbewiesen.
• Testen weiterer Kernel-Versionen. Eine Windows-10-19045- und eine Linux-6.8-Aufnahme sind eine schmale Basis, und Plugins, die versionsspezifische Strukturen lesen, sind dort, wo eine Portierung am wahrscheinlichsten abweicht.
• Hinzufügen der Arrow- und Parquet-Renderer. Sie werden in der Befehlszeile akzeptiert und abgelehnt, was die Python-Version tut, wenn ihre Tabellenbibliothek fehlt.

Danksagung

Volatility 3 ist das Werk der Volatility Foundation und ihrer Mitwirkenden. Dies ist eine Portierung ihres Designs, ihres Plugin-Satzes und ihres Ausgabeformats, und sie existiert, weil dieses Werk offen ist.