Quelle est la structure d'un fichier $I ?

Un en-tête little-endian de 8 octets : version à 0x00, taille originale à 0x08, FILETIME de suppression à 0x10, puis le chemin d'origine en UTF-16LE à partir de 0x18.

Quelle différence entre $I v1 et v2 ?

v1 (Vista–8.1) fait 544 octets fixes avec un chemin UTF-16LE de 260 caractères. v2 (Windows 10/11) est variable : un uint32 longueur de chemin à 0x18, puis ce nombre d'unités UTF-16LE.

Quel format d'heure utilise le fichier $I ?

Un FILETIME Windows : nombre d'intervalles de 100 nanosecondes depuis le 1601-01-01 UTC. Cet outil le convertit dans la date de votre langue locale ; l'export CSV conserve un ISO-8601 UTC strict.

Comment savoir quelle version $I je possède ?

Lisez les 8 premiers octets comme un entier little-endian : la valeur 1 signifie v1, la valeur 2 signifie v2. L'analyseur de ce site la détecte automatiquement.

Le format de fichier $I expliqué (disposition v1 et v2 en octets)

Le $I est une structure minuscule à disposition fixe. Vous pouvez l'analyser dans un éditeur hexadécimal en moins d'une minute. Deux versions existent : v1 de Vista à Windows 8.1, et v2 depuis Windows 10. Toutes deux partagent le même en-tête d'ouverture.

L'en-tête (les deux versions)

Décalage	Taille	Champ
`0x00`	8	Version du format (little-endian, `1` ou `2`)
`0x08`	8	Taille originale du fichier en octets (uint64 little-endian)
`0x10`	8	Heure de suppression (FILETIME Windows, little-endian)
`0x18`	…	Chemin d'origine (UTF-16LE), encodage différent selon la version

Deux conséquences de cette disposition à garder en tête :

Le champ version fait huit octets, pas un. Un $I parasite issu du carving échouera fréquemment la vérification de cohérence (autre chose que 1 ou 2 dans l'octet bas, tout non-zéro dans les sept octets hauts).
Le champ taille inclut la taille du fichier d'origine, pas la taille du $I lui-même. Le comparer à la taille $R appariée est un contrôle rapide d'altération.

v1 : Vista, 7, 8, 8.1

Taille totale fixe de 544 octets. Le chemin au décalage 0x18 occupe exactement 520 octets (260 caractères UTF-16LE, remplis de NUL). 260 correspond au classique MAX_PATH.

Un $I v1 dont la taille totale n'est pas 544 est presque certainement tronqué. Les outils qui le complètent puis "réussissent" l'analyse vous donnent de la fiction.

v2 : Windows 10 et 11

Longueur variable. Après l'en-tête :

Décalage	Taille	Champ
`0x18`	4	Longueur du chemin en unités UTF-16LE, terminateur NUL inclus
`0x1C`	N * 2	Chemin UTF-16LE

Ce uint32 de longueur permet à v2 de porter de longs chemins (fichiers sauvegardés OneDrive qui dépassent MAX_PATH). Il signifie aussi que vous devez valider la longueur contre la taille du fichier sur disque avant de lire le tampon de chemin, sinon un $I corrompu ou conçu malicieusement peut conduire un analyseur négligent au-delà de la fin du tampon.

Le FILETIME de suppression

64 bits little-endian, intervalles de 100 nanosecondes depuis 1601-01-01 00:00:00 UTC. L'article conversion FILETIME couvre le calcul. C'est de l'UTC. Sans fuseau horaire. Présentez-le toujours en UTC ou étiquetez le décalage explicitement.

Recoupement avec d'autres artefacts

Les heures M/A/C de $STANDARD_INFORMATION dans l'entrée MFT du partenaire $R survivant précèdent souvent l'horodatage de suppression du $I de quelques millisecondes, c'est le déplacement de l'emplacement d'origine vers $Recycle.Bin.
Le journal USN enregistre la même paire d'événements : RENAME_OLD_NAME + RENAME_NEW_NAME avec le nouveau chemin sous $Recycle.Bin\<SID>.