Lion Cipher Lab
Recover a deleted file by walking the ext4 filesystem on disk — superblock, inode, extent tree, and the journal
- Foundations
- Advanced
- ~90 min
- Free · no account required
Why it matters
"Deleting" a file almost never means erasing its data. On every mainstream filesystem, unlink is a bookkeeping operation: the filesystem marks the space free and drops the name, and the bytes sit exactly where they were until something else claims and overwrites that space. That single fact is the entire foundation of file-recovery AND of digital forensics — and the entire reason 'I deleted it' is not the same sentence as 'it is gone.' But the details are filesystem-specific, and ext4 — the default on most Linux systems and Android — has a design choice that trips up people who learned…
What you'll learn
- reading a real ext4 filesystem from the OUTSIDE with dumpe2fs and debugfs — superblock, block size, inode count, block groups, the root directory, and a file's inode — without mounting it
- walking an inode's EXTENT TREE by hand: reading the (logical-block-range):(physical-block-range) mapping and recording the exact physical blocks that hold a file's data
- the advanced insight that separates ext4 from ext3 for forensics: ext4 ZEROES the inode's block/extent pointers on unlink, which is precisely why naive inode-based undelete fails — proven by stat-ing the deleted inode and watching the extents vanish
- recovering a deleted file WITHOUT its inode: reading the raw data blocks straight out of the image with dd (block number x block size = byte offset), because the data survives in place until something overwrites it
- using the ext4 JOURNAL as a second recovery route — debugfs logdump for the old, pre-delete copy of the inode and its metadata
- verifying a recovery honestly: sha256 the original before deletion, truncate the recovered blocks to the real file size, and prove the hashes match — not 'it looks right'
- the named forensic failure modes: freed blocks already reused/overwritten (recovery impossible), fragmentation defeating naive carving, mounting the live evidence and mutating it, trusting the inode after ext4 zeroed it, and debugfs write-mode on the original
- the judgment of a real analyst: image first and never touch the original, work on a copy, hash before and after, and know when to escalate to a carving tool (photorec/foremost/extundelete) or fall back to a hash — plus the anti-forensics flip side that secure deletion needs an OVERWRITE, not an unlink
Steps in this lab
- The one fact this whole lab rests on — and the forensic prime directive
- Build a real ext4 filesystem inside a file, and mount it
- Write a known 'canary' file and fingerprint it
- Read the SUPERBLOCK with dumpe2fs
- Walk the directory, stat the inode, and read the EXTENT TREE
- Delete the file — then watch ext4 erase the inode's map
- Recovery route A — read the raw data blocks with dd
- Recovery route B — mine the ext4 JOURNAL for the old inode
- Now DESTROY the recovery — prove the failure mode that beats everyone
- The named failure modes, said plainly
- Judgment — how a pro does it, and when NOT to do it by hand
- What you actually built