Email: service@parnassusdata.com 7 x 24 online support!

    You are here

使用DBRECOVER恢复勒索病毒软件加密损坏数据文件的情况

使用DBRECOVER恢复勒索病毒软件加密损坏数据文件的情况

勒索病毒软件(ransomware malware)会将ORACLE数据文件的部分内容或全部内容加密破坏。由于ORACLE的数据文件大小一般较大,全部加密耗时可能会很久,所以部分勒索病毒软件会选择仅加密ORACLE数据文件头部的连续或随机空间。

对于这种局部的加密破坏,我们可以尝试使用DBRECOVER来恢复其中数据。

由于数据文件头损坏,我们需要通过观察SYSTEM01.DBF的内容来搞清楚,各个数据文件的表空间号(TS#)和相对文件号(RFILE#)等信息。

以下是数据文件清单:

 

 

 

O1_MF_APP01_L782YY4Y_.DBF.eking

O1_MF_APP01_L782ZBM3_.DBF.eking

O1_MF_APP01_L782ZCP1_.DBF.eking

O1_MF_APP02_L782ZO7W_.DBF.eking

O1_MF_APP02_L7830DTG_.DBF.eking

O1_MF_APP02_L7830FJ6_.DBF.eking

O1_MF_DBRECOVE_L6G7B1Q3_.DBF.eking

O1_MF_SYSAUX_L5VP5QJ8_.DBF.eking

O1_MF_SYSTEM_L5VP4N7Y_.DBF.eking

O1_MF_TEMP_L5VPCQGO_.TMP.eking

O1_MF_UNDOTBS1_L5VP66PM_.DBF.eking

O1_MF_USERS_L5VP67TJ_.DBF.eking


以上示例加密后缀为eking

注意其中的TEMP、UNDOTBS1、SYSAUX与我们的恢复作业无关,可以忽略这些文件。

我们首先启动DBRECOVER,使用字典模式DICT-MODE:

 

 

 

按实际情况选择 DB VERSION,对于版本高于12c的实例,例如18c 19c等均选择12。

 

 

仅仅加入SYSTEM01.DBF,并指定其TS#=0 rFILE#=1(注意这是固定的)。

 

以上勾选”SCAN BASE TABLES”选项可以更强有力地应对损坏情况。

之后点击LOAD按钮,DBRECOVER会整体扫描SYSTEM01.DBF并找出其中的数据字典基表数据。

我们打开SYS用户节点,查找TS$和FILE$ 2个基础表:

 

 

 

TS$表存放了表空间信息,TS#列为表空间号,可以得出如下信息:

TS# NAME
0 SYSTEM
1 SYSAUX
2 UNDOTBS1
3 TEMP
4 USERS
5 UNDOTBS2
6 DBRECOVER_TEST
7 APP01
8 APP02

即APP01表空间的TS#=7,而APP02表空间的TS#=8

FILE$表存放了数据文件信息:

 

 

其中我们需要的是TS#和RELFILE#这2列

TS# RELFILE#
0 1
1 3
6 5
4 7
7 2
2 4
7 8
7 9
8 10
8 11
8 12

通过将两张表格的数据映射合并,可以得到:

TS# RELFILE# Tablespace Name
0 1 SYSTEM
1 3 SYSAUX
6 5 DBRECOVER_TEST
4 7 USERS
7 2 APP01
2 4 UNDOTBS1
7 8 APP01
7 9 APP01
8 10 APP02
8 11 APP02
8 12 APP02

删除掉不需要的SYSAUX、UNDOTBS1和已经知道的SYSTEM表空间,则只剩下:

TS# RELFILE# Tablespace Name
6 5 DBRECOVER_TEST
4 7 USERS
7 2 APP01
7 8 APP01
7 9 APP01
8 10 APP02
8 11 APP02
8 12 APP02

对应数据文件名字列表:

O1_MF_APP01_L782YY4Y_.DBF.eking

O1_MF_APP01_L782ZBM3_.DBF.eking

O1_MF_APP01_L782ZCP1_.DBF.eking

O1_MF_APP02_L782ZO7W_.DBF.eking

O1_MF_APP02_L7830DTG_.DBF.eking

O1_MF_APP02_L7830FJ6_.DBF.eking

O1_MF_DBRECOVE_L6G7B1Q3_.DBF.eking

O1_MF_USERS_L5VP67TJ_.DBF.eking


对照上面2个表格,不难发现其中对应关系。对于使用db_create_file_dest OMF文件管理的数据文件,一个表空间下的多个数据文件可按其文件名排序,其顺序与RELFILE#排序一致。对于用户自行管理的文件名(即不使用OMF的情况),一般也会以APP01{XX}(如APP0101、APP0102)之命名方式以便于管理,则也可以获得其对应关系。

以上我们通过猜测获得完整的信息表:

TS# RFILE# Tablespace Name FILE NAME
6 5 DBRECOVER_TEST O1_MF_DBRECOVE_L6G7B1Q3_.DBF.eking
4 7 USERS O1_MF_USERS_L5VP67TJ_.DBF.eking
7 2 APP01 O1_MF_APP01_L782YY4Y_.DBF.eking
7 8 APP01 O1_MF_APP01_L782ZBM3_.DBF.eking
7 9 APP01 O1_MF_APP01_L782ZCP1_.DBF.eking
8 10 APP02 O1_MF_APP02_L782ZO7W_.DBF.eking
8 11 APP02 O1_MF_APP02_L7830DTG_.DBF.eking
8 12 APP02 O1_MF_APP02_L7830FJ6_.DBF.eking

重新打开DBRECOVER,进入字典模式:

 

 

仍需选择数据库版本DB VERSION。

 

 

加入所有必要的数据文件(所有可能存放用户数据的文件文件,UNDOTBS1、TEMP、SYSAUX这些不用加入),注意不要漏掉SYSTEM01.DBF(必须加入)。

按照之前整理的表格,填写此处的TS#和RFILE#信息:

 

若正确填写相关信息,且加密损坏程度不高,则可以直接读取到数据:

 

 

由于加密病毒的特征各异,所以实际操作中可能需要更多问题。欢迎通过邮件与我们交流问题:service@parnassusdata.com