The Sleuth Kit Informer

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

Brian Carrier
carrier at sleuthkit dot org

Issue #12
January 15, 2004


Contents


Introduction

This 12th issue of The Sleuth Kit Informer has two articles in it. The first is on a tool that I recently learned about, sdd, and the other is on breaking a disk into partitions using the 'mmls' tool from The Sleuth Kit. The latter article is an update to the Splitting The Disk article that appeared in the March 2003 issue, which used the 'fdisk' tool.

The Informer will be celebrating its one year anniversary next month and I have decided to change its release schedule. The Informer will now be published on the 15th of every second month, so the next issue will be on March 15. I encourage anyone that is interested in writing an article related to forensics and open source tools to submit an abstract. If you have any requests or suggestions, please email me with them.


What's New?

The architecture upgrade of Autopsy is complete, but I have not released it yet. I am waiting until I add new features and then it will be a 2.0 release. If you are interested in playing around with a beta version, send me an email. The beta has the same features as the 1.75 release and has the same external look, just a different internal look.

On January 6, 2004, I released version 1.67 of The Sleuth Kit. The new version contains bug fixes, the biggest one was that the size for files larger than a 2GB in an EXT3FS file system were incorrectly reported. 'fsstat' was reporting too many entries in the file allocation table for FAT file systems and the '-h' flag in 'icat' wasn't working (so the holes in the file were still being shown). There are some other minor bugs that are listed in the CHANGES file and on the website.

http://www.sleuthkit.org/sleuthkit/index.php

Remember that you can always get a list of open and fixed bugs from the bug tracker on source forge. There is a link from the download page for both Autopsy and The Sleuth Kit.

http://www.sleuthkit.org/autopsy/download.php
http://www.sleuthkit.org/sleuthkit/download.php

I have also started to list the "add-on" tools on the download pages. These are tools that people have developed to work with Autopsy and The Sleuth Kit.

Matthias Hofherr released The Forensic Hash Database, which allows you to import many types of hash databases into a single database. With his patch, you can use 'hfind' to look up hashes in the database and 'sorter' can use the database to skip files.

http://www.forinsect.de/forensics/


Correction

What is this you ask? A corrections section? Yup, I messed up.

In the last issue of The Sleuth Kit Informer, I defined DCFL as the U.S. Digital Computer Forensic Lab. Several people pointed out that the 'D' stands for DoD and DCFL actually stands for DoD Computer Forensics Laboratory. Sorry about that.

Dave Dittrich also pointed out that he has a patch for GNU fileutils that he released in November of 2000 that does similar things to dcfl-dd.

http://www.securityfocus.com/archive/104/144530


sdd: A dd Variant

'sdd' is a 'dd' variant and has at least one cool feature that 'dd' does not have. It uses the same arguments as 'dd', but the printed output is more useful. Instead of just reporting the number of blocks that were copied in and out and a 1 or 0 value to identify if the last block was not complete, 'sdd' actually gives the number of bytes copied and how much of the last block was copied.

Here is an example of an acquisition using 'sdd':

     # sdd if=/dev/hda1 of=/dev/null bs=4k
     sdd: Read 257032 records + 0 bytes (total of 1052803072 bytes = 1028128.00k).
     sdd: Wrote 257032 records + 0 bytes (total of 1052803072 bytes = 1028128.00k).

The same parameters using 'dd':


     # dd if=/dev/hda1 of=/dev/null bs=4k
     257032+0 records in
     257032+0 records out

Here is an example of an incomplete final block using 'sdd':


     # sdd if=/dev/hda1 of=/dev/null bs=5k
     sdd: Read 205625 records + 3072 bytes (total of 1052803072 bytes = 1028128.00k).
     sdd: Wrote 205625 records + 3072 bytes (total of 1052803072 bytes = 1028128.00k).

The same using 'dd':


     # dd if=/dev/hda1 of=/dev/null bs=5k
     205625+1 records in
     205625+1 records out

You can get the source from here:

http://directory.fsf.org/sysadmin/Backup/sdd.html

I haven't fully tested this tool, so I don't know if it is reliable as 'dd', but it is interesting.


Splitting The Disk With mmls

Introduction

The 'mmls' tool was added to version 1.63 of The Sleuth Kit and it is the first tool in the media management set of tools. The media management tools in The Sleuth Kit deal with the data structures that organize and manage disks and other media. I could have called them partition tools, but some platforms use the term slice and I'm sure there are other names. So, media management is my generic term.

I developed 'mmls' so that all platforms that can use The Sleuth Kit would be able to split disks into partitions. There are several versions of 'fdisk' out there and not all platforms have the same options and features. So, 'mmls' provides consistent features and will eventually allow me to develop a library so that you can use disk images instead of file system images with the file system tools. 'mmls' also has some features that I felt were missing from 'fdisk'.

mmls Overview

The 'mmls' tool takes two arguments: the file system type and the disk image. The type is identified with the '-t' flag and currently there are the following types:

When you need to specify an offset for the location of the media management structure, the '-o' flag can be used. The offset value is in sectors (512-bytes each). Offsets are commonly required for BSD disk labels. For example:


     # mmls -t bsd -o 2056321 disk.dd

Using mmls

Lets start with an example of a system with five file system partitions and two extended partitions.

# mmls -t dos disk2.dd
  Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 Unallocated
