NTFS-Metadaten nach einer Schnellformatierung: Eine WinHex-Analyse

NTFS-Metadaten nach einer Schnellformatierung beschreiben ein neu initialisiertes Dateisystem, während einige Datensätze und Dateiinhalte des vorherigen Dateisystems darunter möglicherweise weiterhin lesbar sind. Windows erstellt eine neue Master-Dateitabelle und eine neue Verzeichnisstruktur; es werden nicht einfach alle alten Dateinamen ausgeblendet. Die Wiederherstellung gelingt, wenn genügend ursprüngliche Metadaten und die darin beschriebenen Daten erhalten geblieben und weiterhin zugänglich sind.
WinHex hilft dabei, diese Fälle voneinander zu unterscheiden, indem es Felder des Bootsektors, MFT-Datensätze und Zuordnungen von Datenblöcken anzeigt. Dieser Artikel befasst sich mit einem Fall einer Schnellformatierung von NTFS auf NTFS sowie einem separaten Beispiel zur Rekonstruktion von MFT-Fragmenten. Die Berechnungen beziehen sich auf die aufgezeichneten Layouts und nicht auf jedes Windows-Volume. Das „Discard“-Verhalten von SSDs und nachfolgende Schreibvorgänge können zu sehr unterschiedlichen Ergebnissen führen.
Inhaltsübersicht
1. Welche Änderungen nimmt die Schnellformatierung bei NTFS vor?
Die NTFS-Dateisystem organisiert Dateien mithilfe von Metadaten, Verzeichnisindizes und Clusterzuordnungen. Bei einer Schnellformatierung wird eine neue Instanz dieser Strukturen erstellt.
Struktur | Rolle nach der Schnellformatierung | Auswirkungen auf die Genesung |
Volume-Bootsektor und dessen Sicherung | Beschreiben Sie das neu formatierte Laufwerk | Aktuelle MFT-Zeiger können die alte Tabelle möglicherweise nicht mehr finden. |
$MFT und Stammverzeichnis | Beschreiben Sie das neue Dateisystem und seine ersten Objekte. | Alte Dateinamen und Verzeichnisbeziehungen verschwinden beim normalen Durchsuchen |
| Verfolgt die in der neuen MFT zugewiesenen Datensätze | Erfasst keine erhaltenen Datensätze außerhalb dieser Tabelle |
$Bitmap | Verfolgt die im neuen Volume zugewiesenen Cluster | Zuvor belegte Cluster können für die Wiederverwendung freigegeben werden |
$MFTMirr und andere Systemmetadaten | Unterstützung des neu initialisierten Dateisystems | Ihre Schreibvorgänge können ältere Metadaten oder Dateiinhalte überschreiben. |
Frühere Speicherorte der Dateidaten | Es können lesbare Inhalte außerhalb überschriebener oder verworfener Bereiche erhalten bleiben | Man sollte die Lebensfähigkeit überprüfen, anstatt sie einfach vorauszusetzen. |
Die Stammdatentabelle ist selbst eine Datei. Ihr unbenannter $DATA-Stream enthält Dateisätze; ihre Bitmap beschreibt die Zuordnung der Datensätze. Die separate Datei „$Bitmap“ beschreibt die Clusterzuordnung über das gesamte Volume hinweg. Werden diese beiden Bitmaps verwechselt, führt dies zu falschen Schlussfolgerungen darüber, was erhalten geblieben ist.
Das Formatieren einer bestehenden Partition unterscheidet sich zudem vom Löschen ihres Eintrags in der Partitionstabelle. Bei einer Routine-Volumenformatierung wird das Dateisystem innerhalb des ausgewählten Volumens neu aufgebaut; das Löschen einer Partition betrifft hingegen die Festplattenstruktur außerhalb dieses Volumens.
2. Den ursprünglichen Bootsektor in WinHex lesen
Für einen Hexadezimalvergleich vor und nach einer NTFS-Formatierung sollten Sie vor der Formatierung ein Sektorabbild erstellen und dieses mit einem anschließend erstellten Abbild vergleichen. Bei einem bereits formatierten Quellmedium sollten Sie auf der Grundlage eines Abbilds und etwaiger früherer Erfassungen arbeiten. Wiederholen Sie die Formatierung nicht, um das Ereignis nachzustellen.
Die Volume-Boot-Record stellt die Parameter bereit, die zur Interpretation von Cluster-Adressen benötigt werden.

