50 min read

> Where you are: Part V, Chapter 34 of 40. The advanced-topics chapters so far have pushed against the hard edges of the discipline — encryption you cannot break (Chapter 29), tampering you must detect (Chapter 30), evidence that lives on someone...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 34: IoT, Vehicle, and Embedded Device Forensics — Smart Homes, Cars, Wearables, and the Internet of Evidence

Where you are: Part V, Chapter 34 of 40. The advanced-topics chapters so far have pushed against the hard edges of the discipline — encryption you cannot break (Chapter 29), tampering you must detect (Chapter 30), evidence that lives on someone else's servers (Chapter 31), malware that fights back (Chapter 32), and money that hides on a public ledger (Chapter 33). This chapter pushes against a different edge: the explosion of devices. The computer you are investigating is no longer on a desk. It is on a wrist, in a doorbell, under a dashboard, inside a thermostat. Evidence has become ambient — generated continuously, by dozens of small machines, much of it tethered to a cloud you can only reach with legal process. This is the home chapter for what investigators have started calling the Internet of Evidence.

Learning paths: 🔍 Forensic Examiner owns this chapter — IoT, vehicle, and embedded artifacts are the fastest-growing evidence source in modern casework, and they corroborate (or demolish) timelines and alibis. 🛡️ Incident Response should read the embedded-extraction and firmware sections closely: compromised routers, cameras, and IoT botnet nodes are post-incident analysis targets, and an industrial sensor can be patient zero. 📜 Legal/eDiscovery must internalize that nearly everything here is cloud-tethered third-party data requiring a warrant, subpoena, or the owner's consent — the legal posture, not the technique, governs the case. 💾 Data Recovery gets real work too: dashcam footage on a vehicle's USB stick, a config blob inside router flash, photos on a wearable's companion-app cache, and the recovery of failed automotive eMMC are all legitimate recovery jobs.

The Internet of Evidence

Picture the scene a detective sketches on a whiteboard at the start of a modern death investigation. The victim lived alone in a two-bedroom condo. On the board the detective draws the body, the time it was found, the question mark over the time it happened — and then, almost as an afterthought, the devices. An Amazon Echo on the kitchen counter. A Ring doorbell at the front. A Nest thermostat in the hall. An August smart lock on the door. A Fitbit on the victim's wrist, still recording when the body was found. A car in the garage with a touchscreen that remembers every place it has been and every phone it has ever met. Each of those little machines has been keeping notes. None of them was designed to be evidence. All of them are.

This is the defining fact of the chapter. For most of this book, "the evidence" has been a single storage device you can detach, image, and reason about block by block — a hard drive in Chapter 8, an SSD in Chapter 9, a phone in Chapter 11 and Chapter 24. The Internet of Things scatters the evidence across a swarm of devices, each tiny, each proprietary, each speaking its own dialect, and most of them backhauling the interesting data to a vendor's cloud the instant it is created. The skills you have built still apply — image first, verify with hashes, analyze the copy, document everything, report accurately — but the terrain is unrecognizable, and the single most important shift in your thinking is this: the data you most want is often not on the device in your hand. It is on a server you can only reach with a warrant.

The phrase "the Internet of Evidence" is doing real work. A modern home, car, or body is instrumented with sensors that timestamp human activity at a granularity no previous era of investigation could touch. A heart rate every five seconds. A door event to the minute. A GPS breadcrumb every time the ignition turns. Spoken commands transcribed and stored. The promise is enormous — corroboration, timeline reconstruction, alibis confirmed and alibis broken. The peril is equally real: the formats are undocumented, the clocks disagree, the data is volatile, the cloud is a third party, and the device you are holding may be a model that did not exist eighteen months ago and will be discontinued eighteen months from now. This chapter teaches you to navigate that terrain across three domains — the smart home, the wearable, and the vehicle — and then drops to the hardware level, where you extract and analyze the firmware that runs all of it.

Where IoT data lives — and who controls it

