• GeneralPixel 6a
  • Unsubstantiated claims about Cellebrite contradicted by Cellebrite

We will need a source, preferably the documents you are referring to, to be able to discuss this further.

    • [deleted]

    I am not a private investigator and a language specialist. But many among us know what chances are of unlocking a Pixel 6+ in AFU even with 4+ sized PIN. Close to zero. Unless the poor sod chose something easy to guess.

    • [deleted]

    Rarry what is your aim with this?

    Rarry Thanks, I don't understand swedish so for now, I look at the pictures.

    On a friendly note, and I think everyone here will agree, don't behave like an idiot and do anything stupid that could harm you, don't assume you're above the law, GrapheneOS like other tools are there to help us regain a better control over our digital lives, not to help harmful behavior. I'm not talking about journalists, whistle-blowers and innocent people arrested unjustly.

      Xtreix I don't know if you misunderstood, I don't appear in these files/documents only downloaded from the court, very interested to read such documents

        Rarry Only the "thanks" is addressed to you, the long comment is just a general note :)

          Rarry

          This link contains 16pdf files. Could you please link us to which document and page you are referring to?

          Its not easy to discuss foreign language files otherwise if we are supposed to translate and search in all 16 ourselves.

          GrapheneOS changed the title to Unsubstantiated claims about Cellebrite contradicted by Cellebrite .

          This thread is presenting extracting data from devices after entering the correct lock method as unlocking them which is not accurate and it's going to be removed. No evidence of what was claimed was provided, and it contradicts what has been previously made available to us last month.

          Cellebrite's official documentation as of April 2024 states they cannot even exploit GrapheneOS devices in either BFU or AFU mode to obtain anything from them. They're only able to exploit much older releases before the late 2022 security patch levels. They also state that they have no secure element exploit for the Pixel 6 or later, even with the oldest patch levels. The only functionality Cellebrite claims to offer is extracting the whole filesystem with the lock method provided to them. No evidence has been provided of what was claimed in the title and initial post.

          de0u The only functionality Cellebrite offers with GrapheneOS is performing a full filesystem extraction after the correct lock method is provided and the device is unlocked with it. The only working exploits they have since after the late 2022 patch levels are privilege escalation after being granted ADB access which is a very minor problem and not an impressive capability. For the stock OS, they say that they can exploit both BFU and AFU but cannot bypass the secure element brute force protection on the Pixel 6 or later even with the oldest Pixel 6 firmware without security patches. If people don't want to depend on them not successfully exploiting the secure element, they can use a random 6+ word diceware passphrase instead of a random 6-8 digit PIN.

            GrapheneOS The only functionality Cellebrite offers with GrapheneOS is performing a full filesystem extraction after the correct lock method is provided and the device is unlocked with it.

            This is good to know. Thanks for clearly explaining the situation.

            Rarry I can read Swedish, but you need to point to specific page numbers. The documents are 1000+ pages long.

            In any case, the GrapheneOS account has already clarified the situation around Cellebrite.

            flighty_sloth Their documentation says they can exploit all major Android OEM devices both BFU and AFU. If they're BFU, data in profiles is at rest and they need to brute force to obtain it. It says they cannot do a brute force on the Pixel 6 and later but can on all the other listed brands, since they apparently haven't been able to exploit the Titan M2 even for older versions. Their documentation also states they cannot exploit GrapheneOS either BFU or AFU except devices with a patch level earlier than late 2022. This documentation is listing capabilities rather than explaining why anything is the way it is, so we don't know that. We don't have any reason to think they're either exaggerating or understating their capabilities in these official docs.

            Being able to brute force only means they can brute force at the rate the device is able to do key derivation unless they have a way to extract the hardware bound key or this part of it wasn't properly implemented. Pixel 3 and later added time-based throttling based on the secure element, which Cellebrite apparently hasn't been able to defeat for the Pixel 6 and later even for older releases.

            We don't know much about what other forensic companies can do or what governments have developed themselves, but we have access to Cellebrite's official list of capabilities for law enforcement, governments, etc. as of April 2024. It indicates to us that we were much more successful than we expected at defeating their attacks even before our recent focus on it since around January after we found out about the MSAB/XRY use of a fastboot mode firmware vulnerability.

            Fastboot mode attack surface for recovering data from the OS in AFU mode was eliminated in the April security update due to us reporting it being exploited in the wild with a proposal on how to prevent doing it. Ideally, memory would be encrypted with a per-boot key in the SoC both to greatly raise the bar for extracting data from it and so that it gets purged on reboot by simply rotating a key instead of having to actively wipe it. We hear some other companies were using this too. We did not receive any info which would indicate that they were able to use this attack method against GrapheneOS, but we were very concerned about that possibility which is why we pushed hard to get it addressed in the firmware instead of depending on attempting to work around it in the OS or depending on our auto-reboot feature.