BreakMi: Reversing, Exploiting and Fixing Xiaomi Fitness Tracking Ecosystem

. Xiaomi is the leading company in the ﬁtness tracking industry. Successful attacks on its ﬁtness tracking ecosystem would result in severe consequences, including the loss of sensitive health and personal data. Despite these relevant risks, we know very little about the security mechanisms adopted by Xiaomi. In this work, we uncover them and show that they are insecure. In particular, Xiaomi protects its ﬁtness tracking ecosystem with custom application-layer protocols spoken over insecure Bluetooth Low-Energy (BLE) connections (ignoring standard BLE security mechanisms already supported by their devices) and TLS connections. We identify severe vulnerabilities aﬀecting such proprietary protocols, including unilateral and replayable authentication. Those issues are critical as they aﬀect all Xiaomi trackers released since 2016 and up-to-date Xiaomi companion apps for Android and iOS. We show in practice how to exploit the identiﬁed vulnerabilities by presenting six impactful attacks. Four attacks enable to wirelessly impersonate any Xiaomi ﬁtness tracker and companion app, man-in-the-middle (MitM) them, and eavesdrop on their communication. The other two attacks leverage a malicious Android application to remotely eavesdrop on data from a tracker and impersonate a Xiaomi ﬁtness app. Overall, the attacks have a high impact as they can be used to exﬁltrate and inject sensitive data from any Xiaomi tracker and compatible app. We propose ﬁve practical and low-overhead countermeasures to mitigate the presented vulnerabilities. Moreover, we present breakmi , a modular toolkit that we developed to automate our reverse-engineering process and attacks. breakmi understands Xiaomi application-layer proprietary protocols, reimplements Xiaomi security mechanisms, and automatically performs our attacks. We demonstrate that our toolkit can be generalized by extending it to be compatible with the Fitbit ecosystem. We will open-source breakmi .


Introduction
Fitness tracking systems are complex and pervasive technologies used to monitor sensitive (health) data. They are composed of wearable devices connected to a mobile application acting as a gateway to cloud services. We have seen impactful security and privacy breaches affecting those systems. For example, researchers found backdoors in trackers' firmware [SJMdR16], managed to flash malicious firmware wirelessly [CWP + 18], leaked private data, including health records and login credentials [RCT16], and disabled communication encryption [FCS + 17]. It is not straightforward to fix these issues as vendors might not patch them at all, and fitness trackers might not support (secure) remote patching. Furthermore, vendors must distribute the software fix securely and on a large scale.
Xiaomi is the worldwide fitness tracking leader. In 2020, Xiaomi sold 13.5 million devices and had 24.5% of the market share [Cor20]. Nevertheless, the Xiaomi fitness tracking ecosystem received little attention from security researchers, despite being pervasive and promising security and privacy guarantees to its users [Hua20]. Currently, there is only incomplete and outdated information about Xiaomi security mechanisms [HPK16,FFM + 17]. On the other side, Fitbit (its main competitor) has received more consideration from security researchers. For example, recent work demonstrated that popular Fitbit devices are susceptible to attacks such as packet sniffing, data exfiltration, and code injection through firmware updates [RCB13,CHMS14,GDS16,SJMdR16,CWP + 18].
In this work, we perform an extensive and up-to-date security evaluation of the Xiaomi fitness tracking ecosystem that is currently lacking. We analyze all Xiaomi trackers since 2016 (i.e., Mi Band 2/3/4/5/6 and Amazfit Cor 2) and up-to-date Xiaomi companion apps (Mi Fit and Zepp). Via extensive static and dynamic reverse-engineering experiments, we reconstruct Xiaomi's proprietary Pairing, Authentication, and Communication protocols used to connect trackers and apps via BLE. We find that these protocols are implemented at the application-layer over a BLE link-layer. Moreover, we discover that Xiaomi ignores standard BLE security mechanisms (e.g., BLE pairing and secure sessions), although its devices support them.
Then, we uncover severe specification-level vulnerabilities affecting the self-baked Xiaomi protocols. For example, keys are sent in cleartext, authentication is unilateral and replayable, and the BLE traffic is neither encrypted nor integrity protected. As the vulnerabilities target the protocols' design, they can be exploited regardless of the hardware and software details of the target (e.g., firmware, operating system, app, and BLE versions). Additionally, those issues might even be exploitable on other Xiaomi products sharing the same application-layer security mechanisms.
To demonstrate the impact of the presented vulnerabilities, we develop and evaluate six practical attacks on actual devices. With our over-the-air (OTA) attacks, an attacker in Bluetooth range with a victim can impersonate a tracker to an app, an app to a tracker, man-in-the-middle them, and eavesdrop on their communication. Alternatively, with our remote attacks, indicated in the paper as software-based (SB), an attacker can remotely eavesdrop on data from a tracker or impersonate an app by abusing Android BLE API within a malicious app. Our attacks are high impact because they affect the whole Xiaomi ecosystem and enable the attacker to achieve valuable goals such as eavesdropping on sensitive data exchanged by a tracker and a smartphone (e.g., health data, SMS, and notifications) or sending arbitrary commands to the tracker and the smartphone.
We developed breakmi, a security evaluation toolkit for fitness tracker ecosystems to automate our RE efforts and attacks. breakmi has three modules: protocol dissector, security mechanisms, and attacks. The protocol dissector module understands Xiaomi's proprietary application-layer protocols, allowing for fast and automated analysis of its application-layer packets. The security mechanisms module reimplements Xiaomi's custom security mechanisms, such as Pairing and Authentication. The attacks module deploys our attacks automatically, including over-the-air or remote impersonation and MitM on arbitrary trackers and apps. We will release breakmi in the open after responsible disclosure.
To show the effectiveness of our attacks, we present an extensive evaluation of Xiaomi trackers and apps. In particular, we successfully attacked all Xiaomi trackers released since 2016 (i.e., Mi Band 2/3/4/5/6 and Amazfit Cor 2) and the latest versions of the Xiaomi fitness mobile apps (i.e., Mi Fit version 4.8.1 and Zepp version 5.9.2). Two of the presented attacks are remotely targeting the Android platform. We successfully conduct them on six popular Android versions (i.e., Android 6/8/9/10/11/12) to confirm their widespread impact. According to [Sta21], these versions represent 90% of the Android ecosystem.
To effectively address the presented vulnerabilities and attacks, we propose five coun-termeasures. All of them incur minimal overhead because they rely on a few additional messages and on lightweight security features. We redesign Xiaomi proprietary protocols to implement four out of the five proposed countermeasures at the application-layer. The fifth countermeasure applies to the link-layer, where we encourage the activation of the standard BLE link-layer security (i.e., BLE legacy pairing, LE Secure Connections), already supported by all Xiaomi devices.
To check the effectiveness of our attacks and the extensibility of breakmi to other vendors, we also analyzed the Fitbit ecosystem (the second biggest ecosystem after Xiaomi). We looked at two popular Fitbit trackers (i.e., Charge 2 and Charge 4) and the Fitbit mobile app (v 3.54.1). Our results show that the Fitbit ecosystem provides better (still proprietary) security mechanisms than Xiaomi. However, it is still vulnerable to five out of the six presented attacks. While testing our attacks on Fitbit, we extended breakmi by adding Fitbit's custom protocols and security mechanisms.
To encourage further research on the topic, we describe our reverse-engineer methodology in detail. Specifically, we used a mix of static and dynamic techniques for reconnaissance, traffic analysis, and app analysis. Additionally, we developed custom scripts and tools to automate our analyses that are now part of breakmi. Overall we spent a considerable time reversing the Xiaomi ecosystem (i.e., one year RE effort).
We summarize our contributions as follows: • We reverse-engineer the proprietary security protocols used by Xiaomi to protect the BLE link between its trackers and companion apps. Those protocols include Pairing, Authentication, and Communication at the application-layer, and do not take advantage of BLE link-layer security mechanisms already supported by its devices.
• We uncover novel and severe vulnerabilities in the specification of those protocols enabling an attacker to target the ecosystem as a whole. The list of vulnerabilities includes unilateral and replayable authentication, improper key agreement, and lack of encryption and integrity protection of sensitive data.
• We show how to exploit these vulnerabilities, and we perform high-impact Xiaomicompliant attacks either over-the-air or remotely (via a malicious app). We design and release breakmi, a toolkit to automatically analyze and attack the Xiaomi ecosystem. We address the presented vulnerabilities and attacks by proposing five practical and low overhead countermeasures that fix Xiaomi's vulnerable protocols.
• We compare Xiaomi with Fitbit, and we find that four of the identified vulnerabilities and five of the proposed attacks are portable to Fitbit. We extend breakmi to the Fitbit ecosystem, and we successfully conduct the attacks.
Responsible disclosure We responsibly disclosed our findings to Xiaomi in March 2021 via the HackerOne platform. Xiaomi considered our report as a single and known vulnerability, namely "lack of encryption," scheduled to be fixed on an undisclosed timeline. We disagree with this response as we reported multiple classes of vulnerabilities leading to several attacks (and not a single vulnerability) 1 . We also responsibly disclosed our findings to Fitbit in January 2022 through Google Vulnerability Reward Program, and Fitbit acknowledged our attacks and will deploy a fix in April 2022. Figure 1: Xiaomi fitness tracking system architecture. The tracker is a battery-powered embedded device supporting BLE. The smartphone runs a fitness tracking application and is capable of communicating with the tracker via BLE and with a backend server via the Internet.

