Final year of an honours degree in Computer Forensics.
So, more on the "legal" and "Generic computer science" side than actual "engineering/hardware" or "mathematical/pure algorithm", right?
Would I be right in assuming that manufacturers will not allow me to use their low level software to access the ecc data.
Yes and no, meaning that it is possible that some mixed hardware/software tool (like the mentioned PC-3000) may be able to "talk" directly to the controller of the hard disk and get the ECC data, but as said, the target will be pretty much narrow, I mean like (faked) title of the dissertation
"Analysis of the ECC data on Seagate hard disks model 7200.11 series below 1 Tb in size"
or too vast to be actually tackled (as you will need to analyze EACH make and series of hard disks on the market and they will use different ECC settings and algorithms).
Because if I cannot get at then it pretty much makes this project invalid.
But still - independently from the practical difficulties in actually getting the data - it seems to me like you have not a clear idea of WHAT ECC is and HOW it behaves.
Let's build a fake (in the sense of theoretical only) hard disk with "real" sectors sized (say) 520 bytes.
What you see through a disk editor (or anything that is "filtered" by the controller) is always ONLY the first 512 bytes of it.
Imagine that you have an A4 (210 x 297 millimetres, 8.3 × 11.7 in) sized screen to view legal size (215.9 × 355.6 mm,8.5 × 14 in) documents, and no scrolling or zooming abilities, you can only see the top part of the document and you will simply not be able to see last few lines of each page.
But the issue is further than that.
The HD controller writes the ECC data (the faked last 8 bytes) every time it writes the 512 first bytes and reads them every time it reads the first 512 bytes to make sure that these were read correctly.
If the checksum/verification fails, new attempts are made to read the first 512 bytes until it succeeds (usually several times) then it tries to see if from the ECC it can spot an "obvious" error in the 512 bytes and attempts correcting it, if the error is not correctable it "gives up" and throws an error.
What you are seeing on your A4 screen is not a (restricted) view of the "actual" document, but the (partial) contents of the document re-typed on-the-fly.
Everytime you write a sector (the first 512 bytes) the ECC (the last 8 bytes) are changed accordingly, you CANNOT have an "out-of-sync" ECC, if not (maybe) in the rare case that *something* (let's say a power failure) happens EXACTLY RIGHT AFTER the first 512 bytes are written BUT BEFORE the last 8 bytes are.
So, at the most (and only on this theoretical hard disk) you can have at the most one single sector with "new data" in the first 512 bytes and "old ECC" on the last 8.
Even if you assume (wrongly) that the ECC 8 bytes are enough to rebuild the original 512 bytes (you might want to think at it as a compressor like ZIP or RAR or 7-ZIP with a 8/512 compression ratio, i.e. 164 😯 , you would recover 1 sector out of a zillion ones.
No practical purpose that I can see in forensics.
Better start thinking of alternative projects. If you have any ideas I would like to hear them. I have looked at the project idea page on FF before it is linked.
Well still with the need of some university money (or collaboration from some electronics/hardware department), you may want to try direct analysis of memory sticks, something along the lines of
http//
http//
(which while highlighting a number of interesting points, sometimes "goes astray", see the comments in the reboot.pro thread)
and in any case there would the same difficulties about the narrowedness of the research or the wideness of the samples.
Have you checked both?
http//
http//www.forensicfocus.com/project-ideas
jaclaz