CHFI Storage Forensics and File System Analysis Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Mount the filesystem with `mount -o ro,noatime` and browse

  Why it's wrong here

  Mounting with -o ro,noatime only prevents writes and prevents atime updates, but it does not restore the directory entry or the inode linkage that was severed when the file was deleted. On ext4, a deleted file's inode is marked free in the inode bitmap, and standard directory browsing exposes only live dentries; the file's contents remain inaccessible even though the underlying data blocks may still exist. This approach is suitable for preserving evidence, not for recovering unlinked files.

• ✗

  Use `dd` to copy the entire partition and search for the file signature

  Why it's wrong here

  Using dd to create a partition image and then searching for file signatures is raw carving, which relies on residual content rather than filesystem metadata. This is far less targeted than extundelete because it ignores ext4 inode and journal structures, making it prone to false positives, fragmented-file recovery problems, and loss of filename and path information. Carving is a useful last resort when filesystem metadata is destroyed, but for recovering a known file at a known path on a healthy ext4 volume it is inefficient and imprecise.

• ✗

  Use `ls -la` to view deleted file entries

  Why it's wrong here

  ls -la simply enumerates the directory entries for the requested path, and deleted files have already had their directory entry unlinked, so they are absent from that listing. ext4 does not expose a trash-like bin; the filename is removed immediately, and only tools that parse raw inode tables or journal entries, such as extundelete or debugfs, can detect remnants of the deleted inode. The file is not listed because no live directory entry references it.

• ✓

  Run `extundelete /dev/sda1 --restore-file /path/to/file`

  Why this is correct

  Running extundelete /dev/sda1 --restore-file /path/to/file is correct because extundelete is specifically built to recover deleted files from ext3/ext4 filesystems by scanning inode tables, block bitmaps, and the journal to locate the inode and reconstruct the file's data blocks. It can operate on a live mounted partition, but safest practice is to unmount first, and it restores the original filename in a dedicated output directory if the inode is still present and not overwritten. This targeted approach aligns with ext4's metadata structures, unlike simple browsing or blind carving.

Go deeper

Related to this question