Rohes Lesen von USB-Massenspeicher oder SCSI

864
Balzola

Bei der USB-Festplatte von Wife gibt es ein kleines Problem, bei dem sich ein Ordner nicht öffnen lässt (NTFS-Dateisystem). Ich konnte das Laufwerk unter Linux nur für einen Sektor abbilden (Sektoren sind 4096 Bytes). Das Lesen dieses Sektors schlägt fehl:

sudo dd if = / dev / sdb = block überspringen = 21647245 bs = 4096 count = 1 dd: Fehler beim Lesen von '/ dev / sdb': Eingabe- / Ausgabefehler 0 + 0 Datensätze in 0 + 0 zeichnet auf 0 Bytes (0 B) kopiert, 22,9317 s, 0,0 kB / s

Ersetzen dieses Sektors durch Null-Bytes führt zu demselben Symptom wie in Windows, so dass der Sektor scheinbar mit dem problematischen Verzeichnis zusammenhängt.

Beim Zugriff auf diesen Sektor lautet die Ausgabe von dmesg:

[20381.842495] sd 7: 0: 0: 0: [sdb] Nicht behandelter Erfassungscode [20381.842506] sd 7: 0: 0: 0: [sdb]  [20381.842510] Ergebnis: hostbyte = DID_ERROR driverbyte = DRIVER_SENSE [20381.842514] SD 7: 0: 0: 0: [SDB]  [20381.842517] Sense-Schlüssel: Hardwarefehler [aktuell]  [20381.842531] sd 7: 0: 0: 0: [sdb]  [20381.842535] Add. Sinn: Keine zusätzlichen Sinnesinformationen [20381.842539] sd 7: 0: 0: 0: [sdb] CDB:  [20381.842542] Lesen (10): 28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request: E / A-Fehler, dev sdb, Sektor 173177960 [20381.842572] Puffer-E / A-Fehler in Einheit sdb, logischer Block 21647245

Gibt es eine Möglichkeit, diesen Sektor roh zu lesen, ohne CRC zu überprüfen, oder was auch immer versucht wird, einige der beschädigten Daten wiederherzustellen?

Ich habe das Gehäuse geöffnet: Die Festplatte ist nativ USB, keine Konvertierung von USB in SATA.

Edit: Versuchte ddrescue, konnte den fehlerhaften Sektor aber auch nicht wiederherstellen. Lesen Sie 2Gigs um den schlechten Sektor herum und lassen Sie die Köpfe nach dem Suchlauf stabilisieren:

Sudo ddrescue -s 2Gi -o 0 -i 87593373696 / dev / sdb blkk GNU ddrescue 1.19 Drücken Sie zum Unterbrechen Strg-C gerettet: 2147 MB, Fehlergröße: 4096 B, aktuelle Rate: 0 B / s ipos: 88667 MB, Fehler: 1, durchschnittliche Rate: 8488 kB / s opos: 1073 MB, Laufzeit: 4,21 m, erfolgreich abgelesen: vor 1,06 m Fertig

Rückwärtslesen (-R-Flag) ist ebenfalls fehlgeschlagen.

Bearbeiten 2: Mein geplanter zweiter Schritt bestand darin, mithilfe von Forensik zu versuchen, die fehlenden Dateien abzurufen. Ich habe zuerst angefangen, das MFT von Hand zu betrachten, aber das wird schnell sehr, sehr langweilig. Ich hatte also folgende Tools auf meiner Liste:

  1. das Sleuthkit
  2. ntfs-3g
  3. Skalpell
  4. scrounge-ntfs

Das Sleuthkit würde nichts Nützliches tun, indem es sehr früh aufhörte, sich über Fehler in Metadatenstrukturen zu beklagen.

Mit Ntfs-3g (jetzt Tuxera) ist es möglich, das Image mit Debug-Ausgabe zu mounten:

Sudo-Mount -o-Schleife, Ro, Offset = 258048, Debug-Image2 ./mnt -t ntfs-3g

Der Versuch, das fehlerhafte Verzeichnis einzugeben, würde einen Fehler auslösen:

Der Indexpuffer (VCN 0x0) des Verzeichnisses Inode 101874 hat eine Größe (24), die von der angegebenen Größe (4096) abweicht.

Nach diesem Fehler in DuckduckGo zu suchen, führt mich zu folgendem Beitrag: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 Es stellt sich heraus, dass die Leute bei Tuxera / ntfs-3g tatsächlich die Verwendung fördern von Microsoft CHKDSK NTFS-Fehler zu beheben

