SQL Server Database Bitcoin Encryption Ransomware Recovery

E-mail:chf.dba@gmail.com

Title: SQL Server Database Bitcoin Encryption 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.]

For the Oracle database encrypted by GANDCRAB virus, we can provide a more perfect recovery. “GANDCRAB V5.0.4 Bitcoin encryption oracle database recovery”> GANDCRAB V5.0.4 Bitcoin encryption oracle database recovery and GANDCRAB Upgraded Oracle Recovery , we have done some research on the SQL Server database encrypted by GANDCRAB recently, and now it can be better recovered.
gandcrab5.2-sql-server


 1


And if the cost of finding a hacker to decrypt is $ 10w, the customer cannot accept the cost.The main thing in the system is that the sql server database is encrypted. The customer has a backup of several months ago, but the data is severely lost and cannot bear the relevant losses. Recovery support. After a series of recovery, we can achieve a more perfect recovery of the database
gandcrab5.2-sql-server1


gandcrab5.2-sql-server2


If your sql server database is unfortunately encrypted by Bitcoin, you can contact us at any time to provide database level recovery support
E-Mail:chf.dba@gmail.com

.ALCO Bitcoin Crypto Ransom Recovery

E-mail:chf.dba@gmail.com

Title: .ALCO Bitcoin Crypto Ransom 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 recently consulted another win platform which was encrypted by bitcoin ransomware with the suffix name: .ALCO + oracle database recovery request.
. ALCO +


The analysis revealed that the virus is more disgusting than ever, and the head and tail of the file are encrypted in a spaced manner
 oracle-1-alco +
 oracle-3-alco +
 oracle-2-alco +


The analysis results prove that ALCO + separately encrypts the 318 blocks at the beginning and end of the Oracle file.
Through our analysis, for this type of failure, we can also have better recovery results.
 oracle-4-alco +


.CHAK1 Bitcoin Crypto Ransomware Recovery

E-mail:chf.dba@gmail.com

Title: .CHAK1 Bitcoin Crypto 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, a friend encountered an oracle database whose bitcoin suffix is ​​.CHAK1.
 oracle-chak1


We have confirmed that this destruction and the last ( Bitcoin encryption ransom interval encryption ) is similar
 oracle-chak1
 oracle-chak2
< hr>
Through analysis, such damage results are:
1) 1280 block interval encryption,
2) The first 10M data of each encrypted file may be lost
For this customer, through analysis, business data can be recovered perfectly.
 data


If your database is ransomized by Bitcoin crypto and needs recovery support please contact us
E-Mail:chf.dba@gmail.com

.wncry Bitcoin Ransomware Recovery

E-mail:chf.dba@gmail.com

Title: .wncry Bitcoin 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.]

I have also paid attention to various bitcoin ransomware before. For the oracle database, I mainly focus on pl/sql dev and File Encryption Ransomware, no matter which kind of extortion has not happened The scope of the impact is only wide and has a great impact. Even the public security network of the dynasty was severely infected, and many departments were unable to operate normally.
After infection
 btb
 wncry


Here you can find that the Bitcoin encryption this time is selective encryption, not all files are encrypted, but judged based on the file suffix name, and then encrypted for blackmail.
View encrypted files
 1
 2


This failure is different from the previous encrypted ransomware.This time, the entire file is completely encrypted, which is quite different from the previous encryption, because the full-text encryption also brings great difficulty to the recovery.

Receive Bitcoin
https://btc.com/12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
You can find this linked list. Lisso people receive a lot of bitcoin, and it is generally not recommended to pay bitcoin: 1) it fuels this arrogance, and 2) the payment may not be decrypted (there are examples of failure around)
 3


Fortunately, although we cannot decrypt the encrypted file, according to the encryption principle, we have run oracle (stored the oracle data file) on the hard disk, then there are traces on the hard disk. As long as this trace is not covered, we can pass the underlying Scan the block to recover the data (similar to: asm disk header completely damaged recovery ). Through this principle, we successfully restored a customer’s database today. If this aspect cannot be recovered by itself, you can contact us for technical support
E-Mail:chf.dba@gmail.com
Due to limited technical skills, at present we can only recover the encrypted database for extorting Bitcoin, other files cannot be recovered. For the database, we also need to evaluate the site to determine whether it can be recovered.

