Always-on Processor magic: How Find My works while iPhone is powered off


Update: We wrote a paper with even more technical details :)

iOS 15.0 introduces a new feature: an iPhone can be located with Find My even while the iPhone is turned "off". How does it work? Is it a security concern?

I saw this feature rather early on one of my iPhones with an iOS 15 beta. Here's a screenshot I took in July. The user interface changed a little bit since then.

It took a bit longer until the public realized this feature exists. One needs to update to iOS 15.0, use an iPhone that has location services enabled, a logged in user account, participates in the Find My network, etc. And the weirdest thing nobody does these days: One has to turn the iPhone off. But once Twitter found out, this took off. And so did the rumors how this was implemented.




Apple's Always-on Processor (AOP)

There's only little public documentation about the AOP. All chips and various embedded devices Apple manufactures run a real-time operating system, called RTKitOS. The AOP on the iPhone is no exception. However, the AOP has a special role. It connects to almost every other chip in the iPhone. For some chips, it only does basic tasks like power management, and for other chips, it acts as a transparent proxy that wakes up iOS when needed.

This way, a processor that is always on actually saves energy. iOS can go to sleep while the AOP waits for hardware events. A simple example is the motion sensor. Without touching any button on the iPhone, the display wakes up.


A quick Internet search reveals that even Siri is implemented in the AOP. If you're not too much into technical details, you can skip the remainder of this section and just need to know that the AOP also connects to wireless chips and their power management interfaces :)

Most iOS kernel drivers follow a simple structure. If a chip is running RTKitOS, this is visible in the ioreg output. For example Rose, the U1 Ultra-wideband chip, shows up in this list.


While this is in the iOS kernel, the AOP implements a copy of these drivers. For example, U1 ranging has a duplicate implementation that works without the nearbyd and can run standalone within the AOP.

Even if a chip is not based on RTKitOS, the AOP can connect to it. The Bluetooth chip in the iPhone 11, 12 and 13 is by Broadcom and based on the ThreadX operating system. Nonetheless, the iPhone AOP has some control over Bluetooth. While not following the same RTKitOS-based scheme, it can power the Bluetooth chip using the spmi-bluetooth driver.

Note that this is very different from the HomePod mini and Watch. They both use Apple's own Bluetooth chip, codenamed Marconi. The AOP can control Marconi using the marconi-bluetooth and aop-marconi-bt-control drivers.

Edit after this was discussed on Twitter: The fact that the AOP can control Bluetooth power does not necessarily mean that the AOP is on while the iPhone is "off". I assumed that this is the case, but there are also other means to do this, such as the power controller according to @marcan42. The power controller connects to Bluetooth, Wi-Fi, GPS, NFC, and more. Also, NFC in an iPhone supports running without iOS for the express card feature.

Running a Bluetooth application while the iPhone is "off"

All the iPhone needs to have Find My enabled while it is "off" is some basic power control as well as a Bluetooth chip that can send Bluetooth LE advertisements. Moreover, these advertisements require secret key material bound to the Apple ID on the iPhone.

Broadcom chips are very similar to Cypress chips. The Cypress SDKs support standalone IoT applications, which only require the Bluetooth chip and no additional host. These applications run in the ThreadX thread called mpaf. Let's check if there's an mpaf thread somewhere in the Bluetooth firmware. For this, download the iOS 15.0 IPSW, mount the largest .dmg file, and browse to /usr/share/firmware/bluetooth. The .bin files are patches loaded via the Bluetooth PCIe driver. Since the iPhone 11, these contain a few debug strings. Running grep mpaf * reveals the following device compatibility list.
  • iPhone 11 series, BCM4378B1 (Hei, Moana, Tala)
  • iPhone 12 series, BCM4387C2 (Almond, Cashew, Hazelnut, Pistachio)
  • iPhone 13 series, BCM4387C2 (Acacia, Camellia, Lilac, Mimosa)
  • iPad Air 2020 series, BCM4387C2 (Pomegranate)
  • Some other iPad series, BCM4387C2 (Baobab, Boab, Rambutan)
Interestingly, the iPhone SE 2020, which also has the BCM4378B1 chip and is codenamed Fiti, does not have an mpaf patch. I updated an iPad Air 2020 to iOS 15.0, and despite the patches for Pomegranate, the Find My dialogue is not shown. There's also no location update for the iPad in another iPhone logged into the same account. So there might be a difference in currently supported devices and chips that could in theory support this feature. Apple could add further devices in the future.

The mpaf patch implements a lpm app, which probably stands for low-power mode, that implements a Bluetooth LE gatt service. This can all be found in the strings, and plonk actually saw this before I saw it.

