解密工具跑完，文件后缀恢复正常了，双击却提示格式错误、内容乱码，或者数据库怎么都附加不上——这时候最该做的事只有一件：停止在这批文件上继续运行任何解密器、修复工具或杀毒软件的"修复"功能。
原因很直接。解密和修复都是写操作，每跑一次，就在已经受损的数据上再覆盖一层。真正决定你还能恢复多少的，往往不是找到哪个神奇工具，而是现在手里还剩几份没被反复折腾过的原始数据。
先把能留的东西留下来
在做任何判断之前，按这个顺序保全数据：
- 如果还保留着加密状态的原始文件或原盘，立刻单独复制一份，设为只读，放到另一块盘或另一台机器上。 这份是后面所有补救的底牌。没有它，很多路径直接就断了。
- 当前解密出来但打不开的文件，也单独复制一份留存。 它和加密原件是两个不同的证据，别为了腾空间删掉其中一个。
- 把解密工具的日志、输出窗口截图、勒索信、工具文件名和版本记下来。 很多解密器会在日志里列出 Failed / Skipped / Error 的文件清单，这份清单是判断问题性质的关键材料，关掉窗口就没了。
- 后续所有尝试，都在复制出来的副本上做。
如果机器还在域内或还连着共享盘，先确认加密行为确实已经停止，再谈恢复。还在扩散的情况下折腾文件没有意义。
第二步：确认文件到底解没解开
"打不开"至少对应两种完全不同的状态，补救方向相反，必须先分清。
找一份打不开的文件，复制出来，用十六进制编辑器（HxD、010 Editor 之类）以只读方式打开副本，看最前面十几个字节：
- docx / xlsx / pptx / zip 开头应该是
50 4B 03 04（可见字符 PK） - 旧版 doc / xls / ppt 是
D0 CF 11 E0 A1 B1 1A E1 - PDF 是
25 50 44 46（%PDF） - JPG 是
FF D8 FF - PNG 是
89 50 4E 47
如果开头就是正确的特征字节，说明文件确实被解开了，问题出在文件内部结构损坏，属于"解坏了"。
如果开头仍是毫无规律的随机字节，或者还能看到勒索家族的标记字符串、联系邮箱，那就是根本没解密，只是后缀被改回了原样。这种情况在两类场景里很常见：有人批量跑了个重命名脚本去掉 .locked 之类的后缀；或者解密器对这批文件实际是跳过的，只做了改名。碰到这种，不要再试任何格式修复软件，方向完全错了，要回到"能不能解密"这个问题上重新判断。
真的解开了却打不开，常见是这几种原因
用了不匹配的解密工具或错误的密钥
同一个家族的不同编译批次，密钥派生方式都可能不一样。拿一个"名字看着对"的通用工具去强行解，结果是把密文按错误算法再算一遍，输出一堆不可逆的乱码，并且把原文件覆盖掉。这也是为什么前面强调必须留加密原件——只要原件还在，这次失败就只是浪费时间；原件没了，这批数据基本到此为止。
如果你是在工具提示阶段就卡住的，判断思路可以参考解密工具提示"不支持该文件"的几种原因。
解密器本身有缺陷
攻击者写的解密器普遍没有经过严格测试，公开工具也可能只覆盖部分变种。实际遇到的问题包括：大文件的解密偏移量算错，只有前几兆是正常的；对间歇加密（只加密文件的若干片段）处理不完整，解出来的文件一段好一段坏；文件尾部的元数据被破坏，导致工具判定"无需解密"直接跳过；填充字节没有正确去除，文件尾多出一截垃圾数据。
这类问题的特征是成批出现且有规律——比如所有超过某个体积的文件都坏，小文件全正常。这时候去翻解密日志的跳过列表，比再跑一遍有用得多。
加密当时就被打断了
如果最初发现中招时直接拔了电源、强制关机，或者杀软在加密进行到一半时把进程干掉了，被处理到一半的文件就停在"写了一半"的状态。这种文件即使解密流程完全成功，还原出来也是残缺的。补救方向是按文件格式做结构修复，而不是再去找解密工具——重复解密对它没有任何帮助。
被加密了不止一次
失陷窗口拖得久的系统，可能先后被两个不同家族加密，或者同一家族的多个投放批次重复处理过同一批文件。这时候解密器只剥掉了最外面一层，里面还是密文。判断依据同样是文件头：解完之后的头部如果呈现出另一种规律性的异常，而不是正常格式特征，就要考虑复合加密，需要重新做家族识别，按顺序逐层处理。
数据库和虚拟机是另一类问题
SQL Server 的 mdf/ldf、MySQL 的数据目录、Oracle 数据文件，以及 vmdk / vhdx 虚拟磁盘，加密发生时如果正处于活动读写状态，底层会留下页撕裂、索引断裂、事务日志与数据文件不一致这类损伤。这些损伤和加密是两回事，解密工具还原出正确的字节流之后，它们依然在。
所以数据库解密完附加失败、虚拟机解密完引导不起来，是常见结果，不代表解密失败。但处理上有几条红线：
- 不要在唯一一份文件上执行数据库的强制修复命令（比如 SQL Server 那条会丢数据的 repair 选项），也不要反复 attach / detach。先完整复制出副本再动。
- 不要在原 datastore 上直接对虚拟磁盘做合并、修复或快照操作，应先做整盘镜像。
- 财务类账套还要注意，数据文件、日志文件和备份文件缺一都会影响重建路径，具体可以对照用友账套被加密后必须保留哪些文件那篇的清单自查一遍。
这类文件真正的恢复方式，是在页级别提取仍然完整的数据区，重新校验并重建结构，再把能救回的业务数据导入到新实例。这需要对应数据库的底层结构知识，不是通用修复软件能处理的范围，必要时可以让人先做一次数据库与业务数据的恢复评估，确认哪些表、哪个时间点的数据还有价值，再决定投入。
解密之外还剩哪些路
如果确认这批文件已经被破坏到无法还原，别急着下"全没了"的结论，先把这几处翻一遍：原机的卷影副本、业务系统自带的定时备份目录、离线或异地备份、同事本地留的旧版本、邮件附件和网盘里的副本、数据库自身的 bak 文件。实际处置中，靠这些凑回大部分可用数据的情况并不少见，思路可以看没有免费解密工具时还剩哪些恢复路径。
另外提醒一句：文件解开了不等于系统干净了。尤其是使用攻击者提供的解密器之后，这台机器的后门、残留账号、计划任务都还在，恢复出来的数据放回去，有可能再被加密一次。恢复和清除要当成两件事分别验收。
什么时候该让人来看
下面几种情况，继续自己试的风险大于收益：
- 加密原件已经被覆盖或删除，现在只剩解密后的损坏文件；
- 核心数据是生产数据库、ERP 账套或虚拟机，而且没有可用备份；
- 解密后文件头显示仍是密文，家族归属不明确；
- 已经用多个来源不明的工具在同一批文件上跑过，不确定被改成了什么状态。
这几种都需要先做一次可恢复性判断，而不是继续换工具试。先确认家族和变种、确认文件当前的真实状态、确认还有哪些可用副本，再决定走解密、底层恢复还是备份重建。我们在勒索家族识别与可恢复性评估这个环节就是做这件事：先看清楚还剩什么，再说方案。
找外部处理时，判断对方靠不靠谱的方法也很简单——能不能说清你这批文件现在是什么状态、为什么打不开、准备走哪条路径，而不是先报一个数字。更细的判断要点可以参考怎么判断解密方案靠不靠谱。
最后回到开头那句：在搞清楚文件处于哪种状态之前，少动它。手里还剩几份没被覆盖的原始数据，决定了后面所有选项的上限。
评论(0)