我现在知道这是一个愚蠢的决定，我尝试使用 windows 安装程序双启动 Windows 和 linux，在启动到 windows 安装程序后，我选择了 2 个大小约为 500GB 的克隆硬盘驱动器中的一个来擦除，因为它们是clone 如果我选择一个而不是另一个也没关系。
这样做之后，安装程序说它更改了其中一个 500GB 硬盘的分区表，然后无法安装 Windows。在没有复制文件的情况下因错误而崩溃，或者它说，当它说它甚至无法开始安装时，我不确定我是否可以信任它。
所以我启动到我的 linux 安装以检查它覆盖了哪个驱动器并手动安装它。相反，迎接我的是我的其他驱动器之一，一个 6TB dm-luks 和 btrfs 驱动器，丢失了。不仅两个 500GB 驱动器都没有动过，而且 6TB 驱动器似乎添加了一堆乱七八糟的分区。6个分区依次为499M、99M、499M、100M、499M、100M。
由于我的驱动器很大而且很慢，运行到目前为止hexdump -C /dev/sda |grep LUKS产生了这么多，我会在完成时更新：
8d411ce0 e1 ad 4c 55 4b 53 c0 85 22 3d de 49 dd 44 fd 08 |..LUKS.."=.I.D..|
e6449610 d5 cf 4a 86 9f cc 4c 55 4b 53 a9 a9 16 cc ba 1d |..J...LUKS......|
446ea9a70 b3 db a9 bf 8b 2e 41 4c 55 4b 53 ef f0 75 b0 18 |......ALUKS..u..|
4732c6040 e0 b3 bb ff 4c 55 4b 53 4c c2 5b 12 c6 41 fc d6 |....LUKSL.[..A..|
到目前为止，自从发生这种情况以来，唯一接触过磁盘的是 hexdump，我对运行 testdisk 犹豫不决，因为我听说它会覆盖驱动器上的数据，并且它不会将 luks 列为它可以搜索的内容。
我可以看到其他人使用 hexdump 来检查完整的标头，但是，我不知道我到底在寻找什么。
此时我能做些什么来查看是否可以恢复标头的任何位。有没有办法运行 testdisk 或其他工具来查找 luks 标头以判断它们是否已被覆盖？任何让我知道是否一切都是 FUBAR 的方式都与恢复我的数据的方式一样受欢迎。
编辑
在没有 grep 的情况下在驱动器的第一位上运行 hexdump 显示至少有一些完整的 JSON，从到00005000显示00005310同样多，我更不确定我现在特别寻找的是什么以了解它是否仍然完好无损。它似乎覆盖了数据直到这个确切的字符串。
00005000 7b 22 6b 65 79 73 6c 6f 74 73 22 3a 7b 22 30 22 |{"keyslots":{"0"|
00005010 3a 7b 22 74 79 70 65 22 3a 22 6c 75 6b 73 32 22 |:{"type":"luks2"|
删除中间的数据，因为它包含盐，但块结束于：
000052f0 22 2c 22 6b 65 79 73 6c 6f 74 73 5f 73 69 7a 65 |","keyslots_size|
00005300 22 3a 22 31 36 37 34 34 34 34 38 22 7d 7d 00 00 |":"16744448"}}..|
00005310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
它完好无损吗？
cryptsetup repair, 第二部分 — 完整标头恢复cryptsetup repair，第 1 部分 - 魔术字节恢复为了恢复部分覆盖的 LUKS2 标头，您至少需要两件事：第一，至少一个密钥槽的密钥材料。第二，描述如何使用密钥材料的元数据（算法、迭代计数、盐等）。
密钥材料是大约 256KB 的随机数据，通常位于偏移量 32768 (0x8000) 及以后，但是必须根据元数据确定确切的偏移量和大小。
元数据是一个 JSON 字符串，通常位于偏移量 4096 (0x1000) 和 20480 (0x5000) 处。LUKS2 维护它的两个相同副本（主要和次要标头）。密钥材料本身只存在一次。
如果分区表本身也丢失了，您还必须确定正确的分区偏移量。
设置：
一个闪亮的新加密文件系统！
损害：
所以这是一个带有 LUKS2 分区的 disk.img，偏移量未知，上面有损坏的标头（魔法字节已擦除，部分覆盖，分区表已擦除）。
元数据恢复：
由于 LUKS2 JSON 字符串是纯 ASCII，因此可以使用 找到它
strings，这也会显示偏移量：所以这里我们在偏移量 60837888 处有一个完整的 JSON 字符串。将其复制并粘贴到
header.json文件中。该文件应以 开头{和结尾}。您可以使用它jq来确保它确实是一个有效的 JSON 字符串，并以更易于阅读的形式显示它：分区恢复：
LUKS2 标头中 JSON 元数据的偏移量通常为 4096 或 20480，具体取决于它是主标头还是辅助标头。您必须从
strings之前找到的偏移量中减去这些值。因此，在这种情况下正确的分区偏移量可以是
60837888 - 4096 = 60833792 = 58.02MiB或60837888 - 20480 = 60817408 = 58 MiB。由于后者是 MiB 对齐的，因此它更有可能成为正确分区偏移的候选者。如有疑问，请尝试两者。
关键材料回收：
根据 JSON 元数据，此 LUKS2 标头具有单个密钥槽，其密钥材料位于
"offset":"32768","size":"258048". 让我们抓住它dd：如果有多个键槽，请对每个键槽重复此过程。
密钥材料应该看起来像随机数据。要验证这一点，您可以使用
hexdump -C.或者您可以尝试压缩它并查看压缩结果是否更小：
随机数据通常根本无法压缩，所以如果 gzipped 版本没有变小（甚至大几个字节），那么整个数据很可能是随机数据。
真正的验证只有在最后才有可能——当它接受或不接受你的密码时。
完整标头恢复：
在你收集了上面的必要成分后，你可以尝试从中重建一个完整的标题：
使用 cryptsetup 生成一个有效但不可用的没有密钥槽的标头。这里的目的是获取一个文件，该文件设置了所有正确的魔术字节、UUID 等——与加密无关，但它是使 LUKS 标头成为 LUKS 标头的原因。
现在将您的元数据移植到它上面：
以及关键材料：
在这一点上，我们终于完成了，除了：
校验和恢复：
咦，现在怎么了？添加
--debug以了解：LUKS2 的主要和次要标头有一个校验和。由于我们在没有更新校验和的情况下修改了 JSON 元数据，因此这是不匹配的。值得庆幸的是，cryptsetup 显示了预期值，因此我们不必手动计算它。
此校验和是二进制标头的一部分，因此您必须使用
xxd -r -p它来将其转换为二进制：用正确的内存校验和替换错误的磁盘校验和：
这应该能让事情继续进行。
总结一下：
完毕。最后。