An interesting and useful read. Sending you massive thanks for your hard work. 😊
GrapheneOS a new contributor we plan to hire.
Congratulations, fredu!
Claims made by forensics companies, their capabilities, and how GrapheneOS fares
DeletedUser29 How that is supposed to be noteworthy (by XRY and Cellebrite)?
It's one thing for somebody to have a way to extract data from a phone. For the data to be used in court proceedings it is important to claim a chain of custody from the device as obtained by law enforcement to the screen shot (or other evidence) appearing in testimony. If an officer testifies that a generally-accepted tool was used, that helps.
stereo3441 Cellebrite says Supersonic Brute Force is about 40x faster than the traditional brute force speed.
This news makes me glad I swapped my SIM back to my Pixel 8 running GrapheneOS.
OnePlus does a really good job with hardware but OxygenOS is kinda gimmicky and OnePlus phones are too big anyways.
Great read and thanks for sharing.
I know you stated that mitigating full filesystem extraction via (most likeky) ADB is not planned nor in focus right now, but wouldnt locking developer options (or at least ADB) behind a seperate, secure element protected, password be a viable option.
This would protect people in a scenario where either Pin was snoopped or the Phone snatched unlocked.
If these companies can make a full extraction of the devices when having access to the password why isnt it possible for us/seedvault to have a built a full backup solution that can do the same for us users also that includes full backup of apps and settings which is flagging against that?
Awesome as always
CatPaw Enabling developer options on Android is already gated by the main lock method. That's part of why it shouldn't be enabled in production, so that it's still gated behind the password. We also put configuring system backups behind the password in the same way with a downstream change.
JayJay It does do full backups. Turn on device-to-device backup mode.
- Edited
DeletedUser29 They can extract more data than you're meant to be able to extract via ADB by escalating privileges there, but having the lock method already gives them nearly all the data directly by design unless there's no backup service included to get app data. They can access everything you can access once they have your lock method which at least indirectly gives them nearly all the data even without a backup service. Regardless, once they have the lock method, the attack surface is enormous and it's not very realistic to stop them at that point. They can install whatever apps they want, grant any permissions they want including special access permissions, accessibility services, etc. and a few development permissions only available via ADB. It isn't at all realistic to prevent an exploit by someone with that control over the device already. Secondary users that are at rest have their data safe from them based on the security of the lock method similarly to Owner when the device is at rest since their encryption keys are separate.
Panda-na Other alternate operating systems aren't hardened and largely roll back security rather than improving it. DivestOS applies a portion of our privacy/security patches, but on top of LineageOS which rolls back security and DivestOS is focused on insecure devices. Cellebrite may still need to do some work in order to support them but it would generally be much easier for them compared to exploiting a stock OS device, not harder.
Wow. Thank you so much for all of the amazing work that goes into this project, seriously!
Not just on the technical side, but the clear and concise communication of best practices, exploit updates, changelogs, community involvement, etc.
I'm constantly blown away by the holistic approach you take and how well its all communicated. I don't know of many projects that are as consistent, and of high quality as GrapheneOS in this department.
I need to get around to setting up Monero so I can begin donating.👌
matchboxbananasynergy 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.
While I believe in transparency, if refraining from publishing original information protects sources and allows further improvements to GrapheneOS based on real-world exploits I think that is an acceptable tradeoff.
Question if it is ok to ask: I see in the "Android OS Access Support Matrix" that GrapheneOS is supported for BFU and AFU "up to late 2022 SPL". Is it known exactly what vulnerability was patched around that time?
I'm guessing that for AFU they're trying to exploit the running OS to gain code execution and/or read memory. However what are the implications of exploiting a device in BFU state? Because if my understanding is correct there is a limited amount of metadata or other information available in BFU up for grabs and the rest is protected by FBE which requires deriving the hardware backed encryption keys in conjunction with the users unlock password.
Hathaway_Noa Thank you for your service.
That site was rather difficult to download from. Is it ok with you if I mirror it somewhere that is hopefully less annoying and we can crosscheck the hashes of the files?
popsicleman Of course
Question if it is ok to ask: I see in the "Android OS Access Support Matrix" that GrapheneOS is supported for BFU and AFU "up to late 2022 SPL". Is it known exactly what vulnerability was patched around that time?
No, we don't know what exactly was patched or improved either upstream or in GrapheneOS which blocked their exploits. We do know they weren't able to find another way to exploit GrapheneOS since then, which is great news. We recently implemented massive security improvements including the USB-C port control feature and previously memory tagging after the launch of the Pixel 8 so it should be much harder than it was before to exploit GrapheneOS. We also got those improvements made to the Pixel firmware upstream in April, and there are more improvements based on our reports pending right now.
I'm guessing that for AFU they're trying to exploit the running OS to gain code execution and/or read memory. However what are the implications of exploiting a device in BFU state? Because if my understanding is correct there is a limited amount of metadata or other information available in BFU up for grabs and the rest is protected by FBE which requires deriving the hardware backed encryption keys in conjunction with the users unlock password.
They need the BFU exploit to do a brute force of the lock method, but they can't currently do it on the Pixel 6 or later even with older releases due to the Titan M2 throttling. There's some info such as installed apps they can get there. We could provide the option of a boot passphrase since the current encryption is really filesystem-based full disk encryption and does encrypt every block similar to dm-crypt. There's a global key for metadata and then per-directory keys for file data and filenames which is how profile data is encrypted separately. We COULD provide support for setting a boot passphrase for encrypting the pre-unlock data such as installed APKs, Wi-Fi configuration, etc. along with the metadata blocks with file sizes. It's simply not one of the top priorities right now.
Pixels have had this throttling (Weaver) with the same rate limiting since the Pixel 2 added it via an NXP security chip alongside insider attack protection by requiring Owner authentication before accepting a signed firmware upgrade that's not a downgrade (see https://grapheneos.org/faq#encryption for details on Weaver). It appears they were able to eventually figure out how to exploit the NXP secure element on the Pixel 2 and were able to eventually exploit the ARM-based Titan M on 3rd/4th/5th generation Pixels. The fully custom RIXC-V Titan M2 introduced with the Tensor SoC Pixels has held up against them for years, and it appears similar for the other forensic companies based on the info we have. We do still recommend people who need their data secure indefinitely use a strong passphrase, and we're going to be making that a long more convenient via the 2-factor fingerprint unlock feature. Strong passphrase primary unlock with fingerprint+PIN secondary unlock will be the recommendation for high threat models, with the usual random 6 digit PIN recommendation as a baseline.
Hi, I want to ask when you say latest iphones are you talking about the iphone 15 lineup or 14 as well?
Hathaway_Noa Let's give Proton Drive a try.
https://drive.proton.me/urls/MJ52832388#xmW6MebZC0DJ
SHA256 hashes (please crosscheck for authenticity):
952db145ab34af68d51e5040cac4389cb99b31a41512dd93c905ad7baf2d4c21 Android+Support+Matrix+7.69.1.pdf
a44f88e65b6bc24f46ff08329c6eca0ec5acfcd968e48634acf76b10b32ab7d9 Cellebrite_InseyetsOfflineUFED_UserManual_v10.2_April_2024.zip
b3fc85e1daf2cd98c9fce61cdf0947af5c8ebd5c5e11b9b13326d8ab65f567fc Inseyets+UFED_ReleaseNote_10.2.pdf.zip
6446ee8a33e6b60e7060bcb8985a3c06ff7da24c98a1274e5c49f555f260aa24 Triage+Profile+Management+Offline+Tool+Guide.pdf
d9317473de82985f8f16e7f649441c390ee0b09319760ed1ceb826a7eb0c452c iOS+Support+Matrix+7.69.1.pdf- Edited
Turtle12345 Look at the iPhone/iPad tables from the screenshots of the documentation we've provided:
It's only the latest device generation and OS versions which aren't fully supported yet.
17.4 was released in March and this documentation is from April meaning it doesn't reflect improvements they made in April and May. Less than a month is not enough time to draw any conclusion that they have any major issues with 17.4. You can see that they have support for earlier releases shipping soon for everything but the iPhone 15, which has been out for enough time to give the impression that it must be at least somewhat harder for them to deal with it or it simply changed a lot of things they need to adapt to.
matchboxbananasynergy
Says pixel 6 and later, does this include 6a as it's not as powerful as the pixel 6?
Thanks
FiscalPixel Pixel 6a is a 6th generation Pixel, so it applies to it too.