Always-on Processor magic: How Find My works while iPhone is powered off
source link: https://naehrdine.blogspot.com/2021/09/always-on-processor-magic-how-find-my.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Always-on Processor magic: How Find My works while iPhone is powered off
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 :)Running a Bluetooth application while the iPhone is "off"
- 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)
Is the secret key material related to the U1 chip?
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 shuts "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.
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.
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 AOP and Bluetooth LPM enable a new vector of hardware persistence.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK