Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
Smart speakers, Ring and CP Plus cameras, Mi Band and boAt wearables, MQTT and CoAP protocols, binwalk and Ghidra firmware analysis, UART/JTAG/eMMC acquisition, and BSA Section 63 plus DPDP Act admissibility for IoT-collected evidence.
In October 2016 a botnet called Mirai, built from 600,000 IoT cameras, DVRs and home routers whose owners had never changed the factory password "admin/admin" or "root/xc3511", launched a 620 Gbps DDoS at Krebs on Security, a 1.1 Tbps attack on French host OVH, and the DNS provider Dyn outage that took half the US east coast off Twitter, Spotify and Reddit for an afternoon. The largest single source of compromised devices was a Chinese OEM, XiongMai Technologies, whose firmware was rebranded under dozens of CCTV labels sold across India under brands the buyer often could not name. Mirai was not a sophisticated piece of malware; it was a 64-credential dictionary attack against Telnet on port 23.
Nine years on, the Indian IoT estate is larger by an order of magnitude. CP Plus and Hikvision DVRs sit on shop counters in every Tier-2 city. Mi Band wearables outsell every other fitness device in the country. Alexa Echo speakers have moved into urban households. Each of these devices generates evidence that lives partly on the device, partly in a vendor cloud and partly on the user's phone. This topic covers the IoT forensics surface the working syllabus frames for Module 6: device taxonomy, where the data actually lives, MQTT and CoAP protocols, firmware extraction with binwalk and Ghidra, the UART/JTAG/eMMC acquisition stack, and the DPDP Act 2023 plus BSA Section 63 frame for IoT-collected personal data. Cross-link references run to mobile phone acquisition, DVR/NVR surveillance forensics, cloud forensics challenges and malware analysis.
Five device classes, three storage locations, one investigator's headache.
IoT is a label, not a 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 matter. 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 is the substantive evidence layer; the device is a pointer.
| Device class | On-device | Gateway/hub | Cloud |
|---|---|---|---|
| Smart speaker (Echo, Nest, HomePod) | Wake-word buffer (seconds) | N/A (or HomePod as hub) | Voice History API, full transcript + audio |
Publish/subscribe on TCP, REST on UDP, both with weak defaults.
MQTT is the dominant IoT messaging protocol for cloud-bound telemetry. 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 forensic surface of MQTT begins with the broker. A 2024 Shodan crawl identified more than 105,000 internet-exposed MQTT brokers requiring no authentication. The investigator with permission to query the broker can subscribe to the wildcard topic # and receive every published message; many breach disclosures and supply-chain incidents have surfaced through exactly this pattern. CVE-2017-7651 (Mosquitto memory leak), CVE-2018-12551 (EMQ X authentication bypass) 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 is the constrained-device alternative. 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 25-byte CoAP request can elicit a 24x larger response, used in several 2018 to 2020 DDoS waves.
| Property | MQTT | CoAP |
|---|---|---|
| Transport | TCP |
Three concrete subpoenas, three different APIs, three different retention windows.
Smart speakers carry almost no 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.
When the cloud route is closed, the chip is the next door.
When the device's cloud is unhelpful (banned vendor, dead vendor, region-locked data, encrypted-in-cloud), the examiner moves 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 debug pathway. 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 is the deeper interface. 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.
The defaults that built a 620 Gbps botnet are still shipping in 2026.
The IoT security failure modes are catalogued and predictable. 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.
Mirai's lessons remain unlearned. 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 in IoT investigations are structural. 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 examiner-friendly tools: Cellebrite and Magnet have IoT modules but coverage is partial; chip-off and UART skills are required for the long tail.
The statute caught up with the cameras around 2023; the camera owners are still catching up with the statute.
The Indian legal frame for IoT evidence operates at two 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 interaction matters in two situations. 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.
| Issue | Statute |
|---|
MQTT, the dominant IoT messaging protocol, operates on which transport and default port for unencrypted deployments?
| Smart camera (Ring, Wyze, CP Plus) | MicroSD ring buffer (24 to 168 hours) | NVR if present | Vendor cloud, 60 to 180 days at subscription tier |
| Wearable (Apple Watch, Mi Band, boAt) | Sensor logs (hours to weeks) | Paired phone app DB | iCloud/Google Fit/Mi Fit cloud, full history |
| Smart lock (August, Yale) | Last 32 to 256 events local | Hub | Vendor cloud, complete event log |
| Smart bulb (Philips Hue, Mi) | State only | Hue Bridge or Mi gateway | Vendor cloud, state changes timestamped |
| Industrial IoT sensor | Recent telemetry (minutes) | Edge gateway (hours) | Historian (years), SCADA HMI logs |
The Indian anchor here is the CP Plus and Hikvision DVR ecosystem. 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 the deep dive on the storage-format and timestamp-anchoring side.
| UDP |
| Default port | 1883 plain, 8883 TLS | 5683 plain, 5684 DTLS |
| Architecture | Publish/subscribe via broker | REST request/response |
| Message size | Up to 256 MB (with multi-byte length) | Up to 1152 bytes typical; larger via block-wise |
| Security | TLS in 8883 deployments; no auth in many defaults | DTLS in 5684; no auth in many defaults |
| Typical use | Cloud-bound telemetry, home automation | Constrained device-to-device, mesh |
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.
Wearables are the dense-data devices. 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. The 2024 conviction in a US homicide case that turned on a Fitbit heart-rate trace showing the victim's pulse stopping at a different moment than the husband's stated account is the headline example; equivalent Indian cases have not yet been publicly reported but the data path is identical.
The Indian anchor: a 2023 Mumbai harassment matter under BNS Section 76 admitted Mi Band step-count and location records pulled from the Xiaomi Mi Fit cloud through a BNSS 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.
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.
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.
| Practical implication |
|---|
| Admissibility of IoT record in court | BSA Section 63 | Section 63(4) certificate from the device/system custodian, identifying the record and production process |
| Vendor compliance with production order | BNSS 91, IT Act 69, Intermediary Rules 2021 | BNSS 91 for domestic; IT Act 69 plus 2021 Rules for SSMIs; MLAT for foreign-region data |
| Personal data of third parties on the device | DPDP Act 2023, Section 17 | Section 17 law-enforcement exemption applies; third-party data rights documented but not blocking |
| Mass-surveillance concerns | Article 21 (Puttaswamy 2017), DPDP | Necessity and proportionality required; bulk IoT data collection beyond the warrant's scope is challengeable |
| Smart-camera footage of public space | BSA Section 63, BNSS 105 (seizure) | Admissible with certificate; chain of custody and timestamp anchoring critical |
| Cross-border IoT cloud data | MLAT, Telecom Act 2023 | Foreign-region data requires MLAT; some emerging Indian-data-residency rules may shift this |
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. The combination of BSA Section 63 plus DPDP Section 17 is now the standard frame for IoT-collected evidence in Indian criminal trials.