heronpiston@pm.me encrypted recovery

E-mail：chf.dba@gmail.com

Title: heronpiston@pm.me encrypted recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

A friend found us, the oracle dmp file was encrypted and the suffix was:.id[CA4D3CB9-2696].[heronpiston@pm.me].HER

f:\temp>dir *.HER
 驱动器 F 中的卷是 本地硬盘
 卷的序列号是 928E-A028

 f:\temp 的目录

2020-03-18  03:55     1,992,802,578 HX_2020-03-16.DMP.id[CA4D3CB9-2696].[heronpiston@pm.me].HER
2020-03-18  03:55            51,314 hx_2020-03-16.log.id[CA4D3CB9-2696].[heronpiston@pm.me].HER
               2 个文件  1,992,853,892 字节
               0 个目录 376,749,625,344 可用字节

Analysis found that the file header 0.25M data was blanked
20200331202522

In such cases, you can try your better database recovery.
20200331203024

For such encrypted oracle, sql server, mysql and other databases, no need to contact the hacker, we can provide database level recovery support.

Rezcrypt@cock.li Encrypted Database Recovery

E-mail：chf.dba@gmail.com

Title: Rezcrypt@cock.li Encrypted Database Recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

Some friends feedback system is encrypted with similar suffix name.Email=[Rezcrypt@cock.li]ID=[EOPw1aiueARdMy4].KRONOS

f:\temp>dir xifenfei_DB*
 驱动器 F 中的卷是 本地硬盘
 卷的序列号是 928E-A028

 f:\temp 的目录

2020-03-04  10:37     4,312,465,408 xifenfei_DB.ldf.Email=[Rezcrypt@cock.li]ID=[EOPw1aiueARdMy4].KRONOS
2020-03-04  10:41     5,445,189,632 xifenfei_DB.mdf.Email=[Rezcrypt@cock.li]ID=[EOPw1aiueARdMy4].KRONOS
               2 个文件  9,757,655,040 字节
               0 个目录 376,749,887,488 可用字节

Analysis determined that the file is partially encrypted
20200331192405

Through the underlying processing, perfect recovery of the data outside the shielded block is achieved
20200331192636

For such file encryption, in principle, we can achieve better recovery at the database (mainly oracle and sql server) levels.

expdp dmp recovered by encryption damage

E-mail：chf.dba@gmail.com

Title: expdp dmp recovered by encryption damage

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

A friend oracle database dmp backup is encrypted, with the suffix: .DMP.voyager. Through analysis, it is found that the file is encrypted about 2M.
20200320134933

It can be seen here that the dmp file is exported in expdp mode (expdp is essentially stored in xml mode, exp is stored in direct binary mode), and the situation of the recoverable table is analyzed by tools.
Analyze the dmp file with a tool 

CPFL> OPEN F:\BaiduNetdisk\KINGDEE85GH_2020-03-17.DMP.voyager
TABLE_NAME START_POS DATA_BYTE
-------------------------------------------------- --------------- ---------------
KINGDEE85GH.T_WFD_PROCESSDEF 116300288 648396035
KINGDEE85GH.T_DYN_DYNAMICCONFIGURE 864710656 181453794
KINGDEE85GH.T_RPTS_STORAGEFILEDATA 1078767616 21548951
KINGDEE85GH.T_BOT_RULESEGMENT 1100324864 10372516
KINGDEE85GH.T_LOG_APP 1110712320 12603573
KINGDEE85GH.T_PM_PERMITEM 1123336192 7282412
KINGDEE85GH.T_PM_USERORGPERM 1130635264 6692320
KINGDEE85GH.T_DYN_APPSOLUTION 1137336320 801697
KINGDEE85GH.T_PM_MAINMENUITEM 1138155520 3573943
KINGDEE85GH.T_PM_PERMUIGROUP 1141751808 2159245
KINGDEE85GH.T_SYS_ENTITYREF 1143922688 4183869
KINGDEE85GH.T_PM_ROLEPERM 1148116992 2758960
KINGDEE85GH.T_BAS_SYSMENUITEM 1150885888 3304627
KINGDEE85GH.T_JP_PAGE 1154211840 3019174
…………
KINGDEE85GH.T_XT_CHECKTIME 1212776448 41
KINGDEE85GH.T_XT_SYNCHTIME 1212784640 41
SYSTEM.SYS_EXPORT_SCHEMA_02 1212792832 215423380
-------------------------------------------------- --------------- ---------------
Scanned Find 895 segments.

