When you edit a file, how can the previous version be recovered?
 

Heard of Recuva to recover deleted files even if they have been overwritten. Can similar recovery be done with previous versions of a file that has been edited?

Even if all versions are using the same sectors?

What's the tool to use?

Hi. I think only if you used a tool (for example Kate) that makes automatic backups for you but you could look into forensics tools?

http://en.wikipedia.org/wiki/List_of...orensics_tools
http://www.howtogeek.com/howto/15761/
maybe but only skimmed: http://ncfs.org/craiger.ifip.05.FINAL.pdf

Overwritten files can not be recovered, even with tools like Recuva or Photorec. If you don't have a backup copy (as jamison20000e points out text editors can be configured to do that automatically) or use a version management tool you are out of luck.

What a compehensive list.
Then why does Recuva have an option to overwrite data 35 times ("Gutmann") instead of just once?

Is there anyone here familiar with a tool allegedly capable of reading the same sector in different ways (slight displacement of head? access analog signals?) to recover previously written data, in order to recover previous versions of a file in modern drives?

Out of band data recovery is not "file recovery" and not something that you do by installing a program.

Recovery of out-of-band data consists of sensing snippets that can be read among an ocean that cannot be read and then assigning meaning to them. You never (maybe rarely) get what was previously a "file", and you certainly do not get a versioned history of the drive.

It is also not done with a drive mounted in your PC, but in general requires a jig and access to the drive electronics.

There are services that you can find online that specialize in that sort of forensics, but there is not a program for it to my knowledge.

Sometimes, when you overwrite a file, it is not overwritten in the hard drive, so the question makes sense. Think of SSDs with wear leveling systems.

The need for multiple overwriting for secure deletion has already been discussed in this forum. 35 overwrites are a damn overkill. For software recovery, with just one overwriting the file is surely out, if the overwriting falls in the place where the file is supposed to be. If that is the case, I'd say only invasive forensics could recover fragments of the file, and I would not bet on that.

Your best bet is to try to find the file in temporary locations where it could have been stored (/tmp, maybe the swap...)

If you have actual overwriting, it is always bad news.

Thanks. Closely related question: would full-disk encryption with truecrypt make it too hard for labs to recover data chunks that have been overwritten, even if the lab knows the key?

I don't really know for sure, but I would think it would at least make things much more difficult if not impossible.

"Having the key" generally also implies having a starting point, and with overwritten data you can only read fragments at best, with no clear relations among them, and having a starting point for decryption would be pretty much impossible I would think, even with a key.

As I noted in my first response, even with unencrypted data you only get fragments of overwritten files out of bound, and you have to assign meaning to them. There is no way to say "this is block 37 of the overwritten file named mysecrets.txt", usually a human must decide what a fragment means. With encrypted data that would likely be impossible - just bits...

Don't take my word, but most likely yes.

In an encrypted chunk of data, a single erroneous bit can ruin the whole block after the corruption. Now take lots of erroneous bits and place them on a sane encrypted file. It makes for a nightmare.

Roughly speaking, that's it.

So the only hope of overwritten data recovery from a fully-encrypted disk is if a chunk has no errors at all? How big is a chunk with AES256?

For AES, the block size is always 128 bits (Wikipedia knows it all).

I think a block that has been corrupted can be read with the key up to the point where corruption happened. So, if the first bit is bad, all the block is bad, but if the 10th is bad, the block is good until the 9th bit. Now imagine a complete block overwrite. Remember, however, the block modes are not equal, and depending on the mode used, the corruption may vary.

The idea with disk encryption is that you don't have to delete something securely inside of it. As long as only you know the keys, you can say it is really hard to access any info inside. For destruction of the information, it is better to overwrite the LUKS/TrueCrypt/wehatever header with a bunch of random data.

Anyway, remember that most times, people is not careful, and portions of the file are stored in temporary folders of the operating system, so ensuring secure deletion in an encrypted filesystem is far from being guaranteed if your operating system is in the clear and storing portions of information to the drive.

Moved: This thread is more suitable elsewhere and has been moved accordingly to help your thread/question get the exposure it deserves.

"Please post your thread, topic or question once and in only one forum. Posting a single thread in the most relevant forum will make it easier for members to help you and will keep the discussion in one place. This thread is being closed because it is a duplicate."