You do it because it makes an attacker’s life harder because now I have to find two bugs instead of one.
The entire boot chain of the phone up to the apps you run are verified successively by the component that loads it. A digital signature helps ensure that only trustworthy code ever runs. A bug must be found to bypass these checks to load malware code. For example, a bug in the image code in a web browser might cause loading of code that isn’t checked. This way the malware gets smuggled onto the phone.
This means that if you get hacked via one bug and malware is loaded, the attacker has to work harder to solve the problem of how do I convince the phone to load it again at boot because the code it’s made of isn’t going to be approved code. When you reboot, you are effectively forcing a validation that all the code you have running is authentic, which would exclude the malware. Trick me once sure, can you survive a full pat down? Probably not. It’ll get caught.
Unless I have a second bug to fool the normal code loading systems too, the malware can’t run. You have to go back and trigger the first bug again somehow, which places more strain on the attacker.
Personally, I restart mine maybe once a week. No need to go crazy with it, but it helps make life harder for bad actors and might make your phone run better.
I can’t blatantly associate this account with other identities but I’ll say that I’ll be at DEFCON32 sniffing the air and shaking hands on the Wild Wild West of the open LAN.
I insert a lie or two about real life details every now and then to mitigate profiling. But the gist of what I write is always me.
Exactly, as you already explained in detail this is primarily for security.
GrapheneOS has a feature to set a time after which the phone reboots in case there was no unlock. So in case a bad actor gets your phone they only have that time with a running system after the first unlock. However, if you use it normally, and unlock it in regular intervals it does not auto-reboot. This is especially neat if your threat level is not “investigative journalist” or “political activist on the run”, because then you can set the time to a longer interval and the phone does not reboot every night when you are asleep which also leads to the SIM card being locked and nobody being able to call you…
I remember this feature, and I wish it was a standard Android feature. It sounds like it would be trivial to implement and could be completely optional.
But that only works for untrusted code escaping a sandbox, right? It does not help with malicious code embedded into legitimate seeming apps. The later vector seems easier, especially on Android, no?
I don’t really consider a malicious app to be an exploit. In this case, the software is doing exactly what it was designed to do – malicious activity. It’s not being manipulated to perform unintended operations through the exploitation of a software bug. Code signing and secure boot are not effective in the face of intentionally shipping malicious code to end users. It’s designed to frustrate actual hackers.
For malicious-by-design apps, we rely on a central app store that hopefully reduces the number of bad apps in circulation. If you publish malware, eventually you get caught and we know who you are. Sandboxing with a permissions system helps prevent apps from performing actions contrary to the user’s interests. E.g. why is my flashlight app asking for my contacts when I pressed ‘change color?’
If you directly exploit your way in, it’s harder to know who did this and why because you didn’t go through any central vetting or accountability system, and you’re not so easily bound by the permissions system. It depends on what your bad guy’s goals are, what they want, whom they’re targeting. Force your way in the back entrance, crawl through an open window (like a weak security setting), or lie your way in the front door (trojan)? It depends.
None of it is perfect, but I’m sure OS design experts would love to hear about better solutions if any exist.
wouldn’t a malicious app still be an exploit though? I’d say that if I download an app for playing a game, but instead it was designed to also upload my private photos to the attacker’s server, i’d say that’s still exploiting. It’s just exploiting my expectations of what the app should do, rather than leveraging a system weakness (which it probably does, anyway)
You’d have to grant the app permission to access your photos. At this point, I would say the problem is more the person in the driver’s seat. You can’t really protect the user from themselves. If you had a legitimate reason to grant access to your photos, then we definitely have a problem.
You can think of this as a kind of exploit if you prefer. However, this becomes a permissions and ecosystem and reputation issue and not really a technical software one. Because you’re looking at a totally different set of tools, I think it’s useful to restrict exploit to refer only to bugs.
You could take that argument one step further and ask what if my new phone comes with preinstalled malware? The system collapses if you can’t have some level of trust the software you’re running.
Pixels with grapheneos can reboot automatically after a number of hours with the screen off (unattended because you are sleeping). But this would also interfere with Whatsapp backup, which happens overnight.
Idk man I just do it when my phone won’t ring when I get a call from my dad or doctor or something, so I have to go delete the voicemail and call them back. So like, every couple of weeks. I think it’s a Samsung thing, happened on my last phone too.
Nothing wrong with that. I don’t think it’s a mistake to not reboot your phone until you need to. It’s your phone. It’s not like rebooting your phone will save lives or the planet.
My wife doesn’t even use a lock screen password. I’m interested in the nuances of such things.
Reboot Daily: According to research from Amnesty International and Citizen Lab, Pegasus often relies on zero-click 0-days with no persistence. Regular daily reboots can help clean the device, making it necessary for attackers to repeatedly reinfect, thereby increasing the chances of detection over time.
For a case with persistence, Lookout notes another bug was required and details the extra work.
You do it because it makes an attacker’s life harder because now I have to find two bugs instead of one.
The entire boot chain of the phone up to the apps you run are verified successively by the component that loads it. A digital signature helps ensure that only trustworthy code ever runs. A bug must be found to bypass these checks to load malware code. For example, a bug in the image code in a web browser might cause loading of code that isn’t checked. This way the malware gets smuggled onto the phone.
This means that if you get hacked via one bug and malware is loaded, the attacker has to work harder to solve the problem of how do I convince the phone to load it again at boot because the code it’s made of isn’t going to be approved code. When you reboot, you are effectively forcing a validation that all the code you have running is authentic, which would exclude the malware. Trick me once sure, can you survive a full pat down? Probably not. It’ll get caught.
Unless I have a second bug to fool the normal code loading systems too, the malware can’t run. You have to go back and trigger the first bug again somehow, which places more strain on the attacker.
Thanks for taking the time to write that out. I found it really helpful.👍
I love to talk about computer security. I don’t get the chance often enough.
I hope you get more chances to do so; you explained the situation in a much better way than the article and convinced me to reboot my phone.
You restart your phone because of security.
I ‘restart’ my phone, because it’s overheated and lost its battery % to 0.
We’re not the same.
Thank you, friend. You’ve convinced me to restart my phone.
Personally, I restart mine maybe once a week. No need to go crazy with it, but it helps make life harder for bad actors and might make your phone run better.
I hope to hear you* on Darknet Diaries hahaha
I can’t blatantly associate this account with other identities but I’ll say that I’ll be at DEFCON32 sniffing the air and shaking hands on the Wild Wild West of the open LAN.
I insert a lie or two about real life details every now and then to mitigate profiling. But the gist of what I write is always me.
If you have a blog where you talk about that, I would like to read it.
Exactly, as you already explained in detail this is primarily for security.
GrapheneOS has a feature to set a time after which the phone reboots in case there was no unlock. So in case a bad actor gets your phone they only have that time with a running system after the first unlock. However, if you use it normally, and unlock it in regular intervals it does not auto-reboot. This is especially neat if your threat level is not “investigative journalist” or “political activist on the run”, because then you can set the time to a longer interval and the phone does not reboot every night when you are asleep which also leads to the SIM card being locked and nobody being able to call you…
I remember this feature, and I wish it was a standard Android feature. It sounds like it would be trivial to implement and could be completely optional.
I wonder if tasker could do it… 🤔
I don’t think applications can reboot the phone.
Technically they can…but it requires root which within the context of this conversation yeah, you’re right, lol
But that only works for untrusted code escaping a sandbox, right? It does not help with malicious code embedded into legitimate seeming apps. The later vector seems easier, especially on Android, no?
I don’t really consider a malicious app to be an exploit. In this case, the software is doing exactly what it was designed to do – malicious activity. It’s not being manipulated to perform unintended operations through the exploitation of a software bug. Code signing and secure boot are not effective in the face of intentionally shipping malicious code to end users. It’s designed to frustrate actual hackers.
For malicious-by-design apps, we rely on a central app store that hopefully reduces the number of bad apps in circulation. If you publish malware, eventually you get caught and we know who you are. Sandboxing with a permissions system helps prevent apps from performing actions contrary to the user’s interests. E.g. why is my flashlight app asking for my contacts when I pressed ‘change color?’
If you directly exploit your way in, it’s harder to know who did this and why because you didn’t go through any central vetting or accountability system, and you’re not so easily bound by the permissions system. It depends on what your bad guy’s goals are, what they want, whom they’re targeting. Force your way in the back entrance, crawl through an open window (like a weak security setting), or lie your way in the front door (trojan)? It depends.
None of it is perfect, but I’m sure OS design experts would love to hear about better solutions if any exist.
Your explanations really are poetry.
Aww, thank you!
wouldn’t a malicious app still be an exploit though? I’d say that if I download an app for playing a game, but instead it was designed to also upload my private photos to the attacker’s server, i’d say that’s still exploiting. It’s just exploiting my expectations of what the app should do, rather than leveraging a system weakness (which it probably does, anyway)
You’d have to grant the app permission to access your photos. At this point, I would say the problem is more the person in the driver’s seat. You can’t really protect the user from themselves. If you had a legitimate reason to grant access to your photos, then we definitely have a problem.
You can think of this as a kind of exploit if you prefer. However, this becomes a permissions and ecosystem and reputation issue and not really a technical software one. Because you’re looking at a totally different set of tools, I think it’s useful to restrict exploit to refer only to bugs.
You could take that argument one step further and ask what if my new phone comes with preinstalled malware? The system collapses if you can’t have some level of trust the software you’re running.
I miss my BlackBerry and it’s scheduled reboot option
Pixels with grapheneos can reboot automatically after a number of hours with the screen off (unattended because you are sleeping). But this would also interfere with Whatsapp backup, which happens overnight.
Samsung phones also have a reboot schedule option
Where?
Settings > Device care > Auto optimization > Auto restart
Thanks!
And in addition to that, they also have automatic reboot if the phone detects performance degradation.
Idk man I just do it when my phone won’t ring when I get a call from my dad or doctor or something, so I have to go delete the voicemail and call them back. So like, every couple of weeks. I think it’s a Samsung thing, happened on my last phone too.
Nothing wrong with that. I don’t think it’s a mistake to not reboot your phone until you need to. It’s your phone. It’s not like rebooting your phone will save lives or the planet.
My wife doesn’t even use a lock screen password. I’m interested in the nuances of such things.
Guessing Pegasus and their ilk have an easy way around this
Nope! From Kaspersky:
For a case with persistence, Lookout notes another bug was required and details the extra work.