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

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

                    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]

                        • Post #32

                        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.

                              [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!