Mobile, IoT and Embedded Device Forensics

Introduction and Context

Digital evidence is no longer confined to desktop computers and enterprise servers. Smartphones, smart watches, vehicle systems, domestic assistants, medical devices, cameras, routers, industrial controllers and other embedded systems continuously create, process and exchange information. These devices may reveal a person’s movements, relationships, health condition, work activities, financial transactions and interaction with the physical environment. At the same time, they present difficult forensic problems: fragmented storage, proprietary formats, encryption, volatile memory, secure hardware, cloud dependence and rapidly changing software ecosystems.

Mobile, Internet of Things (IoT) and embedded-device forensics is the disciplined process of identifying, preserving, acquiring, examining, analysing and reporting digital evidence from such systems. The objective is not merely to extract data. It is to establish what data existed, how it was generated, whether it is reliable, how it relates to other evidence, and whether the acquisition and interpretation process can withstand technical and legal scrutiny.

A modern device should be treated as part of an ecosystem rather than as an isolated object. A smartphone may synchronise with a wearable, a vehicle, a cellular provider, application servers, a cloud backup and a home Wi-Fi network. Consequently, a forensic examination may require a combination of device acquisition, account-based collection, network analysis, cloud preservation and correlation with external sources.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Distinguish logical, file-system, physical and cloud-assisted extraction methods.

2. Explain the architecture and evidential significance of mobile, wearable, IoT and embedded devices.

3. Identify important evidence locations involving applications, files, communications, locations and sensors.

4. Evaluate encryption, proprietary formats, volatile data and ecosystem dependencies.

5. Design a defensible acquisition and analysis strategy while protecting privacy.

6. Correlate data from multiple devices and assess reliability, provenance and uncertainty.

7. Apply professional, ethical, legal and governance principles to contemporary device investigations.

1. Device Ecosystems and Evidential Architecture

1.1 From isolated devices to distributed systems

A device ecosystem normally contains several layers:

• Sensing layer: accelerometers, gyroscopes, microphones, cameras, GPS receivers, biometric sensors and environmental sensors.
• Device layer: operating system, firmware, local storage, secure elements and application data.
• Communication layer: cellular, Wi-Fi, Bluetooth, NFC, Zigbee, Z-Wave, Thread, LoRaWAN, USB and proprietary radio protocols.
• Gateway layer: smartphones, home hubs, routers, vehicle gateways or industrial edge computers.
• Cloud and service layer: vendor accounts, synchronisation services, application programming interfaces, databases and notification systems.
• Human and organisational layer: users, administrators, service providers, employers and other individuals whose information may be present.

Evidence can be duplicated, transformed or deleted at each layer. A fitness watch may record raw sensor samples, while its mobile application stores daily summaries and the vendor cloud retains a different aggregation. A router may record a device association but not the content of communications. These records are related but not interchangeable.

1.2 Important evidential properties

Four properties are particularly important:

Provenance concerns the origin and handling history of data. Investigators should document who collected it, from which device or account, using which tool and under what conditions.

Integrity concerns whether data has changed. Cryptographic hashes can demonstrate that a forensic image or exported file has remained unchanged after acquisition. A hash does not, by itself, prove that the original device data was truthful or that the acquisition tool interpreted it correctly.

Temporal validity concerns timestamps, time zones, clock drift, daylight-saving changes and server-side processing. A displayed time may be local time, UTC, device time or an application-rendered conversion.

Context concerns the circumstances under which data was created. A location point may represent a phone carried by another person, a cached location, a geofence event or a server inference rather than a direct GPS observation.

2. Extraction Methods and Their Evidential Trade-offs

No single acquisition method is universally superior. The appropriate method depends on the device state, investigative authority, evidence objective, risk of alteration, available tools and expected legal scrutiny.

2.1 Logical extraction

Logical extraction obtains data through operating-system or application interfaces. Examples include an authorised backup, synchronisation protocol, mobile-device management export or vendor-supported diagnostic interface.

