A frequent question when dealing with browser forensics is ‘Does the Hit Count value mean that the user visited site ‘x’, on ‘y’ occasions?’ Most browsers record a ‘Hit Count’ value in one or more of the files they use to track browser activity, and it is important that an analyst understands any potential pitfalls associated with the accuracy, or otherwise, of this value.

We recently received a support request from an analyst who was analysing Internet Explorer data. They had found a record relating to a Bing Images search, which showed a hit count of 911. The particular search string was significant, and very damning had it actually been used 911 times. The analyst wanted to know if the hit count value could be relied upon.

The following experiment was carried out in order to establish how this surprisingly high hit count value could have been generated. In order to obtain a data set which contained as little extraneous data as possible, a brand new VMWare virtual machine was created. The machine was setup from the Microsoft Windows XP SP3 installation disc, which installed Internet Explorer v 6.0.2900.5512.xpsp.080413-2111 by default. Two user accounts were created on the machine – one to be used as an Admin account, for installing software etc; and the other to be used as the ‘browsing’ account. This separation of the accounts further assisted with minimising the possibility of any unwanted data being present within the ‘browsing’ account. Using the Admin account, the version of Internet Explorer in use on the virtual machine was upgraded to IE v 8.0.6001.18702. The ‘browsing’ account was then used for the first time. Starting Internet Explorer immediately directed the user to the MSN homepage. The address ‘’ was typed into the address bar, which led to the Bing search engine homepage. The ‘Images’ tab was clicked. This Auto Suggested a search criterion of ‘Beautiful Britain’, as can be seen in the figure below:



Figure 1

The term ‘aston martin’ was then typed into the search box, as shown below:


Figure 2

None of the images were clicked or zoomed, nor was the result screen scrolled. Internet Explorer was closed, and the browsing account logged off. The Admin account was used to extract the browser data for processing in NetAnalysis. The below image shows some of the results. Both of these entries are from Master History INDEX.DAT files:


Figure 3


As can be seen, both entries show a hit count of 5. Both of these pages were visited only once, so it is immediately apparent that the hit count value maintained by Internet Explorer may not be an accurate count of how many times a particular page has been visited. However, this still did not explain how Internet Explorer had produced a hit count of 911.

The virtual machine was started again, and the browsing account logged on. The previous steps were repeated; typing ‘’ into the URL bar; visiting the Bing homepage; and clicking on the ‘Images’ tab. Once again, Bing Auto Suggested the search criterion of ‘Beautiful Britain’, and displayed the same thumbnail results page. The search criterion ‘aston martin’ was again typed into the search box and the same thumbnail results page was produced. None of the images were clicked or zoomed. The results page was scrolled using the side scroll bar, which generated more thumbnails as it went. Internet Explorer was closed, and the browsing account logged off. The Admin account was used to extract the browser data for processing in NetAnalysis. The below image shows some of the results. Both of these entries are again from Master History INDEX.DAT files:



Figure 4

As can be seen, the ‘Beautiful Britain’ search now has a hit count of 13 – it is not at all clear how Internet Explorer determined this figure. Moreover, the ‘aston martin’ search now shows a hit count of 511. This page was not visited 511 times, nor were 511 of the thumbnail images clicked. The contents of the INDEX.DAT for the local cache folders (Content.IE5) were checked to see how many records were held relating to thumbnails that had been cached. The results were as follows:


Figure 5

So it does not even appear that there are 511 thumbnails held in the local cache. The result page was scrolled quickly, so the user did not see a large proportion of the thumbnail images.

In conclusion, it is apparent that the ‘Hit Count’ maintained by Internet Explorer cannot be relied upon. Although this experiment involved a quite specific process relating solely to image searches carried out on one particular search engine, the disparity between results and reality makes it clear that unquestioning acceptance of what Internet Explorer is recording as a ‘Hit Count’ could lead to significant errors if presented in evidence.

To complete the experiment, two further identical Virtual Machines were created. On one, the Google Chrome browser (v 15.0.874.106 m) was installed and used. On the other, the Mozilla Firefox browser (v 8.0) was installed and used. The same steps were repeated: typing ‘’ into the URL bar; visiting the Bing homepage; and clicking on the ‘Images’ tab. The results from these processes are shown below:



Figure 6




Figure 7

It is apparent that both of these browsers seem to maintain a more accurate ‘Hit Count’.

We are pleased to announce the release of the updated user manual for NetAnalysis v1.53.  It can be downloaded from here:

Internet Explorer Data

As forensic examiners will be aware, Microsoft Internet Explorer stores cached data within randomly assigned folders. This behaviour was designed to prevent Internet data being stored in predictable locations on the local system in order to foil a number of attack types. Prior to the release of Internet Explorer v9.0.2, cookies were an exception to this behaviour and their location was insufficiently random in many cases.

Cookie Files

Generally, for Vista and Windows 7, cookie files are stored in the location shown below:


The cookie filename format was the user’s login name, the @ symbol and then a partial hostname for the domain of the cookie.

Cookie Files with Standard Name

With sufficient information about a user’s environment, an attacker might have been able to establish the location of any given cookie and use this information in an attack.

Random Cookie Filenames

To mitigate the threat, Internet Explorer 9.0.2 now names the cookie files using a randomly-generated alphanumeric string. Older cookies are not renamed during the upgrade, but are instead renamed as soon as any update to the cookie data occurs. The image below shows an updated cookie folder containing the new files.

Random Cookie Names

This change will have no impact on dealing with the examination of cookie data; however. it will no longer be possible to identify which domain a cookie belongs to from just the file name.

NetAnalysis showing Random Cookie Names

NetAnalysis showing Random Cookie Names


Over the past few weeks, there has been worldwide interest in the trial of Casey Anthony which was held in Orlando, Florida.  Anthony was indicted on charges of murder following the discovery of the body of her daughter Caylee Marie Anthony in 2008.  On Tuesday 5th July 2011, the jury returned a not guilty verdict and she was cleared of murdering her child.

Those of you who have followed this case and listened to the expert testimony may have been intrigued and possibly confused as to some of the alleged facts as the case unfolded.

Casey Anthony Digital Evidence

The digital forensic evidence in this case is of particular interest to me as it involved the recovery and analysis of a Mozilla Firefox history database.  The Internet history records within this database turned out to be extremely important to the prosecution case as the existence of Google searches relating to “chloroform” and other possibly relevant records prior to the child’s disappearance could have indicated premeditation.  This, of course, could have meant the difference between a conviction for murder in the first degree and manslaughter if found guilty.  The State of Florida also has the death penalty as a punishment option for capital crimes.

During a keyword search of Anthony’s computer, a hit was found for the word “chloroform”.  The hit was identified in what appeared to be a Mork database belonging to Mozilla Firefox.  The file was identified as residing in unallocated clusters, and rather surprisingly, is reported to have been intact.  Furthermore, all of the blocks belonging to the file were said to be contiguous.

Mork Database

The Mork database structure used by Mozilla Firefox v1-2 is unusual to say the least.  It was originally developed by Netscape for their browser (Netscape v6) and the format was later adopted by Mozilla to be used in Firefox.  It is a plain text format which is not easily human readable and is not efficient in its storage structures.  For example, a single Unicode character can take many bytes to store.  The developers themselves complained it was extremely difficult to parse correctly and from Firefox v3, it was replaced by MozStorage which is based on an SQLite database.

Forensic Analysis of the Digital Evidence

It is a matter of record that our software NetAnalysis® (v1.37) was used during the initial examination of this data, and then at a later stage another tool was used.  This is, of course, good forensic practice and is often referred to as “dual tool verification”.

Within a Mork database, the timestamp information relating to visits are stored as a micro-second count from an epoch of 1st January 1970 at 00:00:00 hours UTC (Universal Coordinated Time).  In NetAnalysis® v1.37, the forensic examiner had an option to leave the timestamps as they were recorded in the original evidence or to apply a bias to the UTC value to translate it to a local “Standard Time”.  In this older version, there was no option to present the timestamp as a local value adjusted for DST (Daylight Saving Time).  This changed in NetAnalysis® v1.50 when a further date column was introduced which presented the examiner with UTC and local times adjusted for DST.

According to video footage of the trial testimony, the forensic examiner wanted the output to reflect local time and not standard time and tried another tool.  This second tool was unable to recover any records from the Mork file.  The forensic examiner then approached the developer during a training course and discussed the issues he was having with the software.  The developer of the second tool then reviewed the Mork database over a period of a few nights and corrected the problem.  That software then managed to recover 8,557 records (320 less than NetAnalysis® was able to recover at the time).

Discrepancies between Forensic Tools

During testimony, the defence picked up on the fact that there were some major differences in the results produced by both tools.  The defence assertion was that the initial results produced by NetAnalysis® were in fact correct, and that the results from the second tool were flawed.  This was discussed at some lengths in the video testimony on 1st July 2011 when the forensic examiner was questioned regarding the differences.

According to CNN, Jose Baez, the lead counsel for the defence said:

“the state’s computer forensic evidence involving chloroform research, a central element of their premeditation argument, was used to mislead the jury and that the flaws in that evidence infected their entire case like a cancer.”

He pointed out the discrepancy between the first analysis the sheriff’s office did that showed one visit to a website about chloroform and an analysis done later with a second program that appeared to show 84 visits.  However, according to Baez, the first report showed a progression that made it clear that the 84 visits were actually to MySpace.

This was a major discrepancy with critical digital evidence presented in an extremely serious trial.  As the software developer of NetAnalysis®, I was extremely anxious to review the raw data and confirm the facts.

The first time I was made aware of this case (and the discrepancy between both tools) was around 9th June 2011.  To date, I have not been asked by any party representing the prosecution (or defence) to comment on the discrepancies between both tools.   I have however, since the conclusion of the trial, obtained a copy of the recovered “History.dat” Mork database file.

Mork Database File

Using this data, I will walk through the deconstruction of the critical elements of the file and verify the evidence presented during the trial.  The file is 3,338,603 bytes in length and contains data from a Mork database.

Mork Database Header

Figure 1

The block in Figure 1 shows the definition of the database table holding the history data.  The definition identifies the fields in each row as: “URL”, “Referrer”, “LastVisitDate”, “FirstVisitDate”, “VisitCount”, “Name”, “Hostname”, “Hidden”, “Typed”, “LastPageVisited”, and “ByteOrder”.  Not all of these fields will be present in every history record.  Each field is allocated an integer value for identification purposes.  For example, the “URL” field has been allocated the value 82.

According to the Mozilla Developers Network, the model is described as:

“The basic Mork content model is a table (or synonymously, a sparse matrix) composed of rows containing cells, where each cell is a member of exactly one column (col). Each cell is one attribute in a row. The name of the attribute is a literal designating the column, and the content of the attribute is the value. The content value of a cell is either a literal (lit) or a reference (ref). Each ref points to a lit or row or table, so a cell can “contain” another shared object by reference.”

Deconstructing the Mork Database

To demonstrate how this works, and to verify the data, we will walk through a couple of examples.  As we have no access to the SYSTEM registry hive from the suspect system, we must assume the computer was correctly set to Eastern Time in 2008 during these visits (time zone verification is always one of the first tasks for the forensic examiner prior to examining any time related evidence).

Figure 2 shows a screen shot of NetAnalysis® with the data loaded and filtered showing some of the records identified in the testimony from the trial.

NetAnalysis Screen with Mork Database Loaded

Figure 2

The first record (at the bottom of the screen) shows a visit to MySpace on 2008-03-21 15:16:13 (local time).  The visit count shows the value as 84.  The Mork record for this entry is shown in Figure 3.

Mork record 6E2F

Figure 3

