Full Report
iOS 18 contains a new security feature—an inactivity reboot. This feature was widely discussed in the media, with the potential for a wireless component, with other iOS phones communicating with it as well. So, the author decided to investigate how the feature worked. There are two important states of an iPhone for this post: before first unlock (BFU) and after first unlock (AFU). BFU requires the passcode, not Face ID, to unlock the phone. This is because the user data is encrypted with the PIN. Once it's unlocked for the first time, the user data is decrypted, giving access to much more functionality and attack surface. The AFU state is much more susceptible to attacks than the BFU state as a result. Apple code contains a lot of DEBUG strings. A quick search shows a string called inactivity_reboot on Github. After reverse engineering some logs and kernel drivers, they came to the Secure Enclave Processor (SEP) as the source of this reboot happening from. Recently, the firmware keys for this were leaked, allowing for reverse engineering of the code via binary ninja. Unfortunately, there are no symbols and very few debug strings. The rumor is that the reboot happens after 72 hours. So, the author searched for the constant in seconds and milliseconds. Sadly, optimizations are made, but binary ninja knows how to undo these optimizations to search for the values still! Crazy! They found a series of values that corresponded to 3 days, 2 days, 1 day, and 2.5 hours as an enum in the code. Neat! They didn't look much deeper than this. But, they did find out that there is nothing to do with phones communicating with each other to do this - it's all just an internal timer. This was an interesting dive into a new security feature by Apple. Law enforcement doesn't seem happy with this change but it also acts as a major improvement against theft. Good writeup!
Analysis Summary
# Research: Reverse Engineering iOS 18 Inactivity Reboot
## Metadata
- **Authors:** Jiska Classen
- **Institution:** Independent / HPI (Hasso Plattner Institute)
- **Publication:** cat /dev/brain (naehrdine.blogspot.com)
- **Date:** November 17, 2024
## Abstract
This research investigates the "Inactivity Reboot" feature introduced in iOS 18, which automatically restarts an iPhone after a period of non-use. By transitioning the device from the "After First Unlock" (AFU) state back to the "Before First Unlock" (BFU) state, Apple has introduced a significant hurdle for forensic extraction and theft. The study deconstructs the mechanism through kernel and Secure Enclave Processor (SEP) analysis to clarify how the timer works and debunk rumors regarding peer-to-peer wireless triggers.
## Research Objective
The research aims to answer three primary questions:
1. What triggers the iOS 18 inactivity reboot?
2. Does the reboot rely on external wireless communication between iPhones, as suggested by law enforcement reports?
3. Where does the timer logic reside within the iOS architecture (Kernel vs. SEP)?
## Methodology
### Approach
The author utilized a reverse engineering workflow involving:
- **String Analysis:** Searching for debug strings in iOS system files.
- **Kernel Debugging:** Analyzing kernel extensions (`KEXTs`) related to power management.
- **SEP Firmware Analysis:** Examining the Secure Enclave Processor’s highly secure, isolated environment using recently leaked firmware keys.
### Dataset/Environment
- Devices running iOS 18 and iOS 18.1.
- iOS kernel cache and SEP firmware binaries.
### Tools & Technologies
- **Binary Ninja:** Used for disassembly and decompilation, specifically leveraging its ability to de-optimize hair-pinned constants.
- **GitHub Search:** To identify references to `inactivity_reboot` in leaked or analyzed Apple code.
- **img4tool:** For processing Apple's secure image formats.
## Key Findings
### Primary Results
1. **Internal Mechanism:** The feature is an internal timer-based trigger; it does **not** rely on wireless signals from other iPhones.
2. **SEP Integration:** The timer is managed by the Secure Enclave Processor (SEP), making it extremely difficult to bypass via the main Application Processor (AP).
3. **Threshold Identified:** The reboot default is set to **72 hours** (3 days) of inactivity.
4. **State Transition:** The reboot effectively moves the phone from AFU (decrypted keys in RAM) to BFU (keys purged, data encrypted), significantly reducing the attack surface.
### Supporting Evidence
- Discovery of an enumeration in the SEP firmware containing values corresponding to:
- 259,200 seconds (3 days)
- 172,800 seconds (2 days)
- 86,400 seconds (1 day)
- 9,000 seconds (2.5 hours)
### Novel Contributions
- Debunked the "mesh network reboot" theory circulated in law enforcement memos.
- Provided transparency into the role of the SEP in enforcing inactivity policies.
## Technical Details
The "Inactivity Reboot" logic begins in the kernel but is enforced by the SEP. In iOS 18, a specific kernel extension monitors user activity. When the device remains locked and inactive, it signals the SEP. The SEP maintains a persistent timer. If the timer reaches the 72-hour threshold without an unlock event, the SEP mandates a system reset. Because the SEP manages the encryption keys, this reset ensures the keys are wiped from memory and can only be regenerated by the user's passcode entry (BFU).
## Practical Implications
### For Security Practitioners
- **Data Protection:** This feature serves as a "dead man's switch" against sophisticated forensic extraction tools that rely on a device staying in AFU state to brute-force or exploit the OS.
### For Defenders
- **Theft Deterrence:** A stolen iPhone becomes significantly less valuable after 72 hours, as the data is effectively "locked down," and the resale of a BFU device is hampered by Activation Lock.
### For Researchers
- **SEP Vulnerabilities:** Future research may focus on whether the SEP timer can be spoofed or reset via hardware-level glitches.
## Limitations
- The study did not deeply investigate the specific user "activity" triggers (e.g., whether simple charging or sensor movement resets the timer).
- Analysis relied on leaked SEP keys, which may not be available for all hardware generations.
## Comparison to Prior Work
Previously, iPhones would only reboot due to crashes or manual intervention. This research identifies the first time Apple has implemented a "scheduled" security reboot for the purpose of state-transitioning from AFU to BFU.
## Real-world Applications
- **Forensics:** Law enforcement must now extract data within a 72-hour window or risk losing access to AFU-available data.
- **Privacy:** Users who lose their devices have an automated safeguard that eventually protects their data even if the device is not connected to the Internet.
## Future Work
- Investigating if the 72-hour timer is adjustable via MDM (Mobile Device Management) for enterprise users.
- Analyzing if other Apple devices (macOS, iPadOS) have implemented similar SEP-based inactivity timers.
## References
- 404 Media: "Police Freak Out at iPhones Mysteriously Rebooting Themselves"
- Apple SEP Security Documentation (General)
- Binary Ninja API documentation for constant folding/de-optimization.