Possible Vulnerability in Apple's Automatic Reboot

Possible Vulnerability in Apple’s Automatic Reboot

404Media is reporting (alternate link) that a cyber-weapons arms manufacturer is exploiting a vulnerability in iOS to bypass its automatic reboot security feature. This is the feature that automatically puts an iPhone into a more secure state if it hasn’t been used for 72 hours.

The new technology to get around inactivity reboot was developed by Magnet Forensics, the company behind GrayKey, a popular tool sold to law enforcement agencies that allows them to unlock and access data stored in iPhones and Android smartphones. Magnet has developed a new device called GrayKey Preserve and a feature for its regular GrayKey devices called Evidence Preservation Mode, according to the video.

“This is an absolute game changer for iOS forensics and a function that I wish we had years ago,” a Magnet employee says in the leaked video, specifically mentioning that the solution is targeted at the iPhone’s inactivity reboot feature and the data it makes unavailable. GrayKey Preserve and Evidence Preservation Mode are also designed to combat another iPhone feature that automatically deletes certain data - such as cached locations, and recently deleted photos and iMessages - after a certain number of days. “We’re gonna be able to preserve that data for an infinite amount of time.”

Presumably, now that Apple engineers know that this flaw exists they can find and fix it. AI turns out to be really good at this sort of thing.

Another news article.

Tags: iPhone, law enforcement, police, vulnerabilities

Posted on October 6, 2026 at 7:06 AM • 14 Comments

Comments

Celos • October 6, 2026 9:51 AM

Just the usual reminder: Do NOT trust your phone. The attackers and their supporters cannot stand you keeping any secrets and hence they will do whatever they can to break in.

Bob • October 6, 2026 9:57 AM

Bet it’s a Faraday cage with a cell site simulator whose clock doesn’t progress.

KC • October 6, 2026 10:56 AM

Interesting. Here are some supposed natural expiration timelines of certain iOS data.

Eg, cached locations 7 days, recently deleted iMessages 30 days, etc.

lurker • October 6, 2026 1:36 PM

“… another iPhone feature that automatically deletes certain data - … and recently deleted photos and iMessages - after a certain number of days.”

Whatever happened to rm?

Yeah, I know, it’s in the “Trash” can.

Clive Robinson • October 6, 2026 4:08 PM

@ ALL,

On the assumption the clock is involved, one way to do this is to “stop the clock” or keep resetting the clock time back just a couple of minutes or longer.

Another way is a bit more subtle, any CRUD access to memory generally means at least a two step process of the application writing to a buffer and the OS then writing the buffer to the memory. The reason for this is to keep the memory in a sane state.

An OS generally uses some form of signals mediated “Inter Process Communication”. Thus has flags tucked away in the OS to control the signals to App Buffer Memory.

If you block those signals by blocking the flags or flag mechanism then the memory does not get updated by a “Create, Update, or Delete” action.

The way to get around the issue is quite old and was used in Mil Kit back in the 1980s and I assume later.

You actually do this by encrypting the data contents of every memory object with it’s own key. If you delete or change the key at any time it mostly does not do any harm even to open Apps as long as the most basic of meta-data is not damaged…

It must be a decade and a half or more since we discussed the issues with memory encryption on this blog, as it’s something that has in effect been abstracted away in more modern OS’s and Systems.

The last time I remember was with “a snake eating it’s tail”(Ouroboros). The idea being that you actually re-encrypted blocks of memory by having the keys cycle around. With part of the key held in memory and the other part held via a CPU register, as a way to get around the LNO attack on DRAM and SRAM that had had power removed.

cybershow • October 6, 2026 8:44 PM

@Bob

That half makes sense, but why would the device listen to network time
instead of its own internal clock? Network time suddenly standing still
would count as suspicious and trigger a wipe, no? The only hope
of freezing the internal time is to drop it into liquid helium.

lurker • October 6, 2026 10:41 PM

@cybershow
“why would the device listen to network time
instead of its own internal clock?”

Sometimes so-called developers do the darndest things. I’ve seen a FM radio receiver in a de-Googled “privacy” phone that goes out looking for ntp time. Local wall clock ain’t good enough …

freedom • October 6, 2026 11:13 PM

The assumption here seems to be that crapple “products” (i.e. malware) can be “trusted”, which is of course a ridiculous assumption.

I wonder why there is no actual discussion about actually solving the problems caused by the NSA-GCHQ-corporate mafia.

Fake French Spy • October 6, 2026 11:25 PM

@lurker • October 6, 2026 10:41 PM

what you and some other geniuses round here don’t mention is that the CMOS battery gets weaker over time making the system clock more and more inaccurate so to help out with that our computer “forefathers” came up with the concept behind port 123 to SYNC the local time with one of the time servers automagically unless you own an older system and have the luxury of disabling that service or blocking port 123 in yr FW.

lurker • October 7, 2026 1:40 AM

@Fake French Spy

