Table of Contents for
Practical Forensic Imaging

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Practical Forensic Imaging by Bruce Nikkel Published by No Starch Press, 2016
  2. Practical Forensic Imaging
  3. Practical Forensic Imaging
  4. Practical Forensic Imaging
  5. Practical Forensic Imaging
  6. Practical Forensic Imaging
  7. Practical Forensic Imaging
  8. Practical Forensic Imaging
  9. Practical Forensic Imaging
  10. Practical Forensic Imaging
  11. Practical Forensic Imaging
  12. Practical Forensic Imaging
  13. Practical Forensic Imaging
  14. Practical Forensic Imaging
  15. Practical Forensic Imaging
  16. Practical Forensic Imaging
  17. Practical Forensic Imaging
  18. Practical Forensic Imaging
  19. Practical Forensic Imaging
  20. Practical Forensic Imaging
  21. Practical Forensic Imaging
  22. Practical Forensic Imaging
  23. Practical Forensic Imaging
  24. Practical Forensic Imaging
  25. Practical Forensic Imaging
  26. Practical Forensic Imaging

9
EXTRACTING SUBSETS OF FORENSIC IMAGES

image

This chapter covers the selective extraction of data regions from an attached drive or a forensically acquired image file. You’ll learn to extract whole partitions, deleted or partially overwritten partitions, inter-partition gaps, and various volume and file slack areas. In addition, you’ll see how to extract special areas such as Unified Extensible Firmware Interface (UEFI) partitions, the sectors hidden by a DCO or HPA, and hibernation partitions such as Intel Rapid Start Technology.

The final sections demonstrate extraction of data from allocated and unallocated (possibly deleted) areas of the disk for further examination and manual extraction of sectors using offsets. Let’s begin with determining the partition layout of the drive.

Assess Partition Layout and Filesystems

Once you’ve attached a disk to your system or have acquired an image file, you can perform an analysis of the disk partition scheme. This section explains how to identify filesystems, partition tables, and commonly used disk partition schemes.

The disk layout, or partition scheme, refers to the method used to organize the partitions (or slices) on a hard disk. The most common partition schemes you’ll find in consumer computing are DOS, GPT, BSD, and APM (Apple Partition Map, sometimes called mac). We’ll start with identifying the partition scheme used on a disk.

Partition Scheme

Each partition or slice on a disk contains a separate filesystem or is used for some other special purpose. A small portion of the disk (often just the first sector) defines the layout of the disk by specifying the starting sector of each partition, the partition size, the partition type, labels, and so on.

To determine the disk partition scheme, you can examine the initial sectors of the disk for indicators. There is no official “Assigned Number” designation for partition schemes (there are only half a dozen or so). Don’t confuse this with DOS MBR partition types or IDs, which list up to 255 possible filesystems and other formats that could reside inside a DOS partition. When you attach the subject disk to a workstation, the Linux kernel will attempt to detect and interpret the partition scheme used, and it will create the devices for each partition it finds.

You can use the Sleuth Kit mmstat command to identify the most common partition schemes. A list of supported partition schemes is shown here:

# mmstat -t list
Supported partition types:
        dos (DOS Partition Table)
        mac (MAC Partition Map)
        bsd (BSD Disk Label)
        sun (Sun Volume Table of Contents (Solaris))
        gpt (GUID Partition Table (EFI))

Running mmstat will output the name of the scheme used:

# mmstat image.raw
dos

Alternatively, you can use the disktype tool to identify the partition scheme. The disktype tool provides more verbose information and supports partitions, filesystems, and file and archive containers. The following example shows output from disktype:

$ sudo disktype /dev/sda

--- /dev/sda
Block device, size 27.96 GiB (30016659456 bytes)
DOS/MBR partition map
Partition 1: 27.95 GiB (30015610880 bytes, 58624240 sectors from 2048)
  Type 0x83 (Linux)

You’ll find the original disktype software package at http://disktype.sourceforge.net/. Also, you’ll find a fork and multiple patches for disktype at https://github.com/kamwoods/disktype/, https://github.com/Pardus-Linux/Packages/tree/master/system/base/disktype/files/, and https://github.com/ericpaulbishop/gargoyle/tree/master/package/disktype/patches/.

