Skip to content

Journal de transactions NTFS · DFIR

NTFS $LogFile Parser

Les créations, renommages, suppressions et modifications d'horodatage récents, reconstruits depuis le journal de transactions NTFS — chaque enregistrement brut à un clic. Analysé dans votre navigateur en WebAssembly — rien n'est envoyé.

  • $LogFile
  • $MFT
  • LSN
  • redo / undo
  • Rust → WASM

Déposez ici le $LogFile (et le $MFT du même volume)

Ajoutez le $MFT pour transformer les références MFT en chemins complets. Les dossiers et les collectes ZIP (KAPE, Velociraptor) sont acceptés tels quels — chaque $LogFile est associé au $MFT placé à côté.

Un $LogFile et un $MFT synthétiques issus d'une intrusion fictive — aucune donnée réelle.

100 % côté client : les fichiers sont analysés par WebAssembly dans votre navigateur et ne sont jamais envoyés.

Comment récupérer vos données

Guide d'acquisition complet

$LogFile est un métafichier NTFS verrouillé : l'Explorateur et copy ne peuvent pas le lire. Une seule commande le collecte avec le $MFT qui nomme ses fichiers.

  1. 1. Collectez $LogFile + $MFT
  2. 2. Déposez le dossier ou le ZIP ici
  3. 3. Tout reste dans votre navigateur

KAPE, deux ciblesRecommandé

Invite de commandes administrateur (cmd.exe ; PowerShell interpréterait $LogFile) · KAPE sur la machine ou une clé USB · E: = votre disque externe.

cmd · admin
kape.exe --tsource C: --target $LogFile,$MFT --tdest E:\triage

Produit E:\triage\C\$LogFile et E:\triage\C\$MFT. Déposez tout le dossier E:\triage ici. Pour un autre volume, relancez avec --tsource D:.

Pièges

  • Une copie classique échoue ou revient remplie de zéros, car le fichier est verrouillé. Utilisez un outil à accès brut ci-dessus ; l'outil signale les copies remplies de zéros.
  • Le journal est circulaire : sur un disque système actif, il peut être écrasé en moins d'une heure. Collectez-le en premier et écrivez sur un autre disque, pas sur C:.
  • Prenez le $MFT du même volume dans la même collecte, et ne lancez jamais chkdsk sur le volume à analyser (il peut réinitialiser le journal).

Qu'est-ce que le $LogFile NTFS ?

$LogFile est le journal de transactions de NTFS (entrée MFT 2). Avant de modifier ses propres métadonnées — un enregistrement FILE, un index de dossier, une bitmap —, NTFS écrit un enregistrement qui décrit le changement deux fois : une opération redo (comment l'appliquer) et une opération undo (comment l'annuler). Après un plantage, Windows rejoue ou annule ces enregistrements pour garder le volume cohérent.

Pour l'enquêteur, ces octets redo et undo sont précieux : ils contiennent les noms de fichiers, les dossiers parents, les références MFT et les horodatages de chaque modification de métadonnées, avant et après. Créations, suppressions, renommages et réécritures d'horodatage s'en déduisent, même quand le journal USN a été désactivé ou vidé.

Où il est stocké

  • \$LogFile à la racine de chaque volume NTFS (C:\$LogFile, D:\$LogFile…). C'est un fichier de métadonnées caché : l'Explorateur et la copie ne l'ouvrent pas — il faut un lecteur NTFS brut.
  • Taille par défaut : 64 Mio sur les Windows actuels (modifiable avec chkdsk /L). Il est circulaire : les nouveaux enregistrements écrasent les plus anciens, il couvre donc en général de quelques minutes à quelques heures d'activité sur un système chargé.
  • Structure : deux pages de redémarrage (RSTR), puis 2 pages de fin (format 1.1, Windows XP à 7, et Windows 8+ après un arrêt propre) ou 32 pages rapides (format 2.0, Windows 8+ volume monté), puis la zone circulaire des pages d'enregistrements (RCRD), chacune protégée par un tableau de séquence de mise à jour.

