$LogFile, $UsnJrnl ou $MFT : quel artefact NTFS, et quand

Q: Quelle différence entre $LogFile et $UsnJrnl ?

$UsnJrnl:$J est un journal de modifications destiné aux applications : un enregistrement par changement, avec horodatage, codes de raison, référence de fichier et nom, couvrant souvent des jours ou des semaines. $LogFile est le journal de reprise de NTFS : des octets redo et undo bas niveau pour chaque modification de métadonnées, sans horodatage propre, couvrant des minutes à des heures.

TL;DR. Le $MFT dit ce qui existe maintenant. $UsnJrnl:$J dit quel type de changement a touché quel fichier et quand, sur des jours ou des semaines. Le $LogFile dit exactement quels octets ont changé — ancien et nouveau nom, ancien et nouvel horodatage — mais seulement pour les dernières minutes ou heures, et sans horloge propre. Commencez par le $MFT et le journal USN, puis passez au $LogFile pour les questions auxquelles ils ne répondent pas : « quelle était la valeur avant ? » et « que s'est-il passé dans la dernière heure que les deux autres ont perdu ? »

Les trois vivent dans le même volume, décrivent les mêmes fichiers par les mêmes références MFT et sont collectés ensemble en routine. Ils ne sont pas interchangeables. Choisir le mauvais en premier coûte des heures ; ignorer le troisième coûte des constats.

Les trois en un tableau

	`$MFT`	`$UsnJrnl:$J`	`$LogFile`
Entrée MFT	0	dans `$Extend\$UsnJrnl`, flux `$J`	2
Rôle	Index de tous les fichiers et dossiers	Journal de modifications pour les applications (sauvegarde, recherche, réplication)	Reprise des métadonnées après plantage
Unité	Enregistrement FILE (1 Kio ou 4 Kio)	Enregistrement USN	Enregistrement de journal (redo + undo)
Horodatage par entrée	Non (les dates du fichier lui-même)	Oui, l'heure du changement	Non
Noms	`$FILE_NAME` actuels	Nom au moment du changement	Quand le nom fait partie du changement (création, renommage, suppression)
Valeurs avant/après	Non	Non (codes de raison seulement)	Oui
Historique typique	État actuel + entrées supprimées non réutilisées	Jours à semaines	Minutes à heures
Désactivable	Non	Oui (`fsutil usn deletejournal`)	Non

La dernière ligne compte en cas d'intrusion. Le journal USN est une fonctionnalité optionnelle qu'un administrateur — ou un attaquant disposant des droits d'administration — peut supprimer. Le $LogFile fait partie du fonctionnement de NTFS ; on ne peut pas le désactiver sur un volume monté, seulement le redimensionner (chkdsk /L, d'après la référence chkdsk de Microsoft).

Ce que chacun voit lors d'un renommage

Prenons un événement : rc.tmp dans C:\Users\Public devient rclone.exe.

$MFT après coup : un enregistrement FILE nommé rclone.exe, parent Public. L'ancien nom a disparu, sauf si une entrée résiduelle survit dans le slack $I30.
$UsnJrnl:$J : deux enregistrements avec la même référence de fichier — RENAME_OLD_NAME avec rc.tmp, puis RENAME_NEW_NAME avec rclone.exe — chacun horodaté.
$LogFile : un DeleteIndexEntry qui retire rc.tmp de l'index du parent, un AddIndexEntry qui ajoute rclone.exe, et des modifications de l'attribut $FILE_NAME dans l'enregistrement FILE. Les entrées d'index embarquent des structures $FILE_NAME complètes, avec les quatre horodatages $FILE_NAME.

Pour un renommage, le journal USN est plus simple et daté. Le $LogFile ne l'emporte que si les enregistrements USN ont disparu ou si vous avez besoin des valeurs embarquées.

Ce que chacun voit lors d'une réécriture d'horodatage

Voici le cas où le $LogFile est irremplaçable. Un attaquant fixe la date de création de m64.exe au 2019-03-19.

$MFT : $STANDARD_INFORMATION créé = 2019-03-19. $FILE_NAME créé = aujourd'hui. Cet écart est un indice classique, mais seulement un indice : une copie, une extraction d'archive ou un installeur peuvent aussi produire des combinaisons étranges.
$UsnJrnl:$J : un enregistrement avec la raison BASIC_INFO_CHANGE à l'heure du changement. On sait que quelque chose a changé dans les informations de base (dates ou attributs), pas quoi.
$LogFile : un UpdateResidentValue sur $STANDARD_INFORMATION dont les octets undo contiennent l'ancienne date de création et les octets redo le 2019-03-19. C'est la réécriture elle-même.

