Chapter 34 — Exercises
A mix of concept checks, hands-on labs ("classify this device," "parse this header," "convert this timestamp," "carve this firmware," "build the correlated timeline"), and judgment calls — because IoT forensics is the discipline where the legal posture governs more than the technique, and the hardest decisions (what to seize first, what to subpoena, what a sensor actually proves) have no answer key in the room. (answer in Appendix) = worked solution in Answers. ⭐ = stretch. Every hands-on lab below is doable on hardware you own or a sanctioned practice image (Appendix J — Practice Images and Lab Setup) — stand up your own Home Assistant instance, dump the SPI flash of a router you own, export your own Garmin or Fitbit data — and never touch a device, account, or vehicle you are not authorized to examine.
Group A — The Internet of Evidence and the three tiers
The model that governs every device comes before any single device: where the data lives, and what authority each location demands.
34.1 State the three tiers of IoT evidence in your own words. For each tier, name (a) two example artifacts it holds, (b) the access method, and (c) the legal authority you typically need. Then answer the question the model exists to teach: for most IoT devices, which tier holds the richest data, which tier is the hardest to reach, and why is that combination the central problem of the chapter? (answer in Appendix)
34.2 Name the five unifying challenges of IoT, vehicle, and embedded forensics. (a) For three of them, give one concrete way the challenge would defeat an examiner who treated an IoT device the way they treat a hard drive (e.g., what "no standard tooling" actually costs you when you open a smart lock). (b) Two of the challenges are about time pressure of very different kinds — one technical, one legal. Identify both, and explain why "I'll get to the cloud records next month" can be as fatal as "I'll pull the power to preserve it." (c) For the "cannot write-block soldered storage" challenge, name the one thing that must carry the integrity argument in court when no write-blocker is possible.
34.3 The chapter argues that the foundational discipline image first, work the copy (from Chapter 5) is "strained" in IoT work. (a) Give three specific reasons you cannot simply slip a hardware write-blocker between an IoT device and its storage. (b) When you cannot guarantee non-alteration the way a write-blocker does, what must carry the weight the write-blocker normally would? (c) Tie this to the book's second theme, the original is sacred — what plays the role of "the original you never touch" when the evidence is a live cloud account?
34.4 ⭐ (Judgment — acquisition order.) You arrive at a scene with a powered-on voice assistant, a hub running on a Raspberry Pi, a victim's smartwatch still on the wrist, and a vehicle in the driveway. Power is available; nothing is in distress. Write the order in which you would acquire these four sources and justify each placement by volatility and perishability — and explain why "unplug everything first to preserve it" is exactly the wrong instinct here. Which single thing must you do before touching any of them that is not a technical step at all? (answer in Appendix)
Group B — Smart-home forensics
Walk the home device by device. Some witnesses keep useful notes; the skill is knowing which, and where.
34.5 (Interpret the record.) You are handed this Alexa voice-history record produced under a warrant to Amazon:
{
"creationTimestamp": 1700000000123,
"activityStatus": "SUCCESS",
"description": "{\"summary\":\"set an alarm for 5 a.m.\"}",
"sourceDeviceIds": [{ "serialNumber":"G090XXXXXXXX12AB" }],
"domain": "Notifications"
}
(a) Convert creationTimestamp to a UTC date and time, showing your work — and name the conversion trap that sends careless examiners off by a factor of a thousand. (b) State three distinct evidentiary facts this single record establishes. (c) The richest field — the audio recording — is not in this excerpt. Where does it live, and what is the one-sentence reason you cannot simply log into the account to retrieve it? (d) The home also has a Google Nest speaker. Name the Google-side equivalent of this record (the service and its URL), and two other Google account histories that frequently corroborate a voice-assistant timeline. (answer in Appendix)
34.6 A homeowner reports a package theft and wants last week's doorbell clip back; a detective wants the same clip for a burglary case. (a) Classify each request as recovery or forensics and state, for each, the authority and the documentation required. (b) Before either of you builds a theory on that footage, what single fact about the Ring account must you confirm, and why might the clip simply not exist? (c) Name the two modern "walls" — one cryptographic, one procedural — that changed law-enforcement access to Ring footage, and what each one does. (d) Not all camera evidence is cloud-tethered: many cameras and NVRs write to a microSD card or an on-premises hard drive. Explain why that local storage is recovery territory you already own, what acquisition discipline it demands, and why surveillance video — though often a proprietary container — is frequently carvable anyway (Chapter 7).
34.7 (Reconstruct the narrative — the local goldmine.) You image a Raspberry Pi running Home Assistant and pull home-assistant_v2.db. A query of the states table returns:
2024-03-11T02:09:41+00:00 device_tracker.owner_phone -> home
2024-03-11T02:11:03+00:00 lock.front_door -> unlocked
2024-03-11T02:11:55+00:00 binary_sensor.office_motion -> on
2024-03-11T02:48:12+00:00 binary_sensor.office_motion -> off
2024-03-11T02:49:30+00:00 lock.front_door -> locked
2024-03-11T02:50:06+00:00 device_tracker.owner_phone -> not_home
(a) Write the two-sentence narrative this sequence supports. (b) Why is this evidence evidentially special compared with the Echo or Ring data — what about its location changes the legal posture entirely? (c) The last_updated_ts column in older databases was an ISO string; in current ones it is a Unix epoch float, and the entity_id moved into a states_meta lookup table. Name the chapter-wide problem this schema drift previews, and why it is gentler here than on a closed device. (answer in Appendix)
34.8 ⭐ For each device, state in one line what human activity it silently records and one realistic way that record corroborates or contradicts a statement: (a) a smart lock; (b) a Nest or ecobee thermostat; (c) a Z-Wave/Zigbee hub that also logs a lock's events. For (c), explain why a second, independent copy of the same event on the hub is "far stronger than either alone."
Group C — Wearables: the body as a witness
A wearable instruments a person. Its power is a timestamped record of when a body was moving — and its traps are all in the clock.
34.9 (Calculate — the Apple epoch.) An Apple Health samples row stores a heart-rate timestamp as the raw value 700000000. (a) Read naively as Unix time (seconds since 1970), what year does it land in? (b) Apply the correct conversion for Apple's Core Data / Mac absolute time and give the real year — show the offset you add and why. (c) State the error magnitude of getting this wrong, and explain why the chapter calls the one-hour time-zone version of this mistake "the dangerous one" while the 31-year version is merely embarrassing. (answer in Appendix)
34.10 (Parse the header — Garmin FIT.) A FIT file begins:
00000000 0E 20 1A 08 D4 96 00 00 2E 46 49 54 9D 4F
(a) Give the header size, and the byte offset at which the .FIT signature appears. (b) The data-size field is the little-endian value at bytes 4–7; compute it in decimal. (c) Name the two conversions you must perform on the record messages that follow — one for time, one for position — and the constant each requires.
34.11 (Calculate — semicircles and the FIT epoch.) From a decoded FIT record message you read timestamp = 1078000000, position_lat = 500000000, position_long = -1000000000. (a) Convert the timestamp to UTC (Garmin's epoch is 1989-12-31; show the offset). (b) Convert latitude and longitude to decimal degrees using degrees = semicircles × 180 / 2³¹, to two decimal places. (c) In one sentence, state what this single record proves about the device and what it does not prove about a person. (answer in Appendix)
34.12 ⭐ (Judgment — the body's silence.) The chapter extends theme three — the absence of a trace is itself a trace — to physiology, noting that the cessation of a wearable's stream is itself a timestamped event. (a) Explain, clinically, why a sudden stop in heart-rate and step data can constrain a time-of-death window, and why an examiner states it as a window rather than a point. (b) Give two innocent explanations for a data gap that a careful examiner must rule out before treating a stop as significant (think: charging, sync delay, device removal). (c) Why is a wearable record the most ethically sensitive evidence in this chapter, and which chapter owns that duty? (answer in Appendix)
Group D — Vehicle forensics: the car as a computer
Three data systems, three tools, three legal authorities. Confusing them is the surest sign of inexperience.
34.13 Draw or describe the three data systems in a modern vehicle. For each, name (a) the primary content, (b) the standard tool, and (c) the legal authority. Then answer: an examiner looking for trip history reaches for the EDR, and an examiner looking for crash dynamics opens the infotainment report. State exactly why each is looking in the wrong place. (answer in Appendix)
34.14 (Interpret the extraction.) A Berla iVe report on a suspect's vehicle includes:
Connected Devices:
Device name ......... "J. RIVERA iPhone"
Bluetooth address ... 9C:35:EB:xx:xx:xx
First paired ........ 2024-03-04 18:22:07 (vehicle local time)
Last connected ...... 2024-03-11 02:08:51
Synced artifacts .... Contacts (412), Call log (87), Messages (cached)
Navigation:
Last destination .... "1100 INDUSTRIAL PKWY" arrived 2024-03-11 02:13
Tracklog points ..... 1,944
(a) List four distinct evidentiary facts this report establishes. (b) Explain the surprising claim that a car can hold a usable copy of a phone's contacts and call log even if the phone is destroyed, wiped, or never recovered — and what that means for a suspect who used a rental or borrowed car. (c) The "vehicle local time" note on the pairing timestamp is a landmine; explain why, and what you must do before placing this event on a multi-source timeline. (d) iVe's coverage is "broad but not universal" and make/model/year specific. State the first question you ask on any vehicle job, and describe what you fall back to when the vehicle is unsupported or you must validate iVe's parsing of a load-bearing fact.
34.15 The Event Data Recorder is widely misunderstood. (a) What does it actually record, over what time window, and what triggers a capture? (b) Why is an EDR read time-sensitive after a crash — what can happen to a non-deployment buffer? (c) Name the regulation that standardizes the U.S. data set, the tool you use, and the two ways that tool connects to the vehicle. (d) State the authority issue: who is generally held to "own" EDR data, and what does that mean for how you retrieve it?
34.16 ⭐ (Recovery vs. forensics + the cloud.) Tesla illustrates both disciplines at once. (a) Name three categories of data the manufacturer's connected-car cloud holds, and the authority required to obtain them. (b) Describe the recovery angle for Tesla Sentry/dashcam footage — where is it written, and how do you treat it? (c) Describe a genuine recovery failure mode unique to early Tesla units, and why it is "a hardware data-recovery problem in its own right." Cross-reference Chapter 9 — SSD and Flash Recovery.
Group E — Embedded and firmware extraction
When there is no app, no tool, and no cloud you can reach, you drop to the hardware. Four interfaces, in escalating effort.
34.17 (Wire it up — UART.) You find four unpopulated pads near the SoC of a router you own. (a) Describe how you identify GND, VCC, TX, and RX with a multimeter — what does each pad look like electrically? (b) Which of the four do you not connect to your USB-TTL adapter, and why is connecting it dangerous? (c) Write the cross-over wiring between adapter and device, and the most likely baud rate to try first. (d) What three things does the boot log routinely reveal, and what is the "front door" manufacturers leave open "astonishingly often"? (answer in Appendix)
34.18 (Identify the chip — SPI flash.) You clip onto an 8-pin SOIC chip with a CH341A programmer and flashrom reports the JEDEC ID EF 40 18. (a) Identify the manufacturer (give the manufacturer byte) and the capacity in megabytes, showing how the capacity byte encodes size. (b) Write the two-command flashrom sequence to detect and then read the entire chip to a file, and state the very next command you run and why. (c) Why can an in-circuit read be unreliable while the board's CPU is powered, and name two ways to work around it.
34.19 (Carve the firmware.) binwalk on your dumped image reports:
DECIMAL HEXADECIMAL DESCRIPTION
0 0x0 uImage header, OS: Linux, CPU: MIPS, type: OS Kernel,
compression: lzma
64 0x40 LZMA compressed data
1310720 0x140000 Squashfs filesystem, little endian, version 4.0
(a) Name the three components of a typical firmware image this layout shows. (b) Give the on-disk magic bytes for uImage and for SquashFS, and the ASCII you would recognize for SquashFS in a hex view. (c) After binwalk -e carves the root file system, name four specific files or paths you grep for to turn the blob into evidence, and what each yields. (d) What does binwalk -E (entropy) tell you, and what would a flat region versus a region near 1.0 indicate? (e) Inside the dumped image you find this region:
00007000 61 64 6D 69 6E 5F 70 61 73 73 77 6F 72 64 3D 73 admin_password=s
00007010 75 70 65 72 73 65 63 72 65 74 0A 77 69 66 69 5F upersecret.wifi_
00007020 6B 65 79 3D 68 6F 6D 65 6E 65 74 31 32 33 0A key=homenet123.
State what region of the firmware this is, what two secrets are exposed, and why their presence "in the clear" is both an evidentiary gift and a recovery shortcut — and what it would have looked like instead if this region were encrypted. (answer in Appendix)
34.20 ⭐ (Judgment — JTAG, chip-off, and knowing your bench.) (a) When do you escalate from UART to JTAG, and why is JTAG "increasingly fused off" on modern devices? (b) For a vehicle head unit using eMMC, contrast the ISP method with full chip-off, and explain why a managed-NAND dump spares you the raw-NAND reconstruction nightmare of Chapter 9. (c) Resolve the chapter's hardest limitation: you have one evidence device and your shop has never done a successful chip-off. State the professional decision and justify it against theme five.
Group F — Correlation, clock normalization, and honest inference
The most persuasive timelines are corroborated across independent devices with independent clocks. The unglamorous heart of the work is making those clocks agree.
34.21 (Build the timeline — normalize the zoo of epochs.) Five independent sources captured events the same night. Convert each raw value to UTC, then list the events in chronological order. Show the offset or formula for each.
SOURCE RAW VALUE EPOCH / FORMAT
Smart lock (unlock) 1710122970 Unix seconds
Windows USB-insert (Ch.16) 133545966740000000 FILETIME (100-ns since 1601)
Fitbit cloud (HR sample) 1710123480000 Unix milliseconds
Apple Watch Health (workout) 731817000 Apple 2001 epoch (seconds)
Garmin FIT (tracklog point) 1079059806 FIT 1989 epoch (seconds)
Then answer: a single botched conversion here does not merely shift one event — it can make two devices appear to disagree. Explain why that specific failure "hands the defense a real argument," and which chapter sets up timeline analysis properly. (answer in Appendix)
34.22 Reproduce the chapter's normalization helpers as a short reference table: for from_unix, from_unix_ms, from_apple, from_fit, and from_filetime, give the operation each performs (the exact offset or arithmetic) and one device that uses it. Then add two conversions that are not about time: the Garmin semicircle-to-degrees formula, and the GPS-time caveat (how many leap seconds, in which direction relative to UTC). In one sentence, explain why you would bake every one of these into a reusable, tested function rather than converting by hand in each case.
34.23 (State the inference carefully.) For each device finding, write two sentences: one stating exactly what the device recorded, and a separate one stating what it does and does not prove about a person. (a) A Fitbit shows a heart rate of 96 bpm and step activity at 02:18. (b) A vehicle tracklog ends at the office at 02:08. (c) A smart-lock log shows badge #4471 unlocking the rear door at 02:09. Why is the examiner who says "the Fitbit shows the suspect was awake" courting the cross-examination that "ends careers"? Cross-reference Chapter 27 — Expert Testimony.
34.24 ⭐ (The defense's gambit — why corroboration wins.) In the chapter's worked example (anchor case #2), a suspect concedes a device was at the workstation at 2:11 a.m. but disputes that it places the person there. (a) Explain why four independent devices with four independent clocks defeat that argument when the Windows artifact alone could not. (b) Why is it significant that the CCleaner anti-forensic run on the laptop "cannot reach a car's head unit, a wearable's cloud, or a door controller" (tie to theme three)? (c) Identify the single legally delicate source in that timeline and the authority problem it raises, and explain why "the company gave them the device" does not settle it. (answer in Appendix)
Group G — Progressive project: add an Internet-of-Evidence source
Your Forensic Case File (running since Chapter 5, assembled in Chapter 38) holds a disk image, recovered files, browser and email artifacts, a timeline, and an anti-forensics finding. Add an IoT, wearable, vehicle, or embedded source and integrate it.
34.25 (Identify and classify.) From your case scenario, list every IoT, wearable, vehicle, or embedded device in scope. For each, classify its data across the three tiers and state, for each tier, the exact legal authority you would need — consent, a warrant, or third-party process. Flag any source that would require an MLAT or implicates Riley/Carpenter, and say why. (answer in Appendix)
34.26 (Acquire and decode something concrete.) Use a local source you can actually obtain: a Home Assistant home-assistant_v2.db, a router or camera firmware dump you carve with binwalk, a FIT file from a fitness device, or a companion-app SQLite database pulled from the case phone image. Image or copy it, hash it immediately, and record the acquisition method — noting you could not write-block it and documenting how you preserved integrity instead (per Appendix F). Parse the artifact, extract its timestamped events, convert every timestamp to UTC showing your conversions, and merge them into your master timeline.
34.27 ⭐ (State the inference and log it.) For each IoT event you added, write one sentence of exactly what the device recorded and a separate sentence of what it does and does not prove about a person — the discipline you will need on the stand. Then record the source, its hash, the authority, and your epoch conversions in your evidence log, ready for the report in Chapter 26. In one paragraph, explain why "the most persuasive timelines are corroborated across independent devices with independent clocks" is the lesson the whole project is built to teach.
34.28 ⭐ (Write the report paragraph — synthesis.) Drawing on everything in this chapter, draft the methodology paragraph an IoT/multi-device finding would open with in a court-ready report (Chapter 26). It must, in plain professional prose: (a) name each source and the tier it came from; (b) state the authority under which each was acquired and how integrity was preserved without a write-blocker; (c) declare that all timestamps were normalized to UTC and that the conversions are documented; and (d) include the one sentence of epistemic humility that pre-empts cross-examination — the boundary between what the devices recorded and what they prove. Keep it to a single tight paragraph; the discipline is saying all of that without overstating any of it.
Self-check. You have mastered this chapter when you can, without notes: classify any smart-home, wearable, vehicle, or embedded data source across the three tiers and name the authority each tier requires; pull and read the local goldmines (
home-assistant_v2.db, a companion-app SQLite, a FIT file) and convert each device's epoch correctly — Apple's 2001, Garmin's 1989, milliseconds versus seconds — without shifting a timeline by 31 years or one hour; distinguish a vehicle's three systems and pick the right tool and authority for each (iVe, Bosch CDR, legal process to the maker); perform or correctly refuse hardware extraction (UART to a root shell, SPI clip-and-flashrom, eMMC chip-off) and carve firmware withbinwalk/unsquashfs; and build a clock-normalized, multi-device timeline while stating in two sentences what each sensor proves and what it does not. If the difference between "the device recorded activity" and "the suspect was awake" still feels like a quibble, re-read "Limitations: knowing when to stop" before you ever testify to a sensor reading. Next, Chapter 35 — AI-Assisted Forensics and Deepfake Detection turns from the devices that record reality to the algorithms that help you triage it — and that can fabricate it.