GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Website: https://grapheneos.org/
Forum: https://discuss.grapheneos.org/
X: https://x.com/GrapheneOS
GitHub: https://github.com/GrapheneOS

Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

NIP-05 Address

[email protected]

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslp5jg4

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2024-09-12 19:50:02

- reply

The restricted settings feature has nothing specifically to do with the Play Store. The article you've linked explains this. It's an F-Droid deficiency causing it to have settings restricted for apps it installs which does not apply to modern app stores regardless of whether they're the Play Store or not. You can simply toggle off restricted settings. If you want F-Droid to start caring about security and also using modern APIs, that's something they need to address not us...

2024-09-12 19:48:31

- reply

You're completely misunderstanding how this works. Restricted settings is a toggle which can be disabled.
> This is an expansion of the restricted settings feature introduced in Android 13, which can still be manually disabled on a per-app basis in Android 15.
F-Droid only has restricted settings for apps it installs enabled by default because it uses the legacy package installation system and hasn't moved to using the modern system. F-Droid has major security and legacy code issues.

2024-09-10 15:22:44

Our Android 15 port is increasingly solid. It can currently be tested by building the OS via https://grapheneos.org/build. Since there aren't stable releases of Android 15 available yet, we currently support using the firmware, etc. from the Pixel Android 15 Beta releases for Pixels.

2024-08-25 01:40:42

- reply

SimpleX is a real private messaging app with end-to-end encryption, and unlike some other non-Signal E2EE messaging apps has perfect forward secrecy.

2024-08-18 03:35:23

Vanadium version 127.0.6533.104.3 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/127.0.6533.104.3
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/15044-vanadium-version-127065331043-released
#GrapheneOS #privacy #security #browser

2024-08-17 02:26:04

- reply

Installing GrapheneOS doesn't require a laptop or desktop. It can be installed from any Android device including a phone or tablet to one of the supported devices. You need two devices because the security model requires having both control over the OS to enable OEM unlocking and then physical access to the device for unlocking, flashing and locking it via USB with on-device confirmation for both unlocking and locking. OEM unlocking is disabled in the new OS.

2024-08-15 21:17:21

- reply

GrapheneOS has gone through each of the carrier apps included on Pixel generation to determine their purpose and consequences of including or excluding them. Here it is being excluded from the new adevtool project for ProtonAOSP and GrapheneOS in 2021:
https://github.com/GrapheneOS/adevtool/commit/9c5ac945f#diff-95eb7b50f2781158146e721436d7c5d6f7421755906307a6b7a1f727bb20d53eR109

2024-08-01 20:33:05

We're going to be making another attempt at shipping DNS leak prevention for third party VPN apps. The last attempt resolved a lot of the compatibility issues with the previous approach, so we've made some progress. We don't what's wrong with Proton VPN and certain other apps.

2024-07-26 04:04:01

- reply

In Vanadium, our JIT toggle fully disables the JIT and therefore currently loses Wasm support. An increasing number of sites are depending on Wasm with no fallback to JavaScript. Most of these sites perform perfectly fine with only the fast V8 interpreter and no JIT compilation.

2024-07-26 04:01:57

- reply

Chromium has a V8 Optimizer toggle for disabling the 2 optimized tiers of the Just-In-Time (JIT) compiler to greatly reduce attack surface. However, it doesn't disable baseline JIT and therefore still does dynamic native code generation. They did this to avoid breaking Wasm.

2024-07-26 03:59:30

Chromium has merged the WebAssembly interpreter submitted by a Microsoft Edge engineer:
https://chromium-review.googlesource.com/c/v8/v8/+/5509903
Once this reaches a Chromium stable release, Vanadium will support WebAssembly by default instead of requiring turning on JS JIT via drop-down site settings.

2024-07-26 03:17:57

- reply

We don't know how much of our code they're using. As with Copperhead, it's likely they'll simply continue using it regardless and would need to actually be taken to court.

2024-07-25 21:47:13

- reply

Unplugged has built their product out of open source projects, but without complying with the licenses from projects like DivestOS and while trying to harm open source. Claiming to be in the process of replacing some of the code they were caught stealing doesn't change much...

2024-07-25 21:42:00

- reply

They're trying to present themselves as if they were leaders in the field and switched sides, but they never were and simply want money.
Unplugged is an affinity scam in the same vein as the Freedom Phone. At least Freedom Phone doesn't seem to try to harm open source projects.