Voilà pourquoi l'analyse du timestomping s'appuie sur le journal. La méthode, et ses faux positifs, sont dans Détecter le timestomping avec le $LogFile. L'article de Cho en 2013 (Computers & Security 34) fait le même constat : des valeurs de date passées retrouvées dans le $LogFile transforment un horodatage suspect en preuve.

Comment les relier

Les trois artefacts partagent des clés, ce que David Cowen a appelé la TriForce NTFS :

Clé	Dans `$MFT`	Dans `$UsnJrnl:$J`	Dans `$LogFile`
Entrée MFT + numéro de séquence	Numéro d'enregistrement, séquence de l'en-tête	Référence du fichier, référence du parent	Entrée cible (VCN + offsets), entrées d'index
LSN	En-tête FILE `0x08` : LSN de la dernière modification journalisée	—	Chaque enregistrement
USN	Dernier USN dans `$STANDARD_INFORMATION`	Chaque enregistrement	Les écritures du journal USN sont elles-mêmes journalisées

Cette dernière ligne est utile. Le readme de LogFileParser indique que, lorsque le journal USN est actif, les enregistrements USN écrits pendant la durée de vie du journal sont aussi présents dans le $LogFile, et il les décode dans un CSV séparé. En pratique, le journal USN remonte généralement plus loin, mais pour la fenêtre la plus récente le $LogFile peut combler un trou.

Lequel en premier ? Quatre scénarios

« Quels fichiers ce compte a-t-il créés ce matin ? » Le journal USN d'abord (daté, long historique), le $MFT pour les chemins. Le $LogFile seulement si la matinée y figure encore.

« Ce binaire a-t-il été antidaté ? » Le $MFT pour repérer l'écart $SI/$FN, puis le $LogFile pour trouver la réécriture et la valeur d'origine. Le journal USN donne l'heure du BASIC_INFO_CHANGE.

« L'attaquant a supprimé le journal USN. » Le $LogFile pour les dernières minutes ou heures ; le $MFT pour l'état actuel et les entrées supprimées non réutilisées ; les clichés instantanés (VSS) pour des copies plus anciennes des trois.

« Que disait ce fichier texte supprimé ? » Seul le $LogFile a une chance, et uniquement si le fichier était assez petit pour être résident et si les enregistrements concernés ont survécu. Voir Retrouver les traces de fichiers supprimés.

Les outils pour chacun

$MFT : n'importe quel parseur MFT (MFTECmd, analyzeMFT, suites commerciales).
$UsnJrnl:$J : le parseur de journal USN de la même famille, dans le navigateur, ou MFTECmd. usnparser.com propose aussi sa propre comparaison des trois artefacts, vue du côté USN.
$LogFile : le parseur de $LogFile dans le navigateur (déposez le $MFT à côté pour des chemins complets), LogFileParser, NTFS Log Tracker, TZWorks mala — comparés dans Comparatif des parseurs de $LogFile.

N'oubliez pas que les fichiers d'un même volume doivent être collectés ensemble. Un $LogFile du lundi et un $MFT du mardi résoudront certaines entrées MFT avec de mauvais noms dès que des entrées auront été réutilisées.

Questions fréquentes

Quelle différence entre $LogFile et $UsnJrnl ?

$UsnJrnl:$J est un journal de modifications destiné aux applications : un enregistrement par changement, avec horodatage, codes de raison, référence de fichier et nom, couvrant souvent des jours ou des semaines. $LogFile est le journal de reprise de NTFS : des octets redo et undo bas niveau pour chaque modification de métadonnées, sans horodatage propre, couvrant des minutes à des heures.

Si j'ai le journal USN, ai-je encore besoin du $LogFile ?

Oui dès que la question porte sur des valeurs plutôt que sur des événements. Le journal USN dit que les informations de base d'un fichier ont changé ; le $LogFile peut montrer l'ancien et le nouvel horodatage. Il aide aussi quand le journal USN a été supprimé ou désactivé, pour l'activité la plus récente.

Pour aller plus loin

Microsoft Learn, Change Journals.
David Cowen, NTFS TriForce — a deeper look inside the artifacts.
Maxim Suhanov, How the $LogFile works?