QNAP NAS encrypted by ransomware - photorec does not backup all files and restore script quits with error

Using PhotoRec to recover lost data
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Locked
Message
Author
hvgayc
Posts: 3
Joined: 05 May 2022, 14:28

QNAP NAS encrypted by ransomware - photorec does not backup all files and restore script quits with error

#1 Post by hvgayc »

My QNAP NAS system is affected by qlocker ransomware and all files below 30mb size are encrypted now. Following the advice from QNAP support I installed Qrescue which is using photorec + qrescue recovery (python) script. I have a RAID1 system with 2x 3TB WD RED hard disks. Unfortunately i realized the attack to late so no chance to get the key. My questions are:

1) Why is the size of the data on disk (/share/cachedev1) 1.9TB but the size of the recup1 directory (backup) created by photorec only 1.2TB? The whole disk was marked for backup in the recovery proccess, but it seems to me that there is lots of data missing in the backup. I cannot compare it though, because of the special naming and ordering of the recovered data and because restore proccess fails (see point 3). What are possible reasons for photorec not copying all data while doing a backup operation? The process is finished without errors.
PhotoRec 7.2-WIP, Data Recovery Utility, May 2021
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/mapper/cachedev1 - 2418 GB / 2252 GiB (RO)
Partition Start End Size in sectors
P ext4 0 0 1 429391871 0 1 4724359168 [DataVol1]


714213 files saved in /share/rescue/recup1/recup_dir directory.
Recovery completed.
2) The restore script is a compiled python script (qrescue.pyc), hence i have little insight in what it is doing in detail. But from the logs I can see that many JPG files are skipped during restore proccess. They do not seem to differ noticeably from the ones that are restored successfully in size, metadata,... and I can see the decrypted files in the correct folder on the disc, so why are they skipped during restore proccess and is there a possibility to get these files also converted into original name+metadata? Has anyone experience in success rate of testdisk vs. qrescue?
from qrescue_trace.log:
2022-05-04 07:16:05,629(DEBUG) [qrescue(1240):recup_all_7z_files()] handling 7z meta={
"attr": "A_ -rwxrwxrwx",
"crc": "A2C9CA04",
"ext": "JPG",
"file_name": "2019-03-03_BEGI_HANDY_021.JPG",
"mtime": "2019-03-03 18:54:28",
"path": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG",
"size": 5962476
}
2022-05-04 07:16:05,980(DEBUG) [qrescue(1241):recup_all_7z_files()] handling 7z file=/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z
2022-05-04 07:16:07,124(DEBUG) [qrescue(1253):recup_all_7z_files()] matched info={
"error": 2,
"filepath": null,
"same_size": 0
}
2022-05-04 07:16:07,124(ERROR) [qrescue(1258):recup_all_7z_files()] "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z" NOT FOUND !
2022-05-04 07:16:07,125(INFO) [qrescue(790):print_progress()] {
"act": "skip",
"act_7Z": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z",
"proceeded_7Zs": 71493,
"proceeded_%": "33.42%",
"total_7Zs": 213919,
"total_recap": 724187,
"fix": 19093,
"skip": 52400,
"fix%": "26.71%",
"start_time": "2022-05-03 10:20:21",
"elapsed": "20:55:45.32",
"estimated total time": "62:37:25.77",
"estimated remaining time": "41:41:40.46"
}
2022-05-04 07:16:07,128(DEBUG) [qrescue(366):get_file_info_from_7z()] cmd = "/usr/local/sbin/7z.orig l -slt /usr/local/sbin/7z.orig"
3) The script exits with error each time it hits a certain file containing the german letter "Ö" in its filename. The exact error message is "OverflowError: mktime argument out of range", which I identified as time error - argument mtime is too far from current time. Since i can check the metadata of encrypted file on NAS and it seems to be okay, I wonder if the file name (that cannot even be displayed correctly) causes the strange date and leads to error. See below:
2022-05-04 13:17:38,437(DEBUG) [qrescue(366):get_file_info_from_7z()] cmd = "/usr/local/sbin/7z.orig l -slt /usr/local/sbin/7z.orig"
2022-05-04 13:17:38,616(DEBUG) [qrescue(1240):recup_all_7z_files()] handling 7z meta={
"attr": "A_ -rwxrwxrwx",
"crc": "E24CA280",
"ext": "JPG",
"file_name": "2008-08-20_TAT\u00d6_004.JPG",
"mtime": "2104-11-19 00:42:24",
"path": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TAT\u00d6_004.JPG",
"size": 956991
}
2022-05-04 13:17:38,617(DEBUG) [qrescue(1241):recup_all_7z_files()] handling 7z file=/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TATÖ_004.JPG.7z
2022-05-04 13:17:40,097(DEBUG) [qrescue(1253):recup_all_7z_files()] matched info={
"error": 0,
"filepath": "/share/rescue/recup1/recup_dir.338/f616537072.jpg",
"same_size": 1
}
2022-05-04 13:17:40,097(DEBUG) [qrescue(1274):recup_all_7z_files()] matched={
"error": 0,
"filepath": "/share/rescue/recup1/recup_dir.338/f616537072.jpg",
"same_size": 1
}
2022-05-04 13:17:40,124(DEBUG) [qrescue(1279):recup_all_7z_files()] copp recup file:"/share/rescue/recup1/recup_dir.338/f616537072.jpg" to "/share/rescue/restore1/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TATÖ_004.JPG"
# proccess quit here. No more lines in log.
May the special character be responsible for the error? If so, is there a way to ignore it (all files containing äöü case-insensitive)? Or what other reason could lead to this error?


4) In terms of data recovery, I have learned the rule "do not touch the crime scene" which means afaik "do not overwrite or change data". But do I limit my recovery chances by renaming files on the affected disks but letting the file contents as-is and where-it-is? And in addition, do I limit my recovery chances by cutting files to another backup hard disk and copy it back later in the same location on the affected hard disk?

5) Do I have extended chances to get data back using the single hard disks during recovery proccess instead of selecting share/CACHEDEV1/ (which is recommended approach)?


Unfortunately i got no help from QNAP support besides the recovery instruction (quick how-to use qrescue). I am familiar with Linux and have lots of (backup-) disc space available. Any help would be greatly appreciated!

recuperation
Posts: 2720
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: QNAP NAS encrypted by ransomware - photorec does not backup all files and restore script quits with error

#2 Post by recuperation »

hvgayc wrote: 06 May 2022, 23:10 My QNAP NAS system is affected by qlocker ransomware and all files below 30mb size are encrypted now. Following the advice from QNAP support I installed Qrescue which is using photorec + qrescue recovery (python) script. I have a RAID1 system with 2x 3TB WD RED hard disks. Unfortunately i realized the attack to late so no chance to get the key. My questions are:

1) Why is the size of the data on disk (/share/cachedev1) 1.9TB but the size of the recup1 directory (backup) created by photorec only 1.2TB? The whole disk was marked for backup in the recovery proccess, but it seems to me that there is lots of data missing in the backup. I cannot compare it though, because of the special naming and ordering of the recovered data and because restore proccess fails (see point 3). What are possible reasons for photorec not copying all data while doing a backup operation? The process is finished without errors.
Photorec is based on identifying fingerprints. Encryption of files destroys the fingerprints.
But without being familiar with the the QNAP issue:
If there is no decryption key available why should your recovery tool extract files that you can't read anyway?
From what I read about the QNAP issue, the attack is on file level. That means, the attacker does not modify partitions and file systems, just files.
Therefore there is no reason to extract everything.
2) The restore script is a compiled python script (qrescue.pyc), hence i have little insight in what it is doing in detail. But from the logs I can see that many JPG files are skipped during restore proccess. They do not seem to differ noticeably from the ones that are restored successfully in size, metadata,... and I can see the decrypted files in the correct folder on the disc, so why are they skipped during restore proccess and is there a possibility to get these files also converted into original name+metadata? Has anyone experience in success rate of testdisk vs. qrescue?
from qrescue_trace.log:
2022-05-04 07:16:05,629(DEBUG) [qrescue(1240):recup_all_7z_files()] handling 7z meta={
"attr": "A_ -rwxrwxrwx",
"crc": "A2C9CA04",
"ext": "JPG",
"file_name": "2019-03-03_BEGI_HANDY_021.JPG",
"mtime": "2019-03-03 18:54:28",
"path": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG",
"size": 5962476
}
2022-05-04 07:16:05,980(DEBUG) [qrescue(1241):recup_all_7z_files()] handling 7z file=/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z
2022-05-04 07:16:07,124(DEBUG) [qrescue(1253):recup_all_7z_files()] matched info={
"error": 2,
"filepath": null,
"same_size": 0
}
2022-05-04 07:16:07,124(ERROR) [qrescue(1258):recup_all_7z_files()] "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z" NOT FOUND !
2022-05-04 07:16:07,125(INFO) [qrescue(790):print_progress()] {
"act": "skip",
"act_7Z": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z",
"proceeded_7Zs": 71493,
"proceeded_%": "33.42%",
"total_7Zs": 213919,
"total_recap": 724187,
"fix": 19093,
"skip": 52400,
"fix%": "26.71%",
"start_time": "2022-05-03 10:20:21",
"elapsed": "20:55:45.32",
"estimated total time": "62:37:25.77",
"estimated remaining time": "41:41:40.46"
}
2022-05-04 07:16:07,128(DEBUG) [qrescue(366):get_file_info_from_7z()] cmd = "/usr/local/sbin/7z.orig l -slt /usr/local/sbin/7z.orig"
It appears to me that the script generates a file name out of existing file metadata. If the related 7z file does not exist, a step is skipped. That behaviour sounds pretty natural to me.