A storage medium does not require a partition table or even a filesystem. Binary data can be written directly to the raw disk and accessed by any program capable of understanding it (for example, some databases can directly use raw disks). It’s possible to have disks without partition schemes. In such cases, the filesystem starts at sector zero and continues to the end of the disk (that is, the whole disk is the partition). This is common with some older USB sticks and floppy disks. In such cases, partition analysis tools will be ineffective and generally report a false or nonexistent partition table. If a tool cannot detect a partition type, it’s worth checking whether a filesystem was written directly to a raw device. In this example, mmstat finds nothing, but fsstat does identify a filesystem:

# mmls /dev/sdj
Cannot determine partition type
# disktype /dev/sdj

--- /dev/sdj
Block device, size 1.406 MiB (1474560 bytes)
FAT12 file system (hints score 5 of 5)
  Volume size 1.390 MiB (1457664 bytes, 2847 clusters of 512 bytes)

# mmstat /dev/sdj
Cannot determine partition type
# fsstat /dev/sdj
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: FAT12
...

Some encrypted volumes attempt to hide their existence or information about the filesystem used, and they don’t use a recognizable partition scheme.

Partition Tables

A partition scheme will have a disk block or set of blocks describing how it’s organized. These are called partition tables (or disklabels for BSD systems), and you can query them using various tools.

You can use the Sleuth Kit mmls command to list the partition tables on a disk or a forensically acquired image. In this example, mmls finds a regular DOS partition scheme with a FAT32 partition:

# mmls image.raw
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   0000000062   0000000063   Unallocated
02:  00:00   0000000063   0005028344   0005028282   Win95 FAT32 (0x0b)
03:  -----   0005028345   0005033951   0000005607   Unallocated

The traditional DOS partition scheme is not able to handle disks larger than 2TB. The GPT partition scheme was created to allow larger disks to be organized with a greater number of partitions. GPT supports 128 partitions compared to the 4 that DOS supports (not counting extended partitions). I have written a paper on the forensic analysis of GPT disks and GUID partition tables; you can find it here: http://dx.doi.org/10.1016/j.diin.2009.07.001.

Most new PC systems are being shipped with GPT partitions today. An example of a Windows 8 system’s partition table is shown here:

# mmls lenovo.raw
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Safety Table
01:  -----   0000000000   0000002047   0000002048   Unallocated
02:  Meta    0000000001   0000000001   0000000001   GPT Header
03:  Meta    0000000002   0000000033   0000000032   Partition Table
04:  00      0000002048   0002050047   0002048000
05:  01      0002050048   0002582527   0000532480   EFI system partition
06:  02      0002582528   0003606527   0001024000
07:  03      0003606528   0003868671   0000262144   Microsoft reserved partition
08:  04      0003868672   1902323711   1898455040   Basic data partition
09:  05      1902323712   1953523711   0051200000

Gary Kessler provides several partition table–parsing tools that provide much greater detail. You’ll find these tools at http://www.garykessler.net/software/index.html.

To illustrate the level of detail Kessler’s parsing tools provide, here is partial output from the partition table from the preceding example generated using the gptparser.pl tool:

$ gptparser.pl -i lenovo.raw

GPT Parser V1.4 beta - Gary C. Kessler (14 March 2013)

Source file = /exam/lenovo.raw
Input file length = 17408 bytes.

***** LBA 0: Protective/Legacy MBR *****

000:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
016:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
...
=== Partition Table #5 (LBA 3, bytes 0:127) ===
000-015  Partition type GUID: 0xA2-A0-D0-EB-E5-B9-33-44-87-C0-68-B6-B7-26-99-C7
         GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
         Type: Data partition (Linux *or* Windows)
016-031  Partition GUID: 0x64-12-FF-80-A7-F7-72-42-B6-46-25-33-6D-96-13-B5
         GUID: 80FF1264-F7A7-4272-B646-25336D9613B5
032-039  First LBA: 0x00-08-3B-00-00-00-00-00 [3,868,672]
040-047  Last LBA: 0xFF-27-63-71-00-00-00-00 [1,902,323,711]
048-055  Partition attributes: 0x00-00-00-00-00-00-00-00
056-127  Partition name --
056:  42 00 61 00 73 00 69 00 63 00 20 00 64 00 61 00   B.a.s.i.c. .d.a.
072:  74 00 61 00 20 00 70 00 61 00 72 00 74 00 69 00   t.a. .p.a.r.t.i.
088:  74 00 69 00 6F 00 6E 00 00 00 00 00 00 00 00 00   t.i.o.n.........
104:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
120:  00 00 00 00 00 00 00 00                           ........
      Name: Basic data partition
