Chapter 4 — Quiz

14 questions: 10 multiple choice, 2 true/false, 2 short answer. Work them closed-book first, then check the answer key at the bottom. The structure-parsing and "what deleted means" questions are the kind a working examiner answers reflexively, because the first move on any new piece of media depends on them.

Multiple choice

Q1. Where on a disk does the MBR live, and what two-byte signature must end it? - A) The last sector of the disk; signature EF 53 - B) The first 512-byte sector (LBA 0); signature 55 AA at offset 510 - C) LBA 1; signature EFI PART - D) Offset 1024; signature H+

Q2. In an NTFS MFT record, which field decides whether the record describes a live or a deleted file? - A) The $DATA attribute's resident flag - B) The sequence number at offset 0x10 - C) The flags field at offset 0x16 (bit 0 set = in use, clear = deleted) - D) The $FILE_NAME timestamp at offset 0x30

Q3. Decode the NTFS data run 21 0A 00 02 00. (Header low nibble = bytes of length; high nibble = bytes of starting cluster, little-endian.) - A) 10 clusters starting at cluster 512 - B) 33 clusters starting at cluster 2 - C) 2 clusters starting at cluster 10 - D) 512 clusters starting at cluster 10

Q4. An insider backdates a file with a timestamp tool, and Windows Explorer shows the faked date. Which timestamp set still tends to hold the truth, because it is normally written only by the kernel? - A) $STANDARD_INFORMATION` ($SI) - B)$FILE_NAME` ($FN) - C) The $UsnJrnl USN field - D) The $Bitmap allocation time

Q5. An ext4 inode does not contain the file's name. Where does the name actually live? - A) In the superblock's name table - B) In the inode's i_block extent area - C) In the directory entry that references the inode by number - D) In the journal's commit record

Q6. On ext4, deletion strips the inode's block map, so the primary recovery route is to: - A) Read the deleted inode and follow its block pointers directly - B) Mine the journal (jbd2) for an older copy of the inode whose extent map was still populated - C) Rebuild the FAT cluster chain - D) Read the $UsnJrnl

Q7. When a file is deleted on FAT32, which statement is correct about what survives in the directory entry? - A) Nothing survives; the entire 32-byte entry is zeroed - B) The full cluster chain survives, so any file recovers perfectly - C) The first filename character is replaced with 0xE5 and the FAT chain is zeroed, but the start cluster and file size survive in the entry - D) Only the timestamps survive; the start cluster is erased

Q8. Freed data on a modern APFS Mac is often unrecoverable within seconds. The overriding reason — and the recovery source that does survive — are: - A) The journal wraps; recover from $LogFile - B) APFS lives on SSDs and TRIM discards freed blocks; snapshots preserve prior state - C) APFS overwrites in place; recover from the backup superblock - D) The catalog B-tree is zeroed; recover from $MFTMirr

Q9. On a GPT disk, where is the primary partition header and where is its backup kept for resilience? - A) Header at LBA 0; backup at LBA 1 - B) Header at LBA 1 (signature EFI PART); backup header and entry array at the end of the disk - C) Header at offset 446; backup in the second FAT - D) Header at LBA 2; no backup is kept

Q10. In The Sleuth Kit pipeline, which command recovers a file's content by following the data runs from a metadata (MFT/inode) address? - A) mmls - B) fsstat - C) fls - D) icat

True / False

Q11. On every major file system, a deleted file's block map survives the deletion, so you can always follow it straight back to the data. (True / False)

Q12. An NTFS quick format walks the volume and overwrites every data cluster with zeros, securely destroying the old files. (True / False)

Short answer

Q13. State, in two or three sentences, what "deleted" means on NTFS versus on ext4, and explain why the recovery method differs between them.

Q14. Explain the $SI` / `$FN contradiction that proves timestomping: what writes each set, which is forgeable, and what specific ordering of times is a logical impossibility that exposes the tampering.

---

Answer key

Q1 — B. The MBR is the first 512-byte sector (LBA 0): bootstrap code in bytes 0–445, the four 16-byte partition entries at 446–509, and the boot signature 55 AA at offset 510–511. EF 53 is the ext4 magic, EFI PART is the GPT header, and H+ is HFS+.

Q2 — C. The flags field at offset 0x16 holds the in-use bit (0x01) and the directory bit (0x02). When deletion clears the in-use bit, the rest of the record — name, timestamps, data runs — is left intact, which is why NTFS recovery is so forgiving.

