Copy Link

Add to Bookmark

Report

The Sleuth Kit Informer Issue 12

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 #12
January 15, 2004

Introduction
What's New?
Correction
sdd: A 'dd' Variant
Splitting The Disk With mmls

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:

dos: DOS-based partitions (pretty much any disk in an x86 system)
bsd: FreeBSD, OpenBSD, and NetBSD disklabels and slices
mac: Macintosh partitions
sun: Solaris Volume Table of Contents structures and slices

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.