Versehentlich wiederhergestellter LUKS-Header im regulären Dateisystem

555
computer_geek64

Ich bin gerade in großen Schwierigkeiten, daher wäre eine sehr schnelle Lösung sehr zu schätzen. Ich befand mich in einer SSH-Sitzung auf meinem Laptop mit LUKS-Verschlüsselung, und ich dachte, ich würde den Header wiederherstellen. Später erkannte ich jedoch, dass ich tatsächlich SSH auf meinen Desktop hatte und versehentlich die LUKS-Header-Sicherungsdatei für die Wiederherstellung auf meinem Desktop verwendete, der keine LUKS-Verschlüsselung hatte. Jetzt kann ich überhaupt nicht in mein Dateisystem booten. Gibt es eine Möglichkeit, mein Betriebssystem oder zumindest meine Dateien abzurufen? Ich habe auch versucht, den Header zu löschen, sobald ich merkte, aber es hat nicht geholfen, der Header bleibt erhalten, nur die Schlüssel sind deaktiviert.

64-Bit-Dateisystem Kali Linux ext4, Dual-Boot mit Windows 10-Partition Bei der Kali Linux-Partition wurde der Header versehentlich überschrieben.

Der Befehl, den ich versehentlich wiederhergestellt habe, war: cryptsetup luksHeaderRestore /dev/sda5 --header-backup-file header.bak

0
Bitte fügen Sie Ihrer Frage keine Details in Kommentaren hinzu. Bearbeiten Sie Ihre Frage, um sie klarer und vollständiger zu machen. Scott vor 5 Jahren 0
Könnte testdisk versuchen. Oder Fotorec, um Dateien ohne Verzeichnis wiederherzustellen. Struktur & wahrscheinlich keine Dateinamen. Haben Sie danach gesucht, wie Sie mit ext4 überschrieben werden können, nachdem Sie zuerst 2M überschrieben haben? Xen2050 vor 5 Jahren 0

2 Antworten auf die Frage

0
Mark

Sie können wahrscheinlich fast alles wiederfinden, aber wenn etwas schief geht, könnten Sie sich schlechter fühlen, als Sie gerade sind.

Die Do-it-yourself-Option besteht darin, das Dateisystem aus einem der Backup-Superblocks wiederherzustellen:

  1. Machen Sie ein Festplatten-Image der beschädigten Partition und erledigen Sie Ihre gesamte Arbeit an diesem Image. Sie benötigen eine Festplatte mit ausreichend freiem Speicherplatz, um dieses Image zu speichern.
  2. Verwenden Sie losetupdiese Option, um das Bild als Loopback-Gerät einzurichten. Dies gibt ihm einen Gerätenamen wie /dev/loop0.
  3. Führen Sie mke2fs -ndas Loopback-Gerät aus, um herauszufinden, wo sich die Backup-Superblöcke befinden. Sie tun so, als würden Sie hier ein neues Dateisystem anlegen (die -nOption), um mke2fsIhnen sagen zu können, wo es sich befinden würde.
  4. Führen Sie e2fsck -n -b <insert a superblock address here>auf dem Loopback-Gerät nacheinander alle Sicherungs-Superblock-Adressen aus, bis Sie eine finden, die funktioniert. Hier geben Sie vor, das Dateisystem ( -nwieder) zu reparieren, um zu sehen, ob es funktioniert. Die Chancen stehen gut, dass Sie beim ersten Versuch erfolgreich sein werden.
  5. Führen Sie e2fsckdas Loopback-Gerät erneut aus, nur ohne die -nOption. Dadurch wird das Dateisystem so weit wie möglich repariert.
  6. Hängen Sie das Loopback-Gerät als Dateisystem ein und sehen Sie, wie stark der Schaden ist.

Wenn Sie dies getan haben, haben Sie zwei Möglichkeiten: Sie können die Schritte auf dem ursprünglichen Dateisystem wiederholen oder die gewünschten Dateien aus dem Image kopieren, das ursprüngliche Dateisystem löschen, Kali erneut installieren und die wiederhergestellten Dateien kopieren Dateien darauf.

Die sichere Option ist, Ihre Festplatte an ein Datenwiederherstellungsunternehmen zu senden. Sie führen im Wesentlichen die gleichen Schritte wie oben aus, aber da sie mit der Prozedur vertraut sind, werden sie nichts falsch machen. Dies wird wahrscheinlich einige hundert Dollar kosten.

Danke für die Hilfe. Ich denke, die beste Option ist jetzt, das Dateisystem wiederherzustellen und die Dateien in eine neue Kali-Installation zu kopieren, wie Sie sagten. Dieses Mal werde ich sicher STDOUT lesen, bevor ich Teile meiner Partition überschreibe. Können Sie auch etwas mehr über die Verwendung von `mke2fs` und` e2fsck` erfahren? Ich könnte es wahrscheinlich selbst aus den Manpages herausfinden, aber ich denke, es könnte besser sein, es auch von jemandem aus erster Hand zu hören. computer_geek64 vor 5 Jahren 0
0
Xen2050

Mount hat die Option, einen Sicherungs-Superblock ( -o b=40961z. B.) zu verwenden, also einen Befehl mit Nur-Lese-Zugriff und einen Ihrer Sicherungs-Superblöcke, z

mount -v -o ro,b=40961 /dev/sda5 mountpoint

Vielleicht ist es einen Versuch wert, zumindest schreibgeschützt, es sollte keinen Schaden anrichten und erfordert keine Kopie.

Ich habe versucht, ein kleines (50M) ext4-Dateisystem zu erstellen, etwa 34M in 40 Dateien darauf zu kopieren und dann die ersten 2M mit Nullen zu überschreiben (die Größe eines luks-Sicherungsheaders).

