9 ms·

Reverse Engineering iOS 18 Inactivity Reboot

• Dohnm13_th 2y ago
  [dead]
• chews 2y ago
  thank you for such a great writeup, this is an excellent breakdown!
• threeseed 2y ago
  I suspected this was being managed in the Secure Enclave. That means it's going to be extremely difficult to disable this even if iOS is fully compromised.
  • karlgkk 2y ago
    If I’m reading this right: Reboot is not enforced by the SEP, though, only requested. It’s a kernel module, which means if a kernel exploit is found, this could be stopped. However, considering Apple’s excellent track record on these kind of security measures, I would not at all be surprised to find out that a next generation iPhone would involve the SEP forcing a reboot without the kernels involvement. what this does is that it reduces the window (to three days) of time between when an iOS device is captured, and a usable* kernel exploit is developed. * there is almost certainly a known kernel exploit out in the wild, but the agencies that have it generally reserve using them until they really need to - or they’re patched. If you have a captured phone used in a, for example, low stakes insurance fraud case, it’s not at all worth revealing your ownership of a kernel exploit. Once an exploit is “burned”, they distribute them out to agencies and all affected devices are unlocked at once. This now means that kernel exploits must be deployed within three days, and it’s going to preserve the privacy of a lot of people.
    • toomuchtodo 2y ago
      Would be nice if Apple would expose an option to set the timer to a shorter window, but still great work.
      • jojobas 2y ago
        Or to disable it entirely. Someone could set up and ipad to do something always plugged in, would be bloody annoying to have it locked cold every three days.
        • mjevans 2y ago
          I'd rather have a dedicated Kiosk mode that has a profile of allow-listed applications and one or more that are auto-started.
          • aspenmayer 2y ago
            Maybe one or two of these will do what you want? https://support.apple.com/en-us/105121 https://support.apple.com/en-us/105121 > With Screen Time, you can turn on Content & Privacy Restrictions to manage content, apps, and settings on your child's device. You can also restrict explicit content, purchases and downloads, and changes to privacy settings. https://support.apple.com/en-us/111795 https://support.apple.com/en-us/111795 > Guided Access limits your device to a single app and lets you control which features are available.
            • duskwuff 2y ago
              Or "single-app mode", which is a more tightly focused kiosk mode: https://support.apple.com/guide/apple-configurator-mac/start-single-app-mode-cadbf9c172/mac https://support.apple.com/guide/apple-configurator-mac/start...
        • grahamj 2y ago
          Conspiracy theory time! Apple puts this out there to break iPad-based DIY home control panels because they're about to release a product that would compete with them.
    • dmitrygr 2y ago
      > Reboot is not enforced by the SEP, though, only requested We (the public) do not know if SEP can control nRST of the main cores, but there is no reason to suspect that it cannot.
      • karlgkk 2y ago
        We actually do know, it cannot directly*. What it could do is functionally disable RAM, but that would basically cause the phone to hard lock and even cause data corruption in some limited cases. This is still being actively researched. I have no evidence, but would not be surprised to find out that a SEP update has been pushed that causes it to pull RAM keys after the kernel panic window has closed. * This may have been changed since the last major writeup came out for the iPhone 11.
        • dmitrygr 2y ago
          iPhone 11, the one 5 years ago? So yes, you have not at all refuted my statement for any recent phone
    • grahamj 2y ago
      > Reboot is not enforced by the SEP, though, only requested. It’s a kernel module, which means if a kernel exploit is found, this could be stopped. True. I wonder if they've considered the SEP taking a more active role in filesystem decryption. If the kernel had to be reauthenticated periodically (think oauth's refresh token) maybe SEP could stop data exfiltration after the expiry even without a reboot. Maybe it would be too much of a bottleneck; interesting to think about though.
      • karlgkk 2y ago
        > If the kernel had to be reauthenticated periodically (think oauth's refresh token) If the kernel is compromised, this is pointless I think. You could just "fake it". SEP is already very active in filesystem encryption. The real important thing is evicting all sensitive information from memory. Reboot is the simplest and most effective, and the end result is the same.
        • grahamj 2y ago
          It’s involved in handling the keys but I don’t think disk is processed by the SEP. If it was the SEP could simply stop providing access.
    • markasoftware 2y ago
      Kernel exploits would let someone bypass the lockscreen and access all the data they want immediately, unless I'm missing something. Why would you even need to disable the reboot timer in this case?
      • karlgkk 2y ago
        Hypotdthically, I suppose there's value in disabling the timer if you're, for example, waiting for a SEP exploit that only works if in an AFU state? But, I don't know where the idea of disabling a reboot timer came in? I'm only simply saying that now, you have to have a kernel exploit on hand, or expect to have one within three days - a very tall order indeed.
    • KennyBlanken 2y ago
      > * there is almost certainly a known kernel exploit out in the wild, but the agencies that have it generally reserve using them until they really need to - or they’re patched. There's literally emails from police investigators spreading word about the reboots, which state that the device goes from them being able to extract data while in AFU, to them not being able to get anything out of the device in BFU state. It's a bit pointless, IMHO. All cops will do is make sure they have a search warrant lined up to start AFU extraction right away, or submit warrant requests with urgent/emergency status.
      • karlgkk 2y ago
        I sort addressed this in my original comment but local police likely do not have access to an AFU vuln, and generally get it after it’s been patched. Then, they go on an unlocking spree. This prevents that
    • op00to 2y ago
      If reboot doesn’t happen kernel panics, at least that’s what the article says.
      • aaronmdjones 2y ago
        That's only because the kernel tells the userland to reboot. If the kernel is compromised, they can stop it from telling userland to reboot and stop the kernel panicing.
• pnw 2y ago
  Great writeup! And it's good to see Apple pushing the envelope on device security.
  • Etheryte 2y ago
    Wouldn't really say Apple is pushing the envelope here, as covered in the previous threads about this topic, a number of Android flavors have done this long ago.
    • dewey 2y ago
      The power of defaults is not to be underestimated. Yes, you probably can do it with some Android distribution but the amount of people using that would be microscopic.
    • bananapub 2y ago
      > Wouldn't really say Apple is pushing the envelope here come on dude. they're doing it by default, for > billion people, with their army of lawyers sitting around waiting to defend lawsuits from shitty governments around the world.
    • F7F7F7 2y ago
      The fragmentation inherent in Android ALONE makes it an insecure device for the vast majority of its normie users. You need a damn near decoder ring just to figure out where you stand.
• abhishekjha 2y ago
  How do these things work with devices inside a NAT gateway? Most of our devices are inside a LAN. Even if a server gets started, it won't be visible to the outside world, unless we play with the modem settings. Now, a hacker/state who has penetrated a device can do an upload of data from the local decice to a CNC server. But that seems risky as you need to do it again and again. Or do they just get into your device once and upload everything to CNC?
  • aspenmayer 2y ago
    This particular feature doesn’t rely on network connectivity or lack thereof. Here’s some info about how some spyware works: https://www.kaspersky.com/blog/commercial-spyware/50813/ https://www.kaspersky.com/blog/commercial-spyware/50813/
  • sleepybrett 2y ago
    [flagged]
  • meindnoch 2y ago
    What are you even talking about?
• alwayslikethis 2y ago
  Great writeup, but I wonder why so much emphasis is put on not 'connected to network' part. It seems like a timed inactivity reboot is a simpler idea than any type of inter-device communication schemes. It's not new either; Grapheneos had this for a while now and the default is 18 hours (and you can set it to 10 minutes) which would be a lot more effective as a countermeasure against data exfiltration tools.
  • nneonneo 2y ago
    This is because earlier reports coming out of law enforcement agencies suggested that the network was involved in making even older devices reboot. This blog post is an effort to debunk that claim.
  • lathiat 2y ago
    If you’re targeting these evidence grabbing/device exploiting mobs, generally the phones get locked into a faraday cage to drop the mobile network so that they can’t receive a remote wipe request from iCloud.
• dblitt 2y ago
  Does anyone have insight into why Apple encrypts SEP firmware? Clearly it’s not critical to their security model so maybe just for IP protection?
  • jonpalmisc 2y ago
    They have a long history of encrypting firmware. iBoot just stopped being decrypted recently with the launch of PCC, and prior to iOS 10 the kernel was encrypted too. The operating theory is that higher management at Apple sees this as a layer of protection. However, word on the street is that members of actual security teams at Apple want it to be unencrypted for the sake of research/openness.
  • KennyBlanken 2y ago
    [flagged]
  • saagarjha 2y ago
    Someone high up is an idiot presumably
• thrdbndndn 2y ago
  Two questions: 1. surely unconditionally rebooting locked iPhones every 3 days would cause issues in certain legit use cases? 2. If I read the article correctly, it reboots to re-enter "Before First Unlock" state for security. Why can't it just go into this state without rebooting? Bonus question: my Android phone would ask for my passcode (can't unlock with fingerprint or face) if it thinks it might be left unattended (a few hours without moving etc.), just like after rebooting. Is it different from "Before First Unlock" state? (I understand Android's "Before First Unlock" state could be fundamentally different from iPhone's to begin with).
  • bonyt 2y ago
    > 1. surely unconditionally rebooting locked iPhones every 3 days would cause issues in certain legit use cases? I wonder if this explains why the older iPhone I keep mounted to my monitor to use as a webcam keeps refusing to be a webcam so often lately and needing me to unlock it with my password...
    • athrun 2y ago
      I have the same setup and what works for me is putting the phone into Supervised mode using the Apple Configurator. From there, you can enable single app mode to lock it into the app you're using for the webcam (I use Camo).
  • diggan 2y ago
    > it reboots to re-enter "Before First Unlock" state for security. Why can't it just go into this state without rebooting? I think the reason is to make sure anything from RAM is wiped completely clean. Things like the password should be stored in the Secure Enclave (which encryption keys stored in RAM are derived from) but a reboot would wipe that too + any other sensitive data that might be still in memory. As an extra bonus, I suppose iOS does integrity checks on boot too, so could be a way to trigger that also. Seems to me like a reboot is a "better safe than sorry" approach which isn't that bad approach.
    • gizmo686 2y ago
