The Encase image file format is used by [[EnCase]] used to store various types of digital evidence e.g.

−

[[Internet Explorer]] stores the web browsing history in a file called <tt>index.dat</tt>. The file contains multiple records.

+

* disk image (physical bitstream of an acquired disk)

+

* volume image

+

* memory

+

* logical files

−

== File Locations ==

−

Internet Explorer history files keep a record of URLs that the browser has visited, cookies that were created by these sites, and any temporary internet files that were downloaded by the site visit. As a result, Internet Explorer history files are kept in several locations. Regardless of the information stored in the file, the file is named index.dat.

+

Version 1 of the format is (reportedly) based on [[:File:ASR Data's Expert Witness Compression Format.pdf|ASR Data's Expert Witness Compression Format]].

−

On Windows 95/98 these files were located in the following locations:

+

Version 2 was introduced in EnCase 7, for which a format specification (at least for Ex01) is available, but requires registration.

−

<tt>%systemdir%\Temporary Internet Files\Content.ie5

+

The libewf project indicates that the January 2012 version of this format specification, besides Lx01 not being specified, is sufficient to read the format but not complete.

Internet Explorer also keeps daily, weekly, and monthly history logs that will be located in subfolders of %systemdir%\Documents and Settings\%username%\Local Settings\History\history.ie5. The folders will be named <tt>MSHist<two-digit number><starting four-digit year><starting two-digit month><starting two-digit day><ending four-digit year><ending two-digit month><ending two-digit day></tt>. For example, the folder containing data from March 26, 2008 to March 27, 2008 might be named <tt>MSHist012008032620080327</tt>.

+

The media data can be stored in multiple evidence files, which are called segment files.

+

Each segment file consist of multiple sections, which has a distinct section start definition containing a section type.

+

Up to EnCase 5 the segment file were limited to 2 GiB, due to the internal 31-bit file offset representation. This limitation was lifted by adding a base offset value in EnCase 6.

−

== File Header ==

−

Every version of Internet Explorer since Internet Explorer 5 has used the same structure for the file header and the individual records. Internet Explorer history files begin with:

The next field in the file header starts at byte offset 28 and is a four byte representation of the file size. The number will be stored in [[endianness | little-endian]] format so the numbers must actually be reversed to calculate the value.

+

EnCase allows to store the data compressed either using a fast or best level of the deflate compression method.

+

EnCase 7 no longer distinguishes between fast or best compression and just provides for either uncompressed or compressed.

−

Also of interest in the file header is the location of the cache directories. In the URL records the cache directories are given as a number, with one representing the first cache directory, two representing the second and so on. The names of the cache directories are kept at byte offset 64 in the file. Each directory entry is 12 bytes long of which the first eight bytes contain the directory name.

The case information which entails date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password.

+

* In EnCase 3 the case information header is stored in the "header" section, which is defined twice within the file and contain the same information.

+

* As of EnCase 4 an additional "header2" section was added. The "header" section now appears only once, but the new "header2" section twice.

−

=== URL Records ===

−

These records indicate URIs that were actually requested. They contain the location and additional data like the web server's HTTP response. They begin with the header, in hexadecimal:

+

The format adds error detection by storing the data with checksums (Adler32), for both the metadata as the data blocks, which are by default 64 x 512 byte sectors (32 KiB).

+

As of EnCase 5 the number of sectors per block (chunk) can vary.

+

EnCase 3F introduced an "error2" section 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.

+

As of EnCase 5 the granularity of unreadable chunks can vary.

−

<pre>55 52 4C 20</pre>

−

This corresponds to the string <tt>URL</tt> followed by a space.

−

The definition for the structure in C99 format:

+

EnCase 3 can store a one-way hash of the data. For a bitstream it does so by calculating e.g. a MD5 hash of the original media data and adds a hash section to the last of the segment file.

+

As of EnCase 6 the option to store a SHA1 hash was added.

−

<pre>typedef struct _URL_RECORD_HEADER {

−

/* 000 */ char Signature[4];

−

/* 004 */ uint32_t Length;

−

/* 008 */ FILETIME LastModified;

−

/* 010 */ FILETIME LastAccessed;

−

/* 018 */ FATTIME Expires;

−

/* 01c */

−

// Not finished yet

−

} URL_RECORD_HEADER;</pre>

−

<pre>

+

EnCase 5 and later have the option to store '''single files''' into the EnCase Logical Evidence File (LEF) or EWF-L01.

−