Background
In this section, we introduce BLE and what is known about the Xiaomi fitness tracking ecosystem.

Bluetooth Low Energy (BLE)
BLE is the de-facto standard wireless technology for low-power wireless services, including fitness tracking. It is defined in the Bluetooth standard [SIG19] and provides a client-server architecture to exchange data using a specific format. Security-wise, BLE includes pairing and session establishment mechanisms that should provide confidentiality, integrity, and authenticity guarantees at the link-layer.
The BLE client-server architecture is specified by the Generic Attribute Profile (GATT) and uses the Attribute Profile (ATT) protocol [SIG19, p. 1531]. In Bluetooth terminology, the client is defined as the central, and the server as the peripheral. The client sends read, write, and notification requests to the server. The server answers accordingly to the request type and the availability of data.
In a fitness tracking use case, the GATT server is the tracker device (e.g., wristband) and the GATT client is a smartphone application. The server exposes fitness data, such as heart rate and step count, while the client can periodically query such data. BLE data is exchanged using a hierarchical and object-oriented format defined in [SIG19, p. 284].
The top-level of the hierarchy is a profile, and it contains a set of services. Each service provides characteristics or other services. A characteristic provides a value field with optional fields, such as descriptors and properties. Each characteristic can be configured with access-control flags (e.g., read-only, write-only, or read-write).
BLE provides pairing and secure session establishment protocols to secure the link-layer. Before exchanging data over GATT, the client and the server can pair to agree upon a long-term pairing key and use it to establish a secure session (e.g., by using ECDH).
On the contrary, session establishment is implemented using AES-CCM authenticatedencryption, keyed with a fresh session key (derived from a pairing key). The server can protect a GATT characteristic by requiring a client to pair before accessing it by setting its encryption and authentication security permissions.
A BLE device supporting a Bluetooth version greater than or equal to 4.2 can support a security mode known as Secure Connections (SC) that enhances pairing and session establishment by only using Federal Information Processing Standards (FIPS) compliant algorithms.

