Ransomware malware encrypts part or all of the content of Oracle datafiles. As Oracle datafiles are generally large, encrypting the entire file may take a long time, so some ransomware malware may choose to encrypt only continuous or random space in the header of the Oracle datafile.
For this kind of local encryption damage, we can try to use DBRECOVER to recover the data in it.
Since the datafile header is damaged, we need to figure out the tablespace number (TS#) and relative file number (RFILE#) of each datafile by observing the contents of SYSTEM01.DBF.
Below is a list of datafiles
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.ekingThe example above has the encrypted suffix eking.
Note that TEMP, UNDOTBS1, and SYSAUX are irrelevant to our recovery job, so you can ignore these files.
We first launch DBRECOVER, using dictionary mode DICT-MODE.
Choose the DB VERSION according to the actual situation. For instances higher than version 12c, such as 18c, 19c, etc., choose 12.
Only add SYSTEM01.DBF and specify its TS# = 0 rFILE# = 1 (note this is fixed).
Checking the "SCAN BASE TABLES" option above can more powerfully deal with damage situations.
After clicking the LOAD button, DBRECOVER will scan SYSTEM01.DBF as a whole and find the data dictionary base table data in it.
We open the SYS user node and look for the TS$ and FILE$ two basic tables
The TS$ table stores tablespace information, the TS# column is the tablespace number, and we can get the following information:
| TS# | NAME |
|---|---|
| 0 | SYSTEM |
| 1 | SYSAUX |
| 2 | UNDOTBS1 |
| 3 | TEMP |
| 4 | USERS |
| 5 | UNDOTBS2 |
| 6 | DBRECOVER_TEST |
| 7 | APP01 |
| 8 | APP02 |
That is, the TS# of the APP01 tablespace is 7, and the TS# of the APP02 tablespace is 8.
The FILE$ table stores datafile information
What we need are the TS# and RELFILE# columns.
| TS# | RELFILE# |
|---|---|
| 0 | 1 |
| 1 | 3 |
| 6 | 5 |
| 4 | 7 |
| 7 | 2 |
| 2 | 4 |
| 7 | 8 |
| 7 | 9 |
| 8 | 10 |
| 8 | 11 |
| 8 | 12 |
By mapping and merging the data of the two tables, we can get
| 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 |
After deleting the unnecessary SYSAUX, UNDOTBS1, and the known SYSTEM tablespace, only the following are left:
| 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 |
Corresponding datafile name list
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.ekingBy comparing the above two tables, it is not difficult to find the corresponding relationship. For datafiles managed by db_create_file_dest OMF file, multiple datafiles under a tablespace can be sorted by their file names, and the order is consistent with RELFILE#. For file names managed by users themselves (that is, without using OMF), they generally use the naming method of APP01{XX} (such as APP0101, APP0102) for easier management, and their corresponding relationship can also be obtained.
Above, we obtained a complete information table through guessing
| 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 |
Reopen DBRECOVER and switch to dictionary mode
You still need to select the database version (DB VERSION).
Add all necessary datafiles (all files that might store user data, UNDOTBS1, TEMP, SYSAUX don't need to be added), and make sure not to omit SYSTEM01.DBF (it must be added).
Fill in the TS# and RFILE# information according to the table you compiled earlier
If the relevant information is correctly filled in and the degree of encryption damage isn't high, you can directly read the data:
Because the characteristics of encryption viruses vary, there may be more problems that need to be addressed in actual operation. Please feel free to communicate with us via email:[email protected].
DBRECOVER Recovery Options
For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.
When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.