IoT Forensics: Smart Home, Wearables, MQTT/CoAP and Firmware Analysis

IoT describes a category of network-connected devices, not a single device class. The forensic taxonomy splits along the use-case axis: consumer IoT covers smart home (speakers, cameras, locks, thermostats, lights) and wearables (fitness bands, smartwatches); industrial IoT (IIoT) covers SCADA, ICS, sensors and actuators in factories and utilities; automotive IoT covers connected cars and telematics units; medical IoT covers implants, monitors and hospital devices; agricultural IoT covers soil sensors and drone agriculture. The architectural pattern is shared: a constrained device talks to a gateway or directly to a cloud over a low-power protocol, and the user reaches the device through a phone app that authenticates to the same cloud.

The three storage locations determine where an investigator directs their acquisition effort. On-device storage is usually a few megabytes of SQLite or flat files on internal flash; an Alexa Echo holds only the last few seconds of wake-word buffer and a small queued-utterance cache. Gateway or hub storage holds slightly more: a Samsung SmartThings hub or an Apple HomePod acting as a Home hub keeps a few days of automation logs. Cloud storage holds everything: Alexa Voice History keeps every recognised request, Ring keeps every motion-triggered clip for the user's subscription window (often 60 days), Fitbit keeps every heart-rate sample synced through the Google account that now owns Fitbit. For most consumer IoT investigations the cloud holds the substantive evidence; the physical device indicates what accounts and APIs to pursue.

In India, the CP Plus and Hikvision DVR ecosystem is the most common local-storage camera family an examiner encounters. These devices, sold by the thousand under various branded and unbranded labels in every commercial market in India, write to local disks (usually a 1 to 4 TB SATA drive) and frequently to a vendor cloud if the customer paid for the subscription. The DVR's web UI sits on the local LAN and is reachable from outside if the owner forwarded port 80 or 8080 (extremely common), with a default admin password the owner often did not change. Cross-link to DVR/NVR forensics for fuller coverage of the storage-format and timestamp-anchoring side.

MQTT is the dominant IoT messaging protocol for cloud-bound telemetry and home automation. The architecture is publish/subscribe: devices publish messages to topics on a central broker, and clients (other devices, mobile apps, cloud back-ends) subscribe to topics they care about. The broker enforces no semantic structure; topics are slash-separated strings like home/livingroom/temperature or factory/line3/sensor7/pressure. MQTT runs over TCP on port 1883 (plain) or port 8883 (with TLS). The protocol is defined in OASIS MQTT 5.0 (2019); the older 3.1.1 (2014) is still widely deployed.

The primary forensic entry point for MQTT is the broker. A 2024 Shodan crawl identified more than 105,000 internet-exposed MQTT brokers requiring no authentication. An investigator with permission to query the broker can subscribe to the wildcard topic # and receive every published message; numerous breach disclosures and supply-chain incidents have been identified through this method. CVE-2017-7651 (Mosquitto memory exhaustion via crafted CONNECT packet), CVE-2018-12551 (Mosquitto authentication bypass via malformed password file) and several others document the protocol's implementation history. For incident response, capturing port 1883 or 8883 traffic on a network tap shows the device's command-and-control conversation in real time.

CoAP serves as the constrained-device alternative to MQTT. RFC 7252 defines a RESTful protocol over UDP, using GET, POST, PUT and DELETE on URIs of the form coap://device.example/sensors/temperature. UDP base port is 5683; DTLS-secured CoAP runs on 5684. CoAP supports observe (a server-pushed subscription model analogous to HTTP long-polling) and block-wise transfer for messages larger than a single UDP datagram. Because CoAP runs on UDP, it is amplifiable for DDoS reflection: a small CoAP request can elicit a response roughly 34x larger on average, a vector exploited in several 2018 to 2020 DDoS waves.

The Indian anchor: a 2024 advisory from the Indian Computer Emergency Response Team (CERT-In) named exposed MQTT brokers in Indian factory and warehouse deployments as a recurring intrusion vector. The advisory specifically called out the practice of standing up Mosquitto or EMQ X for an industrial pilot, exposing port 1883 to the internet for "easy integration", and leaving the deployment in that configuration after the pilot ended. CERT-In's 2024 sample identified 1,247 exposed MQTT brokers traceable to Indian ASNs; 89 percent allowed anonymous subscription to the wildcard topic.

