Manuelle Plausibilitätsprüfung der NTFS-Wiederherstellung

Question

Ich brauche bitte jemanden, der meinen bisherigen manuellen NTFS-Wiederherstellungsprozess auf Plausibilität prüft, da er mich in eine Sackgasse geführt hat.

Hintergrund:

• Ich hatte ein externes 1-TB-NTFS-Laufwerk (WD Elements), das hauptsächlich Fotos enthielt.
• Aus irgendeinem Grund ist die Festplatte beschädigt und wird unter Windows als Raw-Datenträger angezeigt.
• Es erscheint auf einem Linux-System in den Verzeichnissen /dev/disk/by-path(und by-idusw. by-uuid) und wird als angezeigt /dev/sdb.
• EaseUS kann mit einem schnellen Scan (nicht mit dem aufwändigen Tiefenscan) (fast?) alle meine Fotos dort finden.
• EaseUS findet etwa 70 GB an Dateien (hauptsächlich Fotos).
• Ich glaube, die NTFS-Datensätze sind beschädigt, es handelt sich also nicht um einen mechanischen Fehler.
• Ich möchte aus Spaß und Profit einen Selbstversuch zur Wiederherstellung unternehmen.
• Ich habe kein anderes Laufwerk, das groß genug ist, um ein vollständiges Image des beschädigten Laufwerks zu erstellen.

Ich muss die NTFS MFT $File-Datensätze analysieren, weil:

• Ich möchte die ursprünglichen Dateinamen und die Verzeichnisstruktur wiederherstellen.
• Wenn ein Bild nicht in zusammenhängenden Clustern geschrieben ist, kann ich es nicht erfolgreich wiederherstellen, indem ich lediglich nach Bilddateisignaturen suche.

Der Plan ist:

1. Erstellen Sie ein Image eines Teils der beschädigten Festplatte.
2. Analysieren Sie es, um MFT $File-Datensätze zu identifizieren und zu lesen.
3. Verwenden Sie die $File-Datensätze (und insbesondere deren $Data-Attribut), um die Datenläufe jeder Datei zu bestimmen.
4. Da ich die Datenausführungen für eine Datei kenne, kann ich aus dem von mir erstellten Bild die Bytes einer Datei heraussuchen ddrescue.
5. Ausspülen und wiederholen, bis ich fertig bin.

Erstens: Klingt das nach einem vernünftigen Plan?

Was ich getan habe:

1. Eine Reihe von $File-Datensätzen gefunden
2. Analysieren Sie einen, um die Datenläufe zu erhalten
3. Lesen Sie die Rohbytes an der durch den Datenlauf angegebenen Position.

Speziell:

1. Wird verwendet ddrescue, um ein Image von 100 GB (beginnend bei 0) der beschädigten Festplatte zu erstellen.
   1. Ich nehme an, dass fast alle tatsächlich benötigten Daten innerhalb der ersten 100 GB geschrieben werden, da das Gesamtvolumen der interessanten Daten 70 GB beträgt. Ich kann diesen gesamten Vorgang bei Bedarf für die folgenden 100-GB-Abschnitte wiederholen.
   2. Der Befehl, den ich zum Abbilden der ersten 100 GB verwendet habe, war ddrescue /dev/sdb ~/mydisk.img ~/mydisk.map --size=100G.
   3. ddrescueEs sind E/A-Fehler aufgetreten und es wurde gemeldet, dass die Wiederherstellung nur zu etwa 99,57 % erfolgte.
   4. Der Anfang des Images (die ersten 20 MB oder so) scheint leer zu sein, das könnte also der Grund für den Laufwerksfehler sein. Ich ignoriere das vorerst.
2. Lesen Sie das 100 GB große Bild durch und suchen Sie alle Vorkommen der ASCII-Zeichenfolge „FILE“, die den Beginn eines $File-Datensatzes in der MFT kennzeichnet.
   1. Dies hat auch zu Fehlalarmen geführt, wie beispielsweise dem Wort „PROFILE“ in der Mitte einer beliebigen Datei.
   2. Daher berücksichtige ich nur Ergebnisse, bei denen der Abstand zwischen einem Vorkommen von „FILE“ und dem nächsten <= 1024 Bytes beträgt, da dies die maximale MFT-Datensatzgröße ist. Wenn zwischen einem Vorkommen von „FILE“ und dem nächsten 3 MB liegen, handelt es sich wahrscheinlich nicht um einen $File-Datensatz.