3) The script exits with error each time it hits a certain file containing the german letter "Ö" in its filename. The exact error message is "OverflowError: mktime argument out of range", which I identified as time error - argument mtime is too far from current time. Since i can check the metadata of encrypted file on NAS and it seems to be okay, I wonder if the file name (that cannot even be displayed correctly) causes the strange date and leads to error. See below:
2022-05-04 13:17:38,437(DEBUG) [qrescue(366):get_file_info_from_7z()] cmd = "/usr/local/sbin/7z.orig l -slt /usr/local/sbin/7z.orig"
2022-05-04 13:17:38,616(DEBUG) [qrescue(1240):recup_all_7z_files()] handling 7z meta={
"attr": "A_ -rwxrwxrwx",
"crc": "E24CA280",
"ext": "JPG",
"file_name": "2008-08-20_TAT\u00d6_004.JPG",
"mtime": "2104-11-19 00:42:24",
"path": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TAT\u00d6_004.JPG",
"size": 956991
}
2022-05-04 13:17:38,617(DEBUG) [qrescue(1241):recup_all_7z_files()] handling 7z file=/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TATÖ_004.JPG.7z
2022-05-04 13:17:40,097(DEBUG) [qrescue(1253):recup_all_7z_files()] matched info={
"error": 0,
"filepath": "/share/rescue/recup1/recup_dir.338/f616537072.jpg",
"same_size": 1
}
2022-05-04 13:17:40,097(DEBUG) [qrescue(1274):recup_all_7z_files()] matched={
"error": 0,
"filepath": "/share/rescue/recup1/recup_dir.338/f616537072.jpg",
"same_size": 1
}
2022-05-04 13:17:40,124(DEBUG) [qrescue(1279):recup_all_7z_files()] copp recup file:"/share/rescue/recup1/recup_dir.338/f616537072.jpg" to "/share/rescue/restore1/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TATÖ_004.JPG"
# proccess quit here. No more lines in log.
May the special character be responsible for the error? If so, is there a way to ignore it (all files containing äöü case-insensitive)? Or what other reason could lead to this error?
Your German "Umlaute" may origin from metadata.

4) In terms of data recovery, I have learned the rule "do not touch the crime scene" which means afaik "do not overwrite or change data". But do I limit my recovery chances by renaming files on the affected disks but letting the file contents as-is and where-it-is? And in addition, do I limit my recovery chances by cutting files to another backup hard disk and copy it back later in the same location on the affected hard disk?
You should rather verify if you have the "ö" letter in file names at all. You might consider telling me if you are a crypto german who is posting in English language here instead of German. It is pretty normal for crypto germans to have special characters like "äöüßÄÖÜß" in their file names.
5) Do I have extended chances to get data back using the single hard disks during recovery proccess instead of selecting share/CACHEDEV1/ (which is recommended approach)?
If a low level access is required your recommendation would that that.

hvgayc
Posts: 3
Joined: 05 May 2022, 14:28

Re: QNAP NAS encrypted by ransomware - photorec does not backup all files and restore script quits with error

#3 Post by hvgayc »

hello recuperation, thanks for your reply.
You might consider telling me if you are a crypto german who is posting in English language here instead of German. It is pretty normal for crypto germans to have special characters like "äöüßÄÖÜß" in their file names.
First I would like to clarify that I am german indeed, but no crypto german. Normal german guy who has lost his and his family's entire past to ransomware. I am posting in english language to reach more experts and get more help, that's all.

1)
Therefore there is no reason to extract everything.
The recovery manual written by qnap instructs the users to make a full backup. I thought this would be a good idea, but nevertheless, I wonder why a full backup is only 2/3 the size (1.2TB of 1.9TB) of the original directory.

2)
It appears to me that the script generates a file name out of existing file metadata. If the related 7z file does not exist, a step is skipped. That behaviour sounds pretty natural to me.

