N

nashgraph

My Pixel 6 was confiscated by the German police after a political rally. I was recently able to pick it up again. From an inquiry with my lawyer, the following emerged: The authorities tried to read the device with both UFED4PC and Cellebrite Premium Touch. In addition, software from other forensic providers was used without success. The software did not succeed in breaking the system. The device was in BFU mode and had a 30-digit PIN. USB port was deactivated. As of March 2025, I can therefore say that it is not possible for Cellebrite to break a secured GrapheneOS.

That's pretty much it. It would being huge peace of mind to know mic & camera are turned off after a call, similar to what GOS already does to Wi-Fi and Bluetooth.

GrapheneOS version 2025032500 released:

https://grapheneos.org/releases#2025032500

See the linked release notes for a summary of the improvements over the previous release.

Stayjuice How are we supposed to install GOS on thos devices?

GrapheneOS version 2025032100 released:

https://grapheneos.org/releases#2025032100

See the linked release notes for a summary of the improvements over the previous release.

We created a thread about the upstream bug at https://discuss.grapheneos.org/d/21054-android-15-qpr2-android-16-beta-microphone-indicator-persistence-bug. Please continue discussion there.

GrillsBear56 It's an Android 15 QPR2 UI regression, not a sign of compromise. A clear answer has been provided. It will be fixed in a near future Android release or we may figure out how to fix it ourselves sooner.

GrapheneOS I still don't understand how Magnet was exploiting Pixels 6-8 through fastboot from 2021-10 to 2024-03 (more than 2 years) without no one reporting it to Google during all that time. At least you reported CVE-2024-29745 couple months before they patches few months later. But it's still terrible that they exploited this during 2 years and 5 months. We waited MSAB to proudly post a video of the exploit on YouTube if I remember to make things change.

If anyone is interested to see Graykey Android and iOS support excel files, I can post them (they are from october 2024)

They can exploit also iPhone 12 series in BFU until iOS 17, probably iOS 18 too now.

gk7ncklxlts99w1 I don't even really know what hardware memory tagging is aside from what I could glean from a quick duckduckgo search.

Here is an explainer linked to a while back by @Titan_M2: New Memory Tagging Extension User Guide for Android OS Developers.

Quick summary: MTE is pretty good at stopping some popular methods used by malware to attack devices, such as buffer overruns and use-after-free. If MTE is on, a covered attack has a fair chance of crashing the attacked app (or the attacked kernel) before execution of malicious code can get very far. MTE isn't perfect, because nothing is, but, for people concerned about devices being attacked, any substantial defense mechanism is of interest, and MTE is substantial.

gk7ncklxlts99w1 No, there are multiple security improvements on the newer devices. Hardware memory tagging (MTE) is the most significant one and heavily used by GrapheneOS to implement much stronger defenses against exploitation. It's not used by the stock Pixel OS in production but is nearly exclusive to Pixels in practice. Pointer authentication codes (PAC) and branch target identification (BTI) are similarly only on 8th gen and later Pixels due to them being ARMv9 instead of ARMv8.2. Those aren't the only security improvements, but they're the most obvious ones.

grayway2

However, DE storage space is still accessible without user credentials and can reveal to the examiner installed packages or user file sizes in profiles.

This still requires exploiting the device to take advantage of it, which Cellebrite is unable to do according to their documentation. Graykey and XRY Pro would have been able to take advantage of it with their approach exploiting fastboot mode instead of the OS. As you said, it's how it's designed to work protecting this the device encrypted data with the Owner user password would be an additional feature requiring a toggle since it would significantly hurt usability and accessibility.

Let's talk about the capabilities of these tools on locked android and iOS devices.

I did some research and some informations may be not accurate but here are my conclusions :

