What I see is this:
- Windows complains when reading a file because the CRC for it mis-matches its calculated CRC.
- This means NTFS has a CRC for the file.
- I expect the offending block/sector can be known, or at least guessed.
- I also expect that "wrong data" can be read from the disk.
- If the bits of "wrong data" were inverted one by one, by brute force we could find the correct data.
- A file could thus be recovered using statistics and brute-forcing bits to match the CRC.
My question is, does any software do this kind of thing? Any way I could do it (I'd be happy enough to get the CRC, the drive's "wrong" data, know which is the offending block/sector there, and write a script to brute it myself, if relevant directions are given).
By the way, this is a mechanical HDD.
Edit: After taking a look with hex editors and such, I noticed that a bad block appears as garbage, such as filled with zeros or a copy of the last block (this seems to depend on the program), so in order to get the "real data" that is corrupted, we'd have to disable some hardware-correction that refuses to read a block which is bad. I believe this is called ECC. Also, I expect that if just a few bits are marking a block as "bad", then some 32-bit checksum from Windows could be used to brute force a match.
So this question may be answered simply with guidance to do this by myself.