I’ll be honest, this article is not a great read. Only one paragraph is dedicated to the actual title.
Here’s what the Co-Founder of iVerify mentioned about preventing zero-click attacks:
Cole advises people to treat their phone like a computer. This means that, just as one would apply “a body of best practices that exist to protect traditional endpoints like laptops, from exploitation and compromise – those same standards and practices should just be applied to phones.” This includes rebooting your phone daily because “a lot of these exploits exist in memory only. They’re not files, and if you reboot your phone, in theory, you should be able to wipe the malware as well,” he said.
Can anyone confirm if this should be a best practice activity for smartphones?
Auto-reboot will only get triggered, if you haven’t unlocked your smartphone during a specified interval. It’s a feature to protect against exploitation with physical access, not for malware anti-persistence.
I mentioned that I reboot daily on the GrapheneOS forum. If a daily reboot was ineffective the mods or devs would have said so. I’ve seen three page rebuttles (usually on Reddit) from mods because someone got a tiny detail wrong.
Unless you’re saying auto-reboot doesn’t play any part in anti-persistence (it seems a clear implication to me that Verified Boot only works when paired with reboots), in which case I’d like to know.
it’s more like a very good practice to do with your phone
I have mine to reboot every 8 hours automatically (so after sleeping), this helps so that updates can apply to it among the other potential threats.
They are just saying the feature wasn’t designed for anti-persistence, since if it was there would be an option to reboot automatically regardless of device activity. As it stands now you could go for weeks without rebooting even with the feature turned on.
That being said, you still can use the auto-reboot function to do this pretty effectively by just setting the timer to a smaller number of hours than you usually sleep, then it’ll probably automatically reboot every night
Edit: I would note that malware specifically tailored for GrapheneOS could interfere with the automatic reboots, so watch out for that. This is another reason the feature wasn’t designed with this specific problem in mind.
On iOS you can use a specific hardware key combination to force a reboot in a way that couldn’t be intercepted by malware. I haven’t seen any documentation from GrapheneOS on whether this is the case with the Pixel’s power key but I’d assume something similar is possible on Android even if I don’t know how it works specifically(?)
I still do these force resets occasionally because even as far back as 10 years ago there were reports of malware faking the power menu and reboot sequence on Android, so having basically a Secure Attention Sequence to reboot seems a bit more trustworthy.
I don’t know how realistic this threat actually is though and if what I’m doing even matters
You can accomplish the same on Android by holding the power button for ~30 seconds.
In the same spirit, you should factory reset your phone from the Fastboot menu rather than the OS if you suspect it has been infected by malware, since that could fake a factory reset initiated from the OS.
Yeah, I assumed this would work fine, but I have just not seen any security detailed info on how this is actually implemented in firmware/hardware to know for sure. It might still be implemented at software level which would be concerning.
The traditional uptime mindset is no longer good. This is also from a servers point of view.
These days you want something with high availability - treat computers (and phones) as cattle and not pets: 3 cheaper servers with the ability to be quickly restored to a working state is better than a high endurance expensive single server.
Now, I dont know how this would translate to an everday carry phone: Maybe stick to the Graphene OS on those “cheaper” A variant Pixels? Use your phone as an extension of your homelab cloud?
My point is something could already be wrong catastrophically with your phone and you don’t know that you already needed a replacement for potentially 56 days because you don’t do daily reboots.
Felt pretty certain about it when I read the post initially but nobody has mentioned this yet, so maybe I’m wrong/missing something?
To my knowledge rebooting removes nonpersistent malware that has already infected the device. It protects data that is currently not accessible to the malware but could be in the future [1][2]. All other data was already accessible to the malware and is thus compromised. To protect data against this threat, if initial exploitation cannot be prevented, I’d guess you must minimise data accessible to the malware. Rebooting is part of a defense, but I wouldn’t call rebooting the “best defense against zero click attacks”?
Such as data that is currently encrypted, inaccessible, or not yet created or received. ↩︎
And even the protected data will not remain protected after reboot, as the device can be exploited again using the same stealthy 0-click exploit as before. ↩︎
Spot on. I honestly think the framing of rebooting as the “best defense” is another example of article clickbait.
There has to be some separation between “best practices” and “best defense” or else some poor reader might obsessively reboot their phone instead of preventing zero-click attacks in the first place. Sure, doing so can help if a compromise does take place (besides the usual anti-forensics benefits) but for a low-information reader, they would need a more nuanced explanation.
Keeping the smartphone switched-off is actually the “ultimate best defense”
Yes, rebooting frequently should be part of “best practices” in light of proliferation of exploits that exist no where except in main memory.
If Android (OS) is compromised, verified boot will let you into recovery with a stern warning (post any kind of a restart / power cycle) from where you can factory reset, too? Is fastboot necessary?
iOS seems to have a software implementation (going by the fact that the user is shown “apple logo” before shutdown)? For AOSP though, I couldn’t find “shutdown on very very long power button key press” code anywhere (not in PowerManagerService, ShutdownThread, PhoneWindowManager, init, bionic, or vndk). Very likely that a 30s power button hold triggers a power cycle (via hardware/firmware and not the reboot Linux syscall)? /cc @SkewedZeppelin
As of Android 15, the 30s power cycle behaviour isn’t mentioned in the CDD (compatibility definition document), so unlikely that all OEMs implement this alike or implement it at all.
