☰

在常规文件系统上意外恢复了 LUKS 标头

tag-icon • tag-icon linux unix encryption data-recovery luks
在常规文件系统上意外恢复了 LUKS 标头

我现在真的有大麻烦了，所以如果能有一个非常快速的解决方案就太好了。我当时在笔记本电脑上使用 LUKS 加密，我以为我正在恢复它的标头。但后来我意识到我实际上已经通过 SSH 连接到我的桌面，并意外地使用 LUKS 标头备份文件在我的桌面上进行恢复，而桌面没有任何 LUKS 加密。现在，我根本无法启动到我的文件系统。有什么方法可以恢复我的操作系统，或者至少恢复我的文件？我也删除了试图在我意识到后立即擦除标头，但这没有帮助，标头仍然保留，只是所有的键都被禁用了。

64 位 Kali Linux ext4 文件系统，与 Windows 10 分区双启动 Kali Linux 分区是意外覆盖了标题的分区。

我使用的意外恢复标题的命令是：cryptsetup luksHeaderRestore /dev/sda5 --header-backup-file header.bak

答案1

您可能几乎可以恢复所有内容，但如果出现问题，您可能会发现自己的情况比现在更糟。

自己动手的选项是从其中一个备份超级块恢复文件系统：

  1. 制作损坏分区的磁盘映像，并在该映像上完成所有工作。您需要一个具有足够空闲空间的硬盘来容纳此磁盘映像。
  2. 用于losetup将图像设置为环回设备。这将为其指定一个设备名称，例如/dev/loop0。
  3. 在环回设备上运行mke2fs -n以找出备份超级块的位置。您在这里假装创建一个新的文件系统（选项-n），以便mke2fs告诉您它将把东西放在哪里。
  4. e2fsck -n -b <insert a superblock address here>依次使用每个备份超级块地址在环回设备上运行，直到找到一个可以工作的地址。在这里，您假装修复文件系统（-n再次）以查看它是否有效。很有可能，您第一次尝试就会成功。
  5. e2fsck在回送设备上重新运行，但不带-n选项。这将最大程度地修复文件系统。
  6. 将回送设备挂载为文件系统，并查看损坏程度。

完成此操作后，您有两个选择：您可以在原始文件系统上重复这些步骤，或者您可以从图像中复制所需的文件，擦除原始文件系统，重新安装 Kali，然后将恢复的文件复制到它上面。

安全的选择是将您的驱动器送到数据恢复公司。他们基本上会执行与上述相同的步骤，但由于他们熟悉该程序，所以不会搞砸。这可能要花费几百美元。

答案2

Mount 有一个选项可以尝试使用备份超级块（-o b=40961例如），因此使用只读命令加上一个备份超级块，例如

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

可能值得一试，至少它是只读的，不会造成任何伤害，并且不需要复制。

我尝试创建一个小型（50M）ext4 文件系统，将 40 个文件中的约 34M 复制到其中，然后用零覆盖前 2M（luks 备份头的大小）。

e2fsck 命令（使用 & 而不使用 尝试所有备份超级块-b）没有恢复任何文件。也许是因为覆盖了较小的大小和相对较大的 %，但即使现在可以挂载，也没有文件（甚至 lost+found 也是空的）。另一个答案（https://superuser.com/a/1044614/307834) 表示文件和目录列表可能已被覆盖，显然备份超级块可能没有帮助。

但是，Photorec 能够恢复 40 个文件中的 33 个（没有文件名），其中 31 个是相同的，但有 2 个被更改（md5 不匹配）。以下是分步说明的链接。（它也将显示备份超级块）。

如果您有所有文件名和哈希值的备份列表（如 md5find | md5sum或 crc32），那么将文件与其文件名匹配起来会容易得多。当然，最好备份文件本身 - 不是所有系统文件，它们可以轻松下载并重新安装，而是您的个人数据和文件 ($HOME?)，以及 /etc 中的一些配置文件。

无论如何，如果有人感兴趣的话，这里有一些命令可以创建一个小型的 ext4 并破坏它并尝试恢复：

$ 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

保存原始的“好”文件以供比较

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

没有转换，dd只需用零填充的 2M 文件覆盖 50

$ 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

保存损坏文件的副本，以便稍后重试

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

运行“e2fsck 50”将“修复”文件系统，但挂载时未发现任何恢复的文件

获取/仔细检查备份超级块

$ 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

e2fsck 命令应该/ 可能有帮助：

$ 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

安装后仍未显示任何文件恢复...
尝试使用备份超级块 (-b) 直接安装，但无法与任何备份块配合使用

$ 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.

相关内容