tier2/Olympic/PCIE/Pistachio_CLPC_OS/USI/bld/A_4387C2_ROM/tier2/patch/bcs/mpaf_layer_patch.o.patch2.c
tier2/Olympic/PCIE/Pistachio_CLPC_OS/USI/bld/A_4387C2_ROM/tier2/patch/mpaf/apps/lpm/lpm_app.o.patch2.c
tier2/Olympic/PCIE/Pistachio_CLPC_OS/USI/bld/A_4387C2_ROM/tier2/patch/mpaf/apps/lpm/lpm_app_gatt.o.patch2.c
tier2/Olympic/PCIE/Pistachio_CLPC_OS/USI/bld/A_4387C2_ROM/tier2/patch/mpaf/apps/lpm/lpm_app_fsm.o.patch2.c

These patches were introduced in iOS 15 and not present before. The naming matches the expected functionality. To keep this blog post short and answer your questions early, this blog post doesn't contain instructions on how to analyze these patches, dump the chip's ROM etc. Strings are enough to confirm that this feature is implemented in the Bluetooth chip.

Is the secret key material related to the U1 chip?



On the AirTag, this key material is stored via the U1 chip. Apple calls the nRF on the AirTag "Durian" for a reason. They don't like it, they don't trust it, but it's cheap and low-power. Most time, U1 is on sleep, and from time to time they wake it up.

This is not the design on the iPhone. On the iPhone, keys are stored in the Secure Enclave (SE). Some early U1 build even had debug strings for U1 and the SE exchanging key material, but these are gone in recent builds. So, the little bird is right when it comes to the AirTag, but not the iPhone.

Secret key material transfer

After installing a Bluetooth debug profile to an iPhone 12 on iOS 15.1b2, the idevicesyslog output looks as follows just before shutdown:

Sep 30 22:02:58 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:58 bluetoothd[89] <Notice>: BlueTool finished running "hci reset" command - output was "0x0e 0x04 0x01 0x03 0x0c 0x00"

...

Sep 30 22:02:58 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:58 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x06 ..." command - output was "<decode: missing data>"

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x06 ..." command - output was "<decode: missing data>"

Sep 30 22:02:59 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x06 ..." command - output was "<decode: missing data>"

Sep 30 22:02:59 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x06 ..." command - output was "<decode: missing data>"

Sep 30 22:02:59 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x06 ..." command - output was "<decode: missing data>"

Sep 30 22:02:59 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x07 0x00 0x01" command - output was "0x0e 0x05 ..."

Sep 30 22:02:59 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "bcm -s 0x0f,0x00,0x02,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00" command - output was ""

Sep 30 22:02:59 BlueTool[126] <Notice>: Completed handling of dictionary-xpc event

Sep 30 22:02:59 bluetoothd[89] <Notice>: BlueTool finished running "hci cmd 0xFE62 0x04" command - output was "0x0e 0x05 0x01 0x62 0xfe 0x00 0x04"

Sep 30 22:02:59 backboardd(libEDR)[66] <Notice>: ScheduleSetBrightnessIn_block_invoke: enter WaitUntil late 0.126834 millisecond (333 / 333)

Sep 30 22:02:59 backboardd[66] <Notice>: brightness change:0.67814 reason:BrightnessSystemDidChange options:<private>

Sep 30 22:02:59 SpringBoard(FrontBoard)[62] <Notice>: Shutdown task "NotifyBluetooth" complete after 1.59s

Sep 30 22:02:59 SpringBoard(CoreUtils)[62] <Notice>: Invalidate CID 0x2B760001

Sep 30 22:02:59 SpringBoard(FrontBoard)[62] <Notice>: Shutdown tasks complete.

Sep 30 22:02:59 SpringBoard(CoreUtils)[62] <Notice>: Invalidated

Sep 30 22:02:59 bluetoothd[89] <Notice>: BT_FW_OK flag is set. Entering LPM...

Sep 30 22:02:59 bluetoothd(CoreUtils)[89] <Notice>: LPM entry took 1578ms

Sep 30 22:02:59 bluetoothd[89] <Notice>: Sending BT Stats to CoreAnalytics for com.apple.BTLpmManagerStats

Sep 30 22:02:59 bluetoothd[89] <Notice>: PowerManager power state is 0

Sep 30 22:02:59 bluetoothd[89] <Notice>: PowerManager power state is 0

Sep 30 22:02:59 bluetoothd[89] <Notice>: PowerManager power state is 0

Sep 30 22:02:59 bluetoothd[89] <Notice>: PowerManager power state is 0

[disconnected]

The last steps are repeated multiple times and with a lot of random looking numbers. These are the beacons being configured on the Bluetooth chip. Thus, I redacted them from this post. Then, finally, the Bluetooth chip tells that it goes into the low-power mode (LPM). Immediately after the iPhone turns "off".

Each Find My advertisement starts with 0x4c 0x00 0x12 0x19, and this byte sequence is also contained in the BlueTool output. Overall, there are 80 advertisements written to the Bluetooth chip. I did not analyze how long the time interval for each advertisement is, but it's likely not the default 15 minutes and a larger interval instead.

In case you want to debug this on your own, the HCI reset is the last information visible in Apple's PacketLogger, while the idevicesyslog still shows BlueTool output and commands.

Temporarily disabling Bluetooth low-power mode

