Reconstruction of device activity
across a disputed two-hour window.
This is a fictional exemplar prepared to demonstrate the structure, rigor, and plain-language style of an Evntrace examination report. It describes no real person, device, or matter.
What we were asked to determine.
Evntrace was retained by defense counsel to independently examine one mobile device and answer three questions about activity during a disputed window between 11:00 PM and 1:00 AM:
- Was the device in active use during the window, and if so, when?
- Do any deleted communications from that window remain recoverable?
- Does the device's own data place it in a particular location during the window?
In scope: one Apple iPhone, logical and file-system acquisition, and analysis of on-device artifacts. Out of scope: carrier records, cloud accounts not present on the device, and any device not listed in the evidence inventory. This engagement makes no legal conclusion; it reports technical findings only.
What we received, and how it was handled.
Evidence was received sealed, photographed before handling, and logged. Custody is documented and unbroken from receipt through analysis.
| Exhibit | Item | Identifier (illustrative) | Condition |
|---|---|---|---|
| EX-001 | Apple iPhone 14 Pro, 256 GB · iOS 17.x | IMEI 35•••••••••••48 | Sealed, powered off, undamaged |
| EX-001-A | Forensic image of EX-001 (working copy) | image.e01 | Verified — see §3 |
We work a verified copy — never the original.
A forensic image of EX-001 was acquired on write-blocked hardware so the source could not be altered. The image was hash-verified against the source: identical hashes confirm the copy is a faithful, bit-for-bit duplicate. All subsequent analysis was performed on the verified working copy (EX-001-A).
| Step | Detail | Status |
|---|---|---|
| Acquisition method | Write-blocked file-system acquisition | Complete |
| Source hash (SHA-256) | 9f2ac1b7…e4d0 (illustrative) | Recorded |
| Image hash (SHA-256) | 9f2ac1b7…e4d0 (illustrative) | Match |
| Verification | Source and image hashes identical | Verified |
Repeatable, documented, defensible.
Findings were produced with established, industry-standard techniques and an open-source toolchain so that any qualified examiner can reproduce them from the same evidence. No step depends on a proprietary "black box."
- Forensic imaging and hash verification (SHA-256)
- File-system and deleted-content analysis (The Sleuth Kit-class tooling)
- Super-timeline reconstruction (log2timeline / plaso-class tooling)
- Application-database recovery, including write-ahead logs and freelist pages (SQLite)
- File carving of unallocated space for deleted media
Every finding below is tied to the specific artifact it came from, with timestamps normalized to UTC for consistency and the device's local-time offset noted.
What the data shows.
Activity is present throughout the disputed window.
The reconstructed timeline shows repeated user-driven events between 23:00 and 01:00 — screen unlocks, application launches, and a draft message — indicating the device was actively handled, not idle.
| Time (UTC) | Event | Source artifact |
|---|---|---|
| 23:41:08 | Location sample written | cache · location.history |
| 23:44:55 | Message draft created, then deleted | sms.db · WAL |
| 00:02:17 | Application opened (foreground) | app_logs · session |
| 00:18:40 | Photo captured | DCIM · EXIF |
“Deleted” did not mean gone.
A thread the user had deleted was partially recoverable. 52 messages were reconstructed from the messaging database's write-ahead log and from unallocated space, including the 23:44 draft referenced in F-1. Recovered content is reproduced verbatim in Appendix C of the full report.
The device's own data places it within a consistent area.
Location samples and photo EXIF metadata from the window cluster within a small, internally consistent area. We report what the device recorded; we do not opine on the person carrying it.
No evidence of remote tampering was found.
We found no artifacts indicating remote access or automated message deletion during the window. The absence of such evidence is not proof it did not occur — only that this device's data preserved no trace of it within the examined scope.
How every finding traces back.
Each finding is built from specific artifacts on the verified image, and feeds a specific conclusion. Select any node to light up what it connects to.
// Select a node to trace its connections · select again to reset
What this report does — and does not — establish.
- On-device timestamps reflect the device clock. Where possible they were cross-checked against network-synchronized artifacts; any unverified offset is noted at the finding.
- Device data shows what the device did. It does not, by itself, establish who was holding it.
- Findings are bounded by the evidence in the inventory and the scope in §1. Carrier and cloud sources were not examined.
- Recovered deleted content is reported with its recovery method so its reliability can be independently weighed.
Answering the three questions.
1 · Active use: Yes — the device shows continuous user-driven activity across the 11:00 PM–1:00 AM window (F-1).
2 · Deleted communications: Yes — 52 deleted messages from the window were recovered and verified (F-2).
3 · Location: The device's own location and photo data place it within a consistent area during the window (F-3), with the limits noted in §6.
Examiner statement.
The analysis described here was performed on a verified forensic copy using documented, repeatable methods. The findings are an accurate account of what the evidence showed within the stated scope. Where a matter proceeds to court, expert testimony is provided through a credentialed partner examiner.
Plain-English terms.
| Write blocker | Hardware that lets us read a device without changing a single byte on it. |
| Forensic image | An exact, bit-for-bit copy of the device's storage that we work from instead of the original. |
| Hash (SHA-256) | A digital fingerprint of data. If two hashes match, the data is identical; if one byte changes, the fingerprint changes. |
| Unallocated space | Storage the system has marked "free." Deleted data often still sits here until overwritten — which is why it can be recovered. |
| Write-ahead log (WAL) | A scratch file a database uses before saving. It frequently retains records the user believes were deleted. |
| Super-timeline | Thousands of timestamped events from across the device, merged into one sortable timeline of what happened, when. |