← FIELD GUIDES

mobile / forensic field guide

iPhone forensics: from backup to supported finding

Define what an iOS backup contains, preserve its provenance and validate app artifacts before building a timeline.

INTERMEDIATE5 MIN READUpdated 26 September 2026

WHAT YOU WILL PRODUCE

An evidence inventory, a validated artifact and a qualified timeline.

Start with the question

An iPhone examination should answer a defined question, such as whether a supplied backup contains a particular conversation during a specified period. “Recover everything” is not a useful analytical scope. Record the device, relevant accounts, date range, authorized data sources and expected deliverable before reviewing private content.

This guide works with an authorized acquisition or a supplied training backup. It does not assume that a backup is a physical image or a complete representation of the phone. An examiner should be able to explain exactly which collection method produced the material.

Document the collection boundary

Record the model, OS build, acquisition time, timezone, device condition, backup method and tool version. Document whether the backup is encrypted and whether the necessary credentials were supplied through the agreed process. Keep credentials out of the report and evidence filenames.

Apple's Data Protection architecture makes device state and protection classes relevant to data availability. Avoid changing the state of an evidentiary device casually. If acquisition has not yet occurred, an examiner should select the method before an update, reset or restart alters the situation. See Apple's Data Protection overview.

Source Useful context Boundary to record
Device backup Included application and device records Backup settings, encryption and omitted data
Application export Content supplied by one application Export filters and loss of underlying metadata
Account export Server-side material within the export Collection date, account scope and retention
Screenshot Visible interface at capture time No complete database or interaction history

Keep each source separate in the inventory. Do not describe a cloud export as a device extraction.

Preserve a master and work on a copy

Assign an evidence identifier. Preserve the supplied container and its original manifest. Record SHA-256 hashes for the delivered files and keep a working copy separate from the preserved master. A large backup directory needs a file manifest, not an unexplained claim that “the folder was hashed.”

For a supplied container file, a Windows analysis workstation can calculate its hash without opening its content:

Get-FileHash -LiteralPath '.\evidence\training-backup.zip' -Algorithm SHA256

Save the hash, byte size, filename, collection context and analyst identifier in the case record. A matching hash supports consistency between copies; it does not establish who created the content or whether the original collection was complete.

Validate an application artifact

Use a parser compatible with the acquisition type and record its exact version. Select one finding relevant to the question and trace it back to its source file and record. Preserve the parser's raw output alongside the human-readable export.

For SQLite-based artifacts, account for the database and associated journal material. SQLite's write-ahead log can contain committed changes that have not yet been incorporated into the main database. Reviewing only the main file may therefore show an incomplete state. Preserve the supplied files together and use a documented, read-only examination workflow on copies; do not checkpoint or repair the evidence master. See SQLite's WAL documentation.

Record the table, row identifier, field meaning and any decoding assumptions. If a parser says “sent,” check what the underlying value represents in that app version. A cached message, a delivery receipt and a user composing a message are different observations.

Normalize time without losing the original

Keep the raw timestamp, its storage format, the interpreted timezone and the converted UTC value. Do not assume every timestamp in one export uses the same epoch or unit. Check a known benign event to validate the conversion.

For example, a synthetic record at 12:03:00 UTC+03:00 corresponds to 09:03:00 UTC. If the timezone is unknown, retain that uncertainty instead of silently assigning the workstation's timezone. Account for synchronization and device-clock differences when correlating sources.

Test an alternative explanation

Suppose a backup contains a picture in a messaging application's cache. That establishes the presence of those bytes in the collected backup. It does not by itself establish that the device owner viewed, created or intentionally sent the picture. Compare message records, attachment relationships and other independent evidence before drawing a stronger conclusion.

Absence also needs qualification. Data may have been excluded from the backup, deleted before collection, retained only in the cloud or unsupported by the parser. State which explanations were tested and which remain unresolved.

Practice and deliver

On a training backup, select one benign conversation. Produce a five-row timeline with raw time, UTC time, artifact locator, observation and limitation. Have another reviewer locate one row without using your screenshots.

The final packet should include the evidence inventory, acquisition boundary, hash manifest, tool versions, validated records and a short answer to the original question. Use the case worksheet and synthetic timeline as starting points.

For process background, NIST SP 800-101 Rev. 1 describes mobile preservation, examination and reporting. It dates from 2014; use it for method, not as a current device-support matrix.

← All field guidesExplore the video library ↗

Search the lab

NEWS / FORENSICS / FIELD GUIDES ESC