Through this, you can basically determine that more than 100 M data have been lost, and other data can theoretically be recovered.
Create a user 

SQL> create user KINGDEE85GHidentified by oracle;

User created.

SQL> grant dba to KINGDEE85GH;

Grant succeeded.

unexpdp data (automatic table creation and import data) 

CPFL> unexpdp table KINGDEE85GH.T_WFD_PROCESSDEF

unexpdp table: KINGDEE85GH.T_WFD_PROCESSDEF storage (START_POSITION:116300288 DATA_BYTE:748396035)
824 rows unexpdp

View recovery results
20200320142445
20200320142034

If you have oracle expdp dmp is encrypted or damaged and cannot be imported into the database normally, you can contact us to restore it:chf.dba@gmail.com
If your oracle dmp is exported in exp mode, you can also contact us to process it, see:
exp dmp file corruption recovery
oracle dmp is encrypted and restored

Oracle 19c failure recovery

E-mail：chf.dba@gmail.com

Title: Oracle 19c failure recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

Some customers found us. Their oracle 19c database started abnormally due to abnormal power failure. After a series of recovery, the problem could not be solved, and we asked for support. Through our Oracle Database Recovery Check Script , get The current database information is as follows:
The database version is 19C and the 19.5.0.0.191015 (30125133) patch is installed
20200310220453
20200310220748

Database using pdb
20200310220610

After the database is successfully started, it will crash in a while

