iOS 16: What Digital Investigators Need to Know

With Apple’s announcement of iOS 16’s official launch date, as well as providing their latest “gold master” build, we wanted to take a dive into iOS 16 and see what all was going to be new from an analysis and acquisition perspective.

This blog will explore any changes and new features to the process of acquiring and processing iOS 16 data ahead of Apple’s official release of the software on September 12.

Acquiring iOS 16

While tools will continue to update and release to overcome changes to iOS 16, there’s always the easy way, which is iTunes! In addition to iTunes, tools such as Magnet AXIOM and ACQUIRE successfully work to acquire iOS 16 GM builds from any iOS device (with the passcode, of course).

Once the device has been paired with the computer using the “Trust” dialog on the device, the plist file containing the Lockdown information is placed into its usual spot. After this occurs, and the examiner selects their device, it will prompt for the inclusion of backup encryption to the image.

This process is unchanged from iOS 15 and previous in that it still requires the PIN code for the device to change the backup encryption passcode. This is key because even with a valid Lockdown record, you can’t get around this step without knowing the actual device passcode (no biometrics prompts are available at this stage).

The backup encryption works as per normal, encrypting the contents of the backup as well as the manifest.db file.

The structure of the resulting iTunes-style (not actually using iTunes) backup is going to appear just as it did prior to iOS 16. If we compare the encrypted vs non-encrypted backups, the standard artifacts will be missing.

In a non-encrypted backup, Call Logs and Safari history were not present in the device just like iOS dating back to iOS 13. Within the encrypted backup, both of those artifacts were there as well as the keychain data and health data.

In addition to acquiring data directly from the device, it’s also possible to acquire data using Magnet AXIOM from iCloud directly. Any devices running iOS 16 that back up to the cloud AXIOM will have the ability to pull those backups down and parse them.

iMessage Changes in iOS 16

With the release of a new version of iOS, there are usually new artifacts to parse! While Apple has yet to release all of their new additions to the software such as their new Passkey function, they did roll out their new changes to the Messages database. The Messages application added some new functions this time around including the ability to recall messages, edit messages in place, and flag conversations as unread for dealing with later.

Because of the idea of being able to recall a message from someone else’s device or edit the content after the fact, this obviously raises some forensic concerns. In addition to forensic concerns, there was several who expressed concern with this functionality and Apple made some changes throughout the beta versions of iOS 16.

With the Gold Master release of iOS 16, Apple has settled on the following rules. To recall a message, it must be done within the first 2 minutes after it’s sent. To edit a message, it must be done within 15 minutes of being sent. Also, both of these functions are reserved for iMessages only.

To a recall a message, a user just needs to long press on the message.

Pressing the “Undo Send” option will cause the message to ‘pop’ and then display an alert to both users.

Both users will get an alert that the message has been removed. Regardless, if the message is sent or received before being “undone,” it’s still treated the same within the message storage database. It’s worth noting that Apple warns the user recalling the message that if they’re not on iOS 16 (or macOS 13) the message won’t be recalled.

Messages that have been unsent will appear in the database (and most forensic tools today) with no content to the message.

In the above screenshot, this contains messages that were unsent as well as messages that were edited. When a message is unsent or edited, new records are not added, but the text column will be empty.

For unsent messages, not only will the text column be empty, but the attribuedBody column in the messages table will also be wiped out and replaced with a null value. This is rarer to see, so this can be a great indication of the message being recalled. In addition, a column called date_edited will contain an Apple Time (webkit) value counting in nanoseconds. While there is a date_retracted column, Apple doesn’t seem to be using it today.

In devices not running iOS 16 or macOS 13, the data will still be contained as it normally is without any deletions or changes (even if iMessage in the Cloud is enabled). This means that other devices that haven’t yet been updated are a prime source for information that can’t be recovered from the original device. To learn more about “unsent messages” check out this blog from Chris Vance at d204n6.

When a user chooses to edit a message, they can long press on the data again (as long as it’s within the 15-minute window) and then modify the data in place.

Apple has changed how they’re handling this data throughout the iOS 16 betas. Originally this information was changed within the attributedBody column, and while this data does contain SOME of the information, there’s another more important column.

In addition to capturing the edited message, Apple is capturing each of the edits along the way. If a user modifies a message over and over, Apple keeps the full content of each edit.

This information is stored within an embedded binary plist file found within the message_summary_info column. Messages that are edited will have a null content in the text column for the messages table. Currently, the attributedBody blob will store the most up to date message.

The other edited messages will be within the embedded plist. This is the same plist file that tracks if a message has been sent with Siri. Within this plist, a key called “ec” will contain each of the edits as well as a timestamp of when the edit occurred. Because Apple can’t ever decide which way to store times, they’re still the Apple Time (webkit) value but this time counting in seconds with decimal points.

The messages seem to be in order, and when extracted they appear just as the original attributedBody value did within the database.

Back in the original database, there is a date_edited column which is going to reflect when the final edit was made to the message as discussed with unsent messages (although it seems to be plus or minus a nanosecond or two).

For messages that were edited but synced to devices that aren’t on iOS 16 (or macOS 13), those messages will appear without the data in the attributedBody or message_summary_info columns.

As a quick reminder, and a change to poke fun at my Android-using friends, remember that these two features of iOS 16 are reserved for iMessages only.

Apple also added the ability to delete messages that doesn’t really delete them. Confusing? Well, think of messages now like photos on the device. Just because something is deleted, doesn’t mean it’s deleted, just means it’s flagged for deleted. By default, these messages will continue to exist within the database for 30 days.

The “deleted” messages actually will not appear any different in the messages table. However, there is a separate table chat_recoverable_message_join that tracks which messages are deleted and when they were deleted. The date value here is an Apple Time value (this time again in nanoseconds).

Safari Tabs

Apple has replaced the previously used BrowerState.db with a new SafariTabs.db as well. The BrowserState.db was still in present in our test device but the data was from before it was upgraded to iOS 16. All of the iOS 16 tab records were stored within the SafariTabs.db file. Apple continues to attempt to hide and/or obfuscate this information by burying it several levels deep.

In order to recover a tab’s history, the “bookmark” table must be examined first. Within the extra_attributes BLOB data is stored an embedded binary plist file. There’s some great data here including such as if the link was opened, if it was muted, and more.

There’s also the “SessionState” value which contains a binary plist file. However, it can’t be easy. Similar to how Apple stored data in the BrowserState.db, Apple pads the first few bytes of this data before the binary plist file actually starts.

Wrapping Up

As users jump to pre-order their new devices and upgrade their existing ones to the latest OS, you can feel confident in knowing that for the most part, we’re in a good spot forensically. While there are a few hurdles to overcome still (and some scarier ones to look at as well), Magnet AXIOM and ACQUIRE can help you image those iOS 16 devices and recover the artifacts that you expect to find.

For more information about iOS 16 changes or how AXIOM handles dealing with iOS images from ANY source, please feel free to reach out for more information!

Christopher Vance is Magnet Forensics’ Senior Technical Forensics Specialist. He frequently works on new research projects including looking into the latest versions of Android, iOS, and macOS. Christopher keeps many of these projects online at his blog “D20 Forensics” which can be found at http://d204n6.com.