点击上方蓝字关注我们，文末有惊喜～
我们的文章会在微信公众号“Oracle恢复实录”和博客网站“rescureora.com” 同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
说到病毒，现在我们立马就会想到“新型冠状病毒”，会想到“武汉加油，中国加油”。
作为一名Oracle DBA，提到病毒，我们还会想起近些年来，在windows平台上大量爆发的“比特币勒索病毒”，它对人体无效，但是它曾导致某国的交通系统被感染，出现交通系统瘫痪，也曾导致某省的国土资源厅系统被感染，不动产系统长达10天之久不能正常对外提供服务。
问
那么，比特币勒索病毒它是什么呢？
答
它其实是一类软件，此类软件对指定文件按照配置的规则进行加密。加密完成后，会提示文件已经加密，如需解密，就转***比特币，所以我们称之为“比特币勒索病毒”。
问
它加密的软件一定需要给比特币才能解密吗？
答
答案：肯定不是的，否则就不会有今天的文章了。
比特币勒索病毒已经由原来刚出来的一款软件变化到今天的很多款软件，每款软件的加密规则都不一样，但是原理是类似的。对符合条件的文件，按照指定的格式加密，生成新的文件，新文件名为原文件后加上.xxxx(加密程序不同后缀也不同)，如文件1.txt，经加密程序加密之后将变成1.txt.xxx，同时删除原来文件。
如果加密的文件是Oracle数据的数据文件，那么整个Oracle数据库就不能打开。
问
此时我们能向黑客低头吗？
答
肯定不能的。
如果你很不幸遇到这样的case，别慌张，可以找我们，让我们一起来帮你分析。
针对比特币勒索病毒加密Oracle数据库的不同文件，对数据库的影响，我们做了如下的总结：
数据库软件被加密 -- 无所谓，重新安装一个oracle软件就好
oracle控制文件和redo被加密 -- 此时控制文件和redo都没有那么重要了
oracle数据文件被加密 -- 这是我们需要分析的重点，也是恢复的重点
目前我们遇到常见的比特币勒索病毒有很多种，并且还在不断的新增，加密规则也在不断的发生变化，对加密规则做如下的总结：
文件前1M加密(本文将模拟该情况)
文件前2M加密
8k间隔加密
文件首尾各加密1M
等等。
通过我们以前恢复的经验，加密程序通常并不会对全文件进行加密，我们完全可以通过工具或者一些特殊手段将大部分未加密的数据抽取出来，以实现最大程度的恢复。
也相信加密工具不会对数据文件全部加密，原因很简单：如数据文件大小为32G，如全部加密，那么加密完第一个时就会删除第一个元数据文件，此时Oracle数据库就会立马报错，数据库文件自动offline，甚至数据库实例也会crash。
下面我们就恢复的基本思路和确认加密的算法做一个简单的实操，当然我们还会在后面引入真实的案例来说明。
恢复的基本思路：
1.确认文件加密范围，用于评估恢复比例和恢复难度
2.使用工具来进行抽取，本文还是推荐使用odu，如果没有听说或者没有使用过的朋友可以访问www.oracleodu.com进行了解
模拟故障现象：
确认文件加密范围
确认文件加密范围，每一个数据文件加密的算法和范围都是一样的，所以只需要分析oracle的system数据文件即可。
我们使用 check.sh 脚本进行检查，可以从以下结果看出：从文件头开始到第127个块全部被加密。
[oracle@rescureora ~]$ nohup sh check.sh '/u01/app/oracle/oradata/rescureora/datafile/o1_mf_system_gy6tfgvc_.dbf' 8192 &
[1] 3578
[oracle@rescureora ~]$ nohup: ignoring input and appending output to `nohup.out'
[oracle@rescureora ~]$ cat error.log
1-127 block was Encrypted!
手动划重点！！！！
我们首次公开分享check.sh脚本内容，请扫码图片上面二维码关注我们的公众号，并在后台回复关键词：“check.sh”，你便可以得到确认文件加密范围的check.sh脚本的全部内容！
这里补充一个LMT的数据文件的基础常识：
文件开头存放的是数据文件头和文件位图块等元数据块，不同的blocksize文件位图块个数不同：
8k：前128个块是元数据块(其中2-127是文件位图块)
16k：前64个块是元数据块(其中2-63是文件位图块)
32k：前32个块是元数据块(其中2-31是文件位图块)
共同点就是不管blocksize为多少，数据文件的前1M都是数据文件的元数据块，包括OS块，数据文件头，文件位图块。
恢复比例和难度评估：
从脚本error.log输出结果来看，只是文件前1M被加密，所以并不会丢失任何数据。甚至可以手工构造文件头强制open数据库然后exp导出。本文演示使用odu工具来抽取。
配置odu control.txt
配置好odu control.txt之后，申请lisence。
unload dict
由于1号文件文件头损坏，unload dict不能找到rootdba，需要手工指定block。
unload user
前1M加密的恢复非常简单，如果加密的更多，则需要通过构造odu字典信息进行抽取，极端情况下需要提供表结构来手工构造(所以有一套和生产库表结构一模一样的开发库或者测试库还是有好处的)，过程也非常麻烦，但恢复思路还是不变的。
Oracle恢复实录
rescureora.com
欢迎扫码关注
让我知道你在看
