←back to thread

446 points akyuu | 1 comments | | HN request time: 0s | source
Show context
derbOac ◴[] No.45766747[source]
They couldn't answer the question most on my mind: "We’ve reached out to Google to inquire about why a custom ROM created by volunteers is more resistant to industrial phone hacking than the official Pixel OS. We’ll update this article if Google has anything to say."
replies(10): >>45766778 #>>45777056 #>>45778032 #>>45778056 #>>45779079 #>>45779102 #>>45779404 #>>45780503 #>>45781099 #>>45783125 #
IncreasePosts ◴[] No.45777056[source]
Is grapheheOS actually harder to hack or does cellebrite just not put a lot of effort into supporting it because the very low odds of LEs running into one in the wild?
replies(5): >>45777082 #>>45777144 #>>45777155 #>>45779084 #>>45779157 #
zb3 ◴[] No.45777144{3}[source]
It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.
replies(2): >>45777712 #>>45778612 #
fph ◴[] No.45777712{4}[source]
Two fixes that would be trivial to backport to mainline Android.
replies(3): >>45777832 #>>45777836 #>>45779218 #
vbezhenar ◴[] No.45777832{5}[source]
You can configure USB port for charging only in the developer options.
replies(5): >>45777859 #>>45778136 #>>45779058 #>>45779241 #>>45781153 #
1. strcat ◴[] No.45779241{6}[source]
No, that only changes the USB gadget mode. It doesn't disable USB peripheral support, USB protocol handling, etc. in the OS and doesn't disable USB at a hardware level. It doesn't protect against the vast majority of Linux kernel driver exploits heavily used by Cellebrite. They mainly exploit bugs in USB peripheral drivers but could also exploit lower level kernel code or firmware if they had to.

Modern Android on modern devices does support disabling software USB support for USB peripherals and USB gadgets while locked via Android 16 Advanced Protection feature. It also has a device admin API for disabling USB at a software level through device admin apps, which could implement disable it while locked but cannot provide support for still using a USB device connected while unlocked to make it much more usable. None of that provides comparable protection to the GrapheneOS USB protection feature, which is one small part of the overall GrapheneOS exploit protections.

By default, GrapheneOS blocks new USB connections at a software AND hardware level when the device is locked and then disabling USB data once existing connections end. You can get similar software level functionality via the Android 16 Advanced Protection feature but not the hardware-level protection or the many other exploit protections in GrapheneOS.

https://grapheneos.org/features#exploit-protection explains what's improved compared to standard Android 16. It's not documentation on Android + GrapheneOS features but rather only what GrapheneOS improves.