Zeitstempelformate: FILETIME, Unix, Apple und DOS

Ein Zeitstempel ist nur eine Zahl, solange Sie vier Dinge darüber nicht kennen: seine Epoche (den Zeitpunkt, ab dem er zählt), seine Einheit, seine Größe und Byte-Reihenfolge und die Angabe, ob er UTC oder Ortszeit erfasst. Wenn Sie eines davon falsch bestimmen, wird aus einem korrekten Wert ein falsches Ergebnis – manchmal um Jahrzehnte verschoben, manchmal nur um wenige Stunden, was schwerer zu erkennen ist. In früheren Modulen wurden einzelne Zeitstempel jeweils bei ihrem Auftreten dekodiert. Diese Lektion stellt die Formate als Referenz zusammen, zeigt, wie Sie ein Format anhand eines Rohwerts erkennen, und dekodiert einen Zeitpunkt in mehreren Formaten. Lektion 3.5 behandelt Zeitzonen- und Uhrfehler; hier geben wir nur an, ob das jeweilige Format UTC oder Ortszeit speichert.

Referenztabelle

Windows-Formate

FILETIME ist ein 64-Bit-Zähler für 100-Nanosekunden-Intervalle seit 1601-01-01T00:00:00Z. Die Struktur besteht aus zwei 32-Bit-Hälften (dwLowDateTime, dann dwHighDateTime), sodass die acht Bytes auf dem Datenträger in Little-Endian-Reihenfolge vorliegen und vor dem Lesen umgekehrt werden müssen. Teilen Sie zum Dekodieren durch 10.000.000, um die Sekunden seit 1601 zu erhalten, und subtrahieren Sie anschließend 11.644.473.600, die Anzahl der Sekunden von 1601 bis 1970, um die Unix-Zeit zu erhalten. Einige Artefakte speichern FILETIME als Text: Der Office-MRU-Wert [T01DCB128E569DA00] (Lektion 2.4) liegt bereits in Lesereihenfolge vor und darf nicht umgekehrt werden.

SYSTEMTIME ist eine 16-Byte-Struktur aus acht Little-Endian-WORDs: wYear, wMonth, wDayOfWeek (0 = Sonntag), wDay, wHour, wMinute, wSecond, wMilliseconds. Sie hat keine Epoche, daher lesen Sie die Felder direkt. Ob UTC oder Ortszeit vorliegt, hängt vom Programm ab, das sie geschrieben hat. Die Werte DateCreated und DateLastConnected der Netzwerkprofile unter SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles sind SYSTEMTIME in Ortszeit. Das Wochentagsfeld ermöglicht eine zusätzliche Konsistenzprüfung: Es muss zum Datum passen.

Das OLE-Automation-Datum (der COM-Typ DATE) ist eine 64-Bit-Gleitkommazahl, die Tage seit 1899-12-30T00:00:00 angibt. Der ganzzahlige Teil ist der Tag und der Bruchteil die Tageszeit; 0,5 steht somit für Mittag. ESE-Datenbanken speichern Datums-/Zeitspalten auf diese Weise. Der SRUM-Wert TimeStamp (Lektion 2.8) ist ein solcher Wert in UTC, andere Programme speichern jedoch Ortszeit. Zum Dekodieren: datetime(1899,12,30) + timedelta(days=v) in Python.

DOS-Datum/-Zeit packt ein Datum und eine Uhrzeit in zwei 16-Bit-Wörter:

