A new attack tamper with the firmware and loads malware on a Bluetooth chip while the iPhone is turned off


A first-of-its-kind security analysis of iOS Find My function has identified a novel attack surface that makes it possible to tamper with the firmware and load malware onto a Bluetooth chip that’s executed while an iPhone is “off.”

The mechanism takes advantage of the fact that wireless chips related to Bluetooth, Near-field communication (NFC), and ultra-wideband (UWB) continue to operate while iOS is shut down when entering a “power reserve” Low Power Mode (LPM).

While this is done so as to enable features like Find My and facilitate Express Card transactions, all the three wireless chips have direct access to the secure element, academics from the Secure Mobile Networking Lab (SEEMOO) at the Technical University of Darmstadt said in a paper entitled “Evil Never Sleeps.”

“The Bluetooth and UWB chips are hardwired to the Secure Element (SE) in the NFC chip, storing secrets that should be available in LPM,” the researchers said.

“Since LPM support is implemented in hardware, it cannot be removed by changing software components. As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown. This poses a new threat model.”

“LPM [Low Power Mode] support is implemented in hardware. The Power Management Unit (PMU) can turn on chips individually. The Bluetooth and UWB chips are hardwired to the Secure Element (SE) in the NFC chip, storing secrets that should be available in LPM. Since LPM support is implemented in hardware, it cannot be removed by changing software components.” reads the paper published by the researchers. “As a result, on modern iPhones, wireless chips can no longer be trusted to be turned off after shutdown. This poses a new threat model. Previous work only considered that journalists are not safe against espionage when enabling airplane mode in case their smartphones were compromised.

The current LPM implementation on Apple iPhones is opaque and adds new threats. Since LPM support is based on the iPhone’s hardware, it cannot be removed with system updates. Thus, it has a long-lasting effect on the overall iOS security model.” concludes the paper. “To the best of our knowledge, we are the first who looked into undocumented LPM features introduced in iOS 15 and uncover various issues. Design of LPM features seems to be mostly driven by functionality, without considering threats outside of the intended applications. Find My after power off turns shutdown iPhones into tracking devices by design, and the implementation within the Bluetooth firmware is not secured against manipulation. Tracking properties could stealthily be changed by attackers with system-level access.”

The findings are set to be presented at the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec 2022) this week.

The LPM features, newly introduced last year with iOS 15, make it possible to track lost devices using the Find My network even when run out of battery power or have been shut off. Current devices with Ultra-wideband support include iPhone 11, iPhone 12, and iPhone 13.

A message displayed when turning off iPhones reads thus: “iPhone remains findable after power off. Find My helps you locate this iPhone when it is lost or stolen, even when it is in power reserve mode or when powered off.”


Calling the current LPM implementation “opaque,” the researchers not only sometimes observed failures when initializing Find My advertisements during power off, effectively contradicting the aforementioned message, they also found that the Bluetooth firmware is neither signed nor encrypted.

By taking advantage of this loophole, an adversary with privileged access can create malware that’s capable of being executed on an iPhone Bluetooth chip even when it’s powered off.

However, for such a firmware compromise to happen, the attacker must be able to communicate to the firmware via the operating system, modify the firmware image, or gain code execution on an LPM-enabled chip over-the-air by exploiting flaws such as BrakTooth.

Put differently, the idea is to alter the LPM application thread to embed malware, such as those that could alert the malicious actor of a victim’s Find My Bluetooth broadcasts, enabling the threat actor to keep remote tabs on the target.

“Instead of changing existing functionality, they could also add completely new features,” SEEMOO researchers pointed out, adding they responsibly disclosed all the issues to Apple, but that the tech giant “had no feedback.”

With LPM-related features taking a more stealthier approach to carrying out its intended use cases, SEEMOO called on Apple to include a hardware-based switch to disconnect the battery so as to alleviate any surveillance concerns that could arise out of firmware-level attacks.

“Since LPM support is based on the iPhone’s hardware, it cannot be removed with system updates,” the researchers said. “Thus, it has a long-lasting effect on the overall iOS security model.”

