pagefile.sys ist eine Goldgrube — und eine Falle. Was es nützlich macht
(ein roher Dump ausgelagerter Speicherseiten) ist zugleich die Quelle
jeder Einschränkung.
Keine Prozesszuordnung
Eine Pagefile-Seite lässt sich allein nicht einem Prozess zuordnen. Das Mapping Seite → (Prozess, virtuelle Adresse) lebt in den Page Table Entries (PTEs) im RAM. Ohne RAM-Dump liest man Inhalt, aber keinen Kontext. Deshalb verarbeitet Volatility Pagefiles nicht direkt — es braucht die PTEs eines RAM-Images.
Keine Allocation-Rekonstruktion
Eine Allokation größer als 4 KB wurde als getrennte Seiten in jeweils
freie Slots ausgelagert. Zwei benachbarte Seiten in pagefile.sys haben
fast nie etwas miteinander zu tun. Carving liefert Hits pro Seite —
selten eine vollständige Datei.
Speicherkompression unter Windows 10+
Seit Windows 10 komprimiert der CompressionStoreManager kalte Seiten
im RAM vor jedem Disk-I/O. Der Algorithmus ist Xpress-Huffman
(CompressionFormat 4).
Wenn eine solche Seite geschrieben wird, landen die komprimierten Bytes
in pagefile.sys. Eine reine String-Suche verfehlt den Inhalt. Die
Dekompression erfordert das Parsen der Huffman-Codelängentabelle —
nicht trivial in WebAssembly und noch nicht implementiert. Das Blackhat-
2019-Paper „Paging All Windows Geeks" dokumentiert den Algorithmus.
Dieses Tool erkennt und markiert wahrscheinliche Xpress-Huffman-Blöcke — die Dekompression ist Future Work.
Selektive Auslagerung
Nicht alles Ausgelagerte landet in pagefile.sys: es gibt auch
swapfile.sys (UWP-Apps) und hiberfil.sys (RAM-Snapshot beim
Hibernate).
Flüchtig, fragil, partiell
Daten können beim nächsten Page-out-Zyklus überschrieben werden. Ein
pagefile.sys ist ein Schnappschuss eines Augenblicks, kein
Append-only-Log.
Was trotzdem bleibt
Trotzdem liefert pagefile.sys zuverlässig: Klartext-Credentials, C2-URLs
und -IPs, Kommandozeilen kurzlebiger Prozesse, gelöschte Hive-Fragmente,
sonst nicht wiederherstellbaren Dokumentinhalt. Für Triage ist das oft
genug.