Skip to content

Recovering file slack from a disk image

The bytes past a file's logical end, inside its last cluster, where fragments of older deleted files survive. How slack works and how to extract it.

Published on 4 min read

Filesystems do not hand out bytes. They hand out clusters. A cluster is the smallest unit a filesystem will allocate, commonly 4 KiB, and a file gets a whole number of them no matter how little data it actually holds. Write 100 bytes and you still own all 4096 in that last cluster. The 3996 bytes past your data are yours on disk and meaningless to your file.

That leftover is file slack, and it is one of the more reliable places to find data nobody meant to leave behind.

Why there is anything in there at all

The operating system does not scrub a cluster before reusing it. When a 4 KiB cluster that used to hold part of a deleted file gets handed to a new 100-byte file, the new file's data overwrites the first 100 bytes. The other 3996 are still whatever the previous occupant wrote. The filesystem has no reason to touch them, because as far as it is concerned that space is not in use, it is just part of a cluster that happens to belong to a small file now.

So slack accumulates history. The back half of a deleted Word document. An old log line. The tail of an image that got replaced by a smaller text file. It is not a copy of the deleted file, it is whatever fragment landed in that particular cluster, but fragments are often enough.

Concretely: cluster size 4096, a file of 700 bytes. The file occupies one cluster. Bytes 0 through 699 are the file. Bytes 700 through 4095 are slack, 3396 bytes of it, and on a disk that has seen real use those bytes are rarely zero.

RAM slack versus drive slack, and why the distinction is mostly historical

Old writeups split slack into two regions and the split still shows up in tooling, so it is worth knowing.

Sectors are 512 bytes (or 4096 on newer drives). A file's logical end almost never lands exactly on a sector boundary, so there is a small gap from the end of the data to the end of that sector. That is RAM slack. On DOS and early Windows the OS padded it with whatever was sitting in memory at the time, which occasionally leaked genuinely interesting things. Modern systems zero it, so RAM slack is usually a dead region now.

Drive slack is the rest: the full sectors between the file's last sector and the end of the cluster. Nobody pads these. They are simply not written, so the previous content sits there intact. This is the part you actually care about.

In practice you extract the whole tail, from the file's logical end to the end of its last cluster, and look at it. The RAM-slack subtlety only matters when you are reasoning about why the first few bytes are zeros and the rest is not.

The cases where slack does not exist

Two of them, and both trip people up.

A file sized to an exact multiple of the cluster size has no slack. An 8192-byte file on 4 KiB clusters fills two clusters exactly. There is no tail. This is rare by accident and common with files that were padded on purpose.

And on NTFS, small files have no cluster slack at all, because they have no clusters. When a file's data fits inside its MFT record, NTFS stores it resident, right there in the 1 KiB record, and never allocates a cluster for it. No cluster, no slack. The parser knows this and returns nothing for resident files rather than handing you garbage from an unrelated cluster. Compressed $DATA is skipped too, because the tail of a compression unit is not plaintext and pretending otherwise would be misleading.

Pulling it out

Extraction is mechanical once you have the file's cluster layout. Find the last cluster the file occupies, work out where the logical data ends inside it, and read from there to the end of the cluster.

The parser does this per file on NTFS, FAT, exFAT, ext, and HFS+. Select a file, and alongside the normal export there is a slack extraction that hands you exactly those trailing bytes. On a 700-byte file in a 4 KiB volume you get 3396 bytes back; on a file that fills its clusters you get nothing, correctly.

Slack is the natural companion to carving the free space. Unallocated clusters are the big surface, the clusters the filesystem has fully released. Slack is the small surface hiding inside clusters that are still in use. An examiner who carves one and not the other is leaving data on the table. Run both.

Open an image and extract some slack.

Related articles

How deleted files survive in unallocated clusters, how to pull them out by signature, and the reasons (TRIM, fragmentation) the data often is not there.
Detect filesystems from the superblock instead of trusting the partition type byte. Magic numbers, the offsets that trip people up, and faking it.
What actually replaces FTK Imager for browsing and exporting from a disk image, where the browser wins, and where you still need the real thing.