Deleted texts and edited screenshots: the one-hour timestamp error that moved a message before the order took effect
The situation
A defendant faced harassment, stalking, and protection-order violation charges. The complaining witness provided screenshots of threatening messages appearing to come from the defendant's number, and said he deleted his copies to conceal them. He denied sending the threats, said the screenshots had been edited, and said some messages predated the order entirely.
What the other side said the evidence showed
That the screenshots spoke for themselves: the messages were sent, they were threatening, they came after the protection order took effect, and their absence from the defendant's phone was proof he had deleted them.
A screenshot is a picture of an interface. It is not the message, and it is not the database the message lived in.
Message evidence has four possible independent sources, and most cases only look at one. There is the screenshot, the native message database on the device, the carrier record, and the notification artifact the operating system kept when the message arrived. Each proves something different. The carrier record proves an exchange occurred but never contains content. The notification record preserves a truncated preview. The database is the closest thing to the message itself — including, frequently, deleted rows still sitting in the write-ahead log.
The second issue is timestamps, and it is the one that most often changes a charge rather than merely weakening it. Message databases store time in UTC. Interfaces display local time, using whatever timezone the device was set to at that moment — which changes when someone travels. In this matter a message displayed as 5:12 PM was actually sent at 4:12 PM Mountain Time, before the protection order became effective at 5:00. That is not a credibility argument. It is a count that should not have been charged.
The third issue cuts against reflexive defense arguments too. Absence of a message from the defendant's phone proves very little: database vacuuming, storage reuse, encryption, device resets, OS updates, and unsupported extraction methods all destroy recoverable message data without anyone deliberately deleting anything.
What the examination involved
Preserved both devices and documented their state
Make, model, power condition, lock state, SIM data, visible damage, the time displayed on screen, whether isolation or airplane mode was used, and every known prior interaction — including that a patrol officer had already scrolled through one phone and photographed the screen without a formal acquisition.
Acquired at the file-system level, not just logically
A logical extraction returns active messages, contacts, call logs, and photos. A file-system acquisition reaches the message databases themselves, deleted database records, application caches, attachments, notification artifacts, backup remnants, and system logs. Which level is achievable depends on device, OS, encryption, and lock state.
Examined the messaging SQLite database for deleted rows
Active rows, deleted pages, the write-ahead log, shared-memory files, backup copies, notification records, and attachment directories. Two deleted messages were recovered from the write-ahead log matching portions of the screenshots.
Tested the screenshots as image files
Dimensions, format, creation metadata, editing-software metadata, compression inconsistencies, font and spacing irregularities, status-bar consistency, message-bubble alignment, and chronological continuity. One screenshot carried metadata showing it had passed through an image editor.
Correlated carrier records against on-device artifacts
An outgoing SMS event at 8:41 PM from one number, an incoming event at 8:41 PM to the other, a notification database entry at 8:42, and screenshot creation at 8:44. That correlation supports authenticity far more strongly than the screenshot alone.
Normalized every timestamp from UTC to local time
Including accounting for a timezone change on the device during travel — which is where the one-hour discrepancy on the disputed message originated.
What the examination found
- Two disputed messages were recovered from the SQLite write-ahead log and matched the screenshots
- A cloud backup predating the deletion contained part of the conversation, and notification records preserved truncated previews of two messages
- Carrier records confirmed communication between the devices at the times in question
- One screenshot had been processed through image-editing software — which establishes processing, not fabrication; cropping produces the same artifact
- The message charged as a post-order violation was sent at 4:12 PM local, 48 minutes before the order took effect
- Not every screenshot was corroborated by an independent source
Outcome
The examination authenticated part of the message evidence and dismantled one count of it. That is the normal result: forensic work on message evidence usually strengthens some of the case and eliminates a piece of it, and which piece is not predictable before the examination.
Takeaways for counsel
- For every disputed message ask: is it in a native database, is it in a backup, is there a carrier event, is there a notification artifact, and is the timestamp normalized?
- Never accept a displayed time as the sent time. Databases store UTC; interfaces show whatever timezone the phone was on at the time, and travel changes that.
- Editing-software metadata on a screenshot is not proof of fabrication. Cropping out unrelated content leaves the identical trace, and overclaiming here damages credibility.
- Absence of a message from a device is not evidence of deletion. Vacuuming, encryption, resets, and OS updates all destroy recoverable data on their own.
- Ask what acquisition level was performed. A logical extraction that found nothing is a different fact from a file-system acquisition that found nothing.
Related questions
Sometimes. Messaging apps use SQLite databases, and deleted rows frequently persist in free pages and the write-ahead log until the database is vacuumed or the storage is reused. Recovery depends on the app, the device, the acquisition level achievable, and how much time and use has passed. A logical extraction alone will usually miss them.
An examiner can identify processing — editing-software metadata, compression inconsistencies, alignment and font irregularities, status-bar problems. What that establishes is that the image was processed, not what was changed. The stronger approach is corroboration: find the message in a database, a backup, a notification record, or a carrier event.
Have a case that turns on digital evidence?
Tell us the case, the device, and your deadline. The scoping call is free, and we'll tell you honestly whether an examination is worth it.
Appointed counsel: see our Colorado public defender program.
More case studies
Deleted files in an employee-theft prosecution: what the artifacts proved, and what they couldn't
The video played at trial wasn't the video in discovery: PowerPoint, transcoding, and normalized audio
"No other footage exists": what the body-camera audit logs actually showed
This case study is illustrative. It is written to show how digital evidence is examined, challenged, and presented in court; it is not an account of any client matter, and any resemblance to a specific case is unintended. The techniques and failure modes described are real. Nothing on this page is legal advice, and no result is a prediction or guarantee of the outcome of any other matter.