2024-07-25 21:41:37

- reply

Unplugged was founded by Erik Prince, noted war criminal and illegal arms dealer. They make a point in talking about the involvement of their employees in enabling these kinds of operations:
https://x.com/GrapheneOS/status/1805592120259936338
That doesn't imply competence, but explains the lack of ethics.

2024-07-25 21:41:07

- reply

Unplugged is using an SoC from MediaTek, a company known to have poor security practices, which fares poorly against real attackers and which has a history of repeatedly shipping actual backdoors. They're trying to portray that as more trustworthy and more secure hardware. Nope.

2024-07-25 21:41:00

- reply

They still haven't ported to the initial release of Android 14 with Android 15 right around the corner. This means they're missing at least around a year of Moderate severity privacy/security patches and huge privacy/security improvements from the past year of Android releases.

2024-07-25 21:40:53

- reply

They keep pushing the false claim that Pixels supporting using another OS makes them less secure. The reality is that it's properly implemented in a secure way without adding any significant attack surface. The bottom of the barrel MediaTek Unplugged devices have awful security.

2024-07-25 21:40:46

- reply

We have an existing thread going through many of their false claims and debunking them:
https://grapheneos.social/@GrapheneOS/112717890463524863
We also responded to their lies about GrapheneOS directly. They've read our posts and have chosen to continue peddling the same misinformation about GrapheneOS.

2024-07-25 21:35:25

Unplugged has simply doubled down on false claims about GrapheneOS security, pretending people cannot buy devices with GrapheneOS installed and pretending it's hard to install along with promoting their blatantly insecure products with false marketing.
https://x.com/_AndresSegovia/status/1813261339319804343

2024-07-23 22:07:44

- reply

Try asking for help with a new thread on https://discuss.grapheneos.org.

2024-07-23 21:54:33

Vanadium version 127.0.6533.64.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/127.0.6533.64.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/14403-vanadium-version-12706533640-released
#GrapheneOS #privacy #security #browser

2024-07-23 21:54:21

- reply

It's normal behavior. Did you try enabling exploit protection compatibility mode? The app may also depend on Google Play which would require using sandboxed Google Play.

2024-07-23 21:46:06

- reply

This is normal and also occurs on the stock OS. SELinux denials are a normal part of SELinux. Some denials happen frequently and are meant to occur so they get dontaudit rules silencing them but others are left alone because it may also silence errors.

2024-07-23 19:13:08

GrapheneOS Camera app version 71 released:
https://github.com/GrapheneOS/Camera/releases/tag/71
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/14399-grapheneos-camera-app-version-71-released
#GrapheneOS #privacy #security #camera #android

2024-07-23 18:35:48

- reply

BF implies ability to bypass random 6 digit PINs. It does not imply ability to bypass a decent passphrase where hardware-bound key derivation slows them down too much. A truly strong passphrase is safe even if they bypass hardware-bound key derivation and use a huge server farm.

2024-07-23 18:35:36

- reply

BF capability does not bypass hardware-bound key derivation, so a brute force is still rate limited but no longer has an extremely small number of attempts. Cellebrite Advanced Services may be able to bypass this through extracting data from hardware, but it would be difficult.

2024-07-23 18:35:29

- reply

Glossary:
BFU: Before First Unlock exploitation of OS
BF: Brute Force password after BFU exploitation, which requires bypassing secure element brute force protection if implemented
AFU: After First Unlock exploitation of OS
FFS: Full Filesystem Extraction from an unlocked device

2024-07-23 08:49:59

- reply

If the stock OS isn't up-to-date, where would the alternate OS be getting firmware updates? Many of these operating systems don't even ship the firmware, driver, HAL and other updates that are available because they simply leave the firmware and OS vendor images which were present when they were installed. A proper production OS needs to ship all this and build the vendor images itself even if a lot of what's in there are just prebuilt code from the stock OS for the firmware, etc.

2024-07-23 08:43:14

- reply

They still build and sign nearly all the apps themselves, and are not migrating towards using that approach. Regardless of whether it's their own builds with their own signatures, F-Droid is still responsible for securing the initial download. It has poor security throughout the design and implementation.
You can read https://privsec.dev/posts/android/f-droid-security-issues/ as a starting point but it doesn't cover most of our technical concerns with F-Droid. We also have major concerns about the people in charge of it.

