PE-Zeitstempel: Kompilier-, Debug- und Signaturzeit
Wo eine Windows-Executable ihre Zeiten speichert, welchen man trauen kann, wie sich Reproducible Builds und Timestomping zeigen – und wie man sie nutzt.
Kurz gesagt. Eine PE-Datei trägt mehrere Zeiten: den COFF-TimeDateStamp (die klassische „Kompilierzeit“), Kopien davon im Debug- und im Export-Verzeichnis und, falls signiert, eine Signaturzeit. Keine davon ist für sich allein maßgeblich. Reproducible Builds ersetzen den Wert durch einen Hash; Angreifer setzen ihn auf null, würfeln ihn zufällig oder kopieren ihn. Das nützliche Signal ist die Konsistenz der Zeiten untereinander.
Wo die Zeiten stehen
| Zeit | Ort | Geschrieben von | Hinweise |
|---|---|---|---|
| Kompilierzeit | COFF-Header TimeDateStamp | Linker | Unix-Sekunden, UTC |
| Debug-Zeit | jeder Eintrag IMAGE_DEBUG_DIRECTORY | Linker | normalerweise gleich der Kompilierzeit |
| Export-Zeit | Export-Verzeichnis TimeDateStamp | Linker | DLLs; oft gleich, manchmal 0 |
| Ressourcen-Zeit | Header des Ressourcenverzeichnisses | Ressourcen-Compiler | meist 0 |
| Signaturzeit | signiertes Authenticode-Attribut oder Zeitstempel-Token | Signierer oder Zeitstempelstelle | nur die Zeit aus Gegensignatur / RFC 3161 ist bestätigt |
Der PE Parser zeigt alle im Überblick einer Datei an und ermöglicht es, eine ganze Sammlung nach Kompilier-, Debug- oder Signaturzeit zu filtern.
Reproducible Builds: wenn der Zeitstempel ein Hash ist
Seit Windows 10 baut Microsoft große Teile des Betriebssystems so, dass derselbe Quellcode dieselben Bytes ergibt. Das Zeitstempelfeld enthält dann einen Hash des Inhalts – deshalb zeigen Systemdateien Daten, die Jahrzehnte entfernt liegen. Raymond Chen erklärt das in Why are the module timestamps in Windows 10 so nonsensical?. Solche Binaries haben einen Debug-Verzeichniseintrag vom Typ 16, IMAGE_DEBUG_TYPE_REPRO. Das .NET SDK macht es bei seinen Assemblies standardmäßig genauso.
Der PE Parser erkennt den REPRO-Eintrag, kennzeichnet den Wert als Hash und lässt die Datei bei der Filterung nach Kompilierzeit außen vor, statt sie ins Jahr 2089 einzuordnen.
Werte, die etwas erzählen
- 0: manche Toolchains und viele manipulierte Dateien. Sehen Sie sich die anderen Zeiten an.
- 1992-06-19 22:22:17 UTC (
0x2A425E19): der feste Wert älterer Borland-Delphi-Linker – er identifiziert die Toolchain, kein Datum. - In der Zukunft (ohne REPRO): von Hand bearbeitet, gefälscht oder ein Build-Rechner mit falsch gehender Uhr.
- Vor 1995: für eine PE-Datei unplausibel; gefälscht oder zufällig.
- Kompilierzeit ≠ Debug-Zeit um mehr als einen Tag: Eine davon wurde bearbeitet – ein klassisches Zeichen für Timestomping, weil Tools, die den Header patchen, das Debug-Verzeichnis oft vergessen.
- Vor dem Kompilieren signiert: unmöglich; eine der beiden Angaben ist falsch.
Zeiten in einem Fall nutzen
- Gruppieren, nicht beweisen. Builds eines Tools, die im Abstand von Tagen kompiliert wurden und sich einen Imphash teilen, verraten etwas über den Entwicklungszyklus des Angreifers. Die Beispielsammlung im PE Parser enthält zwei Builds von
m64.exe, kompiliert am 2026-09-03 und am 2026-09-12. - Mit dem Host abgleichen. Ein Binary, das erst kompiliert wurde, nachdem es auf der Platte aufgetaucht ist (erste Sichtung laut Dateisystem, Prefetch oder Amcache), hat einen gefälschten Header.
- Der Zeitstempelstelle am meisten vertrauen. Ein RFC-3161-Token oder eine Gegensignatur wird beim Signieren von einer dritten Partei ausgestellt; das
signingTime-Attribut des Signierers selbst nicht (Authenticode offline). - Die Zeitzone festhalten. Alle PE-Zeiten sind UTC. Geben Sie sie in Berichten in UTC an und nennen Sie bei jeder Umrechnung in Ortszeit die Zeitzone.
Die Zeitraum-Leiste des PE Parser arbeitet für einen Stapel Dateien mit genau diesen Feldern: Feld wählen, Von/Bis sekundengenau setzen oder von einer beliebigen Datei aus „um diese Zeit“ mit ±5 min / ±1 h / ±24 h verwenden – jede Zählung, jede Liste und jeder Export folgt dem Zeitraum. Der Leitfaden zum PE-Format ordnet die Zeiten in den Kontext der übrigen Header ein.
FAQ
Wo steht die Kompilierzeit einer Windows-Executable?
Im Feld TimeDateStamp des COFF-File-Headers, als Sekunden seit dem 1970-01-01 UTC. Der Linker schreibt denselben Wert meist auch in die Einträge des Debug-Verzeichnisses und in das Export-Verzeichnis.
Warum haben manche Windows-Dateien Kompilierdaten in der Zukunft oder weit in der Vergangenheit?
Neuere Microsoft- und .NET-Toolchains bauen reproduzierbar und speichern im Zeitstempelfeld einen Hash des Inhalts statt einer Zeit. Ein Eintrag vom Typ REPRO im Debug-Verzeichnis kennzeichnet solche Dateien.
Kann man dem Kompilierzeitstempel einer PE-Datei trauen?
Nicht für sich allein: Es ist ein einfaches Feld, das jeder bearbeiten kann. Vergleichen Sie ihn mit den Debug- und Export-Zeitstempeln, der Signaturzeit einer Zeitstempelstelle und den Dateisystemzeiten auf dem Rechner.