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

Oct 17
IMEI is not the only hardware identifier for the device available to the cellular network. Changing the IMEi alone isn't enough to hide the device identity from the network. It will only hide one commonly used ID rather than making the device not uniquely identifiable.
Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities.
It's possible to detect the devices with an IMEI not matching their capabilities/configuration or to detect that there's a device with the IMEI changing repeatedly but the other device identifiers remaining the same. You could end up drawing attention to yourself by doing it...
Read 10 tweets
Oct 10
@LysolPionex @Authy Sandboxed Google Play compatibility layer does not require using a work profile, user profile or Private Space for the apps to be sandboxed. They're sandboxed if you use them in your main Owner profile too. Putting it in a separate profile just keeps it a bit more separate.
@LysolPionex @Authy SafetyNet Attestation API was deprecated a while ago and is nearly entirely phased out. It was replaced by the Play Integrity API. Both of these things work fine with sandboxed Google Play. The issue is they largely exist to support services banning any non-Google-ceritifed OS.
@LysolPionex @Authy The weak Play Integrity API level used by most of the services enforcing it can be spoofed, but it requires pretending to be an old device without hardware attestation which they can detect and block with their Play Integrity API hardware fingerprinting. Enforcement is delayed.
Read 9 tweets
Oct 9
There's a highly inaccurate article about Pixels from Cybernews making the rounds everywhere in privacy communities. It gets the details nearly completely wrong and thoroughly misrepresents things like the optional network-based location used nearly everywhere as Pixel specific.
Any non-Pixel device with the standard Google Play integration has similar Google service integration doing the same things. You don't avoid it at all by using a non-Pixel, but you do end up with a device that's far less secure and adds OEM services with their own privacy issues.
It goes through connections for the Google Play network-based location that's offering as an option during the initial setup wizard, the optional Google Play account-based device management, Google Play feature flags, Google Play telemetry, etc. It gets a lot of details wrong.
Read 8 tweets
Sep 3
September 2024 Android Security Bulletin includes a patch for the wipe bypass we reported: CVE-2024-32896. It's actively exploited by forensic companies across devices. Pixels patched it in June 2024...

September ASB:
June PUB: source.android.com/docs/security/…
source.android.com/docs/security/…
We reported several vulnerabilities exploited by forensic companies in January 2024. We proposed implementing firmware reset attack mitigation and wipe-without-reboot. Pixels shipped reset attack mitigation in April 2024 and also a firmware mitigation making wipe bypasses harder.
In June 2024, Pixels shipped our wipe-without-reboot proposal to fully eliminate wipe bypasses. The full solution is a set of AOSP patches () but they still classified it as a firmware patch since it was treated as phase 2 of the Pixel firmware patches.android.googlesource.com/platform/frame…
Read 10 tweets
Aug 16


This is a fake story. Turns out that getting security information from the CISO of a mass surveillance company trying to build a dystopian police state providing police with "predictive policing" software largely based on racial stereotypes is a bad move.
Trail of Bits iVerify EDR product runs in the standard app sandbox on iOS and Android. It can hardly do anything beyond static scanning of APKs. It's a crippled antivirus app marketed as detecting sophisticated attackers. It's a scam and Trail of Bits has lost all credibility.
Trail of Bits is working closely with Palantir and is focused on getting government contracts. They've created a fake news story to promote their EDR product which has been propagated across mainstream media. Journalists didn't do basic due diligence and spread false marketing.
Read 12 tweets
Aug 15
Wired was manipulated into spreading misinformation to market Palantir and iVerify by misrepresenting a vulnerability in a disabled demo app as being a serious problem which could be exploited in the real world. They should retract the article but won't.

wired.com/story/google-a…
iVerify are scammers and anyone paying them money should rapidly stop doing it and remove their malware from their devices. The real security risk is giving remote code execution on your devices to one of these sketchy EDR companies lying about their capabilities and discoveries.
This is one of multiple carrier apps in the stock Pixel OS which we don't include in GrapheneOS. We were aware of it already since we had to go through them and figure out why they exist. We could embrace this fearmongering and leverage it for marketing, but we aren't dishonest.
Read 15 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!

:(