ORA-00702: bootstrap version ” does not match version ‘8.0.0.0.0’

E-mail:chf.dba@gmail.com

Title: ORA-00702: bootstrap version ” does not match version ‘8.0.0.0.0’

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.]

ORA-00704 and ORA-00702 errors were reported when the customer feedback database could not be started properly just after New Year’s Day in 19
 ora-00702


Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_3756.trc:
ORA-00704: bootstrap process failed
ORA-00702: bootstrap version '' does not match version '8.0.0.0.0'
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_3756.trc:
ORA-00704: bootstrap process failed
ORA-00702: bootstrap version '' does not match version '8.0.0.0.0'
Error 704 happened during db open, shutting down database
USER (ospid: 3756): terminating the instance due to error 704
Instance terminated by USER, pid = 3756

Through analysis and confirmation, it was confirmed that the script was injected due to the database suffered, and the database base table data was destroyed. As a result, the database could not be started normally after restarting.
 1


This kind of failure can be restored by the oracle base table to achieve the perfect open database, data 0 is lost. If you cannot resolve it yourself, please contact us for recovery support
E-Mail:chf.dba@gmail.com
Remind again in 2019: 1) database backup and disaster recovery, 2) please use the official channel to download database media and database access tools, 3) regularly check whether the database is injected with malicious scripts

GANDCRAB V5.0.4 Bitcoin encryption oracle database recovery

E-mail:chf.dba@gmail.com

Title: GANDCRAB V5.0.4 Bitcoin encryption oracle 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.]

After receiving a friend’s recovery request, the win server file was encrypted by the bitcoin ransomware oracle database of GANDCRAB V5.0.4 (Zhonglian his [large Chinese table name / xml type]), let us analyze it and determine whether it can be restored
 3
 4


Through the analysis of the tool, it is found that the file header and data file space need to be reconstructed using bitmap-related blocks. The main business data should theoretically be good. By analyzing the basic database information such as database tablespaces and data files, Manually rebuild, rebuild the control file, and after a series of recovery, the database forced to open successfully

SQL> select open_mode from v $ database;

OPEN_MODE
--------------------
READ WRITE

SQL> select name from v $ datafile;

NAME
-------------------------------------------------- ------------------------------
E:\ORCLNEW1\SYSTEM01.DBF.HKNWFZ
E:\ORCLNEW1\SYSAUX01.DBF.HKNWFZ
E:\ORCLNEW1\UNDOTBS01.DBF.HKNWFZ
E:\ORCLNEW1\USERS01.DBF.HKNWFZ
E:\ORCLNEW1\BHDATA.DBF.HKNWFZ
E:\ORCLNEW1\BHMAIL.DBF.HKNWFZ
E:\ORCLNEW1\BHINDEX.DBF.HKNWFZ
E:\ORCLNEW1\ZHBASIS.DBF.HKNWFZ
E:\ORCLNEW1\ZHARCHIVES.DBF.HKNWFZ
E:\ORCLNEW1\ZHSERVICES.DBF.HKNWFZ
E:\ORCLNEW1\ZHADVICES.DBF.HKNWFZ
E:\ORCLNEW1\ZHEXPENSES.DBF.HKNWFZ
E:\ORCLNEW1\ZHMEDICINE.DBF.HKNWFZ
E:\ORCLNEW1\ZHLAB.DBF.HKNWFZ
E:\ORCLNEW1\ZHCHECK.DBF.HKNWFZ
E:\ORCLNEW1\ZHLOB.DBF.HKNWFZ
E:\ORCLNEW1\ZHINDEX.DBF.HKNWFZ
E:\ORCLNEW1\SLREPORT.DBF.HKNWFZ
E:\ORCLNEW1\ZHMATERIAL.DBF.HKNWFZ
E:\ORCLNEW1\ZHMEDREC.DBF.HKNWFZ
E:\ORCLNEW1\ZHINSURE.DBF.HKNWFZ