Before any single device, build the mental model that governs all of them. IoT data lives in three places at once, and your access to each is wildly different.

        THE THREE TIERS OF IoT EVIDENCE
        ===============================

   TIER 1: ON THE DEVICE              TIER 2: ON THE COMPANION       TIER 3: IN THE VENDOR CLOUD
   (the "thing")                       (phone/PC app + local DB)      (the provider's servers)
   ───────────────────────             ─────────────────────────      ───────────────────────────
   Echo, Ring, Nest, lock,             Alexa app, Ring app,           Amazon, Google, Ring,
   Fitbit, watch, car head unit        Fitbit app, Garmin Connect     Fitbit/Google, vendor APIs
   Firmware, configs, Wi-Fi keys,      Cached records, account        THE MOTHER LODE: voice
   small ring buffers, recent          tokens, SQLite databases,      history, full video archive,
   cache, account binding.             thumbnails, last-sync data.    health history, trip logs.
   ACCESS: physical possession +       ACCESS: the phone/PC           ACCESS: legal process
   chip-off / UART / JTAG / SPI.       (Ch.11, Ch.16, Ch.24).         (warrant / subpoena) OR the
   Volatile; pull power = data loss.   Owner-cooperative or seized.   account owner's credentials.

The operational lesson is immediate. Tier 3 holds the richest data and is the hardest to reach: it requires either the account owner's cooperation (a recovery posture, or a consenting witness) or compulsory legal process served on the provider (a forensic posture — Chapter 25 and Chapter 31). Tier 2 — the companion app on the owner's phone or computer — is frequently the practical jackpot, because it caches a usable slice of the cloud data and you reach it with the device-forensics skills you already have. Tier 1 — the physical thing — holds less than you would hope (small buffers, configuration, binding secrets) and costs the most to extract, but it is the only tier that survives when the account is closed, the subscription lapses, or the vendor refuses.

Why This Matters. Theme four of this book is technology changes, principles don't. IoT is where that theme earns its keep. You will never memorize the artifact locations for every smart device — there are thousands of models and the catalog turns over every year. What you can do is apply an unchanging method: identify every device in scope, classify each one's data across the three tiers, determine the legal authority you have for each tier, acquire the most volatile and most perishable data first, normalize every device's clock to a common reference, and document every step because you cannot re-run a one-shot acquisition. The devices are disposable. The method is permanent.

The unifying challenges

Five problems recur across every IoT, vehicle, and embedded job, and naming them up front saves you from rediscovering each one the hard way.

Proprietary, undocumented formats. A hard drive uses NTFS or ext4 — file systems with published specifications and mature tools. A smart lock writes its event log in whatever schema its developers invented on a deadline, in a SQLite database with cryptic column names, or a binary blob with no documentation at all. You will spend real time reverse-engineering formats that no one has published, and a format you decode for one firmware version may change in the next.

No standard tooling. For a Windows image you reach for Autopsy, FTK, or EnCase (Chapter 36). For most IoT devices there is no equivalent. A handful of commercial tools cover the high-value targets — Cellebrite and Magnet have IoT modules, Berla's iVe dominates vehicles — but for the long tail you are working with general-purpose hardware tools (a logic analyzer, a chip programmer, binwalk) and your own scripts. Coverage is partial and lags the market badly.

Volatile and perishable data. Much of what matters lives in RAM or small ring buffers that pulling power destroys, or in a cloud account that auto-deletes on a retention timer. A voice assistant may keep only a rolling window. A camera without a subscription may not retain video at all. An EDR in a car overwrites its buffer unless a crash "locks" it. Once you decide on a course of action, hesitation costs evidence.

Cloud dependence and third-party control. The device is often a thin client for a service you do not control. Subpoena turnaround is measured in weeks to months; the provider may be foreign (triggering MLAT and the CLOUD Act — Appendix E); end-to-end encryption may put the data beyond even the provider's reach; and a retention timer may delete the records before your legal process arrives. Speed of legal action matters as much as speed of technical action.

Rapid device churn and you cannot always write-block. New models ship weekly; old ones are discontinued and their cloud services sunset, taking the data with them. And the foundational discipline of image first, work the copy (Chapter 5) is strained here: you cannot slip a hardware write-blocker between a soldered eMMC and its controller, you may have to power a device on to extract it, and some acquisitions physically alter or destroy the device. When you cannot guarantee non-alteration the way you can with a write-blocked disk, your documentation must carry the weight the write-blocker normally would.

Recovery vs. Forensics. A Ring doorbell clip is the perfect dual-purpose artifact. A homeowner who locked themselves out of their Ring account and wants last week's package-theft video back is a recovery job: you help them authenticate, pull the clip from their cloud, and you are done — speed and restoration. The same clip in a burglary investigation is forensics: you must obtain it through the owner's documented consent or a warrant served on Ring, preserve it with a hash, record the chain of custody, and be able to testify that the file you produce in court is bit-for-bit what the camera recorded. Identical bytes; opposite postures. Throughout this chapter the technique is often the same for both disciplines — what differs is your authority, your documentation, and whether the result has to survive cross-examination.

Smart-home forensics

The smart home is the densest concentration of the Internet of Evidence, and it rewards a methodical, device-by-device sweep. Walk the premises (physically or through the seizure inventory and the network's DHCP table) and enumerate everything that has a radio: voice assistants, cameras and doorbells, locks, thermostats, plugs, bulbs, sensors, and the hubs that tie them together. Each is a witness. The trick is knowing which witnesses keep useful notes and where they keep them.

Voice assistants: Amazon Alexa and Echo

Amazon's Echo line is the most studied smart-home forensic target, and the model generalizes. An Echo is a thin client. When you say the wake word, the device streams the audio that follows to Amazon's cloud, where speech recognition turns it into text and an intent, and the response comes back. The device itself stores remarkably little of lasting value — Wi-Fi credentials, account binding tokens, a small rolling buffer, device state. The evidence lives in Tier 3, in the Amazon account, and in Tier 2, in the Alexa companion app.

The cloud holds, for each interaction, a record with a timestamp, the recognized text (the transcription of what was said), the device that heard it (type and serial number), the intent Alexa derived, and a pointer to the stored audio recording of the utterance itself. A user can see a slice of this themselves under Settings → Alexa Privacy → Review Voice History in the app or at the Alexa privacy web portal. Investigators reach the full set through legal process to Amazon, or — in a consent or recovery scenario — through the account owner's credentials. Researchers documenting the Alexa ecosystem found these records exposed through the same unofficial cloud endpoints the app uses; an activity record looks, in essence, like this (illustrative, annotated):

  ALEXA VOICE-HISTORY RECORD (illustrative, from the account/cloud)
  ----------------------------------------------------------------
  {
    "id":               "A3xxxx#1700000000123",
    "creationTimestamp": 1700000000123,         <- epoch MILLISECONDS (UTC)
    "activityStatus":   "SUCCESS",
    "description":      "{\"summary\":\"turn off the bedroom lights\"}",
                                                  ^ the recognized utterance text
    "sourceDeviceIds":  [{ "deviceType":"A3S5BH2HU6VAYF",
                           "serialNumber":"G090xxxxxxxx12AB" }],
    "domain":           "Lighting",
    "audioUrl":         "/api/utterance/audio/data?recordKey=..."  <- the WAV/Opus clip
  }

Two artifacts in that record do disproportionate work. The creationTimestamp places a human in the room speaking at a specific instant — and note it is in milliseconds, a classic conversion trap (divide by 1000 before you treat it as Unix seconds). The summary text and the linked audio can establish presence, intent, state of mind, and the identity of the speaker by voice. Even routine utterances are evidentiary: "Alexa, set an alarm for 5 a.m." the night before, or a timer started at the moment a meal was cooked, anchors a timeline.

On the companion-app side (Tier 2), the Alexa app stores SQLite databases you can pull with the phone-forensics methods of Chapter 24. On Android the package is com.amazon.dee.app, and under its databases/ directory you will find map_data_storage.db (account identity — the registered name and email, device registrations) and DataStore.db (cached settings and state). These do not hold the full voice history, but they tie the physical device to a named account, which is exactly the link you need for attribution.

Legal Note. Voice recordings and account history held by Amazon are third-party records protected by the Stored Communications Act (18 U.S.C. §2701 et seq.). For content, that generally means a warrant; for non-content records, lesser process may apply. You cannot simply ask Amazon nicely, and you cannot log into a suspect's account without authority. The full framework — SCA, the third-party doctrine, Carpenter's implications for sensor data, and the CLOUD Act for data held abroad — is Chapter 25 and Appendix E. Serve process early: providers run retention timers, and a deletion you could have prevented with a timely preservation letter is evidence you destroyed by waiting.

War Story. The case that put Echo data on every investigator's radar was a 2015 Arkansas death investigation in Bentonville: a man was found dead in a hot tub, and police, knowing the home had an Echo, sought the device's recordings from Amazon. Amazon initially moved to quash the warrant on First Amendment grounds before the defendant himself consented to release the data; the murder charge was ultimately dropped for insufficient evidence. A 2018 New Hampshire double-homicide saw a judge order Amazon to produce Echo recordings outright. The lesson is not that the Echo "solved" either case — handled clinically, it mostly did not. The lesson is procedural: the data exists, it is reachable only through proper legal process, the provider will litigate the boundaries, and the device in the room is a witness whether or not anyone thought to interview it. Investigators who fail to identify and preserve it are leaving testimony on the table.

Voice assistants: Google Home and Assistant

Google's smart speakers follow the same thin-client architecture, and the same three-tier model. The richest store is the Google account's My Activity (myactivity.google.com), where voice and assistant interactions are logged with timestamps and, if the user enabled audio retention, the recordings themselves; Web & App Activity and Location History (Timeline) frequently corroborate. Reach it through the owner's credentials or legal process to Google. The Google Home app on the phone caches device lists, the home's structure (rooms, members), and recent activity; pull it as you would any app under Chapter 24. The pattern, by now, should feel familiar: little on the device, a cache in the app, the gold in the cloud, and a warrant standing between you and the gold.

Cameras and doorbells: Ring and the rest

Cameras and video doorbells are the most viscerally compelling IoT evidence — a doorbell that captures a suspect's face at a timestamped moment is worth a thousand log entries. They are also among the most cloud-dependent. A Ring device (Ring is an Amazon company) uploads motion-triggered and on-demand clips to Amazon's cloud, where they are stored as video objects in AWS — but only if the owner has a Ring Protect subscription. Without a subscription, many Ring devices offer live view but do not retain recordings at all, which means that in a no-subscription home the video you want may simply never have existed past the moment it streamed. Always determine subscription status before you build a case on footage that may not be there.

When recordings do exist, they live in the cloud and are reached through the owner's account or legal process to Ring. The Ring app (Tier 2) caches event history, clip thumbnails, the device list, and sharing activity. Two modern wrinkles change the calculus and you must know both. First, Ring offers end-to-end encryption as an opt-in: when enabled, clips are encrypted with keys held only on the owner's enrolled mobile devices, and Amazon cannot decrypt and produce them — the cloud analogue of the encryption wall you met with phones in Chapter 11. Second, the law-enforcement access path changed: in January 2024 Ring discontinued the Request for Assistance tool in its Neighbors app that had let police publicly solicit footage from owners, so police now generally obtain footage through the owner's voluntary sharing or formal legal process (with the usual exigent-circumstances exception). Treat any third-party who promises "police-portal" access with skepticism; the durable routes are consent and a warrant.

Other ecosystems behave similarly. Google Nest cameras store clips in the Google account (with a Nest Aware subscription); Wyze, Arlo, Eufy, and the rest each have their own cloud, their own subscription model, and their own app cache. And do not forget the humble local options: many cameras and NVRs (network video recorders) write to a microSD card or an on-premises hard drive. That local storage is recovery territory you already own — pop the card or pull the NVR disk, image it behind a write-blocker, and carve the video. Surveillance video files are often proprietary container formats, but they frequently wrap standard H.264/H.265 streams you can extract; the file-signature work of Chapter 7 and Appendix A applies.

Ethics Note. A camera in a home sees everything — children, intimate moments, the ordinary private life of people who never consented to be filmed by your investigation. Theme six of this book, the human cost is real, is acute here. Scope your access to what the warrant or consent authorizes and what the case requires; do not browse. When camera footage incidentally captures third parties or sensitive activity unrelated to your case, handle it with the same minimization discipline you would apply to any over-collection. The fact that the data is technically accessible never settles whether you are entitled to look at it — that question belongs to Chapter 28.

Smart locks

A smart lock is, evidentially, a beautifully simple device: it keeps a log of lock and unlock events, and many record who (which user code or phone) and when. August, Yale, Schlage, Kwikset, and Wyze locks push these events to their cloud and cache them in the app: "Unlocked by Jane's phone, 2:14 PM," "Locked automatically, 2:31 PM," "Front Door unlocked with code 4 (Cleaner), 9:02 AM." That log can establish presence, sequence, and access — who entered, when, and by what credential. It can corroborate or contradict a statement ("I never went back inside that night") with a timestamped event. As with the rest of the smart home, the authoritative store is the cloud account; the app cache is the practical shortcut; and the physical lock holds firmware and a small recent buffer reachable only with hardware techniques. Locks integrated through a hub (Z-Wave or Zigbee) may also have their events recorded by that hub, giving you a second, independent copy — and corroboration across two devices is far stronger than either alone.

Thermostats: occupancy as evidence

A thermostat does not seem like a witness until you realize what it senses. A Nest or ecobee logs temperature setpoint changes, schedules, and — crucially — occupancy and presence: Nest's "Home/Away Assist" and ecobee's motion sensors infer whether anyone is home, and the device records the transitions. A "Home → Away" transition at 6:50 p.m. and an "Away → Home" at 11:20 p.m. is a timeline of the dwelling's occupancy. Setpoint history can show someone adjusting the temperature — a human action at a timestamp. Nest is a Google product, so the data flows to the Google account and the same legal posture applies; ecobee keeps its history in its own cloud. The point generalizes: in the Internet of Evidence, even a device whose entire purpose is comfort is quietly logging human presence.

Hubs: the local goldmine

Hubs tie a smart home together, and they fall into two evidentially distinct camps. Cloud hubs like Samsung SmartThings route device events through the vendor's cloud; the event history lives in the SmartThings cloud and app, reachable on the usual cloud terms. Local hubs are the prize, and the standout is Home Assistant — open-source, self-hosted software that, by default, records the entire state history of every connected device into a local SQLite database, home-assistant_v2.db (larger installs use MariaDB/PostgreSQL). Because it is local, you reach it by imaging the device it runs on (a Raspberry Pi's SD card, a NAS, a mini-PC) — no provider, no warrant to a third party, no retention timer but the one the owner configured. The recorder component keeps a states table and an events table; a single query reconstructs the home's activity:

import sqlite3, datetime

con = sqlite3.connect("home-assistant_v2.db")
con.row_factory = sqlite3.Row
cur = con.cursor()

# Recent state changes for door, lock, motion, and presence entities.
cur.execute("""
    SELECT s.entity_id, s.state, s.last_updated_ts
    FROM   states s
    JOIN   states_meta m ON s.metadata_id = m.metadata_id
    WHERE  m.entity_id LIKE 'binary_sensor.%'   -- motion / door / window
       OR  m.entity_id LIKE 'lock.%'
       OR  m.entity_id LIKE 'device_tracker.%'  -- phone presence
    ORDER  BY s.last_updated_ts
""")
for r in cur.fetchall():
    # Home Assistant stores last_updated_ts as a Unix epoch float (UTC seconds).
    ts = datetime.datetime.fromtimestamp(r["last_updated_ts"], datetime.timezone.utc)
    print(f"{ts.isoformat()}  {r['entity_id']:32s} -> {r['state']}")

  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

That sequence is a near-complete narrative of a 40-minute nocturnal visit: phone arrives, door unlocks, the office is occupied for 37 minutes, door locks, phone leaves. No cloud, no subpoena — it was sitting on the hub.

Try This. If you run Home Assistant (or stand up a free instance), open a forensic copy of home-assistant_v2.db in any SQLite browser and explore the states, states_meta, and events tables. Note the schema changes across Home Assistant versions — older databases stored entity_id directly in states rather than in a states_meta lookup table, and last_updated as an ISO string rather than last_updated_ts as an epoch float. That schema drift, in software you can read the source of, is a gentle preview of the proprietary-format problem you will hit on closed devices where you cannot.

Chain of Custody. Smart-home evidence is acquired in two streams — physical devices and cloud accounts — and both need rigorous custody. For physical devices (a hub's SD card, an NVR disk, a microSD from a camera), image and hash exactly as in Chapter 14. For cloud returns, record what you requested, the legal instrument that compelled it, who at the provider produced it, the date, and the hash of the production set the moment it lands. The most common smart-home custody failure is not mishandling a hard drive — it is logging into a live account and browsing, which alters server-side "last viewed" state, can trip security notifications, and leaves you unable to prove you did not change anything. Capture, hash, then analyze the copy. The account is sacred for the same reason the original drive is.

Wearables: the body as a witness

If the smart home instruments a place, the wearable instruments a person. A fitness tracker or smartwatch records steps, heart rate, sleep, and — on many models — GPS location, continuously, strapped to a human body. As evidence, that is extraordinary: it can place a person in motion (or motionless) at a precise time, confirm an alibi, or break one. Several real cases have turned on exactly this, and they are worth understanding clinically because they illustrate both the power and the limits of the technique.

Fitbit

A Fitbit is a sensor that syncs to a phone, which syncs to the Fitbit cloud (Fitbit is now owned by Google). The device itself holds a rolling buffer of recent samples; the phone app caches more; the cloud holds the complete history — steps per minute, heart-rate samples, sleep stages, and on GPS-capable models, location tracks. Reach the history through the account (consent/credentials) or legal process to Google/Fitbit. The app on the phone stores SQLite databases under its package directory that cache recent intraday data; the cloud account, accessible to the user via data export, contains the authoritative record.

The evidentiary value is the timeline of the body. Two cases make the point. In a 2015 Connecticut case, a man told police an intruder shot his wife in the morning; her Fitbit, however, recorded her steps continuing — she moved over a thousand feet around the house — for roughly an hour after the time he claimed she had been killed. The device's record contradicted the human's account, and he was convicted of her murder years later. In a 2018 California case, a victim's Fitbit recorded her heart rate spiking and then stopping within a narrow window while a relative's vehicle was, per other evidence, at her home — establishing a time of death that framed the investigation. In both, the wearable did not "solve" anything by itself; it provided a timestamped physiological record that constrained the possible timelines and could be tested against everything else.

War Story. The phrase "the Fitbit broke his alibi" became shorthand for a genuine shift in investigation. The deeper lesson is theme three of this book — every action leaves a trace, and the absence of a trace is itself a trace — extended to the body. A living person generates a continuous stream of physiological breadcrumbs they are not even aware of; the cessation of that stream is itself an event with a timestamp. An examiner who knows to ask "was anyone in this case wearing a tracker, and what does its record say about when bodies were moving and when they stopped?" is asking a question that did not exist a generation ago and that suspects, even careful ones, almost never think to address.

Apple Watch

The Apple Watch is, forensically, an extension of its paired iPhone. Health and activity data the watch collects syncs into the iPhone's Health database, and that is where you analyze it: /private/var/mobile/Library/Health/healthdb_secure.sqlite (with healthdb.sqlite alongside it). It holds heart rate, steps, workouts, and — for recorded workouts — GPS tracks, in tables like samples, quantity_samples, workouts, and workout_activities, with associated location series. Because this data lives on the iPhone, you acquire it with the iPhone-forensics methods of Chapter 24; iCloud Health sync (and Apple's Advanced Data Protection) can put a copy in the cloud under the legal posture of Chapter 31.

One technical trap dominates Apple Watch and Health analysis: the epoch. Apple's databases store timestamps as Core Data / Mac absolute time — seconds since 2001-01-01 00:00:00 UTC, not the Unix 1970 epoch. A heart-rate sample stored as 700000000 is not 1992; add the offset (978,307,200 seconds) to get Unix time and you land in 2023. Get this wrong and your entire timeline shifts by 31 years — an error that is obvious at that magnitude but quietly corrupting if you only misjudge a time zone. Australian prosecutors in a 2016 Adelaide homicide relied on a victim's Apple Watch health and activity data to establish a time-of-death window that contradicted a witness's account of a prolonged confrontation; the case is a reminder that the watch's record is only as good as your conversion of its timestamps to a defensible, normalized reference.

Garmin

Garmin dominates the serious-athlete and outdoor market, and its devices are GPS-first, which makes them location goldmines. Garmin records activities in the FIT format (Flexible and Interoperable Data Transfer), a compact binary format from the ANT/Garmin ecosystem, stored on the device (mountable as USB mass storage on many models — pure recovery territory) and synced to Garmin Connect in the cloud. A FIT file is a small, well-structured binary you can parse, and its header is unmistakable:

  GARMIN .FIT FILE HEADER (14-byte variant)
  Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D   ASCII
  00000000  0E 20 1A 08 D4 96 00 00  2E 46 49 54 9D 4F   . ........FIT.O
            │  │  └─┬─┘ └────┬────┘  └────┬────┘ └─┬─┘
            │  │    │        │            │        └ header CRC-16
            │  │    │        │            └ ".FIT" signature (bytes 8-11)
            │  │    │        └ data size = 0x000096D4 (38,612 bytes), little-endian
            │  │    └ profile version 0x081A, little-endian
            │  └ protocol version 0x20 (2.0)
            └ header size 0x0E (14 bytes)

After the header come definition and data messages. The two fields you will extract most are timestamps and positions, and both have conversions you must get exactly right:

  • FIT timestamps are seconds since 1989-12-31 00:00:00 UTC (the Garmin epoch), not 1970. Add 631,065,600 to convert to Unix time.
  • Positions are stored in semicircles, not degrees. Convert with degrees = semicircles × (180 / 2³¹). Concretely, a stored position_lat of 500000000 semicircles is 500000000 × 180 / 2147483648 ≈ 41.91°.
EPOCH_FIT = 631065600           # seconds between 1970-01-01 and 1989-12-31 (UTC)
SEMI = 180.0 / 2**31            # semicircles -> degrees

def fit_time(ts):               # ts = raw FIT timestamp (uint32, seconds)
    import datetime
    return datetime.datetime.fromtimestamp(ts + EPOCH_FIT, datetime.timezone.utc)

def fit_latlon(semi):           # semi = raw position (int32, semicircles)
    return semi * SEMI

# A record message decoded from the FIT stream:
print(fit_time(1078000000))     # -> a UTC datetime in 2024
print(fit_latlon(500000000))    # -> 41.909...  degrees

A FIT activity is a breadcrumb trail: a point every second or few seconds with latitude, longitude, elevation, heart rate, and speed. For a runner or cyclist, that is a minute-by-minute map of where the body was. For an investigation, it can place a person on a specific path at a specific time with GPS precision — or show that they were nowhere near where they claimed.

Ethics Note. Wearable data is the most intimate evidence in this chapter: heart rate, sleep, menstrual cycles, sexual activity inferred from physiological patterns, mental-health signals, precise movements through the world. Handling it demands the clinical clarity this book insists on (tone principle three). Collect only what your authority and your case require; recognize that a wearable export can reveal a person's medical conditions and private life far beyond the question you are answering; and remember that the person whose body generated this data may be a victim, a suspect, or an entirely uninvolved third party. The human cost is never more literal than when your evidence is someone's heartbeat. The duty framework is Chapter 28.

Vehicle forensics: the car as a computer

A modern car is a network of dozens of computers on wheels, and it remembers an astonishing amount. Vehicle forensics is its own sub-discipline because a car holds three distinct data systems, each with different content, different acquisition methods, and different legal treatment. Confuse them and you will look for trip history in the crash recorder, or crash dynamics in the navigation system, and find neither.

        THE THREE DATA SYSTEMS IN A VEHICLE
        ===================================

   1) INFOTAINMENT + TELEMATICS            2) EVENT DATA RECORDER (EDR)        3) CONNECTED-CAR CLOUD
      (the head unit / IVI)                   (the "black box")                   (manufacturer servers)
      ───────────────────────────            ─────────────────────────────       ────────────────────────
      Nav history, GPS tracklogs,            ~5 seconds of pre-crash data:        Trip history, location,
      saved/recent destinations,             speed, throttle, brake, RPM,         remote commands, charge
      PAIRED PHONES (name, BT MAC,           seatbelt, airbag deploy, delta-V,    logs, OTA updates, cabin
      IMEI), synced CONTACTS / CALL          steering. Triggered by a crash       data (Tesla). Vast.
      LOGS / SMS, media, door &              event; overwrites unless locked.     ───────────────────────
      ignition events, Wi-Fi SSIDs.         ───────────────────────────────       ACCESS: legal process to
      ───────────────────────────            Read with BOSCH CDR tool via         the maker (subpoena /
      TOOL: Berla iVe. Stored on             OBD-II/DLC or direct to the          warrant). Third-party
      head-unit eMMC/flash.                  airbag module (ACM/SDM).             custodian.
      Regulated by 49 CFR Part 563.

Infotainment and telematics: Berla iVe

The infotainment system — the touchscreen "head unit," formally the In-Vehicle Infotainment (IVI) system — is the richest forensic target in the car, and the dominant tool for extracting it is Berla's iVe. iVe maintains a database of supported vehicles and the connectors and procedures for each; for a supported make and model it acquires the head unit's flash (sometimes in-vehicle through a diagnostic connector, sometimes by removing the unit and connecting directly) and parses the proprietary structures into a readable report. What it recovers is remarkable, and it falls into two families.

First, the car's own activity: navigation history (recent and saved destinations, favorites, and on many vehicles a GPS tracklog of where the car actually went, point by point), Wi-Fi networks the car connected to, and a stream of vehicle events — doors opening and closing, ignition on/off cycles, gear shifts, lights, sometimes tied to GPS coordinates and odometer readings. An ignition-on event at a location and time can place a specific vehicle at a specific spot.

Second — and this is what surprises people — the phones that met the car. When a phone pairs over Bluetooth, the head unit records the device: its friendly name ("John's iPhone"), its Bluetooth MAC address, often its serial number or IMEI, and the pairing and last-connection timestamps. And if the user allowed it, the car syncs the phone's data — the contact list, the call log (incoming, outgoing, missed, with numbers and times), and sometimes text messages — and caches it in the head unit. This means a car can hold a copy of a phone's contacts and call history that survives even if the phone is destroyed, wiped, or never recovered. A car that a suspect borrowed or rented can reveal which phone was inside it and what that phone's call log looked like at the time.

  iVe-STYLE EXTRACTION SUMMARY (illustrative, paired-device record)
  ----------------------------------------------------------------
  Connected Devices:
    Device name ......... "J. RIVERA iPhone"
    Bluetooth address ... 9C:35:EB:xx:xx:xx
    Device serial ....... F2LXXXXXXXXX
    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  (2024-03-04 .. 2024-03-11)