2024-07-23 05:45:49

GrapheneOS Camera app version 70 released:
https://github.com/GrapheneOS/Camera/releases/tag/70
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/14376-grapheneos-camera-app-version-70-released
#GrapheneOS #privacy #security #camera #android

2024-07-23 03:18:32

GrapheneOS Camera app version 69 released:
https://github.com/GrapheneOS/Camera/releases/tag/69
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/14372-grapheneos-camera-app-version-69-released
#GrapheneOS #privacy #security #camera #android

2024-07-23 03:18:24

- reply

You an install Google Photos and Pixel Camera from the sandboxed Play Store.

2024-07-23 01:59:22

GmsCompatConfig (sandboxed Google Play compatibility layer configuration) version 124 released:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-124
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/14370-gmscompatconfig-version-124-released
#GrapheneOS #privacy #security #gmscompat

2024-07-23 01:57:40

- reply

iodéOS is quite insecure and lacks proper privacy/security patches and features though...

2024-07-23 01:56:55

- reply

It's useful as a stand for charging and giving it better audio. It's unfortunate that it doesn't have a USB hub since you can't use both the USB-C port and stand pogo pins USB connection at the same time. The one that's connected first blocks the other from being used.

2024-07-23 01:55:12

- reply

Molly is a fork of Signal that's compatible with it. It closely follows the Signal releases.

2024-07-22 18:13:18

- reply

See https://accrescent.app/docs/guide/appendix/requirements.html.

2024-07-22 18:07:19

- reply

Molly is a reputable project and we know them well. They're doing good work and are trying to get some of the improvements into Signal but Signal isn't very receptive to it.

2024-07-22 04:14:22

- reply

Cellebrite isn't the only company building these kinds of exploits and governments around the world want these capabilities so they're going to get them built. We work on securing against it through technical measures rather than trying to stop it with legal or political action. It's simply not what we do. We'll defend ourselves as an organization and our team members as individuals when they're attacked but this is something we need to address with technical measures.

2024-07-21 23:23:11

- reply

It requires an unlocked device, but their BFU or AFU exploits provide an unlocked device.
BFU exploit requires BF (Brute Force) to provide a fully unlocked device which they lack on Pixel 6 or later / iPhone 12 or later at the moment. A strong passphrase prevents it.

2024-07-21 23:01:39

- reply

Here's the new thread: https://grapheneos.social/@GrapheneOS/112826067364945164.

2024-07-21 23:01:12

- reply

Here's the new thread: https://grapheneos.social/@GrapheneOS/112826067364945164.

2024-07-21 23:00:20

- reply

Here's the new thread: https://grapheneos.social/@GrapheneOS/112826067364945164.

2024-07-21 22:53:19

- reply

We have no idea if Cellebrite was exploiting it before it was publicly disclosed as part of Google patching it. They may have developed an exploit based on it after it was publicly disclosed. We don't have the historical documentation. At least 3 people found it independently before disclosure: a Google engineer, one of our developers and another security researcher. Indicates that it was not particularly hard to find. Not clear why they didn't prioritize and fix it faster.

2024-07-21 22:52:11

- reply

We thought they were going to take it seriously and get it fixed within 2-3 months with their much greater resources. We eventually ended up fixing it early because it was taking them so long. We were very disappointed in them taking around 10 months to fix this since the initial report. They've gotten better at dealing with stuff like this since then, but they need to improve more. It should be possible for them to fix this kind of thing in days or at least weeks, not months.

2024-07-21 22:50:31

- reply

The 2022 issue is likely the SIM PIN lockscreen bypass. It didn't give much access for Before First Unlock state but it did open up a lot more attack surface and they could have used another exploit. We patched this before the stock OS, but we could have patched it much earlier than we did. We didn't want to risk releasing a partial fix for an issue an in doing so exposing people to it being exploited. We could have fixed it a few months before we did, but we can't change that now.

2024-07-21 22:46:22

- reply

It's known for Pixels because it's easy to check what's stored in device encrypted data. We could provide a toggle for making the Owner password into a boot password protecting more of the data but it would be fairly hard to implement and quite invasive so we haven't done it yet. This wasn't one of our focuses until recently. We were focused much more on defending against remote attacks and security/privacy from apps. Since January, we've been working on defending against this a lot too.

