← Zurück zum Blog

Master File Table (MFT): die NTFS $MFT erklärt

· 11 Min. Lesezeit

$MFT ist der Index, den NTFS verwendet, um jede Datei und jedes Verzeichnis auf einem Volume zu erfassen. Es ist auch das aussagekräftigste einzelne Artefakt, das du von einer Windows-Maschine ziehen kannst. Jede andere Datei auf dem Volume, einschließlich der Tabelle selbst, hat mindestens einen Datensatz darin. Forensik-Tools beantworten knifflige Fragen zu Dateien, deren Existenz Windows nicht mehr eingesteht, weil die Datensätze das Löschen überleben. Threat Hunter verfolgen Persistenz über sie, weil Angreifer Dateien auf NTFS nicht verschieben können, ohne in sie zu schreiben. Wenn du jemals nur ein einziges Windows-Artefakt auf Byte-Ebene lernst, dann dieses.

Das ist die Referenz, die ich mir zu Beginn gewünscht hätte. Sie behandelt, was die Tabelle ist, wie ein Datensatz aussieht, welche Attribute ein Datensatz tragen kann, was die reservierten Systemdateien am Anfang bedeuten, was der gefürchtete Fehler "Windows kann die Master File Table nicht wiederherstellen" tatsächlich bedeutet und wie du die Tabelle selbst lesen kannst.

Was ist die Master File Table

$MFT ist eine Datei. Eine einzige Datei. Sie liegt an einem bekannten Offset nahe dem Anfang jedes NTFS-Volumes. Der Bootsektor an Offset 0 der Partition (die 512 Bytes des BIOS Parameter Blocks) enthält ein Feld namens MftStartLcn, das auf den ersten Cluster von $MFT zeigt. Lies diese 1.024 Bytes und du hast Datensatz 0, die Selbstbeschreibung der Tabelle.

Jede Zeile der Tabelle ist exakt 1.024 Bytes groß und beschreibt eine Datei oder ein Verzeichnis. Jeder Datensatz enthält den Namen, Zeitstempel, DOS-Flags, Verweis auf den Sicherheitsdeskriptor sowie entweder die Daten selbst (kleine Dateien) oder eine Liste von Disk-Clustern, in denen die Daten liegen (große Dateien), alles als Sequenz typisierter Attribute kodiert.

NTFS wurde mit Windows NT 3.1 im Jahr 1993 eingeführt und ist seit Windows XP das Standard-Windows-Dateisystem auf jeder festen Platte. Es ersetzte FAT, das eine kleine Zuordnungstabelle führt und Dateinamen in Verzeichniseinträgen speichert. NTFS legt nahezu jede Metainformation jeder Datei in eine einzige strukturierte Tabelle, $MFT. Diese Entwurfsentscheidung hat zwei Folgen, die man sich merken sollte:

  1. Alle Metadaten liegen an einem Ort. Ein einziger Seek auf $MFT zählt jede Datei auf dem Volume auf. Deshalb lesen Forensik-Tools, Antiviren-Engines, Indexierungsdienste und Backup-Software sie alle. Deshalb ist eine beschädigte $MFT auch ein viel größeres Problem als eine beschädigte FAT.
  2. Gelöschte Dateien hinterlassen ihre Metadaten. Beim Löschen einer Datei löscht NTFS ein Bit im Datensatzkopf und markiert die Cluster der Datei in $Bitmap als frei. Der Rest des Datensatzes (Name, Zeitstempel, oft die Daten) bleibt erhalten, bis dieser Datensatzplatz erneut belegt wird. Siehe was beim Löschen erhalten bleibt.

Das Akronym MFT steht für Master File Table. Auf der Platte als $MFT geschrieben, weil unter NTFS das Dollarzeichen den Namen von Metadatendateien vorangestellt wird.

Wie $MFT auf der Platte angelegt ist

Wenn NTFS ein Volume formatiert, reserviert es einen Bereich namens MFT-Zone nahe dem Anfang der Partition. Die ersten 16 Datensätze der Tabelle sind für NTFS-Metadatendateien reserviert (unten beschrieben); Datensatz 0 ist der Eintrag der Tabelle selbst und verweist auf ihre eigenen Cluster.