Tool Tip. iVe's coverage is broad but not universal, and it is make/model/year specific — the first question on any vehicle job is "is this vehicle supported, and at what acquisition level?" For unsupported vehicles, or to validate iVe's parsing, you drop to the hardware techniques in the next section: the head unit is a circuit board with an eMMC or NAND chip, a UART console, and often a JTAG interface, and you can image its storage directly. Cellebrite and others also field vehicle modules. As always, no single tool covers the long tail, and the examiner who understands the underlying flash can go where the GUI stops.

Recovery vs. Forensics. The same head-unit flash serves both disciplines. A collision-repair shop or a private owner who wants their saved navigation favorites and paired-device list back after a head-unit failure is a recovery job — image the eMMC, parse what you can, restore it. A detective reconstructing where a suspect's car went and which phone was inside it is forensics — the identical extraction, but acquired under a warrant, hashed, custody-documented, and parsed against a verified copy so the tracklog can be defended on the stand. One board, two postures.

The Event Data Recorder: the black box

Distinct from infotainment is the Event Data Recorder (EDR) — the automotive "black box." It is not a continuous trip logger; it is a crash recorder. Built into or associated with the airbag control module (variously the ACM, SDM, or RCM depending on the maker), the EDR continuously buffers a few seconds of vehicle dynamics and captures that buffer when a crash event triggers it (an airbag deployment, or a "near-deployment" event that crosses a threshold). The standardized data set — defined in the United States by NHTSA regulation 49 CFR Part 563 — includes roughly the five seconds before the event: vehicle speed, engine RPM and throttle position, brake on/off, steering input (on some), driver seatbelt status, airbag warning-lamp status, the change in velocity (delta-V) during the crash, and the count of events and ignition cycles. Federal rules do not mandate that every car have an EDR, but if one is present it must record this standard set, and in practice the vast majority of light vehicles do.

