LUKS-Header suchen mit hexdump - stuuuundenlang

[manes]

hallo forum,

wegen eines festplattenproblems und geistig umnaechtigter rettungsversuche zu nachtschlafender zeit bin ich jetzt mit einer live-cd auf der suche nach dem beginn der luks-partition. (hexdump -C /dev/disk/by-id/ata-TOSHIBA_MK2529GSG_7947W4KAW | grep "4c 55 4b 53 ba be")
seit >72h laeuft nun schon hexdump und ist noch immer nicht fertig, die platte ist 250GB gross und hexdump belegt permanent 100% auf einem kern eines core2duo.
aehh, ist das noch normal? dass es lange dauert, wusste ich ja, aber soo lange?

gruesse
manes

[rendegast]

Läuft bei mir mit ~ 2.5MB/s, hd mit 100%, grep mit 10% auf dem zweiten Kern.
-> 100.000s ~ 1Tag
Aber 3 Tage?
Läuft die CPU unter dem Live-System mit voller Leistung? Vielleicht governor powersave o.ä.?

Es geht zumindest etwas schneller:

Code: Alles auswählen

# dd if=/dev/sda of=/tmp/sda bs=1M count=30
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.0355381 s, 885 MB/s

# date; nice hexdump -C /tmp/sda > /dev/null ; date
Mon Mar 19 18:34:16 CET 2012
Mon Mar 19 18:34:28 CET 2012
12 Sekunden

# date; nice hexdump  /tmp/sda > /dev/null ; date
Mon Mar 19 18:34:33 CET 2012
Mon Mar 19 18:34:38 CET 2012
5 Sekunden, 6MB/s!

'-x' wäre auch so "schnell",
die anderen Optionen geben anders codierte Ausgaben.




Da hexdump bei weitem nicht die Datenrate einer Platte erreicht,
wären vielleicht mehrere Prozesse möglich.
Als Idee core-Anzahl 100MB-Blöcke (o.ä) in das tmpfs kopieren, und auf jedes einen hexdump ansetzen.
Bei einem Quadcore also gleichzeitig 4 solche Suchen.

Aus den 100.000 Sekunden würden mit dem "richtigen" hexdump 40.000 Sekunden,
und daraus mit zwei Suchprozessen vielleicht 25.000 Sekunden.

[habakug]

Hallo!

Ich hatte hier mal ein Tool für diesen Zweck verlinkt [1].
Good Luck!

Gruß, habakug

[1] viewtopic.php?f=37&t=132345#p850032

[schorsch_76]

Kennst du diesen Artikel? [1]

Insbesondere den Abschnitt über hexedit?

Gruß
schorsch

[1] http://forum.ubuntuusers.de/topic/anlei ... s-partiti/

[wanne]

Code: Alles auswählen

dd if=/dev/ | grep -a -b LUKS

Das müsste einigermasen Flott durchlaufen du kannst ja einen 2. prozess in der Mitte der Platte anfangen lassen.

[manes]

merci allen miteinander fuer die hilfreichen hinweise!
hexdump ist inzwischen ins stolpern geraten:

Code: Alles auswählen

hexdump -C /dev/disk/by-id/ata-TOSHIBA_MK2529GSG_7947W4KAW |grep "4c 55 4b 53 ba be"
hexdump: /dev/disk/by-id/ata-TOSHIBA_MK2529GSG_7947W4KAW: Input/output error

dann kann ich jetzt mal euen links folgen...

gruesse
manes

[Brancaleone]

Da ich gerade am WE meine verschlüsselte Externe aus Versehen komplett formatiert habe ... (VORSICHT: Wenn ihr im Ubuntu-Startdisk-Ersteller eine Partition auswählt und dann auf Format media geht wird DIE GESAMTE HDD FORMATIERT UND NICHT DIE PARTITION !!! Ich hätts mir bei Ubuntu aaaaaber auch denken können ...)

Hier die Wiederherstellung:

