TL;DR. Collectez le $LogFile et le $MFT du même volume. Déposez-les dans le parseur de $LogFile dans le navigateur. Lisez d'abord la ligne d'en-tête (version, démontage propre ou non, plage de LSN, avertissements). Triez ensuite la vue des événements avec Signalés uniquement, ouvrez le panneau de détail de chaque constat pour voir d'où viennent son heure et son chemin, passez aux enregistrements bruts pour vérifier les octets redo/undo, et exportez en CSV/JSON. Les signalements sont des heuristiques ; les enregistrements bruts sont la preuve. Confirmez avec un second outil tout ce qui va dans un rapport.

Ce pas à pas utilise l'exemple intégré au parseur : un journal LFS 2.0 et un $MFT synthétiques, issus d'une intrusion fictive sur un poste nommé FIN-WKS-07. Cliquez sur Essayer un exemple sur la page de l'outil pour suivre. Noms, heures et contenus de l'exemple sont inventés.

Étape 1 — Collecter les deux fichiers ensemble

Le parseur sait lire un $LogFile seul, mais les chemins seront partiels. Les enregistrements désignent les fichiers par leur entrée MFT ; le nom n'apparaît dans le journal que lors d'une création, d'un renommage ou d'une suppression. Le $MFT complète le reste.

Sans le $MFT, le tools.zip de l'exemple se résout en [MFT #61]\svc_backup\Downloads\tools.zip (le dossier Users n'est nommé nulle part dans ce qui reste du journal). Avec lui, le chemin devient \Users\svc_backup\Downloads\tools.zip.

Les commandes de collecte pour KAPE, Velociraptor, FTK Imager, RawCopy et icat sont dans Acquérir le $LogFile NTFS.

Étape 2 — Charger les fichiers

Déposez les fichiers, choisissez un dossier, ou déposez une collecte de tri au format ZIP (les arborescences KAPE et Velociraptor fonctionnent telles quelles). Chaque $LogFile est associé au $MFT du même dossier : gardez un dossier par volume.

La suite se passe dans l'onglet du navigateur : le parseur est écrit en Rust, compilé en WebAssembly et exécuté dans un Web Worker. Le $MFT est lu par blocs de 16 Mio dans un index de noms, si bien que des MFT de plusieurs gigaoctets passent sans être chargés entièrement en mémoire. Il n'existe aucun point d'envoi vers un serveur.

Les fichiers inutilisables sont listés avec une raison au lieu d'être écartés en silence : une copie qui commence par des zéros (sans doute verrouillée pendant la copie), un $UsnJrnl:$J (non traité par cet outil — utilisez le parseur de journal USN), ou un $MFT sans $LogFile à côté.

Étape 3 — Lire la ligne d'en-tête avant les événements

Pour l'exemple, la ligne d'en-tête indique en substance :

Champ	Valeur de l'exemple	Ce qu'elle vous apprend
Version du journal	LFS 2.0	Windows 8 ou ultérieur, volume monté lors de la capture (1.1 et 2.0)
Taille	256 Kio	Inhabituellement petit ; un vrai volume système tourne plutôt autour de 64 Mio
Pages d'enregistrements	5	Nombre de pages circulaires contenant des enregistrements
Plage de LSN	115720 → 117880	Enregistrements le plus ancien et le plus récent trouvés (les LSN expliqués)
Démontage	non démonté proprement	Capture à chaud ou plantage
Pages de fin / rapides	1 page lue dans la zone des pages rapides	La page la plus récente n'existait que là — typique d'une capture à chaud

Lisez aussi l'encadré Avertissements du parseur. Une copie tronquée, des pages qui échouent au contrôle du tableau de séquence de mise à jour ou une page de redémarrage CHKD changent le degré de confiance à accorder au résultat.

Étape 4 — Trier la vue des événements

Les tuiles de synthèse donnent les totaux par type. Sur l'exemple : 14 créations, 2 suppressions, 2 renommages/déplacements, 6 modifications de $STANDARD_INFORMATION, 2 écritures de données résidentes et 1 indice de timestomping.

Puis resserrez :

Type d'événement : Créé, Supprimé, Renommé / déplacé, Horodatages modifiés ($SI), Données résidentes écrites.
Signalés uniquement : ne garde que les événements portant au moins un signalement.
Recherche : chemin, nom, contenu, LSN ou date.

Les cinq signalements et ce qui les déclenche :

Signalement	Déclencheur
Suppression	L'événement est une suppression
Renommage / déplacement	L'événement est un renommage ou un déplacement
Horodatage modifié (timestomping possible)	Date de création réécrite, valeur qui recule, valeur à la seconde pile, ou création `$SI` antérieure à la création `$FN`
Dossier modifiable par l'utilisateur	Chemin sous AppData/Downloads/Desktop/Documents d'un profil, `Users\Public`, `ProgramData`, `Windows\Temp`, `$Recycle.Bin` ou `PerfLogs`
Exécutable	Nom se terminant par `.exe`, `.dll`, `.ps1`, `.bat`, `.js`, `.hta` et similaires