$MFT wächst, indem sie sich in ihre reservierte Zone ausdehnt, wenn sie mehr Datensätze benötigt. Wenn das Volume voll wird, bevor die Zone aufgebraucht ist, verkleinert Windows die Zone, um Platz für Benutzerdaten zu schaffen, weshalb eine stark fragmentierte $MFT auf alternden Dateisystemen üblich ist. Die Tabelle schrumpft nie. Sobald ein Platz angelegt wurde, bleibt er in $MFT; das Löschen löscht nur das In-Use-Flag. Deshalb können alte gelöschte Datensätze weit oberhalb der aktuellen High-Water-Mark auf einem wenig genutzten Volume jahrelang überleben.

Eine Sicherung der ersten Datensätze liegt in $MFTMirr, in der Mitte des Volumes platziert. Wenn $MFT selbst unlesbar ist, verwendet NTFS $MFTMirr zum Bootstrap der Wiederherstellung. Siehe $MFTMirr und wann NTFS es verwendet.

Anatomie eines FILE-Datensatzes

Jeder MFT-Datensatz beginnt mit der vier Byte langen ASCII-Signatur FILE (46 49 4C 45). Beschädigte Datensätze tragen stattdessen BAAD, einen Grabstein, den chkdsk hinterlässt, wenn er den Datensatz nicht reparieren konnte. Nach der Signatur folgt ein 56-Byte-Header, dann das Fixup-Array, dann ein Strom typisierter Attribute, der mit 0xFFFFFFFF endet.

Der Header trägt die Felder, auf die man am häufigsten zugreift:

  • Signatur. FILE für einen gültigen Datensatz, BAAD für nicht reparierbar.
  • Update-Sequence-Array (Fixup). Der Trick zur Erkennung zerrissener Schreibvorgänge. Die letzten zwei Bytes jedes 512-Byte-Blocks im Datensatz werden durch eine USN ersetzt; die Originale werden in diesem Array abgelegt. Beim Lesen verifiziert NTFS die USN und stellt die ursprünglichen Bytes wieder her.
  • $LogFile-Sequenznummer. Ein Verweis in $LogFile für die Crash-Recovery.
  • Sequenznummer. Wird jedes Mal inkrementiert, wenn der Datensatzplatz wiederverwendet wird. Kombiniert mit der Datensatznummer bildet sie die 64-Bit-Dateireferenz, die eine bestimmte Inkarnation einer Datei eindeutig identifiziert.
  • Anzahl der harten Links. Anzahl der $FILE_NAME-Attribute, die auf den Datensatz verweisen.
  • Flags. Bit 0 ist IN_USE (gelöscht, wenn nicht gesetzt). Bit 1 ist DIRECTORY.
  • Basis-Dateidatensatzreferenz. Bei Erweiterungsdatensätzen ungleich null, die zu einem Basisdatensatz an anderer Stelle in der Tabelle gehören.
  • Belegte und allozierte Größe. Belegt ist, wie viel des 1.024-Byte-Platzes dieser Datensatz tatsächlich nutzt; alloziert ist die Platzgröße (immer 1.024 auf Standardvolumes).

Für einen Byte-für-Byte-Rundgang durch Header und Attributstrom siehe Inneres eines MFT-Datensatzes.

Nach dem Header folgen die Attribute. Jedes hat seinen eigenen kurzen Header (Typ, Länge, Resident-/Nicht-Resident-Flag, optionaler Name), gefolgt von den Daten. Es gibt keine feste Reihenfolge, aber in der Praxis steht $STANDARD_INFORMATION zuerst und $DATA zuletzt. Ein Datensatz, dem der Platz ausgeht (zu viele Fragmente, zu viele ADS, ein ungewöhnlich langer Name), bekommt ein $ATTRIBUTE_LIST-Attribut, das auf einen oder mehrere Erweiterungsdatensätze an anderer Stelle in der Tabelle verweist. Parser müssen der Kette folgen, um die Datei zu rekonstruieren.

