Carve deleted data from unallocated space

When a file gets deleted, the data does not go anywhere. On NTFS the record's in-use flag flips and its clusters get marked free in the $Bitmap. On FAT the directory entry's first byte becomes 0xE5 and its cluster chain is zeroed in the table. In both cases the bytes that made up the file are still sitting in those clusters. Nothing wiped them. They are just no longer spoken for.

That window, between "marked free" and "overwritten by something else," is where deleted-file recovery happens. And once the metadata that pointed at the file is gone, you cannot follow a directory entry to it anymore. You have to find it by what it looks like. That is carving.

Why you carve the free space specifically, not the whole image

You could run a signature scan across the entire image. It works and it is also a waste, because most of the image is allocated files you can already browse and export normally through the filesystem. Re-discovering them by carving gives you worse versions of files you already have, with no names and no timestamps.

The interesting surface is unallocated space: the clusters the filesystem says are free. Those hold the deleted data and nothing you can reach any other way. So the first move is to isolate them.

This is exactly why the parser exposes a [unallocated space] node per volume. It reads the allocation structure (the $Bitmap on NTFS, the FAT table on FAT, the allocation bitmap on exFAT, the block-group bitmaps on ext, the Allocation File on HFS+) and concatenates every free cluster into one stream. You carve that, not the disk. Same surface FTK Imager hands you, minus the install.

How the scan actually works

Carving is pattern matching with a bit of format knowledge. You scan the bytes for known headers and pull from there.

A JPEG starts with FF D8 FF. A PNG with 89 50 4E 47. A PDF with %PDF and, helpfully, ends with %%EOF, so you can carve it exactly. ZIP and every Office document built on ZIP start with the local file header 50 4B 03 04. GZIP is 1F 8B. SQLite databases begin with the string SQLite format 3. The parser's carver knows a couple dozen of these and recovers them from any byte range you point it at.

The exactness varies by format. PDF, PNG, and ZIP carry footers or length fields, so the extracted file is byte-exact. A raw JPEG without a clean end marker, or a format with no terminator, gets carved to the next header it finds, which overshoots. You take the overshoot because a slightly-too-long JPEG still opens.

The two reasons it does not work, and they are common

First, fragmentation. Carving assumes a file lives in one contiguous run from header to footer. The filesystem makes no such promise. A document written in pieces across a busy volume ends up scattered, and a carve grabs the header plus whatever physically follows it on disk, which is some other file's data. You get a recognizable header and a corrupt body. Sometimes that is enough to prove a file of that type existed. Often it is not enough to read it.

Second, and this is the one that surprises people: the data is frequently just gone. Modern SSDs run TRIM. When the OS deletes a file, it tells the drive those blocks are free, and the controller zeroes them, usually within seconds, as part of garbage collection. So on a TRIM-enabled SSD, unallocated space carving comes back empty, not because the tool failed but because there is nothing there. This is why a deleted file is often recoverable from a 2015 laptop's spinning disk and not from last year's NVMe. If your unallocated space is a sea of zeros, that is the finding. Record it and move on.

There are edges. TRIM gets disabled on some RAID configurations and older OS-plus-drive combinations. External USB enclosures historically did not pass TRIM through. So it is worth carving even an SSD image, just do not be shocked when it is dry.

After the free space, check the slack

Unallocated clusters are the obvious place. The less obvious one is the tail of files that are still alive. When a small file lands in a cluster that a larger deleted file used to occupy, the new file's data sits at the front and the old file's bytes survive in the gap. That gap is file slack, and it is a separate carving surface worth a look once the free space is exhausted.

To run this yourself: open the image, let it identify the filesystem, extract the [unallocated space] node, and carve it. Start here.