“Design of LPM features seems to be mostly driven by functionality, without considering threats outside of the intended applications. Find My after power off turns shutdown iPhones into tracking devices by design, and the implementation within the Bluetooth firmware is not secured against manipulation.”

Bluetooth Classic (BT) protocol is a widely used wireless protocol in laptops, handheld devices, and audio devices. BT main procedures are shown in Figure 1 for reference. In the past few years, Bluetooth has come under scrutiny due to the discovery of several critical vulnerabilities. In this report, we disclose BrakTooth , a family of new security vulnerabilities in commercial BT stacks that range from denial of service (DoS) via firmware crashes and deadlocks in commodity hardware to arbitrary code execution (ACE) in certain IoTs. We have evaluated 13 BT devices from 11 vendors. We have discovered a total of 16 new security vulnerabilities, with 25 common vulnerability exposures (CVEs) already assigned and two (2) are pending CVE assignment from Intel.

All the vulnerabilities are already reported to the respective vendors, with several vulnerabilities already patched and the rest being in the process of replication and patching. Moreover, four of the BrakTooth vulnerabilities have received bug bounty from Espressif System and Xiaomi. An exploration on Bluetooth listing  [33] reveals that BrakTooth affects over 1400 product listings. BrakTooth exposes fundamental attack vectors in the closed BT stack.

As the BT stack is often shared across many products, it is highly probable that many other products (beyond the 1400 entries observed in Bluetooth listing) are affected by BrakTooth. Therefore, we suggest vendors producing BT system-on-chips (SoCs), BT modules or BT end products to use the BrakTooth proof-of-concept (PoC) code to validate their BT stack implementation. The availability of the BrakTooth PoC is discussed at the end of this report.


Figure 1: An Illustration of the BT connection procedure.
FHS stands for Frequency Hopping Synchronization, ID stands for Identity, LMP stands for Link Manager Protocol and ACL stands for Asynchronous Connection Less.

Why BrakTooth

The code name BrakTooth is the combination of two words: 1) Brak and 2) Tooth. While the word Tooth is clearly pointing towards Bluetooth targets, the word Brak is Norwegian and translates to crash in English. The BrakTooth family of vulnerabilities affect Bluetooth enabled devices by continuously crashing or deadlocking them, while some result in more serious consequences such as arbitrary code execution.

Attack Scenario Overview


Figure 2: An Illustration of BrakTooth attack scenario

Figure 2 showcases the generic scenario in which BrakTooth attacks are performed. The attacker only requires (1) a cheap ESP32 development kit (ESP-WROVER-KIT  [38]) with a custom (non-compliant) LMP firmware and (2) a PC to run the PoC tool. The PoC tool communicates with the ESP32 board via serial port (/dev/ttyUSB1) and launches the attacks according to the specified target BDAddress (<target bdaddr>) and exploit name parameter (<exploit_name>).

Furthermore, the PoC tool logs over-the-air (OTA) packets and checks the health of the target by getting a paging timeout (no response) or alternatively getting status directly from the target via a serial port, ssh connection, etc.

Due to some vendors having a fixed release schedule, we will release the Proof of Concept (PoC) tool publicly only at the end of October 2021. This is the time when we expect most vendors to have released their patches. In the meantime, any BT semiconductor or module vendor can acquire the PoC by filling up a simple form at the BrakTooth PoC website.

Affected BT BR/EDR chipsets

Table 1: Devices used for evaluation. The sample code is provided by vendor to test the development board. This is not applicable (N.A) on products running a fixed application.

A summary of BrakTooth appears in Table 2. In each row, we use the prefix to identify a security vulnerability and to indicate an anomalous behaviour (i.e., faulty target responses) that deviates from the Core Specifications  [32]. Moreover, Table 2 outlines the respective CVEs, affected devices, protocol layers, and the violated compliance. In summary, we discovered 16 new security vulnerabilities. For all the discovered vulnerabilities, we have followed a responsible disclosure process. Specifically, we have reached out to the affected vendors and we have provided them at least 90 days until the public disclosure of this report. In most cases, we have also actively helped the vendors to reproduce the reported attacks at their end. Several vendors (e.g. Cypress, Bluetrum, Espressif) have already produced patches with many in the process of producing them (e.g. Qualcomm, Intel). The status of patches is discussed in Section 5.

