CHFI Storage Forensics and File System Analysis Practice Question
A forensic analyst is recovering deleted files from an ext3 file system. Which TWO methods can be used to recover deleted inodes?
⚠ Common exam trap
The CHFI exam often tests the distinction between data recovery (carving) and metadata recovery (inode/journal analysis), so the trap here is that candidates confuse file carving (Option A) with inode recovery, not realizing that inodes are metadata structures that require journal or inode table scanning, not content-based carving.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Analyzing the ext3 journal for deleted inode entries
Option C is correct because the ext3 journal (introduced with journaling) retains metadata transactions, including records of inode allocations and deletions, so analyzing the journal with tools like ext3grep or jls can reveal deleted inode entries and their associated block pointers. Option E is correct because deleted inodes often remain in the inode table with their link count set to zero and are not immediately overwritten; scanning the inode table (e.g., with debugfs's lsdel or by walking inode structures) can identify these orphan inodes and recover their data. Option A is incorrect because file carving tools like Foremost operate on raw data streams and file signatures, not on inode structures, so they do not recover deleted inodes. Option B is incorrect because dd merely creates a bit-for-bit raw image of the disk and performs no inode recovery itself. Option D is incorrect because using debugfs to display the superblock only shows file system metadata such as block counts and mount status, not deleted inode entries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Using file carving tools like Foremost
Why it's wrong here
File carving tools like Foremost scan raw disk for known file signatures (headers, footers, magic bytes) and reassemble data blocks, completely bypassing filesystem metadata such as inodes. On ext3, deleted files may have intact inodes whose block pointers are still valid, but carving ignores those pointers and instead relies on content patterns; it cannot leverage inode information, journal records, or orphan lists. Therefore, carving is a content-based recovery approach and is not an inode-focused technique, making it unsuitable for the specific goal of recovering deleted files via ext3's metadata structures.
- ✗
Using dd to create a raw image
Why it's wrong here
dd is a low-level utility that creates a bit-for-bit forensic image of a storage device, preserving both allocated and unallocated space, including deleted data remnants. However, dd itself performs no filesystem interpretation; it simply copies bytes. To recover deleted inodes from the resulting image, a separate tool (e.g., debugfs, extundelete, or a journal analysis tool) must be used to parse ext3 structures. Thus, while dd is a crucial first step for forensics, it is not itself an inode recovery method and does not identify or extract deleted inodes.
- ✓
Analyzing the ext3 journal for deleted inode entries
Why this is correct
The ext3 journal (a circular log, typically stored in .journal or an on-disk journal device) records metadata transaction blocks describing changes to inodes, directory entries, and block bitmaps. When a file is unlinked, the corresponding inode modification—including the decremented link count and updated deletion flags—is written to the journal before being committed. If the journal still contains the relevant transaction, an analyst can extract the inode number, its block pointers, and the associated file data, even though the directory entry is gone. This is a valid inode-recovery method, though the journal's limited circular size means old entries may have been overwritten.
- ✗
Using debugfs to display the superblock
Why it's wrong here
debugfs is a powerful ext2/ext3/ext4 debugging tool that can inspect and manipulate on-disk structures, and it offers commands like `lsdel`, `stat`, and `undelete` that operate on inodes. However, displaying the superblock (via `show_super_stats` or `stats`) only prints global filesystem parameters—block count, free blocks, mount options, and feature flags—nothing about individual inodes or deleted files. While debugfs can be used for recovery, specifically the 'display the superblock' action yields no inode-level information and therefore cannot directly recover deleted files. That action is merely a sanity check, not a recovery step.
- ✓
Scanning the inode table for orphan inodes
Why this is correct
ext3 maintains an orphan inode linked list rooted in the superblock field `s_last_orphan`. When a file is deleted but still open, or during crash recovery, its inode is added to this list; these are inodes with a link count of zero that are no longer reachable from any directory entry but are still marked allocated. By scanning the inode table for such orphaned inodes—or by following the orphan list—an analyst can identify inodes whose data block pointers remain intact. Since ext3 does not clear block pointers on deletion, these orphan inodes can often be used to fully recover file contents, making this a definitive inode-based recovery technique.
Go deeper
Related to this question
About these practice questions
One of 745 original CHFI practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CHFI practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CHFI exam.