[deleted] They probably just haven't shipped the functionality in Cellebrite Premium yet.

What does "FFS Yes, BF No" mean for stock OS Pixel in AFU? Do they get access to all user data unencrypted without the need to brute force the password?

    Thank you for providing the screenshots, although make sure the source is not compromised as it'd be nice to see them in future. I suggest rewriting table manually, there are fingerprinting methods available :P But i'm sure you are aware.

    It's very surprising to see that they have some sort of patent for newest iOS, i thought that recent iOS AFU unlocks were more like exception than normal thing. It seems that these devices can't be widely considered unlock-safe anymore.

    As part of my final year work, I tested Cellebrite against a Pixel 4A phone with GrapheneOS... it was incredibly underwhelming. I'll just say the results were very basic, nothing very useful. I didn't have access to XRY, though.

    jellybean BFU refers to exploiting a device Before First Unlock. BF refers to whether they can brute force lock methods after BFU exploits., which they cannot for Pixel 6 or later / iPhone 12 or later due to the more hardened secure elements. AFU refers to exploiting a device After First Unlock, which obtains access to nearly all the data.

    Added a glossary with terms used in the documentation to the end of the post.

    Upstate1618 There are no exploits for encryption involved in this. Windows and desktop Linux distributions along with typical laptop/desktop hardware are extremely more vulnerable to these kinds of exploits. macOS on modern Mac hardware is not as protected against this as an iPhone but certainly more than those.

      • [deleted]

      GrapheneOS Is there a simple explanation of why computers are considered less secure, and more vulnerable to attacks than mobile devices?

      • de0u replied to this.

        [deleted] Is there a simple explanation of why computers are considered less secure, and more vulnerable to attacks than mobile devices?

        To sone extent it's cultural. People are used to buying a new phone every couple of years, so there are more refresh cycles and more opportunities to change things. Also, phones are easier to steal. And, unlike desktop machines, which were for "professionals" for a long time, the smartphone audience (since 2007) has rapidly become "everybody".

        There is no fundamental reason, but it takes a long time to upgrade legacy stuff that "works", when many individual things must be changed.

        • Edited

        [deleted] Is there a simple explanation of why computers are considered less secure, and more vulnerable to attacks than mobile devices?

        Here's a timely example: Secure Boot is completely broken on 200+ models from 5 big device makers.

        In the mobile world I am aware of this mistake being made by Fairphone, but not a major vendor, whereas apparently in the PC world the doofus factor has been non-trivial. Note that GrapheneOS has, as the article notes is best practice, a different signing key for each device type.

          de0u Secure boot on desktops/laptops generally trusts an enormous number of keys for the firmware and doesn't have any rollback protection. It also doesn't usually verify all the firmware, only portions of it. There's privileged firmware not covered by it. The fact that you can swap the CPU between motherboards, etc. on a desktop prevents having proper early secure boot, as does the overall mess of the ecosystem. The firmware is also highly insecure in practice. Verification of the OS is only done by verifying the kernel, and again it's usually against a huge list of keys. It never supports downgrade protection. TPMs are either an insecure emulated firmware feature (fTPM) as part of the badly secured firmware or an insecure discrete chip without authenticated encryption pairing it with the SoC. TPM APIs are horrible and not comparable to the proper secure elements in an iPhone or Pixel. That's only a tiny portion of the overall mess. Desktop operating systems have awful privacy/security, lacking basic exploit protections, app sandboxing, sandboxing throughout the OS, etc. It's the norm to not have proper firmware and driver updates there. Firmware update situation is even worse for desktop Linux where available updates are even less likely to be available to install. Motherboard / TPM firmware updates often require wiping all the data stored by those and can't be automated. Features like reset attack mitigation are missing or incorrectly implemented so operating systems can't try to use them. It's far more of a mess than that and we don't want to go into much more than this.

          Macs have addressed nearly all these issues other than the OS being fundamentally less secure mainly due to lacking mandatory app sandboxing, a comparably strong app sandbox and having much weaker, barely useful verified boot. They're not far from turning macOS into being comparable to at least older iOS security but are very much held back by backwards compatibility and the lack of interest in a lot of their ecosystem in adopting optional features that are mandatory for iOS.

            One of Fairphone's mistakes was using the AOSP test verified boot key with a publicly available private key as the ONLY supported key for verified boot, which is quite a lot worse in terms of their mistake compared to desktop/server motherboard vendors trusting a key compromised in the past when they're supposed to trust hundreds or thousands of keys because the whole system is broken. If they hadn't made that mistake, it would still be a useless, insecure feature unlike mobile verified boot which is very useful and at least provides a way to purge all malware with high confidence via factory reset even if the OS still has too much trust in persistent state.

            GrapheneOS [...] It's far more of a mess than that and we don't want to go into much more than this.

            That's quite a bit of mess. Thanks!

            About Cellebrite AFU capabilities on latest iphones

            They can bypass phone lock method on all iphones ?

            What if lockdown mode is enabled or if the iphone enter in usb restricted mode after an hour ? AFU exploit is still working ?

            How supersonic BF is possible on iphone XR/XS/11 ? couple years ago checkm8 team found a flaw on secure enclave (up to iphone X) and apparently Apple did the job to remove the flaw on new iphones

              no BF on Pixel 2 ? is the hardware magic compare to Pixel 3/4/5 ?

                Onion Pixel 2 has an off-the-shelf NXP secure element which is likely far less secure than the Titan M1. You're misinterpreting lack of capability as more security but that's not what it means. They likely started caring a lot about Pixels much later and never dedicated the resources to dealing with the Pixel 2 secure element. Pixel 3 through 5a have the same Titan M1 secure element. Pixel 2 is a separate thing, and while likely much easier to exploit is only 2 devices which had far lower sales than more recent Pixels and are hardly used by anyone anymore. If they had a real reason to deal with it, they likely could do it and without as much trouble as later Pixels.

                Onion Yes, they can bypass the phone being locked and gain control of the OS. Lockdown mode doesn't seem to block them or they'd mention the limitation since this is documentation on using Cellebrite Premium. It's not meant for public consumption and is not marketing material, although their ability to exploit most devices does end up marketing their products simply by publishing it since they're doing a good job keeping up. They probably don't mind us posting it much.

                How supersonic BF is possible on iphone XR/XS/11 ? couple years ago checkm8 team found a flaw on secure enclave (up to iphone X) and apparently Apple did the job to remove the flaw on new iphones

                There's no sign of Apple preventing exploitation of the secure element. iPhone 12 and later added an additional layer of security for the brute force protection. The main portion of the secure element is probably still getting exploited, it just doesn't bypass this. Cellebrite could therefore still bypass most of the secure element features but they have no need for it.

                  GrapheneOS If Cellebrite bypasses the locked phone, can they access the passwords in Keychain on iPhone ?

                    racoondog They have the capability of getting the lock method from an iOS device when they exploit it After First Unlock, although it doesn't always work, but when it does there's nothing they can't get. They can also exploit the secure element and just can't bypass the encryption brute force limits due to another layer inside it. It's possible they can obtain that even if the IPR capability for getting the lock method fails and brute forcing can't be done.