The record is enclosed within square brackets and the individual fields for the record are enclosed within round brackets.  The data stored within the brackets contain name/value pairs.  Moving from left to right, the first block of data “-6E2F” identifies the Mork record ID (record ID values are not unique).  The first name/value pair shows (^82^B1).  If you refer back to the Mork header in Figure 1, we can see that field 82 refers to the “URL” (Uniform Resource Locator).   The data for this field is stored in cell B1.  The data cell is enclosed in brackets as shown in Figure 4 (line 47).  The cell data shows (B1=

Mork Field B1

Figure 4

Using the same methodology, we can see that field 84 refers to “LastVisitDate” and is stored in cell 27F42 as shown in Figure 5 (2008-03-21 19:16:13 UTC / 2008-03-21 15:16:13 Local Time).  This integer represents the number of micro-seconds from the 1st  January 1970, 00:00:00 UTC.

Mork Field 27F42

Figure 5

Field 85 refers to “FirstVisitDate” and is stored in cell BAF8 as shown in Figure 6 (2007-12-26 20:25:56 UTC / 2007-12-26 20:25:56 15:25:56 Local Time).

Mork Field BAF8

Figure 6

Field 88 refers to “Hostname” and is stored in cell 16F as shown in Figure 7.

Mork Field 16F

Figure 7

Field 87 refers to “Name” and is stored in cell DA as shown in Figure 8.

Mork Field DA

Figure 8

Further examination of the Index in Figure 3 shows field 86.  This refers to the “VisitCount” and has been assigned the value 84.  This data is actually stored in the Index record and not a separate cell.  If an Index record does not have a field 86, then the “VisitCount” is 1.  Once the visit count is 2 or above, field 86 is assigned a value.  The last field 8A refers to the “Typed” flag and has been assigned the value 1.  This is a Boolean field 0 = False and 1 = True.

Decoded Record 6E2F

Figure 9

The data from this record has been gathered together in Figure 9.  The Name field relates to the Page Title and is stored in pseudo Unicode format with $00 representing 0x00 values.

According to the testimony during the trial, this record was not recovered by the second tool.

Visit Count Discrepancy

At various times during the trial, the prosecution referred to a visit to a page (“”) which allegedly took place at 15:16:13 hours (local time) on 21st March 2008.  This record was recovered by the second forensic tool and indicated a visit count of 84.  This visit was as a result of a Google search for “how to make chloroform”.

This evidence contradicts the data recovered by NetAnalysis® which showed a single visit at 19:16:34 hours UTC (15:16:34 hours local time).  Figure 9 shows a visit to MySpace, which has been verified manually above, and shows 84 visits as of 21st March 2008 at 15:16:13 hours (local time).  This is the record highlighted in NetAnalysis® in Figure 2.

The Mork record containing “” is identified as record 174EF.  The Index record from the original file is highlighted and shown in Figure 10 below.

Mork Record 174EF

Figure 10

The entire record is contained within square brackets.  The highlighted line above shows the full record.  The first field 82 (“URL”) is stored in cell 27F4B, as shown in Figure 11.

Mork Field 27F4B

Figure 11

The second field 84 (“LastVisitDate”) is stored in cell 27F4C, as shown in Figure 12 (2008-03-21 19:16:34 UTC / 2008-03-21 15:16:34 Local Time).  Once again, this integer represents the number of micro-seconds from the 1st  January 1970, 00:00:00 UTC.

Mork Field 27F4C

Figure 12

The third field 85 (“FirstVisitDate”) is stored in cell 27F4C.  This is the same cell value as for (“LastVisitDate”) and indicates this is the first visit to this web site during the scope of the current recorded history.  The First and Last visit times are the same.

The fourth field 83 (“Referrer”) is stored in cell 27F49, as shown in Figure 13.

Mork Field 27F49

Figure 13

The referrer field is very interesting from a forensic point of view as it shows the referring page.  As the HTTP GET is sent to the web server for a page, the browser also sends the referring page as part of the request.  This allows web masters to log the route by which visitors land on their pages.  Mozilla Firefox records this information for each record.  It is therefore relatively easy to track the actions of a user from page to page.  In this case, the referring site was a Google search for “how to make chloroform”.  With this information (which NetAnalysis® shows in the “Referral URL” Column) there really is no need to “guess” how a user arrived at a specific page.

The fifth field 88 (“Hostname”) is stored in cell 27F4D, as shown in Figure 14.

Mork Field 27F4D

Figure 14

The last field 87 (“Name”) is stored in cell 27F4E, as shown in Figure 15.  The decoded value for this string is “New Page 1”.

Mork Field 27F4E

Figure 15

Once again, I have gathered together the data for this record and presented it in a table format for easy review.  This can be seen in Figure 16.

Decoded Record 174EF

Figure 16

There are two critical points to make with this record.  Firstly, there is no field 86 (“VisitCount”) therefore this URL has only been visited once (not 84 times).  This is further corroborated by the fact that field 85 (“FirstVisitDate”) shows the exact same date/time as the “LastVisitDate”.  The second point is that the visit was recorded at 15:16:34 hours (local time) and NOT at 15:16:13 hours as was stated during the trial (from the report produced by the second forensic tool).

Validity of the Recovered File

With the release of NetAnalysis® v1.50, the Mork database parser was completely re-written from the ground up (as were the other parsing modules).  This was primarily to make the code easier to migrate and maintain and to ensure we were recovering as much data as possible.  I tested the current release of NetAnalysis® v1.52 against the Casey Anthony data.  I know from manually examining the data, there are 9,075 individual Index records.  Loading the data into NetAnalysis® resulted in 9,060 records being recovered.  This initially caused me some concern.  However, further examination of the data revealed that there was nothing to be concerned about.  There were 15 records which had missing “URL” cells; 14 of these records also had missing “LastVisitDate” cells.

If there are missing data cells within the file, this is a strong indicator that the file is not intact.


There are a number of conclusions to be drawn from the digital evidence presented in this trial; however, I will leave this to the members of the digital forensic community.  Forensic tool validation is certainly at the forefront of our thoughts.  Whilst it may not be possible to verify a tool, it is possible to verify the results against known data sets.  If two forensic tools produce completely different results, this should at least warrant further investigation.



Safari is a web browser developed by Apple and is included as part of the Apple Macintosh OS X operating system.  It has been the default browser on all Apple computers since Mac OS X version 10.3 Panther and its first public release was in 2003.  Safari is currently at major version 5 released in June 2010.

In June 2007 Apple released a version of Safari for Microsoft Windows operating systems.  The version of Safari at this time was version 3.  Windows versions have been updated in parallel with Mac OS X versions ever since and are also at the time of writing at version 5.

Forensic Analysis of Safari

NetAnalysis® v1 currently supports the analysis of all versions of Safari.  Safari runs on Microsoft Windows and Apple Macintosh OS X operating systems.  The data created by Safari is file based and the structure of the data it creates is similar between operating systems.

Safari Browser v3 – 5

Safari, like all web browsers, aggressively prompts the user to update to the latest version to incorporate new security patches.  This means that you are likely to find the most recent version on computers currently in use, which at the time of writing is Version 5.

Internet History and Cache data is stored within each users profile, the exact location will vary depending on the operating system in use.

Safari stores Internet history records within an Apple property list file entitled history.plist (as shown in Figure 1).  Property list files have the file extension .plist and therefore are often referred to as plist files.  Plist files may be in either an XML format or a binary format.  For earlier versions of Safari (both Windows and Macintosh variants) the history.plist file was in the XML format.  Later and current versions utilise the binary plist format.  NetAnalysis parses both the XML and binary formatted history plist files.

Apple History Folder

Figure 1

Safari versions 3 to 5 store the cache in SQLite 3 database files entitled cache.db (as shown in Figure 2).  Earlier versions of Safari stored cache in files that had the file extension .cache.  These files are not currently supported.

Apple Cache Folder

Figure 2

Stage 1 – Recovery of Live Safari Data

To process and examine Safari live Internet history and cache with NetAnalysis, the following methodology should be used.  In the first instance, it is important to obtain the live data still resident within the file system (web pages can only be rebuilt from live cache data).

This can be done in either of the following three ways:

  • Export all of the data (preferably in the original folder structure) utilising a mainstream forensic tool
  • Mount the image using a forensic image tool
  • Access the original disk via a write protection device

Once the data has been extracted to an export folder, open NetAnalysis® and select File » Open All History From Folder.  Select the folder containing your exported Safari data.


Figure 3


Stage 2 – Recovery of Deleted Safari Data

HstEx® is a Windows-based, advanced professional forensic data recovery solution designed to recover deleted browser artefacts and Internet history from a number of different source evidence types.  HstEx® supports all of the major forensic image formats.

HstEx® currently supports the recovery of Safari XML and Binary plist data.  It cannot at the moment recover cache records (research and development is currently being conducted).  Figure 4 shows HstEx® processing

HstEx Processing Apple

Figure 4

Please see the following link for information on using HstEx® to recover browser data:

Please ensure you select the correct Data Type prior to processing.  Safari v5 stores history data in binary plist files.  When HstEx has finished processing, it will open a window similar to the one shown in Figure 5.  These files can now be imported into NetAnalysis® v1 by either selecting File» Open History and selecting all of the files, or select File » Open All History From Folder and selecting the root recovery folder.


HstEx Output Folder for Apple Safari Extraction

Figure 5

Default Folder Locations

Apple Safari data can be found in the following default folder locations (Figure 6):


Figure 6

Further Reading

Introduction to Userdata

Internet Explorer 8+ user data persistence is a function which allows online forms to save a small file to the system with information about values entered in a particular form.  This allows the user to retrieve a half filled web based form when they revisit.

Persistence creates new opportunities for website authors.  Information that persists beyond a single page without support from the server, or within the finite scope of cookies, can increase the speed of navigation and content authoring.

The folder structure where the data is actually stored is very much like the standard Internet Explorer cache folder structure. Inside the cache folder you will find the files containing data attributed to the associated website.

{user}\AppData\Roaming\Microsoft\Internet Explorer\UserData\

To demonstrate how this works, we have created a page which allows you to save a string to the local drive.

Once you have saved some string data using the above page, open the UserData INDEX.DAT file in NetAnalysis and review the entries.  Selecting F8 will bring up the search/filter dialogue.  Change the field name to ‘Type’ and enter ‘userdata’ in the filter text box.  When this is executed, you should find an entry as shown below:

If you navigate to the corresponding folder, you will find an XML file which contains the string you entered into the website.  This is shown below.

Introduction to NetAnalysis® v1.52

Digital Detective is pleased to announce the release of NetAnalysis® v1.52 (and HstEx v3.6).  The release of this version has been eagerly awaited, so we are glad to say the wait is finally over.

NetAnalysis® v1.52 adds a number of new features and fixes some minor bugs.  Some of the major new features released in this version are the ability to export and rebuild the entire cache for each browser in a single process, new support for all versions of Google Chrome, support for Apple Safari Cache.db files and the ability to import recovered Apple Safari binary plist files recovered by HstEx® v3.6.

Export and Rebuild Cached Data

On 24th October 2002, we introduced the ability to rebuild and export cached pages to NetAnalysis v1.25. Over the years, this functionality has been extremely helpful in providing the necessary evidence in a whole host of forensic investigations.

In v1.52, we have responded to your requests and added the ability to extract and rebuild all of the cached content in one single process. This new functionality can be accessed from the Tools menu as shown below:

In addition to rebuilding and writing out the cached pages, NetAnalysis® exports all of the individual cached files and groups them by file type. This allows the contents of the cache to be quickly reviewed for evidence. The output also includes a full audit for each rebuilt web page and contains relative paths to allow the export folder to be archived to external media. You can also click on the hyperlinks within the audit log to access the cached content.

USB Licence Dongle Support

As some of you may be aware, our Blade® data recovery product is licensed via a USB licence dongle.  We are now offering the option to licence NetAnalysis/HstEx with a USB licence dongle.  The USB licence dongle provides you with much greater flexibility over a licence key file (which is restricted to one licence key per machine) as the USB dongle can be easily moved from machine to machine.  This is not permitted with a licence key file which is restricted to a single workstation.Existing licence key file holders can purchase a USB licence dongle upgrade through our store.  Please see the following link for further information on USB Dongle Licences.

TSV / CSV Exporting

Our support for exporting to TSV (tabbed separated values) and CSV (comma separated values) files has been completely re-written and enhanced. We now include the field column headers in the output and have added a progress bar for the export process. The export engines are also considerably faster than in previous versions.

It is also possible to switch off or hide any columns you do not need or to change the column order prior to exporting. This ensures the output format is in the same order as the grid columns. The export engine will also only output the current filtered records. The HTML export function will be updated in a future release.

Restricting Import Date Range

This is a new feature which was requested by some of our colleagues working within the corporate environment. In some investigations, they may only be permitted to import data within a certain date range. By selecting to restrict the import range, any data outside the target date range is not added to the workspace.

This functionality can be found by selecting Options from the Tools menu and selecting Restrict Data Range (as shown below).


F2 Find Next Tagged Record

This new function was added as a result of a request from a forensic examiner. During an investigation, it may be necessary to tag certain records of interest and then review the activity on either side of each record. This can be achieved by tagging the required records and then pressing F5 to remove all filters. Selecting F2 (or Searching » Find Next Tagged Record) will move the record pointer to the next tagged record allowing you to examine that record and the data surrounding it.

HstEx® v3.6 – Recovering Apple Safari History Binary Plist

NetAnalysis® now has the ability to import Apple Safari History binary plists recovered by HstEx® v3.6.

The Apple Safari browser stores Internet history records in an Apple Property List (plist). With the earlier versions of the Safari browser (version varies depending on operating system), this file was in XML format. In later versions, Apple switched to using a proprietary binary plist format. NetAnalysis supports both XML and binary plist files and now supports the recovery of this data direct from a forensic image or write protected physical/logical device.

The data is recovered by HstEx® and output in the form of *.hstx files. These files can then be loaded directly into NetAnalysis® v1.52. As of the publication of this article, NetAnalysis® and HstEx® are the only forensic tools capable of recovering this data.

Further Information


HstEx v3.6 adds a number of new features and fixes some minor bugs. One of the major new features released in this version is the ability to recover Safari binary plist data.

New Feature: Apple Safari Binary Plist Recovery

The Apple Safari browser stores Internet history records in an Apple Property List (plist). With the earlier versions of the Safari browser (version varies depending on operating system), this file was in XML format. In later versions, Apple switched to using a proprietary binary plist format. NetAnalysis supports both XML and binary plist files.

Using our proprietary Intelli-Carve™ technology (developed for our data recovery product Blade), we have enhanced HstEx by adding the ability to recover Safari binary plist history files. HstEx can recover this data even if the original file was deleted.

The data is recovered by HstEx and output in the form of *.hstx files. These files can then be loaded directly into NetAnalysis v1.52.

USB Licence Dongle Support

As some of you may be aware, our Blade data recovery product is licensed with a USB licence dongle. We are now offering the option to licence NetAnalysis and HstEx with a USB licence dongle. The USB licence dongle provides you with much greater flexibility over a licence key file (which is restricted to one licence key per machine) as the USB dongle can be easily moved from machine to machine. This is not permitted with a licence key file which is restricted to a single workstation.

Existing licence key file holders can purchase a USB licence dongle upgrade through our store. Please see the following link for further information on USB Dongle Licences.

New Feature – Cancel and Partial Recovery during Search Phase

This feature allows you to select cancel during the search phase of a recovery. On selecting cancel, you have the option of recovering what has been found so far (assuming HstEx has found data to recovery at this point) and perform a partial recovery.

New Feature – Open Export Folder on Completion

This feature can be accessed via the Options menu. When set, at the end of the extraction process, the Export folder will automatically open for easy access.

Data Recovery Buffer Size

With previous versions of HstEx, the processing block size was fixed to whichever block size had been set when the original device had been imaged (normally 64 Sectors). Version 3.6 now allows you to manually set the processing block size with the potential of speeding up the recovery.


Some of you will have noticed that from NetAnalysis® v1.50 there have been numerous new date and time columns added. These new timestamps were identified during months of research and development and are now included with the latest release. The image below shows some of the new fields from Internet Explorer. This article will look at each of the new columns and explain what they mean.


Last Visited [UTC]

This column should be self explanatory. It is the timestamp which reflects the last known recorded visit to a webpage (or object) in Coordinated Universal Time (UTC). Normally, this timestamp is extracted directly from the source record and not changed in any way by the time zone information set in NetAnalysis. With the exception of Internet Explorer Weekly INDEX.DAT records, all other records have their timestamps saved as UTC values. Weekly records are stored as local times and therefore have to be converted to UTC to fill this column.

Last Visited [Local]

This column contains the timestamp which reflects the last known recorded visit to a webpage (or object) in Local time. This timestamp is calculated by using the data from the Last Visited [UTC] column and converting it to Local time using the time zone information set in NetAnalysis prior to extraction (with the exception of Daily INDEX.DAT records which is already stored in Local time).

Date Expiration [UTC]

This column contains a timestamp (in UTC) which reflects the date and time when the object or record is no longer regarded as valid by the browser. For example, in History records, you will see that the expiration time is set according to the amount of days the browser is set to keep history records, whilst the cache expiration time can be set by the web developer and is delivered to the browser during the HTTP response. This column reflects the ExpireTime field in the INTERNET_CACHE_ENTRY_INFO Structure.

Date Last Modified [UTC]

This column contains a timestamp (in UTC) which reflects the date and time the webpage (or object) was last modified (last written). This information is passed back to the browser as part of the HTTP response. Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time.

Date Index Created [UTC]

This column contains a timestamp (in UTC) which reflects the date and time the Weekly INDEX.DAT file from Internet Explorer was created.

Date Last Synch [UTC]

This column contains a timestamp (in UTC) which reflects the last date and time at which an object was checked for freshness with the origin server. LastSyncTime is initially set as the time at which an object is added to the cache, and is updated every time the browser verifies freshness of the object with the server.

Date First Visited [UTC]

This column contains a timestamp (in UTC) which is available during the extracting of Netscape and Firefox v1-2 History. It reflects the first date and time at which a web page (or object) was visited.

Date Added [UTC]

This column contains a timestamp (in UTC) which is available during the extracting of Netscape, Firefox and Mozilla bookmark files. It reflects the date and time at which an entry was added to the bookmark file.

Further Information

For a breakdown of NetAnalysis® v2 Date/Time fields, please see a breakdown of the grid columns: NetAnalysis® v2 Grid Columns.


The Internet Explorer disk cache is a storage folder for temporary Internet files that are written to the hard disk when a user views page from the Internet.Internet Explorer uses a persistent cache and therefore has to download all of the content of a page (such as graphics, sound files or video) before it can be rendered and displayed to the user.Even when the cache is set to zero percent, Internet Explorer requires a persistent cache for the current session. The persistent cache requires 4 MB or 1 percent of the logical drive size, whichever is greater.

Disk Cache Storage Location

The disk cache location varies across operating systems and can usually be found in the following default locations:

Digital Detective NetAnalysis Cache Location Windows 98

Figure 1

Digital Detective NetAnalysis Cache Location Windows 2K and XP

Figure 2

Digital Detective NetAnalysis Cache Location Windows Vista and 7

Figure 3

To identify the correct location of the cache for each user, the registry hive for the particular user must be examined. You cannot rely upon the live cache folder being in the default location. Figure 4 shows the registry key containing the cache folder location. Users have been known to move their cache location in an attempt to hide browsing activity.

Digital Detective NetAnalysis Cache Examination Shell Folder Location

Figure 4

The “User Shell Folders” subkey stores the paths to Windows Explorer folders for each user of the computer. The entries in this subkey can appear in both the “Shell Folders” subkey and the “User Shell Folders” and in both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER. The entries that appear in user “User Shell Folders” take precedence over those in “Shell Folders”. The entries that appear in HKEY_CURRENT_USER take precedence over those in HKEY_LOCAL_MACHINE.

Temporary Internet Files Folder Structure

Within the Temporary Internet Files folder, you will find a Content.IE5 folder.  This folder is the main disk cache for Internet Explorer.  Outlook Express also writes data to this location as is explained later in this article.Inside the Content.IE5 folder, you will find a minimum of 4 cache folders.  The file names for these cache folders comprise of 8 random characters.  When further cache space is required, Internet Explorer will add additional folders in multiples of 4.  Figure 5 shows the layout of a typical Internet Explorer disk cache.

Digital Detective Windows Forensic Analysis Microsoft Internet Explorer Cache Folders

Figure 5

Content.IE5 INDEX.DAT File

The cache INDEX.DAT file is a database of cache entries.  It holds information relating to individual cached items so that the browser can check whether the resource needs to be updated (eTag) and information relating to the location of the cached item.  It also stores the HTTP (Hypertext Transfer Protocol) response header for the resource.At the start of the INDEX.DAT file, you will find a zero based array holding the names of the cache folders.  Each individual URL record contains an index value which refers to a specific folder in the array.  This allows Internet Explorer to correctly identify the location of a cached item.  This can be seen in Figure 6 below.

Digital Detective NetAnalysis INDEX.DAT Forensic Analysis

Figure 6

As files are saved to the cache, Internet Explorer uses a specific naming convention as shown in Figure 7.  The only exception to this rule is when data is written to this location by Outlook Express.

Digital Detective Forensic Analysis of Internet Explorer Cache Naming Convention

Figure 7

As pages and resources are cached, they can easily end up in different folders. Internet Explorer attempts to keep the volume of data and number of cached items across each cache folder as level as possible. As Internet Explorer writes files to the cache folders, it checks to see if a file with the same name already exists.  This is frequently the case when web developers do not use imaginative or descriptive names for their files.  If the file already exists within the folder, Internet Explorer will increment the counter.  If no file exists, the counter portion of the file name is set to 1. Files with the same naming structure within a cache folder do not necessarily belong to the same web site.  Also, multiple visits to the same web site can easily result in files with similar naming conventions being spread across all the cache folders.  Cached resources can also become orphaned when the INDEX.DAT entry is not written to disk (such as when Internet Explorer crashes before the entries are written).  Figure 8 shows a typical cache folder.  There are two files within this folder which would have had the original name “images.jpg”.  Internet Explorer has renamed them “images[1].jpg” and “images[2].jpg”.

Digital Detective Internet Explorer Forensic Cache Analysis Folder Structure

Figure 8

Outlook Express Email Client

Microsoft Outlook Express also uses the Content.IE5 folder as a temporary cache.  When a user selects an email message within the client, Outlook Express reads the data from the corresponding DBX file and caches the components of the email so that it can be rendered on screen for the user as an email message. The structure of the DBX files is such that the email message is broken down into blocks and has to be rebuilt before it can be rendered.  If the message contains any attachments, they are stored in Base64 format and stored within the file.  The attachments also have to be extracted, decoded and cached prior to rendering on screen.As the message is rebuilt, Outlook Express saves the different elements of the message to the disk cache as a temporary file.  The naming convention is different to Internet Explorer.  In the past, some forensic examiners have not been aware of this and have incorrectly attributed data in the cache to a visit to a web page when it in fact was there as the result of viewing an email message. The file structure is shown in Figure 9.  The asterisk values represent hexadecimal digits.  Figure 9 also contains some example file names.

Digital Detective Forensic Analysis of Internet Explorer Cache Outlook Express Temporary File Naming Convention

Figure 9