Horodatages des ShellBags : ce que signifie chaque date

TL;DR. Une entrée ShellBags fait intervenir trois types de dates. Le LastWrite de la clé (un FILETIME à 100 ns) indique quand cette clé BagMRU a changé pour la dernière fois, ce qui dépend de ses enfants. La « dernière interaction » est dérivée : l'enfant en première position du MRUListEx d'un parent était le plus récent au moment où la clé parente a été écrite, il hérite donc du LastWrite du parent. Les dates embarquées de création/modification/accès sont celles du dossier dans le système de fichiers, au format FAT à 2 secondes, capturées lors de l'enregistrement de l'item et jamais mises à jour ensuite. Seul le deuxième type s'approche de « quand l'utilisateur y était », et pour un seul enfant par dossier.

Si une constatation tirée des ShellBags doit être contestée, elle le sera sur les horodatages. L'artefact contient beaucoup de dates ; très peu signifient ce que le lecteur suppose.

Les trois types de dates

Les deux premières sont des dates de registre. La troisième est une métadonnée du système de fichiers qui s'est retrouvée copiée dans le registre.

Comment MRUListEx transforme une date de clé en date d'interaction

Chaque clé BagMRU contient une valeur binaire MRUListEx : une liste de numéros d'emplacement 32 bits, du plus récemment utilisé au plus ancien, terminée par 0xFFFFFFFF. Quand l'utilisateur entre dans l'un des enfants, l'Explorateur place l'emplacement de cet enfant en tête et réécrit MRUListEx. Réécrire une valeur met à jour le LastWrite de la clé.

Donc, au moment de la dernière écriture de la clé parente, l'enfant en position 0 était celui en cours d'utilisation. C'est le raisonnement derrière la colonne « last interacted » d'outils comme ShellBags Explorer et SBECmd, exposé par 4n6k avec des tests pas à pas. Il ne vaut que pour la position 0. Pour tous les autres enfants, le LastWrite du parent ne dit rien de leur dernière utilisation.

ShellBags Explorer affiche aussi une date « first interacted » pour certaines entrées. L'idée : une clé sans sous-clé n'a eu aucun enfant à réordonner, son LastWrite est donc proche de sa création. Considérez-la comme une approximation et lisez la documentation de l'outil avant de la citer.

Un exemple commenté

Le ShellBags Parser embarque un échantillon synthétique (données fictives) dans lequel le compte svc_backup parcourt un partage finance. Simplifiées, les clés concernées ressemblent à ceci :

BagMRU\1\0\0                    \\FILESRV01\Finance   LastWrite 2026-09-14 10:36:18 UTC
  values: 0 = Payroll, 1 = Board
  MRUListEx = 1, 0, FFFFFFFF
BagMRU\1\0\0\0                  Payroll               LastWrite 2026-09-14 10:32:40 UTC (no subkeys)
BagMRU\1\0\0\1                  Board                 LastWrite 2026-09-14 10:36:18 UTC (no subkeys)

Ce que l'on peut affirmer :

• Board est en position MRU 0 dans Finance : sa dernière interaction est le LastWrite de la clé Finance, 10:36:18 UTC.
• Payroll est en position 1. Le LastWrite de Finance ne le date pas. Le LastWrite de sa propre clé (10:32:40) est le moment où cette clé a changé pour la dernière fois ; comme elle n'a pas d'enfant, c'est une approximation raisonnable de son premier enregistrement, pas la preuve de la dernière visite.
• L'ordre est solide : Board a été utilisé plus récemment que Payroll.

Dans l'outil, la colonne « Dernière interaction » n'est remplie que pour les entrées en position MRU 0, et la vue « Chronologie » se rabat sur « Dernière écriture de la clé » pour les autres : vous voyez toujours sur quel type de date vous triez.

Ce que sont les dates embarquées

Un shell item de type « file entry » contient une date de modification à l'offset 8. Depuis Windows XP, son bloc d'extension 0xBEEF0004 ajoute les dates de création et de dernier accès, selon la spécification libfwsi. Ce sont les dates du répertoire lui-même, lues dans le système de fichiers au moment de la construction de l'item. Les tests de 4n6k ont montré qu'elles ne sont pas mises à jour après la création du shell item.

