Artifact & Deleted-File Recovery with The Sleuth Kit

In ext4 & XFS Internals for Responders you separated the two things a "file" really is: the inode (the real object — size, owner, timestamps, and the list of data blocks holding the content) and the directory entry (just a name pointing at an inode number). Deleting a file is far less destructive than the word suggests. When you rm a file, the kernel does three small bookkeeping moves:

1. It removes the directory entry — the name disappears from the folder listing.

2. It marks the inode as free in the inode bitmap.

3. It marks the file's data blocks as free in the block bitmap.

Notice what it does not do: it never wipes the data blocks themselves. The bytes of the file are still sitting on the platter or flash, untouched. They're merely flagged as available for reuse. Until the filesystem happens to allocate those same blocks to a new file and write over them, the original content is fully recoverable.

Think of a contact you delete from your phone. The name vanishes from your contacts list, and the phone marks that slice of storage as reusable — but the actual digits sit in memory, perfectly intact, until something else needs the space and overwrites them. "Deleted" means forgotten and reclaimable, not erased. Forensic recovery is the art of reading those forgotten-but-still-present blocks before they're reused.

Everything in this lesson runs against the forensic image you produced in Evidence Acquisition — a bit-for-bit copy of the disk, hashed and verified, that you treat as read-only. The Sleuth Kit (TSK), the suite you'll use, reads filesystem structures directly out of an image file, without mounting it: it never triggers a journal replay, never updates an atime, never allocates a block. It reads the raw bytes and interprets the on-disk structures itself.

That read-only discipline is what protects the freed-but-intact data above. The instant a filesystem is mounted read-write and anything is written to it, the allocator may hand a freed block to a new file — overwriting the deleted evidence you came to recover. By analyzing an image (and keeping the original drive powered off or write-blocked), you guarantee the blocks stay frozen exactly as they were at acquisition.

A whole-disk image isn't one filesystem — it's a partition table followed by one or more partitions, each with its own filesystem. TSK's filesystem tools (fls, istat, icat) need to know where the partition begins, measured as an offset in sectors from the start of the image. mmls ("media management list") reads the partition table and prints that map. If your image is already a single partition (not a whole disk), you can skip straight to fls — but on a full disk you start here.

fls ("file list") lists the files and directories in the filesystem at the offset you give it — and crucially, it shows deleted entries too, because it reads the directory structure directly rather than asking the kernel for a clean listing. A deleted entry is flagged with a leading *`, and each line ends with the entry's inode number**, which is the key you'll use to recover its content.

Run against the partition offset from mmls, fls becomes your map of what's there — and what was there and got deleted but still has a recoverable inode.

You have a deleted file's inode number from fls (524). istat ("inode stat") prints everything that inode records: ownership, permissions, size, the full set of timestamps, and — the part recovery hinges on — the list of data blocks the file occupied. For a freed inode whose block list hasn't been overwritten, that list is your treasure map: it tells you exactly which blocks on disk still hold the file's bytes.

icat ("inode cat") is the recovery tool. Give it the image, the offset, and an inode number, and it reads that inode's block list and streams the file's content to standard output — exactly like cat, but addressing the file by inode instead of by name. That distinction is the whole reason it works on deleted files: the name is gone from the directory, but the inode (524) and its blocks are still there, so icat reaches the data the only way that's left.

Redirect that stream into a file and you've recovered the deleted artifact.

Recovering one file answers "what was deleted here." The bigger forensic question is "what happened, in what order." fls -m produces a body file: a machine-readable inventory of every file and inode — allocated and deleted — with its size, ownership, and all of its MAC timestamps (Modified, Accessed, Changed/inode-changed, and birth). It's the raw material for a timeline.

Feed that body file to mactime and it sorts every timestamp from every file into a single chronological list — a minute-by-minute reconstruction of filesystem activity. This is the same timeline idea from the file-forensics work, but built from the image and including deleted entries, so an attacker's create-use-delete sequence shows up as a clean run of events.

You have a real root shell. The Sleuth Kit isn't installed on every box, so this sequence checks for it first and gives you a portable fallback if it's missing. Everything here is read-only — you're listing and inspecting, not writing to any live filesystem. If you have a practice image handy, point the TSK commands at it; otherwise the checks and the debugfs fallback work on the box as-is.