Get Partition Type GUIDs from GPT
02/19/2016
GUID Partition Table (GPT) is a new disk partition system designed to replace classical DOS (a.k.a MBR) partition system. It is supported by most modern operating systems.
A GPT system starts with a legacy Master Boot Record (MBR) sector. The next sector is GPT header, followed by 32 sectors containing GPT partitiion entries. Each entry occupies 128 bytes and describes one single partition on the disk. Since a sector’s size is 512 bytes, each one can store 4 entries. Thus, the whole partition table can store at most 32 * 4 = 128 partition entries.
(By The original uploader was Kbolino at English Wikipedia [CC BY-SA 2.5 (http://creativecommons.org/licenses/by-sa/2.5)], via Wikimedia Commons)
Each partition entry starts with a 16-byte long partition type globally unique identifier (GUID). It is used to describe the type and general purpose of the partition. This can provide useful information to digital forensic examiners.
Unfortunately, the current version of the Sleuth Kit (4.1.3) does not display partition type GUIDs when processing a GPT system directly. But with a little help of other tools, it won’t be difficult to obtain such information from a disk image.
...Read moreInside Sleuth Kit 01 - Source Code Structure
02/02/2016
Since the Sleuth Kit is an open source software, we can obtain TSK’s source codes easily. Studying the source codes can help us understand more concepts in file system analysis. It will be a great experience to study inside the Sleuth Kit.
The source codes of TSK can be downloaded here.
Note the release version of TSK is in the “master” branch. The current version of TSK being developed is in the “develop” branch. I will use the master branch to explain my discovery over TSK source codes.
The tools folder stores compiled programs once you follow the instruction manual
in “INSTALL.txt” at root folder. These programs are categorized into different folders
such as fstools, vstools, hashtools. The corresponding *.cpp files are also
in these folders. These files contain the main function of each program, making
them good starting point to study the codes.
Using Sleuth Kit 05 - File listing tool
01/30/2015
Digital forensic examiners extract useful information from files. The Sleuth
Kit provides powerful tool to list files contained in a partition. This tool
is fls.
The basic format of fls is: fls [partition_image] [[inode]].
The inode value is optional.
As a simple example, suppose we want to list files in the root folder of partition image “logicalUSBraw.001”. Simply use:
$ fls logicalUSBraw.001
What if what we have is a whole disk image? Of course we can use mmcat to
extract the target partition to a new image file and proceed with fls. But an
easier method will be using the offset value of the target partition given by
the mmls tool and combining it with -o argument.
Using Sleuth Kit 04 - Misleading result of mmls
01/23/2015
As the previous post showed, mmls is a very useful tool when being used to list all partitions and unallocated space on a disk. It not only shows the starting and ending sector, but also gives the information about the type of the partition. However, this piece of information could be wrong and misleading.
In the previous example, I introduced how the mmls recognizes the type of the file system of a partition. It reads the partition table record, finds the partition type flag, then determine the partition type based on the value. But the value of this flag can be modified manually, which means the mmls tool may provide wrong information about the partition type.
Let us see an experiment. In this experiment, I created a partition on a USB drive then modified the partition table record to mislead the mmls tool. This experiment is done in OpenSUSE OS with the help of YaST2 Partitioner program.
...Read moreUsing Sleuth Kit 03 - Using Volume Analysis Tools
10/18/2014
In a previous post, I showed the basic use of
the Sleuth Kit’s volume tools mm-. An image of a FAT16 flash drive was used as example. But in order to learn
more details about volume analysis, it will be more helpful to know how these tools are used to parse partition information from the image.
In the example I mentioned above, mmls was used to display partitions of the image. The command and output are:
$ mmls physicalUSBraw.001
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 0000000511 0000000512 Unallocated
02: 00:00 0000000512 0001957887 0001957376 DOS FAT16 (0x06)
From the result we know that the partition system used in this image is DOS. How does mmls know this? It knows this from Master Boot Record (MBR), namely the “Primary Table” row in the list. MBR usually locates in the first sector of the disk. It contains lots information of how the disk is partitioned. So it will be very helpful to extract it from the image alone for further analysis. Use the following command to extract the partition table and save it in a file called “MBR”.
$ dd if=physicalUSBraw.001 of=MBR count=1
The command is straightforward. The only part that needs to be explained is an argument bs=512 is omitted because 512 is the default block size value. Thus this command uses dd and export the first 512 bytes, namely the first sector of the disk image.