typedef struct _FILETIME {

+

This format changed slightly in EnCase 6 and 7.

−

/* 000 */ uint32_t lower;

+

−

/* 004 */ uint32_t upper;

+

−

} FILETIME;</pre>

+

−

<pre>

−

typedef struct _FATTIME {

−

/* 000 */ uint16_t date;

−

/* 002 */ uint16_t time;

−

} FATTIME;</pre>

−

The Length field is represented by four bytes that give the number of 128 byte blocks that make up the URL record. Therefore, a length of <pre>05 00 00 00</pre> would indicate five blocks (because the number is stored in little-endian format) of 128 bytes for a total record length of 640 bytes.

+

In EnCase 7 the EWF format was succeeded by the EnCase Evidence File Format Version 2 (EWF2-EX01 and EWF2-LX01).

+

EWF2-EX01 is at it's lower levels a different format then EWF-E01 and provides support for:

+

* bzip2 compression

+

* direct encryption (AES-256) of the section data

−

The actual interpretation of the "LastModified" and "LastAccessed" fields depends on the type of history file in which the record is contained. As a matter of fact, Internet Explorer uses three different types of history files, namely Daily History, Weekly History, and Main History. Other "index.dat" files are used to store cached copies of visited pages and cookies.

+

The same features are added to the new logical evidence file format (EWF2-LX01) with the exception of encryption.

−

The information concerning how to intepret the dates of these different files can be found on Capt. Steve Bunting's web page at the University of Delaware Computer Forensics Lab (http://128.175.24.251/forensics/default.htm).

+

EWF2-EX01, EWF2-LX01 are not backwards compatible with previous EnCase products.

−

Please be aware that most free and/or open source index.dat parsing programs, as well as quite a few commercial forensic tools, are not able to correctly interpret the above dates. More specifically, they interpret all the time and dates as if the records were contained into a Daily History file regardless of the actual type of the file they are stored in.

+

−

=== REDR Records ===

+

== See Also ==

−

REDR records are very simple records. They simply indicate that the browser was redirected to another site. REDR records always start with the string REDR (0x52 45 44 52). The next four bytes are the size of the record in little endian format. The size will indicate the number 128 byte blocks.

+

−

At offset 8 from the start of the REDR record is an unknown data field. It has been confirmed that this is not a date field.

Version 2 was introduced in EnCase 7, for which a format specification (at least for Ex01) is available, but requires registration.
The libewf project indicates that the January 2012 version of this format specification, besides Lx01 not being specified, is sufficient to read the format but not complete.

The media data can be stored in multiple evidence files, which are called segment files.
Each segment file consist of multiple sections, which has a distinct section start definition containing a section type.
Up to EnCase 5 the segment file were limited to 2 GiB, due to the internal 31-bit file offset representation. This limitation was lifted by adding a base offset value in EnCase 6.

EnCase allows to store the data compressed either using a fast or best level of the deflate compression method.
EnCase 7 no longer distinguishes between fast or best compression and just provides for either uncompressed or compressed.

Besides digital evidence the evidence files, or segment files, contain a header containing case information.
The case information which entails date and time of acquisition, an examiner's name, notes on the acquisition, and an optional password.

In EnCase 3 the case information header is stored in the "header" section, which is defined twice within the file and contain the same information.

As of EnCase 4 an additional "header2" section was added. The "header" section now appears only once, but the new "header2" section twice.

The format adds error detection by storing the data with checksums (Adler32), for both the metadata as the data blocks, which are by default 64 x 512 byte sectors (32 KiB).
As of EnCase 5 the number of sectors per block (chunk) can vary.
EnCase 3F introduced an "error2" section 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.
As of EnCase 5 the granularity of unreadable chunks can vary.

EnCase 3 can store a one-way hash of the data. For a bitstream it does so by calculating e.g. a MD5 hash of the original media data and adds a hash section to the last of the segment file.
As of EnCase 6 the option to store a SHA1 hash was added.

EnCase 5 and later have the option to store single files into the EnCase Logical Evidence File (LEF) or EWF-L01.
This format changed slightly in EnCase 6 and 7.

In EnCase 7 the EWF format was succeeded by the EnCase Evidence File Format Version 2 (EWF2-EX01 and EWF2-LX01).
EWF2-EX01 is at it's lower levels a different format then EWF-E01 and provides support for:

bzip2 compression

direct encryption (AES-256) of the section data

The same features are added to the new logical evidence file format (EWF2-LX01) with the exception of encryption.
EWF2-EX01, EWF2-LX01 are not backwards compatible with previous EnCase products.