The Sleuth Kit Informer Issue 17

eZine lover (@eZine)

Published in

Sleuth Kit Informer

· 10 months ago

http://www.sleuthkit.org/informer
http://sleuthkit.sourceforge.net/informer

Brian Carrier
carrier at sleuthkit dot org

Issue #17
November 15, 2004

Introduction
What's New?
Call For Papers
Detecting Host Protected Areas (HPA) in Linux
Finding Binary Signatures

Introduction

This issue of The Sleuth Kit Informer is about new tools. The 1.73 release of The Sleuth Kit (TSK) included many new tools (as listed in What's New). In this issue, we look at the new 'diskstat' tool for detecting Host Protected Areas (HPA) and the 'sigfind' tool for finding binary signatures.

What's New?

Version 1.73 of The Sleuth Kit was released on November 2. It will now compile on 64-bit AMD Linux systems and fixes an NTFS bug that caused an error with a fragmented MFT. There are also new tools for Ext3 journals, support for UFS2 (FreeBSD 5), a new diskstat tool (described in this issue), and a new sigfind tool (also described in this issue).
http://www.sleuthkit.org/sleuthkit/

I have been getting some e-mails about the File System Forensic Analysis book that I have been working on and wanted to clarify what the book covers. The book is about how the various file and volume systems work, what they look like on disk, and how to analyze them. For its examples, the book uses tools that are free so that anyone can recreate them. Therefore TSK is used in most examples, but the book is fairly tool independent. The book is expected to be released in late March of 2005.

File System Forensic Analysis
http://www.aw-bc.com/catalog/academic/product/0,1144,0321268172,00.html

Call For Papers

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):

Tutorials on open source tools
User experiences and reviews of open source tools
New investigation techniques using open source tools
Open source tool testing results

http://www.sleuthkit.org/informer/cfp.html

Detecting Host Protected Areas (HPA) in Linux

Newer ATA (i.e. IDE) disks can have an area that is not accessible by users. The Host Protected Area (HPA) was designed so that vendors could store data on the disk and not have to worry about a user deleting them. This area can also be used to hide data from an investigator. The area is created and removed using low-level ATA commands.

After a system has been acquired and you are back in the lab, it is too late to think about the HPA. You will need to look for it when you have access to the original disk. You can detect an HPA by executing two ATA commands and comparing the outputs. One of the commands will give the maximum address of the disk and the other will give the maximum user accessible address. An HPA, if it exists, will be in between these two addresses.

With Linux, there are a couple of ways to detect an HPA. Newer versions will print a message when the system is booting.

For example:

# dmesg | less 
[...] 
hdb: Host Protected Area detected. 
    current capacity is 12000 sectors (6 MB) 
    native  capacity is 120103200 sectors (61492 MB)

A more manual process involves comparing the number of sectors in the output of 'hdparm -I' with the number of sectors on the disk (based on its model number and label / web site). As of TSK 1.73 you also have a third option.

The 'diskstat' tool in TSK works only in Linux and will execute the two ATA commands and compare the sizes. Both sizes are displayed and if there is an HPA, then its location is given. An example is given here:

# diskstat /dev/hdb 
Maximum Disk Sector: 120103199 
Maximum User Sector: 11999 

** HPA Detected (Sectors 12000 - 120103199) **

The 'diskstat' tool is based on the setmax.c program by Andries Brouwer[1]. If you detect an HPA and want to read its contents, then you will need to remove it. The removal process modifies the configuration of the hard disk, but it can be done such that the HPA will return after a reboot. The process of reconfiguring a hard disk makes me nervous and I have not yet released the HPA removal tool because I need to triple check the ATA commands. It should be included in the next release.

In the mean time, if you really want to remove an HPA, then you can use the 'setmax.c' program. Changes made by this tool will be permanent and the HPA will not return after a reboot. If you are concerned about running any of the removal tools on your disk, then make an image of the disk (using 'dd' or similar) while the HPA still exists. Then remove the HPA and image again. This way, you have a copy of the disk in the (rare) case that the removal process damages the disk (you should also document in your notes that you removed the HPA).

[1] Andries E. Brouwer. setmax.c. Available at: http://www.win.tue.nl/~aeb/linux/setmax.c

Finding Binary Signatures

When you need to find an ASCII or Unicode keyword, then you can easily use the 'strings' and 'grep' tools to search a disk image or file. When you need to find a non-ASCII value, then you may have more difficulty. Some versions of grep will support regular expressions that equate to non-ASCII values, but most do not. Searching for a binary value is useful when you want to find a given data structure, file header, or some other low-level value.

The Sleuth Kit (TSK) 1.73 includes a new tool called 'sigfind' that will search a file for a binary value. It requires at least two arguments: the signature in hexadecimal and the file. Optional arguments include the offset where the signature should be found, the block size to analyze, and the endian ordering. By default, an offset of 0 and a block size of 512 bytes are used.

The tool will read the input file in block sized chunks and look for the signature at the specific offset. It will print the sector address where the value was found and the distance since the previous hit. The distance is useful when looking for data structures that are stored in a pattern (every 1,024 sectors for example).

Let's look at some examples. The FAT and NTFS boot sectors have the value 0x55aa in the last two bytes of a 512-byte sector. In this FAT32 image, we search for the FAT data structures:

# sigfind -o 510 -b 512 55AA fat32.dd 
Block size: 512  Offset: 510  Signature: 55AA 
Block: 0 (-) 
Block: 1 (+1) 
Block: 2 (+1) 
Block: 6 (+4) 
Block: 7 (+1) 
Block: 8 (+1) 
Block: 12 (+4) 
[...]

The 512-byte sectors shown have the value in bytes 510 to 511. We see that it is found in sectors 0, 1, 2, 6, 7, and 8. This is a standard sequence for a FAT32 image because this signature is used in several data FAT32 structures and backup copies start in sector 6.

In the previous example, the value 0x55aa is written in that order on disk because it is a data structure signature. There could be other scenarios when we want to search for a value that is stored in a "backwards" ordering because of the system's endian ordering. For example, you may want to search for the value 0x12345678. When this number is written in a little-endian system, it will be written as 0x78563412 (this applies to number values only and not data structure signatures). 'sigfind' will convert this value for you by choosing the '-l' flag.

# sigfind -o 12 -b 512 -l 12345678 img.dd

There are several templates that I have defined in 'sigfind' to make the searching process easier. For example, there are currently templates for DOS partitions, Ext2/3 superblocks, FAT boot sector, NTFS boot sector, and UFS1/2 superblocks.