Another question by @reni_ni was if flight mode disables Bluetooth LPM. Thanks for this question, and another update to this blog post. When Bluetooth is deactivated via the Settings menu (Settings app → Bluetooth → Off), this disables Find My as well as the LPM feature. 


Note that Bluetooth is not necessarily off in flight mode. There are two "Bluetooth off" symbols, and only the second icon indicates that Bluetooth is off. Always use the Settings app to be sure you entered the correct mode.



When disabling Bluetooth like this, the idevicesyslog output indicates that not only the iOS Bluetooth stack is paused, but also LPM is disabled.

Oct  3 15:53:31 bluetoothd[89] <Notice>: LPMManager::stackWillStop


Upon turning off the iPhone, it will no longer show that Find My is enabled after turning it off, and the idevicesyslog output indicates that LPM will be disabled when turning the iPhone off.

Oct  3 15:55:39 bluetoothd[89] <Notice>: LPMManager::powerManagementEventSystemWillShutDown

Oct  3 15:55:39 bluetoothd[89] <Notice>: LPMManager::powerManagementEventSystemWillShutDown fOfflineADVDataPending = true

Oct  3 15:55:39 bluetoothd[89] <Notice>: Triggering LPM

Oct  3 15:55:39 bluetoothd[89] <Error>: lpmFlag is not enabled. Failed to enter LPM.

Oct  3 15:55:39 bluetoothd(CoreUtils)[89] <Notice>: LPM entry took 6ms

Security and privacy impact

The new Find My feature is the first time that a large public got aware of the AOP as well as the possibility of a Bluetooth chip running autonomously.

Assuming that someone hacked your iPhone and spies on you, they might as well show a correct "power off" screen and then not turn the iPhone off. Never trust a device to be off, until you removed its battery or even better put it into a Blender. For example, the Samsung TV was hacked by the NSA including a Fake-Off mode to spy on people. 

The Find My protocol has a couple of interesting mechanisms to protect your privacy. It has been fully reverse-engineered and there's an open-source implementation. Moreover, the AirGuard app enables you to identify Find My BLE beacons on Android. If you're afraid about locations leaking via Find My, you can simply disable it on your iPhone.

Be aware that other wireless chips also leak location information. The cellular baseband makes it possible to locate you and your mobile provider can keep a location history, Wi-Fi leaks your location as well even though MAC address randomization helps, and more. A smartphone is a human tracking device, no matter what. Privacy protections in Find My only eliminate one possible tracking aspect out of many.

The scariest part might be that the maybe the AOP and definitely NFC and Bluetooth LPM enable a new vector of hardware persistence. Broadcom Bluetooth firmware is not signed. Thus, an attacker with control over an iPhone can craft and install Bluetooth LPM malware. Since LPM is a hardware-based feature, there is no way to disable LPM on a potentially hacked device.

Comments

  1. UnknownOctober 7, 2021 at 7:11 PM

    I did not analyze how long the time interval for each advertisement is, but it's likely not the default 15 minutes and a larger interval instead.

    --the find my BLE advertuisement will change per 24 hours.

    ReplyDelete
    Replies
    1. jiskaOctober 8, 2021 at 4:01 AM

      Good to know :) So it's the same as on AirTags.

      Delete

Post a Comment

Popular posts from this blog

Reverse Engineering iOS 18 Inactivity Reboot

Image
Reverse Engineering iOS 18 Inactivity Reboot iOS 18 introduced a new inactivity reboot security feature. What does it protect from and how does it work? This blog post covers all the details down to a kernel extension and the Secure Enclave Processor. Security Before First Unlock / After First Unlock Did you know that entering your passcode for the first time after your phone starts is something very different then entering it later on to unlock your phone? When initially entering your passcode, this unlocks a key store in the Secure Enclave Processor (SEP) that encrypts your data on an iPhone. The state before entering your passcode for the first time is also called Before First Unlock (BFU). Due to the encrypted user data, your iPhone behaves slightly differently to later unlocks. You'll see that Face ID and Touch ID won't work and that the passcode is required. But there's more subtle things you might notice: Since Wi-Fi passwords are encrypted, your iPhone won't co
Read more

BlueZ: Linux Bluetooth Stack Overview

Image
Found some time for another Bluetooth rant :) This time it's going to be about BlueZ , the Linux Bluetooth stack. Note that there are other Bluetooth stacks for Linux such as BTstack , but I didn't find the time to play around with these, and BlueZ is still what you get these days if you install a normal Linux distribution. This is my view on about BlueZ and a couple of things might be over-simplified. Feel free to add comments to this post if anything is wrong or is better explained elsewhere. However, I found that there is no good overview from a programming and hacking perspective, and often times I get questions about patching certain things within InternalBlue that have a root cause deep down in the Linux kernel. BlueZ is missing documentation. In fact, I ended up using dynamic debugging here and there to understand which functions are still called and which are deprecated. Otherwise, this blog post would not be needed for an open-source project m) Linux Bluetooth stack vs
Read more