Die Master File Table, auf dem Datenträger als $MFT geschrieben, ist der Index, mit dem NTFS jede Datei und jedes Verzeichnis eines Volumes verwaltet. Sie ist die erste für Benutzer sichtbare Datei jeder NTFS-Partition, und jede andere Datei des Volumes — einschließlich der Tabelle selbst — besitzt darin mindestens einen Eintrag. Das Lesen von $MFT ist genau der Weg, über den Forensik-Werkzeuge Fragen zu Dateien beantworten, deren Existenz Windows nicht mehr eingesteht: wann sie angelegt wurden, wie sie hießen, was sie enthielten und wer sie zuletzt angefasst hat.
Dieser Leitfaden ist eine vollständige Referenz. Er behandelt, was die Tabelle ist, wie Einträge aufgebaut sind, welche Attribute ein Eintrag tragen kann, die kleine Menge reservierter Systemdateien am Anfang der Tabelle, was „Windows kann die Master File Table nicht wiederherstellen" tatsächlich bedeutet und wie Sie $MFT mit dem Parser dieser Seite selbst lesen.
Was ist die Master File Table?
Die Master File Table ist eine einzelne Datei namens $MFT, die an einer festen Position nahe dem Anfang jedes NTFS-Volumes liegt. NTFS — New Technology File System — wurde mit Windows NT 3.1 im Jahr 1993 eingeführt und löste FAT als Standard-Dateisystem von Windows ab. Im Gegensatz zu FAT, das eine kleine Allokationstabelle führt und Dateinamen in Verzeichniseinträgen ablegt, bündelt NTFS nahezu alle Metadaten jeder Datei in einer einzigen strukturierten Tabelle: $MFT.
Jede Zeile dieser Tabelle ist ein Eintrag von exakt 1.024 Byte Länge. Jeder Eintrag beschreibt eine Datei oder ein Verzeichnis. Er enthält den Dateinamen, die Zeitstempel, die DOS-artigen Flags, die Liste der Disk-Cluster, in denen die Daten liegen, die Sicherheitsdeskriptoren und eine Handvoll weiterer Attribute — alles als kleines Bündel typisierter Felder codiert.
Dieser Aufbau hat zwei wesentliche Konsequenzen:
- Alle Metadaten liegen an einem Ort. Ein einziger Zugriff auf
$MFTgenügt, um jede Datei des Volumes aufzulisten. Forensik- und Recovery-Tools sind darauf angewiesen; ebenso Virenscanner und Indexdienste. - Gelöschte Dateien hinterlassen intakte Metadaten. Wenn NTFS eine Datei löscht, wird ein Bit im Eintrags-Header gelöscht und die Cluster der Datei werden als frei markiert. Der Rest des Eintrags — Name, Zeitstempel, oft auch die Data Runs — bleibt erhalten, bis der Eintragsslot wiederverwendet wird.
Das Akronym MFT steht für Master File Table. Sie werden es als MFT, $MFT oder die MFT geschrieben sehen. Alle Schreibweisen verweisen auf dieselbe On-Disk-Struktur.
Wie $MFT auf der Platte angeordnet ist
Wenn NTFS ein Volume formatiert, reserviert es nahe dem Anfang der Partition einen Bereich namens MFT-Zone. Der Boot-Sektor an Offset 0 des Volumes enthält einen Zeiger (das Feld MftStartLcn) auf den ersten Cluster von $MFT. Die ersten 16 Einträge der Tabelle sind für NTFS-Metadatendateien reserviert (siehe unten); Eintrag 0 ist der Eintrag der Tabelle selbst und verweist auf ihre eigenen Cluster.
$MFT wächst, indem sie sich in ihre reservierte Zone hinein ausdehnt, wann immer mehr Einträge benötigt werden. Füllt sich das Volume, bevor die Zone erschöpft ist, verkleinert Windows die Zone, um Platz für Benutzerdaten zu schaffen — weshalb eine stark fragmentierte $MFT ein typisches Symptom auf älteren Dateisystemen ist.
Eine Sicherung der ersten Einträge liegt in einer zweiten Datei, $MFTMirr, üblicherweise in der Mitte des Volumes. Ist $MFT selbst beschädigt, nutzt NTFS $MFTMirr, um die Wiederherstellung anzustoßen — das ist der Mechanismus hinter der weiter unten beschriebenen Fehlermeldung „Windows kann die Master File Table nicht wiederherstellen".
Anatomie eines FILE-Eintrags
Jeder MFT-Eintrag beginnt mit der vier Byte langen ASCII-Signatur FILE. (Beschädigte Einträge verwenden stattdessen BAAD — ein bewusst von chkdsk gesetzter Grabstein.) Auf die Signatur folgt ein fester Header, anschließend ein Strom variabel langer Attribute.
Der Eintrags-Header enthält:
- Signatur —
FILEfür einen gültigen Eintrag,BAADfür einen Eintrag, denchkdsknicht reparieren konnte. - Update Sequence Number (USN) und Fixup-Array — ein kleiner Prüfsummen-Trick, mit dem NTFS abgerissene Schreibvorgänge erkennt. Die letzten beiden Bytes jedes 512-Byte-Blocks im Eintrag werden durch die USN ersetzt; die Originale werden im Fixup-Array hinterlegt. Beim Lesen prüft NTFS die USN und stellt die Originalbytes wieder her.
- Log-Sequenznummer — ein Verweis in
$LogFilefür die Crash-Recovery. - Sequenznummer — wird bei jeder Wiederverwendung des Eintrags inkrementiert. Zusammen mit der Eintragsnummer bildet sie eine 64 Bit lange File Reference, die eine bestimmte Inkarnation einer Datei eindeutig identifiziert.
- Hard-Link-Zähler — Anzahl der
$FILE_NAME-Attribute, die auf den Eintrag zeigen. - Flags — das wichtigste ist Bit 0,
IN_USE. Ist es gelöscht, gilt der Eintrag als gelöscht. - Referenz auf den Basis-Eintrag — ungleich null bei Extension-Records, die zu einem anderswo in der Tabelle liegenden Basis-Eintrag gehören.
Nach dem Header folgen die Attribute. Jedes Attribut hat seinen eigenen kurzen Header (Typ, Länge, Resident/Non-Resident-Flag, Name falls vorhanden), gefolgt von den Daten. Es gibt keine feste Reihenfolge, aber $STANDARD_INFORMATION steht traditionell zuerst und $DATA zuletzt.
Ein Eintrag, 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 Extension-Records anderswo in der Tabelle verweist. Parser müssen der Kette folgen, um die vollständige Datei zusammenzusetzen.
In $MFT gespeicherte Dateiattribute
Das ist die häufigste Suche hinter dem Stichwort „welche Dateiattribute werden in der Master File Table gespeichert". Die vollständige 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, Security-ID, USN. |
| $ATTRIBUTE_LIST | 0x20 | Verweis auf Extension-Records, wenn die Attribute einer Datei einen einzelnen Eintrag sprengen. |
| $FILE_NAME | 0x30 | Ein Dateiname, Referenz auf das übergeordnete Verzeichnis, belegte und tatsächliche Größe sowie ein zweiter Satz von vier Zeitstempeln. Eine Datei kann mehrere haben — einen pro Hard-Link, einen für den 8.3-Kurznamen. |
| $OBJECT_ID | 0x40 | 128-Bit-Objektkennung, die vom Distributed Link Tracking Service verwendet wird. |
| $SECURITY_DESCRIPTOR | 0x50 | Klassische ACL pro Datei. Modernes NTFS speichert ACLs zentral in $Secure und referenziert sie per ID aus $STANDARD_INFORMATION. |
| $VOLUME_NAME | 0x60 | Nur auf Eintrag 3 ($Volume). Enthält die Volume-Bezeichnung. |
| $VOLUME_INFORMATION | 0x70 | NTFS-Version, Dirty-Flag. |
| $DATA | 0x80 | Der Dateiinhalt. Resident bei sehr kleinen Dateien; ansonsten non-resident (eine Liste von Cluster Runs). Eine Datei kann mehrere $DATA-Attribute tragen — das unbenannte ist der Hauptstream, die benannten sind alternative Datenströme. |
| $INDEX_ROOT | 0x90 | Wurzel eines B+-Baums. Wird von Verzeichnissen ($I30), Reparse-Point-Indizes und anderen indizierten Strukturen verwendet. |
| $INDEX_ALLOCATION | 0xA0 | Non-residente Fortsetzung eines großen Index. |
| $BITMAP | 0xB0 | Allokations-Bitmap für $MFT selbst oder für große Verzeichnisse. |
| $REPARSE_POINT | 0xC0 | Symlinks, Junctions, Mount Points, OneDrive-Platzhalter. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Erweiterte Attribute aus der OS/2-Ära. Auf modernem Windows selten. |
| $LOGGED_UTILITY_STREAM | 0x100 | EFS-Verschlüsselungsmetadaten ($EFS), TxF-Transaktionsdaten. |
Ein Eintrag trägt immer mindestens $STANDARD_INFORMATION, einen $FILE_NAME und einen $DATA. Alles andere ist optional und feature-getrieben.
Residente vs. non-residente Daten
Die meisten $DATA-Attribute auf einem realen Volume sind non-resident: Der Attribut-Header trägt eine kompakte Liste von Cluster Runs (eine Start-LCN plus eine Länge, wiederholt), und die Bytes der Datei liegen anderswo auf der Platte. Der Attribut-Header selbst ist klein.
Ist die Datei klein genug — typischerweise unter ~700 Byte, nachdem die übrigen Attribute berücksichtigt sind — speichert NTFS die Bytes inline innerhalb des Eintrags. Das sind residente Daten, und sie sind eines der nützlichsten Artefakte der forensischen Arbeit: Der Inhalt einer kleinen, vor Wochen gelöschten Textdatei kann Byte für Byte noch in einem nicht allozierten $MFT-Eintrag liegen. Siehe resident-data für eine vertiefte Betrachtung.
NTFS-Metadatendateien in den ersten sechzehn Einträgen
Die ersten 16 Einträge von $MFT sind den eigenen Verwaltungsdateien von NTFS vorbehalten. Sie beginnen mit $, damit sie nicht mit Benutzernamen kollidieren. Die wichtigsten:
| Eintrag | Datei | Beschreibung |
|---------|-------|--------------|
| 0 | $MFT | Die Tabelle selbst. |
| 1 | $MFTMirr | Sicherung der ersten Einträge von $MFT. |
| 2 | $LogFile | Transaktionsprotokoll, das nach einem Absturz unvollständige Operationen rückgängig macht oder erneut anwendet. |
| 3 | $Volume | Volume-Bezeichnung und Dirty-Flag. |
| 4 | $AttrDef | Schema der gültigen Attributtypen. |
| 5 | . | Das Wurzelverzeichnis. |
| 6 | $Bitmap | Ein Bit pro Cluster des Volumes; verfolgt die Allokation. |
| 7 | $Boot | Kopie des Boot-Sektors. |
| 8 | $BadClus | Sparse-Datei, deren Runs auf jeden vom Dateisystem als defekt markierten Cluster zeigen. |
| 9 | $Secure | Zentraler Speicher für Sicherheitsdeskriptoren. |
| 10 | $UpCase | Unicode-Großbuchstaben-Mapping-Tabelle für den Namensvergleich ohne Groß-/Kleinschreibung. |
| 11 | $Extend | Verzeichnis mit neueren Systemdateien: $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
Das Änderungsprotokoll $UsnJrnl (unter $Extend) ist forensisch besonders wertvoll — es protokolliert jede Metadatenänderung des Volumes und ergänzt $MFT bei der Rekonstruktion von Zeitachsen. Siehe usn-journal.
Wenn $MFT versagt: Korruption und „Windows kann die Master File Table nicht wiederherstellen"
Die Fehlermeldung „Windows kann die Master File Table nicht wiederherstellen. CHKDSK wurde abgebrochen" erscheint, wenn chkdsk weder $MFT lesen noch auf $MFTMirr zurückgreifen kann. Wenn Sie diese Meldung sehen, hat NTFS seine eingebaute Selbstreparatur bereits ohne Erfolg versucht.
Häufige Ursachen:
- Versagendes physisches Medium. Defekte Sektoren in der MFT-Zone führen dazu, dass der Lesevorgang Müll zurückgibt. SMART-Daten bestätigen dies meist.
- Plötzlicher Stromausfall während einer metadatenlastigen Operation. Das Transaktionsprotokoll rollt diese normalerweise zurück, aber ein beschädigtes
$LogFilemacht den Rollback unmöglich. - Korruption auf Treiber- oder Filterebene. Fehlerhafte Disk-Encryption-Stacks, Dateisystem-Minifilter oder fehlerhafte Storage-Treiber können inkonsistente Einträge schreiben.
- Bösartige Überschreibungen. Wiper und einige Ransomware-Familien beschmieren
$MFTabsichtlich, um das Volume schwerer wiederherstellbar zu machen.
Die forensisch saubere Reaktion lautet:
- Stoppen Sie sofort jeden Schreibvorgang auf das Volume. Jeder weitere Schreibvorgang verringert die Chance auf Wiederherstellung.
- Erstellen Sie ein Image des Datenträgers mit FTK Imager,
ddoderddrescuean einen sauberen Speicherort. Prüfen Sie den Hash. - Arbeiten Sie am Image, nicht am Original. Probieren Sie
testdisk,R-Studiooder eine manuelle Analyse, die durch Signatur-Scan direkt auf dem Volume nachFILE-Einträgen sucht — selbst wenn der On-Disk-Zeiger auf$MFTverloren ist, sind die Einträge selbst meist noch erkennbar. - Wenn das Ziel darin besteht, das Volume wieder online zu bringen statt Daten wiederherzustellen, lassen Sie erst dann
chkdsk /fauf das Image los.
chkdsk /b auf einem schreibbaren Volume kann Bad-Cluster-Marker entfernen, kann aber auch Einträge verwerfen, die es nicht versteht. Führen Sie es am Original erst aus, nachdem Sie ein Image haben und entschieden haben, dass Verfügbarkeit wichtiger ist als forensische Treue.
Wie man $MFT liest
Es gibt drei realistische Optionen:
- MFTECmd (Eric Zimmerman) — ein Windows-CLI, das CSV im bodyfile-freundlichen Layout erzeugt, das die meisten Timeline-Tools erwarten. Der De-facto-Standard für Incident Responder.
omerbenamram/mft— ein Rust-Crate und CLI. Derselbe Parser, den diese Seite nutzt — sinnvoll, wenn Sie Analysen skripten oder in eine größere Pipeline einbetten wollen.- Der Browser-Parser dieser Seite — legen Sie
$MFTauf der Startseite ab, und derselbe Rust-Parser läuft als WebAssembly kompiliert vollständig in Ihrem Browser. Nichts wird hochgeladen. Praktisch, wenn Sie ohne Installation einen schnellen Blick werfen wollen oder wenn Richtlinien es verbieten, Beweismaterial in einen Cloud-Dienst zu senden.
Einen Vergleich der drei mit konkreten Vor- und Nachteilen finden Sie in mft-parser-tools. Praktische Workflows, die auf einer geparsten $MFT aufbauen, finden Sie in build-mft-timeline, deleted-files und extracting-mft.
Häufig gestellte Fragen
Wofür steht MFT?
MFT steht für Master File Table. Sie wird auf der Platte auch $MFT geschrieben, weil das Dollarzeichen unter NTFS den Namen von Metadatendateien voranstellt.
Wofür wird die Master File Table verwendet?
Sie ist der Index, mit dem NTFS jede Datei und jedes Verzeichnis eines Volumes findet. Jeder Eintrag speichert den Dateinamen, die Zeitstempel, die Sicherheitsinformationen, die Attribute und den Speicherort der Daten auf der Platte.
Welche Dateiattribute werden in der Master File Table gespeichert?
Mindestens trägt jeder Eintrag $STANDARD_INFORMATION (Zeitstempel, DOS-Flags), $FILE_NAME (Name und ein zweiter Satz Zeitstempel) und $DATA (Dateiinhalt oder Verweis darauf). Einträge können zudem $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA und $LOGGED_UTILITY_STREAM tragen, je nach Datei. Die vollständige Referenz steht in der Attributtabelle oben.
Wie groß ist die Master File Table?
Jeder Eintrag ist 1.024 Byte groß. Die Tabelle reserviert standardmäßig etwa 12,5 % des Volumes (die MFT-Zone), verbraucht aber nur den tatsächlich benötigten Platz. Ein Volume mit einer Million Dateien hat eine $MFT von rund 1 GB.
Ist $MFT dasselbe wie $MFTMirr?
Nein. $MFTMirr ist eine partielle Sicherung der ersten Einträge von $MFT, an anderer Stelle auf der Platte platziert, damit NTFS die Wiederherstellung anstoßen kann, wenn der Header der Haupttabelle beschädigt ist.
Wie repariere ich eine beschädigte Master File Table?
Erstellen Sie zuerst ein Image des Datenträgers. Führen Sie dann entweder chkdsk /f gegen das Image aus (schnell, kann Einträge verwerfen) oder verwenden Sie ein Recovery-Tool, das nach FILE-Signaturen scannt und die Tabelle aus rohen Clustern rekonstruiert (langsam, bewahrt mehr Beweise). Führen Sie chkdsk niemals auf dem Original-Volume aus, bevor Sie ein Image haben.
Kann ich $MFT unter Linux oder macOS lesen?
Ja. $MFT ist einfach eine Datei. Jeder Parser, der einen rohen $MFT-Dump akzeptiert, funktioniert auf jedem Betriebssystem — omerbenamram/mft, analyzeMFT, das Browser-Tool dieser Seite. Windows wird nur benötigt, um die Datei aus einem live gemounteten Volume zu extrahieren.