数据库遭遇.dewar或者.devos结尾的勒索病毒加密的恢复

标签：dmp文件   不能   res   dbf   数据   有一个   后缀名   类型   evo   

通过对底层存储数据的解析，发现该病毒有如下特点：

1. 会对服务器上后缀名为dbf、mdf、ibd的文件进行全加密。
2. 对其他类型的文件进行破坏，破坏规则为从文件头部开始清空256k，并且每间隔10g清空256k。

该病毒非常狡猾，会判断文件类型，专门对数据库数据文件进行全加密，这也让从加密的数据文件中抽取数据变成了一件不可能的事情，唯一的解决方法，就是找***解密。

在对加密文件分析过程中，我们发现该病毒并不会对rman备份文件或者expdp/exp的dmp文件进行全加密，这类文件会从文件头部开始清空256k，并且每间隔10g清空256k。这让我们的恢复产生了一些转机，可以通过rman备份或者dmp文件进行恢复。在本次案例中我们就是利用被加密后的文件来恢复客户的数据库。

2，利用RMAN备份还原数据库
咨询了客户是否有备份，客户防患意识非常好，定期对数据库做了rman备份。

2.1 分析RMAN加密后的文件
截取备份片前1G简单通过dd分析一下：

[root@test ~]# dd if=rman_1G.bak bs=8192 count=32|od -x
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
32+0 records in
32+0 records out
262144 bytes (262 kB) copied, 0.00326108 s, 80.4 MB/s

不出所料前256k确实被清空了。而且每隔10g还会清空256k(当然这里我们只截取了1g来分析)。

[root@test ~]# dd if=rman_1G.bak bs=8192 count=1 skip=129|od -x|head -1  
0 records in
0 records out
bytes (8.2 kB) copied, 6.2713e-05 s, 131 MB/s
a238 0000 0081 0040 d899 ed66 0da3 0401
[root@test ~]# dd if=rman_1G.bak bs=8192 count=1 skip=130|od -x|head -1  
0 records in
0 records out
bytes (8.2 kB) copied, 4.6691e-05 s, 175 MB/s
a238 0000 0082 0040 d899 ed66 0da3 0401
[root@lx ~]# dd if=rman_1G.bak bs=8192 count=1 skip=131|od -x|head -1 
0 records in
0 records out
bytes (8.2 kB) copied, 8.2504e-05 s, 99.3 MB/s
a238 0000 0083 0040 d899 ed66 0da3 0401

查看备份片后面一些的block发现块类型为0x38，当时有一种不良的预感，该备份很是压缩的备份集。这给整个恢复带来了非常大的难度。

rman备份默认采用basic压缩，测试使用的压缩算法为bzip2，有了此信息后，我们可以通过手动的方式将加密后的压缩文件进行解密。

3，还原的思路和过程
经过长达几个小时的分析研究，终于比较完美的实现了恢复，数据恢复95%以上达到了客户的要求。大致过程如下：

1. rman_backup_uncompres.exe d:\backup % d:\backupuncompres
2. 使用odu工具对解压的备份片把数据文件抽取出来
3. 使用odu工具对抽取出来的数据文件进行数据抽取
4. 将odu抽取文件导入新建数据库

4，注意事项
1，生产环境中一定要做数据库备份。
2，备份文件不能存放在数据库所在服务器上。
3，搭建数据库容灾环境，并且做好容灾环境的安全控制。

数据库遭遇.dewar或者.devos结尾的勒索病毒加密的恢复

标签：dmp文件   不能   res   dbf   数据   有一个   后缀名   类型   evo   

原文地址：https://blog.51cto.com/luoping/2493325