As the size of media being examined continues go 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 block that hold the information we are seeking.
They are not specific to unallocate data only, but are especially useful for
working on unallocated blocks that have been exstracted 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 nexs couple of exercise.
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.
To illustrate what we are talking about here, we'll run the same exercise
we did in Sleuthkit Exercise #2, 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
from earlier. We expect to get the same results we did in Exercise #2, but this
time by analyzing only the unallocated space, and then associating the
recovered data with its original location in the full disk 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 :
example file the wish to identify :
root@bt:~# mkdir ~/Rby
mkdir: cannot create directory `/root/Rby': File exists
root@bt:~# cd ~/Rby
root@bt:~/Rby# mmls able2.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000056 0000000057 Unallocated
02: 00:00 0000000057 0000010259 0000010203 Linux (0x83)
03: 00:01 0000010260 0000112859 0000102600 Linux (0x83)
04: 00:02 0000112860 0000178694 0000065835 Linux Swap / Solaris x86 (0x82)
05: 00:03 0000178695 0000675449 0000496755 Linux (0x83)
As with Exercise #2, 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.
root@bt:~/Rby# blkls -o 10260 able2.dd > able2.blkls
root@bt:~/Rby# ls -lh
total 340M
-rw-r--r-- 1 root root 9.3M 2012-10-31 16:53 able2.blkls
-rwxrwxrwx 1 root root 330M 2012-10-23 18:38 able2.dd
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, as we did in our previous analysis of this file system (Exercise #2)
we will use grep, this time on the extracted unallocated space, our able2.blkls
file, to search for our text string of interest. Read back through Exercise #2 if
you need a refresher on these commands.
root@bt:~/Rby# grep -abi cybernetik able2.blkls
1631299: * updated by Cybernetik for linux rootkit
9317041:Cybernetik proudly presents...
9323055:Email: cybernetik@nym.alias.net
9323087:Finger: cybernetik@nym.alias.net
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. Of course these are different from the
offsets we found in Exercise #2 because we are no longer searching the entire
original dd image.
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, as we did in our previous effort.
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.
root@bt:~/Rby# fsstat -o 10260 able2.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext2
Volume Name:
Volume ID: 906e777080e09488d0116064da18c0c4
Last Written at: Mon Aug 11 01:50:03 2003
Last Checked at: Tue Feb 11 12:20:09 1997
Last Mounted at: Thu Feb 13 14:33:02 1997
Unmounted Improperly
Last mounted on:
Source OS: Linux
Dynamic Structure
InCompat Features: Filetype,
Read Only Compat Features: Sparse Super,
METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 12881
Root Directory: 2
Free Inodes: 5807
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 51299
Block Size: 1024
Reserved Blocks Before Block Groups: 1
Free Blocks: 9512
BLOCK GROUP INFORMATION
--------------------------------------------
Number of Block Groups: 7
Inodes per group: 1840
Blocks per group: 8192
Group: 0:
Inode Range: 1 - 1840
Block Range: 1 - 8192
Layout:
Super Block: 1 - 1
Group Descriptor Table: 2 - 2
Data bitmap: 3 - 3
Inode bitmap: 4 - 4
Inode Table: 5 - 234
Data Blocks: 235 - 8192
Free Inodes: 789 (42%)
Free Blocks: 4601 (56%)
Total Directories: 16
Group: 1:
Inode Range: 1841 - 3680
Block Range: 8193 - 16384
Layout:
Super Block: 8193 - 8193
Group Descriptor Table: 8194 - 8194
Data bitmap: 8195 - 8195
Inode bitmap: 8196 - 8196
Inode Table: 8197 - 8426
Data Blocks: 8427 - 16384
Free Inodes: 1542 (83%)
Free Blocks: 33 (0%)
Total Directories: 13
Group: 2:
Inode Range: 3681 - 5520
Block Range: 16385 - 24576
Layout:
Data bitmap: 16385 - 16385
Inode bitmap: 16386 - 16386
Inode Table: 16389 - 16618
Data Blocks: 16387 - 16388, 16619 - 24576
Free Inodes: 0 (0%)
Free Blocks: 1813 (22%)
Total Directories: 12
Group: 3:
Inode Range: 5521 - 7360
Block Range: 24577 - 32768
Layout:
Super Block: 24577 - 24577
Group Descriptor Table: 24578 - 24578
Data bitmap: 24579 - 24579
Inode bitmap: 24580 - 24580
Inode Table: 24581 - 24810
Data Blocks: 24811 - 32768
Free Inodes: 746 (40%)
Free Blocks: 2379 (29%)
Total Directories: 76
Group: 4:
Inode Range: 7361 - 9200
Block Range: 32769 - 40960
Layout:
Data bitmap: 32769 - 32769
Inode bitmap: 32770 - 32770
Inode Table: 32773 - 33002
Data Blocks: 32771 - 32772, 33003 - 40960
Free Inodes: 0 (0%)
Free Blocks: 0 (0%)
Total Directories: 10
Group: 5:
Inode Range: 9201 - 11040
Block Range: 40961 - 49152
Layout:
Super Block: 40961 - 40961
Group Descriptor Table: 40962 - 40962
Data bitmap: 40963 - 40963
Inode bitmap: 40964 - 40964
Inode Table: 40965 - 41194
Data Blocks: 41195 - 49152
Free Inodes: 969 (52%)
Free Blocks: 545 (6%)
Total Directories: 4
Group: 6:
Inode Range: 11041 - 12880
Block Range: 49153 - 51299
Layout:
Data bitmap: 49153 - 49153
Inode bitmap: 49154 - 49154
Inode Table: 49157 - 49386
Data Blocks: 49155 - 49156, 49387 - 51299
Free Inodes: 1761 (176100%)
Free Blocks: 141 (6%)
Total Directories: 18
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:
root@bt:~/Rby# echo "1631299/1024" | bc
1593
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.
root@bt:~/Rby# blkcalc -o 10260 -u 1593 able2.dd
5184
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
(see Exercise #2 again). The illustration below gives a visual representation of a
simple example:
caIn the illustrated example above, the data in block #3 of the blkls image
would map to block #49 in the original file system. We would find this with the
blkcalc command as shown (this is just an illustration, and does not apply to
the current exercise):
root@bt:~/example# blkcalc -o $fs_offset -u 3 original.dd
49
So, in simple terms, we have extracted the unallocated space, found a
string of interest in a data block in the unallocated image, and then found the
corresponding data block in the original image.
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 (we're back to the
same results as in Exercise #2). Note that we are now running the commands
on the original dd image. We'll continue on for the sake of completeness.
root@bt:~/Rby# blkstat -o 10260 able2.dd 5184
Fragment: 5184
Not Allocated
Group: 0
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:
root@bt:~/Rby# blkcat -o 10260 able2.dd 5184 | xxd | less
0000000: 2f2a 0a20 2a09 6669 7865 722e 630a 202a /*. *.fixer.c. *
0000010: 0962 7920 4964 6566 6978 200a 202a 0969 .by Idefix . *.i
0000020: 6e73 7069 7265 6420 6f6e 2073 756d 2e63 nspired on sum.c
0000030: 2061 6e64 2053 6169 6e74 5374 6174 2032 and SaintStat 2
0000040: 2e30 0a20 2a09 7570 6461 7465 6420 6279 .0. *.updated by
0000050: 2043 7962 6572 6e65 7469 6b20 666f 7220 Cybernetik for
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.
root@bt:~/Rby# blkcat -o 10260 able2.dd 5184 > 5184.blkcat
root@bt:~/Rby# ls -lh
total 340M
-rw-r--r-- 1 root root 1.0K 2012-10-31 17:16 5184.blkcat
-rw-r--r-- 1 root root 9.3M 2012-10-31 16:53 able2.blkls
-rwxrwxrwx 1 root root 330M 2012-10-23 18:38 able2.dd
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:
root@bt:~/Rby# ifind -o 10260 -d 5184 able2.dd
10090
root@bt:~/Rby# istat -o 10260 able2.dd 10090
inode: 10090
Not Allocated
Group: 5
Generation Id: 3534950782
uid / gid: 4 / 7
mode: rrw-r--r--
size: 3591
num of links: 0
Inode Times:
Accessed: Sun Aug 10 11:18:36 2003
File Modified: Thu Dec 26 04:27:43 1996
Inode Modified: Sun Aug 10 11:29:58 2003
Deleted: Sun Aug 10 11:29:58 2003
Direct Blocks:
5184 5185 5186 5187
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”.
root@bt:~/Rby# icat -o 10260 able2.dd 10090 | head -n 10
/*
* fixer.c
* by Idefix
* inspired on sum.c and SaintStat 2.0
* updated by Cybernetik for linux rootkit
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>
