Recovery of a 10 GB password protected Rar File show 0 Bytes

[am117]

Hi friends.

I had a 10 GB rar file which was password protected. It got deleted from a partition which the OS was NOT on. I'm 90% sure nothing was written on the drive.

I used "GetDataBack" and it found the file name but 0 Bytes of file size. Then I gave the disk to a friend who has a MRT recovery card (don't know which model) and he tried. But he got the same result.

I searched and there are both positive and negative answers that "There is no data, don't try. It's gone" and "There are ways to recover 0 Bytes files".

So what should I do, Is there any hope?

[am117]

Rar file is encrypted (as it have password) and most likely FRAGMENTED as it's very big - 10 GB.

..... as the encryption will look like random noise.

But doesn't the blocks of file stored on the drive have headers info about the next block? something like "Linked Lists"?



I suppose there must be some headers and also the header is not encrypted. Correct me if I'm wrong

[Hermes]

It does sound like you've tried to carve data out of a encrypted archive. If you have the encryption password look around for third party software that can decrypt the archive eve with damage, if not have a look at the Elcomsoft offerings on software that can deal with passwords and encryption assuming you own the archive and your password does not work.

[abolibibelot]

I used "GetDataBack" and it found the file name but 0 Bytes of file size.

Your only hope is if the master file alocation table is still intact and does still have the entries for your deleted file, and i believe that at this point it doesn't so it's game over....

I read that when files larger than 4GB get deleted, the complete cluster chain can no longer be retrieved, since it's too large to fit in a single MFT record. See this post (and thread) for more details :
viewtopic.php?p=256553#p256553

https://forum.piriform.com/topic/36987- ... ecover-it/

If it's more than 4 gb (or was, and I guess an image file could well be) then Windows erases the file cluster adresses on deletion. The data is still on disk but the entry in the MFT no longer points to it.

I think that Recuva has, in the last release or two, changed the way large files are reported. Previously, deleted files over 4 gb in size would be reported as zero bytes, and unrecoverable. Now it appears that the file size is reported, but with the comment that 'File's data could not be found on the disk.' Although NTFS zaps both the file size and the cluster run info in the $Data attribute in the MFT record, the original file size is still available in the $File_Name attribute (although not necessarily accurate). Perhaps this is where Recuva finds the info. If the file is under 4gb but in many extents then it may have forced the $Data attribute to become non-resident, i.e. to be held in a second MFT record for the file. In this case NTFS will, on deletion, zap the cluster run info in the MFT extension record, so the file is unrecoverable. It appears that Recuva also reports these files as 'File's data could not be found on the disk.'

https://forum.piriform.com/topic/38062- ... -and-more/

I have found, from experiment and from comments elsewhere, that NTFS manages deletion of files larger than 4GB differently from those smaller than 4GB. In the smaller files the entry in the MFT is (relatively) simply flagged as deleted, and the dataruns – the fields that hold the address and number of clusters for each extent – are untouched. This is how Recuva can find and recover the file data. In files larger than 4GB the dataruns are overwritten by NTFS. Although the file size is still available, the addresses of the data are not, and Recuva will show the Data not Found on Disk message. In this case no recovery programme can recover data from information in the MFT.
This also happens in smaller files which are in many extents. If the list of extents is too long to fit into a single MFT record it is placed in a MFT extension record. These too are erased on file deletion, leaving the file data unrecoverable.

You might want to try R-Studio, UFS explorer, DMDE, etc ...

And you might want to create an image of the drive (or the partition where the file is/was at least) to avoid the possibility of messing with it inadvertently while trying a bunch of different methods.

R-Studio, and even Recuva possibly (with the “Deep search” option activated), could locate the file by its header, which is called “raw file carving”. Then if you're lucky and one of these softwares does find a 10GB RAR file (it won't have its original name, expect something like “000035.rar” in R-Studio or “[000035].rar in Recuva) and it's not fragmented, you should be able to extract it in one piece right away and the password should work.
Photorec (companion program of TestDisk) is specifically designed for raw file carving ; although you can uncheck all file types except RAR (otherwise it will extract a gazillion of files of various types, everything that matches a common file pattern), it's less convenient than the other two as it will extract all RAR files it finds, but if the file you want is fragmented it will attempt to connect fragments – it may work in a simple case, for instance if there are two fragments separated by one other file, it's worth trying but I have yet to see it actually recover one fragmented file.
Failing that, maybe analysing the whole MFT could allow someone with knowledge and patience to find the required data to piece together the complete file...

But doesn't the blocks of file stored on the drive have headers info about the next block? something like "Linked Lists"?
I suppose there must be some headers and also the header is not encrypted. Correct me if I'm wrong

If I'm not mistaken, that's not file headers you're describing but MFT records (on a NTFS partition, which is probably what you have if you tried using GetDataBack). And as far as I know, no, there are no such things as header informations regarding the location of the next blocks within the files themselves, at least not for RAR archives, the cluster allocation information is all in the MFT.

[Alexey]

I read that when files larger than 4GB get deleted, the complete cluster chain can no longer be retrieved, since it's too large to fit in a single MFT record.

1. The size of a runlist (cluster chain stored in MFT) does not depend on file size, it depends on number of fragments in file and also if NTFS compression is enabled for the file.
2. Any first-line tool can assemble cluster chains from multiple MFT records, if all records are available (that is, not overwritten).

