During a forensic examination of a Linux ext4 file system, an investigator runs the `ls -i` command and sees inode numbers. They need to examine the inode structure. Which command should they use to display detailed inode information?
debugfs is the standard ext2/ext3/ext4 filesystem debugger, and the -R option lets you execute a single request in non-interactive mode. The 'stat <inode>' command within debugfs prints the complete inode record, including file mode, UID/GID, size, access/change/modification times, link count, and block allocation data. This makes it the correct choice for directly querying inode information on a live device or an acquired image without mounting or modifying the filesystem.
Why this answer
The `debugfs` command is a native ext2/ext3/ext4 file system debugger that allows direct inode inspection. The `-R 'stat <inode>'` flag runs the `stat` command in debugfs to display the full inode structure, including permissions, timestamps, block pointers, and extended attributes, which is exactly what the investigator needs after seeing inode numbers from `ls -i`.
Exam trap
EC-CHFI often tests the distinction between file system analysis tools (debugfs) and general-purpose disk utilities (dd, mount, fsck), trapping candidates who confuse imaging or mounting with inode-level inspection.
How to eliminate wrong answers
Option A is wrong because `dd` is a low-level block copy tool used for imaging or cloning a partition; it does not parse or display inode metadata. Option C is wrong because `mount -o loop` attaches a disk image to the file system tree for access as a mounted volume, but it does not provide a command to dump raw inode details—it only makes files accessible via standard file operations. Option D is wrong because `fsck` is a file system consistency check and repair tool; it does not display inode structures and is not designed for forensic inode examination.