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.



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.


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.

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

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.

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.




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.

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.

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.

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.

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.

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

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.

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.


This post is also available on social media platforms as a thread:

X: https://x.com/GrapheneOS/status/1815102487965348324
Mastodon: https://grapheneos.social/@GrapheneOS/112826067364945164
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kxt3462oxi2y


Previous thread based on April 2024 documentation with a large amount of discussion and answered questions: https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/164 (locked to move new discussion here)

    Thanks for the new slides and the write up. We all appreciate it.

    Thanks!
    By the way, will there be a complete PDF file of the support matrix + release notes + user manual distributed like in May?

      I don't understand Polish, but when I watched the video at the following URL using the translation function, I remember hearing the following statement by a man:

      "Control Center must be enabled in order to use Premium to extract data from the iPhone in a hot state (AFU)."

      Does this mean that Premium uses a vulnerability in Control Center to access RAM?

      Video URL:
      https://www.youtube.com/watch?v=8iY9PIHfnFQ

        • [deleted]

        • Edited

        It is intriguing to observe that they have ceased displaying their IPR (instant passcode recovery) capabilities. According to the April document, we are aware that Cellebrite can perform IPR on iOS versions up to 17.0.3 and iPhone models up to 14. Is there any information available regarding whether Cellebrite can conduct IPR on newer iOS versions or iPhone 15/iPad?

          • [deleted]

          orangecola There could be a bug in the control center, or it's possible that he is simply utilizing the control center availability to distinguish between AFU and BFU mode. Additional information is required to further clarify the situation.

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

          Will it be possible to use a PIN instead of a passphrase for the primary unlock method?

            • [deleted]

            Does this mean that newest iPads are not safe?

              horde Pixel (GrapheneOS) devices are protected from https://oxygenforensics.com/en/resources/extract-and-decrypt-android-keystore/ ?

              That article lists two extraction approaches.

              One approach relies on the device being unlocked, or on adb being enabled and available. The GrapheneOS project frequently warns users against leaving debugging on, especially wireless debugging, on the grounds that it increases attack surface (it does).

              The other approach is described as working for certain hardware types, not including Pixels. This is consistent with other information that Pixels, especially if up to date on patches, are more difficult to exploit. Again this is consistent with the project's insistence that at present the Pixel platform is the only platform with sufficient hardware security plus the ability for third-party OSs to effectively use that security.

              Though I am not an expert on the Android Keystore, based on what I see in that piece, a GrapheneOS device that is up to date and configured in accordance with recommendations (e.g., USB and wireless debugging off), is likely not subject to the described key extraction.

              [deleted] The latest iPhones and iPads can be exploited by Cellebrite. They're likely going to continue keeping up with the latest iOS versions and new hardware models unless there's a major change to how they function. They sometimes have a couple months of delay for certain new Android and iOS versions when they have to update their exploits for major changes or replace them completely.

                Lukas You'll be able to do that, but the intended purpose is making it possible to use a strong passphrase while having the convenience of fingerprint unlock + short PIN for secondary unlock.

                [deleted] It's likely simply implied by AFU exploitation capability on iOS. If they lose the capability on newer iOS versions they may start listing where they have it again.

                orangecola we don't have access to the iOS and Android support matrix documents at the moment because it's what we requested from one of our sources. We didn't ask for the rest. We don't plan to publish the documents ourselves anymore, but there was a user on our forum who published the extended documentation before and they may do it again.