Skip to content

Format du $LogFile 1.1 et 2.0 : ce qui change avec Windows 8

Formats de journal NTFS 1.1 et 2.0 : pages de queue ou 32 pages rapides, début de la zone circulaire, captures à chaud en 2.0 et impact sur les parseurs.

Publié le 6 min de lecture

TL;DR. Les deux versions commencent par deux pages de redémarrage RSTR. LFS 1.1 (Windows XP à 7, et Windows 8+ après un arrêt propre) les fait suivre de deux pages de queue — des copies de la page en cours d'écriture — et commence la zone circulaire à 0x4000 (pages de 4 Kio). LFS 2.0 (Windows 8+ tant que le volume est monté) utilise à la place 32 pages rapides et commence la zone circulaire à 0x22000. Sur une capture à chaud, les enregistrements les plus récents peuvent n'exister que dans la zone de queue ou de pages rapides. Un parseur qui l'ignore perd l'activité la plus récente ; un parseur qui suppose la mauvaise version lit mal le fichier.

La version figure dans l'en-tête de la page de redémarrage : version mineure à 0x1A, majeure à 0x1C (libfsntfs, ntfs3). Tout le reste de cet article découle de ce seul nombre.

Les deux organisations

Structure du $LogFile NTFS pour les formats de journal 1.1 et 2.0
Pages de journal de 4 Kio. Offsets d'après le pilote Linux ntfs3.
LFS 1.1LFS 2.0
Pages de redémarrage0x0000, 0x10000x0000, 0x1000
Zone spéciale2 pages de queue (0x2000, 0x3000)32 pages rapides (0x2000–0x21FFF)
Début de la zone circulaire4 × taille de page = 0x40000x22 × taille de page = 0x22000
Comment une page spéciale désigne la page circulaire qu'elle copieDans le champ LSN de l'en-tête de pageOffset explicite dans le fichier, à 0x3C de l'en-tête RCRD
Origine typiqueXP à 7 ; Windows 8+ après un arrêt propreWindows 8+ volume monté

Les offsets sont ceux du pilote Linux ntfs3 (first_page = major_ver >= 2 ? 0x22 * page_size : …), qui rejoue les deux versions.

Les pages de queue (1.1)

Le LFS écrit les enregistrements dans la page courante de la zone circulaire. Réécrire cette page sur place à chaque nouvel enregistrement risquerait qu'une écriture partielle détruise des enregistrements déjà validés. LFS 1.1 s'en protège avec deux pages de queue : la page courante est d'abord écrite dans la zone spéciale, puis plus tard à sa position circulaire. Comme le décrit dfir.ru, la zone spéciale contient deux copies de la page d'enregistrements courante.

Pour l'analyste, la conséquence est simple : la page la plus récente d'un journal 1.1 pris à chaud peut être plus complète dans la zone de queue que dans la zone circulaire.

Les pages rapides (2.0)

Windows 8 a porté la zone spéciale à 32 pages. Au lieu de réécrire la page courante, le LFS écrit les pages mises à jour dans un emplacement libre de la zone de pages rapides, et seulement plus tard dans la zone circulaire, ce qui réduit les écritures dans cette dernière. Les versions plus anciennes d'une même page restent dans la zone rapide et peuvent servir à la reprise après une écriture partielle (toujours selon dfir.ru).

Chaque page rapide porte l'offset de la page circulaire qu'elle représente, à 0x3C dans l'en-tête RCRD (file_off dans ntfs3, « used when major version >= 2 »). C'est ce champ qui permet à un parseur de savoir où ranger une page rapide.

Pourquoi une capture à chaud diffère d'une image à froid

dfir.ru indique que la version du journal est ramenée à 1.1 lors d'un arrêt propre, par défaut. Sur une même machine Windows 11 :

