Chapter 17 — Exercises
Thirty problems in seven groups, mixing concept checks, hands-on labs (mount a snapshot, build the timeline, recover from an ext4 image, carve deleted SQLite rows, convert Mac absolute time, write the report), and judgment questions. Hands-on labs assume the practice macOS and Linux images and the open toolset (
mac_apt, APFS-Fuse,plutil,log,journalctl,last/lastb,debugfs,ext4magic) from Appendix J — Practice Images and Lab Setup. (answer in Appendix) = worked solution in Answers to Selected. ⭐ = stretch. Always work on a hashed copy, read-only — the original is sacred, and opening a SQLite database read-write silently checkpoints the WAL and alters your evidence.
Group A — Cross-platform foundations and the shared substrate
17.1 A colleague says, "I only do Windows forensics — the Mac and Linux stuff is a niche specialty." Make the counter-argument in three or four sentences using facts from this chapter: where the modern caseload actually lives, what macOS and Linux share with each other (name three Unix commonalities), and why the method (understand → image → analyze → document → report) is identical across all three. (answer in Appendix)
17.2 SQLite is the single most important artifact format in modern forensics. (a) Name at least four distinct macOS or Linux artifacts from this chapter that are SQLite databases under the hood. (b) State the 16-byte magic that identifies a SQLite file and where the page size is stored in the header (which bytes, what endianness). (c) Give the two reasons — one about freeblocks, one about the WAL — that a SQLite database is a deleted-data treasure chest even after a user "clears history." (d) Name two tools that recover deleted SQLite rows (as opposed to the standard sqlite3 client, which reads only live data), and explain why mastering this one format pays off again the moment you reach Chapter 18.
17.3 A knowledgeC.db ZSTARTDATE column holds the value 758661482. (a) State the constant you must add and why (name the epoch). (b) Perform the addition to get a Unix timestamp. (c) Convert that to a UTC date-time, then to America/New_York (UTC−5 in January). (d) The result should land squarely on the chapter's worked-example timeline — which app was in focus at that moment? (e) In one sentence, state the timeline error you commit if you forget the constant. (answer in Appendix)
17.4 Distinguish, in your own words, the macOS approach to recording activity from the Linux approach. (a) Why is "macOS hides its state in opaque binary databases while classic Linux wears its history in plain text" both an accurate generalization and an oversimplification? Name the macOS plain-text remnant (a /var/log/ file that predates Sierra) and the Linux binary stores (three of them) that complicate the picture. (b) Which approach is easier to analyze with a text editor, and which is harder for an attacker to edit cleanly — and why are those two properties in tension for the examiner? (c) State the one collection consequence of this difference: which platform forces you to carry more specialized parsing tools to read its everyday artifacts?
Group B — APFS: copy-on-write and snapshots
17.5 Copy-on-write is the design choice that makes APFS snapshots possible. (a) Explain, step by step, what APFS does to the old data blocks when a file's contents change, and why that behavior preserves prior versions. (b) Define an APFS snapshot in terms of a pinned transaction id. (c) Using the book's signature dual lens, state what the same snapshot gives a 💾 recovery engineer versus a 🔍 forensic examiner. (answer in Appendix)
17.6 Lab — mount the past. On the practice macOS image, find the APFS container partition with mmls, then use APFS-Fuse (or mac_apt) to enumerate the volumes and snapshots. Mount the most relevant snapshot read-only, and produce a list of files that are present in the snapshot but absent from the live volume. For one such file, record its name, size, and original timestamps, and write the one sentence you would put in a report to establish that the file existed on the volume at the snapshot's time and was removed before acquisition.
17.7 ⭐ You image a Mac and, scanning the container, you find three valid container superblocks with the magic NXSB at offset 0x20, carrying transaction ids (xid) 1184, 1201, and 1207. (a) Which one represents the current ("now") state of the file system, and why? (b) What are the other two, and how does APFS's transactional design let them coexist on the same media? (c) Why is the highest-xid superblock not always the only one you care about in an investigation?
17.8 From the hex dump below (4 KiB block size), identify (a) the structure, (b) the field at offset 0x20, (c) the block size, and (d) what the eight bytes at offset 0x00 are and why they matter for integrity. Then state how the volume superblock's magic differs.
Offset 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
0x00000020 4E 58 53 42 00 10 00 00 E0 C8 6E 07 00 00 00 00 NXSB......n.....
Group C — macOS activity artifacts
17.9 Match each macOS artifact to the single question it best answers, then name its on-disk location: Spotlight kMDItemWhereFroms, FSEvents, the Unified Log, knowledgeC, com.apple.quarantine / QuarantineEventsV2. Questions: what changed on the file system and in what order? / what URL did this file download from? / which app was in focus and when? / what download event (URL, agent, time) created this file? / what USB device attached at 14:49? Then state which two of these five carry timestamps you must convert from Mac absolute time, and which one carries no wall-clock time at all. (answer in Appendix)
17.10 FSEvents is where beginners stumble. (a) Why can you not read a precise wall-clock time off an individual FSEvents record? (b) What do the 64-bit event IDs reliably establish? (c) Name two timestamped sources you would correlate against an FSEvents sequence to approximate real times. (d) What is the second granularity caution (about directories and coalescing) that you must disclose before testifying to an FSEvents-derived sequence?
17.11 Lab — build the activity timeline. From the practice macOS image, extract knowledgeC.db (system and per-user) read-only and run the /app/inFocus query from the chapter, remembering the +978307200 correction. Produce an app-focus timeline for a one-hour window. Then add the matching QuarantineEventsV2 download row(s) and the relevant FSEvents lines, and assemble a single sourced mini-timeline (artifact named after each line, all times in UTC). In two sentences, state what the agreement of the three artifacts establishes that any one alone does not.
17.12 ⭐ A suspect ran xattr -d com.apple.quarantine installer.dmg to strip the download tag from a file, and also "cleared" their Safari download history. (a) Explain why the QuarantineEventsV2 database row for that download usually survives the xattr deletion. (b) Explain why the cleared download-history row may still be recoverable from the database. (c) Tie both facts to theme #3 (erasing the trace leaves a trace), and state what the combination — missing xattr plus surviving DB row — signals to an examiner.
17.13 You must collect the Unified Log from a mounted image. (a) Name the two directories you must collect together, and explain precisely what breaks if you grab only the first. (b) What single native command produces a complete, self-contained .logarchive that avoids this problem? (c) Why is a strong --predicate filter not optional but essential when working with this artifact?
Group D — plists, persistence, Keychain, and Time Machine
17.14 A file begins with the bytes 62 70 6C 69 73 74 30 30. (a) What format is it, and what do those bytes spell? (b) Why will a text editor show you garbage, and what is the one command that converts it to readable XML on stdout? (c) Contrast this with how an XML plist begins. (d) Name two investigative questions plists answer, with a concrete file location for one of them. (answer in Appendix)
17.15 Persistence on macOS often lives in plist files. (a) Name the three directory families that hold auto-start .plist definitions and say which are per-user versus system-wide. (b) Why is a .plist in ~/Library/LaunchAgents/ pointing at a binary in a user-writable, unusual location a malware indicator worth chasing into Chapter 32? (c) What does TCC.db tell you that is directly relevant to an exfiltration accusation — specifically, whether a tool could have read the data?
17.16 The Keychain and Time Machine each multiply a Mac's evidentiary value. (a) What can you learn from a login.keychain-db without the user's password, and what requires it (and lawful authority)? (b) Explain why a single seized Mac can yield "not one file-system state but a dozen," naming the two sources of that multiplicity (one on the internal drive, one off it). (c) When you seize a Mac, what one question should you ask the client or scene about backups, and why might the answer hold a version of a file deleted from the laptop a year ago? (d) Each of those backup destinations and snapshots is a separate evidentiary object — state in one sentence what your chain-of-custody log (Appendix F) must now record for each, and why a braided finding is only as defensible as that documentation.
Group E — Linux logs, logins, and shell history
17.17 Build the Linux log map from memory. For each purpose, give the Debian/Ubuntu filename and the RHEL/CentOS filename: authentication, general system messages, scheduled tasks. Then explain log rotation: what logrotate does to auth.log over time, why your evidence may be spread across several files including .gz siblings, and why a deleted-but-not-overwritten rotated log is a candidate for carving. (answer in Appendix)
17.18 Lab — decode the login ledger. From the practice Linux image, extract /var/log/wtmp and /var/log/btmp and decode them with last -f and lastb -f. Report (a) the most recent successful login: user, source host, login and logout times, and session duration; and (b) any evidence of a brute-force attempt in btmp (what pattern tells you it is brute force?). Then explain why these binary files are harder for an attacker to edit cleanly than the text auth.log, and why a wtmp that disagrees with a scrubbed auth.log is affirmative evidence of tampering.
17.19 ⭐ A user's .bash_history ends with these three lines:
scp /tmp/repo.tgz user@10.0.4.18:/Users/jchen/Downloads/
history -c
unset HISTFILE
(a) Explain the elegant paradox: why do the very commands meant to erase the history appear in the history? (b) State the two technical truths about .bash_history that every examiner must internalize — one about timestamps by default, one about when the file is written. (c) Where might the most recent commands of a still-open session live if they never reached .bash_history, and which two chapters cover recovering them?
17.20 Distinguish utmp, wtmp, and btmp by purpose and by the tool that reads each. (a) Which one is volatile and most relevant in live response, and which records failed logins? (b) What is the fixed record size on 64-bit glibc, and what fields does each record hold (name at least four)? (c) Why does the binary, fixed-size structure matter both for parsing and for tamper-resistance — and why does an attacker in a hurry so often scrub the text logs but forget wtmp? (d) What does the separate file /var/log/lastlog add, and which tool reads it?
Group F — ext4 under the hood and deleted-file recovery
17.21 Explain — as if to a client who keeps saying "but you said deleted files come back" — why ext4 deletion is harder than NTFS. (a) Name the four things ext4 does at deletion, and identify the one that is fatal to easy recovery. (b) Contrast this with what an NTFS MFT record retains. (c) State the one consolation ext4 leaves in the directory itself, and exactly what it lets you recover even when the inode's block map is gone. (answer in Appendix)
17.22 Decode the ext4 inode extent region below and confirm it describes the worked example's tarball.
i_block 0A F3 01 00 04 00 00 00 00 00 00 00 <- extent HEADER
00 00 00 00 00 0A 00 00 00 88 00 00 <- one EXTENT entry
decoded: logical blocks 0–2559 → physical block 34816, length 2560
(a) What is the extent header magic, and why does it appear as 0A F3 in the bytes? (b) Read eh_entries, eh_max, and eh_depth, and explain what eh_depth = 0 means for where the extents live. (c) Compute the file size in bytes from the extent (length × block size) and confirm it equals 10,485,760 — the 10 MiB tarball.
17.23 Lab — recover from this image, and verify the hash. On the practice ext4 image, a file of interest was deleted. (1) List recently deleted inodes with debugfs -R 'lsdel'. (2) Recover the file via the journal with ext4magic, supplying a time window. (3) Recover the filename from directory slack. (4) Compute the SHA-256 of the recovered file and compare it to a known copy elsewhere (e.g., a file on a USB image). Report each command you ran, the recovered inode number and size, and the hash comparison result. Finally, state in one sentence why a matching hash across two locations is your strongest correlation — and why the differing filenames on the two copies do not weaken it.
17.24 ⭐ The ext4 journal is your second chance at a deleted file's block map — but it is a limited one. (a) Explain how the jbd2 journal can hand back the extents the live inode discarded (what does it contain copies of?). (b) State the journal's key limitation (size and behavior) and why ext4-journal recovery is therefore a "fresh-deletion" technique. (c) Why does a busy server make the situation worse, and how does the mount option data=journal versus data=ordered change what is recoverable? (d) Name the two tools that lean on the journal and say which handles extents better.
Group G — SQLite forensics, the cross-platform case, and judgment
17.25 SQLite is where this chapter's macOS and Linux threads tie together. (a) When SQLite "deletes" a row, what actually happens to the bytes, and where do they linger? (b) What are the -wal and -shm sidecar files, and what can the -wal contain that the main .db lacks (name both categories)? (c) State the one operational rule about opening the database that protects your evidence, and why VACUUM is the enemy of deleted-row recovery. (answer in Appendix)
17.26 Lab — assemble the cross-platform timeline. Using the worked-example artifacts (or the practice images), build a single normalized timeline that braids the MacBook and the Linux build server into one sequence. Convert every timestamp to UTC, label each line with its source artifact, and include at minimum: the macOS download (Quarantine), the app-focus run of the imaging tool (knowledgeC), the USB attach (Unified Log), the zip landing on the removable volume (FSEvents), the SSH login (auth.log/wtmp/journal), the sudo tar (auth.log), the scp (.bash_history), and the ext4 deletion (dtime). Then write two sentences stating what the cross-platform correlation establishes and exactly where the evidence stops.
17.27 ⭐ On the build server, the file scp'd off was repo.tgz; the archive that FSEvents recorded landing on the USB volume was named falcon-x.zip. Their SHA-256 hashes are identical. (a) Explain what an identical hash proves despite the different filenames and extensions. (b) Explain what it does not prove on its own (e.g., who carried the USB drive away). (c) Why is "filenames are metadata; the hash is content" a sentence worth being able to say under cross-examination?
17.28 A current Apple Silicon MacBook arrives for examination with FileVault on, no password, no institutional recovery key, no backups, and no snapshots predating the relevant deletion window. (a) What, precisely, can you establish about this device? (b) Write the one- or two-sentence finding that honestly reports the result, in the spirit of theme #5. (c) Explain why, when the key lives only in a suspect's head, the problem stops being technical and becomes a legal question — and name the constitutional issue and the chapter that owns it. (answer in Appendix)
17.29 Write the report. Counsel asks: "Can you prove the departing engineer exfiltrated the falcon-x project?" Draft a 150-word Findings paragraph that a competent cross-examiner could not impeach. Cite specific cross-platform artifacts (at least one macOS and one Linux), attribute activity to the correct account and device, lean on the hash match as your strongest correlation, keep finding separate from inference, and state at least two limitations explicitly (for example, time-zone normalization, or what the snapshot proves about existence versus who deleted the file).
17.30 Progressive project — the macOS and Linux layer. Extend your Forensic Case File across platforms (if your case image is Windows-only, perform these against the practice macOS and Linux images so the skills are ready for the Chapter 38 capstone). (1) Enumerate APFS snapshots, record each name and xid, mount the most relevant read-only, and note files present in the snapshot but absent from the live volume. (2) Extract and query, read-only: QuarantineEventsV2, knowledgeC.db (remember +978307200), Spotlight kMDItemWhereFroms for key files, and a rendered Unified Log slice (collect diagnostics and uuidtext). (3) Carve out auth.log/secure and its .gz siblings, decode wtmp/btmp, pull the relevant shell history, and read the systemd journal offline with journalctl --file; note any gaps or inter-log disagreements as findings. (4) For one deleted ext4 file, run debugfs lsdel, recover via ext4magic, recover the filename from directory slack, and hash the result. (5) Normalize every timestamp to UTC, label its source, add the events to your master timeline, and write two or three sentences on what the cross-platform correlation establishes — and where it stops. Hash every extracted artifact into your chain-of-custody worksheet (Appendix F) and list the files and hashes in your submission.
Self-check. You have mastered this chapter when you reflexively check APFS snapshots before you carve, add
+978307200to every Apple SQLite timestamp without being reminded, reach for the ext4 journal and directory slack before declaring a Linux file "gone," and collect the-wal/-shmwith every SQLite database — and when you can braid a macOS snapshot, a knowledgeC row, an FSEvents line, anauth.logentry, and a journal-recovered tarball into one sourced timeline whose kill shot is a matching hash, while stating every encryption, TRIM, retention, and time-zone limit out loud. If you can do that, you are ready for Chapter 18 — Browser and Internet Forensics, where the SQLite skills you just built pay off the moment you openplaces.sqlite.