The impact of our discovered vulnerabilities is categorized into (I) crashes and (II) deadlocksCrashes generally trigger a fatal assertion, segmentation faults due to a buffer or heap overflow within the SoC firmware. Deadlocks, in contrast, lead the target device to a condition in which no further BT communication is possible. This may happen due to the paging scan being forcibly disabled (V16), state machine corruption on V6 or entirely disabling BT functionality via arbitrary code execution (ACE) on V1. Our results affect popular BT vendors (i.e, Intel, Qualcomm, Cypress, Texas Instruments) and relatively less known (i.e., Bluetrum, Jieli Technology, Harman), which are still employed in many consumers products such as BT speakers, keyboards, toys, etc.

V1 affects ESP32, which is used in many products ranging from consumer electronics to industrial equipment such as programmable logic controllers (PLCs). Hence, the impact is significant, as the attacker only requires knowledge of the target BDAddress to launch the attack. Indeed, all the vulnerabilities V1-V16 can be triggered without any previous pairing or authentication. Moreover, the impact of V1-V16 reaches beyond the devices listed in Table 2, since any other BT product employing an affected SoC is also vulnerable.

Multiple Link Manager Protocol (LMP) flooding attacks (e.g., V4V12) and V15 were detected across SoCs from different BT vendors. Since the affected vendors are majors in their fields (i.e., Intel & Qualcomm), it indicates that there is a lack of flexible tools for over-the-air testing even in 2021. Besides, the Core Specifications only allows a limited “LMP test mode”  [32] that restricts the SoC to operate with few LMP procedures.

Impact of BrakTooth

We created different concrete attacks leveraging the BrakTooth vulnerabilities. In the following, we show three such sample attacks that launch arbitrary code execution (ACE) or Denial of Service (DoS) on target devices.

4.1 Arbitrary Code Execution in IoTs

The most critical vulnerability (V1 in Table 2 – 8.1) affects ESP32 SoC  [37], which is used in many Wi-Fi and Bluetooth IoT appliances such as Industry Automation, Smart Home, Fitness, etc. The attack is illustrated in Figure 3. A lack of out-of-bounds check in ESP32 BT Library  [11] allows the reception of a mutated LMP_feature_response_ext. This results in the injection of eight bytes of arbitrary data outside the bounds of Extended Feature Page Table (“E. Features Table” in Figure 3). An attacker, which knows the firmware layout of a target device, can write a known function address (JMP Addr.) to the offset pointed by Features Page (“Feat. Page” in the LMP_feature_response_ext packet) field. It turns out that the BT Library stores some callback pointers within the out-of-bounds Features Page offset and such a callback is eventually invoked during the BT connection. While exploiting this vulnerability, we forced ESP32 into erasing its NVRAM data (normally written during product manufacturing) by setting JMP Addr. to the address of nvs_flash_erase. Such erase function is always included in ESP32 SDK  [9] and therefore, it is present in any ESP32 firmware. Similarly, disabling BT or BLE can be done via esp_bt_controller_disable and Wi-Fi via disable_wifi_agc. Additionally, general-purpose input/output (GPIO) can be controlled if the attacker knows addresses to functions controlling actuators attached to ESP32. As expected, this has serious implications if such an attack is applied to Bluetooth-enabled Smart Home products.


Figure 3: An Illustration of CVE-2021-28138.

4.2 DoS in Laptops & Smartphones

We discuss two sample DoS attacks discovered on laptops and smartphones employing Intel AX200 SoCs  [20] and Qualcomm WCN3990 SoC  [34]. Due to the number of smartphones and laptops vulnerable to such attacks, and the common use of BT connectivity during video conference calls and music streaming, updating the affected devices is essential.

