The Sleuth Kit Informer Issue 18
http://www.sleuthkit.org/informer
http://sleuthkit.sourceforge.net/informer
Brian Carrier
carrier at sleuthkit dot org
Issue #18
January 15, 2005
Contents
- Introduction
- What's New?
- Call For Papers
- Description of the FAT fsstat Output
Introduction
This 18th issue of The Informer provides a detailed description of the fsstat tool in The Sleuth Kit (TSK). The purpose of this article and future ones like it is to better document some of the TSK tools, especially those that provide large amounts of information. This article is about fsstat and the FAT file system and future articles will describe other tools and file systems.
To reduce the amount of time it takes for me to write The Informer and to devote more times to the actual tools, I am starting to publish this only in HTML and stop the ASCII format.
What's New?
I have been busy working on the long awaited TSKv2. The major addition is the introduction of an "image layer" that allows multiple image formats to be used. That means that the new tools can use disk images or partition images and the images can be in one file or split among several. There are plans to also support other forensic tool formats, RAID, and compressed images. The v2 tools can now autodetect the file system or partition type (which means you can now skip the '-f' switch). There were also many internal design changes that are not noticeable from the outside.
I am also updating Autopsy to reflect the new image support and the the process for importing images is more automated. While I am working on the Case Management features, I am looking for suggestions and comments about the existing system so that I can make changes now. One of the new features will be a "Recents" list on the opening page so that you can skip the Case and Host screens.
Call For Papers
The Sleuth Kit Informer is looking for articles on open source tools and techniques for digital investigations (computer / digital forensics) and incident response. Articles that discuss The Sleuth Kit and Autopsy are appreciated, but not required. Example topics include (but are not limited to):
- Tutorials on open source tools
- User experiences and reviews of open source tools
- New investigation techniques using open source tools
- Open source tool testing results
http://www.sleuthkit.org/informer/cfp.html
Description of the FAT fsstat Output
Overview
The output of many TSK tools is relatively easy to understand because each tool has a specific focus. For example, the outut of fls is a list of file names and corresponding inode addresses. There are two tools, fsstat and istat, which contain a lot of information and the type of information varies by file system. These tools provide the details of a metadata structure or file system, respectively.
This article covers the output of the fsstat command when run on a FAT file system. The fsstat command gives the general information about a file system. This information is typically located in the boot sector or superblock of a file system and does not apply to any specific file or directory. Examples of the information in these data structures are the size of the data units, the number of data units in the file system, and the number of metadata structures. When using Autopsy, this information is shown under the Image Details tab.
The fsstat output is broken up into sections and each file system type has a different number of sections. The FAT output has four sections and the first three are based on the file system, content, and metadata categories of the basic file system model that I use. The last section of the output contains a graphical representation of the file allocation table.
FAT Basics
Before we look at the fsstat output, we will briefly cover some of the basics of the FAT file system. This is not an extensive description of FAT and is intended only as a review. For more details, refer to the FAT specification [1] (or wait until File System Forensic Analysis [2] is released in March :) ).
The first sector of a FAT file system contains the boot sector data structure, where the basic administrative information can be found. This data structure describes the layout of the file system. Following the boot sector is the first file allocation table structure (FAT). The FAT is used to determine the next cluster in a file and is used to determine which clusters are not being used. In FAT12/16 the FAT immediately follows the boot sector, but in FAT32 there are reserved sectors in between. A backup FAT typically follows the first FAT.
After the last FAT, is the start of the Data Area, which is where the directory and file contents are stored. The layout of the Data Area is different for FAT12/16 and FAT32. With FAT12/16 the sector after the last FAT is the beginning of the root directory, which has a fixed size. After the root directory is the first cluster, which is given an address of 2 (there are no clusters 0 and 1). With FAT32, cluster 2 starts in the sector following the last FAT. The FAT32 root directory can start anywhere in the Data Area. The Data Area extends until the end of the file system.
File and directory content are stored in clusters, which are groups of consecutive sectors. As I previously stated, the first cluster is located dozens or hundreds of sectors into the file system after the boot sector and FATs. TSK does not use cluster addresses in its output because it is too confusing. If TSK were to use clusters, then it would need two different addressing schemes. If you wanted to examine the data in the FAT, you would need to use its sector address. if you wanted to examine the data in a file's contents, you would need to use a cluster address. TSK simplifies this by showing and using only the sector addresses (even if the file system stored the address as a cluster address).
Sample Output
I will now go through the output from an example FAT32 image. The output for a FAT12/16 file system is slightly different from a FAT32 image because it has a different layout. The output of this command is from the new TSK version 2.00, which is slightly different from version 1.73.
# fsstat -o 63 disk-1.dd
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT32The above line represents what file system type TSK thinks the image is. It determines this using the algorithm given in the specification, which is based on the total number of clusters.
OEM Name: MSDOS5.0
Volume ID: 0x6c2e5cb8The boot sector contains several labels that were created when the file system was formatted. The above OEM name is typically based on which OS or application formatted the file system. Another common name is "MSWIN..". The Volume ID is assigned by the creating application and should be based on the time of creation [3], but I have not always found this to be the case.
Volume Label (Boot Sector): NO NAME
Volume Label (Root Directory): FAT-VOLUMEA user can assign a volume label to a file system and there are two locations where it can be stored. One location is in the boot sector and the other is in a special entry in the root directory. I have found that Windows XP will store the label in only the root directory, as can be seen above. The boot sector has the name "NO NAME" and the root directory value contains the actual name "FAT-VOLUME". Refer to DFTT Test #9 for an example how a file was hidden using the special volume label[4].
File System Type Label: FAT32The boot sector contains a label for the file system type, but it is not really used and does not need to be correct. In this case it is correct, but the FAT spec gives an algorithm that should be used to determine the actual type (which was given in the first line of the output).
Next Free Sector (FS Info): 173952
Free Sector Count (FS Info): 61258528The two values shown above are only in a FAT32 file system. They give the next cluster that can be allocated and how many free clusters exist (TSK has converted them to sector values).
Sectors before file system: 63The above value shows how many sectors that may exist before the file system. This typically corresponds to the offset of the partition in which the file system is located. In this case, the file system is in the first partition of the disk and in sector 63.
The next set of information contains the layout of the file system. The stars on the left are used to describe the hierarchy. Lines with '**' are located inside of the previous range with a '*'. Because the data area layout is different for FAT12/16 versus FAT32, the output is slightly different for a FAT12/16 file system.
File System Layout (in sectors)
Total Range: 0 - 61432496
* Reserved: 0 - 33
** Boot Sector: 0
** FS Info Sector: 1
** Backup Boot Sector: 6The above lines show us that there are 61,432,497 sectors in the file system and 0 to 33 are in the reserved area (which is the area before the start of the first FAT). The original boot sector is in sector 0 and the backup is in sector 6. The FS Info data structure is unique to FAT32 and contains information about the next available cluster and number of free clusters.
* FAT 0: 34 - 15024
* FAT 1: 15025 - 30015This file system has a primary and backup FAT and the sector ranges are given in the above output.
* Data Area: 30016 - 61432496
** Cluster Area: 30016 - 61432479
*** Root Directory: 30016 - 30047
** Non-clustered: 61432480 - 61432496After the second FAT is the start of the Data Area. This is FAT32, so the first cluster starts in the first sector of the Data Area, which is sector 30,016. The size of the Data Area is not a multiple of the cluster size and therefore there are 17 sectors at the end of the Data Area that are not allocated to a cluster (because we will later see that each cluster is 32 sectors). The FAT32 root directory can be located anywhere in the file system and its location is given in the above output.
METADATA INFORMATION
--------------------------------------------
Range: 2 - 982439426
Root Directory: 2The above output is the second major section in the fsstat output and it contains the metadata-related information. The FAT file system does not assign addresses to its metadata structures, which it calls directory entries, so TSK must create its own addressing scheme. The above output shows the valid range of addresses. These are the addresses that you would use with the icat or istat tools. The maximum address is based on the total number of sectors in the file system. In this case, the valid range is 2 to 982,439,426 and the root directory has been assigned an address of 2.
CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 16384
Total Cluster Range: 2 - 1918828The above output is the third major section in the fsstat output and it contains general content-related information. We see that the sector size is 512 bytes and that each cluster is 16KB. The total cluster range is also given, even though TSK shows all addresses in sectors.
FAT CONTENTS (in sectors)
--------------------------------------------
30016-30047 (32) -> EOF
[...]
30176-30303 (128) -> EOF
30304-30335 (32) -> EOF
30336-30367 (32) -> 85984
30368-30399 (32) -> EOF
[...]
85984-86015 (32) -> 133920
[...]
133920-133951 (32) -> 146304
[...]The above output is the fourth major section of the fsstat output and it continues for many more pages. It is a graphical representation of the primary FAT structure. Each line corresponds to a "cluster run". The FAT structure contains a pointer to the next cluster in the file. The first line in the output is for cluster 2. We know this because there is no cluster 0 or 1 and we saw in the layout that the first sector with a cluster is sector 30,016. We also know that each cluster is 32 sectors in size (which is the length of the first run). Therefore cluster 2 has been allocated to a file and it does not point to any other clusters, which means it is the last cluster in the file.
The third line shows that a file has allocated four consecutive clusters and we see a run with 128 sectors. There should be four separate entries, but TSK will group them together if an entry points to the next consecutive cluster. The fifth line shows a run for a file that was not able to allocate consecutive clusters. We can see that after it allocated the cluster in sectors 30,336 to 30,367 that it allocated the cluster that starts in sector 85,984. If we jump to the FAT entry for that cluster then we see that it again jumps to the cluster in sector 133,920. This repeats for several more jumps. If a cluster is not allocated then it will not have an entry in the fsstat output.
Conclusion
For basic investigations only some of the information in the fsstat output may be needed. But, it provides a wealth of information if you are looking for hidden data, recovering deleted files, or verifying your results. Future issues will cover the fsstat output for other file systems.
References
- [1] Microsoft FAT32 File System Specification. Available at: http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx
- [2] Brian Carrier. File System Forensic Analysis. Available at: http://www.digital-evidence.org/fsfa/
- [3] Craig Wilson. Volume Serial Numbers & Format Verification Date/Time. Digital Detective White Paper. Available at: http://www.digital-detective.co.uk/documents/Volume%20Serial%20Numbers.pdf
- [4] Brian Carrier. Digital Forensic Tool Testing Image #9 - FAT Volume Label Test #1. Available at: http://dftt.sourceforge.net/test9/index.html
Copyright © 2005 by Brian Carrier. All Rights Reserved
