carrier at sleuthkit dot org
May 15, 2005
This issue of The Sleuth Kit Informer is about new tools and features that were added to version 2.00 of The Sleuth Kit (TSK). The first article describes how to remove Host Protected Areas (HPA) from ATA disks using the disk_sreset tool and the second article describes the new automatic type detection features for file and volume systems.
Version 2.00 of TSK was released on March 15, 2005. It included many new features including support for disk and split images, automatic type detection, and several new tools (img_stat, mmstat, and disk_sreset). Version 2.04 of Autopsy was also released at the same time and it supported the new TSK features.
Version 2.01 of TSK was released on April 8, 2005. It included a couple of bug fixes that were introduced with the new 2.00 features. Autopsy 2.05 was also released at the same time to fix a few bugs.
Florian Buchholz and Courtney Falk from the CERIAS computer forensics research group at Purdue University released the Zeitline tool, which is a Java-based timeline tool. It can import data from 'fls -m' or 'ils -m' (like the mactime tool does) and provides a graphical view of the events so that you can group, sort, and filter them.
Paper submissions for the 5th Annual Digital Forensic Research Workshop (DFRWS) are due June 1. Analysis techniques, tools, and case studies are of interest, so I encourage you to submit a paper.
Paper submissions for the 2005 Annual Computer Security Applications Conference (ACSAC) are due on May 29. They have listed forensics as an area of interest and are looking for papers on applying or developing systems.
My File System Forensic Analysis book was published in late March. The website has a sample chapter on DOS and Apple partitions.
The Sleuth Kit Informer is looking for articles on open source tools and techniques for digital investigations (computer / digital forensics) and incident response. Articles that discuss The Sleuth Kit and Autopsy are appreciated, but not required. Example topics include (but are not limited to):
By: Brian Carrier
Version 2.00 of TSK added a new tool called disk_sreset that, when running in Linux, removes a Host Protected Area (HPA) from an ATA disk. This is a continuation of Issue #17 of The Sleuth Kit Informer, which discussed how to detect an HPA with the disk_stat tool (which was then called diskstat). As a review, an HPA is an area of the hard disk that vendors can use to store support data and it can also be used to hide data from an investigator. The sectors in an HPA are located after the sectors that a user can access.
There are three ATA commands that are used to detect and remove an HPA. One is the IDENTIFY_DEVICE command that reports the maximum user addressable sector of the disk. When using a normal acquisition tool, you will not be able to read beyond the address reported by this command. Another command is READ_NATIVE_MAX and it returns the total number of sectors on the disk (unless a Device Configuration Overlay (DCO) exists, in which case there are still more hidden sectors after this value). If the sectors reported by IDENTIFY_DEVICE and READ_NATIVE_MAX commands are different, then an HPA exists. Refer to File System Forensic Analysis for some nice figures of this and a description of DCO.
To remove the HPA, we need to execute the SET_MAX_ADDRESS ATA command, which sets the maximum user addressable sector. This is also the same command that is used to create an HPA. To remove the HPA, we execute the command with the address returned by READ_NATIVE_MAX, which is the maximum sector of the disk. This will allow you and your tools to read the sectors that were previously inaccessible. The SET_MAX_ADDRESS command has an option to make the change permanent or temporary. If only temporary, then the HPA will exist again after the hard disk is powered off.
When you run the new disk_sreset tool in TSK, it will first confirm that an HPA exists. If one does, then it will remove the HPA using the temporary setting so that the HPA will exist again after the disk is powered off, or reset.
Let's go over how the disk_stat and disk_sreset tools can be used during a disk acquisition. We'll assume that we are acquiring a disk using a Linux system and that the disk being acquired is on /dev/hdb.
The first step is to get the details of the disk. We can get some of the basics using disk_stat. This will show us if an HPA exists and how many user accessible sectors there are. On our example disk we see the following:
# disk_stat /dev/hdb Maximum Disk Sector: 120103199 Maximum User Sector: 118006047
** HPA Detected (Sectors 118006048 - 120103199) **
We can see there is an HPA starting in sector 118,006,048. Before we acquire the data in the HPA, we will first acquire the data that is currently accessible. This will ensure that we get the data even if removing the HPA causes problems and it allows us to have a separate file for the "hidden data".
# dd if=/dev/hdb of=/mnt/hdb_img.dd bs=8k 7375378+0 records in
7375378+0 records out
A quick sanity check shows that 7,375,378 records of 8KB each is equal to the 118,006,048 user addressable sectors. Now we remove the HPA using the disk_sreset tool. Note that some hardware ATA write blocks may block this command because it modifies the configuration of the disk (even though disk_sreset changes it only temporarily).
# disk_sreset /dev/hdb Removing HPA from 118006048 to 120103199 until next reset
We can now acquire the remaining data using dd. We skip ahead to the start of the HPA and acquire the data to a new file:
# dd if=/dev/hdb of=/mnt/hdb_hpa.dd bs=8k skip=7375378 131072+0 records in 131072+0 records out
We can import the hdb_img.dd file into our normal analysis tools (such as The Sleuth Kit or Autopsy) and analyze the volume and file systems. The hdb_hpa.dd file can be analyzed to determine what type of data it contains. It may be a file system or some other structured data.
Brian Carrier. "Detecting Host Protected Areas (HPA) in Linux." The Sleuth Kit Informer #17. November 2004. Available at: http://www.sleuthkit.org/informer/sleuthkit-informer-17.html.
Brian Carrier. "File System Forensic Analysis." Addison Wesley. 2005. Available at: http://www.digital-evidence.org/fsfa/.
As of version 2.00, The Sleuth Kit (TSK) will detect the type of file system, volume system, and image file format so that you do not always need to specify it on the command line or when importing files into Autopsy. This is a short article that describes the general process and why the tools may have trouble determining the type.
The basic design of the autodetect feature is that the tool will try each file system, volume system, or image file type. Even if one type is found to be successful, all of the types are tested. If more than one type is successful, then an error is generated and you will need to specify the type that you think it is. For an example of when this occurs, try the image files for Test #10 at my Digital Forensic Tool Testing site. The image files contain partitions with multiple file systems, such as NTFS and UFS or NTFS and Ext2fs.
Note that DOS partition tables and NTFS and FAT boot sectors both have 0x55AA in their last two bytes and therefore additional tests must be conducted to determine if the file is a disk image with DOS partitions or a partition image with a FAT or an NTFS file system. For example, the mmls code will check to make sure it does not process a FAT or NTFS file system.
Version 2.01 of TSK changed some of the tests that were performed when detecting the volume system (media management) type of a disk image. To prevent mmls from identifying a FAT file system as a DOS partition, there are checks that look for valid FAT boot sector values, such as a cluster size. Some of the tests in version 2.00 were too strict and would claim that DOS partition disk images were FAT partition images and therefore would force the user to specify the type. Version 2.01 relaxed some of the tests.
The type detection tests will likely change over time to more accurately detect the various file and volume systems. If you run into disks or partitions that produce error messages when you do not think they should, let me know what the error message is and I'll look into making it less strict.
Brian Carrier. "NTFS Autodetect Test #1." Digital Forensic Tool Testing (DFTT) Image #10. January 2005. Available at http://dftt.sourceforge.net/test10/index.html.