Exploit Protection - USB State

Bettyswollox

Is it possible / easy for the GOS team to implement a revert to preselected state when a state change to USB On is selected after a period of no data exchange...or when phone reboots after the selected time period. Sometimes I use USB data transfer but forget to turn the protection back on....??

GrapheneOS

Bettyswollox There's no reason to change it to the "On" mode to use USB data transfer. Why don't you use the default "Charging-only when locked"? It continues permitting a connection established while unlocked after locking the device. If you want to reduce it back to "Charging-only" or "Off" when done then that makes sense but what you're describing is unnecessary.

Bettyswollox

My bad...I didn't read the instructions....was using "charging only" selection. Thank you.

Bettyswollox

Hello again....is there any improvement I can or you can do to improve baseband isolation from the main OS.

I run Airplane Mode - Always
I don't have a SIM
I physically remove microphones.

This is hassle!!

I can say with 100% certainty without having physical proof that the mic can be tapped by an external exploit even with the software toggle on (mics off)

I have had numerous pixels over the last few years. I currently hold a P7, 7a and 8a. I've removed the microphone from 7a and 8a I use 7 if I absolutely need to make a call.

With MIC's removed I'm sure I can't be heard (obviously) but I'm also sure with MIC's in place they can be accessed. In fact I believe that when I link a mic via Bluetooth I can also be heard.

I cannot say for definite if the phones were physically accessed but given the consistency I would lean towards a completely remote. I use combined alphanumeric passwords.

Is this possible via baseband commands / MITM ??

I also have a suspicion that what Cellbrite has published about GOS may not be fully transparent.

I am an avid GOS supported and I cannot praise the work you guys are doing enough. But sometimes you can only go as far as you can go.

What are your views here???

I feel I have a good understanding of how pixels interact with baseband and GOS...but I have a few questions...is Bluetooth and WiFi handled via the same SoC as radio signals 2G/3G/4G LTE etc. If there is a piece of hardware that I could remove while leaving microphones in place. Use calls over WiFi i.e use encrypted chats which avoid baseband (if possible ???)

And has GOS gone as far as it can to limit this attack vector...???

userofgos

Bettyswollox see here: https://xcancel.com/GrapheneOS/status/1843912026869117250#m

Any operating system or smartphone claiming it can't be exploited is a scam. Nothing can guarantee security. We provide substantial defenses against exploitation which are hard to bypass. We're always working on improving it. Not an area of work with any finish line at all.

It's possible to remove microphones and sensors usable as microphones as NitroKey offers for their NitroPhone product which is a modified Pixel with GrapheneOS. Can then attach a headset to the device. Removing only the microphones or providing a switch for those is incomplete.

There are hardware products with incomplete switches for disabling audio recording since they're missing coverage of other sensors directly usable as microphones. Kill switches are a good concept as a last resort for a compromised device but need to be done properly to work well.

Even with a way to block the cameras, microphones and other sensors from working, it's quite a disaster for a user's main personal device to get compromised. An attacker can still get all their data including photos, videos, documents, all the app login sessions, keys, etc.

Even a properly designed kill switch for the cameras or overall audio recording can't offer any value while the user is actually using it.

It makes sense to have a way of defending against a compromised device as a last resort, but a lot has already gone wrong at that point.

And also here: https://xcancel.com/GrapheneOS/status/1677905667032596481#m

Cellular radio, Wi-Fi/BT radio, NFC radio, GPU, SSD and other peripheral components are isolated on phones like iPhones and Pixels.

Hardware kill switches are a last resort for a device that's compromised. They should have a purpose such as disallowing audio recording.

Disallowing audio recording requires more than disabling microphones. Other sensors (accelerometers, gyroscopes) can be used as microphones and it has been demonstrated that even with polling limited to 100Hz, that works to decode speech, and you can poll them at 5kHz.