Frage an die Crypto-Experten: Daten aus Luks-Container wiederherstellen
 

Hallo erstmal,

ich bin nicht sicher ob mir da jemand weiterhelfen kann - aber fragen kostet ja nix.

Folgendes Problem ist aufgetreten: ich hab in meinem System eine interne HD für das laufende System und eine externe für Backups.
Auf der backup Platte ist auch ein 500GiB Luks-Container der eine ext4 Partition enthält.

Nach einem System-upgrade bin ich plötzlich beim mount-Versuch auf die Fehlermeldung gestossen, daß der Superblock defekt sei.

Ich hab dann versucht eine Backup-Kopie vom Superblock zurück zu schreiben, aber es konnte keine Kopie gefunden werden.

Mein starker Verdacht ist, daß beim dechriffieren beim mount-Vorgang etwas schief gelaufen ist und deshalb die Daten quasi nur mehr 'verscrumbeld' vorhanden sind.

Auch ein Rettungsversuch mit foremost ist fehlgeschlagen: foremost -wt all hat keine einzige Datei auf der Partition resp. dem image davon gefunden.

Jetzt meine Frage: sind die Daten unrettbar verloren? oder gibts eine Möglichkeit doch noch an sie ran zu kommen?

Danke mal.

Kann gern Fehlermeldungen oder Details zu System u. ä. posten wenn jemand eine Möglichkeit sieht.

hi,

hast du die Fehlermeldungen noch? Wenn ja bitte posten

Den LUKS-Container kannst du nach Eingabe deines Passworts öffnen, ja? Probleme macht "nur" das ext4 filesystem, das in dem Container liegt?

Ja, Luks lässt sich öffnen - Probleme macht das ext4:

Hast du das Filesystem in eine img-Datei erstellt? :wtf:

Ich kenn das eher anders, man erstellt mittels LVM logical volumes im LUKS-Container, diese logical volumes bekommen dann ein filesystem wie ext4 oder so...

Poste mal die Ausgaben von blkid und lsblk

Wir wurde das ext4-Dateisystem denn immer gemountet? Poste daher auch mal am besten den Inhalt der beiden Konfigfiles /etc/fstab und /etc/crypttab

Nein - das filesystem liegt natürlich in einem 'LVM for encryption' ... das ist nur die backup-Kopie die ich aus dem Container 'raus gezogen habe weil ich nicht auf den original Partitionen herumfuhrwerken wollte:

oh man :eek: => Frage an die Profis: Datenrettung aus Luks-Container


Hättest ja mal nen Ton sagen können, dass du Crosspostings machst :balla:

Die Frage war ja nur ob man die verschlüsselten Daten retten kann - nicht das grundsätzliche zur Datenrettung. :abklatsch:

Ja, aber dann hätte man schon vorher gesehen was ihr da gemacht habt!
So lässt du die Helfer hier den gleichen Kram nochmal "erfinden" obwohl das schon längst durchgekaut ist :pfui:

Es kann dir auch niemand sagen was bei dem system-upgrade passiert ist. Sind da irgendwelche Logs zu da? Was genau hast du von was auf was hochgezogen? Und warum steckte eine Backupplatte während des Upgrades am System :confused:

Also ich hab gestern noch gesucht obs noch log-files gibt vom setup: aber ich hab die Platte nachdem Setup ja noch ansprechen können. Drei- oder viermal der Fehler ist erst danach aufgetreten. Und ohne ersichtlichen Grund: Es gab keinen Headcrash, keinen Stromausfall kein unsauberes umount oder sonstiges. Völlig unerklärlich.

Aber ich muß mich wohl damit abfinden daß die Daten weg sind. Was zwar schmerzt. Aber: that's life.

Wie sehen denn jetzt die Ausgaben von lsblk usw. aus wenn du den LUKS-Container entsperrt hast?

was genau sonst meintest du mit "usw"?

damit meinte ich blkid und auch den Inhalt von fstab und crypttab :)

dann noch die fstab ...

... und crypttab:

