I would like to find a way (in Helix, ideally) to verify that Encase evidence files (made via LinEn) were (a) accurately reflect the whole hard drive (e.g. /dev/sda), and (b) are viewable in Encase.
I'm assuming that (a) is possibly by some sort of hashing program, and I'm assuming (b) is possibly via some sort of FTK or equiv program?
Help with either method would be greatly appreciated. (I'm not a forensics person, just have to temporarily assist with some forensics projects)
You can use libewf tool
https://
Roger,
You can verify the integrity of the Encase image files in your possesion by verifying them using FTK Imager and comparing the subsequent MD5 hash to that from the EnCase report of your original image. If the hash values dont match then the evidence is corrupt, if they match the image is sound, however this will not tell you if the physical disk was acquired.
I am not sure if the icon associated by EnCase to the image has any bearing on determining the source of the image (physical/volume). Other forum members may shed some light on this one.
Comparing the LBA (sector count) reported by FTK will help in deciding if some part of the physical disk has not been imaged as sector counts tend to be consistent for disks of the same size. For example 40GB disks report 78,140,160 sectors normally. You can verify EnCase images with EnCase without a dongle.
Neddy
One additional check that I believe that you can do is check the md5 checksum against what LinEn computes.
find the /dev devicefdisk -l
and then run an md5 checksum on itmd5sum /dev/sda
Then you can compare that sum on what you get in LinEn.
(Can anyone else confirm this?)
Roger,
As Marat pointed out, libewf tools which can be accessed on Helix in the /usr/local/bin can do what you want.
Just type in ewfverify <Path to EnCase image file>
The only real way of doing this, especially considering the issues surrounding EnCases imaging engine at the moment is to take an EnCase image then take a further image (FTK or DD for example) and then do a bit for bit comparison between the image files.
especially considering the issues surrounding EnCases imaging engine at the moment
Care to enlighten us?
I was reffering to an issue was identified at the end of 2006 where the EnCase imaging engine would duplicate 32k of data in the image overwriting what should have been there. No errors were reported by EnCase and the image verifies correctly. I'm not sure if this has been fixed - perhaps it has.
and when I said "bit to bit comparison" I mean check the MD5s against each other like neddy said.
I was reffering to an issue was identified at the end of 2006 where the EnCase imaging engine would duplicate 32k of data in the image overwriting what should have been there. No errors were reported by EnCase and the image verifies correctly. I'm not sure if this has been fixed - perhaps it has.
The error you described was found in EnCase version 4.19a (and possibly before), and fixed in 4.22 and above. A separate problem arose in later versions of EnCase (now fixed), whereby under certain circumstances EnCase would read the evidence file incorrectly, but the file itself was intact.
I am curious, is there a known issue with EnCases internal HASH verification process? WHen you image a drive with EnCase it creates a HASH of the original drive, in addition to making one of the evidence file. In the EnCase primary report it shows/ compares the HASH sinatures and if they are the same reports no errors, if they are not, it shows the error.
Has a problem with this internal process come to light? Being new to this board, I am not sure if I missed something in the few topics and subjects I have read so far. Or are you looking for a seperate thrid party verification? If so the suggestions so far have been very good and very informative.
I was just wondering about the EnCase programs reliability being an issue. And thank you for putting up with a new person to the forums..
