I recently wrote about the new iOS feature that forces an iPhone to reboot after it’s been inactive for a longish period of time.
Here are the technical details, discovered through reverse engineering. The feature triggers after seventy-two hours of inactivity, even it is remains connected to Wi-Fi.
John White • December 2, 2024 6:03 PM
I’m not convinced that this has been fully answered. It’s great that this feature exists, and it would be even better if Apple made it possible to adjust the time down so that it occurs more rapidly, but is it conclusively proven that button activity, interaction with the touch screen etc does not reset the timer as actually unlocking the phone would? Because the risk is that pigs and other bad actors could simply automate button clicks- or manually ‘touch’ all the phones- to extend the unlock time.
ResearcherZero • December 2, 2024 11:53 PM
@John White
The countdown timer is likely started each time the device is locked. Therefore the device would have to be in an unlocked to state to stop the inactivity timer from counting down.
“The Secure Enclave Processor (SEP) keeps track on when your phone was last unlocked.”
‘https://naehrdine.blogspot.com/2024/11/reverse-engineering-ios-18-inactivity.html
ResearcherZero • December 3, 2024 12:39 AM
Not that it is guaranteed to keep attackers from targeting your phone with some kind of spyware, or discovering your authentication details via other surveillance methods.
If a device contains sensitive information then remotely wiping it as soon as possible may prevent data from being accessed, as long as the device has not been shielded/turned off.
There are alternative solutions with a 10 minute inactivity timer and a scrambled 128 character password, with charging only allowed from a locked state to reduce attacks. Yet all the same caveats apply with such secure mobile operating system implementations. If an attacker has physical access to a device, they can hold onto it until such time an exploit is released that the device has not yet been patched to the prevent that exploit method.
Apple does not implement the remote wipe/anti-theft features in the device BIOS, yet bootkits that exploited recovery mode were developed and zero-click spyware with support for later updates or new modules that could support yet undiscovered exploits exist. So even without physical access, a well resourced adversary can defeat any security measures.
However, if you practice good OPSEC, then none of that will matter.
ResearcherZero • December 3, 2024 12:53 AM
Keep in mind your family, friends and colleagues likely will not practice good OPSEC.
ResearcherZero • December 3, 2024 6:23 AM
One should also assume those administering the law understand little about IT.
‘https://www.postofficescandal.uk/post/proposed-amendment-to-legal-assumption-about-the-reliability-of-computers/
MDK • December 3, 2024 3:15 PM
@All
Feature should have been implemented a long time ago.
@Bruce
I’m sure you are aware but a confirmed nation state cyber campaign running against US Telco etc. It’s not good from the sounds of it. Dangerous times indeed.
MDK
anon • December 3, 2024 6:00 PM
re: JW
Wouldn’t that simply increase the delay before the phone could be unlocked? Even if you pressed ‘1’ ‘backspace’ repeatedly?
ResearcherZero • December 4, 2024 12:49 AM
@anon
The way countdown timers are generally implemented ensures that simply pressing keys or touching the screen will cause no effect to the countdown once the device is locked. If anyone attempts to interfere with the countdown timer through an exploit, that should cause kernel panic which will then cause the phone to reboot, hopefully neutering the attack.
‘https://en.wikipedia.org/wiki/Init
Clive Robinson • December 4, 2024 4:02 AM
@ ResearcherZero, ALL,
With regards your comment,
“Keep in mind your family, friends and colleagues likely will not practice good OPSEC.”
In my experience in life a couple of aspects to this occur,
1, Even when a persons very life depends on OpSec / Situational Awareness, they stop doing it effectively or at all very quickly.
2, No matter how you try to make others aware of the importance of OpSec / Situational Awareness, they will discount you, tell you you are paranoid, and tell others you are weird / mad.
Yet when their number comes up for “unpleasantness” from those with “ill interest” etc against them, they blame you for not pushing / explaining / etc to them hard / well enough…
Yes I understand OpSec / Situational Awareness has a cognitive load, as well as a required mind set, but why do they not want to take responsibility for their own actions?
I know, you don’t have to answer that, after all the expression “low hanging fruit” came about for a reason 🙁
The problem they appear incapable of grasping is that,
“Their failings become other peoples sufferings.”
It’s one of the reasons I’ve talked about “Fully Deniable Security” where even “second party betrayal” to a hostile third party can be mitigated.
Thus if those who do not do OpSec / Situational Awareness sufficiently, or betray you, thus “Burn themselves” (which in my experience they will in all likelihood do…). You hopefully will not get “hot under the collar” no matter “who feels your collar” because of the second party failings.
I know it’s a rotten thing to say but “some people just won’t learn” even though they can. And as with riding a bike, driving a car, using a computer or playing a musical instrument, OpSec / Situational Awareness is a “skill to be learned” and the cognitive load involved goes down as your learned skills improve.
John White • December 4, 2024 5:10 AM
@anon: The issue is that if there’s a way to extend the time the phone stays in a post-boot unlock state, that extends the time there is to exploit the phone with an exploit that wouldn’t work if it had restarted.
@ResearcherZero:
The countdown timer is likely started each time the device is locked.
Probably, but I haven’t seen that confirmed experimentally.
Not all use cases need perfect security. For example, in the past year, a number of journalists reporting on Palestine have been stopped by UK police or border security and ordered to hand over electronic devices so their contacts in Gaza can be targeted. If those devices can be immediately exploited, then the journalists in Gaza that they’re in contact with may be targeted for murder in the next couple of weeks. If a post-boot unlock-> pre-boot unlock reboot can secure a device against exploitation until a exploit is developed that works pre-boot unlock, and that lasts until the current attack on the people of Palestine is reduced in volume somewhat, those people may survive.
Now, myself? I’m certainly not going to be crossing a border to an unfree country like the UK or US with devices with data that could interest their masters on it. But that doesn’t mean a feature like this can’t be very useful as long as it’s implemented properly. Most of the smartphone generation wouldn’t even see any inconvenience from having the three day timeout turned down to a day or less.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Paul Sagi • December 2, 2024 8:21 AM
Interesting that the Apple code is so transparent that it’s easy to reverse engineer.
I found that the Windows code to trigger automatic updates was similarly transparent. I found a few lines of XML code that server as a timer to trigger updating. Microsoft has been known to use multiple means for updates, so the above might not be the last word. What people hate about Windows updates is they can arrive at the most inconvenient time and cause business disruption. Some people use Sordum’s Windows Update Blocker (WUB) to combat multiple update triggers.