Wie weit reicht das $LogFile zurück? Grenzen und Fallstricke

Q: Lässt sich das $LogFile dazu bringen, mehr Historie zu behalten?

Ja, als vorbereitende Maßnahme vor einem Vorfall: chkdsk /L:Größe ändert die Loggröße eines NTFS-Volumes. Ein größeres Log behält mehr Historie. Führen Sie das nicht auf einem Volume aus, das Sie gleich als Beweismittel sichern wollen, denn es verändert das Log.

TL;DR. Das $LogFile ist auf den meisten aktuellen Volumes ein Ringpuffer von etwa 64 MiB. Auf einem viel genutzten Systemlaufwerk sind das Minuten bis Stunden Historie; auf einem Zweit- oder Wechsellaufwerk kann es deutlich mehr sein. Neben der Aufbewahrung hat es vier strukturelle blinde Flecken: keine Uhrzeit, Namen nur bei Änderungen, nur Metadaten (keine nicht residenten Inhalte) und Anfälligkeit (chkdsk, ntfs-3g und Ihre eigene Aktivität überschreiben es). Außerdem sind sich Parser in Details uneins. Nutzen Sie es für das letzte Aktivitätsfenster und kombinieren Sie es mit USN-Journal, $MFT und Schattenkopien.

Nichts davon macht das Log weniger nützlich. Es macht es zu einem präzisen Instrument mit kurzer Reichweite – und Berichte, die die Reichweite vergessen, werden angefochten.

Aufbewahrung: wie die Zahlen aussehen

Faktor	Wirkung
Loggröße	Standard auf aktuellen Windows-Volumes meist um 64 MiB; `chkdsk /L` zeigt oder ändert sie (Microsoft Learn). Ältere oder kleine Volumes können kleiner sein – Microsofts eigenes chkdsk-Beispiel zeigt 22.544 KB (KB 814594)
Metadaten-Aktivität	Jedes Anlegen, Umbenennen oder Löschen einer Datei, jede Attribut- oder Indexänderung verbraucht Platz im Log. Browser, Updates, Virenscans, Indizierung und SRUM erzeugen ständig Aktivität
Rolle des Volumes	Systemvolumes am meisten; Daten- und Wechselvolumes am wenigsten
Checkpoints	Die bei jedem Checkpoint geschriebenen Tabellen-Dumps verbrauchen ebenfalls Platz

Veröffentlichte Beobachtungen:

Maxim Suhanov hat unter Windows 10 gemessen, wann alte Daten überschrieben werden: 16 Minuten in einem Test, 5 Stunden 20 Minuten in einem anderen (How the $LogFile works?).
Joakim Schichts LogFileParser-Readme rechnet auf einem häufig genutzten Systemlaufwerk mit „a few hours“ und auf externen oder Zweitplatten mit deutlich mehr.
TZWorks beschreibt für ein 64-MB-Log einige Stunden Aktivität bei normaler Nutzung (mala).

Betrachten Sie das als Größenordnungen. Die einzige verlässliche Zahl ist die in Ihrem Beweismittel: der LSN-Bereich laut Parser und das älteste datierte Ereignis.

Mehr Historie gewinnen

Früh sichern. Vor speicherintensiver Triage, bevor Werkzeuge auf den Host kopiert werden.
Jedes Volume. Ein USB-Stick oder ein Datenvolume enthält vielleicht noch den gestrigen Tag.
Volumeschattenkopien. Jeder Snapshot enthält ein älteres $LogFile. Werten Sie jedes aus und versehen Sie es mit dem Zeitpunkt des Snapshots.
Vorbereitung. Auf Systemen, die Sie selbst verwalten, behält ein größeres Log (chkdsk C: /L:<Größe in KB>) mehr Historie. Das LogFileParser-Readme nennt chkdsk D: /L:2097152 als Beispiel für 2 GB. Testen Sie vorher die Auswirkungen auf die Performance, und tun Sie das nie auf einem System, das Sie gleich sichern wollen.

Blinder Fleck 1: keine Uhr

LFS-Einträge tragen LSNs, keine Zeiten. Jede Zeit, die ein Parser anzeigt, stammt aus den protokollierten Daten:

Ereignis	Zeitquelle	Verlässlichkeit
Erstellung	`$FILE_NAME`-Erstellungszeit im FILE-Record oder Indexeintrag	Gut
Umbenennung / Verschiebung	`$FILE_NAME`-Änderungszeit	Gut
`$SI`-Änderung	Neuer `$SI`-Wert	Gut, sofern nicht zurückdatiert (Timestomping)
Löschung	Letzte bekannte Zeit der Datei	Nur Untergrenze
Alles andere	Nächstgelegener datierter Nachbar (≈)	Näherungsweise

Deshalb kennzeichnet der Browser-Parser für das $LogFile jedes Ereignis mit seiner Zeitquelle. Für exakte Zeiten korrelieren Sie mit $UsnJrnl:$J (USN-Journal-Parser) und vergleichen die Artefakte.

Blinder Fleck 2: Namen sind nicht immer da