Original-Hex-Auszug des Bootsektors aus der WinHex-Fallakte. Die roten Kästchen kennzeichnen die Felder für Sektorgröße, Clustergröße und MFT-Position.
Offset des Bootsektors | Aufgezeichnete Bytes | Auslegung |
|
| 512 Byte pro logischem Sektor |
|
| Acht Sektoren pro Cluster |
|
| $MFT beginnt bei LCN 175.724.968 |
|
| $MFTMirr beginnt bei LCN 167.336.228 |
|
| Vorzeichenbehafteter Wert −10: Die Datensatzgröße beträgt 2¹⁰ = 1.024 Byte |
Multibyte-Ganzzahlen verwenden die Little-Endian-Byte-Reihenfolge. Die Größe der Zuordnungseinheit lautet daher:
- 512 × 8 = 4.096 Byte pro Cluster
LCN bezeichnet eine Cluster-Nummer, die sich auf das Volume bezieht. Daraus folgt:
- Ursprünglicher volumenrelativer Sektor des MFT = 175.724.968 × 8
- = 1,405,799,744
- Ursprünglicher volumenrelativer Byte-Offset der MFT = 175.724.968 × 4.096
- = 719,769,468,928
Bei der Untersuchung eines Images der gesamten Festplatte muss der Start-Byte-Offset des Volumes addiert werden. Bei der Untersuchung eines Images, das nur ein Volume umfasst, darf dieser nicht erneut addiert werden. Der von WinHex angezeigte Adressierungskontext muss mit der Berechnung übereinstimmen.
Der Bootsektor identifiziert den ersten MFT-Extent. Er beschreibt nicht jedes einzelne Fragment der Tabelle.
3. Die Daten zu nicht ansässigen Personen aus der ursprünglichen MFT entschlüsseln
Überprüfen Sie am ursprünglichen MFT-Speicherort den Datensatz 0 und suchen Sie dessen unbenanntes Attribut „$DATA“. Geben Sie Folgendes ein: 0x80. Ein „Nonresident“-Attribut speichert im Datensatz keine vollständigen Inhalte, sondern lediglich Zuordnungsinformationen.
In den Fallnotizen wird dieses Attribut auf den Datensatz-Offset gesetzt 0x100. Dadurch erscheint das Form-Byte an der Stelle 0x108; der Wert 01 bedeutet „nicht ansässig“. Diese absoluten Versätze gehören zu diesem Datensatz. In anderen Datensätzen kann das Attribut an einer anderen Stelle stehen.
Verwenden Sie bei der Interpretation eines anderen Datensatzes Offsets relativ zum Beginn des Attributs:
Relativer Versatz | Feld |
| Formular für Gebietsansässige/Gebietsfremde |
| Niedrigste virtuelle Cluster-Nummer (VCN) |
| Höchster VCN, einschließlich |
| Versatz zum Array der Zuordnungspaare |
| Zugewiesene Länge |
| Logische Dateigröße |
| Gültige Datenlänge |
Lesen Sie die drei Größenfelder separat aus. Die zugewiesene Länge reserviert Speicherplatz, die logische Größe definiert die Stream-Länge und die gültige Datenlänge beschreibt die initialisierten Daten. Sie müssen nicht gleich sein.