2020-03-10T01:44:41.018032+08:00
Pluggable database RACBAK opened read write
2020-03-10T01:44:41.018996+08:00
Pluggable database RAC opened read write
2020-03-10T01:44:51.244050+08:00
Completed: ALTER PLUGGABLE DATABASE ALL OPEN
Starting background process CJQ0
Completed: ALTER DATABASE OPEN
2020-03-10T01:44:51.317085+08:00
CJQ0 started with pid=224, OS id=32581 
2020-03-10T01:44:56.067043+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_j001_32588.trc  (incident=1095281) (PDBNAME=RAC):
ORA-00600: internal error code, arguments: [4193], [27733], [27754], [], [], [], [], [], [], [], [], []
RAC(4):Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1095281/XFF_j001_32588_i1095281.trc
RAC(4):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2020-03-10T01:44:56.073112+08:00
RAC(4):*****************************************************************
RAC(4):An internal routine has requested a dump of selected redo.
RAC(4):This usually happens following a specific internal error, when
RAC(4):analysis of the redo logs will help Oracle Support with the
RAC(4):diagnosis.
RAC(4):It is recommended that you retain all the redo logs generated (by
RAC(4):all the instances) during the past 12 hours, in case additional
RAC(4):redo dumps are required to help with the diagnosis.
RAC(4):*****************************************************************
2020-03-10T01:44:56.079228+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_j002_32590.trc  (incident=1095289) (PDBNAME=RAC):
ORA-00600: internal error code, arguments: [4193], [2633], [2638], [], [], [], [], [], [], [], [], []
RAC(4):Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1095289/XFF_j002_32590_i1095289.trc
RAC(4):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2020-03-10T01:44:56.085068+08:00
RAC(4):*****************************************************************
RAC(4):An internal routine has requested a dump of selected redo.
RAC(4):This usually happens following a specific internal error, when
RAC(4):analysis of the redo logs will help Oracle Support with the
RAC(4):diagnosis.
RAC(4):It is recommended that you retain all the redo logs generated (by
RAC(4):all the instances) during the past 12 hours, in case additional
RAC(4):redo dumps are required to help with the diagnosis.
RAC(4):*****************************************************************
2020-03-10T01:44:56.115765+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_j004_32594.trc  (incident=1095305) (PDBNAME=RAC):
ORA-00600: internal error code, arguments: [4193], [63532], [63537], [], [], [], [], [], [], [], [], []
RAC(4):Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1095305/XFF_j004_32594_i1095305.trc
RAC(4):Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2020-03-10T01:46:48.202213+08:00
RAC(4):Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
RAC(4):  Mem# 0: /opt/oracle/oradata/XFF/redo02.log
RAC(4):Block recovery completed at rba 0.0.0, scn 0x0000000d3675e48e
RAC(4):DDE: Problem Key 'ORA 600 [4193]' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
2020-03-10T01:46:48.384040+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_clmn_31741.trc:
ORA-00600: internal error code, arguments: [4193], [27733], [27754], [], [], [], [], [], [], [], [], []
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_clmn_31741.trc  (incident=1093505) (PDBNAME=CDB$ROOT):
ORA-501 [] [] [] [] [] [] [] [] [] [] [] []
Incident details in: /opt/oracle/diag/rdbms/XFF/XFF/incident/incdir_1093505/XFF_clmn_31741_i1093505.trc
2020-03-10T01:46:49.264624+08:00
USER (ospid: 31741): terminating the instance due to ORA error 501
2020-03-10T01:46:49.280664+08:00
System state dump requested by (instance=1, osid=31741 (CLMN)), summary=[abnormal instance termination].
System State dumped to trace file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_diag_31759.trc
2020-03-10T01:46:53.156926+08:00
ORA-00501: CLMN process terminated with error
2020-03-10T01:46:53.157103+08:00
Errors in file /opt/oracle/diag/rdbms/XFF/XFF/trace/XFF_diag_31759.trc:
ORA-00501: CLMN process terminated with error
2020-03-10T01:46:53.157211+08:00
Dumping diagnostic data in directory=[cdmp_20200310014649], requested by (instance=1, osid=31741 (CLMN)), 
summary=[abnormal instance termination].

Judging by the error information, after the database is opened (especially after pdb 4 is opened), an ORA-600 4193 error is reported. Then the CLMN process is abnormal and the database crashes. For this type of failure, because of the pdb used, and because of the pdb The undo exception causes the database to crash after startup.You can perform special processing on pdb to prevent the database from crashing after startup.

Oracle dmp Encryption Recovery

E-mail：chf.dba@gmail.com

Title: Oracle dmp Encryption Recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

An oracle dmp file is encrypted and damaged.The encryption prompt is as follows
20200306192501

20200306191213

Analysis of the tool found that the first 1M of the file was damaged
20200306191553

Special processing of 1M data with head damage through our tool, data is imported directly using imp command
20200306191709
If you have various databases (oracle, sql server, mysql) encrypted by similar viruses, we can provide professional recovery support to achieve almost perfect recovery of data without paying hackers
E-Mail:chf.dba@gmail.comProvide professional recovery services.

Oracle datafile size is 0kb or file loss recovery

E-mail：chf.dba@gmail.com

Title: Oracle datafile size is 0kb or file loss recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

After receiving a friend’s recovery request, some data files in the file system changed to 0kb and the file was lost due to frequent switching of rose.
Failure phenomenon
Some data files changed to 0kb and files were lost.
file_lost
file_size_0

It is obvious here that users03 of the database has become 0kb and users04 are lost. The error message of the database alert log is as follows:

Completed: alter database mount exclusive
alter database open
Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc:
ORA-01157: ????/?????? 7 - ??? DBWR ????
ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF'
ORA-27047: ??????????
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 38) 已到文件结尾。
Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc:
ORA-01157: ????/?????? 8 - ??? DBWR ????
ORA-01110: ???? 8: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS04.DBF'
ORA-27041: ??????
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_12040.trc:
ORA-01157: ????/?????? 7 - ??? DBWR ????
ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF'
ORA-1157 signalled during: alter database open...
Fri May 04 09:35:10 2018
Checker run found 2 new persistent data failures

The error of the alert log is also obvious. Users03 is the file exceeds the size (the size is 0kb, it must exceed the size after reading), users04 indicates that the file cannot be opened (the file has been lost at the file system level). Now the problem is more obvious due to file system failure Causes file size to be 0 and missing

Fragment Scan Recovery
The conventional method is definitely unable to recover. The better method can only be the scanning and reorganization of the underlying fragment. Combined with a variety of scanning tools, I finally found that a friend who does the underlying recovery works well. The scan results are as follows
file_scan

Analysis of bad blocks by tools

C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.7_10.ora

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.7_10.ora

………………

页 382565 标记为损坏
Corrupt block relative dba: 0x01c5d665 (file 7, block 382565)
Completely zero block found during dbv:

页 382566 标记为损坏
Corrupt block relative dba: 0x01c5d666 (file 7, block 382566)
Completely zero block found during dbv:

页 382567 标记为损坏
Corrupt block relative dba: 0x01c5d667 (file 7, block 382567)
Completely zero block found during dbv:



DBVERIFY - 验证完成

检查的页总数: 1374720
处理的页总数 (数据): 27582
失败的页总数 (数据): 0
处理的页总数 (索引): 20114
失败的页总数 (索引): 0
处理的页总数 (其他): 1319752
处理的总页数 (段)  : 0
失败的总页数 (段)  : 0
空的页总数: 1
标记为损坏的总页数: 7271
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 228271996 (0.228271996)


C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.8_8.ora

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.8_8.ora


DBVERIFY - 验证完成

检查的页总数: 1136896
处理的页总数 (数据): 36639
失败的页总数 (数据): 0
处理的页总数 (索引): 57038
失败的页总数 (索引): 0
处理的页总数 (其他): 1043218
处理的总页数 (段)  : 0
失败的总页数 (段)  : 0
空的页总数: 1
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 228271997 (0.228271997)

C:\Users\Administrator>

scan_resulte

Here, the total number of blocks of the two files recovered by analysis is 2511618, of which 7271 blocks are continuously damaged. After the problem occurs, the database is offline and these two files continue to run for several hours, causing a small number of blocks to be overwritten. Leave it blank. The subsequent recovery is relatively smooth, and the database is normally opened, and then the bad block object is processed (it is not the lob field of the business core table, and the loss of all parts is not very significant).

Reminder:
1. Data files and backups should not be placed on the same array, let alone on the same partition (volume)
2. After such a problem occurs, you should understand that any write operation to the partition is stopped, the method is lost, or the 0KB file is overwritten.
If you need professional ORACLE database recovery technical support, please contact usE-Mail:chf.dba@gmail.com

.horseleader encrypted database recovery

E-mail：chf.dba@gmail.com

Title: .horseleader encrypted database recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

Virus-encrypted .horseleader extension file
20200304182923

Through analysis, we only destroyed part of the data, and we can recover most of them
20200304182504
20200304182522

Process through the bottom layer, skip the damaged part and recover the non-corrupted data
20200304182551

For this type of encryption, we can recover the vast majority of data for SQL Server, MySQL, oracle, and realize the recovery of most business data by not paying a ransom to hackers.

SQL Server MDF file size 0kb Recovery

E-mail：chf.dba@gmail.com

Title: SQL Server MDF file size 0kb Recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