It commonly recovers contacts, messages, calendars, media, application databases, device settings and selected system records. It is usually comparatively fast and less invasive than lower-level methods. It may also be safer when a device is operational and encryption keys are available through the logged-in state.

Its principal weakness is selectivity. Deleted records, unallocated storage, protected application containers, system partitions and unsupported artefacts may be omitted. A logical backup may also reflect what an application chooses to expose rather than the complete underlying storage.

2.2 File-system extraction

File-system extraction acquires files and directory structures, metadata, permissions, databases and selected operating-system artefacts. It provides more context than a simple logical backup and may expose application caches, configuration files, logs and indexes.

The method may be performed through an authorised debugging interface, a privileged agent, a recovery environment or a forensic tool exploiting a supported or documented access mechanism. It can reveal records unavailable through ordinary backup interfaces, but access may depend on operating-system version, device model, boot state and encryption status.

File-system acquisition does not necessarily recover deleted data. It normally captures allocated files and file-system metadata, although remnants may sometimes exist in databases, journals, caches or backups.

2.3 Physical extraction

Physical extraction attempts to acquire a lower-level representation of storage, such as a bitstream or partition image. It may provide access to unallocated areas, deleted fragments, file-system structures and low-level system partitions.

Traditional methods include chip-off acquisition, test-point access and specialised bootloader procedures. These approaches can be technically invasive and may damage a device, alter volatile state or fail because modern storage uses encryption and hardware-bound keys. On many contemporary smartphones, a raw image without the correct cryptographic keys is of limited evidential value.

Physical extraction must not be assumed to be inherently more complete or more reliable. It can produce large quantities of difficult-to-interpret data, and errors in handling flash translation layers, wear levelling or proprietary storage may affect reconstruction.

2.4 Cloud-assisted acquisition

Cloud-assisted acquisition obtains evidence from vendor services, account portals, application APIs, backups, synchronisation stores or legally compelled provider disclosures. It may recover data absent from the seized device, including historical location records, account activity, remote backups, device inventories, messages and server-side event logs.

Cloud evidence has distinctive issues. Data may be distributed across jurisdictions, retained for varying periods, transformed by server processes or affected by account-sharing. A provider export may be an application-level representation rather than a complete database. Investigators should preserve the original export, record the collection time and method, document account scope and obtain provider documentation where available.

Cloud collection is complementary rather than a replacement for device acquisition. A server record may confirm that an event was synchronised, but it may not establish who physically possessed the device at the relevant time.

2.5 Comparative decision framework

A defensible acquisition plan considers:

1. Objective: Is the question about current communications, deleted records, configuration, location history or device operation?

2. State: Is the device powered on, unlocked, locked, damaged, network-connected or subject to remote-wipe risk?

3. Volatility: Could shutdown destroy accessible keys, memory contents or session state?

4. Authority: Does the legal authority cover the device, associated accounts, cloud data and third-party information?

5. Risk: Could acquisition alter data, trigger synchronisation or expose private information?

6. Validation: Can the method and tool be tested on a comparable device and documented?

In practice, investigators frequently preserve the device, document its state, perform a validated logical or file-system acquisition, and then pursue cloud and ecosystem sources. More invasive methods are selected when the investigative question justifies them and the risks are controlled.

3. Evidence Locations and Interpretation

3.1 Applications and databases

Application data is commonly stored in SQLite databases, JSON documents, XML or binary preference files, caches, thumbnails, attachment directories and encrypted containers. Important records may include messages, drafts, search terms, account identifiers, notification history, application usage, ride records, payment events and peer-to-peer transfers.

The presence of a database record does not automatically establish that a user intentionally created it. Applications may generate previews, background synchronisation records, automated recommendations and telemetry. Investigators should distinguish user-generated content from system-generated metadata.

Database interpretation requires attention to schema versions, deleted rows, write-ahead logs, journal files, timestamps and application updates. A timestamp may be stored as Unix epoch seconds, epoch milliseconds, a vendor-specific epoch, ISO 8601 text or a localised string. Conversion must be documented and independently checked.

3.2 Communications

