Chapter 21 — Quiz

14 questions: 10 multiple choice, 2 true/false, 2 short answer. Answers and a scoring band are at the bottom. Commit to an answer before you look — and for every timestamp, ask two questions first: what epoch is this, and was the clock that wrote it telling the truth?

Multiple choice

Q1. A Windows FILETIME is a 64-bit count of: - A) Seconds since January 1, 1970 UTC - B) Milliseconds since January 1, 1980 local time - C) 100-nanosecond intervals since January 1, 1601 UTC - D) Microseconds since January 1, 2001 UTC

Q2. An NTFS file carries two full MACB sets. Which attribute's timestamps are maintained by the kernel, have no documented user-space API to write, and are therefore the set to trust when the two disagree? - A) $STANDARD_INFORMATION (type 0x10) - B) $FILE_NAME (type 0x30) - C) $DATA (type 0x80) - D) $BITMAP (type 0xB0)

Q3. In the MACB model, the letter C stands for "Changed." What does it actually record? - A) The time the file's content was created - B) The time the file was last copied - C) The time the file's metadata record (its MFT entry or inode) was last changed — e.g., a rename or permission change - D) The time the file was last closed

Q4. A file's $STANDARD_INFORMATION shows Created 2024-03-15 and Modified 2024-03-10 — created after modified. The most defensible interpretation is: - A) The file was definitely timestomped - B) This is the normal signature of a copied or downloaded file (new birth, inherited modified time); confirm benign by checking $FILE_NAME - C) The file system is corrupt - D) The clock ran backward

Q5. Which observation is the headline tell of timestomping on NTFS? - A) The file is larger than 1 MB - B) $STANDARD_INFORMATION` Born is *earlier* than `$FILE_NAME Born — the file "created" before the kernel recorded its name existing - C) The file has a long file name and an 8.3 short name - D) The Accessed time equals the Modified time

Q6. A column of NTFS timestamps that all end in exactly .0000000 (zeroed 100-nanosecond fractions) is suspicious because: - A) NTFS cannot store sub-second precision - B) Genuine file operations stamp non-zero sub-second fractions, while many timestomping tools and high-level APIs write whole seconds - C) It means the files were created on a FAT volume - D) It proves the disk is failing

Q7. A FAT32-formatted USB thumb drive records its file timestamps in: - A) UTC, like NTFS - B) UTC plus a stored offset byte, like exFAT - C) Local time, with no record of which time zone was in effect - D) Unix epoch seconds

Q8. The constant 116,444,736,000,000,000 that you use constantly in timeline work is: - A) The number of seconds in 400 years - B) The number of 100-nanosecond intervals between 1601-01-01 and 1970-01-01 (i.e., the FILETIME of the Unix epoch) - C) The maximum value of a 64-bit integer - D) The number of microseconds since the Cocoa epoch

Q9. You need one tool that ingests an image and extracts every timestamp it can find — file-system MACB (both $SI` and `$FN), registry, .evtx, prefetch, LNK, browser, email — into one storage file. That tool is: - A) fls/mactime (the Sleuth Kit bodyfile pipeline) - B) log2timeline.py/plaso, sorted with psort.py - C) exiftool - D) hashdeep

Q10. An unchanged $STANDARD_INFORMATION Accessed (A) time tells you almost nothing about whether a file was opened because: - A) Access times are stored in local time and cannot be converted - B) Windows disables last-access updates by default (since Vista), so a stale A time does not mean "never opened" - C) Access times are only updated on FAT volumes - D) The A time is always identical to the B time

True / False

Q11. Because $FILE_NAME` is maintained by the kernel, it can *never* be forged, so a single `$FN value is always sufficient proof of a true creation time. (True / False)

Q12. Windows event ID 4616, "the system time was changed," records that the clock was altered, by which account, and the old and new values — making it a strong indicator of deliberate clock manipulation. (True / False)

Short answer

Q13. In one or two sentences, explain why a professional builds and analyzes the timeline in UTC and converts to a local zone only at the very end — and state the single chain-of-custody sentence the report must contain about its time standard.

Q14. A file's $SI` Born reads `2022-02-11 10:00:00.0000000` (all four `$SI values identical) while its $FN Born reads 2024-03-15 18:58:13.4928130. List at least three tells that this file was timestomped, and name the one independent artifact you would pull to corroborate the true creation time.

---

Answer key

Q1 — C. FILETIME = 100-nanosecond intervals since midnight, 1 January 1601 UTC. (Unix is seconds since 1970; Cocoa is seconds since 2001; DOS/FAT counts from 1980.) The 1601 epoch starts a 400-year Gregorian cycle, which keeps leap-year math clean.

