Brian Carrier
carrier at sleuthkit dot org
Issue #12
January 15, 2004
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.
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/
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' 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.
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'.
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
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.
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
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.
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