Communications evidence may exist in message databases, notification logs, contact lists, call records, email stores, media attachments, Bluetooth pairing records, Wi-Fi association histories and network-provider records. End-to-end encryption may protect message content while leaving metadata such as account identifiers, delivery times, notification events or backup traces.

A Bluetooth pairing record can show that devices were paired or known to each other, but it does not necessarily prove that the devices were communicating at a particular moment. Similarly, a Wi-Fi association indicates network access or attempted access, not necessarily that a particular application transmitted a specific message.

3.3 Location data

Location evidence may originate from GNSS, cellular positioning, Wi-Fi positioning, Bluetooth beacons, application geofences, photographs, map searches, transport applications and cloud history. Each source has different accuracy, sampling behaviour and error characteristics.

Investigators should preserve raw coordinates where available, record coordinate reference assumptions, examine horizontal accuracy fields and distinguish observed positions from inferred places. A sequence of points may be affected by interpolation, battery-saving policies, indoor signal loss or account synchronisation delay. Location evidence should therefore be expressed with appropriate uncertainty rather than as an unjustifiably precise route.

3.4 Sensors and wearables

Wearables may contain accelerometer, gyroscope, heart-rate, skin-temperature, blood-oxygen, barometer, sleep and exercise records. Raw sensor data may be overwritten quickly, while summaries remain in the application or cloud service.

Sensor outputs are measurements or algorithmic interpretations, not direct observations of behaviour. A step count can be affected by arm movement, device placement and vendor algorithms. A heart-rate value may be unavailable or unreliable during movement. Medical or biometric inferences require particular caution because they are sensitive, probabilistic and potentially regulated.

3.5 Embedded and IoT systems

Routers, cameras, smart locks, vehicle control units, industrial controllers and home hubs may contain firmware, configuration databases, event logs, user accounts and network credentials. Evidence can exist in NAND or eMMC storage, removable media, memory-mapped regions, cloud dashboards and companion applications.

Embedded systems often have limited interfaces, undocumented file systems and proprietary logging. Their clocks may be inaccurate or reset after power loss. A camera may store recordings locally, upload motion events to the cloud and notify a phone; each source should be correlated rather than treated as a single authoritative record.

4. Proprietary Formats, Encryption and Anti-Forensic Conditions

4.1 Proprietary formats

Vendor-specific formats may be undocumented, compressed, encrypted or version-dependent. A responsible approach includes preservation of the original artefact, identification of the producing application and version, controlled reverse engineering, comparison with known test data and documentation of every decoding assumption.

When an automated tool presents a human-readable interpretation, investigators should retain the underlying files and, where possible, validate the interpretation against raw database fields. Tool output is an interpretation layer, not the evidence itself.

4.2 Encryption and secure hardware

Modern devices may use full-volume encryption, file-based encryption, application-level encryption, secure enclaves, trusted execution environments and hardware-backed keys. Access can depend on a passcode, biometric state, user authentication, boot stage and device security policy.

Investigators must not assume that possession of storage chips yields readable content. Encryption keys may never be stored in recoverable form outside secure hardware. Attempts to bypass security can trigger lockout, data destruction or remote-wipe behaviour, and may violate law or organisational policy.

4.3 Volatile state and remote change

Running devices may contain session tokens, decrypted application data, network connections, memory-resident keys and notifications unavailable after shutdown. Conversely, leaving a device connected may permit remote deletion or synchronisation that changes evidence. The decision to isolate, maintain power, lock, shut down or place a device in a controlled network environment must be based on a documented risk assessment.

4.4 Deleted and residual data

Deletion may remove a database reference while leaving content in journal files, caches, thumbnails, backups or cloud copies. Flash storage complicates recovery because wear levelling and garbage collection may relocate or erase blocks. Therefore, absence of a record is not always proof that the event never occurred, and the existence of a residual fragment does not necessarily establish when or by whom it was created.

5. A Defensible Forensic Workflow

5.1 Preparation and legal scope