Smart speakers hold negligible on-device evidence. The Echo, Google Nest and HomePod each buffer roughly five seconds of audio after wake-word detection, ship it to the vendor cloud for recognition, and discard the local copy within minutes. The substantive evidence is the cloud: Amazon's Voice History API (accessible by the user at alexa.amazon.in/spa/index.html#settings/dialogs and by Amazon under a production order) contains the recognised text and the audio of every request, with timestamps. Google's My Activity holds the equivalent for Nest and Google Home. Apple's HomePod stores requests anonymised against a random identifier that rotates; production responses for HomePod traffic are accordingly limited.

Smart cameras split into local-storage and cloud-storage families. Ring (Amazon-owned) records to the Ring cloud, retained for the subscription's storage window (60 days basic, 180 days plus). A production order to Amazon for Ring data returns motion clips, doorbell-press events and the user-shared Neighbors-app posts. Wyze, Arlo and Eufy are similar. The local-storage family includes most CP Plus and Hikvision DVRs and most older Mi cameras; these write to a MicroSD card or an attached SATA drive and require a physical seizure. CP Plus DVRs use a proprietary H.264 container that requires the vendor's CMS player or a forensic parser (DVR Examiner, Amped FIVE) for timestamp-correct playback.

Wearables generate dense sensor data. Apple Watch syncs to the paired iPhone every few minutes; the on-device evidence is the recent buffer, the paired-phone iOS HealthKit database carries weeks of detail, and iCloud Health (E2E-encrypted by default) carries the long history. Mi Band and boAt sync to the Mi Fit or boAt Crest app on the paired phone and onward to the vendor cloud; the data set includes heart rate, step count, sleep stages, GPS for the smartwatch variants, and increasingly SpO2 and stress estimates. Fitbit is now owned by Google; Fitbit data flows into the user's Google account and is accessible through Google Takeout. A US homicide conviction turned on a Fitbit activity trace that showed the victim moving for roughly an hour after the time the husband claimed she was shot, contradicting his account; equivalent Indian cases have not been publicly reported, but the data path is the same.

