I have created an image using dcfldd and then checked it with fciv and sometimes they match and sometimes they do not.
Any suggestions or help is appricated.
Time to check your RAM.
Greetings,
Context? More details? You created one image and check it multiple times and sometimes the check fails? Or, you're creating multiple images and sometimes the check fails consistently for the same image?
What are you imaging? What operating system? What write blocker?
Etc.
-David
Using helix in linux running dcfldd with ultradoc write blocker after the image is created we reboot into windows and check the image using fciv -md5 compairing the two md5's sometimes I get the same hash sometimes I dont.
Greetings,
Still using the write blocker when you boot into Windows, I presume.
Any chance of an HPA? One of the UltraDock's LEDs flashes if it detects a DCO or HPA.
Any bad sectors reported by dcfldd? If so, how did you handle them? It may be that dcfldd is doing one thing with bad sectors and fciv is doing something else.
-David
Thank you
Using helix in linux running dcfldd with ultradoc write blocker after the image is created we reboot into windows and check the image using fciv -md5 compairing the two md5's sometimes I get the same hash sometimes I dont.
You still are bit vague on details.
0. What are you using for an acquiry platform? Your own true-and-tested lab computer that you know works? If you are using the suspect's system, did you check that that platform actually works for acquiry? You need at the very least do a memcheck, but preferrably also a BIOS diagnostic if that has been disabled. You also need to examine and preferrably save Helix log files to show that Helix did not report any system error from the boot (suggesting lack of drivers or hardware errors), or from the acquiry (suggesting that the acquiry may be suspect).
1. You acquired the source drive to an image file, getting an source md5 in the process. Right?
2. You checked the image file with fciv – didn't get the same md5. Right?
(Don't understand this – why didn't you md5sum the image file in Helix?)
What did you then? As I read you, you kept fciving the source disk and the image file – but you don't say which md5 changes that of the source file or that of the image file?
When you get a hash mismatch, you either figure out why, or collect more information to decide where the failures spots are located, and live with them.
I would suggest that after a failed acquiry step (i.e. hash source, acquire to destination, hash destination, verify hashes match), you
1. repeat the acuiry to a new image file on new destination drive (that has been checked carefully), getting a new md5. Note *all* inconsistencies in against previous acquiry.
2. Do a new acquiry, with another tool this time, to a third image file. Check again. This may identify issues with the first tool.
Now if you have three image files, and inconsistent hash sums, you probably stop. Things won't magically change the fourth time – unless you discover what the proiblem was. (No, you shouldn't stop when you get a consistent run, use that, and just forget about the failures. Unless you know what you are doing.)
Instead, compare the image files block by block, and identify where the changes appear all over the places, that is, they're not consistent from one acquiry to another? Or are they consistent to a set of disk blocks?
In the latter case, you probably have a failing disk – you may want to check SMART attributes and system logs to corroborate that. You then document and treat evidence from the failed sectors with great care.
If there is little or no consistency in what blocks change, you probably have a platform problem – and in this situation you often end up wishing you had run memcheck86 for a few passes before starting, or checked the boot logs from Helix to see if there are any reports of hard drive or perhaps even cleansed and verified the destination drive before you started (it could be the destination drive that fails.)
Or perhaps even checked that the ESD mat was properly connected/grounded. It's far too easy to fry memory if you're in a hurry.
Murphy's laws applies also in computer forensics - anything that can go wrong will go wrong. And it's far to easy to get into a repetitive 'herring sandwich' mode when acquiry fails – it should really start a well-considered routine to locate the error or identify the failure spots as efficiently as possible.