3. Iterieren Sie über vermutete $File-Datensätze (Größe <= 1024 Bytes) und extrahierte $Data-Attribute.
4. Habe es für Datenläufe analysiert (und dabei die Diskussion über residente vs. nicht residente Attribute ignoriert, die ich, glaube ich, verstehe, die aber nicht Teil meiner Frage ist).

Ich habe also den oben beschriebenen Prozess durchlaufen, einen der $File-Datensätze ausgewählt und seine Datenläufe identifiziert. Hier ist das $Data-Attribut (Header und Inhalt):

80 00 00 00 48 00 00 00  01 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00  FA 03 00 00 00 00 00 00
40 00 00 00 00 00 00 00  00 B0 3F 00 00 00 00 00
F4 AC 3F 00 00 00 00 00  F4 AC 3F 00 00 00 00 00
32 FB 03 ED C8 11 00 00  FF FF FF FF 82 79 47 11

Die Datenlaufdetails sind die erste Hälfte der letzten Zeile, direkt vor dem FF FF FF FFEnde der Attributmarkierung:

• Länge Byte:32
• Cluster-Laufnummer: FB 03(Little Endian) = 1019 Cluster im Lauf
• Cluster-Startnummer: ED C8 11= 1165549 ist der erste Cluster des Laufs
• Der nächste 00zeigt an, dass keine weiteren Läufe vorhanden sind.

Wenn man nun berücksichtigt, dass es 512 Bytes pro Sektor und 128 Sektoren pro Cluster gibt, lese ich (1019 * 128 * 512) Bytes aus dem 100-GB-Image, beginnend bei (1165549 * 128 * 512).

Leider blieb mir dann eine 66,8 MB große Datei mit hauptsächlich 0x00, obwohl gegen Ende noch einige Daten vorhanden waren. Ich bin ziemlich sicher, dass ich etwas falsch gemacht habe und nur zufällig einige Daten gefunden habe (obwohl ich zufällig auf einem JPG-Dateiendemarker (DD F9) gelandet bin).

Ist meine Herangehensweise an die gesamte Aufgabe vernünftig und habe ich nur irgendwo einen kleinen Fehler gemacht?

Oder habe ich etwas Grundlegendes zu NTFS falsch verstanden und das hier ist eine völlig falsche Idee?

Answer 1

Erstens: Klingt das nach einem vernünftigen Plan?

Nein. Ich meine, ich habe mir Ihre Methode zum Dekodieren von Läufen nicht näher angesehen, aber Startcluster sind relativ zum Start des Dateisystems (= Start des Volumes/der Partition, wenn wir von NTFS sprechen). Jeder MFT-Eintrag, der auf eine Clusternummer verweist, verweist also auf die Clusternummer relativ zum Start der Partition, nicht relativ zu Ihrem beliebigen 100-MB-Teil des Volumes.

Außerdem ist MFT „selbstreferenzierend“, also sollten Sie als erstes versuchen, den Anfang von MFT zu finden, von dem Sie dann ableiten könnenalleMFT-Einträge. Wenn Sie den Anfang von MFT nicht finden können, versuchen Sie stattdessen, das Spiegelbild von MFT zu finden.

Um einen MFT-Eintrag richtig zu dekodieren und die Daten zu erhalten, auf die er verweist, benötigen wir:

• Offset zum Beginn der Partition.
• Richtige Clustergröße

Wenn wir also den Startcluster dekodieren, können wir Folgendes tun: (Cluster-Nr. * Sektoren / Cluster) + Offset-Partition

Wie haben Sie 128 Sektoren pro Cluster ermittelt? Das scheint überhaupt nicht richtig zu sein! Die Standardeinstellungen finden Sie hier:https://www.disktuna.com/default-cluster-sizes-for-fat-exfat-and-ntfs/.

Answer 2

Es ist unprofessionell, eine beschädigte Disc der von Ihnen beschriebenen Leselast auszusetzen. Die erste Voraussetzung ist, dieses Laufwerk auf ein stabiles, intaktes Laufwerk zu duplizieren, um den Verlust zusätzlicher Sektoren zu vermeiden und keine unlesbaren Sektoren mehr zu haben. Die Tatsache, dass die unlesbaren Sektoren nicht kopiert werden konnten, ist traurig, aber der Schlüssel ist, zu verhindern, dass Sie oder ein Wiederherstellungsprogramm Lesefehler beheben.

Es ist durchaus möglich, dass Ihre Wiederherstellungsversuche bereits weiteren Schaden auf diesem Laufwerk verursacht haben.

Da Metadatenstrukturen und Daten nicht unbedingt linear angeordnet sind, können Sie den Mangel an mindestens einem ausreichend großen Laufwerk nicht dadurch kompensieren, dass Sie 100-GB-Slices nachträglich irgendwo in einen freien Laufwerksspeicher an anderer Stelle einlesen. Sie benötigen wahlfreien Zugriff. In Ihrem Fall müssen Sie leider Ihren 100-GB-Speicherbereich leeren, sobald eine Struktur auf Ihr nächstes 100-GB-Slice zeigt.

Wenn Sie Strukturen bereits in Ihrer bevorzugten Programmiersprache analysieren, müssen Sie für den Kopierauftrag keine Unix-Befehle wie dd ausführen. ddrescue wird nur einmal zu Beginn Ihres Wiederherstellungsversuchs benötigt.

Wenn Sie nur die internen Vorgänge von NTFS lernen möchten, ist das in Ordnung und eine coole Sache, aber Sie können das auch schon auf Speichermedien wie USB-Sticks lernen. Große Laufwerke sind nicht erforderlich.

Bitte überlegen Sie, aus welchem ​​Grund Easeus die gewünschten Metadaten wie Dateinamen und Ordnerstrukturen nicht wiederherstellen konnte.

Answer 3

Ich dachte, Laufwerke seien linear, beginnend bei Byte 0 des Sektors 0 des Clusters 0 und bis zum Ende des physischen Laufwerks.

Ja und nein. Speicheradressen sind linear und beginnen mit Byte 0. Sektoradressen sind ebenfalls linear.

Clusteradressen sind linear und beginnen mit der Clusternummer Null, jedoch nur relativ zu ihrer jeweiligen Partition. Es gibt keine datenträgerweite Clusterbeschriftung, sondern nur eine partitionweite Clusterbeschriftung, die bei Null beginnt.

Wollen Sie damit sagen, dass ich, wenn ich ein Tool wie ddrescue zum Lesen der Bytes 0 bis 1.000.000 verwende, nicht erwarten kann, die NTFS-Metadaten gelesen zu haben, die das Layout beschreiben?

Die NTFS-Metadaten umfassen nicht nur den Bootsektor, sondern auch die Master File Table und andere Dateien. Wenn Sie 1 MByte vom Anfang des Laufwerks lesen, lesen Sie nur einen Bruchteil der Master File Table, vorausgesetzt, sie befindet sich dort. Ihre Position ist nicht festgelegt und ändert sich wahrscheinlich bei der Defragmentierung.

Verwenden Sie die Strategie, um zu experimentieren und hier mehr über Ihr Dateisystem zu erfahren: https://forum.cgsecurity.org/phpBB3/viewtopic.php?p=31304#p31304

Wenn Sie versuchen, NTFS zu entschlüsseln, wissen Sie das beabsichtigte Ergebnis bereits viel besser. Es ist eine Art Entschlüsselungsprozess, wie bei einem „bekannten Klartextangriff“, bei dem Sie den gesamten Klartext kennen.

Jemand hat gerade meine Antworten abgelehnt. Wenn Sie das waren, erklären Sie bitte den Grund. Ist irgendwo ein Fehler? Das würde ich gerne wissen! Danke.