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.

• ✗

  The ext4 journal will automatically purge the metadata of deleted files

  Why it's wrong here

  The ext4 journal is a circular log that records file system metadata changes for crash recovery; it does not perform any kind of metadata purging when a file is deleted. Deleting a file in ext4 involves clearing the directory entry, decrementing the link count, and freeing the inode, but the journal continues to hold historical transaction records. Rather than actively erasing deleted file metadata, journal transactions may preserve remnants of the file's metadata until those log blocks are overwritten by later activity. Thus, the notion of automatic purging by the journal is incorrect.

• ✗

  Data recovery is still possible using file carving because fstrim only affects free space

  Why it's wrong here

  Data carving after fstrim is not viable because fstrim issues a TRIM command to the SSD for every free block on the filesystem, and deleted file data lives in that free space. The command instructs the SSD controller to discard the underlying NAND blocks, which causes them to be erased and presented as zeroed or unavailable. While fstrim only touches free space, that is exactly the area where unallocated file content would be carved from, so any remnants are destroyed at the physical layer. Allocated files are unaffected, but they are not the target of forensic carving after deletion.

• ✗

  The inodes are overwritten immediately, making recovery impossible

  Why it's wrong here

  ext4 does not overwrite inode data immediately upon deletion; the inode is simply marked as free in the inode bitmap while its original fields—such as timestamps, ownership, and data block pointers—remain intact until the inode is reused by a new file. The data blocks themselves are likewise not touched and still contain the original file content until overwritten by subsequent writes. Therefore, recovery is possible using tools like debugfs or extundelete if the blocks have not been reused or if TRIM has not been issued. The premise of immediate overwriting is a misunderstanding of ext4's lazy allocation and freeing behavior.

• ✓

  The TRIM command instructs the SSD to permanently erase the blocks, and wear leveling may also have moved data

  Why this is correct

  The TRIM command is an ATA interface primitive that informs the SSD which Logical Block Addresses are no longer in use, allowing the controller to erase the corresponding NAND flash blocks in the background, permanently destroying the data they contain. When an ext4 filesystem is mounted with the discard option or when fstrim is run, all freed blocks are trimmed, including those formerly occupied by deleted files. Additionally, the SSD's wear-leveling algorithm continuously remaps logical to physical blocks, so even if a forensic tool reads the logical LBA, the physical block that originally stored the data may have been relocated during garbage collection. This combination of block erasure and physical address remapping makes traditional file recovery impossible on such systems.

Go deeper

Related to this question