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

+

[[Microsoft]] [[Internet Explorer]] (or MSIE) stores its web browsing history in files named <b>index.dat</b> as of version 4 up to version 9.

+

+

== Overview ==

+

By design these index.dat files are cache files but are used to:

+

* keep a record of URLs that the browser has visited

+

* cookies that were created by a site

+

* temporary internet files that were downloaded in the cache during a visit to a size

+

+

Regardless of the information stored in the file, the file is named index.dat.

+

+

<b>Note that not every file named index.dat is a MSIE History (Cache) file.</b>

+

+

The file format of MSIE 4 is slightly different then that of MSIE 5 up to 9. Most of the information on this page applies to the format used by MSIE 5 - 9.

+

+

MSIE 3 probably uses similar records in its History (Cache) files.

== File Locations ==

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

+

The index.dat files are stored in multiple locations.

+

+

=== MSIE 5 - 9 ===

+

+

The actual location can vary per version of MSIE and version of [[Windows]].

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

== File Header ==

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

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.

This string (or signature) is followed (at byte offset 28) by a four byte value containing the file size. The value is stored in [[endianness | little-endian]] so the individual bytes must read in reverse.

+

+

The file header also can contain the name 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.

+

+

== Allocation bitmap ==

+

The IE History File contains an allocation bitmap starting from offset 0x250 to 0x4000.

== Record Formats ==

== Record Formats ==

Line 31:

Line 68:

Every record has a similar header that consists of 8 bytes.

Every record has a similar header that consists of 8 bytes.

−

</pre>typedef struct _RECORD_HEADER {

+

<pre>typedef struct _RECORD_HEADER {

/* 000 */ char Signature[4];

/* 000 */ char Signature[4];

−

/* 004 */ uint32_t AmountOfBlocksInRecord;

+

/* 004 */ uint32_t NumberOfBlocksInRecord;

} RECORD_HEADER;</pre>

} RECORD_HEADER;</pre>

−

The size of the record can be determined from the amount of blocks in the record; per default the block size is 128 bytes.

+

The size of the record can be determined from the number of blocks in the record; per default the block size is 128 bytes. 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. Note that even for allocated records the number of blocks value cannot be fully relied upon.

−

The record can contain slack data.

+

+

The blocks that make up a record can have slack space.

Currently 4 types of records are known:

Currently 4 types of records are known:

Line 44:

Line 82:

* HASH

* HASH

* LEAK

* LEAK

+

+

Note that the location and filename strings are stored in the local codepage, normally these strings will only use the ASCII character set. Chinese versions of Windows are known to also use extended characters as well.

=== URL Records ===

=== URL Records ===

Line 56:

Line 96:

<pre>typedef struct _URL_RECORD_HEADER {

<pre>typedef struct _URL_RECORD_HEADER {

/* 000 */ char Signature[4];

/* 000 */ char Signature[4];

−

/* 004 */ uint32_t Length;

+

/* 004 */ uint32_t AmountOfBlocksInRecord;

/* 008 */ FILETIME LastModified;

/* 008 */ FILETIME LastModified;

/* 010 */ FILETIME LastAccessed;

/* 010 */ FILETIME LastAccessed;

Line 75:

Line 115:

/* 002 */ uint16_t time;

/* 002 */ uint16_t time;

} FATTIME;</pre>

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

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

+

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://www.stevebunting.org/udpd4n6/forensics/index_dat2.htm).

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.

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.

Line 92:

Line 130:

=== LEAK Records ===

=== LEAK Records ===

+

The exact purpose of LEAK records remains unknown, however research performed by Mike Murr suggests that LEAK records are created when the machine attempts to delete records from the history file while a corresponding Temporary Internet File (TIF) is held open and cannot be deleted.

The folders will be named 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>. For example, the folder containing data from March 26, 2008 to March 27, 2008 might be named MSHist012008032620080327.

This string (or signature) is followed (at byte offset 28) by a four byte value containing the file size. The value is stored in little-endian so the individual bytes must read in reverse.

The file header also can contain the name 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.

Allocation bitmap

The IE History File contains an allocation bitmap starting from offset 0x250 to 0x4000.

Record Formats

The size of the record can be determined from the number of blocks in the record; per default the block size is 128 bytes. Therefore, a length of

05 00 00 00

would indicate five blocks (because the number is stored in little-endian format) of 128 bytes for a total record length of 640 bytes. Note that even for allocated records the number of blocks value cannot be fully relied upon.

The blocks that make up a record can have slack space.

Currently 4 types of records are known:

URL

REDR

HASH

LEAK

Note that the location and filename strings are stored in the local codepage, normally these strings will only use the ASCII character set. Chinese versions of Windows are known to also use extended characters as well.

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 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 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://www.stevebunting.org/udpd4n6/forensics/index_dat2.htm).
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

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.

16 bytes into the REDR record is the URL that was visited in a null-terminated string. After the URL, the REDR record appears to be padded with zeros until the end of the 128 byte block.

HASH Records

LEAK Records

The exact purpose of LEAK records remains unknown, however research performed by Mike Murr suggests that LEAK records are created when the machine attempts to delete records from the history file while a corresponding Temporary Internet File (TIF) is held open and cannot be deleted.