The Meaning of Messages

Since the creation of iOS, Apple has used one primary app as the storage center for your communication data—the “Messages” application. It’s responsible for the handling of both your SMS/MMS data as well as the proprietary iMessage transmissions. While the database backing these messages hasn’t moved since its creation, it’s gone through several changes over time as Apple has added new features; not only has the database changed, but other locations where data can be found to support the functions and features of the Messages application have also been added throughout the lifecycle of iOS.

If you’ve seen episode 2 of Mobile Unpacked: The Meaning of Messages you probably noticed there was a LOT of information to keep up with as far as paths, file names, and stored keys. This post will attempt to distil that information down into an easily digestible resource to assist you with investigations into iOS’ messaging client.

Key Storage Locations

Key Points Within SMS.DB

Table: Messages

This table stores the bulk of the data, including the dates and times, message content, handle identifiers, statuses, and additional context around messages. Dates stored within this table can be either UNIX epoch (for older versions of iOS) but are largely now Apple Time (Cocoa/WebKit Time) which counts in either seconds or nanoseconds. Not all messages will have all date columns filled in, service and directionality will play into what columns are used. Handle_id column will let us know who sent/received the message unless it is 0, in which case it is a group message thread and other tables are needed.

GUID column uniquely identifies each message and is key for syncing across devices as well as functions such as replies, multi-part messages, reactions, and threaded conversations.

Messages sent by Siri are tracked within the column “message_summary_info” in which a pist is embedded into the BLOB and will reflect ‘com.apple.Siri’ for messages using this function. The same “message_summary_info” column will also store information such as what messages have been edited (in iOS 16 or later) as well as when they were edited.

Redacted messages and edited messages will both have their “text” column erased. Both will also reflect when they were edited using the column “date_edited.”

Table: Handle

Contains the number or email of the addressed party as well as what service the address was used through. It should be noted the same id can appear multiple times with different services.

Table: Chat

Responsible for linking threads together. In iMessage threads will contain the display name of the room.

Table: Attachments

Tracks the name, size, date/time sent, and other details about all of the files transmitted via MMS or iMessage. While MMS can only be audio/video/image files, iMessage can handle almost any file type. Files can be listed here even if the full file has been removed from the device. No direct link between attachments and messages, join table message_attachment_join used to link the two.

Table: recoverable_message_part

Stores which messages are flagged for deletion in iOS 16 or higher. As of iOS 16, messages are not immediately deleted, but just flagged for deletion for 30 days. Message must be manually cleared out of “Recently Deleted” area or timeout before they are removed from the db.

Tracking Specific Features of iMessages

Recalled Messages

When a message is recalled in iOS 16 or higher, the data is purged from the text column of the messages table. Messages must be recalled within 2 minutes of being sent. The record relating to the recalled message still exists, but the content of the message is destroyed. However, it is possible to track this information in other locations relating to the biome directories, including:

• AppIntents
• User Activity
• Notifications Events

Messages synced to a pre-iOS16 or pre-macOS13 device will show no changes when recalled. Messages.date_edited value will show Apple Time epoch of when the recall occurred.

You can find more information on how to track these records here.

Edited Messages

When a message is edited in iOS 16 or higher, the data is purged from the text column. Messages must be edited within 15 minutes of being sent. The most recent message is left within the BLOB in the attributed_body column. Each individual edit will also be stored within a plist file in the BLOB under the column message_summary_info, which will store the content of the edits as well as a timestamp when the edit occurred.

Messages synced to a pre-iOS 16 or pre-macOS13 device will show a new database record which will say that a message was edited and contain its new content.

Messages Sent by Siri

While only incoming messages show “Sent by Siri” in the iOS UX, all messages both incoming and outgoing that have been sent using the Siri service log a record within the “message_summary_info” BLOB of the messages table. A binary plist will store “com.apple.Siri” when a message has been sent using this service.

What Messages Sync

iMessages will sync between any two iOS/macOS devices where the service is enabled and the devices are signed into the same Apple ID. SMS messages will sync between cellular enabled and non-cellular devices when the SMS forwarding feature has been turned on (see com.apple.sms.plist) and the devices are on the same Wi-Fi network. However, if Messages in iCloud is enabled, they will continue to sync even without being on the same Wi-Fi. If Messages in iCloud is enabled, all messages will automatically sync between the devices that the feature is enabled on. It must be enabled per-device. These messages will also sync to a special container within iCloud and NOT be included in any device’s iCloud backup that has it enabled.

What Device Sent the Message

We have established that Apple uses the guid value for cross-device synchronization. The rowid values of the database are only going to matter to that specific device’s database so how can we figure out which device actually sent the SMS or iMessage record? To figure this out, we must turn to the Biome subdirectory and the SEGB files stored within. With the AppIntent biome data storing both “local” and “remote” records separately, any messages that were outgoing which appear here were sent by the local device. Records from the “remote” SEGB files will reflect messages that simply got synced.  

A Good Road Map to Start Digging Deeper

Due to the high amount of features and functionality that the Messages application has gained over the past few versions, it’s safe to say that Apple isn’t done yet. We hope that this guide can serve as a good road map to start with for investigators digging deeper into the messaging functions. As Apple continues to develop and add features to the Messages application, you can be sure that we here at Magnet Forensics will be watching closely and will be keeping the community informed of all the new materials we find. Until then, keep watching along with Mobile Unpacked to get the latest research delivered right to you each month.