$LogFile-Format 1.1 vs. 2.0: was sich mit Windows 8 ändert

TL;DR. Beide Versionen beginnen mit zwei RSTR-Restart-Seiten. LFS 1.1 (Windows XP–7 sowie Windows 8+ nach sauberem Herunterfahren) folgen zwei Tail Pages – Kopien der gerade beschriebenen Seite –, und der zirkuläre Bereich beginnt bei 0x4000 (4-KiB-Seiten). LFS 2.0 (Windows 8+ im eingebundenen Zustand) verwendet stattdessen 32 Fast Pages, und der zirkuläre Bereich beginnt bei 0x22000. Bei einer Live-Sicherung können die neuesten Logeinträge ausschließlich im Tail- oder Fast-Page-Bereich liegen. Ein Parser, der ihn ignoriert, verliert die jüngste Aktivität; einer, der die falsche Version annimmt, liest die Datei falsch.

Die Version steht im Header der Restart-Seite: Minor-Version bei 0x1A, Major-Version bei 0x1C (libfsntfs, ntfs3). Alles Weitere in diesem Artikel folgt aus dieser einen Zahl.

Die beiden Layouts

Aufbau des NTFS-$LogFile für die Logformate 1.1 und 2.0 — Log-Seiten zu 4 KiB. Offsets gemäß Linux-Treiber ntfs3.

	LFS 1.1	LFS 2.0
Restart-Seiten	`0x0000`, `0x1000`	`0x0000`, `0x1000`
Sonderbereich	2 Tail Pages (`0x2000`, `0x3000`)	32 Fast Pages (`0x2000`–`0x21FFF`)
Zirkulärer Bereich beginnt bei	`4 × Seitengröße` = `0x4000`	`0x22 × Seitengröße` = `0x22000`
Wie eine Sonderseite angibt, welche zirkuläre Seite sie kopiert	Im LSN-Feld des Seiten-Headers	Expliziter Datei-Offset bei `0x3C` des `RCRD`-Headers
Typische Herkunft	XP–7; Windows 8+ nach sauberem Herunterfahren	Windows 8+ im eingebundenen Zustand

Die Offsets sind die des Linux-Treibers ntfs3 (first_page = major_ver >= 2 ? 0x22 * page_size : …), der beide Versionen wiedereinspielt.

Tail Pages (1.1)

Der LFS schreibt Logeinträge in die aktuelle Seite des zirkulären Bereichs. Diese Seite bei jedem neuen Eintrag an Ort und Stelle neu zu schreiben, birgt das Risiko, dass ein abgerissener Schreibvorgang (Torn Write) bereits festgeschriebene Einträge auf ihr zerstört. LFS 1.1 schützt sich davor mit zwei Tail Pages: Die aktuelle Seite wird zuerst in den Sonderbereich geschrieben und erst später an ihre zirkuläre Position. Wie dfir.ru beschreibt, enthält der Sonderbereich zwei Kopien der aktuellen Eintragsseite.

Für die Analyse ist die Folge einfach: Die neueste Seite eines live gesicherten 1.1-Logs kann im Tail-Bereich vollständiger sein als im zirkulären Bereich.

Fast Pages (2.0)

Mit Windows 8 wuchs der Sonderbereich auf 32 Seiten. Statt die aktuelle Seite neu zu schreiben, legt der LFS aktualisierte Seiten in einem freien Slot des Fast-Page-Bereichs ab und schreibt sie erst später in den zirkulären Bereich – das reduziert die Schreibzugriffe dort. Ältere Fassungen derselben Seite bleiben im Fast-Page-Bereich liegen und können nach einem Torn Write zur Wiederherstellung dienen (ebenfalls laut dfir.ru).

Jede Fast Page trägt bei 0x3C im RCRD-Header den Datei-Offset der zirkulären Seite, für die sie steht (file_off in ntfs3, „used when major version >= 2“). An diesem Feld erkennt ein Parser, wohin eine Fast Page gehört.

Warum eine Live-Sicherung anders aussieht als ein Post-mortem-Image

dfir.ru weist darauf hin, dass die Log-Version beim sauberen Herunterfahren standardmäßig auf 1.1 zurückgestuft wird. Auf demselben Windows-11-Rechner gilt also:

