You may also have specified a range of sectors for your EnCase acquisition that
do not match those that are being read from the linux device /dev/sda.
If you conduct a few tests using dd with a small source drive and examine the
start and end sectors as they were imaged by dd, you should be able to confirm
that EnCase is acquiring/hashing the drive at the same start and end sectors.
Should these tests reveal that all is as it is expected to be, you then have
good cause to suspect that something unexpected is happening when you use
md5sum against the device. I have never used it in such a way, and suspect that
if you were to use dd to first acquire an image from /dev/sda and then md5sum
the image you may get a different hash code. It still may not match the EnCase
hash for the reason cited above.
Try dcfldd which will generate a hash for you in addition to the normal dd
output, saving the md5sum step and giving you another way to verify that your
md5sum is coming out right when used on a device input. The Department of
Defense Computer Forensic Lab (DCFL) created dcfldd.
Whenever hashes are generated, the details of how they were generated must be
logged and these details delivered to anyone else who may attempt in the future
to verify the hash. It is not a bad idea, as well, to hash your version of
md5sum or EnCase and document that the hash of your hashing utility appeared to
be X at the time the utility was used to hash the subject media.
Regards,
Jason Coombs
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com