AFU iOS : Access to any iPhones even if running latest iOS version
BFU iOS : can perform a brute-force only up to iPhone 11 series thanks to checkm8 exploit (don't know what hardware vulnerability they are exploiting in XR and 11 series)

Android AFU : Google Pixels running stock OS were vulnerable until march or april 2024 security patch update because of vulnerability in fastboot mode, magnet and msab were actively exploiting the vulnerability
Android BFU : starting pixels 6 series, no BF capabilities

Others Android distributions (Samsung, Oppo, Xiaomi ect) all vulnerable in AFU and BFU

GrapheneOS AFU : no known exploit since 2022 vendor security patch update . They can only perform an extraction if user provide the credentials or if device unlocked. However, DE storage space is still accessible without user credentials and can reveal to the examiner installed packages or user file sizes in profiles. It is not a vulnerability but just how AOSP is designed.

Here's the Cellebrite Premium 7.73.1 Pixel Support Matrix from February 2025.

Pixel 6-9 with GrapheneOS - the best! No any access to BFU/AFU state

whiskeywalrus
Batteries wear out the least if they have a 30% gap between the lower and upper range, i.e. never have less than 30% remaining charge and never have more than 70% charge.
It then also takes a little longer to achieve the corresponding number of full charge cycles.

A good compromise for frequent users or users of devices with very small batteries is charging at 20 to 80 %.
This wears out the battery more quickly, but the device can be used with fewer restrictions or the owner may not feel so restricted.

Conclusion: If it is possible for you or if you do not find it strenuous, charge the battery at 30 or 40 % and only charge it to around 70% if you are not using the device locally for hours on end.
It would be ideal if we could set not only 80% but also 70% as the charging limit in GrapheneOS.
If I understood the release notes correctly, the GOS developers may realise this later.

When it reached 100% I had to leave my phone plugged in for nearly half an hour before the shield icon appeared. Just an FYI for other impatient souls out there. 😊

The best thing for battery health will be using the battery optimization feature and leaving the device plugged in as much as possible to take advantage of bypass charging instead of repeatedly draining and charging the battery. It needs to have proper USB-PD for that to work well, so disabling fast charging would be at odds with the bypass charging feature.

The OS only displays how many cycles were made on the battery, is there a way to check the % health of the battery?

It estimates the capacity but it's not shown in the regular user interface as far as we know. You can check it via ADB shell via /sys/class/power_supply/battery/charge_full but we don't recommend using ADB on a production device. We could potentially add the info to the Settings app.

Alllus

In addition - it makes no sense to reboot in a few hours, if the UFED - is a mobile portable device and the dump of your owner’s phone will be extracted immediately during a police search of the apartment (in AFU State).

Cellebrite Premium doesn't have exploits which work with GrapheneOS with a patch level later than mid-2022. The purpose of the locked device auto-reboot feature is getting the device back to Before First Unlock state before they develop exploits for a current GrapheneOS and Pixel firmware release. It defends against future exploits.

The user of the phone that has with important data - must do all efforts to turn off the phone before his return to the police. With one button or gesture of the finger. Any options.

We provide strong defenses against exploitation combined with getting the device back to Before First Unlock state. Whether or not people manage to reboot to turn it off, GrapheneOS does a great job protecting their data.

https://discuss.grapheneos.org/d/20401-grapheneos-improvements-to-protection-against-data-extraction-since-2024 is a thread about recent improvements to the defenses.

https://discuss.grapheneos.org/d/20402-cellebrite-exploits-used-to-target-serbian-student-activist is a thread about a recent example where GrapheneOS blocks all the exploited vulnerabilities for locked devices. It prevents one from being exploited even unlocked and the other 2 would be much harder to exploit due to the generic memory exploitation protections.

P.S. Support for Pixel 8 and 9 (Physical Dump ( ADB(Rooted) ), File Dump (Android Backup, APK Downgrade), Logical (Apps Data, Phone book, Call logs, SMS etc) ) added to the UFED version 7.72 (release from 2024-10-31).

You're talking about an extraction tool requiring them to already have the PIN/password. We're talking about their exploit products for law enforcement which do not have the ability to exploit modern GrapheneOS in practice, only iOS and Android. We have access to Cellebrite Premium documentation from January 2025 and can obtain more recent documentation if we ask.

gk7ncklxlts99w1 GrapheneOS is definitely not the most secure OS if you don't limit it to user-facing general purpose smartphone, laptop or desktop OS. GrapheneOS is easily the most private and secure general purpose smartphone OS. The competition is iOS, none of these products. It's certainly more secure than everything you've listed here. iOS and AOSP are far more secure than any traditional desktop operating systems. We would simply say GrapheneOS is more secure than iOS in lockdown mode when looking at the whole picture despite iOS having a more secure base for the kernel for now. iOS has a lot of merits, but these things don't.

Solarin by Sirin Labs

We don't have all of the details but we're confident it's less hardened than GrapheneOS and focused more on performative things such as the IDS you mention.

Murena One, which uses /e/OS, a fork of LineageOS.

Highly insecure hardware and software. Massively worse than the Android Open Source Project. Neither good for privacy or security. It lags so far behind on patches and rolls back security so much along with having a bunch of poorly implemented, privacy invasive services as part of it.

Purism Librem 5

These are highly insecure devices without basic security patches and security features implemented. The OS doesn't have a basic application security model or other protections. Audio recording kill switch isn't implemented correctly and that's the one which could be more than a near useless frill.

K-iPhone

Looks like an iPhone with device management and other apps set up. Very sketchy. Just compare to a regular iPhone instead, it's the same hardware and OS, and avoids all the sketchy stuff.

Blackberry

They don't make smartphones anymore. They licensed out their brand to others to make highly insecure ones without proper support. Their hardening was less impactful than the security features missing from not having the major OS upgrades. Their Android smartphones were much less secure, not more secure. Whether or not their prior OS was secure is an open question since it didn't get much research. Using a microkernel is very good in theory, but it can be less secure in practice.

Locart Cellebrite's current documentation shows they can exploit iOS 18 and later versions. Cellebrite is also only one of the organizations developing these kinds of exploits. We have access to later documentation than July 2024, we just don't plan to publish it anymore to avoid the leaks to us being closed.