HD-recovery: ddrescue vs dd_rescue

[Weissbrot]

Hallo,
ich versuche, eine defekte HD mit ddrescue wieder lauffähig zu machen.
Da die Platte verschlüsselt ist, (ich weiß nicht womit, offenbar aber nicht LUKS), suche ich ein Äquivalent zu
$ sudo dd_rescue -d -D -A /dev/sde /dev/sde , welcher mit der Option -A die Errors auf der defekten Platte mit Nullen überschreibt.

Da ddrescue nicht dasselbe ist wie dd_rescue (von Garloff), macht die Option -A hier was anderes.
Also Frage: wie mache ich das mit ddrescue?

[MSfree]

Wenn die Platte verschlüsselt ist, würde ich es sinnvoll finden, ddrescue auf dem entschlüsselten LUKS-Container laufen zu lassen. Dazu braucht man aber den Schlüssel oder die Passphrase, um den Container aufzusperren.

[wanne]

Zuerst mal hat ddrescue so ein bisschen schon einen
ddrescue -f -r-1 /dev/sdcard /dev/null mapfile

Also Frage: wie mache ich das mit ddrescue?

ddrescue kann das erst mal nicht direkt in einem Kommando:

If the output file is a regular file created by ddrescue, the areas marked as bad-sector will contain zeros. If it is a device or a previously existing file, the areas marked as bad-sector will still contain the data previously present there.

Der offensichtlichste Weg ist also

Code: Alles auswählen

ddrescue /dev/sde /tmp/file /tmp/mapfile
ddrescue -wf /tmp/file /dev/sde 

Braucht dann halt aber einen puffer File.

Es hat aber auch den fill mode, der zuvor gefundene kaputte (oder noch lesbare) Sektoren überschreiben kann:

Code: Alles auswählen

ddrescue -f /dev/sde /dev/null /tmp/mapfile # raus finden welche Sektoren kaputt sind
ddrescue -f --fill-mode=- /dev/zero /dev/sde /tmp/mapfile # Kaputte Sektoren mit nullen überschreiben

Normalerweise will man ddrescue ein -r1 -u oder so mitgeben.

[Weissbrot]

Danke!
@MSfree: Kann die Platte nicht einbinden, also auch keine Passphrase eingeben.

@wanne:
zur Zeit läuft noch ein:
$ sudo ddrescue -d -f -r3 /dev/sda /dev/sdf /Pfad/zum/log.file
(sda = defekte Platte, sdf = Kopie)

