Brief Case Studies

Although recently released "WSia has already satisfied its goal of providing new evidence to support forensic investigations. The brief case study shown below is a description of circumstances where WSia has provided a positive contribution to a forensic investigation. Specific details of the investigation are not disclosed for confidentiality reasons but the general detail is included to demonstrate the use of the Search Index in forensic investigations.

Case Study One

Scenario

A suspects machine had been acquired during an investigation under suspicion of containing child pornography. The investigator ascertains that there are no such images within the existing file system but recovers three images from the unused clusters on the drive. A review of unused and deleted MFT records does not establish a definitive path or filename for any of the images.

To make the case more robust the investigator wishes to demonstrate whether the suspect made a positive effort to store the images on their computer.

WSia

The investigator decided to check the Search Index for data which might assist in establishing intent. They obtained the windows.edb file and opened it with WSia. The suspect system had been acquired with immediate power disconnection and therefore the edb file needed repair during the WSia load process.

Once the file had been loaded and repaired the investigator used the WSia repair analysis function to review changes made to the main table in the index, SystemIndex_0A. The analysis report showed some structural changes and after reviewing them the investigator was satisfied as to the integrity of the data recovered.

The investigator now prepared a list of words in a text file which included all known names by which the three images had been known previously. They then instigated a multi-word find process for all fields within the SystemIndex_0A table. After running through some 33,000 records the find process turned up two separate records including the potential file names searched for.

Device Details

Both entries turned out to be index entries for the files themselves but the value in the System_ItemPathDisplay field indicated that they had been stored on an external drive H:. No external drives had been recovered from the suspect during the acquisition process.

A review of the registry key HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices identified the volume GUID for the last device using the H: drive letter allocation. It is also identified that this external device was flash storage in the form of a USB stick although, at this stage, it did not conclusively demonstrate that the files had been stored on the device with that GUID.

The investigator recorded not only the GUID for the volume but also the entries for System_ThumbnailCacheId and System_FileFRN from WSia for possible use in conjunction with the thumbnail caches.

Cross check to DM Thumbs

Subsequently the investigator was able to match the thumbnailcache id stored within the record in the Search Index to that stored in the thumbnail record in the thumbcache_256.db and by reviewing the images in the thumbcache was able to confirm that these were indeed the suspect images.

In addition, the investigator was able to ascertain that the images were definitively* stored on the USB storage device with the recorded GUID by re-creating the thumbnailcache id from the values for System_FileFRN and the GUID. In this particular instance the investigator used the Thumbnailcache Id Creator on the DM Thumbs test platform.

*The thumbnailcache id is a hash and as such it is theoretically possible for collisions to occur in the values which will give rise to any particular thumbnailcache id. However, the probability of a collision is so small that the re-creation can be considered definitive. In practice, it is possible to test all possible combinations of file reference number and volume GUID for a given set of GUID's from a MountedDevices registry key and a maximum MFT record number/Sequence number combination.

As such the investigator could conclude that the files had been saved on to a memory stick which had not been recovered and in conjunction with the naming style of the folder on the stick identified in System_ItemPathDisplay they were able to demonstrate the intent to save the images in question.