The Sleuth Kit Informer Issue 22
http://www.sleuthkit.org/informer
Brian Carrier
carrier at sleuthkit dot org
Issue #22
March 15, 2006
Contents
- Introduction
- What's New?
- Call For Papers
- Current disk_stat Limitations
- TSK Libraries
Introduction
In the 22nd issue of The Sleuth Kit Informer, we address some of the features and limitations of the disk_stat tool in The Sleuth Kit and we address the design of the TSK libraries. The latter article is oriented towards developers who are interested in using TSK as part of their projects.
What's New?
There have not been any new releases of TSK or Autopsy since the last issue of the Informer, but a new version of TSK should be released shortly. It will contain bug fixes and possibly support for new file formats.
New releases of the tools and the Informer should be more consistent in the future now that I have some more time to work on them. I have defended my Ph.D. thesis and returned to the real world. I accepted a job at Basis Technology (http://www.basistech.com) as the Director of Digital Forensics and will be working on designing and developing new digital investigation tools.
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
Current disk_stat Tool Limitations
By: Brian Carrier
I'm starting to get more questions about the behavior of the disk_stat tool as disk sizes become larger. This article addresses some of those questions.
As a reminder, disk_stat is a tool that will display statistics about an ATA disk (under Linux) and will identify if a Host Protected Area (HPA) exists. Details on this process were outlined in issue 17 of the Informer and even more details can be found in File System Forensic Analysis. There are some limitations about disk_stat though that are documented in The Sleuth Kit's TODO file, but I will outline them here as well. All of these will be resolved in future versions of TSK.
The first limitation is that Device Configuration Overlays (DCO) are not currently detected. DCOs can exist at the same time as an HPA and both can be used to hide data from acquisition and analysis tools.
The second limitation of disk_stat is that it works only with ATA disks that are less than 128 GB in size. There are different ATA commands for disks that are larger than 128 GB, but the current version of disk_stat supports only the older version. Therefore it will not handle larger disks, but future versions will.
The third limitation of disk_stat is that it will not work on disks that are attached using a USB or Firewire enclosure. When external enclosures are used, the drives appear as SCSI and therefore the ATA commands required to detect the HPA must be tunneled. This is not currently supported.
In summary, disk_stat can be effectively used to detect a HPA in an ATA disk that is less than 128 GB in size. Now that disks over that size are becoming more common, a higher priority has been placed on removing the current limitation.
TSK Libraries
By: Brian Carrier
Many people are familiar with the command line tools of The Sleuth Kit or a graphical interface to the command line tools, such as Autopsy. But, there is another (little documented) interface to the tools that is of interest to investigation tool developers. This article provides a high-level overview of the C libraries that come with The Sleuth Kit (and assumes some familiarity with programming and libraries). It is intended to help people who want to develop new investigation tools based on TSK.
If you've ever looked at the command line tools in TSK, they are fairly simple because they only parse the arguments that are given to them and then they pass the data to one of the libraries. The libraries are where the real work is done and they exist for disk image file formats, volume systems, and file systems.
The disk image file format library (libimgtools.a) provides an abstraction to the various file formats. It currently supports single and split raw files, but the next versions of TSK will also support the Expert Witness format and the Advanced Forensic Format (AFF). The image file format library provides a read-only interface to disk image files and allows programs to read data from arbitrary locations in the file. The programs that use the library do not need to know what format is being used.
The volume system (media management) library (libmmtools.a) analyzes the various partition types that TSK supports. It has two major interfaces. One is a function to open a disk image file and detect the volume system type. The second is a "walk" function that will identify the volumes on the disk and process a callback function for each volume. The callback function is unique to the program that is using the library and will have access to the layout and type of each volume. This design allows the calling program to obtain information about each volume. For example, the mmls tool uses a callback function that prints the layout of each volume to the screen.
The third library is the largest and it is for the file system tools (libfstools.a). It has a design similar to the volume system tools where a program opens the disk or partition image file and then has access to a series of "walk" functions at the data, metadata, file name, file content, and journal levels. In most cases, the front-end to the command line tools do not have any file system specific code. An overview of each of these levels is given.
The data walk function identifies the blocks or clusters in a given range and processes a callback on each. The callback function has access to the content of the block or cluster and its allocation status. For example, the dls tool uses the data walk function and outputs the data from the unallocated blocks and clusters.
The metadata walk function identifies the metadata structures in a given range and processes a callback on each. The callback function has access to the file size, MAC data, cluster and block addresses, and more. For example, the ils tool uses the metadata walk function and prints most of the data to the screen. When the '-m' argument is given to ils, a different callback is used so that the data is printed in the order needed to make a timeline using mactime.
The file name walk function identifies the file names in a directory and processes the callback on each file name. The callback function has access to the file name and corresponding metadata. For example, the fls tool uses the file name walk function and prints the names and metadata addresses for a directory.
The file walk function identifies the on-disk locations where a file has stored its content and processes a callback on each of the blocks or clusters. The callback function has access to the file content and addresses. For example, the icat tool uses the file walk function and displays the contents of the file.
The file system library can also display unique information about files (i.e. istat) and file systems (i.e. fsstat) to an arbitrary location (typically the screen) . The library also allows an Ext3 journal to be processed using walk functions and callbacks.
In summary, the thousands of lines of code in TSK are easily accessible to other tools. The basic file system library design has existed since Wietse Venema and Dan Farmer first developed The Coroner's Toolkit and it has greatly expanded since then.
Copyright © 2006 by Brian Carrier. All Rights Reserved
