Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


HstEx HstEx® has been designed to process a forensic image, physical/logical disk or binary dump at sector level.  It does not work at the file system level.  When HstEx HstEx® searches your source, it will search it a sector (or number of sectors depending on the block size set) at a time.  HstEx HstEx® uses linear processing and will examine each block of data contiguously.  This means that it will potentially recover data from (but not limited to) the following areas:


It works in a similar way to an imager in that it starts at sector zero and processes all the data to the end.  In many cases, it can recover individual records relating to Browser activity without the entire file being present on the source image or disk.  As HstEx HstEx® ignores the file system, it can be run across many source file system types without issue.  It also means that when it recovers from a disk or image, it will potentially recover the live data as well as any that is deleted.  To identify the location of source evidence, it will record the physical sector and sector offset of any data it recovers.  This allows an independent third party to verify the exact source of the evidence on your source disk or image.

Limitations of Linear Processing

What HstEx HstEx® cannot do is recover data which traverses a cluster boundary on non-contiguous clusters.  This is one of the reasons why you need to also extract and examine the available live data.


With many of the browser types, HstEx HstEx® uses a powerful search engine which is capable of Record Based Extraction.  In some circumstances, there can be limitations with RBE.  Some live browser files contain information which cannot be recovered using RBE.  For example, Microsoft Internet Explorer cache records contain an integer representing a zero based index which identifies the location of the cached item.  Whilst the index is contained within the record, the folder array containing the folder name string is stored at the start of the file.  RBE will not recover the name of folder as this is not stored within the record.


Another extraction methodology employed by HstEx HstEx® is File Based Extraction.  Some browser index files are designed in such a way as to make RBE impossible.  The History file from Firefox v1 - 2 is one such example.  Firefox v1 - 2 uses a Mork database which, because of its complicated structure, makes RBE impossible.  As such, it is impossible to recover individual Mork entries from unallocated clusters.  In this case, HstEx HstEx® employs FBE to recover Firefox v1 - 2 History.


We recommend that you extract the live data from your source as well as processing the entire image so that you recover potentially fragmented live files and all the recoverable deleted data.  This is because:

  • HstEx HstEx® employs a mixture of Record (RBE) and File Based Extraction (FBE)
  • Fragmented data cannot be recovered with Linear Processing
  • HstEx HstEx® does not support all the supported data types supported by NetAnalysisNetAnalysis®

Of course, you will end up with some duplication during your examination, but this is a small price to pay to ensure you have all the possible evidence.

You will also need to recover live cache files for processing so that NetAnalysis NetAnalysis® can rebuild the visited pages.  Internet Explorer cache entries have an index value which points to a zero based string aray which stores the cache folder name.  This is stored at front of the file.  This means you have to import a live cache INDEX.DAT file to get the full original path of the cache object.  During RBE extraction used by HstExHstEx®, although we can identify the index value for the array, we do not have the string array containing the folder names; therefore it is not possible to identify full cached paths using RBE.