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