So, I've written a program to prevent data from being recovered once it's deleted, so now I can't help but wonder about it's logical counterpart. How would I go about writing a program to recover data that's been deleted?
If it is on a fat32 storage device you can find it in the FAT. All that is done is the first letter of the entry in the directory table is invalidated so you can search for the filename (minus the first character to find the entry. Once you get it, it will tell you the first location of the first sector in the fat. It then contains the second, etc, etc. you just walk the fat to find all the blocks. when you get a byte that has the most significant bit set (neg.), you have reached the last one.
Paul
So, how do I get direct access to the FAT table? Will I need to write a driver or something? And what if it's NTFS?
NTFS is Not Too F*****g Simple. :green2
Microsoft is still trying to force people to use that junk. just as bad as .NET, IMO. They will try to convince you that XP needs to run on NTFS, well, that just is not true. Partition your drive and make a data drive using fat32, that's all, why make life hard for yourself. Also, do a step-by-step start of XP or watch the console window after selecting 'safe mode' and watch all the fancy stepping necessary to read a NTFS drive, it is like a movie, man.
Paul
Bieb,
BTW: you do not need a driver, just use the same methode used by a hex editor. Ewayne has a very nice hex editor you can download and scope out. He does excellent work. His only looks at files but you can modify it to look at sectors.
Paul
I thought it was supposed to be much more efficient. Or is that just Microsoft propaganda? Anyhow, I'm gonna have to be able to use it if I want a decent recovery program, because I guarantee you 95% of Windows users have just one NTFS partitions. Is there a tutorial on it I can read somewhere?
And doesn't a hex editor just load up a file using WinAPI functions and then display the bytes as hex values?
Yes and yes...