Because the customer’s database has a large number of xml column types, exp cannot be exported, and only expdp can be used for export. Because expdp creates intermediate tables during the export process, some repairs are made to the database to ensure that the database can write normally. Object and database export succeeded
 2


.WECANHELP encrypted database recovery

E-mail:chf.dba@gmail.com

Title: .WECANHELP 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.]

After receiving the network recovery request, the oracle dmp file is encrypted and the file name is: 2020_01_10_16_00_00.DMP.id_2251820718_.WECANHELP, _RESTORE FILES_.txt file content is:

*** ALL YOUR WORK AND PERSONAL FILES HAVE BEEN ENCRYPTED ***
To decrypt your files you need to buy the special software? "Nemesis decryptor"
You can find out the details / buy decryptor + key / ask questions by email:
        wecanhelpyou@elude.in, w3canh3lpy0u@cock.li OR wecanh3lpyou2@cock.li
IMPORTANT!
DON'T TRY TO RESTORE YOU FILES BY YOUR SELF, YOU CAN DAMAGE FILES!
If within 24 hours you did not receive an answer by email,
   be sure to write to Jabber: icanhelp@xmpp.jp
Your personal ID: 2251820718

By analyzing the encrypted dmp
 20200117180530
We determined that it can be restored through the technical level of the database to achieve maximum rescue of customer data
 20200117181832


If your database (oracle, mysql sql server) is unfortunately encrypted by Bitcoin, you can contact us
E-Mail:chf.dba@gmail.com

Globeimposter * 865qqz ransomware recovery

E-mail:chf.dba@gmail.com

Title: Globeimposter * 865qqz 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, the client server file was encrypted with the suffix: .Globeimposter-Beta865qqz. After analyzing it, the related suffixes are similar:
.Globeimposter-Alpha865qqz
.Globeimposter-Beta865qqz
.Globeimposter-Delta865qqz
.Globeimposter-Epsilon865qqz
.Globeimposter-Gamma865qqz
.Globeimposter-Zeta865qqz, similar screenshots are as follows:
 20200207191431


Analysis revealed that data was encrypted and corrupted
 20200207192144


After the underlying processing of its files, most of the data recovery is achieved
 20200207192721


After analysis, we can recover some databases of such viruses (oracle dmp, sql bak, etc.), if there are such problems, you can contact us for recovery support
E-Mail:chf.dba@gmail.com

mysql database is encrypted recovery

E-mail:chf.dba@gmail.com

Title: mysql database is 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.]

Some customers mysql database is encrypted, the encrypted information is as follows
20200129162256


Since it is the version of mysql 5.6, the default is the innodb engine, and the Innodb_file_per_table parameter is true by default, so the data exists for each table in a separate ibd file, allowing customers to provide the ibd encrypted file of the table that needs to be recovered
20200129162048


Achieve perfect data recovery through a series of low-level operations
1
2


If the Innodb_file_per_table parameter is false (defaults to false before 5.6), you need to restore through the ibdata file
If your database (oracle, mysql sql server) is unfortunately encrypted by Bitcoin, you can contact us
E-Mail:chf.dba@gmail.comProvide professional decryption recovery services.

MySQL ibd Recovery

E-mail:chf.dba@gmail.com

Title: MySQL ibd 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.]

The ibd file is saved in mysql for some reason, but the table has been deleted or the frm file is damaged or the ibdata file is damaged / lost. This article simulates that in this case, ibd file recovery can be completed through mysql’s own technology.
Test environment mysql version

mysql> select version ();
+ ----------- +
| version () |
+ ----------- +
| 5.6.25 |
+ ----------- +
1 row in set (0.00 sec)

mysql main parameters

mysql> show variables like 'innodb_file_per_table';
+ ----------------------- + ------- +
| Variable_name | Value |
+ ----------------------- + ------- +
| innodb_file_per_table | ON |
+ ----------------------- + ------- +
1 row in set (0.00 sec)
mysql> show variables like 'innodb_force_recovery';
+ ----------------------- + ------- +
| Variable_name | Value |
+ ----------------------- + ------- +
| innodb_force_recovery | 0 |
+ ----------------------- + ------- +
1 row in set (0.00 sec)

