LZ 猜测安全专家可能没想到微软的 Crypto API 居然没有清除掉内存中的质数，所以他们才没考虑 dump 内存的方法。
如果让 LZ 继续脑补，就是“阴谋论”了:如果 dump 内存的方法被广泛传播，潜在的勒索软件受害者可能未必把这条信息当回事，但勒索软件制造者倒是很可能在意这条信息，并开始思考如何应对内存 dump。所以，大家决定保持沉默，不把 dump 内存作为首选方法推广。更不用说通过休眠 dump 内存实际上是有“睡死”失败风险的……而且，病毒已经掌握机器控制权，什么都有可能发生，说不定检测到受害者想利用弱点进行破解，就直接撕票(比如删除私钥)。

@GNiux wanawiki 打错，应该是 wanakiwi

@GNiux 我说的不是这个思路。实际上，运行 360 的恢复工具 2.0 会直接干掉病毒的 tasksche.exe，然后 LZ 主帖说的工具 wanawiki 应该就不能工作了。

@gamexg 不过这个误删恢复的思路和本贴无关

@gamexg 就是有文件没被写 0 才有可能恢复啊。有一部分的确是被写 0 了，没救了。

@JJaicmkmy 但是断电是救不回已经加密的文件的。

@JJaicmkmy 这个早就确证了……应该有不少人手动验证过。360 不就出了恢复工具。

继续事后诸葛亮:
WanaCrypt 并没有重启的行为，休眠也同样可以阻止病毒继续运行传播，操作也相对简单，LZ 不知道为啥没看到安全厂商推荐大家休眠。
按理说专家集体犯错的可能性应该接近 0，那应该是出于某种考虑才没这么做。

@zwl2012 是的，dump 内存本应当没有作用，但病毒本地生成了 RSA 密钥对，而且微软的 CryptoAPI 有概率没把生成 RSA 密钥对的质数从内存中清除掉，所以才有现在的解锁工具 wanakiwi。

@zwl2012 而且即使逆向了病毒也有很大概率没 X 用，只要病毒生成密钥时没犯低级错误，就不可能直接破解密钥。

@zwl2012 RSA 是非对称加密没错，病毒作者也及时调用了微软的 CryptReleaseContext API 来清除本机的私钥。但他没想到微软的这个 API 不靠谱，实际上有概率没清除掉生成 RSA 密钥对的质数。(这是 LZ 看完那篇博客的理解)

@ctsed 事后诸葛地考虑一下，那些用着 32 位 XP 或 Win7 的中毒者如果及时 dump 了内存，现在解密工具出来了，他们就有更大的概率能找到私钥、解密文件了。

另外…… dump 内存这个思路，LZ 一个外行都能想到，那世界各大安全厂商的专家肯定早就考虑过这个吧。
那么，他们可能是出于什么考虑才没推广这种方法？

老实说这个思路不是我想出来的，来自于：
https://www.zhihu.com/question/46715248/answer/112125941

@ylsc633 别开玩笑……等病毒窗口出来，文件已经都成为绑票了。

@liaoyaoheng 是的，拼 RP 啊。而且如果是 SSD，很可能直接被 TRIM 掉了，啥也恢复不出来……

@Domains
已经有 Petya 这个 MBR 里的勒索软件了。蓝屏强制重启，重启时伪装成磁盘检查，实际上是执行加密。
不过它用了被弱化的加密算法，被安全研究人员爆破了，即使不爆破，加密的也只有 MFT，找个 DiskGenius 仍然可以扫出文件来……说这些都跑题了，如果 WanaCry 也想到类似的思路了，可能只是编程麻烦一些，能产生的危害可能比现在还大。

@Domains MBR Bootkit 完全可以做到一个文件不“落地”啊。
如果 MBR 是文件，那是不是能说一切皆文件……

@peng1994 虚拟机测试，虽然离加密只过去几分钟，但仍然有文件损坏。
所以……我觉得不太乐观。
如果是 SSD，大概直接会被 TRIM 掉……