2024-07-21 22:31:47

- reply

After First Unlock
Before First Unlock
Full Filesystem Extraction
Brute Force
Cellebrite appears to be able to get the iOS lock method as part of their AFU exploit and uses that to obtain the small subset of data meant to be kept at rest while locked After First Unlock so they're not differentiating between those iOS data classes because they've defeated the whole purpose of those data classes. Hopefully, Android's upcoming implementation actually works properly. We'll see.

2024-07-21 22:30:28

- reply

Our upcoming 2-factor fingerprint unlock feature will help our users avoid relying on the secure element. GrapheneOS users will be able to use a strong passphrase for primary unlock and fingerprint+PIN for secondary unlock to avoid the usual drawbacks of biometric unlock. For this purpose, a 4 digit PIN will be fine since there are only 5 overall attempts. We hope it's usable enough that a large portion of our users end up moving to it. This will combine very well with auto-reboot.

2024-07-21 22:28:33

- reply

Yes, but they can develop new exploits, so there is more to consider.
GrapheneOS users have auto-reboot enabled by default which gets the device to BFU from AFU automatically, so GrapheneOS users don't have to worry about future AFU exploits for a device obtained by an adversary in the past.
A strong passphrase avoids relying on the iPhone/Pixel brute force protection. It's holding up against Cellebrite right now, but not necessarily against the US government using hardware tampering.

2024-07-21 22:12:33

- reply

We're going to continue advancing the state of the art for protection against exploitation. Hardware vendors are welcome to collaborate with us if they want to protect users. We're regularly filing vulnerability reports and making suggestions to improve the security of Pixels.

2024-07-21 22:09:25

- reply

In the near future, we plan to ship support for adding a PIN as a 2nd factor to fingerprint unlock to enable users to use a strong passphrase combined with PIN+fingerprint secondary unlock for convenience. We have an initial implementation, but it needs more work before shipping.

2024-07-21 22:05:23

- reply

We also began triggering a full compacting garbage collection cycle in system_server and SystemUI when the device is locked based on info about these attacks. This releases memory for no longer allocated objects to the OS, where our generic zero-on-free feature clears all of it.

2024-07-21 21:58:50

- reply

Currently, non-Pixel devices are still vulnerable to these reset attacks. In June 2024, Android 14 QPR3 included another feature we proposed providing wipe-without-reboot support for the device admin wipe API. We shipped this early and use it in our duress PIN/password feature.

2024-07-21 21:57:57

- reply

In January 2024, we reported several vulnerabilities being exploited by the XRY tool from MSAB to get data from Android devices including stock OS Pixels. In April 2024, Pixels shipped a reset attack mitigation we proposed preventing the whole attack vector. We plan to expand it.

2024-07-21 21:37:25

- reply

Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for overall Android devices. Other than the Titan M2 on the Pixel 6 and later not being successfully yet to bypass brute force protection, it's largely just based on what they've had time to support.
https://grapheneos.social/system/media_attachments/files/112/826/162/703/194/689/original/538a10a499d35054.png
https://grapheneos.social/system/media_attachments/files/112/826/163/200/478/671/original/7333c2444af7f37f.png
https://grapheneos.social/system/media_attachments/files/112/826/163/595/741/238/original/ffd1f438a564e7ac.png
https://grapheneos.social/system/media_attachments/files/112/826/164/084/167/269/original/7135f327f0cdbb67.png

2024-07-21 21:36:48

- reply

Later in June 2024, we extended our software-level USB protection, merged it into the newer hardware-level protection feature and extended the hardware-level protection to pogo pins on the Pixel Tablet. There's extremely strong protection against these USB-based attacks now.

2024-07-21 21:36:44

- reply

In February 2024, we added a new feature for disabling the USB-C port at a hardware level. In March 2024, we set the default mode to "Charging-only when locked, except before first unlock". In June 2024, we increased the default security level to "Charging-only when locked".

2024-07-21 21:36:35

- reply

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.

2024-07-21 21:36:29

- reply

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.
https://grapheneos.social/system/media_attachments/files/112/826/160/380/376/012/original/5ee4070c6ca3f1cd.png
https://grapheneos.social/system/media_attachments/files/112/826/160/656/912/687/original/ae52a969e31033b6.png

2024-07-21 21:15:55

- reply