The innodb_file_per_table parameter is on to enable each table to store a separate ibd file.The default range of the innodb_force_recovery parameter is 0

Test table situation

mysql> use xifenfei;
Database changed
mysql> show tables;
+ ----------------------------- +
| Tables_in_xifenfei |
+ ----------------------------- +
| user_login |
+ ----------------------------- +
1 rows in set (0.00 sec)

mysql> select count (*) from user_login;
+ ---------- +
| count (*) |
+ ---------- +
| 48 |
+ ---------- +
1 row in set (0.02 sec)

mysql> desc user_login;
+ ------------ + -------------- + ------ + ----- + -------- -+ ------- +
Field | Type | Null | Key | Default | Extra |
+ ------------ + -------------- + ------ + ----- + -------- -+ ------- +
| ID | varchar (255) | NO | PRI | NULL | |
| ACCOUNT | varchar (255) | YES | | NULL | |
| LifeCycle | int (11) | YES | | NULL | |
| Name | varchar (255) | YES | | NULL | |
| Password | varchar (255) | YES | | NULL | |
| Role | varchar (255) | YES | | NULL | |
| UTime | varchar (255) | YES | | NULL | |
UserID | varchar (255) | YES | | NULL | |
| UserName | varchar (255) | YES | | NULL | |
UserStatus | int (11) | YES | | NULL | |
+ ------------ + -------------- + ------ + ----- + -------- -+ ------- +
10 rows in set (0.05 sec)

mysql> select * from user_login limit 1;
+ ---------------------------------- + --------- + ---- ------- + ----------- + ----------
------------------------ + ------ + ------------------ --- + --------------------------
-------- + ---------- + ------------ +
| ID | ACCOUNT | LifeCycle | Name | Password
                        | Role | UTime | UserID
        | UserName | UserStatus |
+ ---------------------------------- + --------- + ---- ------- + ----------- + ----------
------------------------ + ------ + ------------------ --- + --------------------------
-------- + ---------- + ------------ +
| 010d6c85a76c44cba80d07cbd8590bb2 | hyh | 0 | Hu Yuanhui | 698d51a19
d8a121ce581499d7b701668 | | 6 | | 2016-08-30 06:04:32 | 0fe3bc4dd9654687a4b85065e
d5cfee8 | NULL | 1 |
+ ---------------------------------- + --------- + ---- ------- + ----------- + ----------
------------------------ + ------ + ------------------ --- + --------------------------
-------- + ---------- + ------------ +
1 row in set (0.00 sec)

mysql> show create table user_login \ G;
*************************** 1. row *************
       Table: user_login
