Reverse Engineering iOS 18 Inactivity Reboot

Original Article ↗ Hacker News Discussion ↗

Overall reception

  • Many commenters praise the analysis and see the feature as a significant security improvement.
  • Others argue Apple is not “pushing the envelope,” noting similar features existed in hardened Android variants, but acknowledge the impact of a strong default on a billion devices.

How the inactivity reboot works (as discussed)

  • The reboot is coordinated by a kernel module, not enforced directly by the Secure Enclave Processor (SEP); SEP appears to request rather than force reboot.
  • If the kernel is compromised, attackers could theoretically suppress both the reboot and any panic.
  • The feature triggers purely on time since last unlock (AFU duration), not on network connectivity; tests showed reboots after 72 hours even with Wi‑Fi connected, undermining earlier “devices talk to each other” rumors.

Security model: BFU vs AFU and keys

  • Core goal is to return the device to “Before First Unlock” (BFU), where user data keys are not in RAM and only available from SEP after passcode/biometric.
  • Reboot is seen as the simplest reliable way to: drop keys, clear or invalidate RAM contents, and re-establish a clean chain of trust.
  • Commenters discuss iOS data protection classes: some data becomes unavailable whenever locked; others remain accessible until reboot/BFU.
  • There’s debate over how much RAM is actually wiped vs rendered unreadable via regenerated RAM-encryption keys.

Impact on law enforcement and attackers

  • Law enforcement commonly keeps seized phones powered on and isolated (Faraday cages) to exploit AFU state; emails reportedly show AFU vs BFU makes a huge difference.
  • The 3‑day limit greatly shrinks the window to deploy kernel exploits in bulk, potentially preventing “unlocking sprees” using older, post‑patch exploits.
  • Some argue cops will adapt by rushing AFU extraction; others say local agencies often lack zero‑days and rely on later-disclosed tools, so this still helps.

Usability, configurability, and edge cases

  • Concern about non‑configurable 3‑day timeout impacting kiosk-style or always‑on uses (wall‑mounted iPads, webcams, CarPlay, DIY home panels, “phone as server”).
  • Mitigations mentioned: kiosk/single‑app/Guided Access modes, keeping device unlocked, or disabling passcode (which likely disables the feature, though not clearly confirmed).
  • Several want user control over the timeout; others argue configurability would enlarge the attack surface if AFU exploits could extend or disable the timer.
  • Debate over whether 72 hours is a compromise between security and user experience, and if Apple might shorten it over time.