01Scope
- Extraction types and what each contains: logical, file-system, full file-system and physical
- Communication records: SMS/MMS, call logs, contacts, WhatsApp, Telegram, Signal
- Usage and pattern-of-life records: usage stats, knowledgeC, Biome, DataUsage
- Photos, their metadata and the app databases that index them
- Computer backups (iTunes/Finder, Android backups) as an alternative source
- Device identifiers: IMEI, serial, ICCID, IMSI, account identifiers
02Questions it answers
- Was this message sent or received on this device, and when in UTC?
- Were messages deleted, and can their existence still be shown?
- Which apps were in use at a given time?
- Was this photo taken with this device, where and when?
- Which SIM and accounts were associated with the device?
- Is the device's own clock trustworthy for the period in question?
03Evidence used
| Source | What it yields | Note |
|---|---|---|
| Extraction archive (full file-system where possible) | System and app databases, plists, logs, media | Record the extraction type, tool version and hash of the archive; a logical extraction lacks most deleted data and many system records. |
| Messaging databases (sms.db, mmssms.db, msgstore.db, ChatStorage.sqlite, cache4.db) | Messages, participants, status, attachments, deletion traces in WAL and free pages | Each app has its own time encoding (Unix seconds, milliseconds, Apple absolute time). |
| Usage records (usagestats, knowledgeC.db, Biome, DataUsage.sqlite) | App foreground periods, screen state, charging, network use | Retention is limited (often weeks); older periods are simply absent. |
| Photos.sqlite, gphotos databases and media files | Capture time, import time, location, edits, deletion state, originating app | A received image carries the sender's Exif, not the recipient's; check the database, not only the file. |
| Computer backups and cloud exports (Manifest.db, Info.plist, Google Takeout) | A point-in-time copy of app data without access to the device | Backups may be encrypted or incomplete; record the backup date and which domains it contains. |
04How it is approached
Document the device before anything else
Photograph the device and screen, record model, IMEI, serial, SIM/ICCID, power and lock state, network isolation measure (airplane mode or shielded container) and the clock shown by the device compared with a reference clock.
Obtain the most complete extraction the situation allows, and name it
The extraction type is part of the finding. State what a logical extraction cannot contain (deleted records, many system databases) so that a negative result is not over-read.
Hash the archive and work on a copy
Verify the extraction archive, then open databases read-only with their WAL and SHM files kept together; do not let a tool checkpoint the WAL into the main file.
Read application tables by their documented schema
Every app version changes column names and time encodings. Identify the app version from the package record, then decode time values with the encoding that version uses.
Corroborate across system and app records
A message time from the app database should be consistent with usage records, notification logs and, where available, carrier records. Disagreement is a finding in itself.
05Artifacts
The library records behind this area:
- SMS/MMS database (mmssms.db)
- Call log (calllog.db)
- Contacts provider (contacts2.db)
- Usage stats (usagestats)
- Package manager settings (packages.xml)
- Account manager databases (accounts_ce.db / accounts_de.db)
- Messages database (sms.db)
- Call history (CallHistory.storedata)
- CoreDuet knowledge store (knowledgeC.db)
- Photos library database (Photos.sqlite)
- Network data usage (DataUsage.sqlite)
- Computer backup file index (Manifest.db)
- Biome streams (SEGB files)
- WhatsApp for Android messages (msgstore.db)
- WhatsApp for iOS messages (ChatStorage.sqlite)
- Telegram for Android local cache (cache4.db)
- Signal for Android database (signal.db)
06Pitfalls
- A 'deleted' message recovered from a WAL frame or free page shows that the record existed; it does not by itself show who deleted it or when.
- Message status fields (sent, delivered, read) are maintained by the app and can lag or be lost after reinstall.
- Device time can be set manually; compare app times with network-sourced records before relying on them.
- Cloud-synced apps may show messages that were never read on this device.
- Contact names come from the device's address book at the time of extraction, not from the message itself.
07What the report states
- Device identifiers, extraction type, tool and version, archive hash, and the time the device clock showed against a reference.
- For each message or event cited: the database, table, row identifier and the raw time value with its decoding.
- Whether the record was live, in the WAL, or recovered from free space.
- The known limits of the extraction type for the questions asked.
08Questions to ask a report
- What extraction type was obtained, and what does it not contain?
- Was the device isolated from networks from seizure to extraction, and how is that documented?
- Which app version was installed, and which time encoding was used to decode the cited timestamps?
- For recovered messages: where exactly in the file were they found?
- Does any independent record (usage stats, carrier data) agree with the message times?
09Standards
10Procedures and cases
- SOP-01 · First response at the scene
- SOP-02 · Evidence intake and registration
- SOP-05 · Mobile device acquisition
- SOP-03 · Chain of custody
- SOP-08 · Examination notes and working record
- VI-02 · Recovering deleted messages from a chat database
- VI-05 · Assessing whether a photograph is an original
- VI-07 · What call records can and cannot show about location