Difference between revisions of "Encase image file format"
(New page: EnCase uses a proprietary format for images which is reportedly based on ASR Data's Expert Witness Compression Format. (Source?) The evidence files, or E01 files, contain a physical bi...)
Revision as of 10:24, 7 April 2007
EnCase uses a proprietary format for images which is reportedly based on ASR Data's Expert Witness Compression Format. (Source?) The evidence files, or E01 files, contain a physical bitstream of an acquired disk, prefixed with a '"Case Info" header, interlaced with CRCs for every block of 64 sectors~(32 KB), and followed by a footer containing an MD5 hash for the entire bitstream. Contained in the header are the date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password; the header concludes with its own CRC.
Encase can store media data into multiple evidence files, which are called segment files. Each segment file consist of multiple sections. Each section consist of a section start definition. This contains a section type.
At least from Encase 3 the case info header is contained in the "header" section, which is defined twice within the file and contain the same information.
With Encase 4 an additional "header2" section was added. The "header" section now appears only once, but the new "header2" section twice.
Version 3 of The Encase F introduced an "error2" sections that it uses to record the location and number of bad sector chunks. The way it handles the sections it can't read is that those areas are filled with zero. Then Encase displays to the user the areas that could not be read when the image was acquired. The granularity of unreadable chunks appears to be 32K.
Within Encase 5 the amount of sectors per block (chunk) can vary.
Encase from at least in version 3, 4 and 5 can hash the data of the media it acquires. It does this by calculating a MD5 hash of the original media data and adds a hash section to the last of the segment files.