La Master File Table, écrite $MFT sur le disque, est l'index dont NTFS se sert pour suivre chaque fichier et dossier d'un volume. C'est le premier fichier utilisateur visible de toute partition NTFS, et tous les autres fichiers du volume — y compris la table elle-même — y possèdent au moins une entrée. Lire $MFT est ainsi le moyen par lequel les outils de forensique répondent à des questions sur des fichiers dont Windows ne reconnaît plus l'existence : quand ils ont été créés, sous quel nom, avec quel contenu, et qui les a touchés en dernier.
Ce guide est une référence complète. Il couvre ce qu'est la table, comment un enregistrement est mis en forme, quels attributs il peut porter, le petit ensemble de fichiers système réservés au début de la table, ce que signifie vraiment « Windows ne peut pas récupérer la master file table », et comment lire $MFT vous-même avec le parseur de ce site.
Qu'est-ce que la Master File Table ?
La Master File Table est un fichier unique nommé $MFT situé à un emplacement fixe près du début de chaque volume NTFS. NTFS — New Technology File System — a été introduit avec Windows NT 3.1 en 1993 et a remplacé FAT comme système de fichiers par défaut de Windows. Contrairement à FAT, qui conserve une petite table d'allocation et stocke les noms de fichiers dans les entrées de dossier, NTFS regroupe presque toutes les métadonnées de chaque fichier dans une seule table structurée : $MFT.
Chaque ligne de cette table est un enregistrement d'exactement 1 024 octets. Chaque enregistrement décrit un fichier ou un dossier. Il contient le nom, les horodatages, les drapeaux de style DOS, la liste des clusters disque où vit ses données, les descripteurs de sécurité et une poignée d'autres attributs — le tout encodé sous forme d'un petit sac de champs typés.
Ce design a deux conséquences majeures :
- Toutes les métadonnées sont regroupées. Une seule recherche dans
$MFTsuffit à énumérer chaque fichier du volume. Les outils de forensique et de récupération en dépendent ; de même que les antivirus et les services d'indexation. - Les fichiers supprimés laissent des métadonnées intactes. Quand NTFS supprime un fichier, il efface un bit dans l'en-tête de l'enregistrement et marque les clusters comme libres. Le reste de l'enregistrement — le nom, les horodatages, souvent les data runs — reste en place jusqu'à ce que cet emplacement soit réutilisé.
L'acronyme MFT signifie Master File Table. Vous le verrez écrit MFT, $MFT, ou la MFT. Tous renvoient à la même structure sur disque.
Comment $MFT est disposée sur le disque
Quand NTFS formate un volume, il réserve une zone appelée la MFT zone près du début de la partition. Le boot sector au décalage 0 du volume contient un pointeur (le champ MftStartLcn) vers le premier cluster de $MFT. Les 16 premiers enregistrements de la table sont réservés à des fichiers système NTFS (décrits plus bas) ; l'enregistrement 0 est l'entrée de la table elle-même, qui pointe vers ses propres clusters.
$MFT grandit en s'étendant dans sa zone réservée chaque fois qu'elle a besoin de plus d'enregistrements. Si le volume se remplit avant que la zone ne soit épuisée, Windows réduit la zone pour faire de la place aux données utilisateur, ce qui explique pourquoi une $MFT fortement fragmentée est un symptôme courant sur les volumes vieillissants.
Une sauvegarde des premiers enregistrements vit dans un second fichier, $MFTMirr, généralement placé au milieu du volume. Si $MFT est corrompue, NTFS utilise $MFTMirr pour amorcer la récupération — c'est le mécanisme à l'origine de l'erreur « Windows ne peut pas récupérer la master file table » décrite plus loin.
Anatomie d'un enregistrement FILE
Chaque enregistrement MFT commence par la signature ASCII FILE sur quatre octets. (Les enregistrements corrompus utilisent BAAD à la place — une pierre tombale délibérément écrite par chkdsk.) Après la signature vient un en-tête fixe, suivi d'un flux d'attributs de longueurs variables.
L'en-tête de l'enregistrement porte :
- Signature —
FILEpour un enregistrement valide,BAADpour un enregistrement quechkdskn'a pas pu réparer. - Numéro de séquence de mise à jour (USN) et tableau fixup — une petite astuce de contrôle qui permet à NTFS de détecter les écritures interrompues. Les deux derniers octets de chaque bloc de 512 octets de l'enregistrement sont remplacés par l'USN ; les originaux sont rangés dans le tableau fixup. À la lecture, NTFS vérifie l'USN et restaure les octets d'origine.
- Numéro de séquence du journal — pointeur vers
$LogFilepour la reprise après incident. - Numéro de séquence — incrémenté chaque fois que l'emplacement est réutilisé. Combiné au numéro d'enregistrement, il forme une référence de fichier de 64 bits qui identifie de manière unique une incarnation précise d'un fichier.
- Compteur de liens physiques — nombre d'attributs
$FILE_NAMEqui pointent vers l'enregistrement. - Drapeaux — le plus important est le bit 0,
IN_USE. À zéro signifie supprimé. - Référence de l'enregistrement de base — non nulle sur les enregistrements d'extension qui appartiennent à un enregistrement de base situé ailleurs dans la table.
Après l'en-tête viennent les attributs. Chaque attribut a son propre petit en-tête (type, longueur, drapeau résident/non résident, nom s'il y en a un) suivi des données. Il n'y a pas d'ordre fixe, mais $STANDARD_INFORMATION est traditionnellement en premier et $DATA en dernier.
Un enregistrement qui manque de place — trop de fragments, trop d'ADS, un nom inhabituellement long — voit pousser un attribut $ATTRIBUTE_LIST qui pointe vers un ou plusieurs enregistrements d'extension ailleurs dans la table. Les parseurs doivent suivre la chaîne pour reconstituer le fichier complet.
Les attributs de fichier stockés dans MFT
C'est la recherche la plus courante derrière le mot-clé « quels attributs de fichier sont stockés dans la master file table ». La liste complète des types d'attributs NTFS, avec leurs codes hex :
| Type | Hex | Rôle |
|------|-----|------|
| $STANDARD_INFORMATION | 0x10 | Quatre horodatages (création, modification, accès, modification MFT), drapeaux DOS, ID propriétaire, ID de sécurité, USN. |
| $ATTRIBUTE_LIST | 0x20 | Pointeur vers les enregistrements d'extension lorsque les attributs d'un fichier débordent d'un seul enregistrement. |
| $FILE_NAME | 0x30 | Un nom de fichier, une référence du dossier parent, la taille allouée et réelle, et un second jeu de quatre horodatages. Un fichier peut en avoir plusieurs — un par lien physique, un pour le nom court 8.3. |
| $OBJECT_ID | 0x40 | Identifiant d'objet de 128 bits utilisé par le service Distributed Link Tracking. |
| $SECURITY_DESCRIPTOR | 0x50 | ACL par fichier (héritage). Le NTFS moderne stocke les ACL centralement dans $Secure et les référence par ID depuis $STANDARD_INFORMATION. |
| $VOLUME_NAME | 0x60 | Uniquement sur l'enregistrement 3 ($Volume). Contient le nom du volume. |
| $VOLUME_INFORMATION | 0x70 | Version NTFS, drapeau dirty. |
| $DATA | 0x80 | Le contenu du fichier. Résident pour les très petits fichiers ; non résident (une liste de cluster runs) sinon. Un fichier peut porter plusieurs $DATA — celui sans nom est le flux principal, les nommés sont des flux de données alternatifs. |
| $INDEX_ROOT | 0x90 | Racine d'un arbre B+. Utilisé par les dossiers ($I30), les index de points de reparse et autres structures indexées. |
| $INDEX_ALLOCATION | 0xA0 | Continuation non résidente d'un grand index. |
| $BITMAP | 0xB0 | Bitmap d'allocation pour $MFT elle-même ou pour les grands dossiers. |
| $REPARSE_POINT | 0xC0 | Symlinks, jonctions, points de montage, placeholders OneDrive. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Attributs étendus hérités de l'ère OS/2. Rares sur Windows moderne. |
| $LOGGED_UTILITY_STREAM | 0x100 | Métadonnées de chiffrement EFS ($EFS), données transactionnelles TxF. |
Un enregistrement porte toujours au minimum $STANDARD_INFORMATION, un $FILE_NAME et un $DATA. Tout le reste est optionnel et lié à des fonctionnalités spécifiques.
Données résidentes vs non résidentes
La plupart des attributs $DATA sur un vrai volume sont non résidents : l'en-tête de l'attribut porte une liste compacte de cluster runs (un LCN de départ et une longueur, répétés), et les octets du fichier vivent ailleurs sur le disque. L'en-tête de l'attribut lui-même est petit.
Si le fichier est suffisamment petit — typiquement moins de ~700 octets après comptabilisation des autres attributs — NTFS stocke les octets inline dans l'enregistrement. Ce sont des données résidentes, et c'est l'un des artefacts les plus utiles en forensique : le contenu d'un petit fichier texte supprimé il y a des semaines peut encore se trouver, octet pour octet, à l'intérieur d'un enregistrement $MFT désalloué. Voir resident-data pour aller plus loin.
Fichiers système NTFS dans les seize premiers enregistrements
Les 16 premiers enregistrements de $MFT sont réservés aux fichiers de gestion interne de NTFS. Ils commencent par un $ pour ne pas entrer en conflit avec les noms de fichiers utilisateur. Ceux à connaître :
| Enr. | Fichier | Rôle |
|------|---------|------|
| 0 | $MFT | La table elle-même. |
| 1 | $MFTMirr | Sauvegarde des premiers enregistrements de $MFT. |
| 2 | $LogFile | Journal de transactions utilisé pour défaire ou rejouer les opérations interrompues après un incident. |
| 3 | $Volume | Nom de volume et drapeau dirty. |
| 4 | $AttrDef | Schéma des types d'attributs valides. |
| 5 | . | Le dossier racine. |
| 6 | $Bitmap | Un bit par cluster du volume ; suit l'allocation. |
| 7 | $Boot | Copie du boot sector. |
| 8 | $BadClus | Fichier sparse dont les runs pointent vers chaque cluster que le système a marqué comme défectueux. |
| 9 | $Secure | Magasin central des descripteurs de sécurité. |
| 10 | $UpCase | Table de mappage Unicode en majuscules utilisée pour la comparaison de noms insensible à la casse. |
| 11 | $Extend | Dossier contenant les fichiers système plus récents : $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
Le journal de changements $UsnJrnl (sous $Extend) est particulièrement utile en forensique — il enregistre chaque changement de métadonnées du volume et complète $MFT pour la reconstruction de chronologies. Voir usn-journal.
Quand $MFT tourne mal : corruption et « Windows ne peut pas récupérer la master file table »
Le message d'erreur « Windows ne peut pas récupérer la master file table. CHKDSK abandonné » apparaît lorsque chkdsk ne peut pas lire $MFT ni se rabattre sur $MFTMirr. À ce stade, NTFS a déjà essayé et échoué dans sa réparation interne.
Causes racines courantes :
- Média physique défaillant. Des secteurs défectueux dans la MFT zone font que la lecture retourne des données aberrantes. Les données SMART corroborent habituellement.
- Coupure de courant soudaine pendant une opération lourde en métadonnées. Le journal de transactions effectue normalement le rollback, mais un
$LogFilecorrompu mettra en échec ce mécanisme. - Corruption au niveau pilote ou filtre. Des piles de chiffrement disque mal conçues, des minifiltres système de fichiers ou des pilotes de stockage bogués peuvent écrire des enregistrements incohérents.
- Écrasements malveillants. Des wipers et certaines familles de ransomware griffonnent délibérément sur
$MFTpour rendre le volume plus difficile à récupérer.
La réponse saine sur le plan forensique est :
- Arrêtez immédiatement toute écriture sur le volume. Chaque écriture supplémentaire réduit les chances de récupération.
- Imagez le disque avec FTK Imager,
ddouddrescuevers une destination saine. Vérifiez le hash. - Travaillez sur l'image, pas sur l'original. Essayez
testdisk,R-Studio, ou une analyse manuelle qui trouve les enregistrementsFILEen scannant le volume — même si le pointeur sur disque vers$MFTa disparu, les enregistrements eux-mêmes sont généralement encore reconnaissables. - Si l'objectif est de remettre le volume en service plutôt que de récupérer des données, alors seulement lancez
chkdsk /fsur l'image.
chkdsk /b sur un volume inscriptible peut effacer les marqueurs de clusters défectueux, mais il peut aussi écarter des enregistrements qu'il ne comprend pas. Ne l'exécutez sur l'original qu'après avoir obtenu une image et avoir décidé que la disponibilité l'emporte sur la fidélité forensique.
Comment lire $MFT
Vous avez trois options réalistes :
- MFTECmd (Eric Zimmerman) — un CLI Windows qui produit du CSV au format attendu par la plupart des outils de chronologie. Le standard de fait pour les répondeurs incident.
omerbenamram/mft— un crate Rust et un CLI. Le même parseur que ce site utilise, pratique quand vous voulez scripter une analyse ou l'intégrer dans un pipeline plus large.- Le parseur de ce site dans le navigateur — déposez
$MFTsur la page d'accueil et le même parseur Rust, compilé en WebAssembly, s'exécute entièrement dans votre navigateur. Rien n'est envoyé. Utile quand vous voulez une lecture rapide sans rien installer, ou quand la politique interdit d'envoyer les preuves à un service cloud.
Pour une comparaison concrète des trois, voir mft-parser-tools. Pour des workflows pratiques s'appuyant sur un $MFT analysé, voir build-mft-timeline, deleted-files et extracting-mft.
Questions fréquentes
Que signifie MFT ?
MFT signifie Master File Table. Sur disque, on l'écrit aussi $MFT car, sur NTFS, le signe dollar préfixe le nom des fichiers de métadonnées.
À quoi sert la master file table ?
C'est l'index dont NTFS se sert pour trouver chaque fichier et dossier d'un volume. Chaque entrée stocke le nom du fichier, ses horodatages, ses informations de sécurité, ses attributs et l'emplacement de ses données sur le disque.
Quels attributs de fichier sont stockés dans la master file table ?
Au minimum, chaque enregistrement porte $STANDARD_INFORMATION (horodatages, drapeaux DOS), $FILE_NAME (nom et un second jeu d'horodatages) et $DATA (le contenu du fichier ou un pointeur vers celui-ci). Les enregistrements peuvent aussi porter $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA et $LOGGED_UTILITY_STREAM selon le fichier. La référence complète figure dans le tableau d'attributs ci-dessus.
Quelle est la taille de la master file table ?
Chaque enregistrement fait 1 024 octets. La table réserve environ 12,5 % du volume par défaut (la MFT zone) mais ne consomme que l'espace réellement nécessaire. Un volume avec un million de fichiers a une $MFT d'environ 1 Go.
$MFT est-il identique à $MFTMirr ?
Non. $MFTMirr est une sauvegarde partielle des premiers enregistrements de $MFT, placée ailleurs sur le disque pour que NTFS puisse amorcer une reprise si l'en-tête de la table principale est corrompu.
Comment réparer une master file table corrompue ?
Imagez d'abord le disque. Ensuite, soit lancez chkdsk /f sur l'image (rapide, peut écarter des enregistrements), soit utilisez un outil de récupération capable de scanner les signatures FILE et de reconstituer la table à partir des clusters bruts (lent, préserve plus de preuves). N'exécutez jamais chkdsk sur le volume original avant l'imagerie.
Puis-je lire $MFT sous Linux ou macOS ?
Oui. $MFT n'est qu'un fichier. Tout parseur qui accepte un dump $MFT brut fonctionne sur n'importe quel OS — omerbenamram/mft, analyzeMFT, l'outil navigateur de ce site. Vous n'avez besoin de Windows que pour extraire le fichier d'un volume monté.