Before collection, define the investigative questions, identify devices and accounts, obtain appropriate authority, prepare validated tools and establish a secure evidence environment. The scope should address associated cloud services, wearable devices, routers and third-party data where relevant.

5.2 Identification and preservation

Record the device make, model, serial number, identifiers, physical condition, power state, screen state, displayed time, network connections, accessories and observed notifications. Photograph the device and its environment. Use tamper-evident packaging and maintain chain-of-custody documentation.

Preservation should minimise unnecessary interaction. The investigator should consider radio isolation, network containment, battery preservation and the possibility that a change in state will affect encryption keys or remote-wipe risk.

5.3 Acquisition and verification

Use the least intrusive method likely to answer the investigative question, while preserving the possibility of further examination. Record tool name and version, acquisition settings, errors, duration, device state and operator identity. Calculate cryptographic hashes for acquired files or images and preserve logs. Where practical, create more than one verified copy and conduct analysis on working copies.

5.4 Examination and analysis

Examination extracts and organises artefacts. Analysis interprets them in relation to the investigative question. These stages should be distinguishable. Investigators should build a timeline, identify contradictions, correlate independent sources and record alternative explanations.

A useful timeline may include device events, application events, network associations, cloud synchronisation, sensor observations and human actions. Clock offsets should be tested rather than assumed. Correlation increases confidence when independent sources agree, but common-source duplication should not be mistaken for independent confirmation.

5.5 Reporting

A report should state scope, authority, methods, device condition, acquisition limitations, tools and versions, validation approach, findings, uncertainty and supporting exhibits. It should distinguish facts directly observed in artefacts from interpretations and conclusions. Proprietary decoding assumptions, missing data and privacy-relevant material should be disclosed.

6. Applied Scenario: Smart-Home Intrusion Investigation

The following is an illustrative case. A homeowner reports that an unknown person entered a residence while the owner was travelling. The home contains a smart lock, an indoor camera, a Wi-Fi router, a voice assistant and the owner’s smartphone and smartwatch.

Background and problem

The smart lock reports an unlock event at 22:14. The camera application shows a motion notification at 22:16, but the video clip is missing from the phone. The homeowner claims that the phone was in another city. The investigative questions are whether the lock was operated locally or remotely, whether the camera detected a person, and whether the homeowner’s account or device was involved.

Analysis approach

Investigators first preserve the phone, smartwatch, router and hub, documenting power and network states. They obtain legal authority covering the physical devices and relevant vendor accounts. A logical acquisition of the phone recovers application databases and notification records. A file-system acquisition reveals a camera thumbnail cache and a lock-application event index. The smartwatch contains a heart-rate and movement summary, but not a complete raw sensor record.

The router logs show that the smart lock hub communicated with the vendor service at 22:13 and 22:14. The cloud account export identifies an unlock command but labels its origin only as “account session.” The phone’s account-security log records a login from an unfamiliar browser at 22:10. The phone itself was connected to a hotel Wi-Fi network in another city, and its local application log contains no corresponding unlock command. The camera thumbnail indicates motion, but the cloud service reports that the video was overwritten under its retention policy.

Findings and limitations

The evidence supports the conclusion that the smart-lock account was used to generate an unlock event, probably through the vendor service. It does not establish that the homeowner physically operated the phone or that the unfamiliar login was the intruder; account compromise, shared credentials and vendor-side attribution remain possible explanations. The missing camera recording cannot be reconstructed from the notification alone. The smartwatch data is not sufficient to determine the homeowner’s precise activity.

Learning points

The case demonstrates why ecosystem analysis is necessary. The lock, router, phone, cloud account and camera each contributed different evidence. It also illustrates the distinction between an account event and a human action, the importance of preserving short-retention cloud data, and the need to communicate uncertainty rather than overstate conclusions.

7. Privacy, Ethics and Governance

Mobile and IoT investigations routinely expose information about victims, family members, bystanders, employees and unrelated contacts. Collection should follow legality, necessity, proportionality and purpose limitation. Investigators should avoid broad inspection when a narrower acquisition can answer the question.