...

The tool provides detailed information about each of the 128 GPT partitions.

Filesystem Identification

The disktype tool, already presented in “Partition Scheme” on page 260, allows you to identify partition schemes and filesystems within partitions. The Sleuth Kit fsstat tool provides more comprehensive information about a filesystem. The fsstat tool can operate directly on a partition device or on a forensically acquired image if you specify the sector offset.

In the previous examples, the sector offset of a Windows volume on the lenovo.raw image file was 3868672. You can provide this sector offset to the fssstat tool using the -o flag to analyze the filesystem metadata:

# fsstat -o 3868672 lenovo.raw
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: 4038B39F38B39300
OEM Name: NTFS
Volume Name: Windows8_OS
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 786432
...

If the drive is directly attached to your workstation, the Linux kernel will attempt to parse the partition table and make the disk and partition devices available in /dev, where you can access them directly.

However, if you’re examining a raw image file (.raw, .ewf, and so on), there will be no device files for the image. The kernel will not interpret the partition table and will not create the familiar partition devices (/dev/sda1, /dev/sda2, and so on). You must specify an offset when accessing a partition within an image file.

It’s better to rely on forensic tools to determine the partition details rather than to trust the kernel. If a disk is corrupt or damaged, the kernel might refuse to create the partition devices or create the wrong ones. The examples you saw in this section always specified an offset rather than using the kernel. In situations that involve malware, antiforensics, or other malicious misdirection, using forensic tools instead of the kernel should take precedence.

Partition Extraction

This section describes the extraction of individual partitions, inter-partition gaps, and other areas of the disk like the DCO and HPA. Let’s begin with some basic examples of extracting regular partitions.

Extract Individual Partitions

To access and extract individual partitions rather than the entire hard disk, you can use several techniques. I’ll demonstrate a few examples of partition extraction using a directly attached drive with a partition device, a partition mapper device, and image files operated on by Sleuth Kit’s mmcat- and dd-style tools.

If a disk is accessible as an attached device, acquiring the partition is similar to performing a full acquisition with a raw drive device but uses the partition device instead. In the following example, the first partition of /dev/sda is extracted to a file:

# dcfldd if=/dev/sda1 of=partition.raw

Extracting partitions requires some capacity planning, because the partition will consume disk space (possibly alongside the full drive image). If you need only temporary access to a partition from an acquired image file, you can attach it as a loop device and access it. The following steps demonstrate this method.

First, use the mmls tool to identify the partition to be attached as a loop, as follows:

# mmls lenovo.raw
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors
...
05:  01      0002050048   0002582527   0000532480   EFI system partition
...

Then use Bash math expansion to convert the sector offset and sector length into a byte offset and byte length:

# echo $((2050048*512))
1049624576
# echo $((532480*512))
272629760

The calculated byte offset and byte length are then passed to losetup to create a loop device, as follows:

# losetup --read-only --find --show --offset 1049624576 --sizelimit 272629760
    lenovo.raw
/dev/loop2

You can access this resulting loop device using forensic tools in the same way as you access the partition device of an attached disk. An example using Sleuth Kit fls is shown here:

# fls /dev/loop2
r/r 3:  SYSTEM_DRV (Volume Label Entry)
d/d 4:  EFI
d/d 5:  BOOT
d/d * 7:        MSIa11f8.tmp
d/d * 8:        _SI2DBB4.TMP
d/d * 9:        _190875_
...

If you need to extract a partition from an existing acquired image into a separate file, you can use the dd tools or the Sleuth Kit mmcat command.

To extract a partition from an acquired image, the initial step is to identify the partition and sector details. In the following example, the partition table from an acquired disk image shows the partition to be extracted:

# mmls image.raw
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
...
02:  00:00   0000000063   0078124094   0078124032   Linux (0x83)
...

Extracting a partition from an already acquired image file using dcfldd or dd requires adding skip (dc3dd uses iskip) and count parameters, which cause the command to jump (skip) ahead to the start of the partition and acquire only the size of the partition:

$ dcfldd if=image.raw of=partition.raw bs=512 skip=63 count=78124032

In this command, the block size is set to 512 bytes to match the sector size, the start of the partition is at sector 63, and 78124032 sectors should be extracted. With a little additional calculation, you can improve the performance of this command by changing the 512-byte block size to something larger (but don’t forget to adjust the skip and count parameters if you do this).

