Final year of an honours degree in Computer Forensics. Would I be right in assuming that manufacturers will not allow me to use their low level software to access the ecc data. Because if I cannot get at then it pretty much makes this project invalid. 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.  

A hex editor isn't going to show you ECC. You're layers of abstraction away from them.

My recent experience with people who have done CF subjects in college is leading me to believe that these courses have almost zero value because they fail to teach fundamentals before moving students to the find all evidence button.
_________________
Tony Patrick, B. Inf Tech, CFCE
www.patrickcomputerfor...s.com/blog
www.twitter.com/Patrick4n6 

I would suggest you try a new project.

ECC, as I said will correct a few bits only, and routines such as Reed Solomn will indicate that that bit 4 in rown 0x87 is incorrect. It it were possible to reconstruct data from ECC, then disks would in effect be twice the capacity.

Another point is that modern drives are not like floppy disks. Floppy disks have nice neat sectors, followed by a simple CRC to validate the data. Physically, HDDs will work on much larger sectors, even though most will show a logical sector of 0x200 bytes. Some new drives have 4K sectors.

I don't think one can see ECC data with PC-3000 which is a tool your college might have. I am currently out of my office so I cannot check.
_________________
Michael Cotgrove
www.cnwrecovery.com
cnwrecovery.blogspot.com/ 

- bigl

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?

- bigl

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).

- bigl

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. 1:64 , you would recover 1 sector out of a zillion ones.
No practical purpose that I can see in forensics.

- bigl

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:
www.usenix.org/events/...rs/Wei.pdf
reboot.pro/13601/page_...ntry123075
(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?:
www.forensicswiki.org/...rch_Topics
www.forensicfocus.com/project-ideas


jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. -