Hi

I need to undelete a file ( size 20GB) but can not find any software which works. File is seen as 0 size. I did not overwrite the file.

Any tips? Thanks

What are you using?
What happened to the drive before?

_________________
http://www.pclab.com.pt facebook.com/PCLAB.A.T
ACELab partner

"any software that works" would be better replaced with ones you have already tried.
If R-Studio or GetDataBack doesn't help, then maybe manual file carving is needed.

You don't give any details such as OS, filetype, steps you have done that may have attributed to the problems..

cant undelete... is that because windows reported file was too big for recycle bin?

If you are still using the disk this file is lost on, for example it is the only disk in your PC, you would be almost certainly damaging it further every second your computer is turned on.

you should image the disk instantly, but I fear getting a file back of that size that needs to be 100% intact to work, after any length of time is going to be near on impossible.

The file is a veracrypt volume and I deleted by mistake. It is on his own partition E:\ drive and I haven't written anything on that drive since I deleted.

The only one that recognizes its size is rstudio. I tried to recover to another drive (C: drive ) but veracrypt can not open the volume, so I guess the recovery is not 100%

ouch!, I don't know what to suggest here. I don't know veracrypt at all. Hopefully someone else has some ideas. Good Luck

Many crypt container files intentionally have no file signatures so they can't be recovered by data recovery software. It'll all part of what they call "plausible deniability". You can't even prove encrypted data was ever there.

I'm not actually familiar with veracrypt, but if you get me a few sample files created the same way I might be able to rig up a custom file carving xml to plug into R-Studio. PM me if you're interested.

_________________
Data Medics - Hard Drive, SSD, and RAID Data Recovery Service Company

Looking at the sample files you sent me, I can't see any viable signature to search for. And what Veracrypt says here backs that up: https://veracrypt.codeplex.com/wikipage ... eniability

They claim it has no identifiable "signature" to identify it. Sorry man, I think you are out of luck. Unless you know the starting and ending sector numbers it was stored at, not much to do file carving wise. Maybe with the right software like R-Studio you can find a reference in the file tables, but if not....

_________________
Data Medics - Hard Drive, SSD, and RAID Data Recovery Service Company

so the only way left "if it can be done" i repeat "if it can be done" is hard work manually, and a lot of luck

Could you pretend that the whole drive is encrypted and decrypt it with the saved key (assuming there is one) and then run a recovery after that?

_________________
Luke
Recovery Force Data Recovery

I don't think so (that was my first thought too). Talking with the guys at Veracrypt, seems that it's based on Truecrypt architecture and it uses a random key hidden in the header which is further encrypted using the password key. So even if you use the same password to encrypt the drive, it'd be using a different random key over the data area making identification of the file header impossible still.

Only other method I could think to try is looking at the filesystem bitmap for a gap in sectors approximately the size of the file. But, will only work if the file wasn't fragmented.

_________________
Data Medics - Hard Drive, SSD, and RAID Data Recovery Service Company

that's what I meant

Assuming partition e: is not fully encrypted and that you have stored the volume as a file like you would do on truecrypt then what you have is a normal NTFS/FAT32 whatever partition with normal files and a "special" file (that was deleted) that will look like random "junk" so can't be "carved" by tools like R-Studio.
If you still know where the file is stored on the platter, or in other words, if you can find the start LBA and end LBA of the file on the disk using a disk editor and assuming that the file was not fragmented you should still be able to "extract" that file by copy the portion from start LBA- end LBA with the "encrypted data" (that looks like random "junk" on the disk hex editor) and then create a new file (on another unit) with that same data and mount that on the veracrypt (assuming it will work just like truecrypt but with more iterations, key strenght, etc ....)

If it's a full partition encryption or a full drive encryption maybe you have a recoveery CD/DVD created when applying the full drive encryption to force the decryption of the entire unit ? But i guess it's not the case, it wouldn't make sense as you stated a 20 GB file and you wouldn't be able to "delete" the file unless it's a file that it's actually a container for the other encrypted files.

If the drive was fragmented when you created the volume then the chances are that the volume (that will look like random junk characters) was written all over the drive/partition (and as a matter of fact i don't even know if veracrypt/truecrypt wouldn't do that even if you have a full partition whithout data on it - like "fragment" the volume container file by writing portions of ot with LBA gaps) then you would have to find all the portions of the "container" on the drive LBAs and join that on the correct order and then mount on veracrypt for decryption .....

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

a simple way to find out if it's written on random places, is to creating a new file on an empty zero filled HDD, and then examine the drive/file structure.

I don't know how TrueCrypt or VeraCrypt work, but ISTM that in order to satisfy the criterion of plausible deniability, an encrypted volume must not contain any pattern that could be construed as being consistent with a recognised file system or partition layout.

For example, a Windows XP partitioned HDD will have an MBR in sector 0, followed by zero-filled sectors 1 to 62, and then a boot sector at LBA 63. A FAT32 file system will have a copy of the boot sector at LBA 69 while an NTFS volume will have a copy at the end. If the encrypted volume were to demonstrate this same pattern, albeit with encrypted data, then any claim to plausible deniability would be gone. Therefore, ISTM that identical data in different sectors should be encrypted differently, presumably with the LBA influencing the encryption process. If so, then simply carving a range of sectors and copying them to a different location would not work.

_________________
A backup a day keeps DR away.