What Messages keeps after edits, unsends and deletes

Summary

• Messages stores reactions, edits, unsent parts, inline replies, Recently Deleted entries, link previews and app messages in places other than the text column. A plain message list does not show them.
• This pull request adds eight tables to iLEAPP that decode those fields from sms.db. It was merged on 25 October 2026.
• Row counts on eight iPhone extractions in the Lab's research corpus were re-counted with separate code. All 64 numbers agree.
• The tables report what the file stored. They do not show who acted or that a person saw a message.

The issue

An examiner asked whether a message was edited, taken back, answered inline, reacted to or deleted opens the Messages database and finds a list of rows. The list is correct as far as it goes, but several of these actions leave their trace somewhere other than the text column, and a list of rows does not say so.

Take the cases one at a time. A reaction (a tapback, an emoji or a sticker) is stored as a message row of its own, with the system-written phrase as its text, so in a plain list it reads like one more message and nothing links it to the message it answers. An edited message shows its current wording; the earlier versions sit in a binary property list in message_summary_info. An unsent message keeps its row but loses its text, so it looks like an empty message, and the field that marks it is again inside that property list. A message in Recently Deleted stays in the file after it has left the conversation. A link preview or an iMessage app message keeps its title, address or layout in an archive in payload_data.

The second problem is a name. The message table has a column called reply_to_guid, and the name invites the reading that a filled value marks an inline reply. On one database from the Lab's research corpus it is filled on almost three rows in four, so that reading would label most of the conversation as replies. Both problems have the same result: the report is quiet where the file is not.

Figure 1 shows the gap with a short synthetic conversation.

The essence

The contribution adds eight tables to iLEAPP that read these fields out of the same sms.db file the existing messages artifact reads. The existing module is untouched. Each table says what the database stored and nothing about who acted: a row is a reaction, a stored version, an unsent part, a reply, a Recently Deleted entry, a link preview or an app message.

Five new modules do the reading, and they share one helper that decodes the three stored formats (typedstream text, binary property lists and keyed archives). Where the file lists a value that could not be interpreted, it is reported as stored instead of being guessed.

Our methodology

The work started from the stored formats, not from the screen. We described each action as the rows and keys that must exist if our reading is right, wrote the decoders from the formats, and then tried to break the reading on real databases from the Lab's research corpus. The field meaning for the property-list keys follows the public documentation of an open-source exporter, which is cited for meaning only; no code was copied.

Three habits shaped the code. First, every decoder returns an empty value on input it cannot read and never raises, so one damaged blob costs one cell and not the whole report. Second, the module checks that the columns and tables it needs exist before it queries, so an older database gives an empty result and not an error. Third, times are converted from Cocoa seconds or nanoseconds to UTC with a stated threshold, and the target of a reaction or reply is looked up by GUID in chunks so that a large database is read in bounded queries (Figure 2).

Validation had four parts. The paper behind this work states nine checks as equalities, for example that the time of the last stored edit equals date_edited, and counts the exceptions. Row counts of all eight tables on eight full file system extractions were then recomputed with separate code: plain SQL, plistlib for the property lists and a small keyed-archive reader for the previews. All 64 counts agree (Figure 3). The first version of that independent reader was a heuristic and disagreed with the parser by 16, 4 and 26 rows on three databases; a proper archive reader settled each difference in favor of the parser, so the recount tested both sides. The repository's own output check first listed 45 distinct empty, constant or identical column findings, such as no named group chats; each column is now named in the artifact notes with what it was.

The test data is synthetic. A generator builds a fabricated database with reserved 555-01xx phone numbers, example.com addresses, fixed sentences and fixed dates, and the pull request adds twelve unit tests and eight test cases with recorded baselines. On the continuous-integration side all 26 jobs passed on the final change. Two findings in the PR text are stated as limits: databases from iOS 16 and 17 were not available, so those versions are unverified, and a ninth database from iOS 18.1.1 was used earlier but not re-run for this change.

The value

The tables let an examiner answer questions the plain list could not. Was a message edited, and what did it say before? Which parts of a message were unsent, and how long was the original text? Which message did this reaction or reply point to, and is that message still in the database? Which messages are held in Recently Deleted, and are they still linked to a chat? What did a link preview or an app message carry?

The value is largest where the reading would otherwise be wrong. The reply case is the plainest: on the database where it was measured, reply_to_guid is filled on 49,981 of 68,136 rows and equals the thread originator in only 56 of 1,360 replies, so the artifact identifies replies by thread_originator_guid (Figure 4). The notes also record that Recently Deleted rows are not limited to 30 days, that removal rows of reactions often have no matching add row, and that date_retracted was 0 on every database, so the retracted-parts list marks an unsent part.

The limits matter as much. A row is a record the device stored. It does not show who edited, unsent, reacted or deleted, from which device, or that a person read the target message. A link preview shows that Messages stored a preview, not that the link was opened. An empty result is not evidence that nothing happened, because a message removed from Recently Deleted leaves no row. The reply finding rests on one database, and iOS 16 and 17 were not tested.

Where this sits in the Lab's research

This contribution is the tooling side of Lab Technical Report LAB-TR-0008, What iMessage Keeps After You Edit, Unsend, React or Delete, published on Zenodo (doi:10.5281/zenodo.23720066, version 1.2; the concept DOI 10.5281/zenodo.23717930 always points to the newest version). The report states the nine checks, gives the results on nine databases and names this pull request as its artifact release. This post summarizes the part of the report that shaped the code.

A second report, LAB-TR-0013, asks whether removed messages leave traces in the iOS unified log. It is available on this site as a preprint; the Zenodo deposit is pending. It compares identifiers in the log with the identifiers in the Messages store, and it found that the log named 24 percent of the 2,867 messages dated inside a device's log span; it did not show that a message was removed. The message GUID that every row of these tables carries is the identifier such a comparison needs.

Sources

Every figure in the text and in the diagrams is listed here with where it comes from. Nothing else was used: no device, image or report was opened for this post.

Related posts

Other contributions in the same series.