Cops hypothesize iOS 18 back-channels to reboot phones

[Cmaier]

Cops think iPhones are secretly communicating with each other to reboot [U] - 9to5Mac

Update: A security researcher on Mastodon has cracked the case on this, proving that it has nothing to do with...

9to5mac.com

This is a weird story. Cops locking phones in Faraday boxes, etc., claiming that the phones reboot themselves. Then they say that the rebooting may be caused by some magical communication with the cops’ own phones, which somehow tell the locked-up phones to reboot.

Once they reboot, cops can’t easily extract data from the phone.

Assuming it’s true that they are rebooting, and further assuming it isn’t some sort of bug, seems much more likely that Apple instituted some sort of network watchdog timer - after 24 hours of zero network connectivity, they reboot. That would be cool. I don’t believe one iPhone can communicate with another through a Faraday cage.

 

[dada_dave]

Cops think iPhones are secretly communicating with each other to reboot [U] - 9to5Mac

Update: A security researcher on Mastodon has cracked the case on this, proving that it has nothing to do with...

9to5mac.com

This is a weird story. Cops locking phones in Faraday boxes, etc., claiming that the phones reboot themselves. Then they say that the rebooting may be caused by some magical communication with the cops’ own phones, which somehow tell the locked-up phones to reboot.

Once they reboot, cops can’t easily extract data from the phone.

Assuming it’s true that they are rebooting, and further assuming it isn’t some sort of bug, seems much more likely that Apple instituted some sort of network watchdog timer - after 24 hours of zero network connectivity, they reboot. That would be cool. I don’t believe one iPhone can communicate with another through a Faraday cage.

Yeah agreed if not a bug it seems more likely to be a timer.

 

[Altaic]

Definitely a weird one, but now solved

jiska 🦄:fairydust: (@jiska@chaos.social)

Attached: 3 images Apple added a feature called "inactivity reboot" in iOS 18.1. This is implemented in keybagd and the AppleSEPKeyStore kernel extension. It seems to have nothing to do with phone/wireless network state. Keystore is used when unlocking the device. So if you don't unlock your...

chaos.social

 

[Cmaier]

Definitely a weird one, but now solved

jiska 🦄:fairydust: (@jiska@chaos.social)

Attached: 3 images Apple added a feature called "inactivity reboot" in iOS 18.1. This is implemented in keybagd and the AppleSEPKeyStore kernel extension. It seems to have nothing to do with phone/wireless network state. Keystore is used when unlocking the device. So if you don't unlock your...

chaos.social

was just going to post this!

Very nice feature.

 

[Nycturne]

Good catch. Seems like this is probably done for battery consumption more than security, but I'll take the security implications as a happy side effect.

 

[Cmaier]

wait …. this explains something. We have my wife’s old iPhone 14 pro sitting in nightstand mode in the kitchen as a little clock/weather display. Every few days I see it out of nightstand mode, and it tells me that it needs the code to be entered again because of a restart. This has been happening the last couple of weeks. I guess this is that thing.

 

[Yoused]

My iPad asks me for my password about once or twice a week. It just did, and my current uptime stat is 34 days. It gets actively used every day – there is no question of significant idle time. The password request is not tied to rebooting.

 

[Nycturne]

My iPad asks me for my password about once or twice a week. It just did, and my current uptime stat is 34 days. It gets actively used every day – there is no question of significant idle time. The password request is not tied to rebooting.

Yes, the Secure Enclave will expire various credentials it stores to require the passcode every so often (48 hrs I think?).

