Mobile Device Forensics — iOS 14 Manual Forensic Acquisition and User Data Population
Abstract
The use of mobile devices has become prevalent since the past decade, providing further maturity to the mobile device forensics field. Taking into account the mobile device forensics community’s constant enhancement and evolvement over time, and staying current with the Apple devices as well as iOS updates, the main objective of this project was to acquire a forensically sound file system image of an iPhone with the latest iOS update (iOS 14) that Apple released to the public on September 14, 2020. With every new release, Apple establishes a new set of features and security structures that may hinder a complete forensic acquisition and analysis of Apple devices. While new discoveries are made every day in the field of mobile device forensics, in order to contribute a piece of new research, along with the process of acquiring the iOS forensic image, another objective was to populate user artifacts. The goal of the entire project was required to be accomplished with the use of only non-commercial mobile forensic tools. The major phases of the process included obtaining the device, wiping the device, updating the device, jailbreaking the device, acquiring the device, and populating test data for the purposes of thorough documentation and validation. This blog post details the thought process and specific steps executed to complete the task at hand with precise timestamps. The timestamps listed in this blog post for the entire process are in 24-hr, Eastern Daylight Time (EDT).
Device Selection and Metadata
The foremost step for the process was to obtain an iPhone that supported the iOS 14 update. More importantly, the iPhone had to be vulnerable to the selected jailbreak utility. From the research, it was discovered that around seven generations of iOS devices were vulnerable to the selected exploit and most importantly, capable of running a required version of iOS. Taking these factors into consideration, the iPhone 6s hereinafter “device”, was chosen for this project. Table 1 below shows the associated metadata of the device.
Forensic Acquisition Tools and Environment
Per the requirement, all the tools used during the project were non-commercial. Since the project was complex and the process was highly sequential, each of the selected tools served a specific function. While the MacBook Air and the device itself were key parts of the project, tools such as OpenSSH and iproxy played a central role as they provided a secure USB-SSH tunnel with a more stable connection and efficient way for the data transfer. The entire process was conducted under a full Wi-Fi network connection as no enclosed network environment was needed. Table 2 below lists all the resources used in this project including associated version numbers. Further network connections, as well as the final set up for the acquisition, are shown and discussed later in this blog post.
Device Wipe
The next step of the procedure for this project was to reset the device to factory defaults, which included a wipe of the device. While the device was purchased from the well-known online retail company named “Newegg”, resetting the device to its factory settings became even more imperative. The wiping of the device took place on September 17, 2020. As shown in Figure 1 below, from a physical view, the device had a few minor scratches on the screen. However, in terms of operability as well as functionality, the device had no major faults and was ready to be wiped.
As shown in Figure 2 below, the wiping of the device was conducted with the use of the “Erase All Content and Settings” functionality found within the “Reset” tab in the settings of the device. This specific utility wipes everything from the device, including email accounts, personal data, installed applications, and customized settings associated with the system. However, it is critical to note that it will not completely erase every bit of data as remnants of a certain data will be still left behind. For the purposes of this project, the device was completely wiped. This process is extremely critical as it provides a clean start for the use of the device and further offers an opportunity to set up the device as new or restore it from the backup.
Once the device progressed through the wiping process, it booted up with its default startup screen. In terms of device configuration, the selected language was “English”. The chosen country was the “United States”. Additionally, the “Set Up Manually” option was selected for the Quick Start setting. For the network connection, a specific Wi-Fi access point was selected. The Touch ID was not set up at the time and no backup option was selected for the application and data to be transferred. In terms of the creation of Apple ID, the “Set Up Later in Settings” option was selected. During this process, a four-digit passcode was also created which is detailed in Table 1. After concluding the typical (iOS) startup procedure of the device, the traditional home screen was displayed with the default applications installed. Figure 3 below depicts the state of the device once the start-up procedure was completed.
Device Update
Once the device wipe was successfully executed and documented, the observation of the device data revealed that it was running the iOS 13.1.2 version at the time. Thus, the next major step was to update the software of the device to iOS 14. The default setting for the automatic updates was off on the device. The total size of the iOS 14 update was 3.42 GB. For the purposes of documentation, in the meantime, wallpaper for the lock screen and home screen of the device was changed to the original earth wallpaper style. Eventually, the software update process was initiated at 22:57 on September 17, 2020. The terms and conditions associated with the update were accepted and the update was further requested. Once started, the entire process took a few hours due to the poor network connection at the time. From the request stage of the update to the actual download/install, the device had been kept untouched. The device was directly observed in the morning on September 18, 2020, at 09:07, which was the day after the update was initiated. Figure 4 below displays the major stages of the iOS 14 update procedure of the device.
Jailbreak
In the simplest terms, jailbreaking is the removal of certain security protocols/security level from an iOS device. In order to conduct an acquisition for this project, jailbreaking the device was extremely critical. As discussed in the Tools and Environment section, the utility used for jailbreaking the device was checkra1n, which is a community project that offers a high-quality semi-tethered jailbreak. Checkra1n jailbreak uses the exploit known as “checkm8” which was released to the public on September 27, 2019. This exploit leverages unpatchable BootROM vulnerability within Apple devices. The exploit, in particular, takes advantage of the Device Firmware Upgrade (DFU) mode which allows users to move a signed image to a device using USB for later booting. BootROM vulnerabilities are the trap-door making it possible for attackers to take control over the booting process and run unsigned code execution on devices. For the purposes of this project, using Checkra1n was the most effective option. While the iOS update was released to the public on September 14, 2020, the jailbreak exploit for iOS 14 was not released until the week after. Fortunately, the initial release of the iOS 14 exploit supported the device hardware used for this project.
Checkra1n Utility Installation
Checkra1n requires MAC/Linux environment for it to function. Thus, as mentioned in the Tools and Environment section, a MacBook Air was used for the installation. The installation process took place on September 27, 2020. Figure 5 below displays the navigation to the official website of the checkra1n jailbreak which is https://checkra.in. Figure 5 further shows the official page of the checkra1n with the download instructions and highlights of the utility.
Once on the official webpage, the software was downloaded by clicking the “Download for macOS” button. The download tab itself also displayed the hash for integrity preservation. As shown in Figure 6 below, the “checkra1n beta 0.11.0.dmg” file of 9.6 MB was successfully downloaded.
As depicted in Figure 7 below, the downloaded checkra1n file was placed into the “Applications” folder for further installation. However, upon executing the file, it triggered a security warning since checkra1n was not downloaded from Apple’s official app store.
In order to enable the execution of the checkra1n utility, the “security & privacy” settings of the MacBook Air were modified by clicking on the “Open Anyway” security feature shown in Figure 8 below. Once clicked, the final security warning with the button to open the utility was displayed. This was the final screen before the computer could let users bypass the security warning and execute an application. This step is further displayed in Figure 9 below.
Upon bypassing the “security & privacy” settings of the MacBook Air, checkra1n was successfully executed in its Graphical User Interface (GUI) format. The GUI of the checkra1n utility is shown in Figure 10 below.
Using Checkra1n for Jailbreaking
Once the checkra1n tool was successfully installed in the MacBook Air, the jailbreaking process of the device was initiated on September 28, 2020. Apart from the compatibility, no further requirements for the device being used were posed by the utility. Even though checkra1n is known for its greater reliability, backing up a device is highly recommended. However, since the device used was for the sole purpose of testing, no initial backup was performed. The device was then connected to the Wi-Fi and kept unlocked. In terms of communication, Apple’s USB lightning cable was used to connect the device to the MacBook Air. Once the connection between the device and computer was successful, a few software update requests were observed. However, they were rejected as the project revolved merely around iOS 14. Every time the device was connected to the computer, this was a very crucial step to keep in mind as it tried to update the device to iOS 14.0.1. Additionally, the connection between the device and the checkra1n utility was verified. The initial GUI screen of the checkra1n utility displayed the message that read “iPhone 6s (iOS 14.0) connected in Normal mode” because it precisely detected the device and firmware type. There were no changes observed within the device during this particular step. This step is shown in Figure 11 below.
Once the communication between the device and the checkra1n utility was established, the “start” button was pressed. The next screen of the GUI displayed a message that the device needs to be in the DFU mode. However, in order to prevent any sort of filesystem corruption, the device needs to be first put in recovery mode. When this message was displayed, no changes within the device screen were observed. This stage is displayed in Figure 12 below.
Once the “next” button was pressed in order to place the device in the recovery mode, the screen of the device turned dark. After less than a minute, the device was in recovery mode as it displayed an icon of a USB cable and iTunes. It also showed the message called “support.apple.com/iphone/restore”. Once the recovery mode was on, the “next” button was clicked. This is shown in Figure 13 below.
Once the device was successfully placed in the recovery mode, as shown in Figure 14 below, the required three steps to get into the DFU mode were displayed on the Checkra1n GUI. Those steps detailed specific instructions for the Home as well as the Side buttons of the device. Specifically, those steps read “1. Click Start, 2. Press and hold the Side and Home buttons together (4), 3. Release the Side button BUT KEEP HOLDING the Home button (10)”. Then, the “start” button was clicked to proceed with the DFU mode process.
Initially, per instructions, the device’s Home and Side buttons were simultaneously pressed for 4 seconds, then the Side button was released while keep holding the Home button for 10 more seconds. Unlike the recovery mode, the display of the device turned dark after the first 4 seconds were passed, indicating the DFU mode. The process is displayed in Figure 15 below.
As soon as the device was in the DFU mode, the process for the installation of the jailbreak started immediately. The message displayed on the checkra1n GUI was “If the device asks for a passcode, please enter it. Do not disconnect the device until finished”. The installation process involved setting up the exploit and then booting. This process is shown in Figure 16 below.
As the device was booting into the jailbroken mode, checkra1n-themed verbose boot screen was visible on the device. Once the booting was complete, again a plain Apple logo was displayed on the screen, and the “All Done” message was displayed on the checkra1n GUI. This is shown in Figure 17 below.
As soon as the jailbreak bootup process was complete, the device was turned on and it displayed the unlock screen. At the same time, once again, a software update pop-up was observed on the MacBook Air screen but it was denied. Once the device was unlocked, the successful installation of the checkra1n application was observed in the device. At this time, the lightning cable was disconnected. These observations are further shown in Figure 18 below.
Post Jailbreak Process
The goal of removing a certain security level within the device was achieved with the successful jailbreaking of the device. However, in order to proceed with this project and obtain software installs unavailable on the traditional Apple app store, Cydia was installed through the checkra1n loader application in the device. Cydia is a packet manager mobile application for iOS. This particular app store allows users to explore and install various software that are not authorized by Apple on a jailbroken iDevice. As soon as the checkra1n loader app was opened, the install for Cydia was ready. Once tapped on the Cydia cell, it presented a pop-up for the install named “install Cydia”. When tapped on that, it took around 2 minutes for the complete downloading of the base system and installing Cydia. The device was restarted after the installation of Cydia. This process is shown in Figure 19 below.
Once the Cydia app was successfully installed in the device and opened, it displayed a few data associated with the device’s identifier: iPhone 8, 1; iOS software version: 14.0; and Cydia version: Cydia64_1.1.36 (en-us). A pop-up window regarding the upgrades also showed up immediately. A complete upgrade was performed as this is an open-source application and pushes are constantly made in order to update the functionality of the features offered and the efficacy of the application itself. Once the complete upgrade was selected, an entire list of modifications was displayed. When the upgrade was completed, the springboard was restarted for official use. The complete Cydia upgrade process is shown in Figure 20 below.
Manual Forensic Acquisition
In the realm of mobile forensics, when commercial tools do not support the immediate acquisition of a device upon a release of its new iOS version, acquiring a device manually has always been an option. Once the device was jailbroken, it was ready for the next stage of this project which was to conduct a forensic manual file system acquisition for testing purposes. This is because the second major part of the project was to also populate user data. For an overview, Figure 21 below shows the overall setup for the acquisition. In general, the process involved an establishment of a USB-SSH connection as a root user to obtain the file system data. In this process, communication with the device file system played an imperative role. The detailed steps of the entire (test) process are as follows.
Once the device was jailbroken and Cydia was successfully installed, in order to conduct the test acquisition/analysis, the first step was to install SSH. Therefore, a utility named “OpenSSH” was installed in the device via Cydia. This specific utility is a highly favored SSH utility for iDevices. This vital utility is essentially an open-source application that employs the SSH protocol to communicate with the device to enable remote connection with the device. OpenSSH installation process is displayed in Figure 22 below which took place on October 5, 2020.
While accessing the device is feasible with the use of SSH over Wi-Fi, the copying of the data from the device can take a considerable amount of time. Therefore, there was a further need for a tool that can provide a wired connection with the device. Taking that into account, a tool named iproxy was installed into the computer. This tool is a package that is essentially a part of the libimobiledevice suite of utilities. Since the “homebrew” mechanism was not operating effectively, the utility was installed via the “sudo port install libimobiledevice” command. This specific step is shown in Figure 23 below.
Once the libimobiledevice utility was successfully installed to ensure that the iproxy package is usable, the device was connected to the computer via the USB cable. This connection is displayed in Figure 24 below.
Next, the iproxy tool was utilized as it creates a usbmuxd (USB) connection from the connected device to the computer by listening to SSH connections and forwarding them to another port. The command “iproxy 4242 44” was executed. Port 4242 was specifically used for the local TCP port and port 44 was used for the device TCP port. An SSH server is deployed on port 44 on the localhost only; therefore, it was exposed on the local machine using the iproxy tool. This tool provides an ability to interface with the file system within the device. The step is depicted in Figure 25 below.
The next major step was to SSH into the device. This was done via the use of the built-in SSH client on the MacBook Air. For this process, the port in use (4242) was precisely specified as it was configured from iproxy above with the use of the “-P” command. The login was done as a “root” on the localhost. As usual, its address is 127.0.0.1. Essentially, this command provided the root access but also opened up access to the home directory. Due to the use of “root”, the observed directory was “/var/root”. This process is depicted in Figures 26–27 below.
For a quick analysis, partitions of the device were obtained with the use of the “mount” command. The observed partitions are displayed in Figure 28 below. As described by Sarah Edwards in her research, there are generally at least two major partitions that are of interest to digital forensics researchers and examiners. They are the “System” and “Data” partition. The Operating System (OS) is contained in the “System” partition. This specific partition is on the “/dev/disk0s1s1” device and mounted on “/”. The user preferences, data files, as well as different configurations are contained in the “Data” partition which is also known as the “User” partition. Particularly, this partition is on the “dev/disk0s1s2” and mounted on “/private/var”. Unlike the “System” partition, it is critical to keep in mind the encryption scheme associated with the “Data” partition. Taking into consideration the output of the partitions shown in the figure below and what Sarah Edwards discussed in her research, the “System” partition of the device was displayed as “/dev/disk0s1s1 on / (apfs, local, nosuid, union, journaled, noatime)” and towards the end, the “Data” partition of the device was mounted on “/private/var” directory.
From the step above, two (test) acquisitions were conducted (which are not documented as they were only to test if the device allowed the manual acquisition). Those two separate test acquisitions were specific to the “Data” or “User” partition (“/private/var/”) as well as an entire (full) drive (“/”).
Since two test forensic acquisitions of the device were successfully obtained, it further provided a green flag to proceed with the second part of the project which was to populate user data in the device before conducting the final manual acquisition of the device. The data population is documented in the link provided at the end of the blog.
Just for a note — a few data were populated as soon as the device was obtained in September; however, the data population process was paused to test if the device permitted initial (test) manual forensic acquisition as discussed above. Once the test acquisitions were completed, the data population process was resumed and finished on October 26, 2020. After that, the approval was obtained for the final forensic acquisition of the device containing the data population. The final manual forensic acquisition process was conducted on October 26, 2020. As usual, the device was first connected to the computer via a USB cable. This connection is depicted in Figure 29 below.
As usual, the iproxy tool was used to establish a connection between the device and computer with the configuration of ports 44 and 4242. This step is depicted in Figure 30 below.
The command used for the acquisition of the entire drive was “ssh root@127.0.0.1 -p 4242 “tar -cf - /” > /Users/malaypatel/Desktop/output/Patel_Final _Full_Drive_Acq.tar”. This command took into consideration the localhost as well as the previously configured port 4242. The acquisition command used the tar utility in which the “-c” attribute indicates the use of a mode specifier. In this case, it specifies “Create”. The use of the “-f” attribute indicates the use of common options. In this case, it specifies “Filename (Location of Archive)”. Next, instead of selecting a specific directory (e.g. “/private/var/”), the sole use of the “/” attribute acquired the drive in its entirety. The output was redirected to the “Patel_Final_Full_Drive_Acq.tar” file within the “output” folder on the desktop in the MacBook Air. In each stage of the process, when the password for the SSH root was requested, the default password of “alpine” was used. However, the password for root was changed afterward for the purposes of privacy. This part of the acquisition process is displayed in Figure 31 below.
As soon as the final acquisition was completed after around 20 minutes, the output tar file of 16.08 GB was spotted in the associated output directory. The output file is displayed in Figure 32 below.
Later on, for the purposes of sharing such a large file, the file was compressed via the gzip utility. The submission file was named “Patel_Final_iOS 14_Full_Drive_Acq.tar.gz” which was 8.01 GB in size.
Cryptographic Checksums
Patel_Final_Full_Drive_Acq.tar (16.08 GB):
- MD5: f047d320a49d2eea7faaf977da08f2bf
- SHA1: 95d72c0ea0a4b22a64d141100b068a1f2cb23991
Patel_Final_Full_Drive_Acq.tar.gz (Gzipped File) (8.01GB):
- MD5: 451b04d429dfbcd158908f28eb1f5ac6
- SHA1: 2c93a3cd4335e4350b0f33f1662d0b7080807874
Downloads
Access to the iOS 14 forensic image as well as the data population documentation can be found here. The image is available to anyone who wants to use it for the purposes of testing or research.
Acknowledgement
A special thank you to Jessica Hyde for providing the opportunity to conduct the forensic acquisition of a mobile device with the latest iOS update and share it with the digital forensics community.
References
Checkra1n Jailbreak, Checkm8 Exploit Analysis | Checkm8. (n.d.). Retrieved October 17, 2020, from https://checkm8.info/blog/checkra1n-jailbreak-exploit
Creating a File System Image of iOS12 (12.1/16B92). (2019, May 23). Retrieved October 17, 2020, from https://www.4n6files.com/2019/05/creating-file-system-image-of-ios12.html
Edwards, S. (2016, March 23). IOS Imaging on the Cheap! Mac4n6.Com. http://www.mac4n6.com/blog/2016/3/23/ios-imaging-on-the-cheap
Hickman, J. (2020, April 19). Index of /corpora/cell-phones/ios_13_3_1. http://downloads.digitalcorpora.org/corpora/cell-phones/ios_13_3_1/
