Was $MFTMirr tatsächlich tut und wann NTFS es verwendet

$MFTMirr ist die kleinste Versicherungspolice in NTFS. Es spiegelt die ersten Datensätze von $MFT, damit, wenn die Bytes am Anfang der Haupttabelle unlesbar sind, der Dateisystemtreiber immer noch einen Weg hat, jede Datei auf dem Volume zu finden. Es ist auch das Artefakt, das Leute zu erwerben vergessen und dann drei Wochen später brauchen.

Das ist das, was es tatsächlich enthält, wo es auf der Platte liegt, wann NTFS es verwendet, und die (begrenzten) Fälle, in denen es sich in der Forensik bezahlt macht.

Warum überhaupt ein Spiegel existiert

Die ersten Datensätze von $MFT sind tragend. Datensatz 0 ist $MFT selbst, mit einer $DATA-Runliste, die sagt, wo der Rest der Tabelle auf der Platte lebt. Datensatz 2 ist $LogFile. Datensatz 3 ist $Volume. Wenn die Bytes am Anfang von $MFT beschädigt sind, kann NTFS keine der anderen Dateien auf dem Volume finden, einschließlich des Transaktionsprotokolls, das es normalerweise zur Wiederherstellung von Dateisystem-Inkonsistenzen verwenden würde.

Das ist eine zirkuläre Abhängigkeit: Du brauchst $MFT, um $LogFile zu finden, aber du brauchst $LogFile, um $MFT zu reparieren. Der Spiegel bricht den Zyklus. $MFTMirr ist eine separate Datei an einem anderen physischen Ort, die ein Duplikat dieser ersten Datensätze hält. Wenn der Treiber ein Volume mountet, liest er Datensatz 0 von $MFT; wenn dieses Lesen fehlschlägt oder das Fixup-Array nicht verifiziert, fällt er auf Datensatz 0 von $MFTMirr zurück und verwendet das Duplikat, um den Rest neu zu finden.

Wo es lebt

$MFTMirr ist MFT-Datensatz 1. Sein $DATA-Attribut ist nicht-resident, und seine Runliste verweist traditionell auf die Mitte des Volumes, damit ein einzelner lokalisierter Fehler (ein defekter Sektor, ein zerrissener Schreibvorgang über einen Bereich) nicht beide Kopien auslöschen kann. Modernes NTFS platziert es bei LCN clusterCount / 2. Auf einem 500-GB-Volume ist das ungefähr bei der 250-GB-Marke.

Du kannst es von einem Live-System aus finden:

fsutil file queryextents C:\$MFTMirr

Das gibt die Cluster-Runs zurück, die $MFTMirr belegt, die ein roher Read wieder zusammensetzen kann. KAPEs MFT-Target sammelt es standardmäßig zusammen mit $MFT. Wenn du FTK Imager verwendest, liegt es neben $MFT in der Wurzel des NTFS-Volumes.

Was es enthält

Bit-für-Bit-Kopien der ersten MFT-Datensätze. Die historische Garantie waren die ersten vier Datensätze (0 bis 3, die wirklich essenziellen Metadaten). Aktuelle Windows-Versionen spiegeln die ersten sechzehn, was dem gesamten NTFS-Metadatensatz entspricht, der in der Master-File-Table-Referenz beschrieben ist.

Jede Kopie ist ein normaler MFT-Datensatz. Gleiche FILE-Signatur, gleicher Header, gleiches Fixup-Array, gleicher Attributstrom. Ein Parser, der auf $MFTMirr zeigt, durchläuft sie genau wie er $MFT durchläuft. MFTECmd, mft_dump, analyzeMFT und Sleuth Kits fls akzeptieren es alle als Eingabe.

Wie NTFS es beim Mounten verwendet

Bei einem gesunden Mount fasst der Treiber $MFTMirr nicht an. Bei einem beschädigten Mount:

1. Datensatz 0 von $MFT lesen.
2. Wenn das Lesen einen I/O-Fehler zurückgibt oder die Fixup-Verifikation fehlschlägt, stattdessen Datensatz 0 von $MFTMirr lesen.
3. Wenn die Kopie des Spiegels von Datensatz 0 gültig ist, deren $DATA-Runliste verwenden, um $MFT auf der Platte zu finden, und fortfahren.

Der Spiegel muss $MFT nicht ersetzen. Er muss nur genug Informationen liefern, um die echte zu finden. Nachdem der Treiber $MFT aus dem Verweis des Spiegels lokalisiert hat, fährt er mit der Live-Tabelle fort.

Wie chkdsk es verwendet

chkdsk ist aggressiver. Wenn er Korruption in den ersten Datensätzen von $MFT erkennt, vergleicht er jeden Datensatz mit dem Spiegel. Wenn beide Kopien gültig sind, aber abweichen, behandelt chkdsk den Spiegel als autoritativ für die ersten paar kritischen Datensätze (mit der Annahme, dass die Live-Datensätze später aktualisiert und dabei beschädigt wurden).

Wenn $MFT unlesbar ist und der Spiegel unlesbar ist, meldet chkdsk Windows kann die Master File Table nicht wiederherstellen. CHKDSK abgebrochen. An diesem Punkt erfordert die Wiederherstellung Offline-Tools: Signatur-Carving für FILE-Datensätze über das rohe Volume mit Sleuth Kit, R-Studio oder testdisk. NTFS' eingebaute Selbstreparatur ist erschöpft.

Warum $MFTMirr kein vollständiges Backup ist

Es spiegelt nur die Metadatendateien. Datensätze 16 und höher, also jede Benutzerdatei und jedes Verzeichnis, existieren nur in $MFT. Wenn $MFT über Datensatz 16 hinaus beschädigt ist, kann der Spiegel dir nicht helfen. Der Spiegel reicht aus, um das Volume zu mounten; das Wiederherstellen beliebiger Dateien aus Schäden erfordert die gleichen Techniken, die du ohne ihn verwenden würdest.

Das ist das Missverständnis, das Leute in IR-Engagements Zeit kostet. Sie greifen zu $MFTMirr und denken, es sei ein vollständiger historischer Snapshot. Ist es nicht. Dafür willst du Volume Shadow Copies, die jeweils eine tatsächliche Punkt-in-Zeit-Kopie der vollständigen $MFT enthalten.

Forensisches Interesse

$MFTMirr ist selten das primäre Artefakt in einem Fall, aber es hat zwei echte Verwendungen:

• Querprüfung. Datensätze 0 bis 15 im Spiegel sollten bitweise mit den Live-Datensätzen übereinstimmen. Eine Divergenz deutet darauf hin, dass eine Seite außerhalb der Reihe modifiziert wurde: ein Treiber-Bug, vorsätzliche Manipulation, partielle Wiederherstellung nach einem Crash oder ein schlecht geschriebener Wiper, der auf der Live-MFT herumkritzelte und den Spiegel verfehlte. Ich habe genau einen Fall gesehen, in dem der Spiegel einen Wiper erwischt hat, der die ersten 16 Datensätze von $MFT überschrieb und nicht merkte, dass eine Kopie woanders auf dem Volume lebte. Die Rekonstruktion funktionierte, weil der Spiegel intakt war.
• Pre-Korruption-Snapshot. Wenn die Live-$MFT-Datensätze modifiziert wurden, aber der Spiegel noch nicht geflusht wurde (NTFS hält sie synchron, aber es gibt ein kleines Fenster), hält der Spiegel den älteren Zustand. Dieses Fenster ist kurz, im normalen Betrieb Millisekunden, aber in einem plötzlichen Ausfallfall kann es die einzige saubere Kopie sein.

Außerhalb dieser Fälle behandle $MFTMirr als etwas, das du routinemäßig sammelst (KAPE macht es für dich) und selten anschauen musst.

Häufig gestellte Fragen

Ist $MFTMirr dasselbe wie ein Backup der gesamten MFT?

Nein. Es enthält nur die ersten paar Datensätze (die System-Metadatendateien). Benutzerdateien werden nicht gespiegelt.

Kann ich $MFTMirr mit denselben Tools wie $MFT parsen?

Ja. Es ist strukturell identisch: gleiches Datensatzformat, gleiches Fixup-Array, gleiche Attribute. Lege es auf den Browser-Parser oder füttere es an MFTECmd.

Kann ich $MFTMirr löschen oder verschieben?

Nein. Wie $MFT ist es gesperrt, während Windows läuft. Den Spiegel vollständig zu deaktivieren ist keine unterstützte Operation; chkdsk würde das Volume ablehnen.

Was passiert, wenn meine Platte kein $MFTMirr hat?

Hat sie. Jedes NTFS-Volume hat eines, beim Formatieren erstellt. Wenn $MFTMirr fehlt oder unlesbar ist, ist das Volume schwer beschädigt und chkdsk wird scheitern.

Weiterführende Literatur

• Microsoft, NTFS Reserved Files. Offizieller Katalog der Metadatendateien in den ersten 16 Datensätzen.
• Die $MFTMirr-Notizen des linux-ntfs-Projekts. Praktische Ausarbeitung der Rolle des Spiegels aus der Sicht eines Parser-Implementierers.
• Brian Carrier, File System Forensic Analysis. Kapitel über NTFS-Metadatendateien erklärt den Wiederherstellungspfad zum Mount-Zeitpunkt.