Join Us!

How to best double ...
 
Notifications
Clear all

How to best double check Encase evidense files?  

  RSS
RogerRustad
(@rogerrustad)
New Member

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)

Quote
Posted : 10/01/2008 6:26 am
Marat
(@marat)
Junior Member

You can use libewf tool

https://www.uitwisselplatform.nl/projects/libewf

ReplyQuote
Posted : 10/01/2008 4:34 pm
neddy
(@neddy)
Active Member

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

ReplyQuote
Posted : 12/01/2008 4:47 am
 Anonymous

One additional check that I believe that you can do is check the md5 checksum against what LinEn computes.

find the /dev device
fdisk -l
and then run an md5 checksum on it
md5sum /dev/sda
Then you can compare that sum on what you get in LinEn.

(Can anyone else confirm this?)

ReplyQuote
Posted : 12/01/2008 7:52 am
Worcesterdee
(@worcesterdee)
New Member

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

ReplyQuote
Posted : 26/05/2008 2:35 am
honeyjew
(@honeyjew)
New Member

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.

ReplyQuote
Posted : 29/05/2008 3:11 pm
JonN
 JonN
(@jonn)
Member

especially considering the issues surrounding EnCases imaging engine at the moment

Care to enlighten us?

ReplyQuote
Posted : 29/05/2008 5:18 pm
honeyjew
(@honeyjew)
New Member

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.

ReplyQuote
Posted : 29/05/2008 5:46 pm
seanmcl
(@seanmcl)
Senior Member

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.

ReplyQuote
Posted : 29/05/2008 6:24 pm
CWagoner
(@cwagoner)
New Member

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

ReplyQuote
Posted : 29/05/2008 7:27 pm
seanmcl
(@seanmcl)
Senior Member

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.

The hash created by EnCase is a hash of the physical (or logical), drive contents, not the evidence file. The integrity of the evidence file is determined by CRCs done on the chunks of data by which the evidence is collected and appears in the file after each chunk.

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?

Not that I am aware, other than the issue noted for the earlier versions of EnCase. The purpose of hash verification is to verify that what was acquired by EnCase is forensically identical to the physical (or logical) media.

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

From time to time problems are found with various versions of EnCase (and FTK and other software). Most of these problems relate to the analysis of the data rather than the reliability of the acquisition and, with time, all seem to be corrected. The safest strategy is to not rely on a single tool, especially if the reliability or admissibility of the evidence is likely to be an issue.

ReplyQuote
Posted : 30/05/2008 3:11 am
bkberghuis
(@bkberghuis)
New Member

I hope I understand the questions about the integrity and verification process.

When using the EnCase to create a bit for bit image of the orginal data there are three componets to the image file being created. They are the HEADER, the FILE INTEGRITY check (CRC & MD5), and the DATA BLOCKS. This provides a redundant verification of the data during imaging. The FILE INTEGRITY check componet consists of the CRC values and MD5 value. The CRC values are a 32bit checksum calculated from the header and block of data being streamed from the evidence drive. This block of data being streamed is typically 64 sectors of data (32 kb) by default unless manually changed which is not recommend by Guidance. However, this feature is available for versions 5 & 6. These blocks are basically encapsulated with a header which contains the CRC calculated on the header and the block of data. Furthermore, the MD5 (128bit) hash value is calculated from only the data blocks. When Encase reaches the last block of data of the original data being imaged, it will calculate the last CRC for that block of data and the acquisition hash (MD5 value) is then written in the section which is appended to the end of the image file.

When the image file is added a file verification process automatically occurs. During the process it recalculates the CRC values for each header and block of data and the MD5 Hash value on the data blocks only. EnCase compares the CRCs values and MD5 value with acquisition values and reports the results.

If all the CRCs don't match a Checksum Error will be reported. It will report the how many errors occured indicating how many blocks of data failed verification. Additionally, the MD5 hash value will not match either. This may occur for a number of reasons. However, the blocks of data that failed to verify the CRC values will be locked out or excluded from examination by EnCase. This is where the Block Size can be a a big issue. If you leave the block size during acquisition to the default size of 64 sectors or 32 kb of data, this will be the amount of data excluded multiplied by the number of errors. Therefore, one error will mean that just 32 kb of data will be excluded from examination. However, if you manually change this value to a larger value to increase the speed of the acquisition then you will exclude more data. Now you can reacquire your image changing the granularity or block size to a smaller size if needed to reduce the amount of data excluded. Which is why it is better to leave it at the default size 64 sectors. However, when doing a black bag job in an effort to speed up the acquistion one may want to increase the block size.

Additionally, one can reverify the image files in a case by simply selecting the root drive in the left pane and right clicking on it and from the menu options select "reverify". You might want to do this if you had a hardware failure of your RAID and have rebuilt the RAID or moved the case and image files. I would then recommend reverifying the (E01)/image files.

As for using FTK to reverify, certainly you could do this. However, if in EnCase why not use EnCase to reverify?

As for imaging I prefer using FTK imager which allows you to image in multiple formats such as RAW (dd), E01 (EnCase), and AD (AccessData) forensic formats. It is also a great tool for converting image formats from one to another.

ReplyQuote
Posted : 30/05/2008 11:52 am
verdad
(@verdad)
New Member

The safest strategy is to not rely on a single tool, especially if the reliability or admissibility of the evidence is likely to be an issue.

You got that right. I just had the pleasure of ripping apart a so called expert on this issue. (The data was clearly corrupt and improperly handled). Needless to say when it got right down to it, it wasn't pretty for the other side, and there was nothing they could do to salvage it.

ReplyQuote
Posted : 10/06/2008 10:32 pm
Crutey
(@crutey)
Junior Member

(a) accurately reflect the whole hard drive (e.g. /dev/sda)

Any problems with not imaging the whole hard disk drive are likely to be related to hardware, not the chosen OS. Fore example, if you have an HPA set, or the BIOS hasn't detected the full disk, Encase/FTK/Linux are likely to all produce the same result on the same hardware.

The best way to ensure the whole disk is imaged is to compare the number of sectors imaged (whether it's Encase, FTK, or DD and it's derivatives) against the manufacturers specification - obtained from the sticker on the drive or from their website.

identified in 2006

Not exactly an issue 'at the moment' (as per your earlier post) is it?

ReplyQuote
Posted : 11/06/2008 3:23 am
Share: