Im Jahr 2019 kam ein nicht ganz gewöhnlicher Speicher QUANTUM FIREBALL Plus KA mit einer Kapazität von 9,1 GB in unser Labor. Laut dem Besitzer trat der Ausfall im Jahr 2004 durch einen defekten Netzteil auf, der die Festplatte und andere PC-Komponenten beschädigte. Anschließend gab es zahlreiche Versuche, den Speicher in verschiedenen Servicecentern zu reparieren und die Daten wiederherzustellen, die jedoch erfolglos blieben. An manchen Orten wurde eine günstige Lösung versprochen, jedoch ohne das Problem zu lösen, und an anderen Stellen waren die Kosten zu hoch, sodass der Kunde auf eine Datenwiederherstellung verzichtete. Letztendlich durchlief die Festplatte viele Servicezentren. Sie ging mehrfach verloren, doch der Eigentümer hatte vorgesorgt und Informationen von verschiedenen Aufklebern auf dem Speicher notiert, sodass er sicherstellen konnte, dass seine Festplatte aus einigen Servicezentren zurückgegeben wurde. Die ganzen Umgänge blieben nicht ohne Folgen: Auf der Originalplatine des Controllers fanden sich zahlreiche Lötspuren, und es war visuell ein Mangel an SMD-Elementen zu beobachten (vorweggenommen sei gesagt, dass dies das geringste Problem dieses Speichers ist).
Abb. 1 HDD Quantum Fireball Plus KA 9,1 GB
Zuerst mussten wir uns bemühen, einen so alten Zwillingsspeicher mit funktionierender Controllerplatine im Donorarchiv zu finden. Nachdem dieses Abenteuer abgeschlossen war, war es möglich, umfassende Diagnoseschritte durchzuführen. Nachdem wir die Wicklungen des Motors auf Kurzschluss überprüft und dessen Abwesenheit festgestellt hatten, installieren wir die Platine des Spenders auf den Speicher - Patienten. Wir schalten die Stromversorgung ein und hören das normale Geräusch des Anlaufens der Welle, der erfolgreiche Abschluss des Kalibrierungstests mit dem Laden der Firmware, und nach wenigen Sekunden meldet der Speicher über die Register seine Bereitschaft, auf Befehle des Interfaces zu reagieren.
Abb. 2 Die Indikatoren DRD DSC zeigen die Bereitschaft zur Annahme von Befehlen an.
Wir reservieren alle Kopien der Firmware-Module. Wir führen eine Integritätsprüfung der Firmware-Module durch. Es gibt keine Probleme beim Lesen der Module, aber die Analyse der Berichte zeigt einige Merkwürdigkeiten.
Abb. 3. Zonentabelle.
Achten Sie auf die Tabelle der Zonenzuweisung und stellen Sie fest, dass die Anzahl der Zylinder 13845 beträgt.
Abb. 4 P-Liste (Primärliste – Liste der Mängel, die im Produktionszyklus erfasst wurden).
Wir weisen auf die zu geringe Anzahl der Mängel und deren Lokalisierung hin. Wir überprüfen das Protokollmodul zur Versteckung von Herstellermängeln (60h) und stellen fest, dass es leer ist und keinen einzigen Eintrag enthält. Auf dieser Grundlage können wir annehmen, dass in einem der vorherigen Servicezentren möglicherweise irgendwelche Manipulationen mit dem Dienstleistungsbereich des Speichers stattgefunden haben, und versehentlich oder absichtlich ein fremdes Modul aufgezeichnet oder die Mängelliste im Original gelöscht wurde. Um diese Vermutung zu überprüfen, erstellen wir eine Aufgabe im Data Extractor mit den aktivierten Optionen „Sektorkopie erstellen“ und „Virtuellen Übersetzer erstellen“.
Abb. 5 Aufgabenparameter.
Nachdem wir die Aufgabe erstellt haben, überprüfen wir die Einträge in der Partitionstabelle im Nullsektor (LBA 0)
Abb. 6 Hauptboot-Eintrag und Partitionstabelle.
Bei Offset 0x1BE befindet sich der einzige Eintrag (16 Byte). Der Dateisystemtyp der Partition ist NTFS, Offset bis zum Anfang 0x3F (63) Sektoren, die Größe der Partition beträgt 0x011309A3 (18 024 867) Sektoren.
Im Sektor-Editor öffnen wir LBA 63.
Abb. 7 Bootsektor NTFS
Nach den Informationen im Bootsektor der NTFS-Partition kann Folgendes gesagt werden: Die Sektorgröße, die im Volume verwendet wird, beträgt 512 Byte (bei Offset 0x0B ist das Wort 0x0200 (512) aufgezeichnet), die Anzahl der Sektoren pro Cluster beträgt 8 (bei Offset 0x0D ist das Byte 0x08 aufgezeichnet), die Clustergröße beträgt 512x8=4096 Byte, der erste MFT-Eintrag befindet sich bei Offset 6 291 519 Sektoren vom Beginn der Festplatte (bei Offset 0x30 ist das vierfache Wort 0x00 00 00 00 00 0C 00 00 (786 432) die Nummer des ersten Clusters der MFT. Die Sektorennummer wird nach der Formel berechnet: Cluster-Nummer * Anzahl der Sektoren pro Cluster + Offset bis zum Anfang der Partition 786 432* 8+63= 6 291 519).
Wir gehen zu Sektor 6 291 519.
Abb. 8
Die Daten in diesem Sektor weichen jedoch ganz erheblich vom MFT-Eintrag ab. Dies deutet zwar auf mögliche falsche Übersetzungen aufgrund einer inkorrekten Mängelliste hin, beweist diesen Fakt jedoch nicht. Um dies weiter zu überprüfen, führen wir das Lesen der Festplatte in beide Richtungen über 10 000 Sektoren im Verhältnis zum Sektor 6 291 519 durch und suchen danach mit regulären Ausdrücken in den gelesenen Daten.
Abb. 9 Erster MFT-Eintrag
Im Sektor 6 291 551 entdecken wir den ersten MFT-Eintrag. Seine Position weicht um 32 Sektoren von der berechneten ab, und danach folgt kontinuierlich eine Gruppe von 16 Einträgen (von 0 bis 15). Wir tragen die Position des Sektors 6 291 519 mit einer Verschiebung von 32 Sektoren in die Verschiebungstabelle ein.
Abb. 10
Die Position des Eintrags Nr. 16 sollte gemäß der Verschiebung 12 551 431 sein, jedoch finden wir dort Nullen statt eines MFT-Eintrags. Führen wir eine ähnliche Suche in der Umgebung durch.
Abb. 11 MFT-Eintrag 0x00000011 (17)
Ein großer MFT-Ausschnitt wird gefunden, der mit dem Eintrag Nr. 17 beginnt und 53 646 Einträge (mit einer Verschiebung von 17 Sektoren) umfasst. Für die Position 12 155 431 setzen wir die Verschiebung um +17 Sektoren in die Verschiebungstabelle ein.
Nachdem wir die Positionen der MFT-Fragmente im Raum festgelegt haben, können wir schließen, dass dies nicht wie ein zufälliger Fehler aussieht und die Aufzeichnung der MFT-Fragmenten mit fehlerhaften Verschiebungen. Die Version mit einem fehlerhaften Translator kann als bestätigt angesehen werden.
Für eine weitere Lokalisierung der Verschiebungspunkte setzen wir die maximal mögliche Verschiebung. Dazu bestimmen wir, wie stark der Endmarker des NTFS-Partitions (eine Kopie des Bootsektors) verschoben ist. In Abbildung 7 ergibt sich aus der Verschiebung 0x28 das Quadwort — dies ist der Wert der Partitionsgröße 0x00 00 00 00 01 13 09 A2 (18 024 866) Sektoren. Addieren wir die Verschiebung der Partition von Beginn der Festplatte zu ihrer Länge, erhalten wir die Verschiebung des Endmarkers NTFS von 18 024 866 + 63 = 18 024 929. Erwartungsgemäß fanden wir dort nicht die benötigte Kopie des Bootsektors. Bei der Suche in der Umgebung wurde er mit einer ansteigenden Verschiebung von +12 Sektoren relativ zum letzten MFT-Fragment gefunden.
Abb. 12 Kopie des NTFS-Bootsektors
Eine weitere Kopie des Bootsektors bei einer Verschiebung von 18 041 006 ignorieren wir, da sie nichts mit unserer Partition zu tun hat. Basierend auf den vorherigen Aktivitäten wurde festgestellt, dass innerhalb der Partition Einschüsse von „aufgetauchten“ 61 Sektoren vorliegen, die die Daten verschoben haben.
Wir führen ein vollständiges Lesen des Speichermediums durch, wobei 34 unlesbare Sektoren übrig bleiben. Leider kann man nicht zuverlässig garantieren, dass all diese Sektoren Defekte sind, die aus der P-Liste entfernt wurden, aber bei einer weiteren Analyse ist es wünschenswert, ihre Position zu berücksichtigen, da in einigen Fällen die Verschiebungspunkte mit einer Genauigkeit bis auf den Sektor und nicht nur bis zur Datei bestimmt werden können.
Abb. 13 Lese-Statistik der Festplatte.
Unsere nächste Aufgabe wird es sein, die ungefähren Verschiebungsorte (mit der Genauigkeit bis zur Datei, in der sie aufgetreten sind) zu bestimmen. Dazu werden wir alle MFT-Einträge scannen und Ketten der Dateipositionierung (Dateifragmenten) aufbauen.
Abb. 14 Ketten der Dateipositionierung oder ihrer Fragmente.
Als Nächstes suchen wir von Datei zu Datei, ab wann anstelle des erwarteten Dateikopfes andere Daten vorhanden sind und der benötigte Kopf mit einer positiven Verschiebung entdeckt wird. Während wir die Verschiebungspunkte präzisieren, füllen wir die Tabelle aus. Das Ergebnis wird mehr als 99 % fehlerfreie Dateien sein.
Abb. 15 Liste der benutzerdefinierten Dateien (vom Kunden wurde das Einverständnis zur Veröffentlichung dieses Screenshots eingeholt)
Um punktuelle Verschiebungen in einzelnen Dateien festzustellen, können zusätzliche Arbeiten durchgeführt werden. Wenn man die Struktur der Datei kennt, kann man Datenentmischungen finden, die nicht zu ihr gehören. Aber in dieser Aufgabe war das wirtschaftlich nicht sinnvoll.
P.S. Ich möchte auch an die Kollegen appellieren, die diese Festplatte zuvor in ihren Händen hatten. Bitte seien Sie vorsichtig beim Arbeiten mit der Firmware der Geräte und sichern Sie die Systemdaten, bevor Sie etwas ändern, und verhindern Sie absichtlich eine Verschärfung des Problems, wenn Sie keine Vereinbarung mit dem Kunden über die Durchführung der Arbeiten getroffen haben.
Quelle: habr.com