Q2 — B. $FILE_NAME` (attribute 0x30) is written by the kernel when a name is created/moved/renamed, with no documented user-space API to set it — so it is hard to forge and is the truthful clock. `$STANDARD_INFORMATION (0x10) is what Explorer shows and what SetFileTime()/timestomp tools edit.

Q3 — C. "C" is the metadata-change time (MFT entry or inode last altered — rename, permissions, attributes), not creation. Creation is B (Born). This is the single most common MACB misconception.

Q4 — B. Born-after-Modified is the normal signature of a copy or download: copying creates a brand-new file (B = now) whose content was last written earlier (M inherited from the source). Crying "timestomping!" at this benign pattern is a classic error; confirm by checking whether $FN corroborates the recent birth.

Q5 — B. $SI` Born earlier than `$FN Born means the file claims to have been "created" before the kernel recorded its name existing — impossible without intervention, and the headline timestomping tell.

Q6 — B. Real NTFS operations write messy, non-zero 100-ns fractions; many tools and the high-level APIs write whole seconds, zeroing the fraction. A cluster of perfectly round .0000000 timestamps among neighbors with messy fractions is a strong signal (not proof alone — corroborate).

Q7 — C. FAT (and largely exFAT differs by storing a UTC-offset byte) records local time with no zone information. A FAT thumb drive carried between zones silently means different absolute instants — the single most common normalization error new examiners make.

Q8 — B. It is the count of 100-ns intervals between the 1601 and 1970 epochs — the FILETIME value of the Unix epoch. FILETIME→Unix subtracts it then divides by 10,000,000; Unix→FILETIME multiplies by 10,000,000 then adds it.

Q9 — B. log2timeline.py/plaso runs 100+ parsers across an image into one .plaso storage file; psort.py sorts/filters/renders it. fls/mactime see only the file system; the trade-off is comprehensiveness (plaso) vs. a fast, surgical file-system spine (mactime).

Q10 — B. Last-access updates are disabled by default since Vista (NtfsDisableLastAccessUpdate), and many Linux mounts use relatime/noatime. A stale A time is not "never opened," and you must never present it as a reliable "last opened" without confirming the system actually updated it.

Q11 — False. $FN` is strong, not sacred: kernel-level tools (some versions of `SetMACE`) and raw-disk editors can forge `$FN and even edit the USN journal, and innocent causes (file-system tunneling, restore-from-backup, certain installers) can make $SI` legitimately older than `$FN. The defense is corroboration across independent clocks, never reliance on one attribute.

Q12 — True. Event ID 4616 records the time change, the responsible account, and the old/new values. A 4616 not attributable to the w32time service is a flashing indicator of deliberate clock manipulation; use the old/new values to segment the timeline and reinterpret times written during the altered window.

Q13. "When" is meaningless without a standard; mixing zones — even accidentally — can make a later event appear earlier and hands a cross-examiner an easy attack, so you normalize every source to UTC, build and analyze in UTC, and translate to local only at the end for the reader, with the zone stated. The required sentence states the standard and how you derived it, e.g.: "All times are UTC; local-time sources were converted using the evidence system's configured zone, Pacific (Bias 480, ActiveTimeBias 420 during DST), read from SYSTEM\ControlSet001\Control\TimeZoneInformation."

Q14. Tells (any three): (1) $SI` Born (2022) is *earlier* than `$FN Born (2024) — impossible without intervention; (2) all four $SI` values are byte-for-byte identical, which normal operation does not produce; (3) the `$SI sub-seconds are all zeroed (.0000000), the whole-second tool/API signature, while $FN` carries a realistic non-zero fraction; (4) the `$SI date may also predate the OS install/volume creation. Corroborating artifact: a USN_REASON_FILE_CREATE record in $Extend\$UsnJrnl:$J` (the USN change journal) dated to the same 2024-03-15 18:58 instant as `$FN (or, secondarily, $LogFile) — a second, independent witness to the true birth time.

Scoring: 13–14 — courtroom-ready; you convert any clock, trust the kernel over the user, and never overstate a single artifact. 10–12 — solid; revisit epochs/skew (Q1, Q7, Q8) and the $FN` limit (Q11). **7–9** — re-read "How computers tell time," "MACB," and "Detecting timestamp manipulation," then redo Groups A–D in the [exercises](exercises.md). **Below 7** — re-read the chapter [index](index.md) and rebuild the anchor-case `$SI-vs-$FN contradiction by hand before moving on.