Sur l'exemple, Signalés uniquement plus un tri par LSN fait ressortir l'histoire en une douzaine de lignes : m64.exe créé dans Downloads\tools, déplacé vers \ProgramData\Intel, ses horodatages réécrits ; rc.tmp déposé dans \Users\Public puis renommé rclone.exe ; creds.txt créé sur le Bureau puis supprimé.

Étape 5 — Ouvrir le panneau de détail

Un clic sur un événement ouvre son détail. Trois champs méritent l'attention à chaque fois :

Heure tirée de. NTFS ne journalise aucune heure d'horloge. Le parseur date chaque événement à partir des données des enregistrements — création $FILE_NAME (créations), modification $FILE_NAME (renommages), nouvelle valeur $SI (modifications d'horodatage), ou dernière date connue avant une suppression. Les événements qui n'ont rien de tout cela empruntent l'heure de l'événement daté le plus proche et sont marqués ≈. La modification d'horodatage de m64.exe dans l'exemple en fait partie : ses nouvelles valeurs pointent vers 2019, donc le parseur refuse de s'en servir comme heure du changement.
Chemin tiré de. Noms vus dans le journal, le $MFT, partiel (un dossier parent inconnu) ou inconnu.
Pourquoi c'est signalé. Pour m64.exe : la date de création a été réécrite, un horodatage a reculé, une valeur à la seconde pile, et la création $SI est antérieure à la création $FN. Le panneau montre $SI avant (2026-09-14 10:06:52.3551871) et après (2019-03-19 07:14:22.0000000).

Pour juger ces raisons, voir Détecter le timestomping avec le $LogFile.

Étape 6 — Vérifier contre les enregistrements bruts

Chaque événement renvoie vers ses enregistrements (Afficher ces enregistrements). La vue des enregistrements liste chacun avec son LSN, son ID de transaction, ses opérations redo et undo, l'attribut ciblé et l'entrée MFT ou le fichier visé. Son panneau de détail ajoute LSN précédent, LSN undo suivant, type d'enregistrement, VCN cible, offsets enregistrement / attribut / bloc de cluster, offset dans le fichier, indication d'enregistrement multipage, et les dumps hexadécimaux des octets redo et undo.

Pour la modification d'horodatage de m64.exe, vous devez voir une paire UpdateResidentValue / UpdateResidentValue sur $STANDARD_INFORMATION, avec les nouvelles valeurs dans les octets redo et les anciennes dans les octets undo. Pour un renommage, un DeleteIndexEntry* suivi d'un AddIndexEntry* pour la même entrée. La signification de chaque opcode est détaillée dans Les opérations redo/undo expliquées.

C'est cette étape qui rend un constat défendable. Un événement est l'interprétation du parseur ; un enregistrement, avec ses octets et ses offsets, est ce que vous pouvez montrer à quelqu'un d'autre et ce qu'un second outil doit reproduire.

Étape 7 — Exporter et corréler

Les deux vues s'exportent en CSV (protégé contre l'injection de formules) ou en JSON. Les heures s'affichent en UTC ou en heure locale, à 100 ns près. Exportez ce que vous avez filtré plutôt que tout le journal, et gardez les LSN : ce sont les clés stables pour citer un enregistrement.

Puis corrélez :

$UsnJrnl:$J fournit des enregistrements datés RENAME_*, FILE_CREATE, FILE_DELETE et BASIC_INFO_CHANGE (parseur de journal USN).
Le Prefetch montre si m64.exe ou rclone.exe a été exécuté (parseur Prefetch) ; l'exemple journalise d'ailleurs la création de M64.EXE-1C9E54B7.pf.
Les fichiers LNK et les Jump Lists montrent ce qui a été ouvert (parseur LNK) ; le Payroll_2026.xlsx.lnk de l'exemple, dans Recent, est une piste en ce sens.

Étape 8 — Confirmer avec un second outil

Le parseur a été validé sur des journaux synthétiques écrits à partir du format publié (Linux ntfs3, libfsntfs, description de dfir.ru), pas encore sur un corpus de journaux Windows réels. Le regroupement des événements utilise une fenêtre d'enregistrements par entrée MFT, pas les transactions. Pour tout ce qui finit dans un rapport, repassez le journal dans LogFileParser ou NTFS Log Tracker et comparez les enregistrements par LSN. Voir Comparatif des parseurs de $LogFile.

Erreurs fréquentes

Parser un $LogFile avec un $MFT pris un autre jour : les entrées MFT sont réutilisées, les noms deviennent faux.
Prendre les heures « ≈ » pour des faits. Ce sont les heures des voisins.
Considérer un signalement de timestomping comme une preuve. Une valeur à la seconde pile peut venir d'un extracteur d'archives ; une valeur qui recule, d'une restauration légitime.
S'arrêter à la vue des événements. Certains changements ne sont pas reconstruits en événements ; la vue des enregistrements bruts montre tout ce que le journal contient encore.

Analyser un $LogFile NTFS pas à pas