The Indian anchor: a Mumbai harassment matter under IPC Section 354B admitted Mi Band step-count and location records pulled from the Xiaomi Mi Fit cloud through a CrPC 91 order to Xiaomi India's nodal officer, showing the accused's claimed alibi (he was at home, 14 km away) was inconsistent with the steps-and-GPS record (he had walked 3.2 km in a route that passed within 200 m of the complainant's address). The court admitted the record under BSA Section 63 with the cell's examiner certificate.

When the vendor cloud is inaccessible (banned vendor, defunct vendor, region-locked data, or data encrypted at rest in the cloud), analysis shifts to the device itself. Firmware analysis follows a four-step pipeline: acquire the firmware, extract the file system, reverse the binaries, locate the credentials and the storage formats.

Acquisition has four common paths. Vendor download is the easiest: many IoT firmwares are published on the vendor's website or recoverable from a customer-portal account. Network capture during an over-the-air update intercepts the binary as it travels from the vendor to the device, useful when the device is in service and an update can be triggered. Chip-off, where the flash chip is desoldered and read in a programmer (Xeltek SuperPro, RT809H), is the highest-fidelity path for a damaged or non-cooperative device. In-circuit programming through an SOIC-8 clip on SPI flash, or through an ISP pad set on eMMC, recovers the image without desoldering when the layout allows.

UART is the serial debug interface most commonly encountered on consumer IoT boards. Most consumer IoT boards expose four pads or pins labelled VCC, GND, TX, RX (sometimes just TX/RX/GND), typically clocking at 115200, 57600 or 9600 baud, 8N1. A USB-TTL adapter (FTDI FT232, CP2102, or the Bus Pirate) connected with TX-RX crossed gives the examiner a serial console. On most low-end devices the console is an unauthenticated Linux root shell; on others it is the bootloader (U-Boot, often interruptible by spacebar at boot), from which a printenv followed by an md.b memory dump reveals the kernel command line, the bootargs, and frequently the rootfs partition that can be dumped over TFTP or directly read with mmc read.

JTAG provides a deeper hardware interface than UART. The four-pin TCK, TMS, TDI, TDO (with optional TRST and SRST) presents the CPU's boundary-scan chain to a tool such as the SEGGER J-Link, Bus Pirate, or OpenOCD on a Raspberry Pi Pico. The tool halts the CPU, reads RAM and flash through the scan chain, and on cooperative chipsets reflashes the firmware. JTAG-Finder and JTAGulator help locate JTAG test points on an unmarked board.

1. Acquire firmware
   Vendor download (easiest), network capture during OTA, in-circuit SPI or eMMC read with an SOIC-8 clip or ISP adapter, or chip-off if other paths fail. Hash the raw image (SHA-256) and store the original; work on a copy only.
2. Run binwalk
   binwalk -e firmware.bin extracts known file system signatures (squashfs, JFFS2, UBIFS, ext2/3/4, FAT, gzip, LZMA, certificates). For modern stripped images add binwalk -E for entropy analysis (high entropy regions point to encryption or packed code) and binwalk -A for ARM/MIPS/x86 architecture fingerprinting.
3. Mount the file system
   mount -o loop _firmware.bin.extracted/squashfs-root.img /mnt for SquashFS images, or unsquashfs for read-only extraction. Examine /etc/passwd and /etc/shadow for credentials, /etc/init.d/ for startup scripts, and /www/ or /usr/share/www/ for web UI sources.
4. Reverse target binaries in Ghidra
   ghidraRun, import the binary, run auto-analysis with the appropriate ARM/MIPS processor, and search for hard-coded credentials (strings + xref), update-URL endpoints, AES keys (entropy + format), and the device's MQTT/CoAP endpoint configuration. Binary Ninja, IDA Pro and radare2 are equivalent alternatives.
5. Compare against known-good
   If the vendor publishes a hash or signed image, compare the recovered image's SHA-256 to the published value. A mismatch indicates field modification (malware, supply-chain compromise). For unsigned firmware, compare against a reference image pulled from a clean device of the same model.

The Indian anchor for firmware analysis is the CP Plus and Hikvision DVR family. Multiple 2023 and 2024 advisories from CERT-In documented backdoor accounts, hard-coded credentials and update-without-authentication flaws in DVR firmware widely deployed across Indian small businesses. The forensic examiner asked to verify whether a DVR has been compromised in a specific incident typically begins with binwalk on the firmware image (recovered from the device's flash or from the vendor portal), looks for added users in /etc/passwd, looks for inbound shell binaries in /usr/bin or /sbin, and compares network captures against a known-good baseline. Cross-link to malware forensics for the post-firmware-extraction reverse-engineering side.

IoT security failure modes are well-documented and recur across device categories. Default credentials top the list: Mirai's source code released in October 2016 listed 64 username/password pairs ("root/xc3511", "admin/admin", "root/vizxv", "root/anko"), and a 2025 Shodan scan still finds tens of thousands of devices accepting those exact pairs. Hard-coded credentials in firmware are the second: a vendor leaves a debug account in /etc/passwd or hard-codes an API key in a binary, and every device of that model shares the same secret. Unencrypted firmware updates are the third: a device fetching its update over HTTP from a vendor URL trusts a network-positioned attacker. Weak authentication on management interfaces is the fourth: an MQTT broker on port 1883 with no client-certificate requirement accepts any client.

The attack patterns Mirai demonstrated in 2016 have continued to appear in subsequent botnets. The October 2016 attacks (Krebs at 620 Gbps, OVH at 1.1 Tbps, Dyn at 1.2 Tbps) used 600,000 devices, almost all of them rebranded XiongMai DVRs, routers and IP cameras with credentials the customer never changed. The follow-on variants (Hajime, Satori, Reaper, Mozi) used the same 64-credential dictionary plus a few new exploits. The 2024 to 2025 Indian incident landscape shows the same pattern: a Tamil Nadu ISP's customer-edge routers, deployed in 2018 to 2020 with default Telnet enabled, were drafted into a Mozi-variant botnet in 2024 and used as proxies for credential-stuffing attacks against Indian banking apps. CERT-In's empanelled responders ran an emergency credential-rotation campaign over four months.

The forensic challenges specific to IoT investigations arise from the architecture of the devices themselves. Data volatility: most consumer IoT devices clear their local cache on reboot, and the IO often arrives after the device has been power-cycled. Device heterogeneity: a single residential premises can have 30 to 50 IoT devices from 15 different vendors, each with its own protocol, cloud and app. Limited storage: the on-device evidence window is hours to days for most consumer devices, far shorter than the investigation timeline. Lack of standards: there is no IoT-equivalent of ISO 27037 covering acquisition; SWGDE 2020 published an IoT supplement but vendor-specific procedures vary widely. Vendor cooperation: some vendors (Apple, Google, Amazon) have established LE channels; others (smaller Chinese OEMs, defunct startups) have no published contact and no incentive to respond. Limited tooling for forensic workflows: Cellebrite and Magnet have IoT modules but coverage is partial; chip-off and UART skills are required for the long tail.

The Indian anchor: a 2024 case at a Bengaluru police cyber cell illustrated all five challenges. A residence raid identified 38 IoT devices including three Mi cameras, two CP Plus DVRs, eight Philips Hue bulbs, a Samsung SmartThings hub, two Echo Dot speakers, a Google Nest Hub, four Mi Band wearables across the family, and an assortment of smart plugs from no-name vendors. The cell's examiner triaged the devices by likely evidence weight: the Mi cameras for video, the Echo Dot for voice queries, the SmartThings hub for automation logs, and the wearables for movement timelines. Devices from no-name vendors were photographed, identified by FCC ID where possible, and set aside as a secondary tier; the primary acquisition completed within the BNSS 193 statutory window.

IoT evidence in Indian proceedings is governed by two distinct legal layers. The first is the admissibility layer under the Bharatiya Sakshya Adhiniyam 2023 (BSA), which from 1 July 2024 replaced the Indian Evidence Act 1872. Section 63 of BSA (the successor to IEA Section 65B) governs the admissibility of electronic records. Sub-section 4 requires a certificate from a person in responsible charge of the device or system that produced the record, identifying the record, the device, the regular use of the device, and the manner in which the record was produced. IoT evidence (Alexa Voice History, Ring video, Mi Band sensor logs, DVR footage) is electronic record under BSA Section 2(1)(e); the Section 63 certificate is mandatory.

The second is the data-protection layer under the Digital Personal Data Protection Act 2023 (DPDP). The DPDP Act applies to processing of digital personal data in India (Section 3). Smart home device makers, app operators and cloud back-ends are data fiduciaries under Section 2(i), with obligations including consent (Section 6), purpose limitation (Section 8(3)), storage limitation (Section 8(7)), and breach notification to the Data Protection Board (Section 8(6)). For forensic purposes, the DPDP Act's law enforcement exemption under Section 17 permits processing for prevention, detection, investigation or prosecution of any offence; the IO obtaining IoT data under a valid BNSS 91 order does not need separate DPDP consent from the data principal.

The BSA and DPDP layers interact in two situations the examiner should anticipate. First, when the IO is acquiring the device under a search warrant and the device's data is owned by someone other than the suspect (a domestic worker's wearable in a household raid, a tenant's Echo in a landlord's premises), the third party retains DPDP rights and the IO should document the seizure with their rights logged. Second, when the IO is asking a vendor to produce data under BNSS 91, the vendor's obligation to comply (under IT Act 69 if an SSMI, under BNSS 91 generally) overrides DPDP consent because Section 17 applies; the vendor is the data fiduciary and the IO is the lawful recipient.

The Indian anchor: in 2024 a sessions court in Pune admitted CP Plus DVR footage from a shop's external camera as direct evidence of an assault outside the shop. The court rejected the defence's challenge that the footage timestamp had not been independently verified by issuing a finding that the BSA Section 63 certificate from the shop owner, identifying the DVR as in regular use and the footage as produced in the ordinary course, sufficed; the additional defence argument that the DPDP Act had not been complied with for the third-party victims captured in the footage was rejected on Section 17 grounds. BSA Section 63 and DPDP Act Section 17 together constitute the standard legal framework for IoT-collected evidence in Indian criminal proceedings.