Der Befehl e2fsck (mit & ohne alle Sicherungs-Superblöcke mit auszuprobieren -b) konnte keine Dateien wiederherstellen. Vielleicht war es die geringe Größe und der relativ große Prozentsatz, der überschrieben wurde, aber obwohl es jetzt bereitstellbar war, waren keine Dateien vorhanden (selbst verloren + gefunden war leer). Eine andere Antwort ( https://superuser.com/a/1044614/307834 ) besagt, dass die Datei- und Verzeichnisliste möglicherweise überschrieben wurde und ein Backup-Superblock offensichtlich nicht hilft.

Photorec konnte jedoch 33 der 40 Dateien (ohne Dateinamen) wiederherstellen, 31 waren identisch, obwohl 2 geändert wurden (MD5-Nichtübereinstimmung). Hier ist ein Link zu Schritt-für-Schritt-Anweisungen. (Es werden auch die Backup-Superblöcke angezeigt).

Wenn Sie eine Sicherungsliste aller Dateinamen und einen Hash (wie md5 from find | md5sumoder sogar crc32) hätten, wäre es viel einfacher, die Dateien wieder mit ihren Dateinamen abzugleichen. Natürlich ist eine Sicherung der Dateien selbst am besten - nicht alle Systemdateien, sie können einfach heruntergeladen und erneut installiert werden, sondern nur Ihre persönlichen Daten und Dateien ($ HOME?) Und möglicherweise einige Konfigurationsdateien in / etc .

Jedenfalls, wenn jemand interessiert ist, hier ein paar Befehle, um eine kleine ext4 zu erstellen und sie zu brechen und die Wiederherstellung zu versuchen:

$ fallocate -l 50M 50  $ mke2fs -v -t ext4 -E lazy_itable_init=0,lazy_journal_init=0 50 mke2fs 1.43.4 (31-Jan-2017) fs_types for mke2fs.conf resolution: 'ext4', 'small' Discarding device blocks: done  Discard succeeded and will return 0s - skipping inode table wipe Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 12824 inodes, 51200 blocks 2560 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=33685504 7 block groups 8192 blocks per group, 8192 fragments per group 1832 inodes per group Filesystem UUID: b42aef3d-4e2a-44c3-8bb1-967968f61e38 Superblock backups stored on blocks:  8193, 24577, 40961  Allocating group tables: done  Writing inode tables: done  Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done  $ sudo mount -v 50 /media/50 mount: /dev/loop1 mounted on /media/50. $ cp -ar /usr/share/backgrounds /media/50/backgrounds # 40 files totaling 34M $ sudo umount -v /media/50  umount: /media/50 unmounted

Speichern Sie eine "gute" Originaldatei zum Vergleich

$ cp -v 50 50-bak '50' -> '50-bak'

Ohne die Konvertierung werden ddnur 50 Dateien mit einer mit Nullen gefüllten 2M-Datei überschrieben

$ dd if=/dev/zero of=50 bs=1M count=2 conv=notrunc 2+0 records in 2+0 records out 2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.00552528 s, 380 MB/s

Speichern Sie eine Kopie der beschädigten Datei, um es später erneut zu versuchen

$ cp -v 50 50-broken '50' -> '50-broken'

Wenn Sie "e2fsck 50" ausführen, wird das Dateisystem "repariert", beim Mounten werden jedoch keine wiederhergestellten Dateien angezeigt

Backup-Superblöcke abrufen / doppelt überprüfen

$ mke2fs -n 50 mke2fs 1.43.4 (31-Jan-2017) Creating filesystem with 51200 1k blocks and 12824 inodes Filesystem UUID: 7a31ebab-ddc2-40a6-89f6-39ecc26578cc Superblock backups stored on blocks:  8193, 24577, 40961

Die e2fsck-Befehle, die helfen sollten / sollen :

$ e2fsck -v -b 40961 50 e2fsck 1.43.4 (31-Jan-2017) Superblock has an invalid journal (inode 8). Clear<y>? yes *** journal has been deleted ***  Resize inode not valid. Recreate<y>? yes Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory. Clear<y>? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Root inode not allocated. Allocate<y>? yes /lost+found not found. Create<y>? yes Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(1--1875) +1878 +(8193--8450) +(24577--24834) +(40961--41218) Fix<y>? yes Free blocks count wrong for group #0 (6301, counted=6314). Fix<y>? yes Free blocks count wrong for group #2 (4096, counted=8192). Fix<y>? yes Free blocks count wrong (44438, counted=48547). Fix<y>? yes Inode bitmap differences: +1 +(3--10) Fix<y>? yes Free inodes count wrong for group #0 (1820, counted=1821). Fix<y>? yes Directories count wrong for group #0 (3, counted=2). Fix<y>? yes Free inodes count wrong (12812, counted=12813). Fix<y>? yes Recreate journal<y>? yes Creating journal (4096 blocks): Done.  *** journal has been regenerated ***  50: ***** FILE SYSTEM WAS MODIFIED *****  11 inodes used (0.09%, out of 12824) 0 non-contiguous files (0.0%) 0 non-contiguous directories (0.0%) # of inodes with ind/dind/tind blocks: 0/0/0 6749 blocks used (13.18%, out of 51200) 0 bad blocks 0 large files  0 regular files 0 directories 0 character device files 0 block device files 0 fifos 1 link 0 symbolic links (0 fast symbolic links) 0 sockets ------------ 1 file

Beim Mounten werden noch keine Dateien wiederhergestellt.
Versuchen Sie, direkt mit einem Backup-Superblock (-b) zu mounten, funktionierte dies mit keinem Backup-Block

$ sudo mount -vo ro,b=40961 50 /media/50 mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error  In some cases useful info is found in syslog - try dmesg | tail or so.  # Nothing in syslog/dmesg.

Verwandte Probleme