02: 00:00 0000000063 0001028159 0001028097 NTFS (0x07)
03: 00:01 0001028160 0001648394 0000620235 Win95 FAT32 (0x0B)
04: ----- 0001648395 0001654694 0000006300 Unallocated
05: 00:02 0001654695 0002072384 0000417690 Linux (0x83)
06: 00:03 0002072385 0019984859 0017912475 DOS Extended (0x05)
07: ----- 0002072385 0002072385 0000000001 Extended Table (#1)
08: ----- 0002072386 0002072447 0000000062 Unallocated
09: 01:00 0002072448 0002698919 0000626472 NTFS (0x07)
10: 01:01 0002698920 0003116609 0000417690 DOS Extended (0x05)
11: ----- 0002698920 0002698920 0000000001 Extended Table (#2)
12: ----- 0002698921 0002698982 0000000062 Unallocated
13: 02:00 0002698983 0003116609 0000417627 Linux (0x83)

There is a lot of information there, so lets parse it out. The first column is an index of the entries that 'mmls' prints out. The second column, 'Slot', shows the location in the media management structures where the partition entry came from. For example '00:00' is the first entry in the first partition table whereas '01:00' is the first entry in the second partition table (the one in the first extended partition). The Start, End, and Length columns are all in sectors and the last column gives the type of partition. One benefit of this output is that the length is given to you, so you don't have to subtract the ending and starting addresses when you run 'dd'.

Entries 0, 7, and 11 show the partition table sectors, so that you know where the data structures are located. There is typically unused space between the partition table and the start of the next partition and that is shown in the output as 'Unallocated'. If there is any space that has not been allocated by the structures, then 'mmls' will report that as 'Unallocated'. In the above example, we can see that between the second and third file system partitions (entries 3 & 5) there are 6,300 unallocated sectors.

The next example is a system with three primary partitions and three operating systems (Windows, FreeBSD, and OpenBSD). First the 'fdisk' output:

    
# fdisk -lu disk.dd
Device Boot Start End Blocks Id System
disk.dd1   63 2056319 1028128+ b Win95 FAT32
disk.dd2   2056320 8209214 3076447+ a6 OpenBSD
disk.dd3 * 8209215 19999727 5895256+ a5 FreeBSD

Now the 'mmls' output:

# mmls -t dos disk.dd
  Slot Start End Length Description
00: ----- 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000001 0000000062 0000000062 Unallocated
02: 00:00 0000000063 0002056319 0002056257 Win95 FAT32 (0x0B)
03: 00:01 0002056320 0008209214 0006152895 OpenBSD (0xA6)
04: 00:02 0008209215 0019999727 0011790513 FreeBSD (0xA5)

OpenBSD and FreeBSD have disklabel structures inside of their DOS partition. The DOS partition is there so that the system can be booted, but once the OS is loaded, it uses its own disk label structure, so we will need to examine it. To do that, we specify the sector offset of the BSD partition (the OpenBSD one in this example):

# mmls -t bsd -o 2056321 disk.dd
  Slot Start End Length Description
00: 02 0000000000 0019999727 0019999728 Unused (0x00)
01: 08 0000000063 0002056319 0002056257 MSDOS (0x08)
02: 00 0002056320 0002260943 0000204624 4.2BSD (0x07)
03: 01 0002260944 0002875823 0000614880 Swap (0x01)
04: 03 0002875824 0003080447 0000204624 4.2BSD (0x07)
05: 04 0003080448 0003233663 0000153216 4.2BSD (0x07)
06: 07 0003233664 0004257791 0001024128 4.2BSD (0x07)
07: 06 0004257792 0008209214 0003951423 4.2BSD (0x07)
08: 09 0008209215 0019984859 0011775645 Unknown (0x0A)

This output shows that there are seven more partitions inside of the OpenBSD partition. Also note that the FAT partition from the DOS partition table is also shown in the disk label structure (entry #1). If you have never dealt with BSD systems before, this example may seem weird.

This output provides an example of how 'mmls' sorts the output. 'fdisk' will sort the entries based on where they were in the data structures, but 'mmls' sorts them based on their starting sector. For example, 'fdisk' would print the entries in this image so that the 'Slot' column was sequential and therefore the MSDOS entry (entry #1 above) would be at the end of the listing even though it starts at sector 63. 'mmls' sorts the output based on starting sector so that it is easier to identify the disk layout.

Extracting the Partitions

We will use 'dd' to extract the partitions, like we did in Issue #2. 'dd' needs the starting sector for the partition and the number of sectors in the partition. With the 'fdisk' output, we had to calculate the size of the partition using the start and end locations, but 'mmls' gives use the length.

Therefore, to extract the FAT partition in the previous example, we would use:


     # dd if=disk.dd of=part1.dd bs=512 skip=63 count=2056257

Or, we could extract the unallocated space between the partitions in the first example:


     # dd if=disk2.dd of=unused.dd bs=512 skip=1648395 count=6300

Conclusion

This article has shown how to use 'mmls' and how it can be used to extract partitions. There is a lot more output from running 'mmls' that from 'fdisk', but it has been designed with the theory that if the data exists than you should be able to see it. Using 'mmls' may require more knowledge about how partitions work than 'fdisk' does, but I think that it allows you to more easily understand the layout of the disk.

References

Splitting The Disk Part #1- The Sleuth Kit Informer Issue #2
    
http://www.sleuthkit.org/informer/sleuthkit-informer-2.html#split

The Sleuth Kit
     http://www.sleuthkit.org/sleuthkit


Copyright © 2004 by Brian Carrier. All Rights Reserved