$MFT est l'index que NTFS utilise pour suivre chaque fichier et chaque répertoire d'un volume. C'est aussi l'artefact le plus parlant que vous puissiez extraire d'une machine Windows. Tout autre fichier du volume, la table elle-même incluse, y possède au moins un enregistrement. Les outils forensiques répondent à des questions difficiles sur des fichiers dont Windows ne reconnaît plus l'existence, parce que les enregistrements survivent à la suppression. Les chasseurs de menaces y poursuivent la persistance parce que les attaquants ne peuvent pas déplacer de fichiers sur NTFS sans y écrire. Si vous ne deviez apprendre qu'un seul artefact Windows au niveau de l'octet, c'est celui-là.
C'est la référence que j'aurais aimé avoir au départ. Elle couvre ce qu'est la table, à quoi ressemble un enregistrement, quels attributs un enregistrement peut transporter, ce que signifient les fichiers système réservés au début, ce que signifie réellement l'erreur redoutée « Windows ne peut pas récupérer la master file table », et comment lire la table vous-même.
Qu'est-ce que la Master File Table
$MFT est un fichier. Un seul fichier. Il se trouve à un offset connu près du début de chaque volume NTFS. Le secteur de démarrage à l'offset 0 de la partition (les 512 octets du BIOS Parameter Block) contient un champ appelé MftStartLcn qui pointe vers le premier cluster de $MFT. Lisez ces 1 024 octets et vous avez l'enregistrement 0, l'autodescription de la table.
Chaque ligne de la table fait exactement 1 024 octets et décrit un fichier ou un répertoire. Chaque enregistrement contient le nom, les horodatages, les drapeaux de style DOS, la référence au descripteur de sécurité, et soit les données elles-mêmes (petits fichiers) soit une liste de clusters disque où vivent les données (gros fichiers), tout encodé comme une séquence d'attributs typés.
NTFS a été introduit avec Windows NT 3.1 en 1993 et est le système de fichiers Windows par défaut sur tout disque fixe depuis Windows XP. Il a remplacé FAT, qui conserve une petite table d'allocation et stocke les noms de fichiers à l'intérieur des entrées de répertoire. NTFS place presque chaque métadonnée de chaque fichier dans une seule table structurée, $MFT. Cette conception a deux conséquences à mémoriser :
- Toutes les métadonnées sont au même endroit. Un seul seek sur
$MFTénumère chaque fichier du volume. C'est pour cela que les outils forensiques, les antivirus, les services d'indexation et les logiciels de sauvegarde la lisent tous. C'est aussi pour cela qu'une$MFTcorrompue est un problème bien plus grand qu'une FAT corrompue. - Les fichiers supprimés laissent leurs métadonnées derrière eux. Quand NTFS supprime un fichier, il efface un bit dans l'en-tête de l'enregistrement et marque les clusters du fichier comme libres dans
$Bitmap. Le reste de l'enregistrement (nom, horodatages, souvent les données) reste en place jusqu'à ce que cet emplacement d'enregistrement soit réutilisé. Voir ce qui survit à une suppression.
L'acronyme MFT signifie Master File Table. Écrit $MFT sur le disque parce qu'en NTFS, le signe dollar préfixe les noms des fichiers de métadonnées.
Comment $MFT est disposée sur le disque
Quand NTFS formate un volume, il réserve une région appelée zone MFT près du début de la partition. Les 16 premiers enregistrements de la table sont réservés aux fichiers de métadonnées NTFS (décrits ci-dessous) ; l'enregistrement 0 est l'entrée propre de la table, pointant 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, c'est pour cela qu'une $MFT très fragmentée est courante sur les systèmes de fichiers vieillissants. La table ne rétrécit jamais. Une fois qu'un emplacement a été créé, il reste dans $MFT ; la suppression efface seulement le drapeau en-cours-d'utilisation. C'est pour cela que de vieux enregistrements supprimés bien au-dessus de la limite haute actuelle peuvent survivre des années sur un volume peu utilisé.
Une sauvegarde des premiers enregistrements vit dans $MFTMirr, placée au milieu du volume. Si $MFT elle-même est illisible, NTFS utilise $MFTMirr pour amorcer la récupération. Voir $MFTMirr et quand NTFS l'utilise.
Anatomie d'un enregistrement FILE
Chaque enregistrement MFT commence par la signature ASCII de quatre octets FILE (46 49 4C 45). Les enregistrements corrompus portent BAAD à la place, une pierre tombale écrite par chkdsk quand il n'a pas pu réparer l'enregistrement. Après la signature vient un en-tête de 56 octets, puis le tableau de fixup, puis un flux d'attributs typés terminé par 0xFFFFFFFF.
L'en-tête contient les champs que vous consultez le plus souvent :
- Signature.
FILEpour un enregistrement valide,BAADpour non réparable. - Tableau de séquence de mise à jour (fixup). Le truc pour détecter les écritures déchirées. Les deux derniers octets de chaque bloc de 512 octets de l'enregistrement sont remplacés par une USN ; les originaux sont stockés dans ce tableau. À la lecture, NTFS vérifie l'USN et restaure les octets originaux.
- Numéro de séquence
$LogFile. Un pointeur dans$LogFilepour la récupération après crash. - Numéro de séquence. Incrémenté à chaque fois que l'emplacement de l'enregistrement est réutilisé. Combiné au numéro d'enregistrement, il forme la référence fichier 64 bits qui identifie de façon unique une incarnation particulière d'un fichier.
- Nombre de hard links. Nombre d'attributs
$FILE_NAMEpointant vers l'enregistrement. - Drapeaux. Le bit 0 est
IN_USE(effacé signifie supprimé). Le bit 1 estDIRECTORY. - Référence à l'enregistrement de fichier de base. Non nul sur les enregistrements d'extension qui appartiennent à un enregistrement de base ailleurs dans la table.
- Taille utilisée et allouée. Utilisée, c'est ce que cet enregistrement consomme réellement dans l'emplacement de 1 024 octets ; allouée, c'est la taille de l'emplacement (toujours 1 024 sur les volumes standards).
Pour une visite octet par octet de l'en-tête et du flux d'attributs, voir à l'intérieur d'un enregistrement MFT.
Après l'en-tête viennent les attributs. Chacun a son propre petit en-tête (type, longueur, drapeau résident/non résident, nom optionnel) suivi des données. Il n'y a pas d'ordre fixe, mais en pratique $STANDARD_INFORMATION vient en premier et $DATA en dernier. Un enregistrement à court de place (trop de fragments, trop d'ADS, un nom anormalement long) fait pousser un attribut $ATTRIBUTE_LIST pointant vers un ou plusieurs enregistrements d'extension ailleurs dans la table. Les parsers doivent suivre la chaîne pour reconstruire le fichier.
Attributs de fichier stockés dans $MFT
Voici la liste canonique des types d'attributs NTFS, avec codes hexadécimaux :
| Type | Hex | Rôle |
|------|-----|---------|
| $STANDARD_INFORMATION | 0x10 | Quatre horodatages (créé, modifié, accédé, MFT-modifié), drapeaux DOS, ID propriétaire, ID de sécurité, pointeur USN. |
| $ATTRIBUTE_LIST | 0x20 | Pointeurs vers les enregistrements d'extension quand les attributs d'un fichier débordent d'un enregistrement. |
| $FILE_NAME | 0x30 | Un nom de fichier, référence au répertoire parent, tailles allouée et réelle, et un second jeu de quatre horodatages. Un fichier peut en avoir plusieurs (un par hard link, plus le nom court 8.3 sur les volumes où c'est activé). |
| $OBJECT_ID | 0x40 | Identifiant d'objet 128 bits utilisé par le service Distributed Link Tracking. |
| $SECURITY_DESCRIPTOR | 0x50 | ACL par fichier (héritage). 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 l'étiquette 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 runlist de clusters) sinon. Un fichier peut porter plusieurs attributs $DATA ; celui sans nom est le flux primaire, les nommés sont les alternate data streams. |
| $INDEX_ROOT | 0x90 | Racine d'un B+ tree. Utilisé par les répertoires ($I30), les index de reparse points et d'autres structures indexées. |
| $INDEX_ALLOCATION | 0xA0 | Suite non résidente d'un grand index. |
| $BITMAP | 0xB0 | Bitmap d'allocation pour $MFT elle-même ou pour les grands répertoires. |
| $REPARSE_POINT | 0xC0 | Symlinks, junctions, points de montage, placeholders OneDrive, stubs de dédup. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Attributs étendus de l'ère OS/2. Rares sous Windows moderne. WSL1 les utilisait pour les métadonnées POSIX, c'est le seul contexte qui mérite attention. |
| $LOGGED_UTILITY_STREAM | 0x100 | Métadonnées de chiffrement EFS ($EFS), données de transaction TxF. |
Un enregistrement porte toujours au moins $STANDARD_INFORMATION, un $FILE_NAME et un $DATA. Tout le reste est optionnel et lié à des fonctionnalités.
Données résidentes vs non résidentes
La plupart des attributs $DATA sur un volume réel sont non résidents : l'en-tête de l'attribut contient 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 assez petit (typiquement sous ~700 octets une fois les autres attributs comptés), NTFS stocke les octets en ligne dans l'enregistrement. Ce sont les 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 par octet, dans un enregistrement $MFT non alloué. Voir données résidentes pour le seuil de taille et ce qu'il faut chercher.
Fichiers de métadonnées NTFS dans les seize premiers enregistrements
Les 16 premiers enregistrements de $MFT sont réservés à la comptabilité interne de NTFS. Ils commencent par $ pour ne pas entrer en collision avec des noms de fichiers utilisateurs. Ceux qu'il faut connaître :
| Rec # | Fichier | Ce que c'est |
|-------|------|------------|
| 0 | $MFT | La table elle-même. Sa runlist $DATA pointe vers ses propres clusters. |
| 1 | $MFTMirr | Sauvegarde partielle des premiers enregistrements de $MFT. |
| 2 | $LogFile | Journal de transactions utilisé pour annuler ou rejouer des opérations incomplètes après un crash. |
| 3 | $Volume | Étiquette du volume et drapeau dirty. |
| 4 | $AttrDef | Schéma des types d'attributs valides. |
| 5 | . | Le répertoire racine. |
| 6 | $Bitmap | Un bit par cluster du volume ; suit l'allocation. |
| 7 | $Boot | Copie du secteur d'amorçage. |
| 8 | $BadClus | Fichier creux dont les runs pointent vers chaque cluster que le système de fichiers a marqué comme défectueux. |
| 9 | $Secure | Magasin central des descripteurs de sécurité. |
| 10 | $UpCase | Table de mappage majuscules Unicode utilisée pour la comparaison des noms insensible à la casse. |
| 11 | $Extend | Répertoire contenant les fichiers système plus récents : $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
Le journal des changements $UsnJrnl (sous $Extend) est particulièrement utile en forensique ; il enregistre chaque changement de métadonnées sur le volume et complète $MFT pour la reconstruction de timeline. Voir coupler le journal avec la table de fichiers.
Quand $MFT déraille
L'erreur « Windows ne peut pas récupérer la master file table. CHKDSK abandonné » apparaît quand chkdsk ne peut pas lire $MFT et ne peut pas non plus se rabattre sur $MFTMirr. À ce stade, NTFS a déjà tenté et échoué dans son autoréparation intégrée. Les causes racines que j'ai vues, classées par fréquence réelle :
- Média physique défaillant. Des secteurs défectueux dans la zone MFT renvoient des ordures à la lecture. Les données SMART le corroborent habituellement. Imaginez le disque avec
ddrescue, pasdd, et travaillez sur l'image. - Coupure de courant soudaine pendant une opération intensive en métadonnées. Le journal de transactions les annule habituellement, mais un
$LogFilecorrompu fait échouer le rollback. - Corruption au niveau driver ou filtre. Stacks de chiffrement disque défectueux, minifiltres de système de fichiers, ou drivers de stockage bogués peuvent écrire des enregistrements incohérents. Courant sur les hôtes avec plusieurs agents de sécurité qui s'affrontent.
- Écrasements malveillants. Les wipers et quelques familles de ransomware (notamment Petya et la première vague NotPetya) gribouillent délibérément sur
$MFTpour rendre le volume non montable. Voir motifs de ransomware dans la MFT.
La réponse forensiquement saine :
- Arrêtez d'écrire sur le volume immédiatement. Chaque écriture ultérieure réduit les chances de récupération.
- Imagez le disque avec FTK Imager,
ddouddrescuevers une destination connue saine. Vérifiez le hash. - Travaillez sur l'image, pas l'original. Essayez
testdisk,R-Studio, ou un parse manuel qui trouve les enregistrementsFILEen scannant les signatures directement sur le volume. Même si le pointeur on-disk vers$MFTa disparu, les enregistrements eux-mêmes sont généralement encore reconnaissables. - Si l'objectif est de remettre le volume en ligne 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 rejeter les enregistrements qu'il ne comprend pas. Ne le lancez sur l'original qu'après avoir 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). Une CLI Windows qui produit du CSV dans la disposition compatible bodyfile que la plupart des outils de timeline attendent. Le standard de fait pour les intervenants en incidents.
omerbenamram/mft. Un crate Rust et CLI (mft_dump). Le parser que ce site utilise, utile quand vous voulez scripter l'analyse ou l'intégrer dans un pipeline plus large.- Le parser navigateur de ce site. Déposez
$MFTsur la page d'accueil et il exécute le même parser Rust, compilé en WebAssembly, entièrement dans votre navigateur. Rien n'est téléversé.
Pour une comparaison avec des pour et contre concrets, voir outils de parser MFT. Pour des workflows pratiques sur une $MFT parsée, voir construire une timeline, fichiers supprimés et extraire $MFT.
Questions fréquentes
Que signifie MFT ?
MFT signifie Master File Table. Écrit $MFT sur le disque parce qu'en NTFS, le signe dollar préfixe les noms des fichiers de métadonnées.
À quoi sert la master file table ?
C'est l'index que NTFS utilise pour trouver chaque fichier et chaque répertoire d'un volume. Chaque entrée stocke le nom du fichier, les horodatages, les informations de sécurité, les 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 (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 est dans le tableau d'attributs ci-dessus.
Quelle taille fait la master file table ?
Chaque enregistrement fait 1 024 octets. La table réserve environ 12,5 % du volume par défaut (la zone MFT) mais ne consomme que l'espace dont elle a réellement besoin. Un volume contenant 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 la récupération 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 contre l'image (rapide, peut rejeter des enregistrements), soit utilisez un outil de récupération capable de scanner les signatures FILE et de réassembler la table à partir des clusters bruts (lent, préserve plus de preuves). Ne lancez jamais chkdsk contre le volume original avant l'imaging.
Puis-je lire $MFT sous Linux ou macOS ?
Oui. $MFT est juste un fichier. Tout parser qui accepte un dump brut de $MFT 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 depuis un volume monté en direct.
Lectures complémentaires
- Microsoft, Master File Table. La référence officielle, concise.
- Brian Carrier, File System Forensic Analysis. Toujours le meilleur livre unique sur la disposition et la récupération de NTFS.
- La documentation NTFS du projet linux-ntfs. Offsets de champs pour chaque attribut, obtenus à la dure par reverse engineering.