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

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.