Gut. Ich "spiele" hier grad selber mit LUKS herum weil ich das auch nicht jeden Tag mache... :(

Fehlt da nicht sdb2? War das schon immer so? Ok, Nebenkriegsschauplatz :o

Wenn du "sauber" luksOpen /dev/sdb3 crypt-dm3 machen kannst ist das Thema ja gegessen,Partition /dev/sdb3 ist entsperrt und wird nach /dev/mapper/crypt-dm3 (unverschlüsselt) abgebildet. Dann müsste blkid auch nen Eintrag für /dev/mapper/crypt-dm3 haben und die UUID des Dateisystems anzeigen. Warum das Dateisystem dadrauf zerstört wurde kann ich dir jetzt aber auch nicht sagen :confused: (ohne unmount vllt rausgezogen? :wtf: )

Dateisystem auf sdb1 ist aber ok? Was war auf crypt-dm3, ext4?

Ist die Platte selbst denn noch okay? Was sagt ein smartctl?

Mehr fällt mir so auch im Moment nicht ein, es wurde ja auch schon so gut wie alles in deinem Thread in linuxforen.de auch schon probiert...

nein das war nicht immer so:

das hab ich jetzt so gemacht im Zug des - leider sinnlosen - Datenrettungsversuchs.

Auf der Platte waren vorher zwei ntfs-Partitionen (1&2) die ich dann - weil ich ja sowieso das win endgültig runter geschmissen hab zusammengelegt hab auf eine ext4 ... auch aus dem Grund weil ich eben sonst nicht genügend Platz hab um ein 500 GiB Image zu ziehen. Oder wenigstens 400 GB ... die Platte war ja sowieso nicht ganz voll.

Und die Platte ist in Ordnung: das paradoxe daran ist ja: ich hatte vorher eine ältere 250GiB HD und die hat dann angefangen so seltsame Geräusche von sich zu geben und I/O errors ... hab ich mir gedacht: upsi: schleunigst eine neue besorgen und hab die von der Platte auf die neue 1TB 'rüber gerettet. Die Platte ist nichtmal zwei Monate alt.

und weisst was: ich hab gestern nachgesehen ob ich nicht noch die alte herum liegen hab: und nein, hab ich entsorgt. :applaus::applaus::applaus::applaus:

es war ein ext4 drauf. Und so wie da angeführt wird, daß es anscheinend ein gängiges Problem ist daß Luks in Verbindung mit journaled ext4 Probleme macht kann ich jedem nur dringend empfehlen das journalling abzustellen wenn eine Luks-Partition mit ext4 erstellt wird. (hxxp://unix.stackexchange.com/questions/281349/mount-error-when-automounting-a-luks-encrypted-usb-flashdrive)

... bloss aus meiner leidvollen Erfahrung gesprochen.

Und genau das ist ja was mich so verduzt macht: es gab weder ein unsauberes umount, noch einen Stromausfall, oder einen headcrash oder sonst irgendeinen schreib-/lesefehler.
Die Partition war einfach nach einem reboot verschwunden. Fertig. ... wobei noch nichtmal veschwunden: einfach als unbekannter-Typ eingetragen.

... naja. was solls weg ist weg. ... ich werd die Partition aber trotzdem noch aufheben. vl stolpert ja in Zukunft jemand über einen Lösungsvorschlag.

... wobei der eigentlich Grund für das Cross-Posting war ja der, daß ich da den Thread über die Crypto-Trojaner gelesen hab und mir gedacht hab ich frag mal nach weil vl. gibt es eine Möglichkeit die Rohdaten zu dechriffieren so daß ich wenigstens mit foremost o.ä. etwas retten kann.

Immerhin weiss ich ja die Pass-Phrase und ich kenn die Methode mit der verschlüsselt wurde, weil ich das ja selbst erstellt hab. wobei ich mir nicht mehr sicher bin ob das jetzt 256aes oder 512 war. aber das könnte ich herausfinden.

florian0285 hat da einen Satz fallen lassen ... vl. kann ich das mal eruieren. beim -dd mit einer Pype über ccrypt leiten oder so in der Art. Eine Idee dazu?