Pourquoi c'est utile en investigation

  • Créations de fichiers et de dossiers (InitializeFileRecordSegment + AddIndexEntry), suppressions (DeleteIndexEntry + DeallocateFileRecordSegment) et renommages ou déplacements, avec l'entrée MFT et le numéro de séquence.
  • Timestomping : un UpdateResidentValue sur $STANDARD_INFORMATION contient l'ancien et le nouvel horodatage — une date de création réécrite en 2019 se voit comme telle.
  • Contenu des petits fichiers, parfois : les données stockées dans l'enregistrement FILE (résidentes, jusqu'à ~700 octets) peuvent apparaître dans les données redo/undo — parfois même pour des notes ou des scripts supprimés une minute plus tard. Sur les Windows récents, beaucoup de modifications ne journalisent que le fait qu'un changement a eu lieu : considérez le contenu récupéré comme un bonus, pas une garantie.
  • Il complète $UsnJrnl:$J (historique plus long, mais seulement motifs et noms) et le $MFT (état actuel seulement) : le $LogFile donne les valeurs avant / après.

Limites

  • Rétention courte : le journal est circulaire, seule l'activité récente y reste. Collectez-le tôt.
  • Les enregistrements n'ont pas d'heure. Les heures affichées viennent des valeurs $FILE_NAME / $STANDARD_INFORMATION contenues dans les données ; les événements sans heure empruntent celle de l'événement daté le plus proche et sont marqués ≈.
  • Les noms ne sont connus que s'ils apparaissent dans le journal ; sans le $MFT, certains chemins commencent par [MFT #n] ou manquent.
  • Le contenu non résident des fichiers n'est jamais dans le $LogFile (seulement les métadonnées). Le regroupement par transaction, le compagnon $UsnJrnl et le slack $I30 ne sont pas encore exploités.
  • Le parseur est validé sur des journaux synthétiques construits d'après le format publié (Linux ntfs3, libfsntfs) — vérifiez les constats importants avec un second outil.

Comment récupérer les fichiers

  • KAPE : les cibles $LogFile et $MFT (ou !SANS_Triage) les collectent en brut sur chaque volume. Velociraptor : Windows.Triage.Targets avec ses cibles LogFile et MFT (anciennement Windows.KapeFiles.Targets), ou l'accesseur NTFS.
  • Depuis une image disque : FTK Imager (export depuis [root]) ou The Sleuth Kit : icat -f ntfs image.dd 2 > '$LogFile' et icat … 0 > '$MFT'.
  • Prenez le $LogFile et le $MFT du même volume au même moment, et gardez l'arborescence (C/, D/…) pour que chaque journal soit associé à son $MFT.

FAQ

Mon $LogFile est-il envoyé quelque part ?

Non. Le parseur est écrit en Rust compilé en WebAssembly et tourne dans un Web Worker de votre navigateur. Il n'y a aucun point d'envoi ; le $MFT est lu par morceaux et seuls les noms de fichiers et les parents sont conservés.

Pourquoi ajouter le $MFT ?

Les enregistrements pointent vers des entrées MFT, et le nom d'un fichier n'est journalisé que lors de sa création, de son renommage ou de sa suppression. Le $MFT nomme toutes les autres entrées et tous les dossiers parents : les chemins deviennent complets (\Windows\System32\… au lieu de [MFT #44]).

Comment repère-t-il le timestomping ?

Chaque mise à jour de $STANDARD_INFORMATION dans le journal contient l'ancienne et la nouvelle valeur. Une date de création réécrite, un horodatage qui recule, une valeur à la seconde pile ou une création antérieure à celle de $FILE_NAME sont signalés — des indices à vérifier, pas des preuves.

Les journaux de Windows 8, 10 et 11 sont-ils pris en charge ?

Oui : le format 2.0 (32 pages rapides, utilisé quand le volume est monté sous Windows 8 et suivants) et le format 1.1 (anciens Windows, ou après un arrêt propre). La page la plus récente, souvent encore seulement dans la zone de fin / pages rapides d'une capture à chaud, est utilisée si elle est plus récente que sa copie circulaire.

Quelle différence avec LogFileParser ou NTFS Log Tracker ?

Mêmes données sources, sans installation : l'outil tourne dans le navigateur, affiche chaque enregistrement brut à côté des événements reconstruits, résout les chemins avec le $MFT et exporte en CSV / JSON. Ces outils sont plus mûrs — utilisez-les pour confirmer les constats clés.