soimy/c3rb3r-rescue

这个仓库是面向 Synology DSM 上 C3RB3R / .L0CK3D 勒索软件的事件响应手册与工具集，典型症状是文件被改名为 .L0CK3D、目录中出现 read-me3.txt。它写给受害者和管理员（或在授权下操作的 AI 助手），核心主张是先保全现场：加密进程的内存里可能仍保留解锁逐文件加密记录所需的材料。README 的流程依次是停住进程而不杀死它、隔离 NAS、采集内存、检查独立的密文副本，最后在干净环境中恢复服务（README、仓库）。

恢复原理

分析显示，该恶意程序为每个文件生成加密材料，用会话密钥保护后存放在文件末尾。若能从事加密进程的内存中提取该会话密钥，就无需攻击者私钥即可解锁这些尾部记录（README）。另一条路线完全不需要密钥：在 Btrfs 上，写时复制可能保留覆盖前的数据块，若文件未受影响的部分仍指向旧数据块，就有机会重建。这取决于实际 extent 映射、快照和后续写入，仅凭卷是 Btrfs 并不够（Btrfs 恢复指南）。

按情况选择路线

README 按情形分流。DSM 跑在 Proxmox VE 且仍开机时，从可信宿主机采集客户机内存，再离线搜索。物理机且加密进程仍活着时，先停住并确认所有线程已停，再保存进程内存，然后评估整机采集（物理机指南）。进程已消失但机器未重启时，尽快保存可用 RAM 和实际用到的 swap，但不能假定密钥仍在。没有可用密钥且数据卷是 Btrfs 时，保留现有快照并评估旧数据块恢复。已经断电或重启后，此前进程内存无法恢复；磁盘、已保存的转储和快照仍有价值（README）。

案例与边界

仓库自己的案例中，从内存恢复的密钥还原了约 49 GiB 的 GitLab 周备份，且与历史摘要一致，隔离还原恢复了 80 个项目（事件报告）。它还链接了一份独立的物理机报告，声称恢复约 84,500 个文件并用已知原件抽样核对（案例报告），以及无需密钥重建文件的社区 Btrfs 工具，但各次报告的验证程度不一（社区发现、Btrfs 工具）。这些工具针对一个已分析的样本和格式，结果并不通用。项目公开了自身案例中的一个恢复候选密钥，但目前没有证据表明它能解密其他受害者的文件（密钥共享）。

必须遵守的条件

README 警告：在保存内存前不要重启、关机、升级、重装或强制杀死加密进程，不要删除密文、快照或回收站内容，也不要把恢复的文件写回受影响的存储池（README）。命令级细节在技能参考和工具文档中（工具用法、工具验证）。仓库元数据未声明许可证，若打算在个人恢复之外复用代码，需要先确认这一点。成功没有保证；社区报告中也有找不到密钥的情况。