iPhone Investigation
Forensic examination of an iPhone in a simulated theft and fraud scenario conducted as a classroom study project. Recovered deleted SMS/iMessage threads, Safari browsing history, geolocation data from Photos EXIF metadata, call logs, and app usage timestamps. Produced an activity timeline with full chain-of-custody documentation per legal admissibility standards — practising the process used in real digital forensics investigations.
This study project was structured around a fictional case scenario provided as part of a digital forensics course exercise. The scenario: an iPhone belonging to a fictional suspect had been seized as potential evidence in a fraud and theft investigation. The device was provided in a classroom/study context with simulated case data pre-loaded to represent a realistic investigation.
CASE REF: SIM-DFIR-2024-011 [STUDY PROJECT — SIMULATED DATA]
────────────────────────────────────────────────────────────────
DEVICE: iPhone (model withheld per study guidelines)
iOS version: 16.x
Storage: 64 GB
SCENARIO: Suspect alleged to have used the device to coordinate
a fraudulent online purchase scheme and a physical
theft. Case study asks analysts to recover evidence
of communications, location presence, and financial
transaction records from the device.
OBJECTIVE: Perform forensic acquisition, extract and analyse
relevant iOS artifacts, reconstruct a timeline of
key events, and produce admissibility-ready
documentation with hash verification.
────────────────────────────────────────────────────────────────
NOTE: All names, addresses, and identifying details in this
project are entirely fictional and generated for the
study exercise. No real personal data was used.
The four-phase forensic process followed in this study project mirrors the methodology used in professional digital forensics: acquire an evidence image without altering the original, preserve integrity through cryptographic hashing, analyse artifacts systematically, and produce structured documentation.
sms.db), Safari history (History.db), call logs (CallHistory.storedata), and location data. Used iMazing for human-readable views of messages and contacts. Parsed Photos EXIF data for geolocation coordinates.
The following iOS artifact categories were examined during the analysis phase. Each was sourced from a specific SQLite database or file within the iOS backup structure.
sms.db. SQLite message table retains rows even after UI deletion until VACUUM runs.History.db. Identified visits to payment and marketplace URLs.CallHistory.storedata. Recovered incoming, outgoing, and missed calls with timestamps, durations, and contact associations.com.apple.ScreenTime databases. Showed active app sessions during the incident window.AddressBook.sqlitedb) — recorded creation timestamps for contacts added in the 48-hour window around the alleged incident.The iOS backup structure stores most user data in SQLite databases organised under a 40-character SHA-1 hash folder naming scheme. Key database paths within a decrypted backup:
# Key SQLite databases within a decrypted iOS backup (relative paths) HomeDomain/Library/SMS/sms.db └── Tables: message, chat, attachment, handle HomeDomain/Library/Safari/History.db └── Tables: history_items, history_visits HomeDomain/Library/CallHistoryDB/CallHistory.storedata └── Tables: ZCALLRECORD HomeDomain/Library/AddressBook/AddressBook.sqlitedb └── Tables: ABPerson, ABMultiValue CameraRollDomain/Media/DCIM/ └── .jpg/.heic files — EXIF GPS coordinates embedded # Hash verification (performed on acquired backup archive) examiner@forensics-ws:~$ md5sum iphone_backup_SIM-DFIR-2024-011.zip a3f7d9e1b2c4f8a0e5d7c1b9f3e2d4a6 iphone_backup_SIM-DFIR-2024-011.zip examiner@forensics-ws:~$ sha256sum iphone_backup_SIM-DFIR-2024-011.zip e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 iphone_backup_SIM-DFIR-2024-011.zip [+] Hash recorded on chain-of-custody form at acquisition time. Verified again before analysis.
Chain-of-custody documentation ensures that evidence integrity can be demonstrated in legal proceedings. Even in a study scenario, practising this discipline builds the habit of treating digital evidence as legally sensitive from the moment of acquisition. The following table shows the custody log maintained throughout this study project.
| Step | Action | Tool / Method | Hash Verified | Notes |
|---|---|---|---|---|
| CoC-01 | Device received and photographed | Camera (physical documentation) | N/A | Device placed in Faraday bag prior to acquisition to prevent remote wipe |
| CoC-02 | Full backup acquired | iMazing 2.17 | MD5 + SHA-256 recorded | Encrypted iTunes-format backup; passphrased separately |
| CoC-03 | Original backup archived (read-only) | chmod 444 / write-protect | Hash matched CoC-02 | Original stored; all analysis on working copy |
| CoC-04 | Working copy created for analysis | cp (file system) | Hash of copy verified | Working copy imported into Autopsy project |
| CoC-05 | Artifact extraction complete | Autopsy 4.21, iMazing | Consistent with CoC-02 | No modifications to working copy detected |
| CoC-06 | Report generated and finalised | Manual (Word/PDF) | Final hash appended to report | Report includes exhibit index and hash manifest |
By correlating timestamps from multiple artifact sources, an activity timeline was reconstructed spanning the 72-hour period of interest in the study scenario. All times are in UTC. Entries marked with a highlight indicate key events relevant to the simulated case allegations.
sms.db despite apparent deletion. Content referenced a specific address, a dollar amount ($2,400), and a pickup time — consistent with the study scenario's fraud allegation.
is_read and cache_has_attachments flags consistent with a thread deletion event. However, the underlying message rows persisted in the SQLite database, recoverable via direct table query bypassing the iOS UI deletion.
sms.db, History.db, and CallHistory.storedata databases. SQL queries allowed filtering by timestamp ranges and identifying soft-deleted rows not surfaced by iMazing's UI.
DCIM directory of the backup. Output CSV included GPSLatitude, GPSLongitude, DateTimeOriginal, and Make/Model fields. GPS coordinates geocoded against mapping services to identify physical locations.