In $MFT gespeicherte Dateiattribute

Dies ist die kanonische Liste der NTFS-Attributtypen mit Hex-Codes:

| Typ | Hex | Zweck | |------|-----|---------| | $STANDARD_INFORMATION | 0x10 | Vier Zeitstempel (erstellt, geändert, zugegriffen, MFT-geändert), DOS-Flags, Besitzer-ID, Sicherheits-ID, USN-Verweis. | | $ATTRIBUTE_LIST | 0x20 | Verweise auf Erweiterungsdatensätze, wenn die Attribute einer Datei einen Datensatz überlaufen. | | $FILE_NAME | 0x30 | Ein Dateiname, Verweis auf das übergeordnete Verzeichnis, allozierte und tatsächliche Größe sowie ein zweites Set aus vier Zeitstempeln. Eine Datei kann mehrere haben (eines pro hartem Link, plus der 8.3-Kurzname auf Volumes, auf denen das aktiviert ist). | | $OBJECT_ID | 0x40 | 128-Bit-Objekt-Identifikator, der vom Distributed-Link-Tracking-Dienst verwendet wird. | | $SECURITY_DESCRIPTOR | 0x50 | Legacy-ACL pro Datei. Modernes NTFS speichert ACLs zentral in $Secure und referenziert sie per ID aus $STANDARD_INFORMATION. | | $VOLUME_NAME | 0x60 | Nur in Datensatz 3 ($Volume). Enthält das Volume-Label. | | $VOLUME_INFORMATION | 0x70 | NTFS-Version, Dirty-Flag. | | $DATA | 0x80 | Inhalt der Datei. Resident für sehr kleine Dateien; nicht-resident (eine Runliste von Clustern) sonst. Eine Datei kann mehrere $DATA-Attribute tragen; das unbenannte ist der Primärstream, benannte sind Alternate Data Streams. | | $INDEX_ROOT | 0x90 | Wurzel eines B+-Baums. Verwendet von Verzeichnissen ($I30), Reparse-Point-Indizes und anderen indizierten Strukturen. | | $INDEX_ALLOCATION | 0xA0 | Nicht-residente Fortsetzung eines großen Index. | | $BITMAP | 0xB0 | Allocation-Bitmap für $MFT selbst oder für große Verzeichnisse. | | $REPARSE_POINT | 0xC0 | Symlinks, Junctions, Mount-Punkte, OneDrive-Platzhalter, Dedup-Stubs. | | $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Erweiterte Attribute aus der OS/2-Ära. Selten unter modernem Windows. WSL1 nutzte sie für POSIX-Metadaten, der einzige Kontext, der erwähnenswert ist. | | $LOGGED_UTILITY_STREAM | 0x100 | EFS-Verschlüsselungsmetadaten ($EFS), TxF-Transaktionsdaten. |

Ein Datensatz trägt immer mindestens $STANDARD_INFORMATION, ein $FILE_NAME und ein $DATA. Alles andere ist optional und feature-getrieben.

Resident vs. nicht-resident

Die meisten $DATA-Attribute auf einem realen Volume sind nicht-resident: Der Attribut-Header trägt eine kompakte Liste von Cluster-Runs (eine Start-LCN plus Länge, wiederholt), und die Bytes der Datei liegen anderswo auf der Platte. Der Attribut-Header selbst ist klein.

Wenn die Datei klein genug ist (typischerweise unter ~700 Bytes, sobald die anderen Attribute berücksichtigt sind), speichert NTFS die Bytes inline im Datensatz. Das sind residente Daten, und es ist eines der nützlichsten Artefakte in der forensischen Arbeit: Der Inhalt einer kleinen Textdatei, die vor Wochen gelöscht wurde, kann immer noch Byte für Byte in einem unallozierten $MFT-Datensatz liegen. Siehe residente Daten für die Größenschwelle und wonach du suchen solltest.

NTFS-Metadatendateien in den ersten sechzehn Datensätzen

