Chapter 4 — Key Takeaways
The big idea
A file's content, its metadata, and its directory name are stored in three separate structures — so deletion almost never erases all three at once. A file system maps names to locations, tracks free space, holds metadata, and protects integrity (journaling or copy-on-write). When you delete, the system does the cheapest thing: it severs the links between those structures and marks the space free, leaving the data physically in place until something overwrites it. Deleted ≠ destroyed is therefore universal — but the size of the gap between "marked free" and "actually overwritten" is set by the file system. NTFS keeps the whole map; FAT keeps the start but burns the chain; ext4 and APFS burn the map and lean on a journal or snapshot. Knowing which is which dictates your very first move on any deleted-file job.
What "deleted" means, per file system
Memorize this; it chooses your recovery route before you touch a single user file.
| File system | On delete | What survives | First route | The gotcha |
|---|---|---|---|---|
| NTFS | clears in-use flag (0x16), unlinks dir entry, frees $Bitmap |
full MFT record incl. data runs, names, timestamps | read record → follow runs (icat) |
record reuse / cluster overwrite |
| FAT32 | first name byte → 0xE5, zeroes the FAT chain |
dir entry with start cluster + size | contiguous: start+size; else carve | the chain is gone → fragmented = guesswork |
| exFAT | clears 0x80 "in use" bit on the entry set |
start cluster + length; NoFatChain files fully mapped |
rebuild entry set | fragmented non-contiguous files need the chain |
| ext4 | unlinks, frees inode/blocks, stamps i_dtime, strips block map |
data blocks; journal copy of old inode; name in dir slack | mine the journal (extundelete) | journal is a ring buffer — it wraps fast |
| APFS | removes B-tree records, returns blocks to space manager | snapshots (best); maybe old checkpoints | snapshots, Time Machine, then carve | TRIM + encryption erase/obscure freed data fast |
| HFS+ | removes Catalog/Extents B-tree records, clears Allocation | orphaned B-tree leaf nodes; journal remnants | salvage leaf nodes, else carve | node reuse; carving loses names/paths |
Two structures to read cold
- NTFS MFT record (1024 bytes, signature
FILE): the in-use flag at offset 0x16 decides deleted-or-not; the file is a bag of attributes —$STANDARD_INFORMATION` (0x10), `$FILE_NAME(0x30),$DATA` (0x80, **resident** inside the record for tiny files or **non-resident** mapped by **data runs**). `$SIis user-forgeable;$FNis kernel-written — their contradiction proves timestomping. - ext4 inode (256 bytes): holds metadata and an extent tree but no filename (the name lives in the directory entry).
i_dtimeand a zeroedi_links_countflag deletion; the stripped block map is why recovery runs through the journal, not the dead inode.
Partition tables and the toolchain
- MBR — first sector (LBA 0), four 16-byte entries at offset 446, signature
55 AA; caps at ~2.2 TB and four primaries. GPT — header at LBA 1 (EFI PART), type GUIDs, CRC32, and a life-saving backup at the end of the disk. - The Sleuth Kit pipeline:
mmls(partitions) →fsstat(file system + cluster size) →fls -r -p(list,*= deleted) →icat(recover by metadata address) → verify withfile+ a hash. TSK reads images read-only, satisfying the original is sacred by design.
You can now…
- ☐ Parse an MBR or GPT partition entry by hand and identify the file system before mounting anything.
- ☐ Read an NTFS MFT record — in-use flag, attributes, resident vs. non-resident
$DATA`, data runs, dual `$SI/$FNtimestamps — and say exactly what a deletion leaves behind. - ☐ Read an ext4 inode and explain why deletion defeats inode-based recovery and sends you to the journal.
- ☐ State precisely what "deleted" means on NTFS, FAT/exFAT, ext4, APFS, and HFS+, and pick the matching recovery route for each.
- ☐ Recover a deleted file from an image with
mmls/fsstat/fls/istat/icatand recognize when TRIM, encryption, overwriting, or journal expiry has put data genuinely out of reach.
Looking ahead
Chapter 5 — The Forensic Process. You now know what survives a deletion and where to find it; next you make the getting of it defensible — acquisition with write-blocking, preservation with hashing and chain of custody, systematic analysis, and reporting. It is where the court-bound anchor case is introduced and where "I found this" becomes "I can prove I found this, and it is unaltered."
One sentence to carry forward: Deleted is universal, but the route back is dialed by the file system — read the structure first, and let it tell you whether to follow the map, mine the journal, or carve.