Die meisten Logeinträge nennen einen MFT-Eintrag, keine Datei. Namen erscheinen, wenn ein Indexeintrag hinzugefügt oder entfernt wird (Anlegen, Umbenennen, Löschen) oder wenn ein vollständiger FILE-Record geschrieben wird. Eine Zeitstempeländerung an einer Datei, die letzte Woche angelegt wurde, kommt nur mit einer Eintragsnummer. Die $MFT desselben Volumes löst den Rest auf; ohne sie beginnen Pfade mit [MFT #n]. Wurde die $MFT später gesichert als das Log, können wiederverwendete Einträge zu falschen Namen aufgelöst werden – prüfen Sie die Sequenznummern.

Blinder Fleck 3: nur Metadaten

Nicht residente Dateiinhalte laufen nie durch das Log.
Kleine, residente Dateien können in FILE-Record-Abbildern oder Attributerstellungen auftauchen. Die Dokumentation von LogFileParser ergänzt, dass unter modernen Windows-Versionen spätere Änderungen an residenten Daten in der Regel nicht mit ihrem Inhalt protokolliert werden.
Lesezugriffe werden nicht protokolliert (Aktualisierungen der letzten Zugriffszeit sind Metadaten, aber oft deaktiviert oder verzögert).

Blinder Fleck 4: Es ist leicht zu zerstören

Ihre eigene Aktivität. Jede Datei, die Sie auf das Beweisvolume schreiben, erzeugt neue Logeinträge.
chkdsk. Kann das Log verändern oder in der Größe ändern; eine mit CHKD signierte Restart-Seite verrät es.
Linux ntfs-3g. Soll es ein nicht sauber geschlossenes Volume mit seiner Recovery-Option einbinden, „leert“ ntfs-3g das Log, indem es mit 0xFF gefüllt wird (ntfs_logfile_reset in libntfs-3g). Binden Sie Beweismittel immer schreibgeschützt ein.
Hartes Ausschalten vs. sauberes Herunterfahren. Ein sauberes Herunterfahren unter Windows 8+ schreibt das Log als Version 1.1 zurück ($LogFile-Format 1.1 vs. 2.0); ein Absturz lässt die Fast Pages von 2.0 an Ort und Stelle. Beides zerstört für sich genommen keine Einträge, verändert aber, wo die neueste Seite liegt.

Blinder Fleck 5: Parser sind sich uneins

Das Format ist nur durch Reverse Engineering dokumentiert. Echte Unterschiede zwischen Werkzeugen betreffen unter anderem:

ob und wie Tail- bzw. Fast Pages eingemischt werden;
welche Seite (Redo oder Undo) einer Indexlöschung den Eintrag enthält;
die Layouts der Einträge in der Open Attribute Table;
die Gruppierung von Logeinträgen zu Aktionen (nach Transaktion oder nach Nähe);
partielle $SI-Aktualisierungen.

Der Browser-Parser legt seinen eigenen Stand offen: Er ist an synthetischen Logs validiert, die nach den veröffentlichten Layouts erzeugt wurden (Linux ntfs3, libfsntfs, dfir.ru), noch nicht an einem Korpus echter Windows-Logs. Er gruppiert nach MFT-Eintrag innerhalb eines Eintragsfensters statt nach Transaktion, nimmt $SI bei Offset 0x38 an, wenn das Record-Layout unbekannt ist, folgt keinen Attributlisten und prüft beim Auflösen von Pfaden aus der $MFT keine Sequenznummern. Bestätigen Sie wichtige Befunde mit einem zweiten Werkzeug – siehe $LogFile-Parser-Vergleich: LogFileParser, NTFS Log Tracker.

Grenzen im Bericht festhalten

Ein Satz pro Befund genügt:

Das NTFS-Transaktionsprotokoll umfasst LSN 115720 bis 117880; das älteste datierte Ereignis ist 09:58:12 UTC. Aktivität vor diesem Zeitpunkt ist in diesem Artefakt nicht abgebildet. Logeinträge enthalten keine Zeitstempel; die angegebenen Zeiten stammen aus Dateisystem-Zeitstempeln innerhalb der Einträge, wie je Ereignis angegeben.

Häufig gestellte Fragen

Wie weit reicht das NTFS-$LogFile zurück?

Das hängt von Loggröße und Aktivität ab. Das Log ist zirkulär und meist etwa 64 MiB groß; auf einem viel genutzten Systemvolume deckt es Minuten bis wenige Stunden ab, auf einem ruhigen Daten- oder Wechselvolume deutlich länger. In veröffentlichten Tests unter Windows 10 wurden alte Daten einmal nach 16 Minuten und einmal nach 5 Stunden 20 Minuten überschrieben.

Lässt sich das $LogFile dazu bringen, mehr Historie zu behalten?

Ja, als vorbereitende Maßnahme vor einem Vorfall: chkdsk /L:Größe ändert die Loggröße eines NTFS-Volumes. Ein größeres Log behält mehr Historie. Führen Sie das nicht auf einem Volume aus, das Sie gleich als Beweismittel sichern wollen, denn es verändert das Log.