群晖NAS被勒索，仅需1元就能把文件救回来！

这个技能是干什么的： 无密钥恢复被 C3RB3R（.L0CK3D、勒索信 read-me3.txt）加密的群晖/Btrfs NAS 文件 —— 利用 Btrfs 写时复制残留的旧 extent 还原原文，并用 Btrfs CRC32C 逐块验证。

触发方式（直接说中文即可）：

我的群晖 NAS 被勒索了，文件都变成 .L0CK3D，没有快照也没有备份，帮我看看能不能恢复

⚠️ 技能内置的最重要原则：不要删除/覆盖任何 .L0CK3D 文件，不要清空回收站，不要 defrag/balance/btrfs check --repair —— 旧数据块正是靠密文文件引用才没被回收。

需要我现在读一下它的完整执行流程，或者帮你对某台 NAS 跑 preflight 自检吗？

2026-11-03 23:49:06 · 我

我的群晖NAS被勒索了，文件都变成.L0CK3D，没有快照和备份，帮我看看能不能恢复

2026-11-03 23:49:30 · 助手

明白了。这是时间敏感的救援，先别做任何"清理"动作。按技能流程，第 0 步决定成败：如果加密进程还活着，从内存拿密钥可以解开全部文件，远好于 Btrfs 旧数据块路线。

请告诉我这些信息（我才能开始自检）

1. 攻击大概什么时候发生？ NAS 之后重启过吗？现在还在运行吗？
2. NAS 型号 + DSM 版本（控制面板 → 信息中心）
3. 存储空间是什么文件系统？（存储管理器里看，必须是 Btrfs；ext4 不适用）
4. SSH 是否开启？（控制面板 → 终端机和 SNMP）管理员账号是什么（密码先别发在聊天里，我们改用 SSH 密钥或交互输入）
5. NAS 的局域网 IP，以及是否同一网络可达
6. 受影响的共享文件夹有哪些（如 homes、photo、docker…），大概多少数据？
7. 每个共享建的时候有没有勾选"数据校验和"？（这个决定能否逐块证实恢复结果）
8. 导出目标盘：一块 NAS 以外的硬盘，剩余空间至少等于要恢复的数据量
9. 有没有"已知原件"？比如手机/云盘里还留着某个同名同大小的原文件 —— 有的话可以做单文件精确验证，这是继续批量恢复的前提

2026-11-04 00:02:27 · 我

1.攻击时间是10月28日

2.NAS型号是218+,7.2系统

3.Btrfs文件系统

4.ssh开启了，账号：****

5.IP:169.254.85.14

6.主要是photo，大概80GB，只需要恢复/volume1/photo里面的文件就行了

7.不确定

8.导出到/volume2/115这个目录可以吗

9.好像没有，你尝试恢复一个，我试试能不能打开就知道了

2026-11-04 00:02:30 · 助手

收到。先做连通性和环境确认——注意 169.254.x.x 是链路本地地址，需要确认这台电脑能不能路由到它。同时先查一下 NAS 上还有没有加密进程残留。

2026-11-04 00:03:26 · 助手

SSH 通了，但需要认证。请在你自己的终端里执行下面这一条（会提示输入一次密码），把专用公钥装到 NAS 上：


看到 KEY_OK 就告诉我。之后我全程用密钥操作，不再需要你的密码。

同时纠正两件事

#8 不要导出到 /volume2/115。 原因：

• 技能红线是"恢复结果写到 NAS 以外的盘"，避免任何写入占用 volume1 上可能还存着旧数据的空闲块。
• 即使 volume2 是第二块物理盘，写 80GB 也有风险（DS218+ 双盘位，若做了 SHR/RAID1 就是同一存储池）。
• 工具本来就是通过 SSH 把数据流直接传回本机，不在 NAS 上落任何文件。本机 D 盘还有 251GB 空闲，足够。

导出目录我会用：D:\c3rb3r-recovery\photo

2026-11-04 00:08:30 · 我

密码我直接给你，我改了一个简单的密码，********， 那就导出到本机D盘，机器重启过了

2026-11-04 00:08:31 · 助手