You do not read the EDR with iVe. The standard tool is the Bosch Crash Data Retrieval (CDR) system, which connects either through the vehicle's OBD-II diagnostic link connector (DLC) under the dash or, when the vehicle is too damaged to power up, directly to the airbag module on the bench. CDR outputs a standardized report of the captured event. Two cautions are critical. First, EDR data can be volatile: a "non-deployment" buffer may be overwritten by subsequent driving or cleared after a number of ignition cycles, so an EDR read is time-sensitive after a crash. Second, EDR data is a powerful but narrow window — five seconds of dynamics, not a trip history — and it is most defensible when corroborated by physical reconstruction. Authority to read it is also contested ground: several states and federal law treat EDR data as belonging to the vehicle owner, requiring consent or a warrant to retrieve it.

Connected-car cloud

The third system lives on the manufacturer's servers. Connected cars — Tesla most prominently, but also GM (OnStar), Ford, Toyota, BMW, and the rest — continuously upload telematics: location and trip history, remote command logs (lock/unlock, climate, summon), charge sessions, over-the-air update records, and, for Tesla, an unusually rich set including Autopilot/Full Self-Driving event data, Sentry Mode and dashcam clips, and cabin telemetry. This is third-party data: you reach it by serving legal process on the manufacturer (Chapter 31, Chapter 25), and turnaround and scope vary widely by maker. Note the recovery angle too: Tesla's dashcam and Sentry footage are written to a USB drive or local storage as ordinary video files — pop the drive and carve it like any flash media (Chapter 7). And note a genuine recovery failure mode: early Tesla MCUs used eMMC that wore out from excessive logging, bricking the unit — a hardware data-recovery problem in its own right, where the goal is to read a failing eMMC before it dies completely.

Legal Note. Vehicles occupy contested Fourth Amendment ground. The "automobile exception" historically lowered the expectation of privacy in a car's physical contents, but the digital contents — a paired phone's contacts, a tracklog of every place the car went, months of telematics — look far more like the phone data that Riley v. California (2014) protected and the location data that Carpenter v. United States (2018) protected. The conservative, defensible posture is to obtain a warrant specifically covering the vehicle's digital systems, and to keep the three systems legally distinct: consent or a warrant for the EDR, a warrant for the head unit's stored communications and location data, and separate process to the manufacturer for cloud telematics. The framework and the case law are Chapter 25 and Appendix E. Do not let the ease of plugging into an OBD-II port lull you into skipping the legal analysis.

Embedded and firmware extraction at the hardware level

When there is no app, no supported tool, and no cloud you can reach — or when you need to verify what a device actually does rather than what its vendor claims — you drop to the hardware. Every IoT device, camera, lock, router, and head unit is a small computer: a processor, some RAM, and non-volatile storage holding the firmware and configuration. Reaching that storage directly is the most technical work in this chapter, and it rests on four physical interfaces. (The flash-recovery foundations — NAND, eMMC, managed vs. raw flash — are in Chapter 9; this section applies them to embedded targets.)

        EMBEDDED ACCESS INTERFACES ON A TYPICAL IoT BOARD
        =================================================

   ┌──────────────────────────────────────────────────────────────┐
   │   [SoC / CPU]            [SPI NOR flash]        [eMMC / NAND]  │
   │      │  │                  8-pin SOIC            BGA package    │
   │   JTAG  UART               CS CLK DI DO          CLK CMD DAT0.. │
   │   TCK   TX  ── debug       (read with a clip     (ISP test pts  │
   │   TMS   RX     console      + flashrom, or        or chip-off,  │
   │   TDI   GND    (115200)     desolder + reader)    like a phone) │
   │   TDO                                                           │
   └──────────────────────────────────────────────────────────────┘
     UART  = talk to the running OS / bootloader (often a root shell)
     JTAG  = halt the CPU, read memory and flash via boundary scan
     SPI   = read the NOR flash chip directly (the firmware lives here on small devices)
     eMMC  = read managed NAND (larger devices); ISP test points or chip-off

UART: the serial console

UART (Universal Asynchronous Receiver/Transmitter) is the friendliest interface and the first you look for, because manufacturers leave it enabled with astonishing frequency. It is a serial console — the device's text output and, often, an interactive shell. Physically it is three or four pads or pins: TX (transmit), RX (receive), GND (ground), and sometimes VCC (power, which you do not connect — you only need TX/RX/GND). Logic levels are usually 3.3 V (sometimes 1.8 V); connecting a 5 V adapter can damage a 3.3 V device, so confirm the voltage first.

Finding the pads is half the job. Look for a group of three or four unpopulated holes or test points near the SoC. With a multimeter: GND has continuity to the board's ground plane; VCC sits at a steady 3.3 V; TX pulses (it spews boot text) and idles high; RX is comparatively quiet. A logic analyzer or a tool like the JTAGulator can confirm the pinout and the baud rate automatically. Then connect a USB-to-TTL adapter (FTDI, CP2102, or similar) — adapter TX to device RX, adapter RX to device TX, GND to GND — and open a terminal at the common baud rate (115200 is the usual suspect; also try 57600 and 9600):