Sensitive categories may include health data, precise location, biometric identifiers, intimate communications, children’s information, passwords and credentials for unrelated systems. Access should be role-based, logged and limited to authorised personnel. Reports should redact irrelevant personal information where legally and operationally appropriate.

Cross-border cloud collection raises jurisdictional, transfer and retention issues. Organisations should maintain policies for evidence preservation, provider requests, secure storage, disclosure control and eventual destruction. Professional conduct also requires disclosure of tool limitations, failed acquisitions and exculpatory or contradictory evidence.

Artificial intelligence can assist with classification, clustering, image triage, anomaly detection, translation and timeline construction. However, AI-generated labels are investigative leads, not self-authenticating facts. Models may produce false positives, embed bias, obscure provenance or expose sensitive data to external services. Human review, reproducibility, audit logs and preservation of original artefacts remain essential.

8. Contemporary Developments and Best Practices

Important developments include stronger hardware-backed encryption, passkeys, edge processing, vehicle and medical-device connectivity, ultra-wideband ranging, Matter-based smart-home interoperability, eSIMs, satellite connectivity and increased use of ephemeral cloud data. These developments make ecosystem preservation and provider liaison more important.

Best practice includes:

• Build device-specific and version-specific validation datasets.
• Preserve original artefacts and retain acquisition logs.
• Use multiple evidence sources rather than relying on a single application display.
• Record time-zone, clock-drift and synchronisation assumptions.
• Treat cloud exports as scoped representations, not automatically complete images.
• Test proprietary parsers against known data and document reverse-engineering decisions.
• Separate raw evidence, decoded artefacts, analytical inferences and conclusions.
• Minimise collection and protect unrelated personal information.
• Reassess the acquisition plan when device state, encryption or remote-wipe risk changes.
• Report uncertainty, missing data and alternative explanations explicitly.

Chapter Summary

Mobile, wearable, IoT and embedded-device forensics requires analysis of distributed ecosystems rather than isolated hardware. Logical extraction is accessible and comparatively low risk but selective; file-system extraction provides richer structure; physical extraction may expose lower-level and residual data but faces encryption, flash-storage and device-damage limitations; cloud-assisted acquisition can recover synchronised or historical information but depends on provider processes, legal authority and retention.

Important evidence locations include application databases, caches, communications records, location sources, sensor summaries, network logs, firmware, embedded storage and cloud services. Interpretation must account for provenance, timestamps, application-generated records, proprietary formats, encryption, volatile state and uncertainty. A defensible workflow includes preparation, legal scoping, preservation, validated acquisition, verification, examination, correlation and transparent reporting.

Because these systems contain intimate information about many people, privacy, proportionality, security and governance are central professional responsibilities. Contemporary forensic practice combines technical capability with disciplined documentation, independent validation and cautious interpretation.

Key Terms

Provenance: The origin and documented handling history of digital evidence.

Logical extraction: Acquisition through operating-system, backup or application interfaces.

File-system extraction: Acquisition of files, directories, metadata and related system structures.

Physical extraction: Lower-level acquisition of storage or partitions, potentially including residual data.

Cloud-assisted acquisition: Collection from vendor accounts, synchronisation services, APIs or cloud backups.

Volatile data: Information that may disappear or change when power or system state changes.

Secure element: Hardware designed to protect cryptographic keys and sensitive operations.

File-based encryption: Encryption in which files or groups of files may have separately managed protection.

Proprietary format: A vendor-controlled data representation whose structure may not be publicly documented.

Wear levelling: Flash-storage technique that distributes writes across memory blocks.

Sensor fusion: Combining outputs from multiple sensors or positioning systems.

Metadata: Data describing an item, event, device or communication rather than its primary content.

Chain of custody: Documentation of evidence possession, transfer, protection and handling.

Artifact: A data item relevant to an investigation.

Cloud synchronisation: Replication or processing of data between a device and a remote service.

Remote wipe: A command or process that deletes or disables data on a device remotely.

Timeline: An ordered representation of events derived from one or more evidence sources.

