File Slack & FAT Forensics: Recovering What Should Be Gone

Prerequisites

• DFA-K003: NTFS Forensics

Why This Lesson Matters

Disk forensics goes beyond NTFS and MFT. USB drives, older systems, embedded devices, and SD cards often use FAT32. And on every filesystem — NTFS or FAT — the gap between the end of a file's content and the end of its last cluster (called slack space) can contain fragments of previously deleted data. This lesson teaches you to find evidence in the spaces that most people never think to look.

1. File Slack Space

Analogy: Imagine filing a one-page letter in a manila envelope designed to hold ten pages. The extra nine pages of space are still there — and if you used that envelope before for something else, traces of those old pages might remain.

Every file on disk occupies a whole number of clusters. A cluster is the smallest allocation unit (typically 4 KB on NTFS, 32 KB on FAT32 for larger drives). If a file's content is 5,000 bytes and the cluster size is 4,096 bytes, the file occupies two clusters (8,192 bytes). The 3,192 bytes between the end of file content and the end of the second cluster = file slack.

Cluster 1: [4096 bytes of file content]
Cluster 2: [904 bytes of file content][3192 bytes of SLACK]
                                        ↑
                              May contain fragments of
                              previously deleted files

1.1 Types of Slack Space

1.2 Extracting Slack Space

# bstrings — extract strings from slack space specifically
bstrings -f disk.img -o /cases/IR-001/slack_strings.txt

# The Sleuth Kit: extract raw cluster contents including slack
blkcat -o 2048 disk.img <cluster_number>    # raw cluster content in hex
blkstat -o 2048 disk.img <cluster_number>   # cluster metadata

# Autopsy: Tools → Keyword Search → also checks slack space automatically

2. FAT32 File System Forensics

FAT32 is simpler than NTFS and found on USB drives, SD cards, older Windows volumes, and embedded systems. Understanding its structure is essential for any portable media investigation.

2.1 FAT32 Structure

[Reserved sectors: Boot Record + FSInfo]
[FAT1: File Allocation Table]
[FAT2: Backup copy of FAT1]
[Data area: clusters numbered 2, 3, 4, ...]

The File Allocation Table is a linked list. Each entry maps a cluster number to either: - The next cluster in the file's chain - 0xFFFFFFFF = end of file (EOF) - 0x00000000 = free cluster - 0xFFFFFFF7 = bad cluster

2.2 FAT32 Directory Entries

A directory entry is 32 bytes and contains:

The delete marker: When a file is deleted on FAT32, the first byte of the directory entry is replaced with 0xE5. That is the only change — the filename (bytes 1–7), size, and cluster chain remain intact. The data is recoverable until the clusters are reallocated.

# View raw directory entry for a deleted file
xxd -s <directory_offset> -l 32 disk.img
# First byte 0xE5 = deleted; reconstruct filename from bytes 1-10
# Cluster from bytes 26-27 + FAT high word; size from bytes 28-31

2.3 FAT Forensics with TSK

# List all files including deleted on a FAT32 image
fls -r -t fat32 usb.img

# Recover a deleted file (inode number from fls output)
icat -t fat32 usb.img 32 > recovered_file.pdf

# Parse the boot sector
fsstat usb.img
# Shows: cluster size, sector size, FAT copies, root cluster, etc.

3. MBR Forensics

The Master Boot Record (MBR) lives in the first 512 bytes of a disk. It contains:

Bytes 0–445:    Bootstrap code (executes at boot)
Bytes 446–509:  Partition table (4 × 16-byte entries)
Bytes 510–511:  Signature: 55 AA

Why MBR forensics matters: - Bootkits install malicious code in the bootstrap area - Deleted partitions leave traces in the MBR partition table - Data hidden after the last partition (between the last partition end and disk end) is only visible through MBR analysis

# Extract and inspect the MBR
dd if=disk.img bs=512 count=1 of=mbr.bin
xxd mbr.bin | head -32

# Parse partition table with mmls
mmls disk.img
# Check for gaps between partitions — hidden data lives in these gaps

4. Common Mistakes

Mistake 1: Skipping FAT forensics because "it's just a USB drive." USB drives contain evidence. A suspect who used a USB to exfiltrate data left a trail: file dates, directory entries, and possibly fragments in slack space.

Mistake 2: Assuming deleted = gone on FAT. The 0xE5 marker is the weakest possible deletion — the entire file structure remains intact. Recovery is often trivial until clusters are reallocated.

Mistake 3: Ignoring the space between partitions. A sophisticated attacker may hide data in the gap between the MBR and the first partition (typically sectors 1–2047 on a GPT disk, or sectors 63–2047 on an old MBR disk). Always check inter-partition space.

5. Practice Exercises

1. fls -r usb.img shows: r/r * 15: secret_docs.zip. The file is marked deleted. The image was acquired 20 minutes after the USB was connected. Is recovery likely? What command do you try?

2. fsstat usb.img shows cluster size = 32,768 bytes (32 KB). A file is 100 bytes. How much slack space does this file produce? What is the forensic significance of large cluster sizes?

3. xxd mbr.bin | head -32 shows non-zero bytes at offset 440 that do not match a known bootstrap signature. What does this suggest?

6. Lab

Assessment mode: flag

challenge_spec_id: 336 — File slack space recovery

You are given a disk image with a FAT32 partition.

Task: 1. Use fls to find the deleted file 2. Use blkcat or icat to extract the cluster including slack space 3. The flag is hidden in the slack space bytes at the end of the last cluster

7. Framework Alignment

8. Further Reading

• "File System Forensic Analysis" — Brian Carrier — FAT32 chapter is the definitive reference
• TSK fls/icat/blkcat man pages — Required reading for practical file system investigation
• FAT32 Specification (Microsoft) — https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc

["Explain what file slack space is, identify the two slack types relevant to file recovery, and use bstrings to extract string data from slack space in a disk image", "Navigate a FAT32 disk image with fls and icat, identify a deleted directory entry by its 0xE5 marker, and recover the deleted file's content", "Parse an MBR binary to identify the partition table entries and detect any anomalous data in inter-partition gaps using xxd and mmls"]

Prerequisites → Why this matters (manila envelope analogy) → File slack types and extraction → FAT32 structure (boot sector, FAT, data area) → FAT32 directory entries (32-byte structure, 0xE5 delete marker) → FAT forensics with TSK → MBR structure and forensics → Common mistakes → Practice exercises → Lab (flag, spec 336) → Framework alignment → Further reading