Two of our sources have now provided us with the current documentation so we've confirmed that the screenshot above was authentic.
Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.
Our thread is here:
https://grapheneos.social/@GrapheneOS/112826067364945164
https://grapheneos.social/system/media_attachments/files/112/826/074/952/843/582/original/c226d89c304abb2f.png
https://grapheneos.social/system/media_attachments/files/112/826/075/211/949/625/original/08c940b358e4022a.png
https://grapheneos.social/system/media_attachments/files/112/826/075/457/103/365/original/2fc547d3ed3ca255.png

2024-07-21 21:12:42

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.
https://grapheneos.social/system/media_attachments/files/112/826/066/256/335/333/original/176bc82f0c5204a8.png
https://grapheneos.social/system/media_attachments/files/112/826/066/672/278/124/original/4c71d40ae6411cc1.png
https://grapheneos.social/system/media_attachments/files/112/826/067/167/036/562/original/e319b291067e8719.png

2024-07-21 07:36:11

- reply

We can't recommend using F-Droid due to extremely poor security practices throughout their client, repository design and infrastructure. The developers have an anti-security attitude and have demonstrated thoroughly untrustworthy behavior.
We're going to be supporting Accrescent and helping them get what they need to reach a stable release and provide a huge number of apps with the support of the app developers.
People are free to use F-Droid on GrapheneOS but we won't promote it.

2024-07-21 02:51:45

- reply

There will be a lot more apps there in the future. We're doing our part to make it available to GrapheneOS users securely and to promote it now.

2024-07-21 02:22:18

- reply

It's unfortunate that there was a whole bunch of secondary news coverage where it was misreported that Cellebrite was unable to exploit current iOS based on documentation from April 2024. It's July 2024 now, and they've had months to restore the capabilities broken by an update.

2024-07-21 02:15:46

- reply

We're currently waiting for one of our several sources to provide us with the new Android and iOS documentation. We aren't going to post the leaked iOS table in this thread because we can't confirm that it's authentic yet. We should have the new documentation quite soon though.

2024-07-21 02:08:39

- reply

It's common for them to fall behind by a few months for new iOS and Android versions. Android and iOS have no secure way to automatically get devices back into Before First Unlock from After First Unlock as GrapheneOS does so attackers can simply wait until they have an exploit.

2024-07-21 02:06:13

Cellebrite Premium documentation we published in May and which recently received a lot of media coverage was from April 2024. Someone has shared a newer version of the iOS table indicating Cellebrite caught up to iOS 17.5.1 or higher along with the iPhone 15 for the OS exploits.

2024-07-21 01:58:48

- reply

We'll be delegating distributing developer builds of apps signed by the developers to Accrescent rather than doing it in ourselves. Our App Store will be focused on our own apps and eventually hardened, rebranded builds of important third party apps widely used by our community.

2024-07-21 01:45:23

- reply

AppVerifier was based on a planned GrapheneOS feature for users to verify APK files based on their key fingerprint. The feature is currently stalled since relying on the clipboard isn't ideal. For now, users can use AppVerifier from Accrescent until we ship a built-in approach.

2024-07-21 01:38:44

- reply

Lead dev of Accrescent is a GrapheneOS user and contributor. It'll be a good place to publish apps for GrapheneOS users. AppVerifier, BeauTyXT and Transcribro are from the same person who wrote our Info app. Molly is a security-focused fork of Signal from another GrapheneOS user.

2024-07-21 01:25:20

- reply

Accrescent is in alpha and isn't yet open to any developers uploading their apps. It will have a lot more apps available in the future. It will become a full alternative to Play Store permitting closed source apps too, but you'll be able to filter to show only open source apps.

2024-07-21 01:22:22

GrapheneOS App Store now includes a mirror of Accrescent, which is a privacy and security focused alternative to the Play Store distributing developer builds of apps:
https://accrescent.app/
Accrescent comes from within the GrapheneOS community and we're collaborating together.

2024-07-20 19:17:23

- reply

We've been shown a screenshot of the newer documentation showing they support iOS 17.5.1 and the iPhone 15.
We aren't able to confirm the authenticity of this screenshot yet, but this is what someone shared with us:
https://i.imgur.com/WpuUNGh.png
We'll see if our sources can obtain the newer documentation for us and we'll make a new thread with the updated information.
We'll reply here again when we get the newer documentation from a more reliable source than this.

