Use Tool Sleuthkit

Sleuthkit Exercise (Unallocated Extraction & Examination)

As the size of media being examined continues to grow, it is becoming apparent to many investigators that data reduction techniques are more important than ever. These techniques take on several forms, including hash analysis (removing known “good” files from a data set, for example) and separating allocated space in an image from unallocated space, allowing them to be searched separately with specialized tools. We will be doing the latter in this exercise.

The Sleuthkit comes with a set of tools for handling information at the “block” layer of the analysis model. The block layer consists of the actual file system blocks that hold the information we are seeking. They are not specific to unallocated data only, but are especially useful for working on unallocated blocks that have been extracted from an image. The tools that manipulate this layer, as you would expect, start with blk and include:

blkls

blkcalc

blkstat

blkcat

We will be focusing on blkls, blkcalc and blkstat for the next couple of exercises. The tool that starts us off here is blkls. This command “lists all the data blocks”. If you were to use the “-e” option, the output would be the same as the output of dd for that volume, since -e tells blkls to copy “every block”. However, by default, blkls will only copy out the unallocated blocks of an image.This allows us to separate allocated and unallocated blocks in our file system. We can use logical tools (find, ls, etc.) on the “live” files in a mounted file system, and concentrate data recovery efforts on only those blocks that may contain deleted or otherwise unallocated data. Conversely, when we do a physical search of the output of blkls, we can be sure that artifacts found are from unallocated content. this time extracting the unallocated data from our volume of interest and comparing the output from the whole volume analysis vs. unallocated analysis. So, we'll be working on the able2.dd image First we'll need to change into the directory containing our able2.dd image. Then we check the partition table and decide which volume we'll be examining. Recall that this is where we get our -o (offset) value from for our Sleuthkit commands. To do this, we run the mmls command :

we've decided to search the unallocated space in the second Linux partition (at offset 10260, in bold above). We run the blkls command using the offset option (-o) which indicates what partition's file system we are analyzing. We then redirect the output to a new file that will contain only the unallocated blocks of that particular volume.

In the above command, we are using blkls on the second partition (-o 10260) within the able2.dd image, and redirecting the output to a file called able2.blkls. The file able2.blkls will contain only the unallocated blocks from the target file system.

Now, we will use grep, this time on the extracted unallocated space, our able2.blkls file, to search for our text string of interest.

The grep command above now tells us that we have found the string “cybernetik” at four different offsets in the extracted unallocated space. We will concentrate on the first hit here. So the next obvious question is “so what?”. We found potential evidence in our extracted unallocated space. But how does it relate to the original image? As forensic examiners, merely finding potential evidence is not good

enough. We also need to know where it came from (physical location in the original image), what file it belongs or (possibly) belonged to, meta data associated with the file, and context. Finding potential evidence in a big block of aggregate unallocated space is of little use to us if we cannot at least make

some effort at attribution in the original file system. That's where the other block layer tools come in. We can use blkcalc to calculate the location (by data block or fragment) in our original image. Once

we've done that, we simply use the meta data layer tools to identify and potentially recover the original file, First we need to gather a bit of data about the original file system. We run the fsstat command to determine the size of the data blocks we are working with.

In the fsstat command above, we see that the block size (in bold) is 1024. We take the offset from our grep output on the able2.blkls image and divide that by 1024. This tells us how many unallocated data blocks into the unallocated image we found our string of interest. We use the echo command to pass the math expression to the command line calculator, bc:

We now know, from the above output, that the string “cybernetik” is in data block 1593 of our extracted unallocated file, able2.blkls. This is where our handy blkcalc command comes in. We use blkcalc with the -u option to specify that we want to calculate the block address from an extracted unallocated image (from blkls output). We run the command on the original dd image because we are calculating the orginal data block in that image.

The command above is running blkcalc on the file system at offset 10260 (-o 10260) in the original able2.dd, passing the data block we calculated from the blkls image able2.blkls (-u 1593). The result is a familiar block 5184.

If we look at the blkstat (data block statistics) output for block 5184 in the original image, we see that it is, in fact unallocated, which makes sense, since we found it within our extracted unallocated space. Note that we are now running the commands on the original dd image. We'll continue on for the sake of completeness.

Using the command blkcat we can look at the raw contents of the data block (using xxd and less as a viewer). If we want to, we can even use blkcat to extract the block, redirecting the contents to another file:

Note the size of the file resulting from the blkcat output (5184.blkcat) is 1.0k (1024 bytes – the file system block size), just as expected. If we want to recover the actual file and meta data associated with the identified data block, we use ifind to determine which meta data structure (in this case inode since we are working on an EXT file system) holds the data in block 5184. Then istat shows us the meta data for the inode:

   

Again, as we saw previously, the istat command, which shows us the meta data for inode 10090, indicates that the file with this inode is Not Allocated, and its first direct block is 5184. Just as we expected. We then use icat to recover the file. In this case, we just pipe the first few

lines out to see our string of interest, “cybernetik”.

Ok, Good Try & Good Luck.