Für den Bereich der VCNs 0–98.431 beträgt die Clusteranzahl 98.432 und nicht 98.431. Das aufgezeichnete Zwei-Lauf-Layout ergibt:
Laufen lassen | Anzahl der Cluster | Signiert: LCN delta | LCN starten | Logische Datensatzplätze mit jeweils 1.024 Byte |
1 | 75,096 | +175,724,968 | 175,724,968 | 0–300,383 |
2 | 23,336 | +83,118,309 | 258,843,277 | 300,384–393,727 |
Die zweite Adresse bezieht sich auf den vorangegangenen Durchlauf. Beginn LCN:
- 175,724,968 + 83,118,309 = 258,843,277
- (75.096 + 23.336) × 4.096 = 403.177.472 Byte
- 403.177.472 ÷ 1.024 = 393.728 Datensatzplätze
Es handelt sich hierbei um adressierbare Speicherplätze, nicht um die Anzahl der aktiven Dateien. Einige Datensätze sind möglicherweise ungenutzt, und eine Datei kann mehrere Datensätze erfordern.
Die aufgezeichneten Laufüberschriften 43 und 42 Feldbreiten beschreiben. Für 43, die Länge nimmt drei Bytes ein und das LCN-Delta vier; für 42, wobei die Länge zwei Bytes und das Delta vier Bytes einnimmt. Das LCN-Delta ist als vorzeichenbehaftet zu interpretieren, da spätere Fragmente auf dem Datenträger an einer früheren Position liegen können.
Die sich daraus ergebende Ausdehnungslänge beträgt 384,5 MiB. Eine gerundete Anzeige von “385 MB” kann weder eigenständig eine abweichende Zuweisungsgröße begründen noch beweisen, dass zusätzliche Cluster reserviert wurden.
4. Vergleichen Sie das neue MFT mit dem alten Layout
In den Fallnotizen ist eine MFT im Post-Format vermerkt, die bei LCN 786.432 beginnt und eine Ausdehnung von 180 Clustern aufweist. Unter der Annahme einer Clustergröße von 4.096 Byte:
- Start-Byte-Offset des neuen MFT = 786.432 × 4.096
- = 3,221,225,472
- Neue Größe des Extents = 180 × 4.096 = 737.280 Byte
Der neue Startpunkt liegt 3 GiB innerhalb des Volumes. Diese Adresse ergibt sich aus diesem konkreten Fall und ist kein zwingend vorgeschriebener NTFS-Speicherort.

Eigenschaft | Ursprüngliches Layout | Das Layout des Post-Formats ist in den Notizen festgehalten |
MFT LCN starten | 175,724,968 | 786,432 |
Erfasste MFT-Extents | Zwei | Eins |
Umfang der Deckung | 98.432 Cluster | 180 Cluster |
Kapazität bei der angegebenen Datensatzgröße | 393.728 Spielautomaten | 720 Spielautomaten |
In den Anmerkungen werden außerdem die Datensätze 0–717 erwähnt. Das sind 718 Datensätze oder 735.232 Byte. Dies ist mit einer Zuweisung vereinbar, die groß genug für 720 Slots ist, lässt jedoch offen, ob sich die Zahl 718 auf die logische Länge, die initialisierte Länge oder die geprüften Datensätze bezieht. Für diese Felder sind die zugrunde liegenden Attribut-Bytes erforderlich.
Die wesentliche Änderung besteht darin, dass Windows nun der neuen Tabelle folgt. Die geringere Größe der neuen MFT bewirkt, dass nicht bedeutet, dass die alte Tabelle an Ort und Stelle physisch gekürzt wurde. Ihre früheren Speicherorte müssen separat überprüft werden.
Um festzustellen, ob die NTFS-MFT durch das Formatieren überschrieben wurde, vergleichen Sie die ursprünglichen MFT-Extents mit allen neuen Metadatenschreibvorgängen und späteren Zuweisungen. Ein geänderter Zeiger belegt eine geänderte Referenz; ein Byte-Vergleich belegt das Überschreiben an einer bestimmten Stelle. Eine Verschiebung allein belegt weder das vollständige Fortbestehen noch den vollständigen Verlust.
5. Rekonstruktion einer fragmentierten MFT anhand erhaltener Aufzeichnungen
Die MFT-Fragmentierung entsteht, wenn die Tabelle wächst und kein zusammenhängender Speicherplatz mehr verfügbar ist. NTFS reserviert eine MFT-Zone, um die Fragmentierung zu verringern, doch dies garantiert nicht, dass ein einziger Extent entsteht. Bei einer Vergrößerung können Fragmente vor oder nach dem aktuellen Extent zugewiesen werden.
Ein separates Rekonstruktionsbeispiel im Fallmaterial dokumentiert dieses Layout mit drei Durchläufen. Es darf nicht mit dem vorangegangenen Fall mit zwei Durchläufen kombiniert werden, als ob beide dieselbe Tabelle beschreiben würden.
Laufen lassen | Logische Datensatzplätze | LCN starten | Delta seit dem Start des vorherigen Durchlaufs | Cluster |
1 | 0–204,927 | 786,432 | +786,432 | 51,232 |
2 | 204,928–248,587 | 9,274,281 | +8,487,849 | 10,915 |
3 | 248,588–376,391 | 8,858,108 | −416.173 | 31,951 |