2024-07-20 06:16:13

- reply

Cellebrite falling behind a few months doesn't mean data won't be extracted from a device.
They'll catch up and then the device can be exploited. iOS and regular Android don't have a way to get the device from AFU back to BFU automatically.
Additionally, they may figure out a way to bypassing the secure element throttling eventually and then suddenly devices which have been kept around for years can have the lock method brute forced.
Cellebrite also isn't the only option.

2024-07-20 06:13:31

- reply

They have already expanded it since the April 2024 docs which we published in May. It's unfortunate that's being treated as if it's a current reference for capabilities in July 2024. It moves quickly. They lose capabilities regularly and need to update or replace their exploits. It's not static.
The April 2024 docs cover what the stable release of Cellebrite Premium could do at that snapshot in time, not what they had already developed and were preparing to release.

2024-07-20 06:10:51

- reply

You can see they needed to request an in-development version to extract data from this phone which implies that there were changes since April 2024 for Samsung devices and perhaps Android as a whole. They regularly lose capabilities from new devices and OS versions. They're always in the process of updating or replacing exploits. It's not specific to iOS.

2024-07-20 06:06:55

- reply

You should look at Cellebrite's tables from April 2024 and you can estimate what they would have done in the past few months in terms of adding support for newer OS versions. The leaked documentation is from April 2024 for the stable release of Cellebrite Premium, not what they had in development or have shipped since then. It's not up-to-date information. Some of what they use got patched by iOS so they were a bit behind. It's July now, not April, so it's not current info.

2024-07-20 06:04:29

- reply

We're talking about 2 different things:
1) iPhone 12 and later / Pixel 6 and later are successfully preventing Cellebrite from brute forcing even a random 6 digit PIN via their secure element, but they've bypassed it by exploiting the secure element on earlier devices
2) The can usually exploit nearly the most recent iOS or Android on nearly any device, either BFU or AFU. They tend to fall behind a few months if vulnerabilities either get patched or the OS just changes a lot.

2024-07-19 18:51:25

- reply

GrapheneOS zero-on-free features appear to stop that data from being kept around after unlock. However, it would be nice to know what's being kept around. It's not the password since they have to brute force so it must be the initial scrypt-derived key or one of the hashes of it.

2024-07-19 18:51:19

- reply

In Cellebrite's docs, they show they can extract the iOS lock method from memory on an After First Unlock device after exploiting it, so the opt-in data classes for keeping data at rest when locked don't really work. XRY used a similar issue in their now blocked Android exploit.

2024-07-19 18:51:15

- reply

In April, Pixels added a reset attack mitigation feature based on our proposal ruling out the class of vulnerability being used by XRY.
In June, Pixels added support for wipe-without-reboot based on our proposal to prevent device admin app wiping bypass being used by XRY.

2024-07-19 18:51:09

- reply

It would be a lot more helpful if people leaked the current code for Cellebrite, Graykey and XRY to us. We'll report all of the Android vulnerabilities they use whether or not they can be used against GrapheneOS. We can also make suggestions on how to fix vulnerability classes.

2024-07-19 18:51:06

- reply

We received Cellebrite's April 2024 Android and iOS support documents in April and from another source in May before publishing it. Someone else shared those and more documents on our forum. It didn't help us improve GrapheneOS, but it's good to know what we're doing is working.

2024-07-19 18:51:00

- reply

The person who shared it with 404media is one of our community members. We regularly get sent this kind of information. In the case of XRY from MSAB, we were able to report several Android vulnerabilities based on their docs which are now fixed on Pixels but not elsewhere yet.

2024-07-19 18:50:54

- reply

The detailed Android table showing the same info as iPhones for Pixels wasn't included in the article. Other news publications appear to be ignoring the leaked docs and our thread linked by 404media with more detail. They're only paraphrasing that article and making assumptions.

2024-07-19 18:50:50

- reply

404media published an article about the leaked documentation this week but it doesn't go into depth analyzing the leaked information as we did, but it didn't make any major errors. Many news publications are now writing highly inaccurate articles about it following that coverage.

2024-07-19 18:50:39

- reply

Cellebrite was a few months behind on supporting the latest iOS versions. It's common for them to fall a few months behind for the latest iOS and quarterly/yearly Android releases. They've had April, May, June and July to advance further. It's wrong to assume it didn't change.