Die ersten 16 Datensätze von $MFT sind für die eigene Buchhaltung von NTFS reserviert. Sie beginnen mit einem $, damit sie nicht mit Benutzer-Dateinamen kollidieren. Die, die man kennen sollte:

| Datensatz # | Datei | Was es ist | |-------|------|------------| | 0 | $MFT | Die Tabelle selbst. Ihre $DATA-Runliste verweist auf ihre eigenen Cluster. | | 1 | $MFTMirr | Teilbackup der ersten Datensätze von $MFT. | | 2 | $LogFile | Transaktionsprotokoll zum Rückgängigmachen oder Wiederholen unvollständiger Operationen nach einem Absturz. | | 3 | $Volume | Volume-Label und Dirty-Flag. | | 4 | $AttrDef | Schema gültiger Attributtypen. | | 5 | . | Wurzelverzeichnis. | | 6 | $Bitmap | Ein Bit pro Cluster auf dem Volume; verfolgt die Allokation. | | 7 | $Boot | Kopie des Bootsektors. | | 8 | $BadClus | Sparse-Datei, deren Runs auf jeden Cluster zeigen, den das Dateisystem als defekt markiert hat. | | 9 | $Secure | Zentraler Speicher für Sicherheitsdeskriptoren. | | 10 | $UpCase | Unicode-Großbuchstaben-Zuordnungstabelle für den Vergleich von Namen ohne Berücksichtigung der Groß-/Kleinschreibung. | | 11 | $Extend | Verzeichnis mit neueren Systemdateien: $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |

Das Change Journal $UsnJrnl (unter $Extend) ist in der Forensik besonders nützlich; es protokolliert jede Metadatenänderung auf dem Volume und ergänzt $MFT für die Timeline-Rekonstruktion. Siehe Journal mit der Dateitabelle koppeln.

Wenn $MFT schiefgeht

Der Fehler "Windows kann die Master File Table nicht wiederherstellen. CHKDSK abgebrochen" erscheint, wenn chkdsk $MFT nicht lesen kann und auch nicht auf $MFTMirr zurückgreifen kann. Zu diesem Zeitpunkt hat NTFS bereits seine eingebaute Selbstreparatur erfolglos versucht. Die Ursachen, die ich gesehen habe, geordnet danach, wie oft sie tatsächlich vorkommen:

  • Versagende physische Medien. Defekte Sektoren in der MFT-Zone liefern beim Lesen Müll. SMART-Daten bestätigen das meistens. Image die Platte mit ddrescue, nicht mit dd, und arbeite am Image.
  • Plötzlicher Stromausfall während einer metadatenlastigen Operation. Das Transaktionsprotokoll macht solche Dinge normalerweise rückgängig, aber ein beschädigtes $LogFile vereitelt das.
  • Treiber- oder Filter-Level-Korruption. Fehlfunktionierende Disk-Encryption-Stacks, Dateisystem-Minifilter oder fehlerhafte Storage-Treiber können inkonsistente Datensätze schreiben. Häufig auf Hosts mit mehreren um sich schlagenden Security-Agents.
  • Bösartiges Überschreiben. Wiper und einige wenige Ransomware-Familien (insbesondere Petya und die frühe NotPetya-Welle) kritzeln gezielt auf $MFT, um das Volume nicht mountbar zu machen. Siehe Ransomware-Muster in MFT.

Die forensisch korrekte Reaktion:

  1. Sofort aufhören, auf das Volume zu schreiben. Jeder weitere Schreibvorgang verringert die Wiederherstellungschance.
  2. Image die Platte mit FTK Imager, dd oder ddrescue an ein bekanntes Ziel. Verifiziere den Hash.
  3. Arbeite am Image, nicht am Original. Probiere testdisk, R-Studio oder einen manuellen Parse, der FILE-Datensätze durch Signatur-Scan direkt auf dem Volume findet. Selbst wenn der On-Disk-Verweis auf $MFT weg ist, sind die Datensätze selbst meist noch erkennbar.
  4. Wenn das Ziel ist, das Volume wieder online zu bringen statt Daten zu retten, dann erst chkdsk /f am Image ausführen.