# Identify the adapter, then attach a serial terminal.
dmesg | grep ttyUSB                 # e.g. ttyUSB0
picocom -b 115200 /dev/ttyUSB0      # or: screen /dev/ttyUSB0 115200
                                    # or: minicom -D /dev/ttyUSB0 -b 115200

What appears is the boot log, and it is a forensic treasure: the bootloader and its version, the CPU and flash layout, the partition map, the kernel command line, and — alarmingly often — either an interactive U-Boot bootloader prompt or a fully privileged root shell with no password. From a U-Boot prompt you can frequently dump the flash to the console or to a TFTP server; from a root shell you can read configuration, keys, logs, and the file system directly:

  U-Boot 1.1.4 (Mar 11 2019 - 10:02:55)
  DRAM:  64 MB
  Flash: 16 MB  (Winbond W25Q128 SPI NOR)
  ...
  Hit any key to stop autoboot:  0
  =>                                <- bootloader prompt: md / sf read / nand dump
  ...
  BusyBox v1.23.2 built-in shell (ash)
  root@device:/#                    <- a root shell, no password. Read everything.

War Story. An incident-response team analyzing a compromised IP camera that had been recruited into a botnet skipped the exotic tooling entirely. They spotted four unlabeled pads next to the SoC, identified TX/RX/GND with a multimeter in two minutes, attached a $6 USB-TTL adapter, and were dropped straight into a root shell by the camera's own firmware — no password, no exploit. From there they pulled the malware, the config, and the attacker's callback address directly off the running device. The lesson mirrors the mobile chapter's "exhaust the I/O problem first": before you reach for a chip programmer or a hot-air station, check whether the manufacturer left the front door open. On embedded devices, they very often did.

JTAG: boundary scan

