Nachdem der Ubuntu-Installer meine Platte /dev/hda, die in verschlüsselter Form das Backup enthielt, durch die Installation von grub in den Bootsektor unbrauchbar gemacht hatte (LUKS-Header überschrieben). Musste ich mich an die Wiederherstellung der Daten von der Platte machen, auf die ich das System neu installiert hatte. Gott sei Dank hatte ich bei der Neupartitionierung meines Systems andere Partitionsgrößen gewählt, so dass noch Hoffnung bestand, dass die LUKS-Header der ehemaligen Partitionen intakt sein könnte. Meine Rettungsstrategie bestand darin, zunächst zu überprüfen, ob dieser Header noch vorhanden ist, um dann ggfs. über ein Loop-Back Device die Entschlüsselung vorzunehmen und zu schauen, ob noch etwas zu retten ist. Dazu verwendete ich die aktuelle Knoppix-CD.
Mein neues System hatte ich auf /dev/sda installiert. Im Zuge der Neuinstallation hatte ich vier Partitionen erstellt: /dev/sda1 bis /dev/sda4, die teilweise auch verschlüsselt sind. Auf der Platte /dev/sda musste ich also nach meinem alten LUKS-Header für die Datenpartition suchen. Bevor man jedoch mit der Suche loslegt, sollte man auf Nummer sicher gehen und die Partition in den nur-Lesemodus versetzen.
sudo chmod 400 /dev/sda*
Mit dem Hex-Editor hexedit suchen wir nun nach LUKS-Headern:
sudo hexedit /dev/sda
Mit der Taste <Tab> erstmal in den ASCII-Teil wechseln und dann mit der Tastenkombination <Strg>+<S> die Suche nach dem Wort LUKS starten. Sobald ich einen Header gefunden hatte, musste ich überprüfen, ob es ein Header der neuen verschlüsselten Partition war oder aber der meiner alten, den ich verzweifelt suchte. Dazu öffnete ich dann jeweils die anderen Partitionen im Hexeditor und verglich die Zeichenfolgen, die ein paar Bytes nach dem Schlüsselwort LUKS kommen.
sudo hexedit /dev/sda1
Nachdem ich an dem Offset 0x2E44CCC00 den entsprechenden Header meiner alten Partition gefunden hatte, musste ich noch herausfinden, wie groß die alte Partition war. Ich hatte Glück, da die Partition den gesamten Rest der Festplatte einnahm und somit 237639177216 Bytes groß gewesen sein musste.
Mit diesen Informationen kann man nun mittels losetup ein Loopback-Device erzeugen, das genau auf den Teil verweist, der die urpsrüngliche verschlüsselte Partition ausgemacht hat.
sudo losetup -o @0x2E44CCC00 -s 237639177216 /dev/loop1 /dev/sda
Nun kann man das Loopback-Device ebenfalls read-only setzen und mit cryptsetup öffnen
sudo chmod 400 /dev/loop1
sudo cryptsetup -d /path/to/key luksOpen /dev/loop1 cryptbackup
Die Partition können wir nun mit mounten mit einem
mount -t jfs -o ro /dev/mapper/cryptbackup /mnt/recover
oder als Image sichern (Achtung unverschlüsselt!)
dd if=/dev/mapper/cryptbackup of=/location/to/backup.img bs=10M
Den Fortschritt von dd kann man übrigens mit
while /bin/true; do sleep 5; kill -USR1 DD-PID; done
verfolgen.
Bei mir hat der Debian Installer nach meinem zu schnellen „Return“ die Partitionen neu geschrieben, obwohl ich nichts verändert hatte. Vier verschlüsselte Partitionen waren nach dem überschreiben der Header nicht mehr erreichbar.
Glücklicherweise konnte ich dank Ihrer Beschreibung die Partition mit Backups wiedergewinnen. Durch zurückschreiben des ersten Blockes der Partitionen konnte ich so drei der vier verschlüsselten Bereiche zurückgewinnen. Bei der letzen (natürlich der wichtigsten) wird allerdings mein „richtiges“ Passwort nicht akzeptiert.
Mittlerweile halte ich cryptsetup und LUKS für nicht ausgereift und nicht empfehlenswert.
Luks sollte für ein Recover zumindest ein Backup des Headers (besser mehrere) in der Partition selber speichern.
Cryptsetup sollte von sich aus via cron regelmäßig Headerbackups anlegen. Ausserdem müsste es möglich sein, die verschlüsselten Daten auch bei zerstörten Header mit dem richtigen Passort wieder herzustellen.
Wie ich bei Recherchen gesehen habe, bin ich nicht der einzig Blöde, dem solches widerfahren ist.
Vielen Dank für Ihren Artikel, hat er doch meinen Ärger und Schaden deutlich gemindert.
Adriana Teixera
@Adriana: schau mal in die manpage von cryptsetup. Die Möglichkeit des HeaderBackups/Recover gibt es …
[…] Lektion vom Wochenende, ohne CryptoHeader hat man kaum eine Chance. Eventuell kann man noch wie hier beschrieben versuchen zu retten, was zu retten ist und den Header selber “neu schreiben”. Das […]
@Adriana: Das Verfahren als unausgereift zu bezeichnen, wenn man selbst so „blöd“ ist, und den Header bewusst überschreibt, halte ich für ziemlich daneben. Es ist vielleicht nicht Idiotensicher, aber dafür _sicher_!
Die Ansage, es sollte auch ohne Header ein Restore möglich sein, zeigt, dass du nicht wirklich begreifst, wie das System arbeitet.
Hi,
danke für den Tipp, hatte auch die selbe Idee mit hexedit den luks Header zu finden nachdem testdisk kläglich versagt hat.
Der die Signatur für die Suche im Hexmodus ist btw 4C554B53BABE0001616573 nur Ascii LUKS suchen macht keinen Spass 🙂
Sollten die testdisk Jungs mal einbauen 🙂
Gruß,
Jan