Forensics: Imaging the HPA

Host Protected Area or Hidden Protected Area

This is an area of the hard drive that can be hidden from the O/S, but can be accessed during BIOS and therefore has value for a variety of reasons.  This is not the same as the DCO which is hardware locked and is not accessed via a computer during normal usage.

Examples of the HPA being used for genuine/commercial reasons include:

Computer manufacturers may use the area to contain a preloaded OS for install and recovery purposes (instead of providing DVD or CD media).

Dell notebooks hide Dell MediaDirec utility in HPA.  IBM and LG notebooks hide system restore software in HPA.

HPA is also used by various theft recovery and monitoring service vendors. For example the laptop security firm ComputTrace use the HPA to load software that reports to their servers whenever the machine is booted on a network. This is a good example of using the HPA because even if a stolen laptop has its hard drive formatted the HPA remains untouched

Can the HPA be imaged?

Yes ,  some  tools allow for this.  Linen for example will allow the HPA to be imaged.  It is the Linux environment, rather than EnCase specifically, that allows the HPA to be imaged.

Certain write blockers such as Tableau, will allow the imaging of the HPA as the hardware handles the issues of the HPA.

Hardware Cloners, by the likes of ICS and LogiCube, can also image the HPA and DCO


Forensic Cloner: ImageMASSter Solo-3 Forensic Cloner

The ImageMASSter Solo-3 Forensic is the ICS equivalent of the LogiCube Talon.

While it has a better look to it than the Talon ( good metal casing compared to a cheap look plastic case) some of  its specifications are not quite as good, as the ICS. 3 GB per min compared to 4 GB per minute.

Solo3 Forensic Cloner

Solo3 Forensic Cloner

Also the Solo-3 does not have  removebale media for storing logs. However it can image the DCO and HPA areas of the hard (according to the specifications).

Forensic Cloners: ICS Mass Cloner

For years Logicube have always produce a cloner that is slightly faster, or with slightly more features than ICS. But now ICS have produced the mother of all cloners the  Rapid Image 7020.

ICS Mass Cloner

ICS Mass Cloner

This machine, with levers big enough to make Dr Frankenstein happy, can image 10 drives at a time. Each with a maximum speed of 6 GB min. This would mean that a total of  60 GB a min or 3.6 TB of data per hour can be imaged with one device.

It also has the ability to log everything that is occurring, through a SQL database.  For those collecting hundreds of drives onsite, this would all the process to be done simply and easily, from a single centralized room.

But the device is not without its problems. Firstly, its $11,000 (USD). While that’s not very much for any company involved in large scale data collection, its still a hefty chunk of change. For the same price 10 laptops could be bought, to achieve the same goal  (but with more cables).

Secondly, by default, it does not seem very portable, what with those big levers. Large data collections are not a problem in the lab, but onsite. So it needs to be taken onsite.

Thirdly, it doesn’t support laptops by default, that’s an “add on” and its not clear if can support 10 laptop drives at a time, or just a few.

They still don’t produce Eo1 images, but staying with the DD image, which means there is no compression.

Overall its big, its yellow, it can image a lot of drives, and will be great for those large scale onsites, where you fully immerse yourself in the company. But for the smaller cases, imaging using the local machine, or with laptops its just too much.

Forensics Cloners: Talon

The Forensic Talon cloner, by Logicube, has been available for serveral years now, and at the time of its release it was the fastest on the market.

The Pro’s:

  • Its fast. Very fast. It states it can get upto 4 GB a min, and it can. If both drives are good S-ATA drives you will get those speeds.
  • It has a really good logging functionality, and stores everything you need to on flash media.

    Talon Cloner

    Talon Cloner

  • It can conduct a “keyword search” across the drive during the imaging (don’t expect the functionality of EnCase or FTK).
  • It has a good level of functionality, with cloning, imaging, and wiping functionality, as well as MD5 of SHA hashing, and verification methods.
  • If can be used as a write blocker as well as a cloning/imaging device.
  • It checks to see if data is moving over the cables correctly.

The Cons

  • Its plastic and feels cheap. Its not, but it looks and feels it.
  • The logging is fantastic, but it if the flash media is not present it will not image as it cannot log. i.e. if you leave the  flash media out of the kit, by mistake, you may as well not have the cloner at all.
  • It images to FAT32 only, no NTFS capability, and file names are restricted to 8 characters.
  • If you open the device, while the external IDE cables are connected (easy and often done) it can damage the connectors and ruin the cloner
  • The verification methods, involving data lines, can some times produce false negatives. I.e. The system will sometimes state that there is an error with the imaging/cloning functionality, even though the image is good.

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: What is imaging?

What does “imaging” a hard drive mean?