CaptureVersion généralement observéeZone spéciale
À chaud (KAPE, Velociraptor, FTK Imager sur la machine allumée)2.0Pages rapides, contenant peut-être la page la plus récente
Image après arrêt propre1.1Pages de queue
Image après plantage ou coupure brutale2.0Pages rapides, telles que laissées au plantage

La zone de redémarrage porte aussi un drapeau que le parseur dans le navigateur interprète comme « démonté proprement » (bit 0x2 des drapeaux de la zone de redémarrage) ; il est absent sur une capture à chaud ou après un plantage. Ensemble, la version et ce drapeau en disent long sur la manière dont la preuve a été capturée — à mentionner dans votre rapport.

Ce qu'un parseur doit faire

  1. Lire les deux pages de redémarrage, valider leurs tableaux de séquence de mise à jour et garder celle dont le LSN courant est le plus élevé.
  2. En tirer la version majeure et calculer le début de la zone circulaire.
  3. Lire toutes les pages circulaires.
  4. Lire les pages de queue ou les pages rapides, trouver la page circulaire que chacune représente et remplacer la page circulaire quand la copie spéciale est plus récente.
  5. Seulement ensuite, chercher les enregistrements, en réassemblant ceux qui s'étendent sur plusieurs pages ou qui reviennent de la fin du fichier au début de la zone circulaire.

Le parseur dans le navigateur fait exactement cela et affiche « N page(s) la plus récente lue(s) dans la zone de fin / pages rapides » dans sa ligne d'en-tête. Sur son exemple synthétique (LFS 2.0, capture à chaud), une page venait de la zone rapide ; sans elle, les derniers événements de l'intrusion fictive manqueraient. Il n'extrait pas encore les copies plus anciennes de pages qui peuvent subsister dans la zone rapide — une source possible d'enregistrements supplémentaires.

Pièges

  • Coder 0x4000 en dur. Un parseur limité à la 1.1, lancé sur un journal 2.0, traite les pages rapides comme des pages circulaires et place mal ou duplique des enregistrements.
  • Ignorer la zone spéciale. La page la plus récente d'une capture à chaud peut ne se trouver que là.
  • Supposer 4 Kio. Les tailles de page système et de journal figurent dans l'en-tête de la page de redémarrage (0x10, 0x14) ; lisez-les.
  • Faire confiance à une page CHKD. Une page de redémarrage signée CHKD signifie que chkdsk a travaillé sur le journal ; traitez son contenu avec prudence.

dfir.ru évoque aussi une version 3.0 prévue pour les volumes DAX, avec des sommes CRC32 à la place des tableaux de séquence de mise à jour. Ni le pilote Linux ni le parseur de ce site ne la gèrent ; si vous rencontrez une version majeure 3, attendez-vous à ce que les parseurs refusent le fichier.

Questions fréquentes

Quelles versions de Windows utilisent le $LogFile en version 2.0 ?

Windows 8 et les versions suivantes utilisent le format de journal 2.0 tant qu'un volume NTFS est monté. Par défaut, le journal repasse en 1.1 lors d'un arrêt propre : l'image d'un disque Windows 10 ou 11 arrêté proprement peut donc montrer 1.1, alors qu'une capture à chaud montre 2.0.

Pourquoi un parseur doit-il connaître la version du journal ?

La version détermine où commence la zone circulaire des enregistrements (0x4000 ou 0x22000 avec des pages de 4 Kio) et comment les pages de queue ou les pages rapides correspondent aux pages circulaires. Lire un journal 2.0 avec les hypothèses de la 1.1 traite les 32 pages rapides comme des enregistrements ordinaires et place mal les données les plus récentes.

Pour aller plus loin

  • Maxim Suhanov, How the $LogFile works? — la source du comportement 1.1/2.0 décrit ici.
  • Noyau Linux, fs/ntfs3/fslog.c — log_init_pg_hdr, gestion des pages de queue et RECORD_PAGE_HDR.file_off.

Articles liés

Articles liés