GrapheneOS Profile picture
May 18 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

Jul 21
Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.

404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.

Image
Image
Image
Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.
Image
Image
GrapheneOS is defending against these tools with generic exploit protections rather than by patching specific vulnerabilities. Until recently, it's likely that it was our generic memory corruption exploit mitigations including hardened_malloc which was successfully stopping this.
Read 29 tweets
Jul 2
@Parallel_Comms @utdream CalyxOS rolls back security a fair bit and doesn't provide comparable privacy or security features to GrapheneOS. It is not a hardened OS but rather somewhat anti-hardened. Their focus is marketing and bundling party apps and services, often with problematic privileged access.
@Parallel_Comms @utdream CalyxOS lags a bit behind on updates and misleads users about the security patches and privacy/security they offer. All their release notes have inaccurate claims about it, and they copied setting an inaccurate security patch level from LineageOS among other problems from there.
@Parallel_Comms @utdream /e/OS has all the privacy and security reductions from problematic LineageOS changes along with far more of their own. LineageOS lags months behind on quarterly/yearly updates which delays providing full patches and even the baseline ASB patches for Pixels. /e/OS is much worse.
Read 4 tweets
Jul 2
Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as highly private and secure. Bottom of the barrel MediaTek device with outdated AOSP is worse than status quo. All marketing, no substance.
As part of marketing their products, Unplugged are spreading unsubstantiated spin and misinformation about GrapheneOS and the much more secure hardware we target. We've been aware of it for a while but chose not to respond to it until they began doing it in direct response to us.
GrapheneOS is a hardened OS built on the latest release of the Android Open Source Project rather than older releases with inferior privacy/security and incomplete privacy/security patches. We substantially improve privacy/security with our changes rather than making it worse.
Read 21 tweets
Jun 15
@davidbombal This video has major inaccuracies. CalyxOS always uses multiple Google services and gives them extensive privileged access within the OS. CalyxOS has far more limited app compatibility than GrapheneOS, and their approach to compatibility comes a high security and privacy cost.
@davidbombal GrapheneOS provides far broader app compatibility via our sandboxed Google Play compatibility layer. It also has a much easier installation process. It's completely backwards to say that GrapheneOS is harder to adopt. What's the basis for making those statements about GrapheneOS?
@davidbombal GrapheneOS greatly improves both privacy and security. CalyxOS substantially rolls back security rather than improving it. It doesn't provide comparable privacy features either. No Storage Scopes, no Contact Scopes, no Sensors toggle, no per-connection Wi-Fi anonymity, etc.
Read 8 tweets
Apr 2
April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:




These are assigned CVE-2024-29745 and CVE-2024-29748.source.android.com/docs/security/…
source.android.com/docs/security/…
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks.
Read 14 tweets
Jan 3
We've added documentation for the hardware memory tagging implementation in hardened_malloc:



GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.github.com/GrapheneOS/har…
GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.
For user installed apps, we enable MTE by default for apps without bundled native libraries and apps marked as compatible. We give users the option to enable MTE for all user installed apps in Settings > Security and users can then toggle it off for specific incompatible apps.
Read 11 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!

:(