l0ck3d

Btrfs 数据卷：无密钥恢复的社区报告

社区报告称，在 Btrfs 数据卷上，部分加密文件的原始数据块可能仍残留在盘上。本页说明报告内容、验证边界和处置前提，不提供在原盘运行的步骤，也不承诺恢复结果。

内容复核日期：2026-10-30

本页是对社区报告的整理，不是官方结论，也不是恢复承诺。报告尚未经群晖官方确认，本站也未独立复现。

先说结论

  • 报告称：在 Btrfs 数据卷上，只加密开头 1 MiB 或分段加密的文件，原始数据块可能仍留在盘上，有机会在没有密钥的情况下取回。
  • 报告的最终统计：17,893 / 24,142 个被加密文件（约 74%）完成恢复。其中只加密开头 1 MiB 与分段加密的文件恢复率较高，整文件加密的小文件（1 MiB 及以下）几乎无法恢复。
  • 这不能推断你的数据一定能恢复。是否有机会，取决于文件系统类型、加密方式、剩余空间和写入是否已经停止。

报告内容（来源原文）

  • 环境：黑群晖实体机（非虚拟机），Btrfs 数据卷，DSM 7.2.1，机器 23 天未重启。
  • 时间：勒索信出现约 27 小时后才开始处置，加密进程已经不在。
  • 内存：整机内存约 15.86 GiB，扫描未找到可用的会话密钥。
  • 加密方式分类：0x26（只加密前 1 MiB）10,220 个；0x25（分段加密）7,197 个；0x24（整文件加密）6,725 个；共 24,142 个。
  • 最终结果：0x26 完整恢复 10,200 个（约 99.8%）；0x25 完整恢复 7,071 个（约 98.2%）；0x24 完整恢复 117 个。合计 17,893 个、约 274 GiB。
  • 早期的「约 99.9%」「约 99%」是处理过程中的阶段性数字，以上述最终结果为准。
  • 验证等级：格式级（文件头、完整解码、目视抽查），没有与原始文件的 SHA 比对。

来源：c3rb3r-rescue issue #12。报告作者的仓库中 README 状态为「已完成」，统计数字以该 README 为准。

为什么可能有效（本站整理）

Btrfs 修改文件时，通常把新内容写到新位置，旧数据块不会立即释放。如果加密只改了文件的一部分，其余未改写的部分仍然引用旧数据块。报告认为，只要旧数据块还有任何部分被引用，整块就不会被释放，被加密区段的原文可能仍在盘上。

  • 这是报告作者的推理（本站整理），需要专业人员在副本上逐个验证。
  • 整文件被加密时，旧数据块不再被引用，通常已被释放或覆盖，所以难以恢复。
  • 这个原理只适用于 Btrfs。报告称 ext4 不使用写时复制，改写通常直接覆盖原位置。

风险提示（先看这一节）

以下操作会缩小可恢复范围，或使原盘失去证据价值。

  • 不要删除 .L0CK3D 文件。删除后，原数据块可能失去最后一个引用，随后被释放或覆盖。
  • 不要做碎片整理、balance、空间回收或修复。
  • 不要把恢复结果写回同一个卷。
  • 不要在原盘上运行任何恢复工具，包括报告中描述的只读流程。本站不提供原盘操作步骤。
  • 继续往该卷写入数据（相册索引、同步、下载、录像等）会覆盖旧数据块。请尽快联系可信的技术人员，由其停止写入。
  • 社区工具未经本站审计，不要运行来源不明的解密器，也不要运行自称「L0CK3D 解密器」的程序。

**停止条件：**如果你无法确认卷的文件系统类型，或无法保证原盘不再被写入，请停止，不要自行操作。

自查：这个方法是否可能适用

  1. 确认文件系统是 Btrfs。 可以在 DSM 的「存储管理器」里查看卷信息，只查看，不修改。界面位置以你的 DSM 版本为准。如果是 ext4，这一路线基本不适用。
  2. 确认加密进程是否仍在运行。 若仍在运行，请先按机器仍运行处理，不要在本页操作。
  3. 确认被加密文件的类型分布。 这需要解析加密文件的页脚，普通用户无法自行判断，应交由专业人员完成。
  4. 确认是否有可用副本。 副本可以用于验证恢复结果，原件和副本都要保留。

如果群晖运行在虚拟机里

  • 可以在宿主机上复制虚拟磁盘，把副本作为操作对象。原盘和原始文件保持不动。
  • 复制前，是否需要先关闭虚拟机应由技术人员决定：如果加密进程仍在运行，关机会丢失内存；如果进程已经退出，仍应由专业人员确认后再操作。
  • 复制完成后，所有后续操作只在副本上进行。

待确认

  • 关机或断电后，此方法是否仍可用：报告未验证，本站标记为待确认。
  • 其他 DSM 版本、其他加密变种和其他文件系统的适用性：待确认。
  • 群晖官方是否认可该方法：未确认。

来源与边界