Encase verification...
 
Notifications
Clear all

Encase verification errors E01 image, Imaged using Guymager

5 Posts
5 Users
0 Likes
3,191 Views
(@klllmmm)
Posts: 5
Active Member
Topic starter
 

Hi there,

I took a disk image using Guymager 0.8 application via CAINE Linux live distro and the verification was successful.

However, when I verify the image with Encase (v8.09) it results differences in hash values.

Also at the time, I add the evidence I get the following errors

Errors are;
Error in “Header” String cannot be longer than 12 characters
Error in “Header” String cannot be longer than 64 characters
Invalid date Value

Appreciate it if someone can tell why and how to avoid such Encase verification errors, and why such errors occur when adding the evidence into Encase.

Thanks

 
Posted : 15/12/2019 3:07 am
UnallocatedClusters
(@unallocatedclusters)
Posts: 577
Honorable Member
 

1. Verify the image files using Guymager or another tool. It has been my experience that different tools can generate different MD5 hash values for the same exact evidence source; I have no explanation as to why this occurs but it does.

2. Open the image file with FTK Imager (green plus sign), mount the image file with OSForensics, and see if other tools can open, mount and interact with your image file. If no tool at all can open nor mount your original image file, it may have become corrupted.

Our best practice is to create and verify 2nd copies of forensic images to completely separate media in the event one drive holding a copy of the forensic image fails. If you have followed this best practice, try to verify, mount, open your second image copy.

 
Posted : 15/12/2019 8:03 pm
(@rich2005)
Posts: 535
Honorable Member
 

I was going to type that this is simply a difference between the implementations of the EWF/E01/EXX format….and I'm sure I've seen this over the years, without being a problem, as the data still verified, despite the incompatibilities reading the header information in the tools.
What I find strange is the fact you're getting different verification MD5/SHA results. Without referring to manuals I believe the hashes should be of the data rather than the metadata in the E01 and therefore everything should match….assuming your data is intact.
I'd verify it using another tool (like FTK imager or X-Ways if you have that) and see if the MD5/SHA results tally with your original Guymager hashes. If those tools match your original hashes it would seem to indicate that it's a compatibility problem in EnCase.
If you don't get a match with those tools - I'd verify using Guymager (if possible - can't remember if you can instruct it to do that) - just to check there's not been data corruption subsequent to imaging.

 
Posted : 16/12/2019 10:45 am
minime2k9
(@minime2k9)
Posts: 481
Honorable Member
 

We use Guymager for most of our imaging, though we don't use Encase but haven't encountered this problem yet.

Try using EWFverify from the CAINE distribution on the image, Guymager won't let you just verify an image AFAIK, and check the hashes after that.

I take it the image was created on a hard disk and then that hard disk was transferred to a machine for investigation?

 
Posted : 16/12/2019 10:58 am
JimC
 JimC
(@jimc)
Posts: 86
Estimable Member
 

Errors are;
Error in “Header” String cannot be longer than 12 characters
Error in “Header” String cannot be longer than 64 characters
Invalid date Value

The EWF / E01 file format is not very well specified and different products implement it subtly differently. The "header" section of the image file contains case information (case number, examiner name, acquisition dates etc). This information is stored in a relatively loose text format. According to Joachim Metz's work EnCase imposes some limits on how long some of the text fields can be. These limits are not strictly necessary according to the format. I would suspect that Guymager doesn't know this and isn't trying to create an EnCase "compatible" file. You could work around this by setting using shorter text descriptions when creating the image. See

https://github.com/libyal/libewf/blob/master/documentation/Expert%20Witness%20Compression%20Format%20%28EWF%29.asciidoc#header_values

Provided the image worked in every other respect, I wouldn't be too concerned about the EnCase errors. However, the different hash values are a different issue and maybe a sign of a more serious problem acquiring/verifying the image.

Jim

www.binarymarkup.com

 
Posted : 18/12/2019 9:10 am
Share: