Deleting files on FAT32 USB changes the first cluster information

Question

i have made a file recovery software, which reads the FAT32 directory entry and identifies the first cluster of the file and attempts to recover the data, it is supposedly to be working fine however when i try on a fat32 usb disk the following happens.

The Cluster number assigned to a file when it is not deleted is different from the cluster number, immediately after it is deleted. I used Disk Investigator and Tune Up Undelete to verify this, none of them w.ere able to recover the file. It was the common problem that, usually upon deleting the file's name first character is changed to 0xE5 and rest remains intact, but this is changing it's cluster information too.

Any help? Can you try with your FAT32 USB and tell me what is happening?

My OS is Windows Vista, Pen Drive is Single Partition FAT32.

Answer 1

To put it shortly: in flash memory, when a block is written to, a cluster of blocks around that block must first be erased, then re-written with the changes to the block taken into account. Therefore, writing to a block whose neighbor is marked as unallocated (though you actually want that data later) might be causing the unallocated block to be written as zeros. Alternatively, the old block might be marked unallocated, and a new block in an already blank cluster could be written to with the changes, and then the block changes would get noted somewhere.

This behavior is not OS specific but actually handled by the USB device itself. We would therefore need to know what kind of device you're using, unless what you are saying is that this happens on all your USB flash devices, which wasn't clear in your question.

The long version is much better explained by Anand Shimpi in his now famous SSD Anthology article (E.G. in the degradation chapter); there's even a detailed follow up if you like that sort of thing.

Answer 2

Perhaps vista really is intentionally changing the first cluster field within the directory entry? What is it actually changing it to? You didn't post any examples with real numbers. If it's overwriting that field with some number like 0 or 0xFFFFFFFF in every case, that's a pretty sure sign Vista is intentionally destroying this information so you can't find the file. If it's changing that field, unnecessarily, to some other valid cluster number, well that's very strange.

Another thing you didn't mention is if the file's data is actually still physically on the disk in the cluster where it was originally located. Seeing actual sector dumps of what is physically stored in the old locations and new location (assuming the new value is a cluster number which really exists) would be interesting. If neither location has the actual file data, you could do a complete capture of all sectors and search. Is the file's original data even still on the drive in any cluster/sector at all?

I know this isn't much of an answer, but with so little information (and not much inclination to actually install Vista and try this stuff), this is about all I can do.

Answer 3

You probably want to compare the code that you have written to the "icat" and "fls" programs that are part of SleuthKit, the open source computer forensics toolkit. Using SleuthKit you can easily find the directory entries for deleted FAT32 files and then icat the inodes. You can find SleuthKit at http://sleuthkit.org/