You are absolutely right. The problem is that the related 7z files exist in my case, the path is correct, and the file is skipped during restore proccess nonetheless. And that affects many many files in many directories. E.g. from one folder with 68 JPG files, only 13 are restored and 55 skipped. I don't unterstand the reason and the pattern why/how some files are restored but many are skipped.

3)
Your German "Umlaute" may origin from metadata.
Unfortunately they are contained in the filenames. Is there a way to bypass them at string check? Does testdisk also have problems with these kind of characters? My next approach is using testdisk for restoring, i hope that it does not run into the same problem.

4)
You should rather verify if you have the "ö" letter in file names at all.
I can confirm that the letters causing the problem are part of the file names. I will try to avoid this in future, but that does not help me right now.
But do I limit my recovery chances by renaming files on the affected disks but letting the file contents as-is and where-it-is?
This would be important to know for me! I could rename all affected 7zip files on my NAS using a script in order to avoid this python error.

Thank you for your answers in advance. I greatly appreciate any help.

recuperation
Posts: 2720
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: QNAP NAS encrypted by ransomware - photorec does not backup all files and restore script quits with error

#4 Post by recuperation »

hvgayc wrote: 19 May 2022, 13:57 hello recuperation, thanks for your reply.
You might consider telling me if you are a crypto german who is posting in English language here instead of German. It is pretty normal for crypto germans to have special characters like "äöüßÄÖÜß" in their file names.
First I would like to clarify that I am german indeed, but no crypto german. Normal german guy who has lost his and his family's entire past to ransomware. I am posting in english language to reach more experts and get more help, that's all.

1)
Therefore there is no reason to extract everything.
The recovery manual written by qnap instructs the users to make a full backup. I thought this would be a good idea, but nevertheless, I wonder why a full backup is only 2/3 the size (1.2TB of 1.9TB) of the original directory.
Dear readers, the following text contains very specific answers which are not of general interest. You do not miss anything if you don't speak German.
Hier spricht der Testdisk-Support! Für QNAP-spezifische Probleme sprechen Sie bitte die Firma QNAP an. Darüber ist die Problembeschreibung sowieso vollkommen unzureichend. Trotzdem zwei Hinweise: 1. defekte Festplatte(n) oder 2. Zieldateisystem unterstützt Dateigrößen nicht.


2)
It appears to me that the script generates a file name out of existing file metadata. If the related 7z file does not exist, a step is skipped. That behaviour sounds pretty natural to me.

You are absolutely right. The problem is that the related 7z files exist in my case, the path is correct, and the file is skipped during restore proccess nonetheless. And that affects many many files in many directories. E.g. from one folder with 68 JPG files, only 13 are restored and 55 skipped. I don't unterstand the reason and the pattern why/how some files are restored but many are skipped.
siehe 1)


3)
Your German "Umlaute" may origin from metadata.
Unfortunately they are contained in the filenames. Is there a way to bypass them at string check? Does testdisk also have problems with these kind of characters? My next approach is using testdisk for restoring, i hope that it does not run into the same problem.
Ich weiß es nicht. Die Beschränkung auf reinen ASCII-Code würde Testdisk stark in der Nutzung einschränken, da z.B. NTFS UTF-Codes in Zwei-Byte-Darstellung unterstützt. Die Frage können Sie mit 2 Minuten selber testen beantworten.

4)
You should rather verify if you have the "ö" letter in file names at all.
I can confirm that the letters causing the problem are part of the file names. I will try to avoid this in future, but that does not help me right now.
But do I limit my recovery chances by renaming files on the affected disks but letting the file contents as-is and where-it-is?
This would be important to know for me! I could rename all affected 7zip files on my NAS using a script in order to avoid this python error.
Keine Ahnung. Duplizieren Sie alles, dann können Sie nach Herzenslust spielen. Das ist kein Witz - ich würde das genauso machen.

recuperation
Posts: 2720
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: QNAP NAS encrypted by ransomware - photorec does not backup all files and restore script quits with error

#5 Post by recuperation »

Anbei noch ein kleiner Zusatz:
1) Why is the size of the data on disk (/share/cachedev1) 1.9TB but the size of the recup1 directory (backup) created by photorec only 1.2TB?
Hier stellt sich die Frage, wie die 1,9 TB gemessen wurden. Ist das Gerätegröße abzüglich freiem Speicher, oder wurde rekursiv alle Dateigrößen über ein Verzeichnis addiert?

Liegen Hardlinks vor, oder handelt es sich um ein "copy on write" - Dateisystem, kann es Unterschiede geben.

Locked