• alphan0n 2y ago
  If I were looking for low hanging fruit, I suspect it wouldn’t reboot if you were to replicate the user’s home WiFi environment in the faraday cage, sans internet connection of course. Or repeatedly initializing the camera from the lock screen.
  • deleted 2y ago
    [deleted]
  • Syonyk 2y ago
    From the article: > Turns out, the inactivity reboot triggers exactly after 3 days (72 hours). The iPhone would do so despite being connected to Wi-Fi. This confirms my suspicion that this feature had nothing to do with wireless connectivity.
• happytoexplain 2y ago
  >In the After First Unlock (AFU) state, user data is decrypted Note that this is a slight simplification because, I assume, the reality is irrelevant to understanding the topic: There are a few different keys [0] that can be chosen at this level of the encryption pipeline. The default one makes data available after first unlock, as described. But, as the developer, you can choose a key that, for example, makes your app's data unavailable any time the device is locked. Apple uses that one for the user's health data, and maybe other extra-sensitive stuff. [0]: https://support.apple.com/guide/security/data-protection-classes-secb010e978a/web https://support.apple.com/guide/security/data-protection-cla...
  • wepple 2y ago
    How useful do you think this is in practice? Wouldn’t it rely on app-level memory scrubbing and page clearing and such as well, if you wanted to truly make sure it’s unavailable? Do Apple offer APIs to assist there?
    • _1tem 2y ago
      > The class key is protected with a key derived from the user passcode or password and the device UID. Shortly after the user locks a device (10 seconds, if the Require Password setting is Immediately), the decrypted class key is discarded, rendering all data in this class inaccessible until the user enters the passcode again or unlocks (logs in to) the device using Face ID or Touch ID.
      • happytoexplain 2y ago
        This means it can't be read from storage, but AFAIK anything you've read into your app's memory sandbox is still sitting there decrypted until your app releases it or is closed or has its memory wiped by system housekeeping.
    • happytoexplain 2y ago
      It's a good point - I am not an expert, but I think this feature just doesn't protect memory (tying one of the keys to rebooting helps, but the Data Protection feature itself doesn't seem to protect memory). However, that doesn't moot in-storage protection. There are other features protecting memory (and other features protecting data in storage - there are tons of security features). I am not aware of APIs for securely clearing your app's memory (aside from lower level, more manual APIs). This may be one of those cases that relies mostly on sandboxing for protection. I also imagine it's hard to circumvent sandboxing without rebooting. But I'm making a lot of guesses here.
• ghssds 2y ago
  My question is: why three days specifically instead of a user-configurable delay?
  • Etheryte 2y ago
    Apple's whole thing is offering whatever they think is a good default over configuration. I can't even begin to count all the things I wish were configurable on iOS and macOS, but aren't. Makes for a smooth user experience, sure, but is also frustrating if you're a power user.
  • Slartie 2y ago
    Because this way, the delay is parameterized within the Secure Enclave firmware by hard-coding it, which is a thing that only Apple can do. If you were to allow a user to change it, you'd have to safeguard the channel by which the users' desired delay gets pushed into the SE against malicious use, which is inherently hard because that channel must be writable by the user. Therefore it opens up another attack surface by which the inactivity reboot feature itself might be attacked: if the thief could use an AFU exploit to tell the SE to only trigger the reboot after 300 days, the entire feature becomes useless. It's not impossible to secure this - after all, changing the login credentials is such a critical channel as well - but it increases the cost to implement this feature significantly, and I can totally see the discussions around this feature coming to the conclusion that a sane, unchangeable default would be the better trade-off here.
    • axxto 2y ago
      > if the thief could use an AFU exploit to tell the SE to only trigger the reboot after 300 days, the entire feature becomes useless Then why not simply hardcode some fixed modes of operation? Just as an example, a forced choice between 12, 24, 48, or a maximum of 72 hours. You can't cheat your way into convincing the SE to set an unlimited reset timer. I'm sure there must be a better reason.
      • F7F7F7 2y ago
        Any "choice" suffers from the same user exploit you responded to. The attack surface remains. Plus, vulnerability often follows complexity. Whether it's human written validation logic being attacked for 6 months in a lab somewhere in Israel or the overly complex UX exposed to some soccer Mom in Minneapolis. Save money. Save headaches. K.I.S.S.
• pushupentry1219 2y ago
  I haven't read the whole thing, but from skimming the beginning. This is pretty similar how AOSP's BFU vs AFU unlock works.
• archeantus 2y ago
  Great post. They talked about the possibility of iOS 18 wirelessly telling other phones to reboot, but then afaik didn’t address that again. Maybe they did and I missed it?
  • C4K3 2y ago
    They conclude that there's no wireless component to the feature. This feature is not at all related to wireless activity. The law enforcement document's conclusion that the reboot is due to phones wirelessly communicating with each other is implausible. The older iPhones before iOS 18 likely rebooted due to another reason, such as a software bug.
    • zarzavat 2y ago
      If you think about it, if the attacker is sophisticated enough to break the phone within a 72 hour window, then they are definitely sophisticated enough to use a faraday container. So communication between phones wouldn't help very much. Moreover, you'd have to have some inhibitory signal to prevent everybody's phones restarting in a crowded environment, but any such signal could be spoofed.
• sunnybeetroot 2y ago
  This may explain why since iOS18 my device randomly reboots (albeit only takes max 5 seconds). I am a daily user so perhaps the reboot I experience is a bug.
  • sroussey 2y ago
    Yes, lots of complaints on forums about this bug. Saw it happen to my phone today.
  • echoangle 2y ago
    If it takes only 5 seconds, it doesn’t sound like a reboot. Does it show a black screen and the apple logo during this event?
    • sunnybeetroot 2y ago
      No Apple logo, just black screen with loading spinner followed by requiring passcode to unlock
      • future10se 2y ago
        That might be what's informally called a "respring", where the SpringBoard process is restarted. SpringBoard is the process that shows the home screen, and does part of the lifecycle management for regular user apps. (i.e. if you tap an icon, it launches the app, if you swipe it away in the app switcher, it closes the app) It is restarted to make certain changes take effect, like the system language. In the jailbreaking days, it was also restarted to make certain tweaks take effect. Of course, it can also just crash for some reason (which is likely what is happening to you)
        • kaba0 2y ago
          Hi, is there some further info on iOS "internals" like this? I was always interested in how it works, but I found much less information compared to android (which obviously makes sense given one is more or less open-source), even though these probably don't fall in the secret category.
• zombot 2y ago
  [flagged]
  • jadtz 2y ago
    Maybe English is not their first language.
  • saagarjha 2y ago
    It seems like you are unable to understand the complex topic of “security researchers might not be perfect at English”.
• jjallen 2y ago
  If this is such a security benefit why not do it after 24 hours instead? How many people go that long without using their phones? How many people are using their phones for some other purpose for which they want their phones to never reboot? And what are they actually doing with their phones?
  • saagarjha 2y ago
    Because it harms the user experience.
    • jjallen 2y ago
      How though? Users haven't used their phone in a day or more? How would they notice except for having to reenter their passcode which takes two seconds?
      • IshKebab 2y ago
        Read the introduction.
      • Shank 2y ago
        Not being able to glance at any push notifications or get incoming caller ID would be pretty disruptive.
        • layer8 2y ago
          That’s not the case if you also have other Apple devices on the same account.
    • Wowfunhappy 2y ago
      I'm sure this is why but I had the same thought as GP. Under what circumstances would 24 hours be disruptive, but three days would be okay? If you're using the iPhone as some type of IoT appliance, either time limit would be disruptive. But if you e.g. enable Guided Access, the phone will stay unlocked and so shouldn't reboot. If you're using the iPhone as a phone, who the heck doesn't touch their phone in 24 hours? Maybe if you're on some phone-free camping trip and you just need the iPhone with you as an emergency backup—but in that case, I don't think Inactivity Reboot would be particularly disruptive. Maybe Apple will lower the window over time?
• jesprenj 2y ago
  > In law enforcement scenarios, a lot of the forensically relevant data is available in the AFU state. Law enforcement takes advantage of this and often keeps seized iPhones powered on, but isolated from the Internet, until they can extract data. In Slovenia, devices have to be turned off the moment they are seized by their owner, prior to putting them into airplane mode.
  • Razengan 2y ago
    Also when thieves or muggers rob someone, the first thing they do is turn on Airplane Mode or force power-off. WHY the hell don't those actions require a passcode or bio authentication??
    • saagarjha 2y ago
      They could just put it in a foil-lined pocket instead.
      • Razengan 2y ago
        "Why bother deterring the more-common low-effort risks if there are higher effort ways to thwart the deterrence?" How often do muggers carry foil pockets even in first world countries? Certainly not in places where there's a mugging almost every week. Some way to track the device on its way to wherever they strip them off for parts would be helpful than not being to track it at all.
        • saagarjha 2y ago
          They don’t because they don’t have to. Make it necessary and they’ll switch within the week.
          • Razengan 2y ago
            That’s still only the preplanned muggings. Not the opportunists who spot an unattended phone somewhere by chance.
• Shank 2y ago
  To me the biggest takeaway is that Apple is sufficiently paranoid to add this feature. Some people (like John Gruber) advocate for activating bio lockout at the border by squeezing the volume and power buttons. I would say if you’re the type of person who would do this, you should go one step further and power off. Similarly, if you’re in a situation where you cannot guarantee your phone’s security because it’s leaving your possession, and you’re sufficiently worried, again, power off fully.
  • 486sx33 2y ago
    If I had to guess, there must have been an exploit in the wild that took advantage of this. It sounds like it eliminates the oldest tools in one swoop. Which is pretty sweet
    • gruez 2y ago
      Even without an exploit in the wild, having such a feature is critical for security. Otherwise any device that's seized by police can be kept powered on indefinitely, until firms like Cellebrite can find an exploit.
      • privacy_second 2y ago
        [dead]
  • vsl 2y ago
    Doesn't the volume+power gesture transition into BFU, i.e. be equivalent to power-cycling?
    • jonpalmisc 2y ago
      No. This is a myth, and while it does force you to enter your password instead of using biometrics on the next unlock, it is not the same as returning to BFU.
  • phinnaeus 2y ago
• lofaszvanitt 2y ago
  More security theatre.
  • bayindirh 2y ago
    Elaborate.
  • deleted 2y ago
    [deleted]
• mjlee 2y ago
  I had to look up what SRD meant. It's a Security Research Device - "a specially fused iPhone that allows you to perform iOS security research without having to bypass its security features." https://security.apple.com/research-device/ https://security.apple.com/research-device/
• 486sx33 2y ago
  Nice work, and appreciate the time you spent! “I also downloaded an older kernel where Apple accidentally included symbols and manually diffed these versions with a focus on the code related to inactivity reboot. The kernel has three strings relating to the feature:” sounds like a little luck there for sure !