Yebbut, the operating system is supposed/allowed to do that, and then provide a sufficiently reliable system clock so that random apps and service don’t create security risks by wandering over the net unattended.

Hacketry • October 7, 2026 2:40 AM

That kind of thing is kind of old, any software can be hacked, directly or what it does in the computer, meaning hack the computer. Example: software with a ‘FREE 30-day trial’ or the computer it resides in (or both) can be hacked to extend that ’30-day trial’ to many years. That is not just conjecture, it has been done.

Clive Robinson • October 7, 2026 10:27 AM

@ Hacketry, ALL,

With regards,

“… any software can be hacked, directly or what it does in the computer…”

Actually depending on what you mean by “software” and “computer” that might not be true.

Those old enough to have worked in FMCE as design engineers back into the mid 1990’s and earlier will have used “Mask Programmable Microcontrollers”. Those working on lower production runs would have used the equivalent of a diode “fuse programmable array.

Untill much the same time the BIOS and similar for Personal Computers were written into either ROM or EPROM. But on boot up the code in them would copy down into RAM which then made them vulnerable in the way you are suggesting.

Even today comparatively hard as they are to get now, there are still actual ROM or PROM parts you can get in Mil Spec byte-wide parts that are not Flash or “Electrically Erasable PROM”(EEPROM). I use them in CubSat and other HiRel and HiSec designs where code should not be alterable.

The other issue is “control Flags” for signals and buffers as I mentioned above, they are also usually RAM based and thus vulnerable. Moving them to X

Thus the trick is to design systems where executable code can not run in RAM and where control instructions (think branches in ASM) can not be available from RAM.

This way malware has nowhere to go in the system, and software can not be changed by it.

Basically you have to think of the memory in a secure system as ranging from “fully mutable” to being “immutable”. You want executable code in “immutable memory”. Likewise control flags and similar to being where possible in CPU registers only.

One more modern trick you see in some systems where security is considered important but code needs to be changed is to have an encryption key chain system where the executable code is encrypted in a way that if it gets changed it fails to decrypt and execute.

freedom • October 7, 2026 11:59 AM

CMOS battery gets weaker over time making the system clock more and more inaccurate

That is patently false. The clock is controlled by a quartz crystal.

Clive Robinson • October 7, 2026 10:52 PM

@ cybershow, Bob, ALL,

With regards,

“The only hope
of freezing the internal time is to drop it into liquid helium.”

Actually not quite true…

Apple has used and I assume still uses “MEMS” devices that are supposedly hermetically sealed and physically smaller than even the smallest of 32Khz quartz “clock crystals” and other sensors such as gyros that use “mechanical strain or resonance” for basic operation.

Only “hermetically sealed” even “vacuum sealed” does not mean sealed against certain very small atoms such as hydrogen[1] and helium used as cryo-coolants and party balloons that people have been known to use to make their voice sound like a cartoon chipmunk / Donald Duck…

There is a reported case from 2018 of a US hospital dumping it’s MRI machine cryo-coolant inadvertantly into the hospital internal air rather than to directly outside the building. Then people with Apple phones and other devices experiencing very odd behaviour,

https://www.ifixit.com/News/11986/iphones-are-allergic-to-helium

What is not reported is how staff and patients felt. Both Helium and Hydrogen displace oxygen in your respiratory system and whilst helium gas won’t poison you, they both will effectively drown you (Inert gas asphyxiation)…

But another thing to note. Apple OS’s used in these devices is not a traditional style multi-tasking OS. I’m not going to go into details you can look it up.

But it did enable Apple to pull a dirty trick back in 2017 on it’s users called “BatteryGate” at the time, for which it finally got fined by the French in 2020.

https://www.ifixit.com/News/35519/apple-has-been-fined-e25-million-for-deliberately-slowing-down-iphones-in-2017

[1] Hydrogen is a pesky gas and even worse atom. It only has a single electron that can be fairly easily stripped away when it “ionises” chemically or electrically to “atomic hydrogen” leaving just the nucleus which is a proton. When it gets the electron back it reverts to “molecular hydrogen” and it’s very much larger size… Thus can create fairly serious mechanical stress and structural breakdown of materials at the molecular level in steel etc. The process is known as “hydrogen embrittlement”,

https://en.wikipedia.org/wiki/Hydrogen_embrittlement

And it’s the curse of both industrial chemical and nuclear engineers who have to design plant installations,

https://www.intechopen.com/chapters/1185588

Hydrogen gas in the normal environment atmosphere is also something electrical/electronics engineers have to keep in mind when designing “Intrinsically Safe”(IS or ‘Ex i’) or “flame proof”(Ex d) equipment as a mixture of hydrogen and other gases such as oxygen can make quite a pop even with very small electrical charges, as I know from personal experience with “IS certification testing” “blowing the bell jar”.

Schneier on Security

Possible Vulnerability in Apple’s Automatic Reboot

Comments

Leave a comment Cancel reply