When UART is disabled or gives you only read-only boot text, JTAG (named for the Joint Test Action Group) is the next escalation. Originally a boundary-scan standard for testing solder joints, JTAG also lets you halt the CPU and read and write memory and flash through it. The interface is the Test Access Port (TAP): TCK (clock), TMS (mode select), TDI (data in), TDO (data out), and optional TRST/SRST (resets). Finding an undocumented JTAG pinout is the classic use of the JTAGulator (Joe Grand's hardware tool) or the JTAGenum firmware on a microcontroller, which brute-force the pin assignments. Once you have the pinout, an adapter (an FT2232-based interface, a J-Link, or a Bus Pirate) plus OpenOCD drives it:

openocd -f interface/ftdi/ft2232h.cfg -f target/<soc>.cfg
# In the OpenOCD telnet/console:
#   > halt
#   > flash banks
#   > dump_image flash_dump.bin 0x00000000 0x01000000   # read 16 MB of flash

JTAG is slower than reading a chip directly and is increasingly fused off in production devices (manufacturers blow a one-time fuse to disable it), so it is more useful on older or cheaper hardware. When it works, it gives you a clean dump of flash and the ability to read live RAM — the latter occasionally the only route to keys held only in memory.

SPI flash dumping

On small IoT devices — routers, cameras, locks, many sensors — the entire firmware lives on a single SPI NOR flash chip, usually an 8-pin SOIC or WSON package. Common parts are the Winbond W25Q family (W25Q32 = 4 MB, W25Q64 = 8 MB, W25Q128 = 16 MB), Macronix MX25L, and GigaDevice GD25Q. The pinout is standard: CS (chip select), CLK/SCK (clock), DI/MOSI (data in), DO/MISO (data out), WP (write protect), HOLD, VCC, GND. You can read it two ways.

In-circuit with a SOIC-8 test clip (a Pomona 5250 is the classic) attached to the chip's legs and wired to an inexpensive programmer (a CH341A is the famous $5 option; better programmers exist), driving it with flashrom:

flashrom -p ch341a_spi                       # detect: prints the JEDEC ID and chip name
# Found Winbond flash chip "W25Q128.V" (16384 kB, SPI) on ch341a_spi.
flashrom -p ch341a_spi -r firmware_dump.bin  # read the entire chip to a file
sha256sum firmware_dump.bin                  # hash immediately (custody)

In-circuit reads can be unreliable when the device's own CPU is powered and contending for the bus; tricks include holding the CPU in reset, cutting power to the rest of the board while powering only the flash through the clip, or — when all else fails — desoldering the chip and reading it in a socketed adapter. The chip identifies itself: the SPI JEDEC ID command (0x9F) returns a manufacturer byte and device ID (Winbond is 0xEF; a W25Q128 reports 0xEF 0x40 0x18), and the read command is 0x03 (or 0x0B fast read). Once dumped, the firmware image is yours to analyze.

  Inside a dumped firmware image, the config/NVRAM region is frequently plaintext:
  Offset    00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F   ASCII
  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.
            ^ hard-coded credentials and Wi-Fi keys sitting in the clear in flash

Chip-off for embedded eMMC

Larger embedded devices (vehicle head units, higher-end cameras, hubs) use eMMC — managed NAND with an embedded controller — rather than a small SPI chip. Reading it is the same problem you met in Chapter 9 and Chapter 11: either solder to the eMMC's clock/command/data test points and read it in place (the ISP method, with an eMMC-capable reader), or perform a full chip-off — reflow the BGA package off the board, re-ball it, and read it in a socket. Because eMMC is managed, the dump is already a logical image (the controller handled ECC, wear-leveling, and bad-block remapping), which spares you the raw-NAND reconstruction nightmare. The same caveat from the mobile chapter applies: if the embedded storage is encrypted (some head units and higher-security devices are), chip-off yields ciphertext — but the bulk of cheap IoT devices and many head units store data in the clear, and there the dump is immediately useful.

Analyzing proprietary firmware

A flash dump is a blob; the analysis turns it into evidence. The indispensable first tool is binwalk, which scans for known signatures, reports the layout, and can carve out embedded file systems. Firmware is typically a bootloader, a kernel (often a uImage wrapping an LZMA- or gzip-compressed kernel), and a root file system (very commonly SquashFS, sometimes JFFS2 or CramFS), laid end to end:

binwalk firmware_dump.bin            # identify components by signature
binwalk -E firmware_dump.bin         # entropy: flat = code/config, ~1.0 = compressed/encrypted
binwalk -e firmware_dump.bin         # extract/carve the file systems out

  DECIMAL     HEXADECIMAL   DESCRIPTION
  ------------------------------------------------------------------------------
  0           0x0           uImage header, OS: Linux, CPU: MIPS, type: OS Kernel,
                            compression: lzma, name: "Linux Kernel Image"
  64          0x40          LZMA compressed data
  1310720     0x140000      Squashfs filesystem, little endian, version 4.0,
                            compression: xz, blocksize: 131072

The signatures themselves are worth knowing, because you will recognize them in a hex view even when a tool does not:

  uImage   : 27 05 19 56            (big-endian magic 0x27051956, at offset 0)
  SquashFS : 68 73 71 73  "hsqs"    (little-endian, 0x73717368)
  JFFS2    : 85 19                  (node magic 0x1985, little-endian on disk)
  CramFS   : 45 3D CD 28            (magic 0x28cd3d45)
  gzip     : 1F 8B 08
  TRX      : 48 44 52 30  "HDR0"    (Broadcom firmware container)

Once you have carved the root file system — for SquashFS, unsquashfs firmware.squashfs — you have the device's entire software as ordinary files, and the evidence hunt is the same as on any Linux system (Chapter 17): /etc/passwd and /etc/shadow for hard-coded accounts, /etc/ for configuration and Wi-Fi keys, embedded private keys and certificates (grep -r "BEGIN .*PRIVATE KEY"), the web UI under /www, startup scripts, and strings across the binaries for URLs, credentials, and version markers. For deeper analysis you can emulate the firmware with the Firmware Analysis Toolkit or firmadyne (QEMU under the hood) to interact with the device's services without the hardware. For a malware case, this is where you recover the implant the device was carrying (Chapter 32); for an IoT-botnet incident, it is where you find the command-and-control address.

Recovery vs. Forensics. A firmware dump serves both disciplines, often in the same afternoon. As recovery, the dump lets you extract a device's configuration, Wi-Fi keys, or stored content when the device's UI is dead — restoring access the owner lost. As forensics, the same dump is evidence: you hash it the instant you read it (you cannot write-block a chip you are actively reading, so the hash and your contemporaneous notes are your integrity proof), you document the chip's JEDEC ID and the read method, and you analyze the carved file system on a verified copy. The dual lens is identical to the disk-imaging discipline of Chapter 14 — only the medium is a soldered chip instead of a removable drive.

Limitation. Hardware extraction is genuinely destructive-risk work. A slip with a hot-air station lifts pads or cooks the chip; an over-voltage on a UART line kills the SoC; an in-circuit read can corrupt a chip if the CPU writes mid-read. On a one-of-a-kind evidence device, that is unacceptable risk taken blind. Practice on identical sacrificial units first, document everything, and know your bench's limits (theme five) — if chip-off is beyond your shop, send it to a lab that does it daily rather than destroy the only copy of the evidence learning on it.

Worked example: the after-hours timeline the laptop could not hide

Return to anchor case two — the departing senior mechanical engineer suspected of copying the firm's proprietary turbine-housing CAD files before joining a competitor. In Chapter 16 you built the core of the case from the Windows workstation: USB device history in the registry showing a personal external drive connected late on a Saturday night, LNK and Jump List artifacts pointing at the CAD folder, $FILE_NAME MFT timestamps exposing the file-access times the suspect tried to backdate, and the CCleaner artifacts proving an anti-forensic tool had run. The suspect's defense, relayed through counsel, is simple: that USB activity is a glitch in your tooling; I was home asleep that night, nowhere near the office. The Windows image places a device at the workstation at 2:11 a.m. The defense disputes that it places the person there. The Internet of Evidence closes that gap.

The firm issued the engineer a company vehicle and, through a voluntary corporate wellness program, a fitness tracker — and the building uses a smart-lock access system. Three independent devices, three independent clocks, none of them touched by the CCleaner run on the laptop, because anti-forensics that scrubs a Windows workstation cannot reach a car's head unit, a wearable's cloud, or a door controller. You acquire each under the appropriate authority (the company owns the vehicle and the access system; the wellness data requires careful, separately documented consent — see the note below) and you normalize every timestamp to UTC. The picture assembles:

  CORRELATED TIMELINE (all normalized to UTC; sources independent)
  ---------------------------------------------------------------
  02:08:51  Vehicle head unit (Berla iVe): car arrives at 1100 INDUSTRIAL PKWY (the office);
            ignition-off event logged, last destination = office, tracklog ends here;
            paired phone "J. RIVERA iPhone" (BT 9C:35:EB:..) was connected during the drive
  02:09:30  Smart-lock access log: rear entrance unlocked with badge #4471 (engineer's)
  02:11:14  Windows registry (Ch.16): USB external drive S/N ...A7F3 connected
  02:11:50  $FILE_NAME MFT (Ch.16): turbine-housing CAD folder accessed
  02:18:00  Fitbit (wellness account): heart rate 96 bpm, step activity — subject AWAKE & MOVING,
            not the resting/sleep pattern claimed for that hour
  02:46:09  Windows: USB external drive safely removed
  02:49:30  Smart-lock access log: rear entrance locked
  02:50:06  Vehicle: ignition on; tracklog departs office, routes toward engineer's home

No single device proves the case. Together they are devastating: the car carrying the engineer's paired phone arrived at the office and left forty minutes later; the engineer's own badge unlocked the door on the way in and out; the wearable shows a body awake and active, not asleep at home; and all of it brackets, to the minute, the USB insertion and CAD-folder access the Windows artifacts already established. The defense's "the laptop tooling glitched" cannot survive four independent clocks agreeing. This is theme three made concrete — every action leaves a trace — multiplied across the Internet of Evidence, and it is why a thorough examiner now inventories the room and the car and the wrist, not just the computer.

A note on method that the example exists to teach: the timeline only works because you normalized the clocks. The car's head unit was set to local time with no daylight-saving awareness; the Fitbit cloud stored UTC milliseconds; the smart lock used the Unix epoch; the Windows artifacts used FILETIME (100-nanosecond intervals since 1601). Each had to be converted to a single reference before they could be compared, and a single botched conversion would have made the devices appear to disagree and handed the defense a real argument. Clock normalization is the unglamorous heart of multi-device IoT forensics, and it belongs in your report (Chapter 26) and is set up properly in Chapter 21 — Timeline Analysis.

# Normalize the zoo of IoT/forensic epochs to UTC before correlating.
import datetime as dt
UTC = dt.timezone.utc

def from_unix(s):     return dt.datetime.fromtimestamp(s, UTC)                 # locks, HA, most IoT
def from_unix_ms(ms): return dt.datetime.fromtimestamp(ms/1000, UTC)          # Alexa, Fitbit cloud
def from_apple(s):    return dt.datetime.fromtimestamp(s + 978307200, UTC)    # Apple Health (2001 epoch)
def from_fit(s):      return dt.datetime.fromtimestamp(s + 631065600, UTC)    # Garmin FIT (1989 epoch)
def from_filetime(ft):                                                         # Windows FILETIME (1601)
    return dt.datetime(1601,1,1,tzinfo=UTC) + dt.timedelta(microseconds=ft/10)
# GPS time (e.g., from a tracklog) runs ~18 leap seconds ahead of UTC as of this writing —
# subtract the current leap-second offset when a source reports raw GPS time.

Legal Note. The wellness-tracker data in this example is the legally delicate piece. A corporate wellness program's health data is governed by consent terms, employment law, and potentially HIPAA-adjacent and state privacy rules; "the company gave them the device" does not automatically grant the employer forensic access to the employee's heart rate. In a real matter you would route that acquisition through counsel, rely on the documented program consent and any applicable policy, and be prepared to defend the authority separately from the vehicle and access-system data, which the company owns outright. The vehicle's paired-phone data raises its own Riley/Carpenter questions if the matter turns criminal. The technical correlation is only as admissible as the authority behind each source — which is exactly why posture, not technique, governs this chapter.

Common mistakes

  • Pulling the power first. The reflex to "secure" a device by unplugging it destroys volatile evidence — RAM-resident keys, an unflushed buffer, a session that will not re-authenticate. For IoT, decide your acquisition order before you touch anything, and capture the perishable tier first (theme: the absence of a trace is itself a trace — and you may be the one who erased it).
  • Treating the device as the evidence and forgetting the cloud. On most IoT devices the rich data is in Tier 3. An examiner who images a Ring doorbell and stops has missed the archive. Send the preservation letter and the legal process to the provider early, before a retention timer deletes it.
  • Ignoring the companion app. The phone or PC running the device's app (Tier 2) is frequently the fastest route to usable data and is reachable with skills you already have. Inventory the apps on every seized phone for IoT companions.
  • Mishandling timestamps and time zones. Apple's 2001 epoch, Garmin's 1989 epoch, milliseconds vs. seconds, local time with no DST flag, GPS leap seconds — every device lies about time in its own way. Normalize everything to UTC and prove your conversions, or your timeline will be wrong by 31 years or one hour, and the second error is the dangerous one.
  • Confusing the car's three systems. Looking for trip history in the EDR or crash dynamics in the infotainment unit wastes time and signals inexperience. Infotainment/telematics (iVe), EDR (Bosch CDR), and cloud telematics (the maker) are three different sources with three different tools and three different legal authorities.
  • Assuming a subscription means footage exists. A camera or doorbell without an active cloud subscription may retain nothing. Confirm retention before you build a theory on video that was never saved.
  • Skipping the legal analysis because the port is right there. An OBD-II connector or an exposed UART pad is an invitation, not authorization. The ease of physical access never substitutes for the warrant, consent, or process the data requires.
  • Cooking the only copy. Practicing chip-off or hot-air rework on the one evidence device is how irreplaceable evidence dies. Practice on sacrificial twins; refer beyond your bench's competence.
  • Browsing a live account. Logging into a suspect's or victim's cloud account to "look around" alters server-side state, can trigger alerts, and forfeits your ability to prove you changed nothing. Capture and hash through proper process, then analyze the copy.

Limitations: knowing when to stop

IoT, vehicle, and embedded forensics is the chapter where theme five bites in several directions at once, and honesty about the ceiling protects your credibility. Cloud data you cannot compel is gone. If a provider is foreign and uncooperative, if end-to-end encryption (Ring E2EE, iCloud ADP, the strong cases) puts data beyond even the provider, or if a retention timer deleted records before your process arrived, the data is unrecoverable by any means available to you — and "we were unable to obtain the cloud records" is a complete, professional finding. Proprietary formats may resist decoding. Some devices store data in undocumented binary blobs that you cannot fully parse within the time and budget of a case; partial decoding, clearly bounded, is a legitimate result, not a failure. Hardware extraction can fail or destroy. Chip-off and rework carry real risk, encrypted embedded storage yields ciphertext, and a fused-off JTAG or a disabled UART can close the only hardware door. Device churn outruns tooling. A device released last quarter may have no tool support and no published research; you will sometimes face a target no one has ever documented, and "no method currently exists to extract this model" is the truth on a given date.

And the deepest limitation is interpretive. A wearable shows a heart rate, not who was wearing it. A car's tracklog shows where the car went, not who drove it. A door log shows a badge, not the person holding it. A voice record shows words spoken, not always by whom. IoT evidence is powerful precisely because it is granular and continuous — but it is circumstantial, and the leap from "this device recorded this" to "this person did this" is an inference that must be argued, corroborated, and defended, never assumed. The examiner who overstates what a sensor proves — who tells the court the Fitbit shows the suspect was awake rather than that the device on the wrist recorded activity — has stepped beyond the data and invited the cross-examination that ends careers (Chapter 27). State exactly what the device recorded; let corroboration and argument carry the rest.

Progressive project: add an IoT or embedded source to the case file

Your Forensic Case File (the running project from Chapter 5 onward) has, by now, a disk image, a recovered-file inventory, browser and email artifacts, a timeline, and an anti-forensics finding. Add an Internet-of-Evidence source and integrate it:

  1. Identify and classify. From the case scenario, list every IoT, wearable, vehicle, or embedded device in scope. For each, classify its data across the three tiers (on-device, companion app, cloud) and state, for each tier, the legal authority you would need — consent, a warrant, or third-party process.
  2. Acquire 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 (you could not write-block it — document why and how you preserved integrity instead).
  3. Decode and normalize. Parse the artifact, extract its timestamped events, and convert every timestamp to UTC, showing your epoch conversions. Add the events to your master timeline beside the disk-derived artifacts.
  4. State the inference carefully. For each IoT event, write one sentence of exactly what the device recorded and a separate sentence of what it does and does not prove about a person — practicing the discipline you will need on the stand.
  5. Log it. Record the source, its hash, the authority, and the conversions in your evidence log, ready for the report in Chapter 26 and the capstone in Chapter 38.

The lesson for the case file mirrors the lesson for the discipline: the most persuasive timelines are corroborated across independent devices with independent clocks, and the examiner's job is to harvest those independent witnesses, normalize their disagreeing notions of time, and state plainly what each one does and does not prove.

Summary

The Internet of Things has turned the world into a field of small, continuous witnesses, and this chapter taught you to interview them. The governing model is three tiers: a little data on the device itself, a usable cache in the companion app, and the rich archive in the vendor's cloud — with your access to each governed less by technique than by authority, because most of the gold is third-party data behind a warrant. In the smart home, voice assistants (Alexa/Echo, Google) store transcriptions and recordings in the cloud and bind to a named account through the app; cameras and doorbells (Ring and the rest) hold video in the cloud — if a subscription exists and end-to-end encryption does not — with the law-enforcement access path now running through consent or formal process; smart locks log who entered and when; thermostats quietly record occupancy; and hubs split into cloud services and local goldmines like Home Assistant's home-assistant_v2.db. On the body, wearables — Fitbit, Apple Watch, Garmin — record steps, heart rate, sleep, and GPS, and have broken real alibis by showing when a body was moving and when it stopped; each carries a timestamp trap (Apple's 2001 epoch, Garmin's 1989 FIT epoch, milliseconds versus seconds) that you must convert correctly. In the vehicle, three distinct systems demand three distinct approaches: infotainment and telematics (Berla iVe — navigation tracklogs, and the paired phones, contacts, and call logs the car cached), the EDR "black box" (Bosch CDR, five seconds of crash dynamics under 49 CFR Part 563), and the manufacturer's connected-car cloud (legal process). And beneath all of it is the hardware: UART consoles that often drop to a root shell, JTAG boundary scan, SPI flash read in-circuit with a clip and flashrom, eMMC chip-off, and firmware analysis with binwalk, unsquashfs, and strings that turns a flash blob into readable evidence. The unifying challenges — proprietary formats, no standard tooling, volatile and cloud-tethered data, the inability to write-block soldered storage, and relentless device churn — never disappear; you meet them with an unchanging method and rigorous documentation. The worked example closed the loop: when a suspect disputed that a Windows artifact placed a person at the scene, four independent devices with four independent clocks — car, badge, wearable, and laptop — agreed to the minute, because anti-forensics on one machine cannot reach the Internet of Evidence around it. Image first where you can, normalize every clock, state exactly what each sensor recorded and no more, and respect the wall where the cloud, the encryption, or the format simply will not yield.

You can now: - Classify any IoT, wearable, or vehicle data source across the three tiers (device, app, cloud) and identify the legal authority each tier requires. - Locate and interpret smart-home evidence — Alexa/Google voice history, Ring/Nest video, smart-lock and thermostat logs, and the local Home Assistant database — under the correct legal posture. - Extract and analyze wearable evidence from Fitbit, Apple Watch (Health database), and Garmin (FIT files), converting each device's epoch correctly and stating its evidentiary limits. - Distinguish a vehicle's three data systems and choose the right tool for each — Berla iVe for infotainment/telematics, Bosch CDR for the EDR, and legal process for connected-car cloud data. - Perform hardware-level extraction — UART, JTAG, SPI flash dumping, and eMMC chip-off — and analyze proprietary firmware with binwalk, unsquashfs, and strings. - Build a corroborated, clock-normalized timeline across multiple independent devices, and state precisely what each sensor proves and what it does not.

What's next. Chapter 35 — AI-Assisted Forensics and Deepfake Detection — confronts the flip side of all this evidence: when machine learning helps you triage oceans of IoT and disk data faster than any human could, and when the same technology fabricates the photos, voices, and videos you will be asked to authenticate — the frontier where the examiner must prove not just what a file says, but whether it is real at all.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.