Somit gilt: Datum = (Jahr − 1980) << 9 | Monat << 5 | Tag und Uhrzeit = Stunde << 11 | Minute << 5 | Sekunde ÷ 2. Das Jahresfeld deckt 1980 bis 2107 ab, und die Uhrzeit hat eine Auflösung von 2 Sekunden. In einem FAT-Verzeichniseintrag liegt die Schreibzeit am Offset 0x16 und das Schreibdatum bei 0x18, das Zeitwort steht also zuerst. Die Erstellungszeit bei 0x0E hat ein ergänzendes Byte bei 0x0D, das Einheiten von 10 Millisekunden hinzufügt; das Datum des letzten Zugriffs bei 0x12 enthält dagegen überhaupt keine Uhrzeit. FAT und die grundlegenden ZIP-Header speichern Ortszeit (zusätzliche ZIP-Felder können UTC-Unix-Zeiten ergänzen). exFAT verwendet denselben Aufbau in einem 32-Bit-Feld, ergänzt jedoch 10-ms-Schritte und ein Feld für den UTC-Offset. Windows-Shell-Elemente (Lektion 2.5) verwenden denselben Aufbau, speichern jedoch UTC. Der Aufbau allein verrät Ihnen niemals die Zeitzone.

Unix-basierte Formate

Unix-Zeit zählt Sekunden seit 1970-01-01T00:00:00Z und ignoriert Schaltsekunden. Ein vorzeichenbehafteter 32-Bit-Wert endet bei 2.147.483.647, was 2038-01-19T03:14:07Z entspricht. Sie begegnen ihr in Registry-Werten wie InstallDate und DHCP-Lease-Zeiten (Lektion 2.2), im PE-Header TimeDateStamp (obwohl viele moderne Binärdateien, darunter die meisten Windows-Binärdateien seit Windows 10, dort statt einer Zeit einen Hash für reproduzierbare Builds speichern) sowie in unzähligen Protokollen. Varianten ändern nur die Einheit: Millisekunden bei JavaScript Date.now() und in vielen Browser- und App-Speichern, Mikrosekunden bei Firefox PRTime (beispielsweise visit_date in places.sqlite) und Nanosekunden bei APFS.

ext4 speichert 32-Bit-Sekunden und erweitert sie durch die _extra-Felder: 2 Epochenbits plus 30 Bit für Nanosekunden (Lektion 1.6). APFS speichert vorzeichenlose 64-Bit-Nanosekunden seit 1970 UTC (Lektion 1.7).

Chrome/WebKit-Zeit zählt Mikrosekunden seit 1601-01-01 UTC, also ab der FILETIME-Epoche mit einer gröberen Einheit. Modul 4 behandelt die Browserdatenbanken, die dieses Format verwenden.

Apple-Formate

Mac Absolute Time, auch Cocoa- oder Core-Data-Zeit genannt, zählt Sekunden seit 2001-01-01T00:00:00Z. Unix-Zeit = Mac Absolute + 978.307.200. Üblicherweise handelt es sich um einen Double-Wert mit einem Nachkommaanteil. Binäre Property-Listen speichern Datumswerte auf diese Weise als Big-Endian-64-Bit-Doubles, während XML-plists sie als ISO-8601-Text wie <date>2026-03-14T09:21:07Z</date> darstellen. Einige neuere Apple-Datenbanken, etwa die Messages-Datenbank chat.db, speichern stattdessen Nanosekunden seit 2001.

HFS+ speichert vorzeichenlose 32-Bit-Sekunden in Big-Endian-Reihenfolge seit 1904-01-01; der Wertebereich endet bei 2040-02-06T06:28:15. Unix-Zeit = HFS+ − 2.082.844.800. HFS+-Katalogdaten sind in UTC angegeben, mit einer dokumentierten Ausnahme: Das Erstellungsdatum im Volume-Header ist Ortszeit. Klassisches HFS (Mac OS Standard) speicherte alle Datumswerte in Ortszeit.

Textformate: ISO 8601 und RFC 3339

ISO 8601 schreibt Datums- und Zeitangaben als Text, beispielsweise 2026-03-14T09:21:07Z oder 2026-03-14T06:21:07-03:00. RFC 3339 ist ein strengeres Profil davon für Internetprotokolle: ein vollständiges Datum mit Uhrzeit und einem obligatorischen Z oder numerischen Offset. Die XML-Ansicht der Ereignisanzeige stellt EVTX-FILETIMEs auf diese Weise dar, als SystemTime="2026-03-14T09:21:07.2500000Z". Eine Zeichenfolge ohne Z und ohne Offset gibt keine Zeitzone an; ISO 8601 behandelt sie als Ortszeit. Kennzeichnen Sie sie daher nicht als UTC, sofern nicht dokumentiert ist, dass das schreibende Programm UTC verwendet. Die CFX-Prüfung erwartet Antworten in ISO 8601 mit Z.

