Wie der Windows-Prefetch-Hash berechnet wird

Ein Dateiname wie NOTEPAD.EXE-1B4A5887.pf sieht so aus, als wären die acht Hex-Zeichen eine Prüfsumme. Sind sie nicht. Sie sind ein Hash des Startpfads der ausführbaren Datei, codiert als UTF-16, mit dem Präfix \DEVICE\HARDDISKVOLUME{n}\. Der Byte-Inhalt von notepad.exe geht nie in die Berechnung ein. Zwei Kopien derselben Binärdatei unter C:\Windows\System32\notepad.exe und C:\Users\analyst\notepad.exe erzeugen zwei verschiedene .pf-Dateien, weil sich ihre Pfade unterscheiden.

Das ist der ganze Grund, warum Prefetch zwischen psexec.exe in C:\Program Files\ und psexec.exe, das nach C:\Users\victim\AppData\Local\Temp\ abgelegt wurde, unterscheiden kann. Der Pfad-Hash ist die Per-Start-Ort-Kennung.

Drei Algorithmen, drei Epochen

Die Funktion wurde in der OS-Geschichte zweimal ersetzt:

• Windows XP / Server 2003. Der originale SuperFetch-Hash. Einfache rollende Berechnung über den UTF-16-Pfad.
• Windows Vista / 2008. Dieselbe Familie, anderer konstanter Multiplikator, anderer Start-Seed. Vista-Hashes stimmen nicht mit XP-Hashes für denselben Pfad überein und umgekehrt.
• Windows 7 und neuer. „Hash Function 5" in Microsofts Terminologie. Immer noch in Windows 10 und Windows 11 in Verwendung. Faltet Gruppen von Bytes aus dem UTF-16-Pfad durch eine Multiply-and-XOR-Schleife, maskiert auf 32 Bit, und das wird als die acht Hex-Zeichen im Dateinamen gerendert.

Der String, der allen dreien zugeführt wird, enthält ein \DEVICE\HARDDISKVOLUME{n}\-Präfix und den Dateipfad in Großbuchstaben-UTF-16 LE. Auf späteren Windows-Versionen gibt es einige Eigenheiten dabei, wie Befehlszeilenargumente und bestimmte Volume-Formate in die Berechnung eingehen, aber für den üblichen Fall ist der Pfad genau das, was man erwartet.

Warum es in der Praxis wichtig ist

Eine eingeschleuste Prefetch-Datei ist einer der billigeren Anti-Forensik-Tricks: eine .pf von einem anderen Host auf das Ziel kopieren. Der Pfad innerhalb des SCCA-Payloads ist das, was er auf der Quellmaschine war; der Dateiname-Hash ist das, was die Quellmaschine berechnete. Eine eingeschleuste Datei hat keinen Hash, der zu ihrem eigenen eingebetteten Pfad passt, wenn dieser unter dem Algorithmus des Ziels neu berechnet wird, besonders über größere Windows-Versionen hinweg.

Die Prüfung ist mechanisch:

1. Parsen Sie den SCCA-Payload.
2. Holen Sie sich den Pfad der ausführbaren Datei (das Feld Executable filename plus die Volume-Informationen).
3. Rekonstruieren Sie den kanonischen UTF-16-LE-Großbuchstaben-String mit dem \DEVICE\HARDDISKVOLUME{n}\-Präfix.
4. Führen Sie ihn durch den Algorithmus für das Versionsfeld im Payload (v17 verwendet die XP-Funktion, v23 die Vista-Funktion, v26/v30/v31 verwenden Hash Function 5).
5. Vergleichen Sie mit den acht Zeichen im Dateinamen.

Eine Abweichung ist schlüssig. Entweder wurde die Datei von einer Maschine mit einer anderen OS-Version eingebracht oder jemand hat sie von Hand gebastelt und den Algorithmus falsch gewählt.

Wenn der Hash das Einzige ist, was übrig bleibt

Moderne SCCA-Payloads behalten keinen Roh-Pfad-String mehr, wie es XP tat. Sie behalten den Dateinamen der ausführbaren Datei (ohne Pfad), die Volume-Seriennummern und die Dateimetrik-Liste von allem, was die Binärdatei berührte. Die Frage „woher lief das" muss oft aus dem Dateiname-Hash kombiniert mit der Volume-Informationssektion beantwortet werden. Paaren Sie das mit MFT-Volume-Datensätzen und LNK-Laufwerks-Seriennummern, die dieselbe NTFS-Seriennummer tragen, und Sie können die Binärdatei in der Regel auf ein bestimmtes physisches oder Wechsel-Volume festnageln.

Wenn die Binärdatei auf einem USB-Stick lebte, der seitdem abgezogen wurde, und die Volume-Seriennummer zu keinem Volume auf dem Host passt, ist der Dateinamen-Hash Ihr verbleibender Hinweis. Die Hash-Funktion in die offensichtliche Richtung umkehren (geht nicht, sie ist Einweg) — oder, nützlicher, die Kandidatenpfade hashen, von denen Sie annehmen, dass die Binärdatei lief, und nach einem Treffer suchen. Praktiker führen aus genau diesem Grund kleine Tabellen erwarteter Hashes für übliche Angreifer-Tooling-Locations.

Implementierungs-Notizen

Open-Source-Implementierungen aller drei Funktionen finden sich in der Dokumentation von libyals libscca und im Rust-Crate frnsc-prefetch. Die Vista- und Win7+-Funktionen sind kurz genug, um sie inline einzubauen — etwa ein Dutzend Zeilen jeweils — ohne eine Abhängigkeit hereinzuziehen. PECmd legt den geparsten Pfad offen; den Hash davon neu zu berechnen ist ein Einzeiler.

Der Parser auf dieser Seite verifiziert den Hash noch nicht automatisch. Er legt sowohl den geparsten Pfad als auch den Dateinamen-Suffix offen, damit Sie manuell gegenprüfen können. Eine Mismatch-Markierung steht auf der Liste.

Weiterführende Literatur

• libyal, libscca-Format-Dokumentation — die gründlichste öffentliche Beschreibung aller drei Algorithmen.
• Yogesh Khatri, Beiträge zum Prefetch-Hashing über Windows-Versionen hinweg — praktische Beispiele mit bekannten Testvektoren.