Using Magnet AXIOM on Devices Running Up to iOS 13
iOS 13 was recently released, along with a new set of iOS devices to go along with it. There are several things to consider with iOS 13 and how to handle iOS as a whole in the forensic landscape.
With the recent release of Magnet AXIOM 3.6, AXIOM can now:
- Handle iOS 13 devices for Quick imaging
- Ingest and process full file system images from iOS 13
- Acquire iCloud backups from accounts that have 2FA enabled for iOS 11 and iOS 12
- Ingest Apple Warrant Returns
No matter which part of an iOS investigation you have, AXIOM has you covered. In this how-to, we’ll go over these new capabilities and how you can use them to find evidence in your investigations.
iOS 13 Quick Imaging
The biggest point anyone should understand going into iOS 13 backups is that you absolutely should be applying a backup encryption password to the device. Previously, data like that from the keychain and health kit were locked behind encrypted backups, but with iOS 13 that can also include Safari history and call log data too!
Part of the issue coming to iOS 13 and encrypting your backups, is that now examiners must provide the device handset PIN in order to apply, change, or remove a backup encryption password. If a backup encryption passcode is already set on the device from iTunes, you’ll also have to provide it along with the handset PIN in order to proceed.
AXIOM had added information to our prompts to alert users that this device PIN will be required in order to kick off the backup process. At the end of the process, if the user did not already have a backup encryption password set and the examiner set one, the iOS device will prompt for the handset passcode in order to allow AXIOM to remove the password. Since we use a single-stage process between imaging and processing, if a user isn’t around to change this, AXIOM will time-out the removal of backup encryption password after three minutes and continue on to processing. Users will need to go back and remove this backup encryption password later manually by using iTunes.
Since most of your iTunes backup images will be encrypted, we wanted to have a better way to deal with those. With AXIOM 3.6, we’ve changed the way encrypted backups are handled in AXIOM so that you will see the data from the encrypted backup that is NOT encrypted like media and information from the Info/Manifest.plist file, as well as a secondary set of data from the decrypted backup. Using the File System explorer, examiners will be able to browse the data in this decrypted copy which has been rebuilt in AXIOM’s more friendly file system view compared to a raw backup.
From the stance of processing iOS 13, a lot of the artifacts are the same this time around. Some notable exceptions are for the Safari application. After moving to its own AppDomain several versions back, it’s now rejoined its earlier spot back in the HomeDomain-Library/Safari/ directory, joining the Bookmarks.db file. In addition to the history database, the browser tab storage (BrowserState.db) has also moved to this folder. There’s still an AppDomain-com.apple.mobilesafari folder found in the Quick images which contains the Recent Search Terms still in its plist preference file. Safari still seems to be keeping the same 30 day time frame as before.
Another big addition to the Quick images in iOS are the presence of lots of additional .ktx files! These .ktx files are Apple’s answer to the old .png file snapshots of applications as they are minimized. They haven’t been in backups nearly this much in a long time. There’s a downside though, .ktx files are hard to deal with on Windows (for now). These .ktx files, when reviewed, will have lots of great data for both first party and third party applications as they have been minimized in the background.
Another great addition to the Quick-style image of iOS is inclusion of data that’s part of the “Files” app for iOS. Apple is keeping this data within the HomeDomain for both data that is currently stored locally as part of the files app but information on files that are stored in the cloud as part of the user’s iCloud drive. Stored within HomeDomain-Library/Mobile Documents/, examiners can find a folder structure for applications that are allowed to store data natively here as well as a set of “iCloud ~[BundleID]” folders. The com~apple~CloudDocs folder contains a listing of files that are stored within the iCloud Drive account of the user. Not every file is backed up to the iPad though. Files that are not synced locally will have the same name of the file, but abbreviated with a “.” and have a .icloud extension. These are actually property list files which will contain the file name and the size of the file stored in iCloud.
Under HomeDomain-Library/ApplicationSupport/CloudDocs examiners will find information about the iCloud drive storage as well. An account.1 file will reveal the numerical value for the synced Apple ID account while the session folder will store a server.db and a client.db in the db folder. These files can list out all of the files and folders being stored within the user’s iCloud drive accounts which can give a lot valuable intel to examiners in order to pursue the stored cloud files in other ways.
When it comes to iPad devices, Apple is now technically calling the operating system “iPadOS” with version 13. It’s still the same as iOS, but with a few additional features, and a few additional artifacts. Part of iOS 13 is that Safari got a better experience on iPad. This includes the way to actually download files from the web. When a user starts a download, a property list file will track these downloads and the user has the ability to assign where they would like the files to live. By default, they’ll live in the “Downloads” folder within the iCloud drive.
To find files that may have started the download but not completed, the AppDomain-com.apple.mobilesafari has some information for us. Within AppDomain-com.apple.mobilesafari/Library/Safari/Downloads is a Downloads.plist file similar to macOS. This file will track when downloads are started but only holds the downloads for around 24 hours. Files that have started downloading but not finished will also live in this Downloads folder under a GUID that is stored in the Downloads.plist file.
This plist will display a “Path” entry for files that have not yet finished downloading or the download was canceled. The “State” entry refers to whether or not the download is completed, in progress, or canceled. For files that were canceled before ending up in the “Downloads” folder, the path will show where the data that has been downloaded will live. The BookmarkData entry in the property list is embedded data that can store the files intended path.
iOS Full File System Handling
What if you have a full file system image for iOS 13? With the release of the checkm8 exploit, jailbroken devices may rise in popularity. Law Enforcement can already gain access to full file system images from iOS 13 devices and then ingest and process those images in Magnet AXIOM. Many of the file-system type artifacts such as PowerLog and KnowledgeC haven’t changed dramatically from iOS 12 to iOS 13.
One large change from full file systems is that the databases for Apple Mail application have changed their schema. The Protected Index database has changed and full contents of the messages don’t appear to be in the database as before (at least at the time of testing) but snippets of the messages were available from this database. .EMLX files that are left behind on the device are still cached and fully available for review using the Apple Mail Fragments artifact.
iCloud Backup Acquisition
If an examiner has the ability to download the iCloud backups of a user, AXIOM can now assist with this as well. If the account was created post-iOS 10.3, Apple enables two-factor authentication by default and won’t let the user disable this option. With AXIOM 3.6, users can now download the stored iCloud backups of any iOS device up to and including iOS version 12. iOS 13 support is also currently being actively worked on for support. Even if device backups are iOS 13 and higher, AXIOM still allows the examiner to acquire the iCloud drive files, mail, and photo data that have been synced with iCloud.
Handling Apple Warrant Returns
If an investigator doesn’t have access to the live device or the iCloud backups, they often will have to deal with the warrant return data produced by Apple. Users of the Cloud module can import these .zip files (after completing the PGP decryption) by using the Cloud -> Load Evidence -> Apple option. AXIOM will automatically process all backups that are produced as well as any other files produced as part of the iCloud drive for review.
Any detected backups will be decrypted automatically and processed for information as any other standard iTunes/iCloud backup type. Examiners can then differentiate between those backups by using filters in the Artifact Explorer’s Source fragment or by using a right-click, “View Related Artifacts” option from within the File System explorer.
As you can see, AXIOM is ready to help you deal with iOS forensics however you get the data. Whether from a live device, from the Cloud, or from Apple’s warrant returns, AXIOM can help examiners acquire and process a number of existing and new artifacts. It’s really become a fun time for iOS forensics again!