According to media reports it seems that iPhone resets if it has no connection to mobile network for some time. Typically that is in a case when iPhone is stored in forensic bag.

However, if that is true, there could be workaround for that. Police should just present the phones some fake network (without internet connectivity, no SMS and no calls), and iPhone will have access to network (however, there will be no further network connectivity), and will not reboot itself?

We don't know if this would be a workaround, however GrapheneOS's option to autoreboot at specific time interval when screen is not unlocked, seems much better option.

    Matthai Last night I removed the case from my iPhone to clean it, and I turned it a little in all directions to put it back, he asked me for my password after putting it back, so I wonder if by turning my phone in all directions he must have believed that I had it stolen or something like that

        Matthai According to media reports it seems that iPhone resets if it has no connection to mobile network for some time.

        According to this report, it's just a timer:

        The reboot timer is not reliant on charging or network functions, and is only tied to inactivity since the last unlock.

        Edit: A timer would be simpler and more secure, so hopefully any report claiming network coverage is involved would be detailed and would report on experiments.

          Guillaume no, it just tried to scan a face and failed twice. Completely normal for every FaceID enabled iPhone.

            Matthai The police speculation and the news stories about it were wrong. There is nothing rebooting the devices automatically for iOS 18 and earlier. iOS 18.1 added an auto-reboot timer similar to the one we've used since June 2021. iOS 18.1 was released on October 28th. Their auto-reboot timer is 4 days. There's no way that most of the devices police are complaining about are on iOS 18.1 and clearly not all are since some of the info is about clearly older devices. They were also talking about them rebooting in batches, etc. despite being locked at different times. It is likely that what happened is a few newly obtained iOS 18.1 devices rebooted and then that triggered a bunch of speculation and inaccurate reports leadijng to the news stories.

                21 days later

                Is Pixel 9 more secure against attacks like Cellebrite compared to Pixel 8? Of course both running GrapheneOS. I wonder if it's worth buying the Pixel 9, I'm only interested in the security against authoritarian states. Not better camera or whatever.

                Thanks to everyone working for GrapheneOS!

                  Pixel 8 and Pixel 9 both have Memory Tagging Extension, because they are running Arm v9 CPUs.

                  Arm Memory Tagging Extension (MTE) was introduced in Arm v9, and is a hardware feature in CPUs designed to improve software security by detecting memory-related vulnerabilities.

                  MTE helps catch two common memory vulnerabilities - Use-After-Free vulnerabilities, when a program tries to use memory that has already been freed, and buffer overflow vulnerabilities, when a program writes more data than allocated to a memory block.

                  Memory safety has been a major source of security vulnerabilities for decades. Studies suggest that over 75 percent of vulnerabilities in Android are violations of memory safety.

                  So I guess if you buy Pixel 8 or 9, you will be pretty secure with GrapheneOS.

                  Hi GrapheneOS I've been on GOS for near two years, and by next week will have flashed my 200th Pixel with GOS for clients. And I am just so greatful for GOS, but also for how you guys share information such as above. Just wanted to say thank you to the team for all you do for we the people. "Privacy is Dead! Long Live Privacy!"

                  VAULT

                    vmpas Pixel 9 has some security improvements but not a large improvement over the Pixel 8. Pixel 8 and later is a massive improvement over the prior devices when using GrapheneOS due to hardware memory tagging. Pointer authentication codes (PAC) and branch target identification (BTI) are nice minor features. PAC could be much more heavily integrated but currently isn't and MTE is far more valuable. MTE is a far better long term approach if they increased the tag sizes. PAC is a short term approach and requires a lot of case-by-case integration to get much value out of it.

                        18 days later

                        GrapheneOS

                        There are still a few things unclear to me.

                        1. If FFS = Full Filesystem Extraction from an unlocked device, then what does BF: NO, FFS: YES suggest. They can extract filessystem without unlocking it or not?

                        2. Assuming BF: YES in AFU still has rate limits as you state it does, can you assume that a 6 digit pin would take long enough to crack that it would go over the GrapheneOS default 18 hours to reset to BFU / iOS 18.2 default 72 hours?

                        3. Why do they even list FFS in unlocked devices? Can't you do whatever you want to an unlocked device or am I missing something?

                            On iPhone 12-14 with iOS 17.5-17.5.1 does AFU mean that if it's in AFU mode they can unlock the phone?

                              stopthefeds

                              FFS refers to extracting data when they have the PIN/password to unlock it already. Having an unlocked device doesn't mean you can extract all of the data from it. Their tool requires unlocking, enabling developer options (requires authentication), enabling ADB, authorizing ADB access from their tool and then uses unintended functionality in ADB to extract all of the data. FFS is their baseline capability which generally works everywhere as long as the user doesn't have a device admin app disabling ADB. They could far more easily exploit the OS after unlocking it but those aren't the kinds of exploits done by the Cellebrite Premium tool and would require something else.

                              BF refers to brute force attacks after they've exploited the devices, which implies also exploiting the secure element on devices providing throttling with one.

                                stopthefeds AFU means they can exploit the device in AFU and obtain nearly all the data from it even without the BF capability. They have a capability not listed in this table called IPR which was listed for previous versions of the table which enables them to obtain the PIN/password for iOS when they have the AFU capability. It's possible they support this on each version with AFU support now so they stopped listing it. The details of IPR are unclear and it seems it only works when the memory hasn't been reused for something else. It's definitely not supposed to be possible but iOS was or still is making a mistake enabling it. It may be fixed by now.

                                    stopthefeds Does closing a user profile put that profile back into BFU? Or it stays unencrypted?

                                    Closing a secondary user profile unloads the encryption key, making all its data inaccessible, so is in some sense equivalent to BFU. But traces from the activity in that user profile may still exist, such as in system wide log files. Rebooting the device is the only way to be sure. Rebooting is also the only way to unload the encryption key for the owner profile or private space.

                                    BFU (before first unlock) refers to a device that is powered off, or that has been powered on without any valid credentials yet provided at all. Rebooting or powering off the device is the only way to return it to BFU state.

                                      stopthefeds It's back at rest in terms of the disk encryption. However, data can persist in memory in parts of the kernel, SystemUI, system_server and other system-wide software such as driver services. Our zero-on-free implementation in the kernel and userspace helps clear data as soon as possible but it won't clear something that's not released. @ryrona mentioned the in-memory log buffer which is one example. No sensitive data is supposed to be logged there but not all apps will respect that and the interpretation of what that means varies throughout the OS and apps. It's not the only example, just one of them. If you want to get back to a clean BFU state, you inherently need to reboot.