File System Tools

=============================================================================

Currently, evidence is more frequently found in the file system than
in process memory.  This is because it is non-volatile and remnants of
deleted files can typically be found.  This file will help one to use the
low-level tools in The @stake Sleuth Kit (TASK) for a forensic analysis.

This document is organized into small scenarios, which provide examples
of how to use TASK.


TIME LINE
=============================================================================
The steps from mac.README are followed (using both ils and fls) and 
you notice some interesting activity from unallocated inodes, namely
inode 5035 from image wd0e.dd.  To display the contents of this file,
use "icat":

    # icat -f openbsd images/wd0e.dd 5035 | less

NOTE: To prevent your terminal from getting messed up, pipe all output of
"icat" through a pager like "less".


SEARCH
=============================================================================
In this scenario, we will search the unallocated space of the "wd0e.dd"
image for the string "abcdefg".  The first step is to extract the
unallocated disk units using the "dls" tool (as this is an FFS image,
the addressable units are fragments).

    # dls -f openbsd images/wd0e.dd > data/wd0e.dls

Next, use the UNIX strings(1) utility to extract all of the ASCII
strings in the file of unallocated data.  If we are only going to be
searching for one string, we may not need to do this.  If we are going
to be searching for many strings, then this is faster.  Use the '-t d'
flags with "strings" to print the byte offset that the string was found.

    # strings -t d data/wd0e.dls > data/wd0e.dls.str

Use the UNIX grep(1) utility to search the strings file.  

    # grep "abcdefg" data/wd0e.dls.str | less
    10389739: abcdefg

We notice that the string is located at byte 10389739.  Next,
determine what fragment.  To do this, we use the '-s' argument to
'dcat' on the original image.

    # dcat -s -f openbsd images/wd0e.dd
	1024: Size of Addressable Unit
	8192: File Block Size
	8: Num Frags

This shows us that each fragment is 1024 bytes long.  Using a calculator,
we find that byte 10389739 divided by 1024 is 10146 (and change).
This means that the string "abcdefg" is located in fragment 10146 of the
"dls" generated file.  This does not really help us because the dls image
is not a real file system.  To view the full fragment from the dls image,
we can use dd:

    # dd if=images/wd0e.dd bs=1024 skip=10146 count=1 | less

Next, we will identify where this fragment is in the original image.
The "dcalc" tool will be used for this.  "dcalc" will return the "address"
in the original image when given the "address" in the dls generated image.
(NOTE, this is currently kind of slow).  The '-u' flag shows that we
are giving it an dls address.  If the '-d' flag is given, then we are
giving it a dd address and it will identify the dls address.

    # dcalc -f openbsd -u 10146 images/wd0e.dd
    59382

Therefore, the string "abcdefg" is located in fragment 59382.  To view
the contents of this fragment, we can use "dcat".

    # dcat -f openbsd images/wd0e.dd 59382 | less

To make more sense of this, let us identify if there is a meta data
structure that still has a pointer to this fragment.  This is achieved
using "ifind".  The '-a' argument means to find all occurrences.

  # ifind -f openbsd -a images/wd0e.dd 59382
  493

Inode 493 has a pointer to fragment 59382.  Let us get more information
about inode 493, using "istat".

    # istat -f openbsd images/wd0e.dd 493
	inode: 493
	Not Allocated
	uid / gid: 1000 / 1000
	mode: rw-------
	size: 92
	num of links: 1
	Modified:       08.10.2001 17:09:49     (GMT+0)
	Accessed:       08.10.2001 17:09:58     (GMT+0)
	Changed:        08.10.2001 17:09:49     (GMT+0)
	Direct Blocks:
	  59382

Next, let us find out if there is a file that is still associated with
this (unallocated) inode.  This is done using "ffind".

    # ffind -f openbsd -a images/wd0e.dd 493
	* /dev/.123456

The leading '*' identifies the file as deleted.  Therefore, at one point,
the file '/dev/.123456' allocated inode 493, which allocated fragment
59382, which contained the string "abcdefg".

If "ffind" returned with more than file that had allocated inode 493,
it means that either both were hard-links to the same file or that one
file (chicken) allocated the inode, it was deleted, a second file (egg)
allocated it, and then it was deleted.  The string belongs to the second
file, but it is difficult to determine which came first.  On the other
hand, if "ffind" returns with two entries where one deleted and one not,
then the string belongs to the non-deleted file.


DELETED CONTENT
=============================================================================
To view all of the deleted file names in an image, use the "fls" tool.
For all deleted files, use the '-r' flag for recursive and '-d' flag
for deleted.

    # fls -f linux-ext2 -rd images/hda9.dd | less
    d/d * 232: 	/TEMP-823450
    r/d * 293: 	/TEMP-131100
	
This shows us the full path that the deleted files are located.  On some
systems, such as Linux, the file content may be recovered (depending
on how much system activity has occurred).  On other systems, such
as Solaris, deleted files can not be easily recovered.   The number
at the beginning of the line is the inode number.  The '*' shows that
it is deleted and the 'd' and 'r' show the type (directory and file).
The first letter identifies the directory entry type value (which does
not exist in all file system types) and the second letter is the type
according to the inode.  In most cases these should be the same, but
it may not for deleted files if the inode has been reallocated to a
file of a different type.  If we do an "istat" on the directory (232)
we will notice that the size is 0.

    # istat -f linux-ext2 images/hda9.dd 232
	inode: 232
	Not Allocated
	uid / gid: 0 / 0
	mode: rwxr-xr-x
	size: 0
	num of links: 0
	Modified:       08.23.2001 21:52:33     (GMT+0)
	Accessed:       08.23.2001 23:05:39     (GMT+0)
	Changed:        08.23.2001 21:52:33     (GMT+0)
	Deleted:        08.23.2001 23:05:39     (GMT+0)
	Direct Blocks:


Linux does this to all of its deleted directories.  It should also
be observed that no block addresses are shown in the "istat" output.
This is because the size is 0 and the program thinks that the address
is bogus.  Using the '-b' option of "istat", we can force it to output
the block address.

    # istat -b 2 -f linux-ext2 images/hda9.dd 232
	inode: 232
	Not Allocated
	uid / gid: 0 / 0
	mode: rwxr-xr-x
	size: 0
	num of links: 0
	Modified:       08.23.2001 21:52:33     (GMT+0)
	Accessed:       08.23.2001 23:05:39     (GMT+0)
	Changed:        08.23.2001 21:52:33     (GMT+0)
	Deleted:        08.23.2001 23:05:39     (GMT+0)
	Direct Blocks:
	  388 0

Now we can examine the contents of block 388 and see the file
names that were in that directory:

    # dcat -f linux-ext2 -h images/hda9.dd 388 | less


-----------------------------------------------------------------------------
Brian Carrier
March 2002