Forensic: EnCase Verification, MD5, and Other Myths

Encase is without doubt the most popular forensics tool on the market, however due to the name of one its features, it has also started one of the most common myths. Verification.

When EnCase completes an image it then conducts a “verification” and when it completes, it brings up a variety of hash values, and confirms that the data has “verified”. Excellent. Data verified…no not at all.

The EnCase verification does not check the original data, it check the destination data. This is an often misunderstood point, but one that can be critical.

A very simple test of this, for the doubting Thomas out there, is to simply disconnect the original drive while the verification is being carried out. The verification will still complete, successfully, despite the fact there is nothing to verify against. The reason is this:

The verification checks the image file, it verifies the integrity of the image files, an important process. It does not check if the data imaged is correct – a very important difference.

Example: Company X is at an clients site  imaging hard drives, they are using Tableau write blockers, connected to laptops and imaging to USB drives from a well known brand (inside the USB case is a 3.5 inch 500 GB S-ATA).  The drive to be imaged is an old 2.5 inch IDE drive.

The 2.5 inch drive, an old laptop drive, is taken out of the laptop and connected, via a 2.5 to 3.5 inch converter to the tableau write blocker, which is then connected, via USB, to the the laptop.

The person imaging selects the source drive, the 2.5 inch and sets the destination drive as the USB drive, this means that the data takes the following route.

1) It is read from the old, dusty, 2.5 inch hard drive.

2) It goes out the 2.5 inch pins, into the 3.5 inch converter.

3) From the 3.5 inch converter it goes along an IDE cable.

4) From the IDE cable it goes along to the Tablea write blocker.

5) The black box that converts the IDE to a USB.

6) The tableau then transmitts the data down a USB cable.

7 ) The USB cable connects to the laptop USB port.

8 ) The laptop USB port then connects to the motherboard.

9) The data is then transferred internally, and EnCase then “reads” the data.

10) Encase then “write the data” out and it travels along the mother board to another USB port.

11) From the USB port it goes down a USB cable to the USB drive.

12 ) The USB drive then converts to a 3.5 inch S-ATA drive.

13) The 3.5 inch S-ATA then write the data.

It is not until step (9) that Encase reads the data. It is that data that EnCase then writes, and then verifies what it has written. If it is feasible for an error to occur between 9 and 13, hence the need for the verification, it is also feasible, if not more so, that an error occurs between 1 and 9.

If the hard drive is not working correcty, or the cables are damaged, or the pins are not aligned correctly, or any of a host of other reasons then the hard drive will not image correctly. 99% of the time this error will be a very obvious error, e.g the hard drive will not spin up, or it cannot be seen – which is a good error to have, as it can be addressed.

Sometimes, very rarely but sometimes, the drive will image, but it will be producing junk data, or “skewed” data. While this is rare, it certainly does happen (unlike the theoretical problem of MD5 collisions). i.e. this is a real world problem, not just one confined to labs and mathematics papers.

In the worst case scenario this means that data will be imaged, Encase will read it, write it, and then verify it. The person conducting the image will then leave the scene and state, without intending to lie, that they have a 100% accurate image of the data.When in actual fact they have junk. This can, and does lead to all sorts of problems.

In one case the image of a single hard drive was taken at a “suspects” home, the image was verified and then taken back to the office.  The image was later investigated, from the investigation the examiner concluded that the user had wiped their drive with a tool that deliberately made a mess of the MFT.

What had actually happened is that the image of drive was poor, and much of the MFT was skewed during the imaging process, probably due to bad electronics/electrics somewhere in the imaging process. i.e. they had not taken a good image. But the person investigating the drive did not know/understand this and as a result produce a very detailed report explaining how the drive had been deliberately wiped to hide information.

The suspect/victim of this allegation was fortunate in that the computer was working (and shown to be working) prior to the image being taken and was working after the image being taken; this was, oddly, recorded by the person conducting the image. From this alone it was very obvious that the one and only drive in the computer could not have been wiped. But, in this case a long and detailed report, accusing the suspect/victim of wiping evidence  was submitted. While there was no evidence of the original allegations, the report stipulated, at great length, that the suspect had wiped their drive, and therefore conclusions could be drawn from that. The person writing the report was adamant that the image was correct, because it verified when he wrote the report. Even though he was hundreds of miles from the actual hard drive, the myth of EnCase Verification was so strong, that he believed that the verification guaranteed the quality of the data. A common belief.