Xiaomi Fitness Tracking Ecosystem
The Xiaomi fitness tracking ecosystem includes wearable tracking devices, smartphones running a tracker companion app, and backend infrastructure. As we see from Figure 1, the Xiaomi components communicate wirelessly using a combination of short-range and longrange technologies. The tracker and the smartphone use BLE (introduced in Section 2.1), while the smartphone and the backend require Internet connectivity through Wi-Fi or a cellular network. We note that other fitness tracker vendors, including Fitbit, employ the same general architecture.
Xiaomi trackers are wearable and battery-powered devices composed of sensors to collect health data, such as step count and heart rate, and actuators, such as buttons and a touch screen. They can also control the associated smartphone (e.g., lock/unlock the screen) and receive notifications (e.g., SMS, WhatsApp).
Xiaomi's official companion app is Mi Fit and is freely available for Android [Co.] and iOS [Incc]. The app provides a user interface to configure and manage a tracker and is compatible with all Mi Band and Amazfit Cor generations. Another official app that supports Xiaomi trackers is Zepp, available on Android [Incd] and iOS [Ince]. There are also several third-party apps compatible with Xiaomi.
The Xiaomi backend is an Internet-accessible infrastructure that manages several aspects of the ecosystem. It stores the list of registered users and their associated trackers. It also backups the configurations of the trackers and the apps. Additionally, it distributes firmware and resource file (e.g., fonts, images) updates to the trackers. The backend is managed by Huami, which is also the developer of the Mi Fit and Zepp applications (and the tracker's manufacturer).
On one hand, Xiaomi does not provide any information about its security architecture and mechanisms. However, on the other hand, it claims to guarantee its users' confidentiality, security, and privacy (see the Privacy Policy [Hua20] dated May 2020). Hence our work investigates how these claims are actually implemented in practice.

Analysis of Xiaomi Fitness Tracking
From our reverse-engineering experiments, we found that Xiaomi uses three proprietary application-layer protocols in three different operations: Pairing, Authentication, and Communication.
These three protocols define the format, and the purpose of any BLE packet exchanged between Xiaomi companion apps and trackers. A single vulnerability in the protocols can be used to exploit any supported Xiaomi tracker and app. Hence they must be well designed and implemented, but this work (experimentally) shows the contrary. We note that Xiaomi protocols are orthogonal to the link-layer security mechanisms provided by BLE introduced in Section 2.1.
In our experiments, we also uncover that Xiaomi disables BLE link-layer security and privacy features despite being supported by its trackers and apps. BLE security mechanisms were designed to protect the emerging IoT market, including the fitness tracking industry, and it is not evident why Xiaomi simply ignores them. This choice considerably increases the risk of a security breach as Xiaomi only trusts its vendor-specific protocols. Now we describe these protocols in detail. The presented information required extensive

Reverse-Engineered Protocols
We isolate three Xiaomi proprietary application-layer protocols, and we name them Pairing, Authentication, and Communication. Pairing is used to establish a long-term secret (i.e., pairing key) between a tracker and an app. Authentication is employed to prove ownership of a pairing key. Communication runs only after a successful Authentication and enables interaction between trackers and an app. Those interactions include sending health data from the tracker and sending commands or notifications from the app to the tracker or vice versa. Now we describe their technical details. We use the terms tracker and app to refer to any Xiaomi-compliant device, and, when needed, we indicate the specific tracker model or app name.

Pairing
Pairing is used to establish a 16-byte pairing key between the tracker and the app. The pairing key is the root of trust between the devices and must be kept secret and stored securely. We observed two versions of Pairing.
The first version, which we call Pairing v1, is used by Mi Band 2/3 and Amazfit Cor 1/2 trackers. Instead, Pairing v2 is employed by Mi Band 4/5/6 and is server-based as it involves Xiaomi backend. Mi Fit and Zepp apps support both pairing versions. Now we describe the technical details of Pairing v1/v2. Pairing v1 is supported by MB 2/3 and works shown in Figure 2. The app sends a pairing initialization message (Pairing Init). The tracker responds with a Pairing version message (pair_v1). The app generates and sends a 16-byte pairing key (Key) to the tracker in the clear. Then, the tracker shows the user a pairing confirmation message (see Mi Band 2/3 in Figure 3) and waits for user confirmation (together with the app). Once the user confirms pairing, the tracker sends a success message (Pairing Complete) to the app and resets its stored data, completing Pairing v1.
Xiaomi introduced Pairing v2 in 2019, and it is supported by MB 4/5/6. The protocol involves interactions with the Xiaomi backend using HTTPS. The protocol works as depicted in Figure 4. The app sends a Pairing Init message, and the tracker replies with a pair_v2 and a truncated digest of its public key (SHA1(pub_k)). As we observed the same digest on all trackers that we tested (i.e., 1863c2cce5d159413bed92c4b163c279), we are confident that all trackers are using the same public key.
Then, the app sends a random number request, and the tracker answers with R, a 16-byte random number. R and the tracker public Bluetooth address (TR_A) are inputs to a custom key derivation function (kdf) that generates the pairing key (Key). As such, R is the pairing key seed and is sent in the clear. We reverse-engineered kdf and discovered that it computes a SHA256 of the concatenation of TR_A and R and outputs Key, the leading 16 bytes of the digest. The function is expressed as: Next, the app and the backend establish a TLS session, and the app sends SHA1(pub_k) and the Key encoded as base64 to the backend. The backend computes a signature (Sig) of Key using its private key (pri_k) and sends the base64-encoded signature to the app (B64(Sig)). The app provides the signature to the tracker that verifies it and sends back an acceptance message (Valid Sig). Then, pairing completes identically to Pairing v1, with the user having to accept a pairing confirmation message (see Mi Band 4/5/6 in Figure 3).

Authentication
Authentication has only one version and works as depicted in Figure 5. The app sends an authentication request message (Auth Req). The tracker answers with a 16-byte challenge (Chal). The app computes a 16-byte response (Resp) by encrypting Chal with Key using AES in ECB mode and sends it to the tracker. The tracker computes its own response, checks it against Resp, and sends a positive authentication message (Auth OK) if Resp is verified. As a result, the tracker authenticates that the app owns the correct pairing key and unlocks access to its private data (e.g., step count). However, the tracker never authenticates to the app, and the authentication messages are sent in the clear.

Communication
Once a tracker and an app complete Pairing and Authentication, they run the Communication protocol to exchange data, commands, and notifications. We discovered that Communication is neither encrypted nor integrity protected despite the tracker and the app sharing a pairing key. This finding is surprising, as Xiaomi trackers and apps do support encryption primitives and crypto hardware acceleration. Moreover, prior authoritative reports, such as the ones from Mozilla [Fou20b,Fou20c,Fou20a], state that Xiaomi uses encryption (and meets Mozilla's minimum security standards) when this is not the case.
Communication is implemented on top of BLE GATT (introduced in Section 2.1). The tracker is the GATT server, and the app is the GATT client. The server has a set of public services (e.g., Generic Access) and characteristics (e.g., Device Name). Each characteristic has access control bits to set reading and writing permissions.
On top of GATT, Xiaomi uses a custom data locking mechanism where a tracker GATT characteristic cannot be accessed until the app has authenticated to the tracker (via a successful run of Authentication). Two examples of locked characteristics are heart rate and step count. For the list of GATT services and characteristics exposed by Mi Band 2/3/4/5/6, see Table 6 and Table 7 in the Appendix.

Protocol-level Vulnerabilities
We analyzed the Pairing, Authentication, and Communication protocols (described in Section 3.1), and we identified thirteen severe vulnerabilities in their specifications. Most of them, such as unilateral/replayable authentication and lack of encryption and integrity protection, were publicly unknown. The issues affect all trackers released since 2016, even  the newest releases (i.e., MB 6) and the most recent app versions. We now describe the vulnerabilities grouped by protocol.

Pairing v1 (MB 2/3, AC 1/2)
• Pairing key sent in the clear. The app sends the pairing key to the tracker in the clear and with no integrity protection (see Key in Figure 2).
• Pairing not authenticated. The devices do not authenticate each other during Pairing. Hence the app and the tracker cannot determine if they are pairing with a legitimate device.
• Pairing key generated by the app. The pairing key is generated and distributed by the app, despite the tracker being able to run a key agreement protocol (e.g., Elliptic-curve Diffie-Hellman (ECDH)).
• Weak user confirmation. As shown in Figure 3, pairing confirmation is weak as the user only has to interact with the tracker, and the tracker does not show any contextual information.

Pairing v2 (MB 4/5/6)
• Pairing key seed sent in the clear. The tracker sends the pairing key seed to the app in the clear and with no integrity protection (see R in Figure 4). This issue is as bad as in Pairing v1, as the pairing key is deterministically computed from its seed and its publicly available information (i.e., the tracker's Bluetooth address).
• Pairing only (weakly) authenticates the app. Pairing v2 does not authenticate the tracker to the app but authenticates the app to the tracker. In particular, the tracker must receive a correct signature from the app. The signature algorithm is deterministic, and both inputs are public, so an attacker could reverse the algorithm and obtain the signature.
• Pairing version can be downgraded/upgraded. The tracker decides the version of Pairing by sending either pair_v1 or pair_v2. As this message is not integrity protected, it can be manipulated to force a specific pairing version (e.g., downgrade from v2 to v1 or upgrade from v1 to v2).
• Pairing key generated by the tracker. The pairing key only depends on the tracker, despite the app being able to run a key agreement protocol (e.g., ECDH). This issue is worse than the one highlighted for Pairing v1 key generation. The tracker is a computationally-constrained device and is more likely to generate a low-entropy key than an app running on a smartphone.
• Default keypair. The hash of the public key is the same for all MB 4/5/6 that we tested, and this entails that all our trackers share the same public key. Our device sample is limited, but we found the same key even across devices bought in different countries. This implementation is risky because an attacker can compromise the whole ecosystem by leaking the default private key.
• Weak user confirmation. As shown in Figure 3, pairing confirmation is weak for the same reasons as Pairing v1.

Authentication
• Unilateral app authentication. The protocol unilaterally authenticates the app (see Resp in Figure 5), but it does not require to authenticate the tracker. Indeed, there is no way for an app to check if it is connected with a legitimate tracker.
• Replayable authentication. The protocol is vulnerable to replay attacks as, given a fixed challenge, there is no way to generate different responses (i.e., there is no nonce). Hence a fitness tracker cannot be certain that a valid response comes from a trusted app.

Communication
• No encryption. Despite sharing a pairing key and supporting encryption algorithms, the tracker and the app do not encrypt their sessions. Hence sensitive data exchanged over BLE can be effortlessly obtained.
• No integrity protection. Despite sharing a pairing key and supporting Message Authentication Codes (MAC), the tracker and the app do not integrity-protect their communication. As a result, sensitive data can be manipulated at will.

Proposed Attacks
We now describe six attacks to demonstrate the severity of the issues presented in Section 3.2. As the attacks exploit architectural vulnerabilities in the Xiaomi protocols, they are effective on all devices employing those protocols. Developing the attacks required extensive RE efforts as we target proprietary and unknown protocols (unlike BLE pairing and session establishment). We discuss four over-the-air attacks and two software-based attacks. Our OTA tracker impersonation, OTA app impersonation, and OTA MitM require proximity with the target, as they exploit BLE traffic and minimal equipment.
Our SB app impersonation and SB eavesdropping are remote and require the installation of a malicious app on the victim's phone. The app only asks for Internet and Bluetooth normal permissions (no root access) and abuses Android BLE API to interfere with BLE traffic. Next, we present our threat model, describe the attacks, discuss how each attack maps to the vulnerabilities presented earlier and their impact.

System Model
Our system model has the same architecture presented in Section 2.2 and depicted in Figure 1. There are three entities: a tracker, a companion app, and a backend. The tracker and the app communicate over BLE, and the app communicates with the backend via Wi-Fi or a cellular network. The entities use the strongest security mechanisms at their disposal.
For example, the communication between the tracker and the app is protected using Xiaomi Pairing, Authentication, and Communication protocols that we reverse-engineered and described in Section 3.1. Similarly, the app and the backend use TLS. Such mechanisms should protect against passive and active attacks, including eavesdropping, device impersonation, and MitM attacks.
Our victim is a user of the Xiaomi ecosystem. She might use any supported trackers, such as Mi Band (MB) 2/3/4/5/6 and Amazfit Cor (AC) 1/2, and any version of the Mi Fit and Zepp companion apps. We assume that the victim has installed the app, registered an account with the Xiaomi backend, and paired her tracker with the smartphone app. Hence the user can establish authenticated sessions between the tracker and the app.

Attacker Model
Our attacker targets Xiaomi Pairing, Authentication, and Communication protocols as the vulnerabilities in these protocols can be exploited regardless of the hardware and software details of the target tracker and app. In other words, she is looking for Xiaomi-compliant vulnerabilities.
The attacker only knows public information advertised by the tracker over BLE (e.g., the public BLE address of the tracker), and she has no physical access to the target devices. Hence the attacker does not know any pre-shared secret between the victims (e.g., pairing keys) and cannot tamper with the devices' operating system and firmware.
The attacker has four goals: (i) she aims at impersonating the tracker to the app and (ii) the app to the tracker; (iii) she wants to establish a MitM position between the tracker and the app; (iv) she desires to eavesdrop the data exchanged between the tracker and the app.
The attacker can use over-the-air (OTA) or software-based (SB) attacks. Our attacker model is based on the Android threat model proposed by Mayrhofer et al. [MSBK21]. This threat model labels our OTA attacks as both Proximal Access and Network-level threats. In particular, our OTA attacks involve T.P1 -Devices in physical proximity, but not under direct control, of an attacker who can control radio communication channels, including BLE), T.N1 -Passive eavesdropping and traffic analysis, and T.N2 -Active manipulation of network traffic. The attacker can sniff BLE traffic, jam the BLE spectrum, craft, and send custom BLE packets to the app and the tracker. The same threat model labels our SB attacks as Application Code threats. In particular, our SB attacks involve T.A1 -Abusing APIs supported by the OS. The attacker can remotely attack the victim through a malicious app already installed on the victim's smartphone, a common requirement for most Android malware [Lak21b,Lak21a,Lak21c]. This requirement is reasonable as users often install unwanted apps on their smartphones fairly often. Kotzias et al. [KCB21] estimated that 67% of unwanted apps are directly installed from the Google Play Store or alternative markets (10.4%). When launched, our malicious app stealthily abuses Android BLE API. It only requires normal permissions related to the Internet and Bluetooth and does not need root privileges.  , which is already paired with the impersonated tracker, recognizes the attacker as trusted and sends her an authentication request (Auth Req). The attacker's device answers with a random challenge (Chal). The app solves it and sends back a response (Resp) computed from the pairing key unknown to the attacker. The attacker ignores Resp, answers with a positive authentication message (Auth OK), and unlocks its fake GATT server. As a result, the app starts the Communication protocol with the impersonated tracker, believing it is trusted.

OTA Tracker Impersonation Attack
The attacker can wirelessly impersonate any tracker by presenting itself to a victim app as a spoofed tracker, running the unilateral Authentication protocol without having to authenticate, and then starting a Communication session that is neither encrypted nor integrity protected. The attack does not require knowledge of the pairing key, does not trigger Pairing (which requires user interaction), and can be launched anytime a target app is in BLE range with the attacker. The attack leverages Xiaomi's unilateral authentication and the lack of encryption and integrity protection of Communication.
The technical details of the attacks are presented in Figure 6. The attacker advertises her presence as the impersonated tracker by copying its features, including its Bluetooth address and GATT server. The victim (App) recognizes the attacker as trusted and sends her an authentication request (Auth Req). The attacker answers with a random challenge (Chal), and the app computes and sends back a response (Resp) derived from a pairing key unknown to the attacker. The attacker ignores Resp, answers with a positive authentication message (Auth OK), and unlocks her own GATT server. Afterward, during Communication, the app considers the impersonated tracker as trusted.

OTA App Impersonation and MitM Attacks
The attacker can impersonate any app over-the-air or MitM an app and a tracker using a replay attack on the non replay-protected Authentication protocol and can start an insecure Communication session.
In particular, the attacker can start Authentication in parallel with the app and the tracker. When the tracker sends a challenge, the attacker replays it to the app, relays the app response to the tracker, and successfully authenticates to the tracker without knowing the pairing key. Then, the attacker can either impersonate the app by dropping her connection with the legitimate app and starting a Communication session with the tracker or MitM the Communication session between the app and the tracker.
The attacks do not require knowledge of the pairing key and do not trigger Pairing. Unlike the OTA tracker impersonation attack, these ones require both the app and the tracker to be in BLE range with the attacker. This issue is not that significant as the tracker and the app are typically carried and used by the same person.
The technical details of the OTA app impersonation and MitM attacks are presented in Figure 7. The attacker advertises her presence as a trusted tracker, and the app sends an Auth Req message to the attacker to start Authentication. The attacker sends a parallel Auth Req message to the tracker to initiate Authentication with the tracker. The tracker sends a Chal to the attacker, who relays it to the app. Then, the app computes Resp and sends it to the attacker, who replays it to the tracker to prove ownership of a pairing key that she does not know. The tracker sends an Auth OK message to the attacker, and the attacker sends an Auth FAIL message to the app if she wants to impersonate it or sends an Auth OK message to preserve her MitM position.

Tracker
Attacker App

SB App Impersonation Attack
The attacker can impersonate any Xiaomi Android app and remotely pair with a victim tracker. The attack works regardless of the pairing's protocol version. Similarl to other Android malware threat models [MSBK21], the malicious app is already installed on the victim's smartphone. This app acts stealthily, runs with normal BLUETOOTH and INTERNET permissions, and does not require root access. The main advantage of this attack over the OTA counterpart is that it can be conducted remotely (i.e., over the Internet). Its main drawback is that it requires user interaction to trigger a new pairing session. However, since pairing confirmation involves interactions only with the trackers, the user has no way to tell if the tracker is pairing with a malicious or legitimate app.
The SB app impersonation on Android is depicted in the right part of Figure 8 and works as follows. The attacker abuses the Android BLE API to discover a tracker paired with the Xiaomi app. This task can be done by finding Xiaomi proprietary commands in the smartphone GATT traffic or by looking for the BLE address of the tracker in the list of connected devices.
If the target tracker supports Pairing v1, the attacker starts a pairing protocol with the tracker. The tracker cannot tell if the pairing request is authentic and completes pairing with the attacker's malicious app. Otherwise, if the tracker supports Pairing v2 (i.e., server-based), the attacker must use a different strategy. In particular, the attacker sends a factory reset proprietary command (that we reverse-engineered). The command does not require prior authentication. It deletes the bond between the tracker and the legitimate app, changes the tracker's BLE address, and puts it in pairing mode. Then, the attacker can find the tracker and complete the pairing. This attack strategy completely defeats server-based pairing, which still lacks strong device authentication. Finally, regardless of the attacked pairing version, the legitimate app cannot connect back to the tracker (e.g., in Figure 8, the tracker accepts the red key, but the app has the black one).

OTA and SB Eavesdropping Attacks
Due to the lack of encryption during Pairing, Authentication, and Communication, the attacker can effortlessly launch OTA and SB eavesdropping attacks.
In the OTA case, the attacker can sniff sensitive data exchanged between tracker and app. For example, during Pairing v1 she can sniff the pairing key, during Pairing v2 the pairing key seed, during Authentication the challenge-response pairs (to be used in an offline brute-force attack), and during Communication all the data sent including health parameters from the tracker and notifications from the app.
In the SB case, the attacker can sniff sensitive data from remote trackers via a malicious app, taking advantage of the lack of encryption and a known issue with the Android BLE API. Android allows applications with BLUETOOTH permissions to sniff all GATT data received by a smartphone. Thus, any application co-located with the Mi Fit app can sniff all the traffic coming from a tracker without pairing or authenticating with it. For example, in Figure 8, we depict a malicious app (Attacker App in red) sniffing the heart rate value sent by the tracker by abusing Android BLE API.

Discussion
Mapping between attacks and vulnerabilities In Table 1, we present a mapping between our attacks and the vulnerabilities presented in Section 3.2. The Pairing v1/v2 protocols can be targeted by OTA eavesdropping, SB eavesdropping, and SB app impersonation. OTA and SB eavesdropping exploit the data sent in the clear during the Pairing protocol (pairing key in Pairing v1 and pairing key seed in Pairing v2). SB app impersonation exploits the missing/weak authentication and weak user confirmation to connect a malicious device to a legitimate tracker. The Authentication protocol can be targeted by OTA tracker impersonation, OTA app impersonation, and OTA man-in-the-middle. OTA tracker impersonation exploits unilateral app authentication (the tracker does not need to authenticate with the app). The OTA app impersonation exploits the replayability of BLE traffic between app and tracker, allowing any device to mimic a legitimate tracker. The OTA man-in-the-middle is a combination of the OTA app and tracker impersonations. The Communication protocol can be targeted by OTA tracker impersonation, OTA app impersonation, OTA man-in-the-middle, OTA eavesdropping, and SB eavesdropping. The lack of encryption and integrity protection in any BLE packet exchanged between app and tracker allows an attacker to eavesdrop and manipulate BLE traffic freely.

Attacks' Impact
The attacks' impact is high for several reasons. The proposed attacks, and their root causes (that we RE), were not known by the community. Also, our attack techniques include novel aspects. For example, the SB remote attacks combine unknown Xiaomi vulnerabilities with known Android issues.
The proposed attacks disprove the security and privacy claims made by Xiaomi in their Privacy Policy [Hua20], as we highlight in Section 6. We demonstrate that all Xiaomi trackers released since 2016 are vulnerable to the proposed attacks, and future releases will be vulnerable as well, as our attacks are Xiaomi-compliant. Our attacks affect millions of users, as Xiaomi is the world's leading fitness tracker manufacturer.
The proposed attacks are cheap and low-effort (e.g., only require commercial-off-theshelf products and minimal equipment) and are easy to deploy. An attacker can violate users' privacy by leaking and manipulating sensitive data (e.g., health records and 2FA SMS) and enforcing malicious factory reset and firmware update requests.

Pairing v1
Pairing key sent in the clear -

Implementation
In this section, we present the implementation of breakmi, a toolkit that we developed to reverse-engineer and attack Xiaomi's proprietary Pairing, Authentication, and Communication protocols. breakmi reimplements these protocols and automates our experiments and attacks. The toolkit contains a protocol dissector module, a security mechanisms module, and an attacks module. We will release breakmi as open-source, and now we describe how we implemented each module.

Protocol Dissector Module
Our toolkit, breakmi, includes a protocol dissection module capable of speaking Pairing v1/v2, Authentication, and Communication protocols (presented in Section 3). The dissectors module can detect and craft any Xiaomi proprietary message given a capture. We develop the dissectors as an aid for RE. We implement the module defining fifteen custom dissection classes for scapy [BtSC21], an interactive packet manipulation program. Each class encodes a message type using a specific binary layout.   [Wir21], and label them as v1 or v2. For Pairing v2, they also look for the Signature transmitted on Xiaomi's custom Chunked Transfer characteristic (00:00:00:20:00:00:35:12:21:18:00:09:AF:10:07:00), under Xiaomi's 0xfee1 service.
The Auth characteristic also serves Authentication messages. The dissectors monitor the status of Authentication and the challenge-response. In our experiments, we crafted Authentication messages with different opcodes and noticed that MB 4/5/6 accept opcodes used by MB 2/3, as shown in Table 2.

Security Mechanisms Module
Our toolkit also implements the custom key derivation function for Pairing v2 and challengeresponse Authentication procedures. By using these functions, breakmi is capable of deriving a valid pairing key from its seed (R) and a valid authentication response (Resp) from a challenge (Chal), and a pairing key (Key). We invested much time in understanding how the key derivation and challenge-response procedures work, and we reimplemented them with Python. In particular, we used Python's cryptography module from PyCA [Aut21] to implement SHA256 for the key derivation and AES-ECB for the challenge-response part.
To reverse the key derivation and the challenge-response, we used a mix of static and dynamic techniques. For the static analysis, we decompiled the Mi Fit APK with JADX [Sky21] and looked at the recovered source code. Unfortunately, the Mi Fit app is obfuscated, and we could not recover the key derivation and authentication logic. At this point, we switched to dynamic binary instrumentation with Frida [Ple21]. Our dynamic approach was successful, as we were able to reverse the key derivation and authentication logics by hooking their entry point at runtime and observing their inputs and outputs.

Attacks Module
The OTA tracker impersonation attack, presented in Figure 6, was implemented using Bleno [Mis21a], an open-source BLE peripheral written in Node.js. Our Bleno script imitates any Xiaomi tracker by exposing the same BLE features (e.g., BLE advertisements and GATT server) collected by an extensive study of legitimate Mi Band 2/3/4/5/6, as shown in Table 6 and Table 7 in the Appendix. It was challenging to collect this information from all trackers and make sense of the (proprietary) characteristics and services exposed by the trackers. Once a victim app finds our Bleno tracker, we can complete Pairing v1 and Authentication as a trusted device, and we expose a malicious GATT server to the app during Communication.
The OTA app impersonation attack, presented in Figure 7, was implemented using Noble [Mis21b], an open-source BLE central, and by re-using the tracker impersonation described above. Our tool connects to nearby Xiaomi apps and trackers, performs a replay attack on the Authentication protocol, disconnects from the app, and establishes a communication session with the tracker as a trusted app. Once connected, our fake app retrieves data from the tracker, such as the step count and the user's heart rate. Furthermore, it can send fake SMS and phone call notifications and activate alarms. The OTA MitM attack implementation uses the same logic of the app impersonation. However, instead of disconnecting from the app after the replay attack is completed, the tool keeps two parallel connections and establishes a MitM position between the app and the tracker.
The toolkit also includes a malicious app that can be used to perform SB app impersonation and eavesdropping attacks. Our app requires only Android's BLUETOOTH permission to interact with the tracker over BLE and INTERNET permission to exfiltrate data remotely. Android classifies these permissions as normal, so they are granted during installation without triggering any user prompt.
SB eavesdropping and SB app impersonation utilize the same setup that periodically checks active BLE connections using Android getConnectedDevices API and waits for a Xiaomi tracker to appear. As soon as a tracker connects, the malicious app launches the attack.
During SB eavesdropping, our app subscribes to relevant characteristics and can eavesdrop on all BLE data coming from the tracker, including sensor readings, commands, pairing key seeds, and authentication challenges. During app impersonation, our app starts a new pairing session with the tracker by sending a Pairing Init without disrupting the communication between the tracker and the legitimate app. The malicious app eventually negotiates a new pairing key as in the right part of Figure 8 and gains access to protected data. The SB app impersonation attack on Pairing v2 entails the additional challenge of interacting with the Xiaomi backend to retrieve a signature. The malicious app sends a factory reset command to the tracker, which causes the change of its BLE address. A scan (requiring Android BLUETOOTH_ADMIN and ACCESS_FINE_LOCATION permissions) allows our app to perform a new pairing process and associate the tracker to our malicious Xiaomi account stealing its ownership from the legitimate user.
Since all attacks performed by breakmi are fully automated, we propose it as a continuous evaluation tool for the Xiaomi ecosystem. Even if Xiaomi were to enable link-layer security, the vulnerabilities we found at the application-layer would continue to exist. By

Evaluation
This section describes the evaluation of the attacks (presented in Section 4) using breakmi (described in Section 5). Our evaluation confirms that all Xiaomi trackers since 2016 and the most recent version of Xiaomi companion apps are vulnerable to our protocol-level attacks. In addition, it proves that breakmi works in practice and is cheap to deploy. As a result, millions of Xiaomi users are potential targets, and their sensitive health and personal data can be leaked and manipulated by bad actors.

Setup
In our evaluation, we tested all trackers shipped by Xiaomi since 2016. The sample includes Mi Band 2/3/4/5/6 and Amazfit Cor 2. The MB 1 is out of scope because it is known to ship with no security at all [of19]. We did not test the Amazfit Cor 1 because of its limited availability and market share. However, we expect that it is vulnerable to our attacks as it is a MB 2 clone. Moreover, we tested the latest versions of Mi Fit (v 4.8.1) and Zepp (v 5.9.2) as the official Xiaomi mobile applications. The apps are compatible with all Xiaomi trackers and are available for Android and iOS. Despite our attacks not requiring root permissions, we use rooted devices to facilitate our experiments. Table 3 presents the trackers' technical specifications. The Mi Band 2, Mi Band 3, and Cor 2 support Bluetooth version (BTv) 4.2 and Pairing version (Pv) v1. The others support Bluetooth 5.0, Pairing v2, and BLE Secure Connections (SC). All trackers support BLE security (BS) at the link-layer, but Xiaomi is not taking advantage of that. The tracker system-on-chip (SoC) is either a DA14681, a DA14697, or a DA14699, all manufactured by Dialog Semiconductor [Sem21]. We also report the firmware version (FW) of the tracker at the evaluation time.
Since our SB attacks depend on an issue with the Android BLE API (in addition to Xiaomi ones), we tested six popular Android versions using different smartphones: Android 12 (Google Pixel 4A), Android 11 (Google Pixel 2 XL), Android 10 (Google Pixel XL), Android 9 (Samsung Galaxy J5), Android 8.1 (Xiaomi Redmi 5 Plus) and Android 6 (Samsung Galaxy S5). We note that we cannot test our attacks on the Android emulator as it does not support Bluetooth emulation.
Our OTA attacking device is an Acer Aspire 3 laptop connected with a BLE sniffer and a BLE dongle. The laptop runs Ubuntu version 18.04 and supports Bluetooth 4.2. Table 4: Evaluation results for OTA and SB attacks. The first column shows the attack name, the following eight columns contain the targets (two companion apps and six fitness trackers). A checkmark () means that the attack was successful, and a hyphen (-) means that the attack does not apply to that target. MB and AC abbreviate Mi Band and Amazfit Cor. The SB attacks on the Mi Fit and Zepp apps were successfully tested on six Android versions (see Table 5). The sniffer uses three BBC Micro Bit boards and btlejack [Vir21]. The BLE dongle is a CSR8510 A-10 Controller with Bluetooth 4.0 support. The dongle is needed as we have to change the attacking device's BLE address, and the laptop (BLE controller) does not allow this operation.
The OTA impersonation and MitM attacks were performed by the attacking device running breakmi and acting as both a spoofed tracker and a spoofed app. When impersonating the tracker, the attacking device advertises as a spoofed tracker, while during an app impersonation, it scans for trackers as a spoofed app. OTA eavesdropping was performed using the BLE sniffer. The SB app impersonation and eavesdropping attacks were performed by running the malicious app in the background and letting the legitimate app and the tracker communicate as usual.

Results
The attacks' evaluation results are shown in Table 4, where we demonstrate that the attacks are effective across all evaluated devices (if the attack applies to that device). We can wirelessly impersonate all tested trackers and apps, MitM them, and eavesdrop on their communication. We can also remotely eavesdrop and impersonate the Mi Fit and Zepp apps for Android via a malicious app. All attacks work regardless of the hardware and software details of the victim device (e.g., SoC, firmware, app, tracker, and BLE versions).
The SB remote attacks target Android, so we test them on six popular Android versions, as we show in Table 5. We confirm that all six tested Android versions are vulnerable to our attacks. According to [Sta21], this means that (at least) 90.22% of Android devices are vulnerable. Since Android 12 was recently released in October 2021, statistical market share data is not available yet. We highlight that, up until Android 11, our attacks only ask for standard Bluetooth permissions as a requirement to access the getConnectedDevices method (that we exploit). Android 12 introduces the BLUETOOTH_CONNECT dangerouslevel runtime permission, which must be declared to access getConnectedDevices. As a consequence, on Android 12, our malicious app must show the user a Nearby Devices dialog that explicitly states our intent to find, connect to and determine the location of nearby devices. Table 5: Evaluation results for SB attacks against the latest six Android versions. All attacks were tested using a MB 4 as a tracker. The first column shows the smartphone model, the second one the Android version and its market share according to [Sta21]. Market share numbers for Android 12 are not available (n/a) as it is too recent. The third and fourth columns show that all Android versions we test are vulnerable to SB attacks ( ). If we sum the markets share numbers, our attacks are effective on at least 90.22% of Android devices.

Countermeasures
We now discuss five countermeasures addressing the vulnerabilities presented in Section 3.2 and the attacks presented in Section 4. The first four apply to the application-layer and the fifth to the link-layer.

C1 (Authenticated) Key Establishment
Pairing v1/v2 should use an Authenticated Key Establishment (AKE) to prevent impersonation, man-in-the-middle, and eavesdropping attacks. Figure 9 illustrates an updated version of Pairing v1/v2 to support C1. The tracker and the app first generate a public-private key pair and share their public keys (App_Pk and TR_Pk). They proceed with the calculation of a key (K) through a Diffie-Hellman (DH) function and the sharing of two nonces (App_N and TR_N). Finally, the tracker and the app calculate a confirmation value (V) displayed on each screen and wait for user confirmation concerning the match of the displayed values.

C2: Strong Pairing Confirmation
The updated Pairing v1/v2 protocol, shown in Figure 9, guarantees C2 thanks to the numeric comparison performed by the user. In particular, while pairing, a MitM attacker is not capable of generating V as she does not know K pairing. Moreover, during an app impersonation attack, the adversary would trigger an unexpected user interaction while re-pairing with the app.

C3: Strong Key Authentication
The Authentication procedure should be mutual and resistant to replay attacks. Mutual authentication is easy to implement by letting the app and the tracker send their challenges and then verifying them on both ends. Replay protection is also straightforward and can be achieved by using nonces and generating a response from a challenge and a nonce. These measures raise the bar for tracker impersonation and app impersonation. Figure 10  HKDF key derivation function from the pairing key K, and two exchanged nonces (App_N and TR_N).

C4: Authenticated-encryption
The Communication protocol should use a fresh session key derived from the pairing key K to encrypt and integrity-protect the data exchanged between app and tracker. Devices can rely on AES-CCM and HKDF to introduce this countermeasure, as both functions are already supported by the devices SoC. C4 protects against eavesdropping and MitM attacks during Communication.

C5: BLE Link-Layer Security
To complement the security at the application-layer, Xiaomi might also enable the BLE link-layer security mechanisms already supported by all its devices. The robustness of BLE link-layer security mechanisms depends on the BLE version of the device. The MB 4/5/6 implement BLE SC, so that they would benefit from secure protocols for pairing and session establishment. Instead, the MB 2/3 implement legacy BLE security, which is known to be insecure [Rya13a].

Comparison with Fitbit
In this section, we compare our findings of Xiaomi with the Fitbit [Fitb] ecosystem, which is Xiaomi's main competitor in the fitness tracker market. Our motivation for the comparison is twofold. Firstly, to assess if Fitbit is affected by similar vulnerabilities and attacks found on Xiaomi devices. Secondly, to evaluate how effective breakmi is on other large  (App_N and TR_N). The mutual verification of challenges guarantees C3 and AES-CCM with a fresh session key provides C4.
fitness tracking ecosystems. We used the same RE methodology adopted for Xiaomi and described in Section 9 for this analysis, but we targeted different proprietary protocols. In particular, we had a look at a Charge 2 tracker and the latest version of the Fitbit app for Android [Fita], as their security mechanisms were already reversed [CHMS14, SJMdR16, FCS + 17, CWP + 18]. The Charge 2 is from 2016, supports Bluetooth 4.1 and BLE link-layer security, and is powered by a BLUENRGCSP SoC from ST Microelectronics. We also considered the Charge 4 from 2020, but unlike the Charge 2, it uses unknown protocols, and reversing them is out of the scope of this work.
We now summarize what is known about the Fitbit protocols. Then we discuss their vulnerabilities and how the attacks presented in Section 4 apply to them. We describe how we extended breakmi to deploy five attacks on actual Fitbit devices successfully. Finally, we discuss how to port the countermeasures discussed for Xiaomi to the Fitbit ecosystem.

Architecture and Protocols
Fitbit uses the same system architecture as Xiaomi (see Figure 1). A tracker communicates over BLE with the Fitbit companion app, and the app communicates via Wi-Fi or a mobile network with the Fitbit backend. The devices use proprietary application-layer protocols (e.g., Pairing, Authentication, and Communication) and ignore available BLE link-layer security mechanisms. Unlike Xiaomi, which utilizes public BLE addresses, Fitbit trackers use random static addresses. Regardless, Fitbit devices are still trackable because their BLE address never changes for their entire lifetime.
Pairing As described in [SJMdR16, CWP + 18], Fitbit employs a Pairing protocol to establish a pairing key (authentication key in Fitbit terms) between the trackers and the app. During Pairing, the backend (which pre-shares a device key with a tracker) computes the pairing key from the device key and a salt, and sends them to the app. The app sends the salt to the tracker, and the tracker computes the pairing key from the salt and the device key. We note that, unlike Xiaomi, the key or its seed is not sent in cleartext, and pairing confirmation is strong. Pairing is accepted only when the user confirms on the app that she sees the same numeric sequence on the tracker and app screens. As such, Fitbit adopts a stronger user confirmation strategy than Xiaomi.
Authentication Fitbit Authentication, unlike Xiaomi, is mutual and works as follows. The app sends a random challenge together with a constant key salt (provided by the backend during Pairing). The tracker sends back a MAC and a counter value, where the MAC is computed using the counter and the random challenge and is keyed using the pairing key corresponding to the key salt. The app checks that the MAC is valid and sends back a different MAC computed using the counter and keyed with the pairing key. The tracker checks the MAC, and then mutual authentication of the pairing key is achieved. The counter is updated on each run of the Authentication protocol.
Communication Fitbit sessions, unlike Xiaomi, have two different modes: live and normal. Live mode is not encrypted and monitors the tracker readings in real-time. Live mode data stays in the app, and is not relayed to the backend. On the other hand, normal mode synchronizes the data from the tracker to the backend. The synchronization process is encrypted with the shared pairing key by using either XTEA (extended TEA) encryption [NW97] or AES-EAX authenticated-encryption [BRW04].

Vulnerabilities and Attacks
We compare Xiaomi and Fitbit security mechanisms, investigate if Xiaomi vulnerabilities can be found in the Fitbit ecosystem, and evaluate how our OTA and SB attacks perform on Fitbit.
Vulnerabilities Fitbit proprietary security mechanisms are slightly better than Xiaomi's, but severe vulnerabilities still affect them. In particular, the Fitbit Pairing protocol does not send the pairing key (seed) in the clear, has strong user confirmation but still lacks device authentication. The Authentication protocol is mutual but is replayable. The Communication protocol partially uses encryption and integrity protection. For example, only normal mode data is encrypted.
OTA attacks The OTA app impersonation and MitM attacks from Figure 7 are still effective, as Fitbit Authentication is not replay-protected. Instead, the OTA tracker impersonation presented in Figure 6 does not work as Fitbit Authentication is mutual. However, the attacker can still impersonate a tracker using a replay attack similar to the one described in Figure 7. The OTA eavesdropping works only with unencrypted data (e.g., live mode data).
SB attacks The SB app impersonation attack on Android in Figure 8 is still effective. A malicious app can get valid authentication credentials from the backend and re-pair with the victim tracker (see Fig 4a in [CWP + 18]). Thus, we discovered a novel technique to steal trackers virtually. The SB eavesdropping suffers the same limitations as OTA eavesdropping.
Overall, the attacks' impact on Fitbit is lower than the one on Xiaomi but remains significant. For example, during impersonation or MitM, the attacker can only manipulate and tamper with the packets sent in cleartext. Nevertheless, the attacker can still abuse the unprotected live mode data to report worrisome health conditions to the user.

Attacking Fitbit with breakmi
We extended breakmi to analyze and attack the Fitbit ecosystem. We can clone Charge 2 trackers (including their advertised data and GATT servers) and the Fitbit app. Moreover, we can speak the Pairing, Authentication, and Communication protocols described before. We created custom scapy dissection classes to generate valid packets just like we did for Xiaomi. Fitbit uses static (random) BLE addresses, and we updated breakmi to support this privacy feature.
We use breakmi to perform the OTA impersonation and MitM attacks by replaying packets during the Fitbit Authentication. We also developed an extra module for our malicious Android app that performs the SB eavesdropping and app impersonation attacks. The latter provides the trackers' serial number and BLE address to the backend to reset the tracker's owner and then triggers pairing from the malicious app. This strategy is different from those we presented in Section 4.5, targeting Xiaomi.

Porting our Xiaomi Countermeasures to Fitbit
Fitbit Pairing, Authentication, and Communication protocols described in Section 8.1 can be strengthened by using a subset of the countermeasures proposed for Xiaomi in Section 7. In particular, unencrypted live mode data can be protected with C1 (authenticatedencryption), Pairing can be enhanced with C2 (authenticated key establishment), Authentication can be improved by adding replay protection as in C3. In addition, defense in depth can be achieved using C4 (BLE link-layer security). C5 (strong pairing confirmation) is not needed as is already provided by Fitbit pairing confirmation.

Reverse-Engineering Methodology
In this section, we describe our reverse-engineering methodology and how we applied it to perform our security analysis of Xiaomi and Fitbit ecosystems. We describe how we perform reconnaissance on a fitness tracking ecosystem. We explain how we analyze the traffic exchanged between tracker, app, and backend and how we apply static and dynamic analysis techniques to a mobile app. We also discuss the development of automated scripts for reverse-engineering and security assessment.

Trackers and Apps Reconnaissance
We now describe how we performed reconnaissance of the Xiaomi trackers and apps.
Regarding the tracker, we inspect its BLE GATT server using the "nRF Connect for Mobile" app [ASA21]. The app allows to scan, explore and communicate with BLE devices. We extract data from every service and characteristic, collecting the information shown in Table 6 and Table 7 in the Appendix. We identify Xiaomi proprietary GATT services (i.e., 0xFEE0, 0xFEE1). We find a set of characteristics protected by Authentication. For example, the Auth characteristic manages Pairing and Authentication, and the Steps and Heart Rate characteristics contain sensitive data.
We install Mi Fit and Zepp apps and interact with them. The apps are very similar as they share the same UI, communicate with the same backend, and provide the same interface to the tracker. The apps' UI does not show any information about the Pairing, Authentication, and Communication protocols that we RE. We also find that their codebase is very similar despite being closed-source. GadgetBridge [Fre21], an open-source project, provides some insights into the apps' internals.

BLE and Web Traffic Analysis
First, we intercept over-the-air BLE traffic with a BLE sniffer and confirm that Xiaomi BLE traffic is not encrypted. Then, since we control the smartphone running the app, we simply enable the "Bluetooth HCI Snoop Log" under the "Developer Options" and directly access BLE capture files. This option does not work correctly on some smartphones, but other alternatives exist (e.g., hcidump [KHG21], adb bugreport [And21]). We visualize and inspect BLE packets using Wireshark [Wir21], a network protocol analyzer. We find several recurring opcodes, shown in Table 2. We define the Pairing, Authentication, and Communication protocols and implement them in our automated scripts.
We run mitmproxy [Pro22] on our machine, a MitM proxy tool that intercepts and logs Wi-Fi and cellular networks traffic. We also configure our smartphone to redirect its web traffic to mitmproxy, and we install the mitmproxy CA (Certificate Authority) certificate. We intercept traffic going from the app to the Xiaomi backend while performing various operations with the tracker (e.g., adding a new tracker, synchronizing user activity data, completing workout sessions). We discover several API endpoints (e.g., account.xiaomi.com/oauth2/authorize, account.huami.com/v2/client/login, api-mifit-de2.huami.com/v1/device/binds.json). We inspect the traffic looking for interesting requests. For example, we reverse-engineer how Xiaomi registers new trackers on its backend. Then, we test the API endpoints by sending custom-made requests and monitoring their responses (the tests were performed according to Xiaomi's Bug Bounty program guidelines).
We merge BLE and Web capture files using a Wireshark utility better to visualize the sequentiality of the packets in Xiaomi protocols. We discover how the app acts as a proxy between the tracker and the backend during Pairing v2 and how the app sends security packets to the unprotected (custom) Chunked Transfer characteristic.

Mobile Companion Apps Analysis
We examine Mi Fit and Zepp apps' code to uncover the implementation of Xiaomi proprietary protocols from the source. We describe which static and dynamic analysis techniques we applied to our app analysis.
We start our static code analysis by extracting Mi Fit and Zepp APKs and decompiling them with JADX [Sky21], a Dex to Java decompiler. We discover that the Java code is obfuscated and difficult to navigate. We experiment with different deobfuscation tools, either by directly acting on the APK files (i.e., JADX deobfuscation utility, De-Guard [BRTV16], simplify [Fen20]) or by converting them into JAR files first (i.e., Java Deobfuscator [Sam20]), but they were unable to deobfuscate it. We utilize apktool [iBo21] to reverse-engineer the APK, inspect its resources and experiment with repackaging.
We manually inspect the apps' code. We search for keywords, trying several interesting words (e.g., Pairing, Bonding, Authentication, and Characteristic strings) and cryptographic functions supported by the tracker (e.g., MD5 and AES-ECB). We utilize the Mobile Security Framework (MobSF) [Abr21], an automated pen-testing and malware analysis tool, to inspect app components and for its automated binary analysis. We create control-flow graphs with Androguard [DG19], a Python reverse-engineering tool. Then, we perform dataflow analysis to help us to track the pairing Key. Ultimately, we find the code sections responsible for Pairing, Authentication, and Communication.
We apply dynamic analysis techniques to confirm that those code sections are actually executed at runtime. We rely on Frida [Ple21], a dynamic binary instrumentation toolkit that allows us to inject code during runtime execution. We use Frida hooks to log runtime variables and confirm they match with the values found in the capture files. We also experiment with editing variables at runtime and test the robustness of Xiaomi's security mechanisms when receiving unexpected values.

Development of Scripts
Throughout our RE efforts, we develop a set of scripts that automate time-consuming tasks. We aggregate and upgrade those scripts in breakmi, an extensible modular toolkit.
First, we build automated scripts to interact with a tracker's GATT server using a Python library called Bleak [BL21]. Our scripts automatically connect, explore, and display information about any BLE device. Then, we build scripts that replicate interesting operations on the tracker (e.g., read requests, enable notifications, firmware update, and factory reset).
We automate BLE traffic analysis by developing protocol dissectors on Pyshark [New21], a Python wrapper for packet parsing, and by using the scapy [BtSC21] packet crafting library. We reverse-engineer the binary structure of Xiaomi firmware so that we can extract firmware from capture files containing a firmware update. We also automate web traffic analysis via mitmproxy by developing scripts with the mitmdump utility. Our mitmdump scripts analyze hundreds of web requests to find pairing-related messages, identify their purpose and retrieve their parameters.
We automate our OTA attacks using Bleno [Mis21a] and Noble [Mis21b]. We create spoofed BLE peripherals that mirror services, characteristics, and advertising from legitimate MB 2/3/4/5/6 and Cor 2. We implement the Pairing, Authentication, and Communication protocols on the Auth, Steps, Heart Rate, and Chunked Transfer characteristics. We also implement the Pairing, Authentication, and Communication protocols on a BLE central and configure it to scan for and connect to the target trackers. During OTA MitM, the malicious BLE central and peripheral communicate with each other through websockets.

Related Work
We discuss the current state of the literature concerning the security and cryptographic analysis of Mi Band, Fitbit, and other embedded devices, the attacks on BLE protocols, and Android vulnerabilities and compare it with our work.

Attacks against Mi Band devices
Fereidooni et al. [FFM + 17] looked at ways to inject false data from the tracking application to the backend of 17 popular trackers, including a Mi Band device. Hilts et al. [HPK16] presented a security and privacy analysis of six trackers, including a Mi Band. These analyses are useful yet orthogonal to ours as they do not cover Xiaomi's proprietary security protocols. Some developers released tools for Mi Band 2 [Cre19] and Mi Band 3 [Yog19] able to trigger Xiaomi's Pairing v1 to unlock private data as described in [Ojh18]. Mi Band 4 tools such as [Sat21] require the knowledge of the pairing key, because nothing is known about Pairing v2 apart from it being "server-based" [Fre21]. Our attacks are much stronger and stealthy. They do not require knowledge of the pairing key, no specific action from the victim, do not disrupt the pairing between the victim's app and the victim's tracker, and do not reset the data (as they completely skip Pairing). In fact, we improved and corrected the attack in [Ojh18], that claims to be targeting Authentication when it is actually targeting Pairing v1. The Xiaomi protocols reverse-engineered in [Gie18] belong to Mi Home [Incg, BXC], the Xiaomi app that manages smart home devices, which does not support fitness trackers. To conclude, existing attacks were ad-hoc and partial. Our work is the first to systematize and generalize attacks against the Xiaomi fitness tracking ecosystem.
Attacks against Fitbit devices Rahman et al. [RCB13,RCT16] attacked the legacy ANT Communication protocol used by Fitbit Ultra and Garmin Forerunner and provided fixes for them. Cyr et al. [CHMS14] utilized Ubertooth to sniff OTA BLE traffic from a Fitbit Flex and an HTTP/HTTPS proxy, underlining several privacy-related issues, including device identification attacks. As described in [AV-15], Fitbit Charge was patched for being vulnerable to non-authenticated reads and a replay attack. Goyal et al. [GDS16] presented a comparative analysis of a Jawbone UP Move and Fitbit Charge. They discovered security issues in the GATT server, the mobile app, and the backend. Schellevis et al. [SJMdR16], reversed the Fitbit Charge HR authentication protocol through firmware analysis. Fereidooni et al. [FCS + 17] found ways to spoof Fitbit Flex and One data by tearing down the devices and analyzing their firmware. Classen et al. [CWP + 18] demonstrated attacks on Fitbit capable of leaking private data from a tracker, re-flashing a rogue firmware, and redirecting the app to a rogue cloud service. Other researchers could only perform eavesdropping while being near the target device, but we can do it remotely with our SB eavesdropping attack. Our SB app impersonation attack allows us to remotely inject fake data into the Fitbit account of our victim. Instead, previous studies required the ownership of the tracker or physical access. We also verified that Fitbit Charge 2 is still using the same protocols reversed in [CWP + WGP21] reverse-engineered the Tesla Model S and Model X key fob and found new vulnerabilities. Our study and methodology are similar to theirs, as they reversed proprietary protocols (i.e., Tesla's PKES and Pairing protocols), analyzed the BLE SoC, discussed cryptographic security measures, developed a proofof-concept and proposed countermeasures. Their findings could apply to other key fob manufacturers, similar to what we did with breakmi. We exploited the same vulnerabilities found both in Xiaomi and Fitbit devices, two of the largest players in the fitness tracker market. An orthogonal approach to reverse-engineering embedded systems is firmware and binary code analysis, adopted by Incision [TdHV + 21], an architecture and OS-agnostic RE framework. While similar tools are effective, we believe that our application-layer analysis is necessary to provide a full security assessment of an embedded device.

Vulnerabilities in Android
It is known that Android does not properly isolate Bluetooth keys among apps. For example, all devices' Bluetooth pairing keys are shared by all apps enabling co-located attacks [NyZD + 14,SB19]. This fact might affect fitness trackers that are relying on BLE pairing. However, this is not the case for Xiaomi, which only relies on proprietary security mechanisms at the application-layer. As a result, our attacks are still effective even if Android would fix the shared pairing key issue.
Smartwatches Prior work also studied the security of smartwatches, with Apple Watch as the main target. In particular, researchers focused on MagicPairing [HCR20], Apple's Bluetooth security mechanism, and reverse-engineering [HPK16,FFM + 17]. In this work, we focus only on fitness trackers, as smartwatches represent a separate class of devices with far more capabilities than fitness trackers. For example, smartwatches ship with more capable SoC (e.g., ARM general-purpose and multi-core application processors) than trackers (e.g., ARM microcontroller), so comparing the two devices classes would be unfair.

Conclusion
Xiaomi is a market leader in the fitness tracking industry. Little is known about this ecosystem's security and privacy properties despite managing the sensitive information of millions of users (such as health and personal data). Nonetheless, Xiaomi claims to be "committed to protecting the privacy, confidentiality, and security of personal information" in its Privacy Policy [Hua20]. We address this relevant issue by performing an extensive and up-to-date security evaluation of the Xiaomi fitness tracking ecosystem.
After extensive RE experiments, we uncover several worrisome issues. Xiaomi uses proprietary and undocumented security mechanisms to protect the communication between its trackers and apps. In particular, Xiaomi provides Pairing, Authentication, and Communication application-layer protocols over an insecure BLE connection. Xiaomi's approach is extremely risky as the security of its ecosystem relies on custom protocols that cannot be peer-reviewed in the open by the security community. Moreover, Xiaomi ignores standard BLE link-layer security mechanisms despite being supported by its devices.
We uncovered thirteen severe vulnerabilities (most of which were unknown) in the specification of Xiaomi custom application-layer protocols and exploited ten of them. The issues range from unilateral and replayable authentication to the lack of encryption and integrity protection. Being Xiaomi-compliant, the issues are exploitable on all devices using these protocols.
We demonstrate how to exploit the vulnerabilities with proximity-based (OTA) and remote (SB) attacks. Specifically, we describe over-the-air eavesdropping, impersonation, and MitM attacks, and remote eavesdropping and impersonation threats based on a malicious app co-located with the Xiaomi app.
We develop breakmi, a modular toolkit that automates RE experiments and attacks. breakmi includes protocol dissector, security mechanisms, and attacks modules. It is based on open-source software and requires cheap and available hardware. We test our toolkit on the Xiaomi ecosystem, and we extend it to also work on Fitbit. We will open-source breakmi.
We propose five effective countermeasures that fix the presented vulnerabilities and attacks. Our countermeasures provide stronger Pairing, Authentication, and Communication protocols. Moreover, we show how to integrate our protocols into the Xiaomi ecosystem.
We assess whether the Fitbit ecosystem suffers from the same vulnerabilities as Xiaomi. We find that Fitbit has better (still proprietary) Pairing, Authentication, and Communication protocols. Nevertheless, it is vulnerable to five out of the six attacks presented in this paper. We conduct such attacks on actual Fitbit devices, and we extend our toolkit to be compatible with Fitbit.
Overall, our work required an extensive and time-consuming RE effort. The hardest RE challenge was the server-based Pairing v2. More specifically, it took us six months to understand how the tracker, app, and backend interact among themselves while pairing. We spent two months developing breakmi, which automated most of our protocol analysis and reverse-engineering and quickly made up for the time investment. For example, when Xiaomi released the new MB 6, our toolkit immediately detected its similarity to the previous generation of trackers. Using this information, we could deploy our attacks on the MB 6 within a single day. Another example would be the process of adding support for the Fitbit ecosystem. We only spent two weeks on it, while we spent three months working on fully supporting the Xiaomi ecosystem. Table 6: Standard and vendor-specific services and characteristics exposed by every Mi Band GATT server. The first column shows the service name, and the second the characteristic name. The third column indicates the characteristic's access control policy (R = read, W = write, WWR = write without response, N = notify, I = indicate). The last column indicates which Mi Band supports the current characteristic.  Anhui Huami Information Technology Co. 0000fee1-0000-1000-8000-00805f9b34fb Auth 00000009-0000-3512-2118-0009af100700 N, R, WWR All Jawbone 0000fedd-0000-1000-8000-00805f9b34fb W All Coin, Inc. 0000fede-0000-1000-8000-00805f9b34fb R All Design SHIFT 0000fedf-0000-1000-8000-00805f9b34fb R All Apple, Inc. 0000fed0-0000-1000-8000-00805f9b34fb R, W All Apple, Inc. 0000fed1-0000-1000-8000-00805f9b34fb R, W All Apple, Inc. 0000fed2-0000-1000-8000-00805f9b34fb R All Apple, Inc. 0000fed3-0000-1000-8000-00805f9b34fb R, W All Unknown 0000fec1-0000-3512-2118-0009af100700 N, R, W 2, 3, 5, 6