1. testdisk deep search rüberlaufen lassen
2. Partitionen werden angezeigt, aber die Größe stimmt nicht (sind nur ein paar KB). Partitionen setzen und Tabelle schreiben.
3. Mit sfdisk -d /dev/sdx > partition die Tabelle kopieren.
4. Die korrekte Größe errechnen und in der Tabelle unter size eintragen
5. mit sfdisk --force /dev/sdx < partition zurückschreiben
6. Partitionen laufen wieder.
7. Entschlüsseln, ro mounten, Backup machen

Klappt leider nicht bei Truecrypt ... da bleibt die Partition verschollen.
Im Zweifelsfall die Partition größer wählen, als sie vorher war. Wenn ihr sie zu klein macht, könnt ihr zwar entschlüsseln und mounten, aber es fehlen Daten.

PS Ihr könnt natürlich auch mit fdisk editieren ...
PPS Hab mir gerade den Artikel über Hexedit durchgelesen. Meiner Erfahrung nach ist die Größe das einzige, was testdisk nicht richtig erkennt. Irrelevant, solange wir den Anfang und den der nächsten Partition kennen. Aber wer es sich lieber komplizierter machen will oder sauer ist, kann natürlich auch den Computer zur Rache ein bischen rechnen lassen ...

[wanne]

Also als ich mir das letzte mal eine LUKS-Partition zerschossen habe, konnte testdisk die noch nicht finden. Das ist aber auch ne weile her.

[manes]

hallo forum,
nochmal vielen dank fuer eure hilfe!
ich bin schorsch_76' hinweis auf die suche mit hexedit gefolgt - leider wird das babe-suchmuster nicht gefunden.
jetzt gestehe ich: mein "rettungsversuch" wegen ausufernder ata-fehlermeldungen war ein gedankenloses

Code: Alles auswählen

badblocks -vvws /dev/<device>
Checking for bad blocks in read-write mode
From block 0 to <irgendeine grosse zahl>
Testing with pattern 0xaa: 0.3irgendwas% done, 0:05 elapsed

das ich nach ca fuenf gedenksekunden erst wieder gestoppt habe. ich hatte das mit copy&paste aus irgendeinem thread gefischt hatte, ohne die optionen zu ueberpruefen.
gerechte strafe, dass ich meine daten verloren habe.
die sind doch verloren, oder?

gruesse
manes

[Cae]

Naja, badblocks -w schreibt zufällig (?) bestimmte Pattern auf die Platte, egal, ob da ein Dateisystem drauf ist oder nicht. Nach Murphys Gesetz wirst du natürlich den LUKS-Header erwischt haben, was auch sonst…
Putt ist putt, aber du kannst ja habakugs Empfehlung bgrep ausprobieren, das hat auch den Vorteil, dass man den Umweg über ASCII nicht hat, wie hexdump und grep es machen. Das müsste viel effizienter sein. Der Code sieht nett aus, Lob an den Autor.

Gruß Cae

[wanne]

Wenn du hexdump -x ausführst verdreht er dir immer 2 Bytes. Du musst also dann nach "554c 534b beba" grepen. Und wenn du pech hast, dann ist ein Zeilenumbruch drin. Ich würde dir empfehlen (b)grep zu nuzen. Aber wenn du badblocks -w voll drüber gelaufen ist, ist nichts mehr zu holen. Der überschreibt schön braf alle Blöcke, um dann zu testen, ob auch wirklich jeder Block beim Auslesen das was er vorher reingeschrieben hat auch enthelt. Da hätte ein n hin ghört.

[rendegast]

zufällig (?)

Code: Alles auswählen

... (0xaa, 0x55, 0xff, 0x00) ...

jeweils ein kompletter Durchgang
10101010
01010101
11111111
00000000
-> "systematisch"

Da hätte ein n hin ghört.

Der "non-destructive" Write-Modus schreibt zufällige Daten.
Ist aber nur Nicht-zerstörend, wenn der Datenträger wirklich fehlerfrei ist.
Sollte ein Fehlerblock festgestellt werden, können die zuvor ausgelesenen und im Arbeitsspeicher abgelegten Nutzdaten vielleicht nicht mehr zurückgeschrieben werden. -> Datenverlust
Und in diesem Fall ist von fehlerhafter Hardware auszugehen, der Auslöster waren ja ATA-Fehler.