Utiles pour :

• Dater un dossier qui n'existe plus (voir dossiers supprimés).
• Rapprocher un dossier d'un support amovible du même dossier dans une image disque saisie.
• Montrer qu'un dossier a été créé peu avant d'être parcouru (un schéma de staging).

Inutiles pour : dire quand l'utilisateur l'a ouvert.

Formats et précision

• Date/heure FAT. Deux valeurs de 16 bits : la date (année depuis 1980, mois, jour) et l'heure (heure, minute, secondes/2). Microsoft documente cette structure dans DosDateTimeToFileTime. Les secondes sont toujours paires. Attendez-vous à un écart allant jusqu'à 1 seconde face à un FILETIME issu de la $MFT ou du journal USN.
• Fuseau horaire. libfwsi documente les dates FAT des shell items comme étant en UTC. Les LastWrite du registre sont des FILETIME UTC. Présentez tout en UTC dans les rapports et ne convertissez que pour l'affichage.
• Systèmes de fichiers FAT. Pour les dossiers situés sur des volumes FAT (beaucoup de clés USB), le système de fichiers stocke lui-même l'heure locale, et le dernier accès n'est qu'une date. La page Microsoft File Times précise que la date d'accès sur FAT a une résolution d'un jour. Ne lisez pas une heure dans un accès provenant d'une clé FAT32.

Les pièges que je vois dans les rapports

1. « Le dossier X a été ouvert pour la dernière fois à [LastWrite de la clé]. » Faux, sauf si X est en position MRU 0 dans son parent, et même alors la date appartient à la clé parente.
2. « L'utilisateur a accédé au dossier à [date d'accès embarquée]. » C'est la date d'accès du dossier dans le système de fichiers au moment de l'enregistrement de l'item.
3. Appliquer le LastWrite d'un parent à tous ses enfants. Un seul enfant en hérite.
4. Supposer que chaque écriture vient d'une navigation. Les changements d'affichage (ordre de tri, taille des icônes) et la maintenance de l'Explorateur écrivent aussi des clés. La date borne un événement ; elle ne le nomme pas.
5. Une précision à la minute sans corroboration. Les écritures de registre peuvent être décalées par rapport au clic. Recoupez avec les fichiers LNK, les Jump Lists, les journaux d'événements et le journal USN avant d'avancer une heure précise.
6. Ruche non rejouée. Sur une ruche sale, les LastWrite les plus récents peuvent se trouver dans les journaux de transactions.
7. Problèmes d'horloge. Une horloge système fausse, ou modifiée volontairement, décale toutes les dates de registre. Vérifiez les événements de changement d'heure.

Comment le rédiger

Formulation défendable : « L'entrée BagMRU de \\FILESRV01\Finance\Board était l'enfant le plus récemment utilisé de \\FILESRV01\Finance lors de la dernière écriture de cette clé, le 2026-09-14 à 10:36:18 UTC. Cela est cohérent avec une navigation du compte vers ce dossier à ce moment ou peu avant. » Citez ensuite l'artefact qui corrobore.

FAQ

Le LastWrite d'une clé ShellBags correspond-il à la dernière ouverture du dossier ?

Pas en général. Le LastWrite d'une clé BagMRU change quand ses propres valeurs changent, c'est-à-dire quand ses enfants sont ajoutés ou réordonnés. Seul l'enfant en première position du MRUListEx d'un parent peut être rattaché au LastWrite de ce parent.

Les dates de création/modification/accès d'un ShellBag sont-elles des dates d'accès de l'utilisateur ?

Non. Ce sont les dates du dossier dans le système de fichiers, copiées dans le shell item lors de son enregistrement, et elles ne sont pas rafraîchies lors des visites suivantes.

Pourquoi les heures des ShellBags tombent-elles sur des secondes paires ?

Les dates embarquées sont stockées au format date/heure FAT (DOS), dont la résolution est de 2 secondes pour l'heure.

Articles liés

• Le format des shell items expliqué
• ShellBags : le guide complet de l'analyse forensique
• Limites et anti-forensique des ShellBags