In family court, the arguments are often not about what happened — they’re about what was said, when, and by whom. Each party has a version of events. Each version is plausible. And the gap between “my client said” and “the evidence shows” is where forensic examiners do some of their most consequential work.

This composite illustration draws on common patterns in custody-related digital forensic engagements. The scenario is constructed from representative case elements and does not represent any specific client matter.

The Dispute

The custody matter involved two co-parents who had separated two years prior. A dispute arose over the communication record — specifically, whether one parent had consistently notified the other about changes to the custody schedule as required under their parenting agreement, and whether a series of communications had been sent within a particular window relevant to a pending court motion.

Both parties produced screenshots from their own phones as their evidence. This is the starting point for nearly every digital communications dispute in family court, and it’s a deeply flawed evidentiary approach.

Screenshots can be faked. They can be cropped. They can be selectively produced. More commonly, they’re not deliberately manipulated at all — but they reflect only one party’s device, which means they’re inherently incomplete. The other party’s device has a different view of the same thread, including messages that one side may not have produced.

Both attorneys agreed to a mutual forensic examination of both parties’ devices. That agreement was memorialized in a stipulated court order, which defined the scope of examination and the handling of privileged communications.

Device Acquisition

Both devices were iPhones. The relevant data was iMessage and SMS messages.

For iPhone forensics, the acquisition method determines what data is accessible. The primary options:

iTunes/Finder backup. A locally generated backup of the iPhone’s contents, created either from the device itself or via iTunes/Finder on a computer. Backups are accessible without the device passcode if the backup is unencrypted. Encrypted backups require the backup password. We requested both parties’ iCloud or local backup if available, as a supplement to direct device acquisition.

Logical acquisition via GrayKey or Cellebrite UFED. For locked devices or when backup is unavailable, supported physical acquisition tools can extract data directly from the device. For this engagement, both devices were unlocked and provided voluntarily, so logical acquisition via Cellebrite UFED in iOS logical mode was appropriate.

iCloud extraction. With appropriate legal authority and the account holder’s cooperation, iCloud backups and iCloud message sync can provide an additional source of messages. iCloud message sync (`sms.db` in iCloud) can contain messages not present on the local device if the device was restored or replaced.

We acquired both devices in logical mode, producing full filesystem images where iOS version permitted. We also obtained iCloud backups from both parties under the scope of the court order.

The sms.db Database: Structure and Contents

iOS stores both SMS and iMessage conversations in a single SQLite database: `sms.db`. It’s located at `/private/var/mobile/Library/SMS/sms.db` in the device filesystem.

The database structure has evolved through iOS versions, but the core tables have remained largely consistent:

`message` table. The primary table. Each row represents a single message. Key columns:

`handle` table. Maps `handle_id` values to contact identifiers — phone numbers or Apple IDs (email addresses for iMessage contacts).

`chat` table. Represents conversation threads. Each chat has a `guid` and a `display_name`. Group chats have display names; 1:1 threads typically don’t.

`chat_message_join` table. The many-to-many join table connecting messages to chats. This is how you reconstruct which messages belong to which thread.

`attachment` table. Records for attached media. Each attachment has a file path pointing to the actual file in the device filesystem, a MIME type, and transfer state information.

The Date Conversion Problem

Apple’s timestamp format trips up every examiner the first time.

The `date` column in `sms.db` is not a Unix timestamp. Unix time is seconds since January 1, 1970. Apple uses a different epoch: seconds since January 1, 2001, at 00:00:00 UTC.

But in iOS 11 and later, Apple moved to nanoseconds since the Mac epoch. The same-looking integer value means completely different things depending on the iOS version that created the record.

For iOS 11+ databases (the vast majority of current devices):

“`
Human-readable timestamp = (date value / 1,000,000,000) + 978,307,200
“`

Where 978,307,200 is the number of seconds between January 1, 1970 and January 1, 2001.

For iOS 10 and earlier:

“`
Human-readable timestamp = date value + 978,307,200
“`

Tools like Cellebrite Physical Analyzer, Magnet AXIOM, and iExplorer handle this conversion automatically. But if you’re querying `sms.db` directly with SQLite browser or custom queries, you must apply the correct conversion for the iOS version.

Misapplied timestamp conversion is a real error that has produced incorrect timeline findings. Verify your conversion against a known message — cross-reference the database timestamp against a message the device owner can confirm they sent or received at a known time.

Thread Reconstruction

Reconstructing a specific conversation thread from `sms.db` requires joining across multiple tables:

“`sql
SELECT
m.date,
m.is_from_me,
h.id AS contact,
m.text,
m.service
FROM
message m
JOIN
chat_message_join cmj ON m.ROWID = cmj.message_id
JOIN
chat c ON cmj.chat_id = c.ROWID
JOIN
handle h ON m.handle_id = h.ROWID
WHERE
c.guid = ‘[target chat GUID]’
ORDER BY
m.date ASC;
“`

This produces a chronological reconstruction of a specific conversation thread. For family court presentation, we then convert timestamps to local time (documenting the device’s time zone setting, which is stored in device preferences), format the output as a clean message log, and annotate each message with whether it was sent or received on the examined device.

The dual-device advantage: examining both parties’ devices and cross-referencing their `sms.db` records allows us to verify that the message records are consistent. A message that appears as sent on one device should appear as received on the other. Discrepancies — a message present on one device but missing from the other’s database — are forensically significant and worth investigating.

Deleted Message Recovery

Messages deleted by the user aren’t necessarily gone from `sms.db`. When a message row is deleted from the SQLite database, the underlying database page may still contain the data until it’s overwritten by new content. This is SQLite’s WAL (write-ahead log) behavior and page allocation — deleted rows leave recoverable remnants in unallocated database pages.

Tools like SQLite Deleted Records Parser can extract these remnants. Additionally, the SQLite WAL file (`sms.db-wal`) and shared memory file (`sms.db-shm`) can contain recent transaction data including deleted message content that hasn’t been fully committed to the main database.

In our examination of both devices, we ran deleted message recovery on both `sms.db` files. This is standard practice — not because we expect to find missing messages in every case, but because a complete examination requires it.

In this matter, we recovered several messages that had been deleted from one party’s device. Some were routine. Two were significant: they contained content that addressed the notification dispute at the heart of the court matter, sent during the relevant period.

Deleted message recovery findings require careful handling in family court. You’re producing messages one party believed they’d destroyed. Present them with full methodological documentation: what tool was used, what the recovery process involves, and what limitations apply. Be precise about confidence — a fully intact recovered row is different from a partially overwritten fragment. Only present recovered messages you can read completely and accurately.

The iCloud Dimension

Both parties had iMessage sync enabled, meaning Apple’s servers maintained a synchronized copy of their message histories tied to their Apple IDs. Under the scope of the court order, we obtained iCloud backup access from both parties.

iCloud backups provided two things:

Historical message data. iCloud backups can contain older messages that were deleted from the local device but preserved in the cloud backup. If the last iCloud backup predates the deletion event, those messages are in the backup.

Independent corroboration. The iCloud record of a message’s metadata — send time, delivery confirmation, read receipt — can be compared against the local `sms.db` records to verify accuracy. Discrepancies between cloud and local records warrant investigation.

In practice, we compared the thread reconstructions from both local devices against the iCloud backup data. The records were consistent — which is itself a meaningful finding. Consistency across three independent sources (Device A’s `sms.db`, Device B’s `sms.db`, and iCloud sync records) substantially increases confidence in the accuracy of the timeline.

Timeline Presentation for the Court

Family court judges aren’t forensic examiners. They’re also not naive — they deal with disputed digital communications constantly. What they need is a clear, organized presentation of what the evidence shows, with enough methodological transparency to evaluate its reliability.

We prepared three deliverables for this matter:

Forensic report. Full methodology, chain of custody, acquisition details, database query documentation, timestamp conversion validation, and complete findings. This is for the attorneys and, if challenged, for the court.

Message log exhibit. A clean, formatted log of the reconstructed conversation thread, in chronological order, with dates and times converted to local time, annotated to show which device each message came from. This is the courtroom exhibit.

Timeline graphic. A visual representation of the disputed period, marking message timestamps against the events referenced in the parenting agreement dispute. One page. No jargon. Designed for a judge who needs to understand the communication sequence at a glance.

The key finding in this matter: the message record from both devices, corroborated by iCloud, showed a clear and consistent timeline of communications between the parties. The timestamps demonstrated the timing of specific notifications within the relevant period. The content of those messages, as reconstructed from both devices, was consistent — no evidence of manipulation on either device.

Both sides got a complete and accurate record. The court’s evaluation of the evidence — and what conclusions to draw from it — wasn’t our role. Our role was to produce a reliable record.

Handling Privileged Communications

Family court forensic examinations are fraught with privilege issues. A parent’s device may contain:

The court order governing the examination should address this explicitly. Standard practice is a two-step process:

  1. The forensic examiner extracts all communications and delivers them to a designated neutral party or the requesting attorney.
  2. A privilege review occurs before any communications are shared with the opposing party, with a protocol for resolving disputes about what is and isn’t privileged.

We followed this protocol. All message thread content was initially produced only to the retaining attorneys. The privilege review identified several attorney-client communications that were excluded before production. The remaining message record — the actual communication timeline between the parties — was produced to both sides after the review.

This process takes longer. It’s worth it. Privilege issues that aren’t handled correctly at the examination stage can taint the entire evidentiary record and, in some jurisdictions, create professional liability for the examiner.

What iMessage Forensics Reveals That Screenshots Don’t

Screenshots are admissible. They’re also terrible evidence.

A screenshot shows you what one person’s screen looked like at a moment in time. It doesn’t prove when the conversation happened. It doesn’t prove the screenshot was captured from a real device (screenshots can be fabricated with a text editor and basic image manipulation). It doesn’t show you deleted messages, read receipts, or the other party’s synchronized record.

`sms.db` examination shows you the actual database record, with timestamps written by the OS at message creation, delivery, and read events. It shows both sides of a conversation from both devices. It survives deletion attempts with recoverable database remnants. And it can be cross-referenced against the other party’s database and iCloud records.

The standard of evidence is higher. The reliability is substantially greater.

In any family court matter where communication timing and content are disputed, database-level examination of both parties’ devices is the right approach. Screenshots as primary evidence should be supplemented or replaced by this type of examination whenever it’s feasible.

For related methodology, the [identity theft reconstruction case study](/identity-theft-reconstruction-insurance/) demonstrates similar timeline reconstruction approaches applied to email and account access records.

Frequently Asked Questions

Can iMessage timestamps be trusted to reflect when a message was actually sent?

Generally yes, with some important caveats. iMessage timestamps are written by iOS at the time of send/receive and stored in `sms.db`. They reflect the device’s clock at the time the event occurred. If a device’s clock was intentionally set incorrectly, timestamps would be incorrect. However, iMessage timestamps are also validated against Apple’s servers during delivery — a delivered iMessage carries a server-confirmed delivery time that’s independent of the device clock. Comparing device-recorded timestamps against iCloud server records catches intentional clock manipulation in most cases. Document both values in your report.

What happens to iMessages when a user switches to a new iPhone?

When setting up a new iPhone and restoring from backup (iCloud or local), the `sms.db` from the old device is restored to the new device. The message history migrates intact, with original timestamps preserved. If the user set up the new iPhone as a fresh device without restoring, messages may not transfer — though iCloud message sync can repopulate recent message history if enabled. When examining a device that may be a replacement for an older device, check iCloud backup history (available in the iCloud account settings) to understand the continuity of the message record.

How do you handle messages in third-party apps like WhatsApp or Signal?

Third-party messaging apps store their databases separately from `sms.db`. WhatsApp uses its own SQLite database (`ChatStorage.sqlite` on iOS). Signal uses a separate encrypted database. Each requires its own extraction and analysis approach. Signal’s encryption is designed to resist forensic extraction — the database key is derived from device-specific hardware identifiers, making acquisition on locked devices extremely difficult. For any matter where messaging apps beyond iMessage and SMS are relevant, scope your examination explicitly and know the limitations of what each app’s database reveals.

What if one party refuses to submit their device for examination?

Refusal to comply with a court-ordered device examination is a discovery compliance issue, not a forensic issue. The appropriate response is a motion to compel, and courts may draw adverse inferences against parties who refuse court-ordered discovery. As a forensic examiner, your role is to examine devices that are presented to you. If one party’s device isn’t available, note that limitation in your report and present findings from the available device(s) with appropriate qualification about completeness. Don’t speculate about what the missing device might show.

Are read receipts in iMessage forensically reliable?

Read receipts in iMessage — the “Read at [time]” notification visible in conversation threads — are stored in the `date_read` column of the `message` table in `sms.db`. When a device with read receipts enabled opens and reads a message, iOS writes a timestamp to this field and sends a delivery receipt to the sender’s device. This field can be forensically examined to determine when a specific message was read on the receiving device. Important caveat: read receipts are an opt-in feature on iOS. If the recipient had read receipts disabled, no `date_read` timestamp is generated even if they read the message. The absence of a `date_read` value doesn’t mean the message wasn’t read — it may simply mean read receipts were off.