Previously restored the Oracle database dbf file size became 0kb case ( Oracle data file size is 0kb or file loss recovery ), this time I encountered a customer that the mdf file size of the sql server database became 0kb due to the host restart, and the customer himself deleted it The software cannot be recovered normally, we process it through the underlying block of the disk to achieve most of the data recovery (partial data coverage due to some operations of the customer)
This disk partition has multiple mdf files (multiple sql server libraries)
20200303190055
Discover a large number of blocks of the file that are not covered by the underlying block technology
20200303190141
20200303190332
After the mdf file is restored through the block technology, then the table data is restored.
20200303190617

If you encounter a sql server database that causes the mdf file size to become 0kb for some reason, please protect the site as soon as possible and do not perform any write operations. We can recover it to the maximum extent and minimize your loss
If you need to recover, contact us(E-Mail:chf.dba@gmail.com) to provide professional database recovery services

MySQL Ransomware Recovery

E-mail：chf.dba@gmail.com

Title: MySQL Ransomware Recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

Recently encountered several mysql databases that were deleted by hackers and left Bitcoin ransomware in the WARNING table of each library

mysql> desc WARNING
    -> ;
+-----------------+----------+------+-----+---------+-------+
| Field           | Type     | Null | Key | Default | Extra |
+-----------------+----------+------+-----+---------+-------+
| id              | int(11)  | YES  |     | NULL    |       |
| warning         | longtext | YES  |     | NULL    |       |
| Bitcoin_Address | longtext | YES  |     | NULL    |       |
| Email           | longtext | YES  |     | NULL    |       |
+-----------------+----------+------+-----+---------+-------+
4 rows in set (0.00 sec)

mysql> select * from WARNING;
+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+------------------+
| id   | warning                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | Bitcoin_Address                    | Email            |
+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+------------------+
|    1 | To recover your lost Database and avoid leaking it: Send us 0.06 Bitcoin (BTC) to our Bitcoin address 1BLYhUDmnmVPVjcTWgc6gFT6DCYwbVieUD and contact us by Email with your Server IP or Domain name and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your Database is downloaded and backed up on our servers. Backups that we have right now: xxxx,xxxxxx,xxxxxxxx,xxxxxxx . If we dont receive your payment in the next 10 Days, we will make your database public or use them otherwise. | 1BLYhUDmnmVPVjcTWgc6gFT6DCYwbVieUD | contact@sqldb.to |
+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------+------------------+
1 row in set (0.00 sec)

The general meaning is: We have backed up your database, and you gave us 0.06 bitcoins, and we give you the data. If we do not receive the payment within 10 days, the database will be made public or used for other purposes. The experience of friends we have contacted in the past, the database will not be given to you after payment (most likely the hacker did not back up the database at all, just deleted the database and then extorted Bitcoin.

For such cases, through analysis, it is confirmed that the hacker has deleted the database.In the case of no coverage, we can recover its data.MySQL drop database recovery (the recovery method is also applicable to MySQL drop table, delete, truncate table)Minimize the loss caused by database corruption.
20200303125417
If you also encounter this problem, please protect the site, do not import the backup database, do not write to the partition where the data is located (the better the site protection, the better the data recovery effect), mirror the relevant disk to prevent secondary damage. We can provide professional mysql recovery services to reduce your losses.

.[geerban@email.tg].Devos Encrypted database recovery

E-mail：chf.dba@gmail.com

Title: .[geerban@email.tg].Devos Encrypted database recovery

Author: DATABASE SOS©All rights reserved [without my consent, it may not be reproduced in any form, otherwise there is the right to further legal responsibility.]

A new virus was found to encrypt the Oracle database, with a suffix named:.id[06495F21-2700].[geerban@email.tg].Devos
20200302121209

Through analysis, it was found that the data in the front part of the file was directly blanked.
20200302122026

File intermediate data still exists
20200302122204

Through the underlying analysis for such failures, we can recover the vast majority of data and achieve the vast majority of business data recovery without paying a ransom to hackers.