$MFTMirr est la plus petite police d'assurance de NTFS. Il reflète les premiers enregistrements de $MFT afin que, lorsque les octets du début de la table principale sont illisibles, le driver du système de fichiers ait toujours un moyen de retrouver chaque fichier du volume. C'est aussi l'artefact que les gens oublient d'acquérir et dont ils ont besoin trois semaines plus tard.
Voici ce qu'il contient réellement, où il se situe sur le disque, quand NTFS l'utilise et les cas (limités) où il fait ses preuves en forensique.
Pourquoi un miroir existe
Les premiers enregistrements de $MFT sont porteurs. L'enregistrement 0 est $MFT elle-même, avec une runlist $DATA qui dit où vit le reste de la table sur le disque. L'enregistrement 2 est $LogFile. L'enregistrement 3 est $Volume. Si les octets du début de $MFT sont endommagés, NTFS ne peut trouver aucun des autres fichiers du volume, y compris le journal de transactions qu'il utiliserait normalement pour récupérer les incohérences du système de fichiers.
C'est une dépendance circulaire : il vous faut $MFT pour trouver $LogFile, mais il vous faut $LogFile pour réparer $MFT. Le miroir casse le cycle. $MFTMirr est un fichier séparé à un emplacement physique différent contenant un duplicata de ces premiers enregistrements. Quand le driver monte un volume, il lit l'enregistrement 0 de $MFT ; si cette lecture échoue ou si le tableau fixup ne se vérifie pas, il se rabat sur l'enregistrement 0 de $MFTMirr et utilise le duplicata pour relocaliser le reste.
Où il vit
$MFTMirr est l'enregistrement MFT 1. Son attribut $DATA est non résident, et sa runlist pointe traditionnellement vers le milieu du volume afin qu'une seule défaillance localisée (un secteur défectueux, une écriture déchirée sur une région) ne puisse pas faire tomber les deux copies. Le NTFS moderne le place à la LCN clusterCount / 2. Sur un volume de 500 Go, cela place le miroir autour de la barre des 250 Go.
Vous pouvez le trouver depuis un système vivant :
fsutil file queryextents C:\$MFTMirr
Cela renvoie les cluster runs occupés par $MFTMirr, qu'une lecture brute peut réassembler. La cible MFT de KAPE le collecte aux côtés de $MFT par défaut. Si vous utilisez FTK Imager, il se trouve à côté de $MFT à la racine du volume NTFS.
Ce qu'il contient
Des copies octet par octet des premiers enregistrements MFT. La garantie historique portait sur les quatre premiers enregistrements (0 à 3, les métadonnées vraiment essentielles). Les versions actuelles de Windows reflètent les seize premiers, ce qui correspond à l'ensemble complet de métadonnées NTFS décrit dans la référence de la master file table.
Chaque copie est un enregistrement MFT normal. Même signature FILE, même en-tête, même tableau fixup, même flux d'attributs. Un parser pointé sur $MFTMirr le parcourt exactement comme il parcourt $MFT. MFTECmd, mft_dump, analyzeMFT et le fls du Sleuth Kit l'acceptent tous en entrée.
Comment NTFS l'utilise au montage
Sur un montage sain, le driver ne touche pas $MFTMirr. Sur un montage endommagé :
- Lire l'enregistrement 0 de
$MFT. - Si la lecture renvoie une erreur I/O, ou si la vérification fixup échoue, lire l'enregistrement 0 de
$MFTMirrà la place. - Si la copie de l'enregistrement 0 dans le miroir est valide, utiliser sa runlist
$DATApour localiser$MFTsur le disque et continuer.
Le miroir n'a pas à remplacer $MFT. Il doit seulement fournir assez d'informations pour retrouver la vraie. Une fois que le driver a localisé $MFT depuis le pointeur du miroir, il continue avec la table vivante.
Comment chkdsk l'utilise
chkdsk est plus agressif. Quand il détecte une corruption dans les premiers enregistrements de $MFT, il croise chaque enregistrement avec le miroir. Si les deux copies sont valides mais diffèrent, chkdsk traite le miroir comme faisant autorité pour les premiers enregistrements critiques (en supposant que les enregistrements vivants ont été mis à jour plus récemment et corrompus dans le processus).
Si $MFT est illisible et que le miroir est illisible, chkdsk signale Windows ne peut pas récupérer la master file table. CHKDSK abandonné. À ce stade, la récupération nécessite des outils hors ligne : carving de signature pour les enregistrements FILE sur le volume brut avec Sleuth Kit, R-Studio ou testdisk. L'autoréparation intégrée de NTFS est épuisée.
Pourquoi $MFTMirr n'est pas une sauvegarde complète
Il ne reflète que les fichiers de métadonnées. Les enregistrements 16 et au-delà, qui correspondent à tout fichier et tout répertoire utilisateur, n'existent que dans $MFT. Si $MFT est endommagé au-delà de l'enregistrement 16, le miroir ne peut pas vous aider. Le miroir suffit à monter le volume ; récupérer des fichiers quelconques à partir de dommages nécessite les mêmes techniques que vous utiliseriez sans lui.
C'est la méprise qui coûte du temps aux gens dans les engagements IR. Ils se tournent vers $MFTMirr en pensant que c'est un snapshot historique complet. Ce n'est pas le cas. Pour cela, vous voulez les Volume Shadow Copies, dont chacune contient une vraie copie à un instant donné de la $MFT complète.
Intérêt forensique
$MFTMirr est rarement l'artefact principal dans une affaire, mais il a deux usages réels :
- Recoupement. Les enregistrements 0 à 15 du miroir devraient correspondre bit pour bit aux enregistrements vivants. Une divergence suggère qu'un côté a été modifié hors bande : un bug de driver, une manipulation délibérée, une récupération partielle après un crash, ou un wiper mal écrit qui a gribouillé sur la MFT vivante et raté le miroir. J'ai vu exactement un cas où le miroir a attrapé un wiper qui avait écrasé les 16 premiers enregistrements de
$MFTsans se rendre compte qu'une copie vivait ailleurs sur le volume. La reconstruction a fonctionné parce que le miroir était intact. - Snapshot pré-corruption. Si les enregistrements vivants de
$MFTont été modifiés mais que le miroir n'a pas encore été vidé sur disque (NTFS les maintient synchronisés mais il y a une petite fenêtre), le miroir contient l'état antérieur. Cette fenêtre est courte, des millisecondes en fonctionnement normal, mais sur un cas de défaillance soudaine, ça peut être la seule copie propre.
Au-delà de ces cas, traitez $MFTMirr comme quelque chose que vous collectez en routine (KAPE le fait pour vous) et que vous avez rarement besoin de regarder.
Questions fréquentes
$MFTMirr est-il la même chose qu'une sauvegarde de toute la MFT ?
Non. Il ne contient que les premiers enregistrements (les fichiers de métadonnées système). Les fichiers utilisateurs ne sont pas miroités.
Puis-je parser $MFTMirr avec les mêmes outils que $MFT ?
Oui. Il est structurellement identique : même format d'enregistrement, même tableau fixup, mêmes attributs. Déposez-le sur le parser navigateur ou nourrissez-le à MFTECmd.
Puis-je supprimer ou déplacer $MFTMirr ?
Non. Comme $MFT, il est verrouillé pendant que Windows tourne. Désactiver entièrement le miroir n'est pas une opération supportée ; chkdsk refuserait le volume.
Que se passe-t-il si mon disque n'a pas de $MFTMirr ?
Il en a un. Chaque volume NTFS en a un, créé au moment du formatage. Si $MFTMirr est manquant ou illisible, le volume est gravement endommagé et chkdsk échouera.
Lectures complémentaires
- Microsoft, NTFS Reserved Files. Catalogue officiel des fichiers de métadonnées des 16 premiers enregistrements.
- Les notes sur $MFTMirr du projet linux-ntfs. Écrit pratique sur le rôle du miroir vu d'un implémenteur de parser.
- Brian Carrier, File System Forensic Analysis. Le chapitre sur les fichiers de métadonnées NTFS explique le chemin de récupération au moment du montage.