[Cae]

-> "systematisch"

Aha, danke für die Aufklärung!

Gruß Cae

[manes]

Naja, badblocks -w schreibt (...) bestimmte Pattern auf die Platte, egal, ob da ein Dateisystem drauf ist oder nicht. Nach Murphys Gesetz wirst du natürlich den LUKS-Header erwischt haben, was auch sonst…
Putt ist putt, aber du kannst ja habakugs Empfehlung bgrep ausprobieren,(...)

es waren wirklich nur eine handvoll gedenksekunden, bis ich kapiert habe, was ich da anrichte und dann habe ich den prozess gestoppt. wenn aber hexedit das babe-muster nicht findet, nutzt doch auch ein anderes, effizienteres tool wie bgrep nix. wo nix ist, kann man auch nix finden!?
diese 0xaa-muster werden doch auch nicht nur auf die ersten zwei byte des sektors geschrieben, sondern der sektor wird vollgeschrieben: aa aa aa aa aa..., korrekt?
weil ausser /boot die gesamte platte verschluesselt ist, wird badblocks auch recht schnell am luks-header angekommen sein, ihn ueberschrieben haben und deshalb ist da nix mehr zu finden.
sind meine ueberlegungen grob unzutreffend?

und nochmal vielen dank fuer eure unterstuetzung!

gruesse
manes

[rendegast]

diese 0xaa-muster werden doch auch nicht nur auf die ersten zwei byte des sektors geschrieben, sondern der sektor wird vollgeschrieben: aa aa aa aa aa..., korrekt?

Das Muster wird linear auf die ganze Platte geschrieben,
nach 5s also 200-500MB je nach Plattengeschwindigkeit.
Einfach nachzuprüfen zBsp. mit einem VM-Image.

Anders der "non-destructive" Schreibtest, der nimmt sich immer einen Teilbereich vor.
Statistisch werden dabei nur die Hälfte aller Bits gekippt.
Die Chance, defekte Sektoren bestätigt zu bekommen ist dennoch hoch,
da wohl meist nicht nur einzelne defekte Bits existieren.
Der Test ist insgesamt lahm, und/weil erzeugt viele Kopfbewegungen
-> noch schnellerer Plattentod eines angeschlagenen Datenträgers.

[wanne]

Wenn du in etwa weist, wie groß die /boot partition war und dann die anzahl an blöcken überspringen und mal count=1 ausgeben lassen. wenn da nur aa rauskommt ist der header wahrscheinlich weg.
Prinzipiell kann es sein, dass ein zeilenumbruch im LUKS header ist, und du deswegen nichts findest. Aber das ist unwahrscheinlich, da eine Vernünftige Patitionierung an 512 Blöcken anfängt.
ABER:
Wenn du hexdump -x ausführst musst du die Zeichen vertasuchen:
=> Du must nach beba nicht nach babe greppen!
Der ganze Befehl ist dann

Code: Alles auswählen

dd if=/dev/sde6 | hexdump -x | grep -n -E "554c[[:space:]]*534b[[:space:]]*beba"

Oder eben alternativ:

Code: Alles auswählen

dd if=/dev/sde6 | hexdump -C | grep -n -E "4c 55 4b 53 ba be" #langsam
dd if=/dev/sde6 | grep -ab "LUKS" #schnell

[manes]

vielen dank für eure engagierte hilfe!
der header war nicht mehr aufzufinden, also ist der luks-container mindestens bis zur serienreife von quantenrechnern sicher vor mir.
außer zwei monaten mailkorrespondenz und meiner steuererklärung habe ich nichts wichtiges verloren. naja.
habe den neuen "spinning rust" genutzt, mal endlich von lenny kde 3.5 auf wheezy zu wechseln.
ein backup vom header und die position auf der platte mache ich mir noch...
danke nochmals!

grüße
manes