A second image was taken, correctly, and the drive examined. From this it could be seen that there was no evidence of wiping, nor evidence of the original allegations. The  suspect/victims statement that that there computer was working were fully corroborated, and they were proved innocent.

Forensics: Rebuilding a Windows RAID with EnCase

Rebuilding a Windows Striped RAID in EnCase is incredibly simple. This is because the information about the RAID is kept within the hard drives, as its a software RAID. This is not the case for a hardware RAID, as the information about the drive configuration .

Note – A video guide on how to rebuild a hardware RAID will be on  the Where is Your Data? YouTube Channel  later this month.

 

Step 1: Add the striped drives to the case

Adding Striped Drives to EnCase

Adding Striped Drives to EnCase

Step2: Scan the disk configuration – right click one of the disks and select option (see screen shot)

Scan disk configuration with EnCase

Scan disk configuration with EnCase

Step 3: View the rebuilt RAID

Rebuilt RAID with EnCase

Rebuilt RAID with EnCase

Forensics: What happens when files are deleted?

The video below shows what happens when files are deleted on an NTFS partition.

When a file is deleted in NTFS, it is marked as deleted within the MFT entry for that file. The clusters that were allocated to the fille are now marked as free, within the $BitMap

This is shown at offset 22 for 2 bytes; i.e. bytes 22 and 23 of the MFT for that entry.

  • For an active file the 22nd and 23rd offsets read “01 00″  (in the video its flipped because of the big endian/little endian issue)
  • For a deleted file the 22nd and 23rd offsets read “00 00″.

Forensics: Viewing the MFT in EnCase

To view the MFT in EnCase in the most efficient manner, you should view it in a 1024 text style.  The steps below show how to do this. The attached PDF includes screen shots.

  1. Create a new text style in the “Text Style” panel. 
  2. Once in the Text Style “Attributes” section, do the following
    1.  Enter the Name of the style. The name is only for reference, and does not affect the view itself.
    2. Set the Line Wrap to Max Size
    3. Set the Wrap length to 1024
    4. Then select the “Code Page”
  3. In the code page select Western European ISO. Then press OK. 
  4. Then view the $MFT in text, and all the MFT headers should line up correctly
     

Forensics: Why is there no “Entry Modified” Date?

EnCase can only show the entry modified date if it exists, and it only exists  for certain file systems, e.g NTFS.

FAT, for example, does not record this information.

If the Entry Modified data cannot be seen in EnCase, during a forensic examination, this is probably because it is a file system that does not support that date.

Forensics: What does “Entry Modified” mean in EnCase?

EnCase can display a variety of dates, including created, written, and accessed, one date which often causes confusion for computer forensics examiner is “Entry Modified”.

Entry Modified, in EnCase, refers to when the MFT entry for that file was last change. As the MFT entry contains a lot of information about the file, including, size, name, location on the disk, parent folder, creation date, etc, changing any one of these should also change the “Entry Modified” date. E.g renaming the file, moving the file (defragmenting – moving it on the disk, or moving it into a different folder), or increasing the file size.

Under normal circumstances any action that trips any of the other dates, created, accessed, or file modified (referred to as Last Written in EnCase), will also trip the Entry Modified date – this is  due to one of two reasons:

The action that tripped the date, e.g. renaming the file caused a change in the MFT so the Entry Modified date will be updated

Altering any of the file dates will, by definiiton, change the MFT Entry (as this is where the dates are stored). Therefore the MFT Entry is changed.

Forensics: When is a bookmark not a bookmark in IE

The “Search Internet History” option in EnCase is an excellent function, and pulls back a lot of information very quickly. However, it can show misleading information, if its not interpreted correctly.

Looking for Internet History with EnCase

Looking for Internet History with EnCase

In the “bookmarks” section, which EnCase produces (under “Record”) Encase reports bookmarks, or URL shortcuts on the hard drive being examined.  Some people can interpret this as Bookmark that has been created manually, or is in the IE books marks tab. However this is not the case.

Some book marks are put their automatically, e. g the ubiquitous “MS.com” bookmark is in IE as a default.

Other bookmarks are not bookmarks at all. In the example shown below “Avast!” appear to be a bookmark in IE, but it is not. It is a shortcut is in the “program files” and its entirely possible that the user had no knowledge of it being there.

When a bookmark is not a bookmark

When a bookmark is not a bookmark

For this reason caution should be taken when explicitly stating that a bookmark proves knowledge of a website, or webaccess.

Add to Technorati Favorites

Follow

Get every new post delivered to your Inbox.

Join 31 other followers