Sicherung	Üblicherweise sichtbare Version	Sonderbereich
Live (KAPE, Velociraptor, FTK Imager auf dem laufenden Host)	2.0	Fast Pages, möglicherweise mit der neuesten Seite
Image nach sauberem Herunterfahren	1.1	Tail Pages
Image nach Absturz oder hartem Ausschalten	2.0	Fast Pages im Zustand des Absturzes

Die Restart Area trägt außerdem ein Flag, das der Browser-Parser als „sauber ausgehängt“ liest (Bit 0x2 der Restart-Area-Flags); bei einer Live-Sicherung oder nach einem Absturz ist es nicht gesetzt. Version und Flag zusammen verraten viel darüber, wie das Beweismittel gesichert wurde – ein Vermerk im Bericht lohnt sich.

Was ein Parser tun muss

Beide Restart-Seiten lesen, ihre Update Sequence Arrays prüfen und die mit der höheren aktuellen LSN verwenden.
Daraus die Major-Version entnehmen und berechnen, wo der zirkuläre Bereich beginnt.
Jede zirkuläre Seite lesen.
Die Tail oder Fast Pages lesen, ermitteln, für welche zirkuläre Seite jede steht, und die zirkuläre Seite ersetzen, wenn die Sonderkopie neuer ist.
Erst dann Logeinträge suchen und dabei solche zusammensetzen, die sich über mehrere Seiten erstrecken oder vom Dateiende an den Anfang des zirkulären Bereichs umlaufen.

Der Browser-Parser macht genau das und meldet in seiner Kopfzeile „N neueste Seite(n) aus dem Tail- / Fast-Page-Bereich gelesen“. In seinem synthetischen Sample (LFS 2.0, live gesichert) stammte eine Seite aus dem Fast-Page-Bereich; ohne sie fehlten die letzten Ereignisse des fiktiven Einbruchs. Ältere Seitenkopien, die im Fast-Page-Bereich liegen bleiben können, extrahiert er noch nicht – eine mögliche Quelle zusätzlicher Einträge.

Fallstricke

0x4000 fest verdrahten. Ein reiner 1.1-Parser behandelt die Fast Pages eines 2.0-Logs als zirkuläre Seiten und platziert oder dupliziert Einträge falsch.
Den Sonderbereich ignorieren. Die neueste Seite einer Live-Sicherung liegt womöglich nur dort.
4 KiB voraussetzen. System- und Log-Seitengröße stehen im Header der Restart-Seite (0x10, 0x14); lesen Sie sie aus.
Einer CHKD-Seite vertrauen. Eine Restart-Seite mit der Signatur CHKD bedeutet, dass chkdsk am Log gearbeitet hat; den Inhalt mit Vorsicht behandeln.

dfir.ru erwähnt zudem eine geplante Version 3.0 für DAX-Volumes, die CRC32-Prüfsummen statt Update Sequence Arrays verwendet. Weder der Linux-Treiber noch der Parser dieser Website unterstützen sie; sollten Sie je Major-Version 3 sehen, rechnen Sie damit, dass Parser die Datei ablehnen.

Häufig gestellte Fragen

Welche Windows-Versionen verwenden $LogFile-Version 2.0?

Windows 8 und neuer verwenden das Logformat 2.0, solange ein NTFS-Volume eingebunden ist. Standardmäßig wird das Log beim sauberen Herunterfahren auf 1.1 zurückgestuft. Ein Image einer sauber heruntergefahrenen Windows-10- oder -11-Platte kann also 1.1 zeigen, eine Live-Sicherung dagegen 2.0.

Warum muss ein Parser die Log-Version kennen?

Die Version legt fest, wo der zirkuläre Bereich mit den Logeinträgen beginnt (0x4000 oder 0x22000 bei 4-KiB-Seiten) und wie Tail oder Fast Pages den zirkulären Seiten zugeordnet werden. Wer ein 2.0-Log mit 1.1-Annahmen liest, behandelt die 32 Fast Pages als gewöhnliche Einträge und platziert die neuesten Daten falsch.

Weiterführende Literatur

Maxim Suhanov, How the $LogFile works? – die Quelle für das hier beschriebene Verhalten von 1.1/2.0.
Linux-Kernel, fs/ntfs3/fslog.c – log_init_pg_hdr, Behandlung der Tail Pages und RECORD_PAGE_HDR.file_off.