Imaging is the process of taking an exact copy of a hard drive, and is the very foundation of computer forensics, data recovery and electronic discovery processing.  It takes every single 0 and 1 on one hard drive and puts it on another

The imaging process, for most tools, takes an exact copy of each sector, starting at the first sector, Sector 0, then continues until the last sector.

Once a sector is read by the imaging tool it is then written down again onto another media.  Depending on the tool, the settings, and the users requirements, will depend on the how the data is stored.

Generally the options are:

Copy one sector to another sector: Cloning.  In this process each sector is mirrored onto another sector. Sector 1 of the source is copied to sector 1 of the destination, sector 63 is copied to sector 63, etc. At the end of the process the media being written to will be an exact copy of the original drive. In theory you could put the cloned drive into the computer the original computer came from and it would boot successfully. For example, if the original drive is 100 GB, with one 100GB partition)  and the destination media is 250 GB all of the 100 GB would be cloned to the 250 GB drive and the rest of the 250 GB would be blank. If the 250 GB drive was connected to a hard it would state that there was one 100 GB partition, and the remaining 150 GB would be “unused”.  The drive could be navigated and used as if it were the original drive.

As long as the exact number of sectors that have been imaged have been recorded the exact end of the 100GB clone on the 250 GB drive could be demonstrated.  This is a perfectly legitimate method of imaging drives, and historically was the most popular.

Note for this reason the destination drive must be zeroed/blank before the process starts.

Copying to a file: Raw/DD. In this process every sector is copied to another sector on the destination drive, but rather than cloning the data. e.g. Sector 1 is copied to Sector 1,  the data is put into a file. This is a very important difference. Firstly it means that the destination media HAS to be formatted, i.e the imaging drive cannot be completely blank. Secondly it means that you cannot boot a physical machine from the image directly (there are options using virtual machines, mounting the drive, or creating a clone). It is also important to understand that as the data does not have to be sequential or contiguous in a file (as it can be fragmented) the data being written on the destination drive will not be necessarily be sequential.

Example A 40 GB drive is to be imaged to a 250 GB hard drive. The 250 GB drive is formatted with NTFS. The imaging tool is set to create a raw file, called image1.raw, on the destination (250 GB) drve.  Sector 0 of the source drive is read and written to the first sector of image1.raw, sector 1 is then read and written to sector 2 of the file…sector 63 is then writen to the 64th sector of file..etc.  While the sector numbers appear very similar they are not because the first sector of the file image1.raw, could be 1,453,642, and therefore the second sector would be 1,453,643, and the third 1,453,644. As NTFS has the ability to fragment files, the 4th sector could be 2,743,203, or any other available sector. The actual physical sectors on the destination hard drive do not matter because that is handled by the NTFS. This will continue until every sector of the 250 GB drive is completed. The end result is a 100 GB file that is an exact duplicate of the original hard drive, that can be moved between media, across networks, backed up, and examined by tools like Encase, FTK, etc.

The difference between a Raw and DD format is that the latter will chunk up the data into set sizes, so that a single large file does not have to be created. For example, if a 1 TB drive is required to be imaged then the raw image would create 1 1 TB file, which could be problematic. However, if DD is used it will create multiple files of a set size (determined by the user) e.g. the max file size for the DD file could be set to 2 GB. This would mean that 500 2GB images would be created. This would result in image files like this image1.dd.1 image1.dd.2…image1.dd.500. When the DD is opened by FTK,  EnCase, or the like the DD image is then reassembled and the drive is viewed as if it were a raw or clone.

Copying to an image/propietary  file: E.g. E01.

This is the next stage on from an a raw or DD file. In this case when a sector is written down it is not a case of 1 sector to 1 sector, this is for several reasons. Firstly, programs like EnCase allow for compression, this means that muple sectors are compresed into a single sector. This is most effective when imaging hard drives with a lot of blank data. This means that a very large drive can be compressed significantly, an example of this is the Eo1 image created for the NTFS quiz on this site. This is a 40 GB drive, that has been compressed down to a few hundred MB, using EnCase, because most of the drive is blank. In addition to the compression of image files, such as E01, put in a variety of check sums and security features todetect if the files have been tampered with. More information on the E01 file is avaiable here.

Imaging Tools

There are many imaging tools and systems on the market from the boot drive BackTrack which has a DD imaging tool installed and ready to Encase, the most famous/popular/expensive of forensic toosl which can only create E01 files, to FTK Imager, a light weight free imaging tool that can produce E01 Files, RAW, or DD images.

Despite claims of perfect imaging etc, no image tool is really perfect and deals with errors in different ways, this article shows the effectiveness of different imaging tools

Forensics: How to image a hard drive

The video below shows how to image a hard drive using EnCase.