Apples WWDC this week announced iOS16 and the new features of editing and unsending iMessages.

Obviously from a forensic point of view, this is less desirable. It doesn’t take much imagination to see how this could be abused as evidential messages get deleted or altered to something much less incriminating.

So how does it look? I installed the beta and gave it a test...

Editing Messages

Using Messages looks like it has for the last few iOS versions. Sending messages is exactly the same as normal and the underlying database still looks pretty normal. There are a couple of new things which I’ll come to shortly.

So, I send the first message

The original message was sent

And checked the database. All is as expected.

The original message seen in the database

But then I returned to the phone and edited the message.

The option to edit

While editing the text

And the edited message

I checked the database again.

The message body is gone! But visible in the attributedBody field

Firstly, notice how the body has now disappeared. To get the body of the message, we now need to look in the AttributedBody field which includes much more data about the message than just the text.

One of the new fields is now being used; edited_date, which shows the time that I altered the message.

The edited message timestamp

OK, so we see the message was edited at least, even if we can’t see the original message.

Unsending Messages

I then “Unsent” the message. On my device, it gave a warning that I had unsent a message but that the recipient may still see it if they are using an older version of iOS (note, my receiving device was still on iOS14 and neither the edits or unsends had any affect).

The option to Unsend

After unsending

From the database point of view, the record still existed but again, the message body was gone. Sadly, it was also gone from the AttributedBody field too.

The empty text and attributedBody field

The second new database field, date_retracted was now being used to show the time I had unsent the message.

The retracted message timestamp is still empty... But the edited_timestamp has been updated

So again, we have evidence of a message but no evidence of what it initially said.

It’s worth noting that after about 15 minutes, the option to Unsend or Edit a sent message disappears.

Deleting Messages

Finally, I deleted (rather than unsent) a message. Interestingly, it now placed the deleted message into a Recently Deleted folder, much like when you delete photos. These deleted messages can be totally deleted or recovered.

The messages still exist in the main table and a table called CHAT_RECOVERABLE_MESSAGE_JOIN is used to track the deleted messages.

The "deleted" message

The CHAT_RECOVERABLE_MESSAGE_JOIN table

UPDATE

In what appears to be a change since my initial research, there is now additional information within a field called "message_summary_info" found within the Message table.

This field has been there for a long time but this is the first time I've seen a use for it from a forensic point of view.

Specifically, this field may contain a BPList blob which contains the previous message contents and the time of the change.

Here we can see 4 edits made to the message

And within T node we find the attributedBody and the D node has the timestamp.

Wrapping Up

So overall, it’s not great news, but it’s not as bad as it could be. The Edit/Unsend has to occur quite soon after the message was sent and it can likely be proven that a message was tampered with, but from the sending device, it will be difficult to prove what it said. I have yet to see how it looks on a receiving device but will update this post once done.

Of course, my database viewing was conducted solely on the fruits of an iOS Backup. So I lose the benefit of being able to process the WAL or Freepages properly. That test will have to wait until a better extraction method is available.

Update : So it seems that the WAL/Freepages may not be as necessary as thought. Recovering multiple updates to a message is really rather simple.