Skip to content
FSEvents Parser

FSEvents-Datensätze ohne Zeitstempel datieren

FSEvents-Datensätze haben keine Zeit: ehrliche Zeitfenster aus den mtimes der .fseventsd-Logs, uuid-Dateien und datierten Pfaden bilden – und wo das scheitert.

Veröffentlicht am 4 Min. Lesezeit
fseventstimelinemacos-forensicsdfir

Kurzfassung. Ein Datensatz wurde zwischen der Änderungszeit der vorherigen Logdatei und der eigenen Änderungszeit seiner Logdatei geschrieben. Dieses Fenster plus die Reihenfolge der Event-IDs ist alles, was FSEvents über die Zeit aussagen kann. Alles andere (ein datierter Pfad, ein APFS-Zeitstempel, ein Eintrag in den Unified Logs) ist Korrelation. Berichten Sie Zeitspannen und nennen Sie Ihren Anker.

Warum es keinen Zeitstempel gibt

Jeder Datensatz enthält einen Pfad, eine Event-ID, Flags und (in neueren Versionen) eine Node-ID. Die Event-ID ist ein Zähler, keine Uhr. Die einzigen verfügbaren Zeiten sind die Dateisystem-Metadaten der Logdateien selbst und von fseventsd-uuid.

Die Fenstermethode

fseventsd puffert Ereignisse im Speicher, hängt sie an die aktuelle Logdatei an und beginnt von Zeit zu Zeit eine neue Datei. Für die nach Event-ID sortierten Logdateien eines Volumes gilt daher:

  • Die Änderungszeit einer Datei ist der Zeitpunkt, zu dem ihre letzten Datensätze geschrieben wurden: eine Obergrenze für jeden Datensatz darin;
  • die Änderungszeit der vorherigen Datei markiert ungefähr, wann diese Datei begonnen wurde: eine Untergrenze;
  • für die älteste Datei ist die Änderungszeit von fseventsd-uuid (Beginn dieser Historie) die einzige Untergrenze, und sie kann Monate zurückliegen.

Beispiel aus dem Beispieldatensatz, der mit dem FSEvents Parser ausgeliefert wird:

Logdateimtime (UTC)Fenster ihrer Datensätze
…12a4439d09:58:4009:31:07 → 09:58:40
…12a444cf10:09:5509:58:40 → 10:09:55
…12a4475910:23:1810:09:55 → 10:23:18

Ein LaunchAgent, der in der dritten Datei erstellt wurde, wurde zwischen 10:09:55 und 10:23:18 UTC geschrieben. Das ist die korrekte Aussage, nicht „10:23:18“.

Das Fenster eingrenzen

  • Reihenfolge der Ereignisse. Innerhalb eines Fensters sind die Datensätze geordnet. Kommt der Datensatz des LaunchAgents nach einer Änderung der Terminal-Einstellungen und vor einem Schreibvorgang an der TCC.db, und lässt sich einer davon anderweitig datieren, schrumpft das Fenster.
  • Datierte Pfade. Rotierte Logs, Diagnoseberichte und Snapshots tragen oft ein Datum im Namen (…-2026-09-14-091214.ips). Wird ein solcher Pfad mit Created angelegt, verankert er die benachbarten Event-IDs. FSEventsParser nutzt eine Reihe bekannter Pfade für seine Spalte mit ungefähren Daten; der FSEvents Parser listet für jede Logdatei die Daten, die er in erstellten Pfaden findet, als Hinweise auf.
  • Andere Artefakte. APFS-Erstellungs- und Änderungszeiten des Objekts, falls es noch existiert, Quarantäne-Ereignisse für Downloads, Unified Logs für das Laden durch launchd, Zeilen der TCC.db mit eigenen Zeitstempeln.

Wann die Methode versagt

  • Ohne Zeiten kopiert. Ziehen im Finder auf manche Ziele, AirDrop, E-Mail oder ein unbedachter Upload versehen jede Datei mit der Kopierzeit. Symptom: Alle Logdateien haben nahezu dieselbe mtime. Der Parser weist darauf hin, die Fenster sind dann zu ignorieren; die Reihenfolge bleibt gültig.
  • mtimes außer der Reihe. Eine Datei, deren mtime vor der ihres Vorgängers liegt (Uhrumstellungen, mit touch bearbeitete Dateien, Tools, die Dateien neu schreiben). Diese Datei erhält keine Untergrenze.
  • Lokale Zeiten in ZIPs. ZIP speichert Zeiten ohne Zeitzone, sofern das erweiterte Zeitstempelfeld fehlt; eine in einer Zeitzone gezippte und in einer anderen gelesene Sicherung verschiebt jedes Fenster um den Versatz. Bevorzugen Sie tar.gz.
  • Lange Ruhephasen. Auf einem Rechner, der tagelang schläft, kann ein Fenster Tage umfassen; die Obergrenze bleibt dennoch belastbar.
  • Das aktuelle Log. Die neueste Datei ist bei der Sicherung möglicherweise noch geöffnet; ihre mtime ist der Sicherungszeitpunkt oder der letzte Schreibvorgang.

Nach Zeit filtern

Zwei Fragen erfordern zwei verschiedene Filter, die der Zeitraum des Parsers als Zeitfeld anbietet:

  • Ungefähres Fenster (Überlappung): Ein Datensatz bleibt erhalten, wenn sein Fenster den Zeitraum überlappt. Nichts, was möglicherweise im Zeitraum liegt, geht verloren; einige Datensätze außerhalb können enthalten sein.
  • Logdatei geschrieben (Obergrenze): Ein Datensatz bleibt erhalten, wenn die mtime seiner Datei im Zeitraum liegt. Enger, aber ein Datensatz, der kurz vor einem Schreibvorgang außerhalb des Zeitraums geschrieben wurde, fehlt.

Verwenden Sie das erste für Vollständigkeit, das zweite zur Fokussierung. In beiden Fällen gilt der Zeitraum für jede Ansicht, jede Zählung, jeden Befund und jeden Export und wird in der URL gespeichert (#from=…&to=…), sodass ein geteilter Link dasselbe Fenster wieder öffnet.

FAQ

Wie genau ist ein FSEvents-Zeitfenster?

So genau wie der Abstand zwischen zwei Schreibvorgängen von Logdateien: auf einem aktiven Mac typischerweise Minuten bis Stunden, auf einem ungenutzten deutlich mehr. Es ist immer eine Zeitspanne, nie ein Zeitpunkt.

Was, wenn alle FSEvents-Logdateien dieselbe Änderungszeit haben?

Dann wurden sie mit ziemlicher Sicherheit kopiert, ohne die Zeiten zu erhalten. Die Reihenfolge der Datensätze bleibt gültig, die Zeitfenster sind jedoch bedeutungslos; sichern Sie erneut mit tar, ditto oder UAC, wie im Sicherungsleitfaden beschrieben.

Verwandte Artikel