With Sleuth Kit version 3.0 and later, you can use the mmcat tool to easily extract partitions. To recover the first partition in the previous example using mmcat, you must specify the mmls slot number (not the DOS partition number). In this case, the first partition is located in the mmls slot number two and can be extracted as follows:

$ mmcat image.raw 2 > partition.raw

The mmcat tool simply pipes the output to stdout, so you must either redirect it to a file or pipe it into a program.

Find and Extract Deleted Partitions

To exhaustively search for partially overwritten or deleted partitions of a forensically acquired image, you can use several methods. Sleuth Kit provides a basic tool called sigfind to search for binary signature strings. Two useful tools for comprehensive partition searching are gpart and testdisk. These tools implement filesystem recognition algorithms with more intelligent guessing to identify lost partitions.

Running gpart without any options starts a scan for partitions, skipping over areas identified as allocated. For example:

# gpart lenovo.raw

Begin scan...
Possible partition(Windows NT/W2K FS), size(1000mb), offset(1mb)
Possible partition(Windows NT/W2K FS), size(3mb), offset(1030mb)
Possible partition(Windows NT/W2K FS), size(3mb), offset(1494mb)
Possible partition(Windows NT/W2K FS), size(926980mb), offset(1889mb)
Possible partition(Windows NT/W2K FS), size(25000mb), offset(928869mb)
End scan.
...
Guessed primary partition table:
Primary partition(1)
   type: 007(0x07)(OS/2 HPFS, NTFS, QNX or Advanced UNIX)
   size: 1000mb #s(2048000) s(2048-2050047)
   chs:  (0/32/33)-(406/60/28)d (0/32/33)-(406/60/28)r
...

Adding a -f flag tells gpart to be exhaustive, looking for partitions in every sector of the entire disk, even in areas where no partitions are expected to be found. This will take much longer than the default gpart scan without flags.

