Specification-compliant BLE advertisements contain little information that can be used for proximity estimation. We assume that theApple and Google exposure notification API uses advertisements nonetheless (applegooglebt), because they preserve battery and limit RCE risks. When receiving an advertisement, the chip measures the RSSI and includes it in the advertisement report before forwarding it to the operating system. This behavior is specification-compliant and does not need any further modifications (bt52, p. 2382). There are multiple ways to enhance proximity measurements. For example, one could include the sender’s transmission power in the advertisements (applegooglebt, p. 4). The transmission power directly influences the RSSI on the receiver. Not all chips can be set to the same transmission power, and thus, RSSI measurements need to be adjusted on the receiver.
We find that Apple’s Bluetooth PacketLogger goes beyond the Bluetooth specification and displays the channel, antenna, and scan mode of each advertisement—but this information is always set to zero. Further investigation reveals that this information can be enabled with a firmware-internal global variable. As shown in Figure 1, the advertisements are not modified, as the information is measured on the receiver. In the most recent version of InternalBlue (mantz2019internalblue), this feature can be activated with the adv command.
Information about the advertisement channel is valuable, as the RSSI varies depending on the channel. The three advertisement channels are spread across the spectrum. Thus, typical interference sources such as a Wi-Fi access point can easily be evaded by blacklisting the interfered channel without taking statistics on multiple advertisements over time.
|Apr 15 17:19:28:281||HCI Event||CA:FE:BA:BE:13:37||
LE - Advertising Report - 1 Report - Normal - Random - CA:FE:BA:BE:13:37
-56 dBm - Channel 37
|Parameter Length: 30 (0x1E)|
|Num Reports: 0x01|
Event Type: Scan Mode: Normal Scan Mode - Channel 37 - Antenna: BT
- Connectable Undirected Advertising (ADV_IND)
|RSSI: -56 dBm|
|Apr 15 17:19:28:281||HCI Event||00000000: 3E1E 0201 0001 3713 BEBA FECA ...|
2. Reverse-Engineering Proprietary Advertisement Features
We use two methods to reverse-engineer vendor-specific additions to the BLE advertisement handler. First, we analyze which information the PacketLogger is using to display the channel in Section 2.1. Based on this information, we analyze the Broadcom and Cypress firmware to enable the output of this information in Section 2.2.
The PacketLogger is included in the Additional Tools for Xcode on macOS. It features similar functions as Wireshark but is specifically designed for Bluetooth in the Apple ecosystem. Thus, it supports various proprietary protocols and features that are a helpful starting point for reverse-engineering. These protocols are otherwise undocumented. We assume that Apple uses the PacketLogger for developing protocols and debugging and, thus, intentionally includes information about these protocols in their toolchain.
Table 1 shows a BLE advertisement as captured on macOS Catalina with PacketLogger. Note that by default all advertisements are displayed to be on channel 37, even though they are also received on channels 38 and 39. However, this indicates that there are some means of channel interpretation that are not included in specification-compliant advertisement reports (bt52, p. 2382).
The PacketLogger binary is located in PacketLogger.app/Contents/Frameworks/PacketDecoder.framework/Versions/A/PacketDecoder. It contains all the strings displayed within the PacketLogger and also most function names, which enables an analysis with IDA Pro 7.2. A search for the string ‘Channel’, as it can be seen in the PacketLogger output, leads to the function leAdvertisingEventTypeString. This function prints the antenna, channel, and scan mode, which are encoded into the upper half byte of the event type as shown in 1. This is possible because the event type is , but Bluetooth specification only defines the values 0x00–0x04 (bt52, p. 2383). The channel values 0x0–0x2 correspond to the Bluetooth channels 37–39. Thus, without this feature enabled on the chip, the channel is always interpreted as 37 by PacketLogger.
Note that the Bluetooth specification defines an extended advertisement report (bt52, p. 2402). However, this report type also does not contain channel information.
2.2. Bluetooth Firmware
The PacketLogger reverse-engineering only indicates that additional event types exist. They still need to be enabled within the firmware. For the firmware analysis, we dump firmware from a selection of chips with InternalBlue. WICED Studio 6.2 contains partial symbols for various Cypress chips as well as the Broadcom BCM20703A2 chip that is in MacBooks produced in 2016 and 2017.
The firmware is organized in tasks that are called by the BCS. The scan task is responsible for receiving advertisements. In general, packet reception tasks are separated into receiving a header and receiving the according payload. The channel is already known when receiving a header, and thus, if bEnhancedAdvReport is set, additional information is copied from the raw packet data into ulp_extraInfo.
While tasks need to be finished within the strict timings of the Bluetooth clock, handlers asynchronously parse task data and pass it on to the host’s operating system driver. In the case of an advertisement, this handler is lculp_HandleScanReport. The prefix lculp stands for link control in the ultra-low-power protocol, namely BLE. The advertisement handler copies the additional information into the event_type field if bEnhancedAdvReport is set.
Searching for the variable name bEnhancedAdvReport is only possible within a firmware that has partial symbols. However, symbols for most off-the-shelf devices are unknown. Nonetheless, hardware registers are mapped similarly over various firmware generations. Also, the architecture is typically an ARM Cortex M, and compiler options are similar. Thus, we can search for equal and snippets, which only return a few results within each firmware, to identify the scan task handler across multiple firmware versions. In our case, the scan task handler disassembly includes the line mov.w r0, #0x650000, which is a instruction represented by 0x00caf44f, and that we used for manual binary diffing.
We find that the comparably old Nexus 5 firmware with a build date from 2012 does not feature the bEnhancedAdvReport flag. However, the Cypress evaluation boards CYW20719, CYW20735, and CYW20819 support it, as well as the MacBook 2016–2017 chip BCM20703A2, the MacBook 2017–2019 chip BCM4364B0, and the Samsung Galaxy S10/S20 chip BCM4375B1. We assume that this feature was introduced by Broadcom around 2014 and all newer chips support it. While our InternalBlue-based setup can only enable this feature for research, Broadcom could also roll it out as a patch for a broad variety of devices.
The channel reporting within BLE advertisements can be enabled with a single flag on most Broadcom and Cypress chips. This makes the patch rather simple, as it only needs to set the flag to 0x01. Future practical tests within contact tracing will show how much channel awareness can improve proximity measurements. Further physical-layer properties might also be available during advertisement reception. However, we did not spot any additional advertisement flags during the reverse-engineering process. Thus, more complex patches are required for further physical-layer insights.
This demo consists of an InternalBlue addition that enables the enhanced event type within advertisements on various Broadcom and Cypress chips. InternalBlue runs on Android, Linux, macOS, and iOS. Thus, the demo can be tested on various devices, as long as they have a supported chip.
is open-source and available onhttps://github.com/seemoo-lab/internalblue. The extended advertisements can be activated by running the command adv. After enabling the enhanced advertisements with adv and opening Wireshark, the event type field in advertisements contains the masked channel, antenna, and scan mode information.
To show this demo, we will provide a video of receiving the enhanced event type on a Cypress CYW20819 evaluation board on Linux. On the Linux BlueZ stack, advertisements can be received by executing hcitool lescan.
Moreover, the video will show the workflow of reverse-engineering PacketLogger to identify the field where the channel information is included, as depicted in Figure 2. Then, we will search for this field in a partially symbolized Cypress firmware. This part of the demo will help other researchers to identify similar proprietary features.