Q3 — A. Header 21: low nibble 1 = length field is 1 byte, high nibble 2 = starting-cluster field is 2 bytes. Length 0A = 10 clusters; starting cluster 00 02 little-endian = 0x0200 = 512. So: 10 clusters starting at cluster 512.

Q4 — B. $FILE_NAME` ($FN) timestamps are normally written only by the kernel on create/move/rename and are not exposed to ordinary user-space timestamp-setting calls.$SI` is the set Explorer shows and that any user-space tool can rewrite — so liars usually only edit `$SI`.

Q5 — C. The inode holds metadata (mode, owner, sizes, timestamps, block map) but no name. The name lives only in the directory entry that points to the inode by number — which is why one inode can have several names (hard links) and why a recovered inode gives you content, not a filename.

Q6 — B. ext4 deletion strips/zeroes the live inode's block map, so the deleted inode no longer maps to the data. Tools like extundelete/ext4magic mine the jbd2 journal for an older copy of the inode whose extent map was still populated, then follow that to the still-present blocks.

Q7 — C. FAT deletion writes 0xE5 over the first filename character (hence _ILENAME.JPG) and zeroes the FAT chain entries — but the directory entry keeps the first cluster and file size. Contiguous files therefore recover trivially (start + length); fragmented files lose the map and degrade to carving.

Q8 — B. APFS runs on SSDs; when blocks are freed, TRIM lets the controller discard/zero the underlying flash, often within seconds. Snapshots (and, briefly, superseded checkpoints) deliberately retain prior state, so they — plus Time Machine and live acquisition — are the recovery route, not unallocated space.

Q9 — B. The primary GPT header sits at LBA 1 and begins with EFI PART; GPT stores a backup header and a second copy of the entry array at the end of the disk, and checksums everything with CRC32. That backup frequently reconstructs a wiped primary table in seconds.

Q10 — D. icat follows a metadata record's data runs and writes the file's bytes to standard output. mmls lists partitions, fsstat reports file-system geometry, and fls lists files (flagging deleted ones with *).

Q11 — False. Only some file systems keep the map. NTFS preserves the MFT record's data runs after deletion, but ext4 strips the inode's block map (sending you to the journal) and FAT zeroes the cluster chain (leaving only the start cluster). Assuming the map always survives will fail you on ext4 and on fragmented FAT files.

Q12 — False. A quick format writes a fresh, nearly empty $MFT and root directory and marks the rest free; it does not zero the data area, and usually not the old MFT either. That is exactly why the reformatted wedding-photos drive is recoverable. A full format (zeroing/verifying every sector) is the one that genuinely destroys the old data.

Q13. NTFS: deletion clears the MFT record's in-use flag (offset 0x16), removes the directory index entry, and frees the clusters in $Bitmap — but the full record, including its data runs, name, and timestamps, survives. You read the deleted record and follow its data runs (icat) straight to the content. ext4: deletion unlinks the directory entry, decrements i_links_count, and at zero frees the inode/blocks, stamps i_dtime, and strips the inode's block map. The live deleted inode no longer points to the data, so you mine the journal for an older inode copy (or fall back to carving). The methods differ because NTFS keeps the map and ext4 burns it.

Q14. Windows writes and displays the $STANDARD_INFORMATION` ($SI) timestamps and lets any user-space tool rewrite them with a single API call, so$SI` is forgeable. The `$FILE_NAME($FN) timestamps are normally written only by the kernel on create/move/rename and are not exposed to those calls, so `$FN tends to hold the truth. When someone backdates a file by editing $SI`, the result can be a `$SI "modified" time that is earlier than the $FN` "created" time — a logical impossibility (a file cannot be modified before it exists), which exposes the tampering. Suspiciously round `$SI times against precise $FN times are a second tell.

Scoring: 13–14 correct — you own the file-system layer this book stands on; proceed to Chapter 5 confidently. 10–12 — solid; re-read the sections behind any miss, especially data runs (Q3), the per-FS meaning of deletion (Q5–Q8, Q11), and $SI`/`$FN (Q4, Q14). 7–9 — re-read the NTFS, ext4, and "What 'deleted' means" sections and redo exercises.md Groups C, D, and F. 6 or below — work the chapter again from the top, paying special attention to the master comparison table; everything in Parts II and III assumes you can say exactly what deletion leaves behind on each file system.