Recovering Deleted Files on ext4

"I deleted the file, so it's gone." This is the most common misconception in forensics. On ext4 — the default filesystem of most Linux distributions — deleting a file removes the metadata, but the data blocks often survive untouched until the filesystem reuses them. That gap between deletion and reuse is exactly where forensic recovery lives.

How deletion really works

When you rm a file on ext4, the kernel does roughly this:

• Removes the directory entry (the filename disappears).
• Marks the inode as free and clears most of its fields.
• Adds the data blocks to the free-space bitmap so they can be reused.
• Does not wipe the actual file content from the blocks.

Key consequences for recovery:

• The content is recoverable until new writes claim those blocks.
• On ext4, the inode records the old file size and may keep block pointers (unless the inode has been reused).
• Journal remnants can help reconstruct metadata even after the inode is gone.

Locating deleted inodes

Before recovering, find what's deleted and where. Two classic tools:

# The Sleuth Kit: list deleted entries in a directory
fls -rd /evidence/image.dd -f ext4 /home/bob

# output marks deleted files with '%'
r/r * 137243:  report.pdf
d/d * 137244:  secret_files

# istat shows the inode details, block list, MAC times
istat -f ext4 /evidence/image.dd 137243

The * marker means the inode is unallocated (deleted). Remember the inode number — you'll use it with debugfs.

Recovery with debugfs

debugfs ships with e2fsprogs and talks to ext2/3/4 images directly. Open the image read-only and use lsdel to list deleted inodes:

debugfs /evidence/image.dd

# within debugfs interactive session:
lsdel

# shows deleted inodes with size and deletion time, e.g.:
Inode  Inode is deleted but has open handles:
Inode 137243 deleted, size 5120, mode 100644
  deleted at 1727789114, MTIME at 1727789100

# dump a deleted inode's data to a file
dump <137243> /evidence/recovered_report.pdf

quit

lsdel only lists deleted inodes that are still in the inode table. If the inode was already reused, debugfs can't help with that inode — but carving might.

Recovery with extundelete

extundelete automates what debugfs does manually and adds journal support:

# always work on a copy of the image, not the original!
cp /evidence/image.dd /evidence/work.dd

# restore a single file by path
extundelete /evidence/work.dd --restore-file /home/bob/report.pdf

# restore a directory
extundelete /evidence/work.dd --restore-directory /home/bob/secret_files

# restore EVERYTHING that can be recovered
extundelete /evidence/work.dd --restore-all

# files land in ./RECOVERED_FILES/
ls -la RECOVERED_FILES/

File carving for the rest

When metadata is destroyed but content remains, carving scans the raw disk for file signatures (magic bytes) and reassembles files. It needs no filesystem at all and works beautifully on unallocated space.

# 1. extract unallocated space with tsk
blkls /evidence/image.dd -A > /evidence/unallocated.bin

# 2. carve it with foremost
foremost -i /evidence/unallocated.bin -o /evidence/carved/

# or with scalpel (edit its config to add custom types first)
scalpel -i /evidence/unallocated.bin -o /evidence/scalped/

# 3. check what came out
find /evidence/carved -type f | head -20

Carving has limits: fragmented files lose their order, and files with no recognizable header are missed. It's a second net, not a replacement for metadata recovery.

The one-page summary

Recovery odds drop fast the longer a system runs after deletion. Image early, image read-only, and let the tools work from copies.

← Previous: Live vs. Dead Acquisition  ·  Next: Log Analysis with journald & syslog →