chkdsk /b auf einem beschreibbaren Volume kann Bad-Cluster-Markierungen löschen, aber es kann auch Datensätze verwerfen, die es nicht versteht. Führe es nur am Original aus, nachdem du ein Image hast und entschieden hast, dass Verfügbarkeit wichtiger als forensische Genauigkeit ist.

Wie man $MFT liest

Du hast drei realistische Optionen:

  • MFTECmd (Eric Zimmerman). Eine Windows-CLI, die CSV im Bodyfile-freundlichen Layout produziert, das die meisten Timeline-Tools erwarten. Der De-facto-Standard für Incident Responder.
  • omerbenamram/mft. Eine Rust-Crate und CLI (mft_dump). Der Parser, den diese Seite verwendet, nützlich wenn du Analysen skripten oder in eine größere Pipeline einbetten willst.
  • Der Browser-Parser dieser Seite. Lege $MFT auf der Startseite ab und sie führt denselben Rust-Parser aus, zu WebAssembly kompiliert, vollständig in deinem Browser. Nichts wird hochgeladen.

Für einen Vergleich mit konkreten Vor- und Nachteilen siehe MFT-Parser-Tools. Für praktische Workflows auf einer geparsten $MFT siehe eine Timeline erstellen, gelöschte Dateien und $MFT extrahieren.

Häufig gestellte Fragen

Wofür steht MFT?

MFT steht für Master File Table. Auf der Platte als $MFT geschrieben, weil unter NTFS das Dollarzeichen den Namen von Metadatendateien vorangestellt wird.

Wofür wird die Master File Table verwendet?

Sie ist der Index, den NTFS verwendet, um jede Datei und jedes Verzeichnis auf einem Volume zu finden. Jeder Eintrag speichert Name, Zeitstempel, Sicherheitsinformationen, Attribute der Datei sowie den Speicherort ihrer Daten auf der Platte.

Welche Dateiattribute werden in der Master File Table gespeichert?

Mindestens trägt jeder Datensatz $STANDARD_INFORMATION (Zeitstempel, DOS-Flags), $FILE_NAME (Name und ein zweites Set Zeitstempel) und $DATA (Inhalt der Datei oder ein Verweis darauf). Datensätze können auch $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA und $LOGGED_UTILITY_STREAM enthalten, je nach Datei. Die vollständige Referenz steht in der Attributtabelle oben.

Wie groß ist die Master File Table?

Jeder Datensatz ist 1.024 Bytes. Die Tabelle reserviert standardmäßig etwa 12,5 % des Volumes (die MFT-Zone), nutzt aber nur den tatsächlich benötigten Platz. Ein Volume mit einer Million Dateien hat etwa eine 1 GB große $MFT.

Ist $MFT dasselbe wie $MFTMirr?

Nein. $MFTMirr ist ein Teilbackup der ersten paar Datensätze von $MFT, an anderer Stelle auf der Platte platziert, sodass NTFS die Wiederherstellung bootstrapen kann, wenn der Header der Haupttabelle beschädigt ist.

Wie behebe ich eine beschädigte Master File Table?

Image zuerst die Platte. Dann entweder chkdsk /f gegen das Image ausführen (schnell, kann Datensätze verwerfen) oder ein Recovery-Tool verwenden, das nach FILE-Signaturen scannen und die Tabelle aus rohen Clustern wieder zusammensetzen kann (langsam, bewahrt mehr Beweise). Führe niemals chkdsk am Originalvolume aus, bevor du es geimaget hast.

Kann ich $MFT unter Linux oder macOS lesen?

Ja. $MFT ist nur eine Datei. Jeder Parser, der einen rohen $MFT-Dump akzeptiert, funktioniert auf jedem OS: omerbenamram/mft, analyzeMFT, das Browser-Tool dieser Seite. Du brauchst Windows nur, um die Datei aus einem live gemounteten Volume zu extrahieren.

Weiterführende Literatur

Verwandte Artikel

Externe Ressourcen