The first DoS (Invalid Timing Accuracy – 8.15) is due to a failure in the SoC to free resources upon receiving an invalid LMP_timing_accuracy_response from a BT slave. The attacker can exhaust the SoC by (a) paging, (b) sending the malformed packet, and (c) disconnecting without sending LMP_detach. These steps are repeated with a different BT address (i.e., BDAddress) until the SoC is exhausted from accepting new connections. On exhaustion, the SoC fails to recover itself and disrupts current active connections, triggering firmware crashes sporadically. This vulnerability allows an attacker to forcibly disconnect slave BT devices currently connected to AX200 under Windows or Linux Laptops. Similarly, Android phones such as Pocophone F1 and Oppo Reno 5G  [26] experience BT disruptions. For example, users connected to BT Headsets experience audio to be continuously “cut” during the attack. This also results in firmware crashes and restart of Android BT Service. In all cases, the OS tries to recover connectivity which can be continuously disrupted.

The second DoS (Paging Scan Disable – 8.16) affects only devices using Intel AX200 and it is triggered when an oversized LMP_timing_accuracy_request (>17 bytes) is sent to AX200 slave. This temporarily corrupts AX200 firmware, which responds incorrectly during a subsequent BT connection and eventually disables the paging scan procedure (cf., Figure 1). Thus, scanning AX200 works, but no connection is established from an external BT device. Therefore, this attack can be used to trick an user to connect to the attacker’s BT hardware instead of the legitimate target since AX200 paging scan is disabled. Indeed, the user needs to manually re-enable BT to restore functionality. The attack is also used to disconnect certain master BT devices connected to a vulnerable Laptop. This leads to sporadic BT firmware crashes.


4.3 Freezing Audio Products

Many vulnerabilities were discovered while testing with a BT Speaker (Mi Portable Bluetooth Speaker – MDZ-36-DB  [42]), BT Headphone (JBL TUNE 500BT  [21]) and BT Audio Modules (XY-WRBT  [29] and an unbranded BT Audio Receiver). The discovered vulnerabilities arise from failures when sending oversized LMP packets (LMP Auto Rate Overflow – 8.5), truncated packets (Truncated LMP Accepted – 8.8), starting procedures out-of-order (Invalid Setup Complete – 8.9) and finally by flooding LMP packets (Feature Response Flooding – 8.4).

The vulnerabilities can “freeze” Xiaomi MDZ-36-DB and completely shut down JBL TUNE 500BT. This requires the user to manually turn on the unresponsive devices. Since both devices accept multiple BT connections, an attack can be triggered while the user is playing some music. As an exception, XY-WRBT and BT Audio Receiver accept only one connection, which avoids an attack to be launched during an active BT connection with the user. Nevertheless, different products employing the same SoC may enable multiple BT connections depending on the product requirements.

Although issues were found in SoCs targeted to Audio products, the BT Implementation can be reused in a number of SoCs destined to different BT products. Hence, our discoveries are not limited to the type of products discussed in this section, but rather to the LMP stack implementation.

4.4 Estimating the Scope of BrakTooth

In this section, we measure the potential impact of BrakTooth vulnerabilities. To this end, we estimate the number of product listings employing the affected BT chipsets. Each listing may contain one or multiple (up to hundreds) products from the same company. We get such an estimated number by querying the Bluetooth Listings Website  [33]. In particular, we use the qualification IDs (QIDs) of each affected SoCs to get their corresponding products listings. The total number of potentially affected product listings is illustrated in Table 3. In summary, as of August 23, 2021, the total number of listings affected is over 1400. We note that even if the number of listings for a major vendor such as Intel seems low, its listings have up to hundreds of product models referenced by popular PC brands such as HP, Asustek, Dell, etc.Table 3: Number of product listings with respect to BT SoC.

It is worthwhile to mention that while we can get the total number of registered products within Bluetooth Listings website for a certain chipset QID, it only reveals a lower-bound of the exact total number of listings employing a particular chipset. This is because product vendors may choose to customize the design. In this case, the QID of the employed chipset or BT stack is written to a field called Combined Designs. Unfortunately, the Bluetooth Listings site do not cross-reference Combined Designs when searching for a QID, which makes it almost impossible to get the total number of products employing a particular chipset. Furthermore, products employing modules derived from chipsets such as ESP32, CSR8811, etc are also not shown during the search of a chipset QID.