This appears to be related to a feature added in iOS 18 (and it didn't even work correctly until 18.1 if I read this correctly). The feature will reboot the system when it's inactive.

 

[Andropov]

Good catch. Seems like this is probably done for battery consumption more than security, but I'll take the security implications as a happy side effect.

Hmm how would this save battery?

 

[Nycturne]

Hmm how would this save battery?

Back when I worked on mobile OSes, one of the issues is just ensuring that the system remains well-behaved over longer periods of time. Long-lived processes don't always behave well and can get into one bad state or another that your automated testing can't catch. We had approaches like stress tests and the like meant to try to tease out these bad states in a way we could then debug them, but it's not bullet proof. We tended to measure our success using a metric very similar to MTBF. But the failure doesn't necessarily need to be a crash, it can just be unintended behavior, such as failing to honor network back-offs properly, which would result in more radio use than is desirable for example.

One approach to this is to accept that long-lived processes will tend to need a kick every now and then, and just let the system do so.

I'm not claiming this is exactly why Apple did this, and it is merely speculation.

 

[Andropov]

Back when I worked on mobile OSes, one of the issues is just ensuring that the system remains well-behaved over longer periods of time. Long-lived processes don't always behave well and can get into one bad state or another that your automated testing can't catch. We had approaches like stress tests and the like meant to try to tease out these bad states in a way we could then debug them, but it's not bullet proof. We tended to measure our success using a metric very similar to MTBF. But the failure doesn't necessarily need to be a crash, it can just be unintended behavior, such as failing to honor network back-offs properly, which would result in more radio use than is desirable for example.

Interesting. What kind of mechanism causes a failure because a process has been running for too long? Like, why does time matter here? Only thing I can imagine is a memory leak that increases with every iteration of the runloop (or something similar), but I sense I'm missing something more interesting here.

 

[Nycturne]

Interesting. What kind of mechanism causes a failure because a process has been running for too long? Like, why does time matter here? Only thing I can imagine is a memory leak that increases with every iteration of the runloop (or something similar), but I sense I'm missing something more interesting here.

That's part of the problem. If you knew what it was ahead of time, you'd write tests against it. But as system complexity increases, the more things you miss through lack of coverage also increases. Add in third party apps that run in the background, and it becomes infeasible to catch everything ahead of time. There is some value in just having some mechanism that gets the user out of a bad state automatically rather than having perfect code.

It's not always about time, but sometimes about rarity of circumstances that can lock a process into a bad state, meaning it's more likely to reach this bad state the longer the process runs. But you can have internal global state in a process that can overflow, or get outside an expected range, changing behavior. Or you have something based on time passed since some event, which leads to a different kind of overflow.

All that said, as more reporting has come out, it looks like the inactivity timer is on the order of ~4 days here, so with that in mind, security is the more likely reason.

 

[mr_roboto]

There's also heap fragmentation - even a process with no leaks can, after enough uptime, fragment its own virtual address space to the point that memory allocation becomes noticeably slower and more memory is being wasted due to the fragmentation.

 

[Yoused]

There's also heap fragmentation

Really? An app has around 16 TB of heap space, maybe twice that. You think Apple does not have an allocator that can manage that efficiently?

 

[Nycturne]

Really? An app has around 16 TB of heap space, maybe twice that. You think Apple does not have an allocator that can manage that efficiently?

It’s more that depending on the allocation pattern of the app, you can get ugly cases where individual pages get low utilization due to the fragmentation. Ex. 4KB used on a 16KB page meaning that 12KB of the page is basically wasted despite being kept resident while the app accesses the 4KB that is in use.

It’s been a while since I’ve been on a team that did this sort of analysis though, so I don’t have any numbers to share.

 

[quarkysg]

Really? An app has around 16 TB of heap space, maybe twice that. You think Apple does not have an allocator that can manage that efficiently?

It's the physical memory fragmentation that will cause issue. If you suddenly need a big block of contiguous physical memory (e.g. for DMA) but due to fragmentation, you will not be able to get it, even tho. you might have enough total memory to satisfy the request.

 

[theorist9]

I also reboot after being put in a Faraday cage. At least that's what they tell me, since all my memory is volatile.

 

[mr_roboto]

It's the physical memory fragmentation that will cause issue. If you suddenly need a big block of contiguous physical memory (e.g. for DMA) but due to fragmentation, you will not be able to get it, even tho. you might have enough total memory to satisfy the request.

Both can cause problems, but in different places in the system. This one you described is an issue in the operating system's kernel, whereas virtual address space fragmentation is a problem in long-running userspace processes.

 

[Citysnaps]

Could be this:

iPhones now auto-restart to block access to encrypted data after long idle times

Apple has added a new security feature with the iOS 18.1 update released last month to ensure that iPhones automatically reboot after long idle periods to re-encrypt data and make it harder to extract.

www.bleepingcomputer.com

 

[Andropov]

There's an excellent article reverse engineering the inactivity reboot thing here.

The SEP keeps track of the 3-day timer, so it should be pretty hard to stop the phone from entering the BFU state. Pretty cool.