机器重启过，那内存密钥路线就没戏了，直接走 Btrfs 旧数据块路线。我先把钥匙装好。

2026-11-04 00:08:51 · 助手

密钥装上了但没生效——DSM 的****家目录不存在（用户主目录服务没开）。我确认一下实际路径和 sshd 配置：

2026-11-04 00:09:19 · 助手

钥匙生效了 ✅（**** 在 administrators 组）。现在开始只读侦察：

2026-11-04 00:09:38 · 助手

环境确认：DSM 7.2.2、photo 下 12,256 个 .L0CK3D、加密进程已不在（符合重启过的情况）。现在跑只读自检 preflight：

2026-11-04 00:10:02 · 助手

G 值非常干净：

• 攻击期新写入代数：12,499,778 ~ 12,508,121
• 攻击前最近正常写入：8,080,473（中间有 440 万代空档，无混淆）
• 建议 G_ATTACK = 12,499,762
• photo 共享：CoW、lastsnap=0 → 走精确恢复路线

现在做单文件原理验证。先挑一张 2MB 以上的照片（大于 1.004MB 基本可精确恢复）：

2026-11-04 00:10:15 · 助手

单文件 plan 结果非常理想：status = exact，被改写的 1,048,659 字节全部映射回旧 extent（gen=133545，攻击前的原始数据），边界自校验 bchk_bad=0。现在导出并用 CRC32C 验证：

2026-11-04 00:10:43 · 助手

✅ 第一张照片恢复成功，三重验证全部通过：

CRC32C 是 Btrfs 自己存的校验和，256 块全对基本可以确认恢复出的就是原始明文。照片发给你，先确认能否打开、内容是否正确：

MEDIA:D:\openclaw9.9.1_win\data.openclaw\workspace\tmp\single_out\volume1\photo\WeiXin\mmexport1547021674.jpg

全量普查已经在后台跑起来了（12,256 个文件，只读，预计 20–60 分钟）。跑完我会给你统计：

• exact：可精确恢复并可校验证实（预计占照片/视频的大头）
• needs_inference：只能推测，需靠解码挑选
• no_candidate / inplace_lost：救不回（主要是 1MiB 以下小文件和数据库）

你确认照片没问题后，我就按普查结果分批导出到 D:\c3rb3r-recovery\photo。

2026-11-04 00:11:48 · 我

太厉害了，图片没错，继续恢复其他文件吧

2026-11-04 00:11:50 · 助手

照片确认无误，那就继续。先看普查进度：

2026-11-04 00:20:17 · 助手

普查完成 ✅ 12,256 个文件全部扫描。生成统计：

2026-11-04 00:20:39 · 助手

普查结果非常好：

可恢复的是 7,405 张 JPG、1,209 个 MP4、538 个 MOV、38 个 PNG、2 个 GIF。现在开始分批导出（共 12 批，每批 800 个文件），边传边解包、边算 SHA：

2026-11-04 00:22:07 · 助手

导出已经在后台跑了。当前进度（约 5 分钟）：

• 389 / 9,192 个文件，3.05 GB / 86.3 GB
• 速度约 11 MB/s（受 NAS 机械盘随机读限制，旧数据块分散在盘上）
• 预计全程约 2 小时，12 批依次执行

后续会自动完成，无需你盯着：

1. 每批边传边解包、边算 SHA-256
2. 全部导出后跑 CRC32C 逐块校验（exact 文件的最终证据）
3. 图片/视频完整解码验证
4. 出恢复报告，并列出救不回的 3,040 个小文件清单

我会在约 20 分钟后自动汇报一次进度。导出期间请继续不要动 NAS 上的 .L0CK3D 文件、不要重启、不要跑 balance/defrag。

输出目录：D:\c3rb3r-recovery\photo

2026-11-04 01:16:25 · 我

是完成了吗，怎么好像没在执行了

2026-11-04 01:16:41 · 助手

导出已经完成了 —— 12 批全部成功，9,192 个文件、80.4 GiB（= 统计里的 86.3 GB）都在 D:\c3rb3r-recovery\photo。后台会话被系统回收了，但任务本身已跑完。现在进入校验阶段。