In conclusion, the total number of individual product models that are potentially affected by BrakTooth could be an order of magnitude higher than the listings estimated in Table 3.Table 4: Sample products using SoCs affected by BrakTooth. The declaration ID references each product on the Bluetooth Listing search website  [33].

From the listings shown in Table 3, we capture some interesting products employing the vulnerable chipsets and list them in Table 4. The observed types of products range from audio appliances (BT Speakers, headsets, ambience, etc) to personal PC/laptop computers, smartphones, and surprisingly even automotive multimedia electronic control units (PMP3), automotive infotainment systems (Volvo FH) and in-flight audio systems such as AMU6500. Notably Volvo FH and AMU6500 are employing Qualcomm CSR8811/510 and Silabs WT32i chipsets, respectively. As discussed in Section 5, the Qualcomm CSR8811/510 is unlikely to receive a patch (affected by V6) and we are not able to receive a response from Silicon Labs regarding their status of the investigation on Silabs WT32i (affected by V5).

4.5 Product Design Considerations

It is important to clarify that any product employing a vulnerable Bluetooth chipset, is not necessarily insecure (nevertheless, affected due to BT connectivity being impaired). The overall security of an end-product, which has an internal chipset with firmware flaws, depends on how much the product relies on such a vulnerable chipset for its main functionality.

Figure 4 showcases common BT product design strategies and their dependency on the BT chipset or stack.


Figure 4: Examples of Bluetooth Product Design

1. In the Isolated Design, products may have their main processor application (Product SW) communicating with a standalone BT chipset via a simplistic interface (e.g., serial AT commands, SPI/I2C transfers, etc). Such products may not need targeted handling of vulnerabilities in the BT stack and therefore are less impacted by a vulnerable BT chipset. This means that BT vulnerabilities are not likely to affect the Product SW or at least, the design allows to fully isolate attacks coming from a vulnerable chipset. WT32i is an example of such a BT Standalone chipset.

2. In between, a Mixed Design, which shares the BT stack between the main processor and the BT controller, are somewhat susceptible to attacks on the specific part of the BT stack. Since BrakTooth affects the BT Baseband or LMP implementation, the host stack is not affected directly. However, since both the BT Controller Stack and the BT Host Stack are continuously communicating depending on what happens inside the BT Controller, issues on the Product SW could arise if the HCI interface hangs. HCI interface may also misbehave in terms of whether the BT Controller provides expected responses or not. Therefore, it is up to the product software designer to investigate and handle all potential issues that can arise in the BT host stack. In general, this involves significant expertise and cannot be easily derived. The Mixed Design choice was unfortunately observed to affect products that rely on MSP432 as the main processor and Texas Instruments CC2564C as the BT controller when we had tested a sample code from TI’s BT stack (CC2564CMSP432BTBLESW1 (v4.2.1.1) + Service pack v1.4). In this context, attack V12 (8.12) causes a temporary hang on MSP432, which could cause an impact on the underlying product. In contrast, operating systems in smartphones and laptops have a mature mechanism to handle BT controller hardware errors originated from attacks in the BT controller. See Section 4.2 where we illustrate the impact of BrakTooth attacks on smartphones and laptops.

3. Lastly, we have the Fully Integrated Design, which is an obvious choice for cost reduction and is widely deployed for IoTs, speakers, headphones, and computer accessories. This design is susceptible to BrakTooth hangs, crashes, and RCE directly on the main product functionalities. Such is due to both the Product SW and BT Stack being coexistent on the same hardware. This is exemplified by V1 attack (8.1), which affects ESP32 running Bluedroid BR/EDR stack.

To conclude, the assessment of a product based on its dependency on the BT chipset is a fundamental approach to understand and calculate the final risk factors. Nevertheless, since BrakTooth affects the lower layers of several BT implementations, at least BT connectivity is impaired regardless of the design choice. Therefore, this should be taken into consideration when evaluating the product risks. Specifically, it needs to be evaluated whether a stable BT connectivity is always required for the assessed product to properly function.

