GrapheneOS Profile picture
May 18, 2024 16 tweets 4 min read Read on X
XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.
Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.
Image
Capability table described by the tweet. We can't properly format the tabular data as alt text but we can share it elsewhere.
Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks.
Capability table described by the tweet. We can't properly format the tabular data as alt text but we can share it elsewhere.
Capability table described by the tweet. We can't properly format the tabular data as alt text but we can share it elsewhere.
Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits.
Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much.

As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked.
Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks.
By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked.
Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes.

GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging.
Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all.
Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up.
GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastbootd zeroing.
New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits.

Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this.
If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable.
See for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us.
Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock.
One of our community members has uploaded the Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it:



We have info on XRY, Graykey and others but not the same level of reliable details as this.discuss.grapheneos.org/d/12848-claims…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with GrapheneOS

GrapheneOS Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GrapheneOS

Jun 18
@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ is what we recommend for a comparison but it does not compare to iOS. iOS has a lot more substance behind the privacy and security marketing than nearly any niche products/projects though. iOS does get targeted more right now but that's not all bad.
@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ You can see from that GrapheneOS is not only on the radar of companies developing exploits but they put work into trying to support it. If there's something successfully protecting people and it's gaining adoption, effort will be put into exploiting it.discuss.grapheneos.org/d/14344-celleb…
@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ The back and forth between attackers and defenders results in increasing security and more difficult exploits. Platforms like iOS and AOSP or Pixels and iPhones putting lots of effort into doing better and defeating attacks have ended up way ahead of those not targeted much.
Read 5 tweets
Jun 12
We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run GrapheneOS () and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost.grapheneos.org/faq#future-dev…
In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early.
We spent most of May preparing for the Android 16 release. Due to our extensive preparation work, our initial port to Android 16 has been completed and is being tested in the emulator. We could have published experimental releases yesterday if this was a regular AOSP release.
Read 21 tweets
Jun 11
In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable (). Android 16 launched today and porting is going to be significantly more difficult than we were expecting.
We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports.
Unfortunately, Android has made changes which will make it much harder for us to port to Android 16 and future releases. It will also make adding support for new Pixels much more difficult. We're likely going to need to focus on making GrapheneOS devices sooner than we expected.
Read 6 tweets
May 29
Our Contact Scopes and Storage Scopes features provide essential privacy functionality that's missing on standard Android. Scopes are a replacement for the standard contacts, storage and media permissions. We offer these as an alternative when apps request access to any of those.
When you enable Contact Scopes or Storage Scopes, GrapheneOS makes the app believe you've granted the requested permissions. However, it doesn't receive access to any more additional data not created by itself. Most apps work by simply enabling these without doing anything more.
For Contact Scopes, you can choose to give the app read access to a subset of the data for specific contacts. For more convenience, we support grouping contacts together and granting access to a group. It's very useful even without granting access to anything to pretend you have.
Read 17 tweets
May 17
Similar to iOS lockdown mode, Android 16's Advanced Protection feature is misguided. It adds security features exclusive to it which require using all of the other features. This prevents people using new security features if they need to avoid 1 feature.

security.googleblog.com/2025/05/advanc…
Most of the features already existed. The new ones are cloud-based intrusion logging, inactivity reboot (hard-wired to 72 hours), a new mode of USB protection and disabling auto-connect to a small subset of insecure Wi-Fi networks. Production MTE support is also essentially new.
GrapheneOS added locked device auto-reboot in July 2021. We proposed it to Google for Android in January 2024 as part of reporting exploitation by forensic data extraction companies. They implemented several of our other proposals, but not this until iOS added it in October 2024.
Read 14 tweets
Apr 25
@MishaalRahman Android 12 API for this will stop most of Cellebrite's current attacks since they target Linux kernel USB peripheral drivers. However, they could switch to targeting the Linux USB-C protocol implementation which doesn't get disabled by the Android 12 API, only high level drivers.
@MishaalRahman By default, our feature blocks new connections in both software (similar to the standard toggle) and hardware but allows existing connections established while unlocked to continue. Once those end, it disables USB-C and pogo pins data (USB-C is more than USB) at a hardware level.
@MishaalRahman The approach of allowing existing connections to continue in the default mode allows us to have it enabled by default. Users can set it to a stricter mode for higher security. Charging-only mode is the next stricter setting disabling USB connections and data all of the time.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(