Rechenbeispiel: ein Zeitpunkt, fünf Kodierungen

Betrachten Sie 2026-03-14T09:21:07Z auf einem System, das auf UTC−3 eingestellt ist.

Unix-Sekunden. Von 1970-01-01 bis 2026-03-14 sind es 20.526 Tage. 20.526 × 86.400 = 1.773.446.400. Addieren Sie 9 h 21 min 7 s = 33.667 s: 1.773.480.067.

FILETIME. (1.773.480.067 + 11.644.473.600) × 10.000.000 = 13.417.953.667 × 10.000.000 = 134.179.536.670.000.000 = 0x01DCB393E3578380. In Little-Endian-Reihenfolge gespeichert: 80 83 57 E3 93 B3 DC 01.

Mac Absolute Time. 1.773.480.067 − 978.307.200 = 795.172.867 (als Double 795172867.0).

WebKit-Mikrosekunden. 13.417.953.667 s seit 1601 × 1.000.000 = 13.417.953.667.000.000.

DOS (Ortszeit). Die Ortszeit ist 09:21:07 − 3 h = 2026-03-14 06:21:07.

• Datum: (2026 − 1980) << 9 | 3 << 5 | 14 = 46 × 512 + 96 + 14 = 23.662 = 0x5C6E, Bytes 6E 5C.
• Uhrzeit: 6 << 11 | 21 << 5 | 7 ÷ 2 = 12.288 + 672 + 3 = 12.963 = 0x32A3, Bytes A3 32.
• In einem FAT-Eintrag bei 0x16 lauten die vier Bytes A3 32 6E 5C. Die Dekodierung ergibt 3 × 2 = 06 Sekunden: 2026-03-14 06:21:06 Ortszeit oder 09:21:06Z. Die ungerade Sekunde ging verloren: Die Formel schneidet sie ab, während einige schreibende Programme, darunter Windows beim Kopieren einer Datei auf FAT, stattdessen auf die nächste gerade Sekunde (08) aufrunden (Lektion 3.5).

Zum Vergleich lautet dieselbe Ortszeit als SYSTEMTIME EA 07 03 00 06 00 0E 00 06 00 15 00 07 00 00 00 (2026, März, Samstag = 6, 14., 06:21:07.000).

Welches Format ist das?

Die Größenordnung liefert den schnellsten Hinweis. Werte für 2026:

Die Größenordnung grenzt die Auswahl ein, beweist das Format aber nicht. Mac Absolute 795.172.867 ergibt als Unix-Sekunden gelesen 1995-03-14T09:21:07Z, ein vollkommen plausibel aussehendes Datum. Bestätigen Sie das Format immer anhand einer zweiten Quelle: der Dokumentation oder des Parsers des Feldes, eines zugehörigen Artefakts, das dasselbe Ereignis erfasst, oder einer Plausibilitätsprüfung anhand des Installationsdatums des Systems und des Sicherungszeitpunkts.

Übung. Identifizieren und dekodieren Sie jeden Wert: (a) Bytes 80 B6 F9 4D 6B E7 DC 01; (b) 1.779.180.097; (c) 800872897.0 in einer plist; (d) 13.423.653.697.000.000 in einer SQLite-Spalte; (e) FAT32-Bytes bei 0x16 32 2D B3 5C, System auf UTC−3 eingestellt.