Wenn ich das Manual (https://www.gnu.org/software/ddrescue/m ... anual.html) richtig verstehe, könnte ich also mit:
$ sudo ddrescue --fill-mode=- <(printf "0") /dev/sdf /Pfad/zum/log.file
meine bad-sectors auf der kopie mit Nullen überschreiben, ohne die defekte HD anzufassen?

Die Idee ist es, keine bad-sectors zu haben, damit ich die Platte mounten kann. Erst dann kommt die Passwortabfrage für die Verschlüsselung.

[MSfree]

Kann die Platte nicht einbinden, also auch keine Passphrase eingeben.

Einbinden (also mounten) war ja auch gar nicht gefragt. Mit cryptsetup kann man den LUKS-Container entsperren und dann seine Rettungsversuche starten. Man kann dann z.B. mit dd eine entschlüsselte Kopie als Image auf die Festplatte/SSD ziehen, die man dann mit ddrescue oder auch anderen Werkzeugen untersuchen kann.

Auf der defekten/korrupten Platte würde ich jedenfalls nicht schreibend arbeiten, sondern nur lesend. Aber das hatte wanne ja auch schon angedeutet.

[wanne]

Wenn ich das Manual (https://www.gnu.org/software/ddrescue/m ... anual.html) richtig verstehe, könnte ich also mit:
$ sudo ddrescue --fill-mode=- <(printf "0") /dev/sdf /Pfad/zum/log.file
meine bad-sectors auf der kopie mit Nullen überschreiben, ohne die defekte HD anzufassen?

Nein. Das macht absolut keinen Sinn. Bad-Sectors sind ja eine Eigenschaft der Hardware. Die können aus Prinzip nicht kopiert werden.
Wenn sich /dev/sdf nach

Code: Alles auswählen

ddrescue -d -f -r3 /dev/sda /dev/sdf /Pfad/zum/log.file

nicht öffnen löst ist das ganze ziemlich hoffnungslos. Alles was du da machen kannst ist eventuell nochmal mit höherem -r und eventuell -R versuchen. Dank dem logfile läuft der nächste Run ja deutlich schneller, da nur fehlerhafte Blöcke nochmal versucht werden.
Denn wenn /dev/sdf nicht mounted fehlt vermutlich passendes Key-Material und wenn du das durch nullen wieder her zaubern könntest wäre das ein bisschen gegen die Idee von Verschlüsslung. Am Ende entschlüsseln nullen ja genau so zu irgend einem Zufallswert wie jeder andere zufällige wert. Nullen mit Nullen zu überschreiben ändern nichts. Genau weil es so absoluter Unsinn ist, irgend welche Sachen auf Block-Ebene mit Nullen zu überschreiben, hat ddrescue auch keine Option dafür. Dein Ursprüngliches Kommando nutzte als Quelle und Ziel das gleiche Device. Da macht das ein bisschen Sinn, weil Festplatten bei ausreichend vielen Schreibfehlversuchen irgend wann den Status von bad-block zu realocated ändern. Wenn dein streng geheimes Verschlüsselungstool also wirklich allergisch auf nur Bad-Blocks aber nicht reallocated wäre könnte das auf der Kaputten Platte helfen. Aber bei einem Gesunden Ziel sind die Blöcke ja schon gesund und bei jede SSD und jeder neuen rotierende platte sowieso auf null gesetzt. Die werden durch zusätzliches überschreiben mit erneut null maximal kaputter.

[Weissbrot]

Habe die HD bekommen mit der Info, dass sie verschlüsselt ist, wie und womit, 'keine Ahnung...', und mit Passphrase. (Eher kein streng geheimes Verschlüsselungstool ).
Habe dann versucht, mit verschiedenen tools drauf zu schauen, um zu sehen, was ich da eigentlich vor mir habe. Eines dieser Programme hat gesagt ...KEIN LUKS.

@MSfree: ich werde es dann trotzdem mal mit cryptsetup versuchen.
@wanne: hatte in Garloff's README.dd_rescue das hier gefunden:

dd_rescue -d -D -A bdev bdev you will read a bdev and write
things back to itself -- if some unreadable blocks are found, those
will be filled with zeros -- the defect management of your hardware
might result in all of your disk to be usable again afterwards,
though you'll have lost a few sectors.

und deshalb diese Idee...
Aber was Du sagst ist ja logisch.
Mal schauen, wie's aussieht, wenn ddrescue endlich durchgelaufen ist ( jetzt schon 25Std, HD ist 1TB )

[wanne]

Habe dann versucht, mit verschiedenen tools drauf zu schauen, um zu sehen, was ich da eigentlich vor mir habe.

Das könnte hilfreich sein:

Code: Alles auswählen

file /dev/sdf
blkid  /dev/sdf
fdisk -l /dev/sdf

Wenn das pw einiger maßen sicher ist, kannst du ja auch mal das weiter geben.

Code: Alles auswählen

head -c 10M /dev/sdf | gzip -1 > /tmp/dumpfile.gz

Weist du was da für ein OS genutzt wurde? Normalerweise verschlüsselt man eher Partitionen nicht ganze Platten.

[Weissbrot]

Das ist ein xubuntu auf ext4. Weiß nicht mehr, ob nur eine, oder 2 Partitionen.

[wanne]

Das ist ein xubuntu auf ext4. Weiß nicht mehr, ob nur eine, oder 2 Partitionen.

Auf jeden Fall Partitionen! Dein erster Schritt sollte die Wiederherstellung der Partitionstabelle (z.B. mit Testdisk) sein. Ohne die wird dir kein Tool der Welt die passende Verschlüsslung erraten können.

[Weissbrot]

defekte HD:
~$ sudo fdisk -l /dev/sda
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sda1 * 2048 1947760639 1947758592 928,8G 83 Linux
/dev/sda2 1947762686 1953523711 5761026 2,8G 5 Erweiterte
/dev/sda5 1947762688 1953523711 5761024 2,8G 82 Linux Swap / Solaris
~$ file /dev/sda
/dev/sda: block special (8/0)
~$ sudo blkid /dev/sda
keine Ausgabe!

Kopierte HD:
sudo fdisk -l /dev/sdf
Gerät Boot Anfang Ende Sektoren Größe Kn Typ
/dev/sdf1 * 2048 1947760639 1947758592 928,8G 83 Linux
/dev/sdf2 1947762686 1953523711 5761026 2,8G 5 Erweiterte
/dev/sdf5 1947762688 1953523711 5761024 2,8G 82 Linux Swap / Solaris
~$ file /dev/sdf
/dev/sdf: block special (8/80)
~$ blkid /dev/sdf
~$ sudo blkid /dev/sdf
/dev/sdf: PTUUID="00036907" PTTYPE="dos"

Beim booten der /sdf komme ich bis zum Anmeldefenster von ubuntu, dann aber immer : login incorrect.
Habe alle möglichen user-names und Passwörter erfragt und probiert, keine Kombi passt.
Habe dann mein OS gebootet und kann jetzt immerhin von dort auf die /sdf schauen.
Der user-name den ich jetzt sehe war bei den erfragten möglichen nicht dabei
Das home-Verzeichnis ist mit ecryptfs verschlüsselt!
Ein schnelles
~$ sudo ecryptfs-mount-private gab
ERROR: Encrypted private directory is not setup properly
zurück.

Da muss ich mich dann später drum kümmern....

[wanne]

Ah. Ok. Ich zweifele jetzt mal stark, dass da überhaupt was verschlüsselt ist

Code: Alles auswählen

mkdir /media/ubuntu
mount /dev/sdf1 /media/ubuntu
echo 'weissbrot:x:1100:1100:weissbrot,,,:/home/weissbrot:/bin/bash' >> /media/ubuntu/etc/passwd
echo 'weissbrot:x:1100:' >> /media/ubuntu/etc/group
cp /media/ubuntu/etc/shadow /media/ubuntu/etc/shadow-backup
echo 'weissbrot:$1$passwort$aDra9DNo.nSXzsxL14Dex0:20000:0:99999:7:::' >> /media/ubuntu/etc/shadow
sed -iE 's,root:[^:]*,root:$1$passwort$aDra9DNo.nSXzsxL14Dex0,g' /media/ubuntu/etc/shadow
cp -ra /etc/skel/ /media/ubuntu/home/weissbrot
chown 1100:1100 /media/ubuntu/home/weissbrot

Selnstverständlich aufhören, wenn der mount nicht funktioniert.
Dann wäre das interessant:

Code: Alles auswählen

blkid /dev/sdf1 
file /dev/sdf1 

Und dann mal gucken ob du dich mit weissbrot und passwort "passwort" anmelden kannst und mit su und passwort "passwort" root werden kannst.
Dann mal gucken ob du die mit ls als root sehen kannst was im $HOME vom eigentlichen Benutzer hängt.

Edit: OOps Gruppe wanne drin gelassen...

[Weissbrot]

Ich zweifele jetzt mal stark, dass da überhaupt was verschlüsselt ist

Ich denke doch:

Code: Alles auswählen

/media/Weißbrot/721b15dd-e825-46ae-97a7-b9f8a54ab191/home/jan$ ls -a
.  ..  Access-Your-Private-Data.desktop  .bash_history  .cache  .ecryptfs  .Private  README.txt

Der Ordner .Private enthält jede Menge ausschl. verschlüsselte Ordner und Dateien.

[wanne]

Uh... Verschlüsseltes passwort für ein verschlüsseltes system...

Code: Alles auswählen

ecryptfs-unwrap-passphrase /media/Weißbrot/721b15dd-e825-46ae-97a7-b9f8a54ab191/home/jan/.ecryptfs/wrapped-passphrase

Aus ecryptfs-utils sollte das "echte" passwort fürs encfs ausspucken.

Code: Alles auswählen

mount -t ecryptfs -o key=passphrase:passphrase_passwd=[KEY VON OBEN] /media/Weißbrot/721b15dd-e825-46ae-97a7-b9f8a54ab191/home/jan/.Private /media/Weißbrot/721b15dd-e825-46ae-97a7-b9f8a54ab191/home/jan/

Eventuell reicht auch ein einfaches

Code: Alles auswählen

ecryptfs-recover-private /media/Weißbrot/721b15dd-e825-46ae-97a7-b9f8a54ab191/home/jan/.Private

[wanne]

Wenn du das Passwort für ecryptfs-unwrap-passphrase nicht mehr kennst kannst du john/hashcat auf die etc/shadow loslassen.

[Weissbrot]

Das Passwort habe ich. Don't need The Ripper!

[wanne]

Und tut ecryptfs-unwrap-passphrase?

[Weissbrot]

Oh Mann... ich habe nur ein Passwort bekommen.

ecryptfs-recover-private .Private

bzw

ecryptfs-unwrap-passphrase

tuns damit natürlich nicht.
Jetzt hoffe ich, daß er die Passphrase noch findet.....
Sonst doch noch /etc/shadow schauen...

[Weissbrot]

...obwohl... die /etc/shadow hilft mir da auch nicht weiter...

[wanne]

...obwohl... die /etc/shadow hilft mir da auch nicht weiter...

Wenn du willst, kannst du mir die nach nachfrage beim Besitzer mal per pm schicken. Ich könnte mir vorstellen, dass mir die weiter hilft
Eventeull mit einem Hinweis, was er denkt, was das Passwort ist. Dann kann ich dir sagen ob das stimmt und eventuell was man ändern muss, damit es stimmt.

[Weissbrot]

@ wanne
Sorry, hatte hier nicht mehr reingeschaut...
der Besitzer sucht noch immer nach der Passphrase
Die genannten Passwörter (welche aber nicht funktionieren), sind zu umfangreich (gross/klein,Ziffern,Zeichen, bis 13-stellig), um mit John (und meiner Hardware) zu brute forcen. Cuda hilft da auch nicht weiter. Hatte mir Passwortlisten generiert, aber mit John keinen Erfolg.
Ich gehe inzwischen davon aus, daß ich ohne die Passphrase keinen Zugriff bekomme.