cgsecurity.org

One (probably) final post.
The disk was ransomed, all files were put in a .7z file.
However 7z l -slt retrieves some info from the zip file including the file name and the crc for the file.
By calculating the crc of the recovered files and comparing with the info in the 7z listing it was possible ...

Thanks for spotting the problem. Can you try the following fix ?

diff --git a/home/kmaster/src/git/testdisk/src/file_riff.c b/./file_riff.c
index 4bd69e0..3b68d6e 100644
--- a/home/kmaster/src/git/testdisk/src/file_riff.c
+++ b/./file_riff.c
@@ -153,7 +153,7 @@ static void check_riff_list(file ...

I already made the middle change yesterday evening.
That one seemed to fix the issue. That is, photorec continued and recovered more files.
The recovery of the disk is still in progress and will probably complete tomorrow early morning.
Once the recovery of this disk is completed I'll try your patch ...

Hmm, I spotted a possible issue while reading the code.

In file_riff.c it reads
165 file_size = next_fs;
166 /* align to word boundary */
167 file_size = (file_size&1);

Is this last line correct? I see a bitwise and with 1 here so after this files_size will be 0 or 1
Shouldn't this line read ...

EDIT: the issue seems to be solved. See post #11. I kept this here for reference/additional information.

Ok, after peeking into the source I figured that the fail could be at the read at line 135 of file_rff.c so I went back to gdb and used next to find out a bit more of the flow

Program received ...

EDIT: the issue seems to be solved. See post #11. I kept this here for reference/additional information.

Ok, this hang is repeatable.It just halted again at about the the same spot.
See attachment.
Screen is not updated any more (neither sectors read nor the elapsed time and expected duration.
top ...

When it was hanging it indeed used up 100% of the CPU.
dmesg gives nothing around the time of failure.
kern.log is same info as dmesg
syslog has messages about metadata extraction, not sure if that is related. These messages seem to stop around the time the last data was received.
This is a snippet ...

I was trying to recover whatever possible from an 8 TB harddisk that was locked by ransomware.
I merged your second topic with the first one.

Now we know why it did not work out well: You are trying to recover a 8TB disk to a 5TB disk.
Unfortunately you did not mention the size of the source ...

I started recovery on a disk that had ransomware on it. The disk has a btrfs filesystem on it and apparently the ransomware created a large zip file (maybe a bogus one).

When running qphotorec on this disk it very quickly complained about a file that could not be stored on the rescue drive (an ...

I was trying to recover whatever possible from an 8 TB harddisk that was locked by ransomware.
I used qphotorec but unfortunately recovery stalled at 23 %. The program was just hanging and not reading data any more.
This is the status
https://ibb.co/kB1J62X . It was like this for the last 12 hrs ...