I have found, from experiment and from comments elsewhere, that NTFS manages deletion of files larger than 4GB differently from those smaller than 4GB. In the smaller files the entry in the MFT is (relatively) simply flagged as deleted, and the dataruns – the fields that hold the address and number of clusters for each extent – are untouched. This is how Recuva can find and recover the file data. In files larger than 4GB the dataruns are overwritten by NTFS. Although the file size is still available, the addresses of the data are not, and Recuva will show the Data not Found on Disk message. In this case no recovery programme can recover data from information in the MFT.
This also happens in smaller files which are in many extents. If the list of extents is too long to fit into a single MFT record it is placed in a MFT extension record. These too are erased on file deletion, leaving the file data unrecoverable.

This statement is not technically correct. This may be applicable to Recuva if it does not have a capability to look up and link to extension records, but in general case, the runlists are still available after file is deleted.

[abolibibelot]

1. The size of a runlist (cluster chain stored in MFT) does not depend on file size, it depends on number of fragments in file and also if NTFS compression is enabled for the file.
2. Any first-line tool can assemble cluster chains from multiple MFT records, if all records are available (that is, not overwritten).

Alright, thanks for those corrections. It is noted in the quotes above that files smaller than 4GB can be affected by that issue, but is it correct that all files above 4GB are concerned by this issue ?
How does NTFS compression interfere with this aspect ?
And what do you call a “first-line” tool ?

This statement is not technically correct. This may be applicable to Recuva if it does not have a capability to look up and link to extension records, but in general case, the runlists are still available after file is deleted.

I have seen the same behaviour in R-Studio for instance : for instance a directory with deleted MKV files, those with a size below 4GB appear with their native name, size, timestamps and other metadata, those above 4GB only appear as “extra found files” (and only in very recent versions as raw MKV detection used to be lackluster in this otherwise excellent software). How do you explain that several prominent recovery softwares are affected by that issue ?

[Alexey]

It is noted in the quotes above that files smaller than 4GB can be affected by that issue, but is it correct that all files above 4GB are concerned by this issue ?

File size is not relevant to the issue. The requirement to use several MFT records instead of one comes from number of fragments in file. Each fragment requires several bytes to describe and as soon as 1024- or 4096-byte MFT record overflows, the second one will be created, and then the third one and more, as needed.

How does NTFS compression interfere with this aspect ?

NTFS compression splits file into 64KB fragments internally, for the purpose of compression. Each fragment may then require its own description, which overflows the single MFT record pretty quick.

And what do you call a “first-line” tool ?

As far as NTFS goes, any of ZAR, R-Studio, ReclaiMe, or UFS. If by your observation R-Studio does not do it, then strike it from the list, although I have to admit I'm surprised. NTFS is well-known by now with exhaustive documentation available.

[drHDD]

Hi friends.

I had a 10 GB rar file which was password protected. It got deleted from a partition which the OS was NOT on. I'm 90% sure nothing was written on the drive.

I used "GetDataBack" and it found the file name but 0 Bytes of file size. Then I gave the disk to a friend who has a MRT recovery card (don't know which model) and he tried. But he got the same result.

I searched and there are both positive and negative answers that "There is no data, don't try. It's gone" and "There are ways to recover 0 Bytes files".

So what should I do, Is there any hope?

There is hope, but you need to go to pro.

[fzabkar]

@am117, you could use the "Gather Free Space" function in WinHex to copy all unused clusters to a file on another drive.

Alternatively, you could clone your drive or partition in full, and then delete and "wipe" (zero fill) all active files on the clone. This will then leave you with a clone where all the non-zero data correspond to unused clusters. If you then find the RAR! signature for your missing archive, you should find it easier to reassemble your data by skipping over the zero-filled areas between file fragments.

[Amarbir[CDR-Labs]]

Hi,
Is its fragmented ,which 100% it will be game over ,If it was a text file no issue ,Its a Encrypted File By RAR "Compressed Technically " And Actually Compressed and Encrypted .

[DR-Kiev]

Hi,
Is its fragmented ,which 100% it will be game over ,If it was a text file no issue ,Its a Encrypted File By RAR "Compressed Technically " And Actually Compressed and Encrypted .

That is unprofessional opinion. If you dont know how to pick up fragments, dont say 100% it is not possible.

fzabkar wrote one of the way to do that even for compressed or encryted files.
Same way could be done for outlook.pst files with huge size and lost MFT entries, and it works great for them.

From my side , i would tell best tool to exclude filled area with files and work only with unfilled ones, is Data Extractor.

[posidon]

Hi,
Is its fragmented ,which 100% it will be game over ,If it was a text file no issue ,Its a Encrypted File By RAR "Compressed Technically " And Actually Compressed and Encrypted .

That is unprofessional opinion. If you dont know how to pick up fragments, dont say 100% it is not possible.

fzabkar wrote one of the way to do that even for compressed or encryted files.
Same way could be done for outlook.pst files with huge size and lost MFT entries, and it works great for them.

From my side , i would tell best tool to exclude filled area with files and work only with unfilled ones, is Data Extractor.

Great Dr-Kiev
This is core recovery work ( manual reconstruction of data on low level) , I am sure results will be there for cases where file entry is slipped out of MFTs or overwritting cases ( Severe file system damage) etc.
Recovery may not be possible by using hundreds of Data recovery softwares.
It will be great to learn firmware recovery from Dr-Kiev (if he permits ). Person like me who is in lower KG will be directly eligible for college admissions