Wir sehen also, das bringt uns nicht so recht voran. Als ich also vor ein paar Tagen einen Anruf bekam, der sich um einen USB-Stick, einen abgestürzten Rechner und knapp 1 GB Datenverlust drehte, sah ich dies als eine Gelegenheit, meine Kenntnisse auf diesem Gebiet etwas zu erweitern willigte ein, mein Glück zu versuchen.
Am Start stehen: Ein 2-GB-USB-Stick, der an einem Windows-Recher eingebunden war, der offenbar in einem äußerst ungünstigen Moment unter Mitnahme der Dateisystemkonsistenz abstürzte. Danach ließ sich der Stick anfangs gar nicht mehr, nach einigem Herumgefummel wenigstens rudimentär wieder einbinden, zeigte aber keine Daten mehr an. Die in Forensik etwas Erfahrenen werden jetzt die Stirn kräuseln, bedeuten solche Versuche doch in der Regel, dass man vielleicht einen Schritt voran kommt, aber mindestens vier Schritte nach hinten rennt, indem man beim verzweifelten Versuch, dem Dateisystem wenigstens irgendein Lebenszeichen zu entlocken, so wild auf dem Datenträger herumschmiert, dass viel von dem, was man retten wollte, verloren geht. Sie kennen die Szene wahrscheinlich aus diversen Krimis: Die Spurensicherung rückt am Tatort an, wo die übereifrige Haushaltshilfe, weil sie sich wegen der Unordnung schämte, erst einmal tüchtig aufgeräumt hat. Genau das passiert, wenn Sie Ihren Datenträger retten wollen und dabei direkt mit ihm arbeiten.
Am Start stehen also besagter, von ersten Rettungsversuchen gebeutelter USB-Stick, ein Linux- und ein Windowssystem sowie eine Reihe frei erhältlicher Werkzeuge:
dd if=/dev/sdb1 of=USBimage.iso
greift man ein letztes Mal, und dann auch nur lesend auf den Orginialdatenträger zu. Alle weiteren Versuche finden entweder direkt auf der Imagedatei oder auf dem mit
mount -o ro,loop USBimage.iso /mnt/test
eingebundenen Image statt.
Zumindest stimmt diese Aussage in einer idealen Welt. In der schnöden Realität hat man mitunter keine Möglichkeit, seine 400-GB-Platte mal so eben als Image irgendwohin zu kopieren. Im von mir beschriebenen Fall ist die Situation aber zum Glück erheblich einfacher. Zwei Gigabyte für das Image eines USB-Sticks kann man bei handelsüblichen Platten in der Regel erübrigen.
Windows XP kann mit Bordmitteln keine ISO-Images als Laufwerke einbinden. Für die Tests benutzte ich eine Testversion der Daemon Tools.
Daemon Tools
Bei einem derart beliebten und verbreiteten Werkzeug hätte ich erwartet, dass selbst nicht ganz einwandfreie ISO-Images zumindest ansatzweise gelesen werden können. Tatsächlich wurde die Imagedatei auch eingebunden, aber es wurden keine Dateien angezeigt.
PC Inspector File Recovery
Der nächste Versuch bestand darin, Daten von der Imagedatei auf ein Rettungsmedium zu überspielen. PC Inspector File Recovery quittierte leider den Versuch, das eingebundene Image zu scannen mit einer Fehlermeldung und fand nichts.
Recuva
Möglicherweise greifen die Rettungsprogramme auch tiefer in die Hardware des Speichermediums ein, so dass eine Imagedatei einfach einen Abstraktionsgrad zu weit geht. Da ich eine Sicherungskopie des Sticks besaß, beschloss ich beim nächsten Test, direkt auf dem defekten Medium zu arbeiten. Tatsächlich fand Recuva auch prompt einige Excel-Dateien, was aber längst nicht alles war, was ich auf dem Stick zu retten hoffte.
Magicrescue
Die Zeit schien reif, Linux ins Spiel zu bringen. Wegen der Erfolgsaussichten hatte ich einige Zweifel. Zwar konnte ich mir vorstellen, dass man im Prinzip jedes Bit auf dem Datenträger finden und untersuchen konnte, aber ich hätte erwartet, dass kommerzielle Software unter Windows allein deswegen schon bessere Chancen besitzt, weil man erstens mehr in eine schicke Benutzerführung investieren kann und man zweitens auf einem Dateisystem operiert, das unter Windows einfach weiter verbreitet ist als unter Linux. Um den korrekten Befehl zusammenzustellen, musste ich auch in der Tat ein wenig Anleitungen lesen und herumprobieren, aber nachdem ich
magicrescue -d rescued_files -r magicrescue-1.1.9/recipes usb_stick.iso
abgesetzt hatte, brauchte ich nur 50 Minuten Geduld und bekam danach 1632 Dateien präsentiert - abzüglich Doubletten 1370.
Von der Anzahl Dateien darf man sich natürlich nicht blenden lassen. Viele davon sind nur Trümmer. Man muss also schon fleißig herumprobieren, ob sich die gesuchten Daten irgendwo befinden. Ein erster Überblick aber zeigte schon: Es sah sehr gut aus.
Foremost
Um ganz sicher zu gehen, auch den wirklich letzten noch verwertbaren Trümmer zu finden, probierte ich noch Foremost aus. Die Befehlssyntax war etwas einfacher als bei magicrescue
foremost -o rescued_files -i usb_stick.iso
und lieferte nach einigen Minuten Suche dieses Ergebnis:
und lieferte nach einigen Minuten Suche dieses Ergebnis:
Processing: usb_stick.iso
|**foundat=_rels/.rels �� (�
foundat=xl/_rels/workbook.xml.rels � (�
**WMV err num_header_objs=-1442784858 headerSize=1283357180869879345
WMV err num_header_objs=-1442784858 headerSize=1283357180869879345
*WMV err num_header_objs=-1442784858 headerSize=1283357180869879345
foundat=cntimage.gif
****************|
Die Ausbeute waren stolze 6170 Dateien, abzüglich Doubletten 5181.
Meine abschließenden Spielereien mit dem Sleuth Kit waren zugegebenermaßen nicht mehr besonders sorgfältig. Diese Werkzeugsammlung genießt offenbar völlig zu recht einen ausgezeichneten Ruf, eignet sich aber eher für die forensische Analyse als für automatisierte Datenrettung. Man möge mich korrigieren, aber eine einfache Möglichkeit einen Datenträger zu durchsuchen und alles, was irgendwie nach verwertbarer Datei aussieht, in ein Rettungsverzeichnis zu schreiben, habe ich auf Anhieb nicht gefunden.
Keine Kommentare:
Kommentar veröffentlichen