Das Ausführen von chkdsk auf der Festplatte war mein dritter und letzter geplanter Schritt. Es sollte jedoch viel früher versucht werden, zu wissen, dass es auf einem Festplatten-Image ausgeführt werden kann, z. B. OSFMount ( http://www.osforensics.com/tools/mount- disk-images.html ).

Die meisten der fehlenden Dateien und Verzeichnisse (wenn nicht alle) wurden von chkdsk / f auf dem bereitgestellten Disk-Image wiederhergestellt. Mehr als hundert Fehler (von denen die meisten verwaiste Dateien sind) wurden behoben.

Edit 3: Ich akzeptiere die Antwort von Psusi. Obwohl es sich nicht als unmöglich erwies, die fehlerhaften Sektoren zu lesen, ist sicherlich der unsicherste und schwierigste Weg, um Daten von einer leicht beschädigten Festplatte wiederherzustellen.

1

1 Antwort auf die Frage

1
psusi

Nein, das ist nicht möglich. Dazu gibt es einen SCSI-Befehl, aber Sie würden immer noch Müll bekommen, und er wird auf Laufwerken auf Consumer-Ebene nicht unterstützt, insbesondere nicht auf USB. Was auch immer in diesem Sektor war, ist weg.

Es wäre nicht unbedingt Müll. Es könnten ansonsten gute Daten mit einem fehlerhaften Bit sein, das den CRC nicht erfüllt. Vor langer Zeit konnte ich den generischen Linux-Treiber scsi und ein zugehöriges Dienstprogramm verwenden, um Befehle direkt an das Gerät auszugeben (ich habe vor 18 Jahren Treiberprogrammierung auf Scsi-Ebene durchgeführt). Wenn es solche rohen Befehle gibt, kann es nützlich sein, es zu versuchen. Otheus vor 8 Jahren 0
Das ist eigentlich das, was ich gerne machen würde :) und selbst entscheiden, ob die gelesenen Daten total oder nur teilweise Müll sind ... Balzola vor 8 Jahren 0
@Otheus, nein, funktioniert so nicht. Vor dem CRC gibt es ein ECC. Bis zu einer bestimmten Anzahl von schlechten Bits korrigiert es, aber sobald Sie das durchgehen, fängt es an, Müll auszuspucken. psusi vor 8 Jahren 0
@psusi ECC auf Datenträger? Du hast dafür eine Referenz? Otheus vor 8 Jahren 0
@Otheus, http://en.wikipedia.org/wiki/Hard_disk_drive psusi vor 8 Jahren 0
Ernst? Ein ganzer Wikipedia-Artikel? Nicht einmal ein Unterartikel oder Unterabschnitt? Otheus vor 8 Jahren 0
@Otheus, brauchst du wirklich so viel Halt? Sie konnten sich nicht die Mühe machen, die Seite nach CRC zu durchsuchen? psusi vor 8 Jahren 0
Wenn Ihre Kenntnisse über Festplattenlaufwerke aus Wikipedia stammen, habe ich schlechte Nachrichten für Sie. Wenn Sie sich nicht die Mühe machen, auf einen bestimmten Abschnitt zu verweisen, nehme ich nicht an, dass Sie nicht wissen, wovon Sie sprechen. Otheus vor 8 Jahren 0
@Otheus, ich habe Sie darauf hingewiesen, um zu zeigen, wie allgemein bekannt dies ist und wie leicht Sie es hätten finden können, wenn Sie sich gestört hätten. Es ist jetzt klar, dass Sie es vorziehen, Ad hominum-Angriffe durchzuführen, anstatt tatsächlich etwas zu lernen. psusi vor 8 Jahren 0
Es tut mir leid, @psusi, bitte akzeptiere meinen versöhnlicheren Ton. ECC funktioniert im Allgemeinen nicht so, wie Sie es vorschlagen. Ich weiß - ohne Wikipedia -, dass Festplatten mehrere Überprüfungen und Fehlerkorrekturen verwenden. Aber: CRCs werden auf _Blocks_ ausgeführt, während sich ECC auf Bit- oder Byte-Ebene befindet. Wenn Sie wissen, dass das ECC auch auf einer breiteren Ebene abläuft, würde ich mir wünschen, dass die technischen Spezifikationen dies versprechen. Nehmen Sie andernfalls an, dass n + 1 Fehler dazu führen, dass CRC fehlschlägt, und wenn Sie Glück haben, ist n das Minimum, um ECC zu durchdringen, aber CRC schlagen fehl. Normalerweise ist das Minimum für n 1 Bit in 512 Bytes von 10 Bit, dh 2 fehlerhafte Bits in 5120. Otheus vor 8 Jahren 0
@Otheus, nope .. ECC wird auch auf Blöcken durchgeführt (zumindest der Reed-Solomon-Typ, der auf Festplatten verwendet wird). Sie sind dazu gedacht, längere Fehlerfolgen zu korrigieren, anstatt den einzelnen, hier und dort verstreuten Fehler (wie ein Hamming-Code). Die einzige Möglichkeit, wie Festplattenkapazitäten in den letzten 15 bis 20 Jahren skaliert werden konnten, ist die Möglichkeit, zahlreiche Fehler zu korrigieren, die beim Packen von Bits immer enger zusammenliegen, und nicht nur ein fehlerhaftes Bit in 512 Bytes. psusi vor 8 Jahren 0

Verwandte Probleme