2024-07-19 18:50:32

We published the Cellebrite Premium documentation from April 2024 in May 2024:
https://grapheneos.social/@GrapheneOS/1124627562935861
Our thread properly explains the info in the tables including their inability to exploit Pixel 6 or later secure element and only partially bypass it on iPhone 12 or later.

2024-07-19 17:23:28

- reply

An interesting part of it is that the iPhone data classes for keeping data at rest while locked don't work since Cellebrite has an exploit for obtaining the lock method as part of an exploiting an AFU device, which they mark as IPR in the table.
It's likely they've partially caught up on iOS version support since April 2024. They may be fully caught up. It's strange to present it as if they would have done absolutely nothing through April, May, June and now part of July.

2024-07-19 17:21:59

- reply

What the documentation shows is that in April 2024, Cellebrite had working exploits for nearly all Android and iOS devices but was currently a couple months behind on supporting iOS versions.
It also showed they could not yet bypass secure element throttling on the iPhone 12 or later / Pixel 6 or later but had bypassed it on earlier versions Pixels added it with the Pixel 2 and iPhones also added it a long time ago, and that didn't hold up against them over the long term.

2024-07-19 17:19:36

- reply

This is where the Cellebrite Premium documentation from April 2024 was originally published in May, showing all of the tables instead of selectively choosing them:
https://grapheneos.social/@GrapheneOS/112462756293586146
That shows each table, not only select ones, and properly explains it.
News publications only cared after 404media published an article this week, but their article didn't cover much about what's in it and it's several months later now. Other news sites have done made inaccurate coverage.

2024-07-19 17:09:54

- reply

It's strange that this article is presenting leaked Cellebrite documentation about iOS from April 2024 as still being fully applicable in July 2024. Certain iOS and Android updates cause their existing exploits to stop working. That doesn't mean they don't port them to newer versions or develop new exploits. It's several months after April already.
Their article about the leaked info is also very wrong and misunderstands several things including lack of old device support.

2024-07-19 17:00:28

- reply

SPL refers to security patch level. FFS refers to extracting data from an already unlocked device where they have the lock method already. FBE refers to filesystem-based full disk encryption as opposed to block-based full disk encryption. FBE has finer-grained keys and Android uses it to have certain data outside of the profiles and per-profile keys. GrapheneOS plans to improve how FBE works.

2024-07-19 01:48:29

GrapheneOS App Store version 24 released:
https://github.com/GrapheneOS/AppStore/releases/tag/24
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/14278-grapheneos-app-store-version-24-released
#GrapheneOS #privacy #security #android #repository

2024-07-18 23:52:12

- reply

Cellebrite Premium (Cellebrite), XRY (MSAB) and Graykey (Magnet Forensics) are the major players with tools available to law enforcement, intelligence agencies, etc. around the world. US government intelligence agencies would normally have far more capabilities than these standard tools. These are very widely accessible tools so it's entirely possible for Apple/Google to repeatedly get their hands on them and fix all the vulnerabilities. We don't know if they do it.

2024-07-18 23:50:13

- reply

This information is from April 2024 so it's not the latest information on their exploits. It's also only for Cellebrite Premium, not overall security against forensic data extraction tools. For example, MSAB was using a firmware-based Pixel exploit which was mitigated by GrapheneOS. We figured out what they were doing from a documentation video, reported it to Google in January and it was prevented in April so MSAB likely lost non-FFS Pixel capabilities in April 2024.

2024-07-18 23:45:52

- reply

Pixel 6 and later moved from the Titan M1 to the Titan M2. iPhone 12 hardened the secure element brute force protection against exploitation. The tables show these have held up well, but the earlier secure elements in iPhones and Pixels were eventually exploited. If someone wants their data protected for years into the future, they should probably use a strong passphrase.
They were behind a few months on iOS versions in April 2024. They may not be behind anymore.

2024-07-18 23:43:43

- reply

GrapheneOS has a default enabled auto-reboot feature which starts a timer after the device is locked and reboots it if the timer elapses before the next successful unlock. The default is 18 hours to avoid causing any reboots for most users, but users can set it as low as 10 minutes or as high as 72 hours.
There's a table in Cellebrite documentation specifically for Pixels comparable to the iPhone table which includes GrapheneOS. Look here:
https://grapheneos.social/@GrapheneOS/112462758257739953