Convertir un horodatage FILETIME de suppression Windows en date lisible
3 min de lecture
Au décalage 0x10, chaque fichier $I contient l'heure de suppression
sous la forme d'un FILETIME Windows 64 bits little-endian : le compte
des intervalles de 100 nanosecondes depuis 1601-01-01 00:00:00 UTC.
C'est l'époque 1601 qui piège la plupart des gens. Le même format
sert pour $STANDARD_INFORMATION dans le
MFT, la plupart des horodatages du
registre, et plusieurs colonnes dans
SRUM et EVTX.
La conversion
Étant donné la valeur 64 bits T :
- Secondes depuis 1601 :
T / 10_000_000 - Décalage vers l'époque Unix : soustraire
11_644_473_600(les secondes entre 1601-01-01 et 1970-01-01) - Le résultat est un horodatage Unix en UTC. Passez-le à n'importe quelle bibliothèque de dates.
secondes_unix = (filetime / 10_000_000) - 11_644_473_600
Pour la précision sous la seconde, conservez le reste de l'étape 1 comme fraction de seconde.
Aide-mémoire
| Concept | Valeur |
|---|---|
| Époque | 1601-01-01 00:00:00 UTC |
| Unité | Intervalles de 100 nanosecondes (1e-7 s) |
| Décalage 1601→1970 | 11 644 473 600 secondes |
| Ordre des octets | Little-endian, 8 octets |
| Plage | Année 1601 jusqu'à environ l'an 30 828 |
Erreurs de conversion courantes
- Traiter la valeur comme des secondes Unix. Un véritable FILETIME
est de l'ordre de
1,3 * 10^17. Affichez-le comme Unix et vous atterrissez en l'an 4 000 000 000. - Inversion d'endianness. Toujours little-endian sur disque. Certains visualiseurs hexadécimaux affichent par défaut en big-endian ; vérifiez en calculant la valeur vous-même.
- Lire les mauvais huit octets. Le décalage est
0x10, pas0x08(qui est la taille du fichier original). Facile à confondre quand on scrute du hex. - Affichage en heure locale sans étiquette. Deux analystes dans des fuseaux différents produiront deux rapports qui ne s'accordent pas. Affichez par défaut en UTC et étiquetez toute conversion locale.
Pourquoi la rigueur sur les fuseaux compte
Le FILETIME ne porte aucun fuseau horaire. Il est toujours en UTC. Deux cas réels où la rigueur a compté :
- Une affaire d'exfiltration où le portable du suspect avait journalisé
une suppression à
09:31 UTC. L'analyste avait affiché l'heure locale, mais le portable était en vol dans un fuseau différent. Sans étiquette UTC explicite, la chronologie ne s'alignait pas avec les journaux du VPN d'entreprise. - Un cas de ransomware où les horodatages de suppression successifs correspondaient aux relèves d'équipes en EMEA, mais seulement en affichage UTC. L'affichage en heure locale étalait la rafale sur deux jours ouvrés et masquait le motif.
Exportez toujours en ISO-8601 UTC. Affichez par défaut en UTC. Étiquetez toute vue en heure locale.
Pour aller plus loin
Questions fréquentes
- Qu'est-ce qu'un FILETIME Windows ?
- Un entier 64 bits little-endian qui compte le nombre d'intervalles de 100 nanosecondes depuis le 1601-01-01 00:00:00 UTC. Le fichier $I de la Corbeille stocke l'heure de suppression dans ce format au décalage 0x10.
- Comment convertir un FILETIME en date normale ?
- Divisez la valeur par 10 000 000 pour obtenir des secondes, soustrayez 11 644 473 600 (secondes entre 1601 et 1970), puis traitez le résultat comme un horodatage Unix en UTC.
- Pourquoi l'horodatage est-il en UTC ?
- Windows enregistre le FILETIME en UTC, sans stocker de fuseau horaire. Présentez-le toujours en UTC (ou indiquez explicitement le fuseau) pour qu'un événement de suppression soit sans ambiguïté sur une chronologie.
- Cet outil convertit-il l'horodatage automatiquement ?
- Oui. L'analyseur lit le FILETIME du fichier $I et l'affiche dans votre langue locale, tandis que l'export CSV conserve une valeur ISO-8601 UTC stricte pour que les chronologies restent cohérentes entre fuseaux.