iOS Inactivity Reboot
Apple continues to bolster the security of its mobile lineup with the introduction of the “Inactivity Reboot.” This feature automatically reboots the device after 72 hours of inactivity, forcing the device into a state that is resistant to exploitation and data exfiltration. This feature has been around since iOS 18.0; however, as Chris Vance mentions in his blog post [1], the timer was originally set to reboot the device at 168 hours (one week) of inactivity. As of iOS 18.1, the timer was shortened to only three days of inactivity.
An identical feature known as “auto-reboot” was introduced into the security-focused Android operating GrapheneOS back in 2021 [2]. Several Android devices have adopted the same feature, with Apple following suit. Graphene had originally set the time to reboot at 72 hours (just as Apple has) but has since changed it to only 18 hours by default [3]. This feature has proven effective against forensic acquisition techniques.
While this feature is undoubtedly beneficial for users' privacy and security, it has also raised concerns among law enforcement agencies, who may find it more challenging to extract data from locked iPhones. The new feature highlights the conflict between user privacy and law enforcement needs, as mobile devices are now an integral source of evidence. It remains to be seen how the mobile forensics landscape will adapt to this security measure, whether it will lead to advancements in Mobile Forensic Acquisition technologies or if it will lead to potential legal disputes.
How Does a Reboot Make a Device More Secure?
Once a mobile Apple device is rebooted, nearly all data on it becomes encrypted until it is unlocked at least once (more on this later). Additionally, the number of attack surfaces is greatly reduced until a device is unlocked at least once.
Take WiFi for example – When a device is rebooted WiFi is entirely disabled until the device is unlocked at least once. Suppose an exploit has the ability to write files or inject code as long as a WiFi connection with that device can be established. Until the device is unlocked, that exploit becomes effectively useless. The same can be said for nearly all USB-accessible services and communication with third-party wireless devices.
The reboot also flushes memory contents which not only further secures the device but may also serve as a performance boost. Note, since iOS 17 there has been an influx of other memory flushing mechanisms. I have personally encountered some issues with memory flushing hindering device usability. This new feature is a massive improvement to overall operating system security; it also hinders data acquisition techniques used by forensic examiners.
Why is this important for examiners?
Forensic examiners leverage software, firmware, and hardware weaknesses to obtain data from mobile devices (with the exception of logical acquisition). Data stored on mobile Apple devices is subject to what is known as Data Protection Classes. Entries within the filesystem are tied to a class ‘A’ through ‘D’ which details how accessible each entry is:
Files with Class A protection: Can only be read if the device is unlocked at the very moment.
Files with Class B protection: Can only be read if the device has marked the files as important to be read while the device is locked. For example, this might include application installation contents as the app will continue to be installed when the device is put to sleep.
Files with Class C protection: Can only be read once the device has been unlocked at least one time after reboot. A device which has been unlocked at least once since reboot is known as After First Unlock (AFU).
Files with Class D protection: Can always be read without restriction. A device which has not been unlocked at least once since reboot is known as Before First Unlock (BFU).
Much of the data which forensic examiners rely on is classified as Class C data. With a proper suite of tools, and a device willing to communicate with a PC, Class C data may be obtained if the device is in After First Unlock. In some cases (e.g., when a new iOS version is released) tools will not have the ability to communicate with the device at a low level and obtain class C data even when the device has been unlocked since reboot.
To solve this problem, examiners oftentimes opt to obtain the device, keep it plugged in to ensure that it does not power off (as this would force BFU), and wait for tooling to support devices in AFU. Herein lie the challenges introduced by inactivity reboot. Examiners will no longer have the option to wait for tooling support; not for more than three days at least, since at this point the device will be kicked out of AFU and pushed into BFU. The change in accessible data classes, along with a reduced attack surface, greatly hinders the ability to recover data from devices. Note if a passcode is provided data will still be recoverable since the examiner can manually put the device in AFU by simply unlocking the device.
What Does This Mean For DFIR?
Security for mobile devices is evolving and introducing new hurdles for vulnerability researchers and forensic examiners. Implications for Digital Forensics and Incident Response include:
Further complication of evidence preservation: Volatile data will be erased when the device is rebooted.
Increased resource demands: Tooling vendors are pressured to research and mitigate this feature as fast as possible (or find alternate methods of data acquisition). Law enforcement agencies are pressured to maintain a large number of technical personnel to acquire evidence as fast as possible.
For the time being, law enforcement must adopt new best practices, prioritizing passcode recovery, rapid device seizure, and rapid data acquisition whenever possible. When a device is sized, Mobile Forensic Acquisition tool developers are compelled to accelerate the development and deployment of effective recovery techniques to race against the timeout limitations.
Exploitation of devices in BFU mode is theoretically possible as was seen back in the days of the iPhone X vulnerable to the Checkm8 exploit [4] which targeted DFU mode, although development of such an exploit is magnitudes more difficult.
Unified Log Analysis
A trail of logs in the unified logging system provides insight into the device reboot. The following log is written as the device is instructed to reboot.
The kernel (specifically the keybag daemon located at /usr/libexec/keybagd) along with the AppleSEPKeyStore kernel extension instruct the device to reboot – more on this later.
The system will then continue to perform a standard reboot function by breaking down running applications and forcing the device to restart.
Code Analysis
The keybag daemon (/usr/libexec/keybagd) is a background service which automatically starts when the mobile device boots. This service plays a vital role in keeping user data safe by managing how the filesystem and protected items are encrypted and decrypted. The service is managed by a file known as a launch daemon; located at /System/Library/LaunchDaemons/com.apple.mobile.keybagd.plist, the launch daemon tells the system to automatically run the keybagd service at startup.
When the device is unlocked for the first time, the service pushes out a notification throughout the system and unlocks class C files on the device. The notification is detected by other services which understand that the vault is now unlocked and loosen other restrictions accordingly. The theoretical device is now in AFU mode.
Analysis of the keybagd executable is straightforward as the executable is easily accessible. The AppleSEPKeyStore kernel extension is not as accessible. To analyze the extension, I first exported the kernelcache from a jailbroken iOS 18.2 device (iPad 7th Gen). Alternatively, you may use the ipsw [5] tool to export the kernelcache from an iOS release directly (e.g., ipsw download appledb –device [DeviceVariant] –os iOS –version [Version] –kernel).
Next, I can import the kernelcache into Ghidra and export the com.apple.driver.AppleSEPKeyStore executable.
AppleSEPKeyStore
With the executable extracted, I opt to use disarm [6] to disassemble code. The following command is used to disassemble the entire executable:
By narrowing the output down to a specific function (func_0xfffffff0086e4f08), the output may be filtered to only include unified logging messages. Here we may find the message which was identified earlier on in the unified logs!
Tracing back to where the function which calls this log message originates, we are able to identify the IORegistry property “aks-inactivity”.
When this variable is set to 1 the device will perform an inactivity reboot. But where is this variable set, how does the device know at which time to enable this variable, and how is this variable reset after reboot?
The device restarts when the timer reaches exactly three days (= 72 hours = 259200 seconds). I attempted to search for this value across several different kernel extensions with little luck; although I found some other services which also coincidentally time out at 72 hours. A great blog post covering the codebase of the inactivity reboot by @naehrdine [7] got to the bottom of this. By using leaked SEP firmware encryption keys, they were able to identify the code which checks how long the device has been locked and compares that value to three days. Storing these values in the SEP directly is a safe choice by Apple as the SEP is difficult to interact with from an attacker’s perspective.
keybagd
As stated earlier on, the keybagd executable is launched every time the device boots. On launch, the keybagd daemon will check if the internal variable “aks-inactivity” (aks standing for “Apple KeyStore”) is set to true. If it is, the variable will be deleted. If the variable were not deleted, then the device would likely remain stuck in an infinite reboot. Pseudocode
Summary
The introduction of the ‘Inactivity Reboot’ feature presents a new challenge for digital forensics. The future of this feature remains uncertain, and I am interested to see if Apple will allow users to modify the length of the timer or if they will shorten the default timer as Graphene has in the past. Apple’s mobile security measures are evolving, and forensic tooling will need to adapt to reflect that.
It is recommended that Extractions should occur as immediate to seizure as possible to allow for greater amounts of data acquired from AFU extractions. Unless the device is actively being used when seized, it is impossible to determine how much time is left on the 72-hour countdown. It is also worth noting that this time frame could be changed in different versions of iOS as it has already been reportedly changed from 96 hours to 72 hours [1]. The rebooting from AFU to BFU feature is currently affecting multiple Operating Systems and may continue to grow requiring the need to adapt procedures to ensure the preservation of data.