BT Firmware Patches

Table 5: Patching status, Vulnerabilities and SDK/Firmware version of affected devices.
Contact vendor to acquire the patch; † The vendor disclosed to us to be affected by BrakTooth vulnerabilities.

Table 5 captures the affected vendors and the status of their investigation. We categorize the status of the investigation in the following forms:

  • Available: The chipset vendor has replicated the vulnerability and a patch is available to the general public.
  • TBA (To be announced): The chipset vendor has successfully produced a patch and have distributed it to OEM/ODM partners. This means that the chipset vendor has done its part and is up to the equipment/device manufacturer to deliver patches to the end-user via some security patch delivery mechanism.
  • Patch in progress: The chipset vendor has successfully replicated the vulnerability and a patch for the same will be available soon.
  • Investigation in progress: The chipset vendor is currently investigating the security issue and our team is assisting them.
  • No fix: The chipset vendor has successfully replicated the issue, but there is no plan to release a patch.
  • Pending : The chipset vendor hardly communicated with the team and the status of their investigation is unclear at best. No patch is in pending state as of 1st November of 2021.

We observe that Espressif SystemsInfineon (former Cypress) and Bluetrum have so far produced the patches. All other vendors are currently at the stage of investigation or patch development of the reported issues. We are working with the vendors to help them reproduce the issues in their systems such that patches are available to the public.

The vendor Texas Instruments has successfully replicated the security issue, however, at this stage has no plan for producing a patch. In particular, according to the Texas Instruments PSIRT team, they will consider producing a patch only if requested by customers. Through technical analysis, TI PSIRT concluded the potential vulnerability causes the CC256x device to enter a deadlock state, resulting in a denial of service, which could impact the availability to the user, but does not impact sensitive information in the system.

Our team approached Qualcomm to inquire whether a patch would be available for the affected devices. We were informed that they are working on a fix for WCN3990/8 and that the security issue reported in Qualcomm CSR8811A08  [28] has been fixed since 2011 only for ROM Versions A12 and beyond. However, new products in 2021 are still being listed to use CSR8811A08, which has no plan to be fixed. Moreover, a patch for the issue on CSR8510A10  [27] that causes V6 (see Section 8.6) is not possible for CSR8510A10 due to the lack of ROM patch space.

Zhuhai Jieli Technology confirmed that a fix for AC6366C  [40] would be released soon, but they did not confirm whether a patch would also be available to their other audio devices AC6925C and AC6905X. Finally, we notice for certain vendors (e.g. Harman International, Silabs), the investigation status is unclear, as indicated by the Pending status in Table 5.

Sniffing BT BR/EDR in less than $15

As part of our work of reverse engineering ESP32 BT stack, we are releasing to the community a low-cost BT Classic (BR/EDR) Active Sniffer which is available at the following URL:


At the time of writing, this is the cheapest BR/EDR active sniffer, we are aware of due to the low price of ESP32 boards. ESP32-PICO-KIT can be purchased for $14.80  [25], but it is possible to find alternative ESP32 boards on AliExpress for as low as $4  [10].

Note that differently than passive sniffers, which does not interact with the network, the ESP32 active sniffer must act as either a BT Master or Slave device within the BT piconet. As exemplified in Figure 5, the sniffer logs BT BR/EDR OTA protocols such as Baseband header, FHS, LMP, and ACL packets. The sniffer cannot be used to inject packets at the moment due to the PoC embargo. The embargo will be lifted at the end of October 2021 and our full PoC tool will be made available to the public for research and reproduction. Nevertheless, some open-source tools such as InternalBlue BT patching framework  [6] and Ubertooth experimental BTBR implementation  [16] could be used by someone with certain BT firmware skill to attempt triggering BrakTooth LMP attacks.


Figure 5: Active BR/EDR Sniffing of piconet. The sniffer captures Baseband + FHS and LMP frames.

reference link : https://asset-group.github.io/disclosures/braktooth/


Please enter your comment!
Please enter your name here

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.