Create Table: CREATE TABLE `user_login` (
  `ID` varchar (255) NOT NULL,
  `ACCOUNT` varchar (255) DEFAULT NULL,
  `LifeCycle` int (11) DEFAULT NULL,
  `Name` varchar (255) DEFAULT NULL,
  `Password` varchar (255) DEFAULT NULL,
  `Role` varchar (255) DEFAULT NULL,
  `UTime` varchar (255) DEFAULT NULL,
  `UserID` varchar (255) DEFAULT NULL,
  `UserName` varchar (255) DEFAULT NULL,
  `UserStatus` int (11) DEFAULT NULL,
  PRIMARY KEY (`ID`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8
1 row in set (0.00 sec)


mysql> show variables like 'datadir';
+ --------------- + --------------------------------- -------------- +
| Variable_name | Value |
+ --------------- + --------------------------------- -------------- +
datadir | D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ |
+ --------------- + --------------------------------- -------------- +
1 row in set (0.00 sec)

Back up ibd files

C: \ Users \ XIFENFEI> dir D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd
 The volume in drive D has no labels.
 The serial number of the volume is 4215-1F18

 D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei

2016-12-02 20:07 98,304 user_login.ibd
               1 file 98,304 bytes
               0 directories 78,789,591,040 available bytes
C: \ Users \ XIFENFEI> cp D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd d: /
C: \ Users \ XIFENFEI> dir d: \ user_login.ibd
 The volume in drive D has no labels.
 The serial number of the volume is 4215-1F18

 d: \ directory

2016-12-25 23:15 98,304 user_login.ibd
               1 file 98,304 bytes
               0 directories 78,789,591,040 available bytes

Simulated delete table (ibd file is also deleted)

mysql> drop table xifenfei.user_login;
Query OK, 0 rows affected (0.03 sec)


C: \ Users \ XIFENFEI> dir D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd
 The volume in drive D has no labels.
 The serial number of the volume is 4215-1F18

 D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei

File not found

Create a new table

mysql> CREATE TABLE `user_login` (
    -> `ID` varchar (255) NOT NULL,
    -> `ACCOUNT` varchar (255) DEFAULT NULL,
    -> `LifeCycle` int (11) DEFAULT NULL,
    -> `Name` varchar (255) DEFAULT NULL,
    -> `Password` varchar (255) DEFAULT NULL,
    -> `Role` varchar (255) DEFAULT NULL,
    -> `UTime` varchar (255) DEFAULT NULL,
    -> `UserID` varchar (255) DEFAULT NULL,
    -> `UserName` varchar (255) DEFAULT NULL,
    -> `UserStatus` int (11) DEFAULT NULL,
    -> PRIMARY KEY (`ID`)
    ->) ENGINE = InnoDB DEFAULT CHARSET = utf8;
Query OK, 0 rows affected (0.03 sec)

C: \ Users \ XIFENFEI> dir D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd
 The volume in drive D has no labels.
 The serial number of the volume is 4215-1F18

 D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei

2016-12-25 23:19 98,304 user_login.ibd
               1 file 98,304 bytes
               0 directories 78,789,591,040 available bytes

mysql> select count (*) from xifenfei.user_login;
+ ---------- +
| count (*) |
+ ---------- +
| 0 |
+ ---------- +
1 row in set (0.00 sec)

Stop mysql and replace user_login.ibd

C: \ Users \ XIFENFEI> dir D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd
 The volume in drive D has no labels.
 The serial number of the volume is 4215-1F18

 D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei

2016-12-25 23:22 98,304 user_login.ibd
               1 file 98,304 bytes
               0 directories 78,787,141,632 bytes available

C: \ Users \ XIFENFEI> cp d: \ user_login.ibd D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd
C: \ Users \ XIFENFEI> dir D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei \ user_login.ibd
 The volume in drive D has no labels.
 The serial number of the volume is 4215-1F18

 D: \ xifenfei \ mysql-5.6.25-winx64 \ data \ xifenfei

2016-12-02 20:07 98,304 user_login.ibd
               1 file 98,304 bytes
               0 directories 78,787,141,632 bytes available

Start the mysql service and query the database

mysql> select count (*) from xifenfei.user_login;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> exit
Bye

C: \ Users \ XIFENFEI> mysql -uroot
ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (10061)

mysql log error

2016-12-25 23:31:07 11632 [Note] MySQL: ready for connections.
Version: '5.6.25' socket: '' port: 3306 MySQL Community Server (GPL)
InnoDB: Error: tablespace id is 56 in the data dictionary
InnoDB: but in file. \ Xifenfei \ user_login.ibd it is 47!
2016-12-25 23:31:31 2eb8 InnoDB: Assertion failure in thread 11960 in file fil0fil.cc line 796
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be

Obviously, because the replaced ibd file and the dictionary information of the page of the ibd file recorded in the database do not match, because the database cannot query the data normally, and mysql directly crashed the instance for security.

Resume operation

mysql> show variables like 'innodb_force_recovery';
+ ----------------------- + ------- +
| Variable_name | Value |
+ ----------------------- + ------- +
| innodb_force_recovery | 1 |
+ ----------------------- + ------- +
1 row in set (0.00 sec)
mysql> alter table xifenfei.user_login discard tablespace;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> alter table xifenfei.user_login import tablespace;
Query OK, 0 rows affected, 1 warning (0.06 sec)

mysql> select count (*) from xifenfei.user_login;
+ ---------- +
| count (*) |
+ ---------- +
| 48 |
+ ---------- +
1 row in set (0.00 sec)

mysql> select * from xifenfei.user_login limit 1;
+ ---------------------------------- + --------- + ---- ------- + ----------- + ----------
------------------------ + ------ + ------------------ --- + --------------------------
-------- + ---------- + ------------ +
| ID | ACCOUNT | LifeCycle | Name | Password
                        | Role | UTime | UserID
        | UserName | UserStatus |
+ ---------------------------------- + --------- + ---- ------- + ----------- + ----------
------------------------ + ------ + ------------------ --- + --------------------------
-------- + ---------- + ------------ +
| 010d6c85a76c44cba80d07cbd8590bb2 | hyh | 0 | Hu Yuanhui | 698d51a19
d8a121ce581499d7b701668 | | 6 | | 2016-08-30 06:04:32 | 0fe3bc4dd9654687a4b85065e
d5cfee8 | NULL | 1 |
+ ---------------------------------- + --------- + ---- ------- + ----------- + ----------
------------------------ + ------ + ------------------ --- + --------------------------
-------- + ---------- + ------------ +
1 row in set (0.00 sec)

After the discard tablespace and import tablespace operations provided by mysql, the table data can be completed.
mysql log

2016-12-25 23:34:08 10464 [ERROR] InnoDB: Failed to find tablespace for table '"xifenfei". "User_login"' in the cache. Attempting to load the tablespace with space id 56.
2016-12-25 23:34:08 10464 [ERROR] InnoDB: In file '. \ Xifenfei \ user_login.ibd', tablespace id and flags are 47 and 0, but in the InnoDB data dictionary they are 56 and 0. Have you moved InnoDB .ibd files around without using the commands DISCARD TABLESPACE and IMPORT TABLESPACE? Please refer to http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
2016-12-25 23:34:08 10464 [ERROR] InnoDB: Could not find a valid tablespace file for 'xifenfei / user_login'. See http://dev.mysql.com/doc/refman/5.6/en/innodb -troubleshooting-datadict.html for how to resolve the issue.
2016-12-25 23:34:08 30e8 InnoDB: cannot calculate statistics for table "xifenfei". "User_login" because the .ibd file is missing. For help, please refer to http://dev.mysql.com/doc /refman/5.6/en/innodb-troubleshooting.html
2016-12-25 23:34:08 10464 [ERROR] InnoDB: Cannot delete tablespace 56 because it is not found in the tablespace memory cache.
2016-12-25 23:34:08 10464 [Warning] InnoDB: Cannot delete tablespace 56 in DISCARD TABLESPACE. Tablespace not found
2016-12-25 23:34:41 10464 [Note] InnoDB: Sync to disk
2016-12-25 23:34:41 10464 [Note] InnoDB: Sync to disk-done!
2016-12-25 23:34:41 10464 [Note] InnoDB: Phase I-Update all pages
2016-12-25 23:34:41 10464 [Note] InnoDB: Sync to disk
2016-12-25 23:34:41 10464 [Note] InnoDB: Sync to disk-done!
2016-12-25 23:34:41 10464 [Warning] InnoDB: Tablespace 'xifenfei / user_login' exists in the cache with id 47! = 56
2016-12-25 23:34:41 10464 [Warning] InnoDB: Freeing existing tablespace 'xifenfei / user_login' entry from the cache with id 56
2016-12-25 23:34:41 10464 [Note] InnoDB: Phase III-Flush changes to disk
2016-12-25 23:34:41 10464 [Note] InnoDB: Phase IV-Flush complete

The mysql log still reports that the page dictionary information does not match. But the data is already accessible, you can re-create the table through mysqldump export. If this method cannot be restored due to ibd damage, please refer to: MySQL drop database recovery (the recovery method is also applicable to MySQL drop table, delete, truncate table)