Purpose limitation: Restricting collection and use of personal data to defined legitimate purposes.

Review Questions

Short Answer Questions

1. What is the principal limitation of logical extraction?

2. Why does a physical image not necessarily provide readable evidence from a modern smartphone?

3. Name three possible sources of location evidence.

4. Why should a forensic tool’s decoded output be checked against underlying artefacts?

5. What is the difference between provenance and integrity?

Long Answer Questions

1. Compare logical, file-system, physical and cloud-assisted extraction methods, including their benefits, risks and appropriate uses.

2. Explain how a smartphone, wearable, router and cloud service may form a single evidential ecosystem.

3. Discuss the forensic significance of application databases, caches, notifications and synchronisation records.

4. Describe a defensible workflow for acquiring evidence from a powered-on, network-connected smartphone.

5. Analyse the ethical and governance issues created by health, location and communication data in IoT investigations.

Analytical / Application Questions

1. A smart lock records an unlock event, but the owner’s phone shows no matching local action. Design an investigation using device, router and cloud evidence, and identify at least three alternative explanations.

2. A wearable reports a high step count during an alleged physical assault. Evaluate what can and cannot be concluded from the sensor record, and identify additional evidence required.

3. An investigator has authority to examine a seized phone but not unrelated third-party cloud accounts. Propose a privacy-preserving acquisition strategy and explain how scope and proportionality should be maintained.

Multiple Choice Questions with Answers

Question 1

Which extraction method generally obtains data through an operating-system backup or application interface?

A. Logical extraction

B. Physical extraction

C. Chip-off extraction

D. Volatile-memory acquisition

Correct Answer: A. Logical extraction

Question 2

What is a major limitation of logical extraction?

A. It always damages the device

B. It may omit deleted or protected data

C. It cannot recover any application data

D. It requires removing storage chips

Correct Answer: B. It may omit deleted or protected data

Question 3

Why may a raw storage image from a modern smartphone be difficult to interpret?

A. The device has no file system

B. The display resolution is too low

C. Encryption keys may be protected by hardware

D. Cloud services prevent all local storage

Correct Answer: C. Encryption keys may be protected by hardware

Question 4

Which statement best describes a cloud export?

A. It is always a complete physical image of the provider’s infrastructure

B. It is an application-level representation that must be scoped and documented

C. It cannot contain historical information

D. It automatically proves who physically used a device

Correct Answer: B. It is an application-level representation that must be scoped and documented

Question 5

A Wi-Fi association record most directly demonstrates that a device:

A. Sent a particular message

B. Was associated with or attempted to access the network

C. Was physically held by a named person

D. Used GPS successfully

Correct Answer: B. Was associated with or attempted to access the network

Question 6

Which property concerns the origin and handling history of evidence?

A. Provenance

B. Compression

C. Interpolation

D. Sampling rate

Correct Answer: A. Provenance

Question 7

Why should sensor data be interpreted cautiously?

A. Sensors never record numerical values

B. Sensor outputs can be affected by placement, movement and algorithms

C. Sensor data is always manually entered

D. Sensors cannot be synchronised with applications

Correct Answer: B. Sensor outputs can be affected by placement, movement and algorithms

Question 8

What is the principal purpose of hashing an acquired forensic image?

A. To decrypt the image

B. To identify the device owner

C. To help demonstrate that the acquired copy has not changed

D. To recover deleted files

Correct Answer: C. To help demonstrate that the acquired copy has not changed

Question 9

Which practice best supports analysis of a proprietary format?

A. Relying only on an unexplained parser result

B. Discarding the original file after decoding

C. Testing the parser with known data and documenting assumptions

D. Treating every field as a user action

Correct Answer: C. Testing the parser with known data and documenting assumptions

Question 10

Why is ecosystem correlation valuable in an IoT investigation?

A. It guarantees that every record is independent

B. It allows different sources and limitations to be compared

C. It eliminates the need for legal authority

D. It proves that cloud timestamps are always correct

Correct Answer: B. It allows different sources and limitations to be compared