Zum Inhalt springen
Pagefile.sys Parser
← Zurück zum Blog

Registry-Hive-Fragmente aus pagefile.sys carven

20.5.2026 · 4 Min. Lesezeit

Registry-Hives leben permanent im RAM — jeder Prozess öffnet beim Start Hive-Handles, und Windows cacht aktive Hives im Non-Paged-Pool. Aber die älteren / kälteren Teile großer Hives (man denke an SOFTWARE auf einem ausgelasteten Server oder eine inaktive NTUSER.DAT eines ungenutzten Users) werden ausgelagert, und genau dort spielt Pagefile-Carving seinen Wert aus: man kann gelöschte oder modifizierte Registry-Daten rekonstruieren, die auf der Disk nicht mehr sichtbar sind.

Die zwei relevanten Signaturen

Windows-Registry-Hives bestehen aus zwei Blocktypen, beide auf 4 KB ausgerichtet und beide trivial carvebar:

SignaturHexWas es ist
regf72 65 67 66Hive-Basisblock — der Dateiheader
hbin68 62 69 6EHive-Bin — ein 4-KB-Cell-Container

Ein vollständiger Hive auf Disk beginnt mit einem einzelnen regf-Block (4 KB), gefolgt von einer Sequenz von hbin-Blöcken. In einem Pagefile bekommt man die Sequenz fast nie intakt — was man bekommt, sind viele isolierte hbin-Blöcke, jeder ein 4-KB-Stück Registry-Daten, das aus dem RAM ausgelagert wurde.

Der Parser klassifiziert jede 4-KB-Seite und markiert regf-/ hbin-Treffer im Tab Page map. Per Klick sehen Sie den absoluten Datei-Offset.

Was in einem isolierten hbin überlebt

Ein hbin ist ein Container für Cells. Jede Cell ist entweder:

  • Ein Key Node (nk) — enthält Schlüsselname, Last-Write-Zeit, Parent-Referenz und Subkey-Anzahl.
  • Ein Value Entry (vk) — Name, Typ (REG_SZ, REG_DWORD, REG_BINARY etc.), Daten-Offset.
  • Eine Subkey-Liste (lf, lh, li, ri).
  • Ein Security Descriptor (sk).
  • Big Data für Werte größer als die Cell-Größe (db).
  • Die eigentlichen Werte-Bytes.

Ein einzelnes 4-KB-hbin enthält typischerweise einige Dutzend Cells. Selbst ein abgehängtes Bin kann liefern:

  • Die Namen und Last-Write-Zeiten der Schlüssel, die in diesem Bin lagen.
  • Die Namen und Typen der Werte plus deren Daten, sofern die Daten inline vorlagen (was bei den meisten REG_SZ- und REG_DWORD-Werten der Fall ist).
  • Gelöschte Cells: Wenn ein Schlüssel oder Wert entfernt wird, wird die Cell als frei markiert (das hohe Bit der Größe wechselt), ihr Inhalt aber nicht genullt. Live-Hive-Tools überspringen gelöschte Cells; Carver können sie lesen.

Das ist die forensische Hauptbeute — Registry-Artefakte, die im lebenden Hive nicht mehr existieren.

Cells aus einem gecarvten hbin extrahieren

Ein einzelnes hbin lässt sich nicht direkt in Regedit oder Registry Explorer laden — diese wollen eine vollständige regf-präfigierte Datei. Der Workflow:

  1. hbin-Seiten im Pagefile per Page Map dieses Tools finden.
  2. Die absoluten Offsets notieren, z. B. 0x12340000, 0x12341000.
  3. Die Bytes per dd herausziehen: 
    dd if=pagefile.sys of=hbin1.bin bs=1 skip=$((0x12340000)) count=4096
  4. Entweder:
    • Manuell parsen: Die Microsoft-Referenz zum Windows-Registry- Dateiformat (libregf-Docs) ist die kanonische Quelle.
    • Einen synthetischen regf-Header voranstellen, damit ein Hive-Viewer die Datei akzeptiert — yarp (Maxim Suhanovs Python-Registry-Parser) bietet Hilfsfunktionen dafür und ist deutlich toleranter gegenüber Korruption als hivexsh oder Registry Explorer.

Was in gecarvten Hives zu suchen ist

Die Schlüssel, deren Rekonstruktion aus einem Pagefile am meisten bringt:

  • SAM\Domains\Account\Users\… — RID, NT-Hash, Account-Flags.
  • SECURITY\Policy\Secrets\… — LSA-Secrets (Maschinenkonto-Passwort, Service-Account-Credentials, DPAPI-Masterkeys).
  • SOFTWARE\Microsoft\Windows\CurrentVersion\Run / RunOnce — Persistenz-Einträge.
  • SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks — Scheduled-Task-GUIDs.
  • SYSTEM\CurrentControlSet\Services\… — installierte Dienste, inklusive Malware, die sich selbst registriert hat.
  • NTUSER.DAT Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU — zuletzt eingegebene Befehle aus dem Ausführen-Dialog.
  • NTUSER.DAT Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths — Verlauf der Explorer-Adressleiste.
  • UsrClass.dat ShellBags — vom Benutzer geöffnete Ordner, auch bereits gelöschte.

Ein gecarvtes Fragment eines dieser Bereiche ist forensisch aussagekräftig, auch ohne den umgebenden Hive-Kontext.

Abgleich mit dem lebenden System

Wenn Sie sowohl das Pagefile als auch die lebenden SOFTWARE-/SYSTEM-/SAM-/NTUSER.DAT-Hives aus C:\Windows\System32\config\ haben:

  • Diffen Sie die gecarvten Fragmente gegen den lebenden Hive — alles, was in den gecarvten Daten steht und im lebenden Hive fehlt, ist gelöscht. Das ist die Spur.
  • Mit yarp (oder regipy) beide durchlaufen und eine vereinigte Werteliste ausgeben.

Einschränkungen speziell beim Registry-Carving

  • Kein Replay des Transaction Logs: Das lebende Hive-System nutzt *.LOG1-/*.LOG2-Dateien für dauerhafte Schreibvorgänge; in einem ausgelagerten Fragment sehen Sie eventuell einen Pre-Commit-Zustand, den das lebende Hive längst überschrieben hat.
  • Cell-Offsets sind relativ zum Hive-Base: Pointer von einer Cell zur anderen (Subkey-Listen-Pointer, Value-Listen) sind ohne den vollständigen Hive-Basisblock nutzlos — Sie können die Cells inline lesen, aber nicht durch sie navigieren.
  • Komprimierte Seiten: Unter Windows 10+ kann ein hbin vor dem Auslagern Xpress-Huffman-komprimiert sein. Dieses Tool markiert solche Seiten in der Page Map; manuelle Dekompression ist ein zukünftiges Feature.

Weiterführend