Lösung. (a) FILETIME 0x01DCE76B4DF9B680 = 134.236.536.970.000.000; ÷ 10^7 − 11.644.473.600 = 1.779.180.097 = 2026-05-19T08:41:37Z. (b) Unix-Sekunden, derselbe Zeitpunkt. (c) Mac Absolute: + 978.307.200 = 1.779.180.097, erneut derselbe Zeitpunkt; als Unix gelesen ergäbe sich fälschlicherweise 1995-05-19. (d) WebKit: ÷ 10^6 = 13.423.653.697 s seit 1601, minus 11.644.473.600 = 1.779.180.097. (e) Uhrzeit 0x2D32: Stunde 5, Minute 41, 18 × 2 = 36 s; Datum 0x5CB3: 1980 + 46 = 2026, Monat 5, Tag 19. Die Ortszeit 2026-05-19 05:41:36 entspricht 08:41:36Z, wiederum mit einer Auflösung von zwei Sekunden. Fünf Quellen, die innerhalb von zwei Sekunden übereinstimmen, liefern genau die gegenseitige Bestätigung, auf der Lektion 3.4 aufbaut.

Präzision und Genauigkeit

Präzision ist die kleinste Schrittweite, die ein Format darstellen kann: 100 ns für FILETIME, 1 ns für APFS, 2 s für DOS-Schreibzeiten und knapp unter einer Mikrosekunde für ein OLE-Datum im Jahr 2026. Genauigkeit beschreibt, wie nahe der gespeicherte Wert am tatsächlichen Zeitpunkt liegt, und hängt von der Systemuhr sowie vom Programm ab, das ihn geschrieben hat. Viele FILETIMEs enden auf sieben Nullen, weil das schreibende Programm nur über ganze Sekunden verfügte. Geben Sie die Präzision an, die die Quelle tatsächlich besitzt, und schneiden Sie Nachkommastellen ab, statt zu runden, wenn eine Aufgabe Sekunden verlangt. Eine 100-ns-FILETIME ist nicht vertrauenswürdiger als eine DOS-Zeit mit 2-Sekunden-Auflösung, wenn die Uhr falsch ging.

Dekodierungswerkzeuge

Werkzeuge sind Hilfsmittel, keine Autoritäten. DCode dekodiert die meisten der oben genannten Formate über ein einziges Eingabefeld. CyberChef bietet Operationen wie „Windows Filetime zu UNIX-Zeitstempel“ und „Aus UNIX-Zeitstempel“. In Python dekodiert datetime(1601,1,1,tzinfo=timezone.utc) + timedelta(microseconds=ft//10) eine FILETIME, und datetime.fromtimestamp(u, timezone.utc) dekodiert Unix-Sekunden. Ohne timezone.utc konvertiert fromtimestamp stillschweigend in die lokale Zeitzone des Analyserechners. Überprüfen Sie jedes Werkzeug anhand eines Werts, den Sie von Hand berechnet haben.

Prüfungsschwerpunkt: Rechnen Sie mit Rohwerten, häufig als Little-Endian-Hex-Bytes, die Sie identifizieren und in ISO 8601 UTC mit Z umwandeln müssen. Kennen Sie die Konstanten 11.644.473.600 und 978.307.200, die DOS-Bitaufteilung und ihre Auflösung von 2 Sekunden sowie die Formate, die Ortszeit speichern (DOS, klassisches HFS) oder vom schreibenden Programm abhängen (SYSTEMTIME, OLE). Falsche Antwortoptionen sind häufig die richtige Zahl, die mit der falschen Epoche dekodiert wurde.

Kernpunkte

• Jeder Zeitstempel benötigt vier Angaben: Epoche, Einheit, Größe und Byte-Reihenfolge sowie UTC oder Ortszeit.
• FILETIME und WebKit zählen ab 1601 (100 ns und µs); Unix, APFS und ext4 zählen ab 1970; Mac Absolute zählt ab 2001; HFS+ ab 1904; OLE-Datumswerte ab 1899-12-30; DOS ab 1980.
• DOS-Datum/-Zeit verwendet Ortszeit, hat eine Auflösung von 2 Sekunden und deckt die Jahre 1980–2107 ab; SYSTEMTIME und OLE-Datumswerte verwenden je nach schreibendem Programm UTC oder Ortszeit.
• Größenordnung und Ziffernanzahl geben Hinweise auf das Format, eine zweite Quelle muss es jedoch bestätigen.
• Präzision beschreibt, was das Format darstellen kann; Genauigkeit hängt von der Uhr und dem schreibenden Programm ab.