Formats d'horodatage des navigateurs expliqués
2026-05-19 · 2 min
L'erreur de forensique de navigateurs la plus fréquente est un décalage
d'époque. Affichez un last_visit_time Chromium avec l'époque Unix et
chaque visite atterrit dans les années 1600. Trois formats couvrent
quasiment tout ce que vous rencontrerez sur le terrain.
Chromium (Chrome, Edge, Brave, Opera)
Microsecondes depuis le 1601-01-01 00:00:00 UTC, l'époque WebKit/FILETIME.
Utilisée par urls.last_visit_time, visits.visit_time,
cookies.creation_utc, downloads.start_time et la plupart des autres
colonnes d'horodatage dans History, Cookies et Login Data.
unix_ms = chromium_value / 1000 - 11644473600000
Le piège : autofill.date_created et autofill.date_last_used sont en
secondes Unix simples. Même base de données, convention de colonne
différente. Vérifiez la cohérence sur un événement connu avant toute
conversion en masse.
Firefox (PRTime)
Microsecondes depuis le 1970-01-01 00:00:00 UTC. Utilisée dans
moz_places.last_visit_date, moz_historyvisits.visit_date et
moz_bookmarks.dateAdded.
unix_ms = firefox_value / 1000
Exception : moz_cookies.expiry est en secondes Unix, et
moz_cookies.creationTime / lastAccessed en microsecondes PRTime.
Conventions mélangées dans une seule table.
Safari (Mac absolute time)
Secondes (souvent fractionnaires) depuis le 2001-01-01 00:00:00 UTC, aussi
appelées Cocoa ou CFAbsoluteTime. Utilisé dans History.db et les
fichiers associés .plist.
unix_ms = (safari_value + 978307200) * 1000
Discipline des fuseaux horaires
Aucun de ces formats ne porte de fuseau horaire ; ils sont tous en UTC. Si vous les affichez dans l'heure locale de l'analyste, deux personnes dans des fuseaux différents se contrediront sur l'heure d'un événement. Gardez les chronologies en UTC, étiquetez explicitement lorsque vous affichez en local, et confirmez en alignant un événement connu (une connexion VPN, un enregistrement SSO d'entreprise issu d'EVTX) avant de faire confiance au reste.