In jeden 4.096-Byte-Cluster passen vier 1.024-Byte-Slots. Dies erklärt beide Grenzen:
- 51.232 × 4 = 204.928 Plätze
- 204.928 + (10.915 × 4) = 248.588
- 9.274.281 − 416.173 = 8.858.108
Insgesamt umfassen die Durchläufe 94.098 Cluster bzw. 385.425.408 Byte. Der endgültige VCN-Wert beträgt 94.097.
Kandidatendatensätze suchen und überprüfen
In den Rekonstruktionsnotizen wird beschrieben, wie nach dem Datensatz 204.928 gesucht wurde, ein Kandidat als ungültig verworfen wurde und ein weiterer Kandidat gefunden wurde, der als gültig akzeptiert wurde. Eine übereinstimmende Nummer oder die DATEI Die Unterschrift allein reicht nicht aus.
Bei einem schreibgeschützten Image:
- Suche nach
DATEISignaturen, einschließlich Standorte außerhalb der aktuellen MFT. Bei einem Scan, der sich auf die neue Tabelle beschränkt, werden abgelöste Datensätze übersehen. - Überprüfen Sie die Datensatzgrenzen, die Datensatzlänge, die Attribut-Offsets und die Attributlängen.
- Überprüfen Sie das Array der Aktualisierungssequenz, bevor Sie die geschützten Datensatzbytes auswerten. Bei den aufgezeichneten 1.024-Byte-Datensätzen erstrecken sich die Prüfungen auf die Enden der beiden 512-Byte-Abschnitte.
- Laden Sie die gespeicherten Trailer-Wörter wieder in den Speicher des Parsers, bevor Sie Attribute über diese Grenzen hinweg analysieren; nehmen Sie keine Änderungen am Evidenzbild vor.
- Vergleichen Sie benachbarte Datensätze, gegebenenfalls deren Nummerierung, Namen, Verweise auf übergeordnete Datensätze und Sequenznummern. Verwerfen Sie unplausible oder veraltete Beziehungen.
Wenn ein erhaltener alter Datensatz 0 eine gültige Laufliste liefert, ist diese Zuordnung zu verwenden. Fehlt diese, bleibt die Rekonstruktion von Extents anhand von Datensatzsequenzen eine Hypothese, die weiterer Überprüfungen bedarf. Leere Datensätze in einem Bereich beweisen allein noch nicht, dass kein späteres Fragment existiert.
Die logische Tabelle separat wieder zusammenstellen
Kopieren Sie die validierten Extents in einer separaten Analysedatei in VCN-Reihenfolge. Sortieren Sie sie nicht nach aufsteigendem LCN: Der dritte Durchlauf oben liegt auf der Festplatte vor dem zweiten, folgt diesem jedoch logisch.
Für die Datensatznummer n, Datensatzgröße R, und Clustergröße C:
- VCN = floor(n × R ÷ C)
- Offset innerhalb des Clusters = (n × R) mod C
- LCN = LCN zu Beginn des Durchlaufs + (VCN − VCN zu Beginn des Durchlaufs)
Für den Datensatz 204.929 im Beispiel mit drei Durchläufen beträgt der VCN 51.232 und sein Offset innerhalb des Clusters 1.024 Byte. Seine volumenrelative Adresse lautet daher:
- 9.274.281 × 4.096 + 1.024 = 37.987.456.000 Byte
Diese Zuordnung liefert eine Adresse, keine Datei. Der Datensatz und die darin referenzierten Daten müssen noch überprüft werden.
6. Wiederherstellung des Dateiinhalts anhand der alten Attribute
Sobald ein erhaltener Datensatz verstanden wurde, bestimmt dessen Attribut „$DATA“ die Extraktionsmethode.
Daten zu den Einwohnern: Lesen Sie den Offset und die Länge des Attributwerts aus und exportieren Sie diesen Wert anschließend aus dem validierten, durch „Fixup“ wiederhergestellten Datensatz. Bei kleinen Dateien kann der Inhalt verloren gehen, wenn ihre MFT-Datensätze überschrieben werden, da sich der Inhalt dort befindet.
Allgemeine Daten zu Nichtansässigen: die dateieigene Runlist dekodieren, jeden Extent aus dem ursprünglichen Volume-Image lesen, die Bytes in VCN-Reihenfolge zusammenfügen und die Ausgabe auf die logische Dateigröße zuschneiden. Die MFT-Runlist lokalisiert Dateisätze; sie ersetzt jedoch nicht die Zuordnung von Dateidaten durch den jeweiligen Benutzer.
Beachten Sie die Verweise in $ATTRIBUTE_LIST, wenn Attribute in andere Datensätze hineinreichen. Für spärliche und komprimierte Datenströme gelten jeweils eigene Dekodierungsregeln. Für verschlüsselte Inhalte ist weiterhin das entsprechende Entschlüsselungsmaterial erforderlich. Eine einfache Verkettung reicht in diesen Fällen nicht aus.
Die Wiederherstellung von Verzeichnissen erfordert besondere Sorgfalt. Ein Dateiname kann erhalten bleiben, während das übergeordnete Verzeichnis nicht mehr existiert. Rekonstruieren Sie Pfade nur dort, wo Verweise und Sequenznummern übereinstimmen; andernfalls behalten Sie eine verwaiste Datei bei, anstatt eine Ordnerbeziehung zu erfinden.
Speichern Sie die extrahierten Dateien auf einem anderen physischen Gerät. Die Bearbeitung des neuen Bootsektors, sodass er auf eine alte MFT verweist, ist nicht gleichbedeutend mit der Wiederherstellung von Dateien: Zuordnungstabellen, Indizes, Systemdatensätze und andere Metadaten können zu verschiedenen Dateisysteminstanzen gehören.
7. Warum eine Genesung gelingen kann – und warum sie scheitern kann
Eine metadatenbasierte Wiederherstellung kann erfolgreich sein, da ein alter Datensatz die Identität, die logische Größe und die Datenzuordnungen einer Datei beibehält, während die zugeordneten Inhalte weiterhin lesbar bleiben. Ein Wiederherstellungstool kann diesen Beziehungen nachgehen, auch wenn Windows sie nicht mehr in seinem aktiven Namensraum enthält.
Fehlen Datensätze, kann das signaturbasierte Carving den Dateiinhalt manchmal direkt identifizieren. Dabei gehen in der Regel die ursprünglichen Dateinamen und die Verzeichnisstruktur verloren, und bei fragmentierten Dateien ist diese Methode weniger zuverlässig. X-Ways dokumentiert die Suche nach NTFS-Datensätzen außerhalb der aktuellen MFT getrennt von der Suche nach Datei-Headern, was diese unterschiedlichen Wiederherstellungsmethoden widerspiegelt.
Die Wiederherstellung wird erschwert, wenn neue Metadaten ursprüngliche Datensätze überlagern, spätere Dateien alte Cluster wiederverwenden oder Fragmentzuordnungen fehlen. Ein gültiger Dateiname ist kein Beweis für einen intakten Inhalt; eine erkennbare erste Seite oder ein erkennbarer Video-Header ist kein Beweis dafür, dass spätere Fragmente erhalten geblieben sind.
Bei SSDs kommt noch eine weitere Bedingung hinzu. Bei der Formatierung unter Windows können TRIM-/Löschbenachrichtigungen gesendet werden; Microsofts Format Die Dokumentation umfasst /NoTrim um sie zu unterdrücken. Hierbei handelt es sich um eine Formatierungsoption, nicht um eine Abhilfe nach einem Datenverlust. Je nach Gerät und Speicherpfad können verworfene Bereiche bereits dann keine ursprünglichen Bytes mehr zurückgeben, wenn in WinHex noch keine herkömmliche Überschreibung sichtbar ist. Die Schnellformatierung ist daher keine allgemeingültige Garantie für die Wiederherstellbarkeit.
8. Überprüfen Sie die extrahierten Daten, bevor Sie die Festplatte wiederverwenden.
Bewahren Sie das Quellbild und die Ausdehnungskarte bis zum Abschluss der Validierung auf. Einen praktischen Arbeitsablauf zum Scannen und Exportieren finden Sie unter Dateien von einer formatierten Festplatte wiederherstellen.
Vergleichen Sie die wiederhergestellten Dateien, sofern verfügbar, mit einer vor der Formatierung erstellten Bestandsliste. Vergleichen Sie Namen, Größen, Ordnerstrukturen und Hashwerte mit den bekannten Originalen. Wenn keine Referenz-Hashwerte vorliegen, öffnen Sie die Dokumente und überprüfen Sie deren Seiten, testen Sie Archive, betrachten Sie Bilder in voller Auflösung und spielen Sie vollständige Videodateien ab.
Erfassen Sie beschädigte oder fehlende Dateien getrennt von den verifizierten Dateien. Eine ohne Parsing-Fehler rekonstruierte MFT liefert lesbare Metadaten; nutzbare exportierte Inhalte ermöglichen die Dateiwiederherstellung. Für eine vollständige Wiederherstellung muss der erwartete Datensatz berücksichtigt werden.
FAQs
Wird bei einer Schnellformatierung die gesamte NTFS-MFT überschrieben?
Können Dateien erhalten bleiben, wenn ihre MFT-Einträge nicht mehr vorhanden sind?
Kann der MFT-Spiegel jeden Dateieintrag wiederherstellen?
Bedeutet ein Null-Bit in der Bitmap des neuen Volumes, dass die alten Daten gelöscht wurden?
Kann bei einem alten MFT-Datensatz das „In-Use“-Flag noch gesetzt sein?
Wird durch die Wiederherstellung des alten Bootsektors die Formatierung rückgängig gemacht?
Jason ist ein Spezialist für Datenwiederherstellung und technischen Support mit über 15 Jahren praktischer Erfahrung. Er hat intensiv mit Endnutzern zusammengearbeitet, schwierige Fälle von Datenverlust behoben und praktische Lösungen für versehentlich gelöschte Daten, formatierte Laufwerke, beschädigte Dateisysteme, verlorene Partitionen, Systemausfälle und andere Notfälle im Bereich der Datenwiederherstellung bereitgestellt. Zu seinen Fachgebieten gehören außerdem Datensicherung und -wiederherstellung, Dateireparatur sowie Notfallwiederherstellung, wobei er besonderen Wert auf eine sichere, zuverlässige und technisch korrekte Beratung legt.
