• Announcements
  • Claims made by forensics companies, their capabilities, and how GrapheneOS fares

Hathaway_Noa Thank you for your contributions to the community and the enlightening info you provided. Do you know how supersonic BF differs from regular BF on iOS?

    matchboxbananasynergy 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.

    So this feels like a dumb question. But I fail to see -- probably due to my lack of technical understanding -- how that is supposed to be noteworthy (by XRY and Cellebrite)? It just sounds like the equivalent of "we have the key to the door so we're able to enter and look around". Like no shit Sherlock. Am I missing something vital here or is this just marketing fluff?

      This is very fascinating! Since the graphic shows a list of phones with stock OS, and a table with GrapheneOS specifically, does this mean that GrapheneOS is the only alternative OS that can be a match against XRY and Cellebrite? I know very well that the GrapheneOS team is doing amazing security work, but to see it like this? It seems like XRY/Cellebrite is threatened by the existence of GrapheneOS 😄

        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?

            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.

            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?