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.