The testdisk tool (http://www.cgsecurity.org/, written by Christophe Grenier, who also wrote the photorec carving tool) provides several features in addition to partition searching. Testdisk provides an interactive interface, supports multiple disk layouts (DOS, GPT, BSD, and more), detects several dozen partition types, generates activity logs, and can extract discovered partitions to a file. You can use testdisk on devices, raw image files, and even *.e01 files.

Use the testdisk tool with caution. This tool was designed for repairing and recovering partitions, and it could easily modify evidence. Be sure to use a write blocker before running this tool on attached subject disks.

Also included with the tool is a comprehensive user interactive menu system to define options and activities. Shown here is a batch mode example operating on an attached disk:

# testdisk /list /dev/sdb
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Please wait...
Disk /dev/sdb - 15 GB / 14 GiB - CHS 14663 64 32
Sector size:512
Model: SanDisk Ultra Fit, FW:1.00

Disk /dev/sdb - 15 GB / 14 GiB - CHS 14663 64 32
     Partition                  Start        End    Size in sectors
 1 P FAT32 LBA                0   1  1 14663  44 18   30031218 [NO NAME]
     FAT32, blocksize=16384

You can perform a certain amount of manual analysis to search for deleted partitions. If the partition table shows a large area of unallocated space on a disk, check this area to determine whether a partition exists. In the following example, mmls shows nearly 2.5GB (4863378 sectors) of empty space at the end of a thumb drive:

# mmls /dev/sdb
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0025167871   0025165824   Win95 FAT32 (0x0c)
003:  -------   0025167872   0030031249   0004863378   Unallocated

This unallocated space could be a deleted partition. In this example, running fsstat using the offset of the empty space discovers a valid filesystem:

# fsstat -o 25167872 /dev/sdb
FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: Ext3
Volume Name:
Volume ID: 74a2f1b777ae52bc9748c3dbca837a80

Last Written at: 2016-05-21 15:42:54 (CEST)
Last Checked at: 2016-05-21 15:42:54 (CEST)
...

If you detect a valid filesystem, you can use the meta information about it to determine the probable size of the partition. Knowing the size and starting offset, you can extract the discovered partition or further analyze it. You can extract it using dd-style tools or more easily with mmcat, like this:

# mmcat /dev/sdb 3 > deleted_partition.raw

Here, the mmcat output of the deleted partition discovered in mmls slot 003 is sent to a file called deleted_partition.raw.

Identify and Extract Inter-Partition Gaps

In some cases, there may be gaps between partitions that were created accidentally or due to adjacent partitions meeting on cylinder or block boundaries. There could also be intentional gaps that were created for hiding data. You can identify and recover these inter-partition gaps in the same way as you extract a partition. Use mmls to determine the size and sector offset of the gap, and then use dd or mmcat to extract it.

The mmls output of a partition table is shown here. The disk contains two partitions, and there is a gap between them:

# mmls /dev/sdb
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

      Slot      Start        End          Length       Description
000:  Meta      0000000000   0000000000   0000000001   Primary Table (#0)
001:  -------   0000000000   0000002047   0000002048   Unallocated
002:  000:000   0000002048   0015626236   0015624189   Linux (0x83)
003:  -------   0015626237   0015626239   0000000003   Unallocated
004:  000:001   0015626240   0030031249   0014405010   Linux (0x83)

In this example, the first partition ends on sector 15626236, but the adjacent partition starts on sector 15626240, indicating a three-sector gap between them. Although you can extract this inter-partition gap using dd, using mmcat is simpler:

# mmcat /dev/sdb 3 > gap.raw
# ls -l gap.raw
-rw-r----- 1 root root 1536 May 21 16:11 gap.raw

The resulting file is three sectors in size with the contents of the gap between the two partitions. Larger gaps between partitions that contain partially overwritten, corrupted, or identifiable filesystem fragments can be analyzed with carving tools such as foremost.

The gap between the last partition and the end of a disk can also be of interest. It may contain artifacts such as content from previously overwritten partitions, backup copies of the GPT partition, or even malware attempting to hide segments of binary code.

Extract HPA and DCO Sector Ranges

You have already learned how to identify and remove HPA and DCO restrictions. Once removed, these areas of the disk can be extracted for separate analysis.

In this example, hdparm shows that an HPA exists, and the mmls output shows three slots, one of them being a Linux partition:

# hdparm -N /dev/sdh

/dev/sdh:
 max sectors   = 234441648/976773168, HPA is enabled
# mmls /dev/sdh
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   0000002047   0000002048   Unallocated
02:  00:00   0000002048   0234441647   0234439600   Linux (0x83)

After you successfully remove the HPA (and tell the kernel to rescan the SCSI bus), running the same commands again produces different output, as shown here:

# hdparm -N p976773168 /dev/sdh

/dev/sdh:
 setting max visible sectors to 976773168 (permanent)
 max sectors   = 976773168/976773168, HPA is disabled
# mmls /dev/sdh
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   0000002047   0000002048   Unallocated
02:  00:00   0000002048   0234441647   0234439600   Linux (0x83)
03:  -----   0234441648   0976773167   0742331520   Unallocated

Now, hdparm indicates the HPA is disabled, and the mmls output shows an additional line of output (slot 03) representing the sectors previously hidden by the HPA.

Using the mmcat command with partition slot 03 will extract the data from HPA, as follows:

# mmcat /dev/sdh 3 > hpa.raw

This example uses a live disk attached to an acquisition host. When an image file is acquired from a disk with the HPA removed, mmls will see this hidden region.

Extracting sectors hidden by a DCO is identical to the method shown here with the HPA. First use hdparm to expose the DCO-protected sectors, and then extract them using dd or mmcat. This procedure does not need to be repeated with additional examples specifically demonstrating sectors from a DCO.

Other Piecewise Data Extraction

In this final section, I describe various additional examples of piecewise data extraction. The contents of this section (in fact the contents of most of this chapter) blur together slightly with forensic filesystem analysis, which is not the intended scope of the book. For this reason, the examples are slightly less descriptive.

Extract Filesystem Slack Space

Slack space is a traditional digital forensics concept referring to allocated but unused data at the end of disk sectors, filesystem blocks, or filesystems (RAM slack, file slack, and partition slack, respectively).

To visualize slack space, imagine this book as a hard disk, where paragraphs are sectors, chapters are files, and body of the text is the partition. Notice that paragraphs don’t finish exactly at the end of a line, chapters don’t finish exactly at the end of a page, and the end of the book might have a couple of additional blank pages. These empty spaces are the book’s “slack space.” With storage media, if the OS or physical drive has not explicitly written zeros to these areas, they might still contain data from previously written files.

Historically, extracting and analyzing slack space has been useful in forensic investigations. However, the value of slack space is beginning to decrease due to several factors:

• SSDs are using TRIM commands to zero unallocated blocks.

• Modern OSes are writing back zeros to unused portions of sectors and blocks.

• Disks with native 4K sectors align with filesystem block sizes.

• OSes create partitions and filesystems aligned to block boundaries.

As part of the forensic process, acquiring and analyzing potential slack areas are still diligent steps to complete.

To extract all slack space on a given image, you can use the Sleuth Kit blkls command. Slack space is filesystem specific, so you must extract slack space on each filesystem separately (you can’t just use the entire raw disk). In this example, the filesystem offsets of the acquired image are found with mmls, and the slack space of each one is extracted:

# mmls lenovo.raw
GUID Partition Table (EFI)
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
04:  00      0000002048   0002050047   0002048000
05:  01      0002050048   0002582527   0000532480   EFI system partition
06:  02      0002582528   0003606527   0001024000
...
08:  04      0003868672   1902323711   1898455040   Basic data partition
...
# blkls -o 2048 -s lenovo.raw > slack.04
# blkls -o 2050048 -s lenovo.raw > slack.05
# blkls -o 2582528 -s lenovo.raw > slack.06
# blkls -o 3868672 -s lenovo.raw > slack.08

The slack space for each recognized filesystem is saved to a file. The blkls command’s -s flag extracts all slack space (and only slack space). It is important to understand that slack space does not refer to unallocated blocks or sectors. Slack space is the unused area found within allocated blocks and sectors of a filesystem.

Extract Filesystem Unallocated Blocks

This next example will gather all unallocated blocks from filesystems on an acquired image. Unallocated blocks are filesystem specific, so you need to perform this operation separately on each recognized filesystem.

Here, the mmls command is again used to determine the offsets of each filesystem, and the blkls command is used to extract unallocated blocks:

# blkls -o 2048 lenovo.raw > unalloc.04
# blkls -o 2050048 lenovo.raw > unalloc.05
# blkls -o 2582528 lenovo.raw > unalloc.06
# blkls -o 3868672 lenovo.raw > unalloc.08

The correct blkls flag for extracting unallocated blocks is -A, but because it’s the default command behavior, you can omit it.

You can also perform the inverse action of extracting all (and only) allocated blocks using the blkls -a command.

Manual Extraction Using Offsets

In certain situations, you might use a hex editor to browse, search, or manually analyze the contents of a disk or acquired disk image. The hex editor may provide a byte offset, a sector offset, or both.

This example uses the console-based hexedit tool to analyze a disk:

# hexedit -s /dev/sda

The hexedit tool allows you to directly edit block device files and edit very large image files (no loading in memory or temp files), and it provides a sector mode (entire sectors and sector offsets are shown).

In the following example, the sector offset is 2048 (the start of an NTFS partition), the byte offset is 0x100181, and the entire sector is shown (note: hexedit assumes 512-byte sectors):

00100000   EB 52 90 4E 54 46 53 20  20 20 20 00 02 08 00 00  .R.NTFS    .....
00100010   00 00 00 00 00 F8 00 00  3F 00 FF 00 00 08 00 00  ........?.......
00100020   00 00 00 00 80 00 80 00  01 48 00 00 00 00 00 00  .........H......
00100030   04 00 00 00 00 00 00 00  80 04 00 00 00 00 00 00  ................
00100040   F6 00 00 00 01 00 00 00  22 90 FD 7E 2E 42 12 09  ........"..~.B..
00100050   00 00 00 00 FA 33 C0 8E  D0 BC 00 7C FB 68 C0 07  .....3.....|.h..
00100060   1F 1E 68 66 00 CB 88 16  0E 00 66 81 3E 03 00 4E  ..hf......f.>..N
00100070   54 46 53 75 15 B4 41 BB  AA 55 CD 13 72 0C 81 FB  TFSu..A..U..r...
00100080   55 AA 75 06 F7 C1 01 00  75 03 E9 D2 00 1E 83 EC  U.u.....u.......
00100090   18 68 1A 00 B4 48 8A 16  0E 00 8B F4 16 1F CD 13  .h...H..........
001000A0   9F 83 C4 18 9E 58 1F 72  E1 3B 06 0B 00 75 DB A3  .....X.r.;...u..
001000B0   0F 00 C1 2E 0F 00 04 1E  5A 33 DB B9 00 20 2B C8  ........Z3... +.
001000C0   66 FF 06 11 00 03 16 0F  00 8E C2 FF 06 16 00 E8  f...............
001000D0   40 00 2B C8 77 EF B8 00  BB CD 1A 66 23 C0 75 2D  @.+.w......f#.u-
001000E0   66 81 FB 54 43 50 41 75  24 81 F9 02 01 72 1E 16  f..TCPAu$....r..
001000F0   68 07 BB 16 68 70 0E 16  68 09 00 66 53 66 53 66  h...hp..h..fSfSf
00100100   55 16 16 16 68 B8 01 66  61 0E 07 CD 1A E9 6A 01  U...h..fa.....j.
00100110   90 90 66 60 1E 06 66 A1  11 00 66 03 06 1C 00 1E  ..f`..f...f.....
00100120   66 68 00 00 00 00 66 50  06 53 68 01 00 68 10 00  fh....fP.Sh..h..
00100130   B4 42 8A 16 0E 00 16 1F  8B F4 CD 13 66 59 5B 5A  .B..........fY[Z
00100140   66 59 66 59 1F 0F 82 16  00 66 FF 06 11 00 03 16  fYfY.....f......
00100150   0F 00 8E C2 FF 0E 16 00  75 BC 07 1F 66 61 C3 A0  ........u...fa..
00100160   F8 01 E8 08 00 A0 FB 01  E8 02 00 EB FE B4 01 8B  ................
00100170   F0 AC 3C 00 74 09 B4 0E  BB 07 00 CD 10 EB F2 C3  ..<.t...........
00100180   0D 0A 41 20 64 69 73 6B  20 72 65 61 64 20 65 72  ..A disk read er
00100190   72 6F 72 20 6F 63 63 75  72 72 65 64 00 0D 0A 42  ror occurred...B
001001A0   4F 4F 54 4D 47 52 20 69  73 20 6D 69 73 73 69 6E  OOTMGR is missin
001001B0   67 00 0D 0A 42 4F 4F 54  4D 47 52 20 69 73 20 63  g...BOOTMGR is c
001001C0   6F 6D 70 72 65 73 73 65  64 00 0D 0A 50 72 65 73  ompressed...Pres
001001D0   73 20 43 74 72 6C 2B 41  6C 74 2B 44 65 6C 20 74  s Ctrl+Alt+Del t
001001E0   6F 20 72 65 73 74 61 72  74 0D 0A 00 00 00 00 00  o restart.......
001001F0   00 00 00 00 00 00 00 00  80 9D B2 CA 00 00 55 AA  ..............U.

---  sda       --0x100181/0x6FD21E000--sector 2048---------------------------

From the byte or sector offset, you can construct dd commands to extract what was found within the hex editor.

The following example uses a sector size of 512, a sector offset, and a sector count to extract a range of data (four 512-byte sectors) from an image:

# dd if=/dev/sda of=sectors.raw skip=2048 bs=512 count=4

The next example extracts the same range of data using byte offsets. The skip command uses Bash math expansion to convert hexadecimal into decimal, which is needed for dd; the block size is 1 byte; and the count is the number of bytes required.

# dd if=/dev/sda of=bytes.raw skip=$((0x100000)) bs=1 count=2048

The two previous examples extract the same block (four sectors or 2048 bytes) of data. Note that when extracting regions of a disk, it is sensible to ensure you have sector- or block-aligned offsets (that is, multiples of the sector size or block size).

In cases in which you need to extract a range of filesystem blocks, use the Sleuth Kit blkcat command. The following example extracts 25 blocks from a filesystem starting at block 100:

# blkcat /dev/sda1 100 25 > blocks.raw

The filesystem block size should be detected by the tool.

The examples in this final section showed how you can access images; use offsets; and extract a range of bytes, sectors, or blocks. You can also use other Sleuth Kit commands to map sectors to blocks and map blocks to inodes and filenames. These tasks are filesystem specific and move into the realm of filesystem forensic analysis.

Closing Thoughts

In this final chapter, you learned how to extract subsets of drives and forensic images. The chapter focused on extracting various portions of an image such as sectors hidden by an HPA or DCO, deleted partitions, and inter-partition gaps. You also saw the manual extraction of specified sectors and blocks, including unallocated blocks and slack space. This chapter bordered on forensic analysis, as it looked at identifying partition schemes, understanding partition tables, and identifying filesystems. Since this book is about forensic acquisition and not forensic analysis, it is a fitting final chapter.