Huawei Watch D2 BLE Pairing: Protocol & Vendor Lock-In Case

April 11, 2025

TL;DR: The Huawei Watch D2 doesn't use standard BLE pairing. Instead, it requires an 11-step proprietary handshake involving custom GATT characteristics, HMAC-SHA256 key derivation from a QR code, and application-level encryption. This is vendor lock-in by design -- it forces you into Huawei's Health app. The good news: the community has reverse-engineered it. Gadgetbridge now supports the Watch D2, and open-source implementations like huawei-lpv2 exist. The EU DMA is also starting to push back.

I expected standard Bluetooth pairing. Connect, bond, exchange data -- the usual. What I got instead was a proprietary cryptographic handshake that took weeks to reverse-engineer.

This happened while building D2Explorer -- my project to connect the Huawei Watch D2 to Linux and macOS without Huawei's Health app. After sorting out BlueZ's pairing agent issues and migrating to the cross-platform SimpleBLE library, I thought the hard part was over. The hard part hadn't started.

What You'd Expect: Standard BLE Pairing

Here's how Bluetooth LE pairing is supposed to work:

Scan for the device by its advertised name (e.g., "HUAWEI WATCH D2-CA0").
Connect with peripheral.connect().
The OS handles pairing/bonding -- a PIN prompt, Just Works, whatever the security level requires.
Once bonded, interact with standard or custom GATT services.

The OS manages security. Your application focuses on data. Simple.

What Actually Happens: An 11-Step Proprietary Handshake

What the Watch D2 actually requires is entirely different. The basic BLE connection is just the door. Behind it is a custom application-level authentication protocol that Huawei built on top of standard BLE -- what the community calls Huawei Link Protocol v2 [1].

Standard BLE pairing mechanisms are bypassed entirely. To authenticate and access any meaningful data, you need to navigate this sequence over custom GATT characteristics:

Connect -- establish the basic BLE link.
Enable Notifications -- immediately subscribe to notifications on characteristic 0000fe02-.... This is timing-critical -- miss the window and the watch drops you.
GetLinkParams -- immediately send a custom command (Service ID 0x0001, Command ID 0x0001) to the write characteristic 0000fe01-....
Receive Server Nonce -- wait for a notification containing the watch's random challenge.
Derive Secret Key -- generate a client nonce. Combine the server nonce, client nonce, and the numeric value from the watch's QR code. Run HMAC-SHA256 (using the QR code value bytes as the key) to derive a shared secretKey_.
AuthRequest -- send the client nonce and an HMAC digest (using the derived secretKey_) back to the watch (Service 0x0001, Command 0x0002).
Verify Server Token -- receive the watch's authentication token. Verify it using the secretKey_ and exchanged nonces.
SetTime -- send current time and timezone offset, encrypted with the secretKey_ (Service 0x0002, Command 0x0003).
QrToken -- send the QR code value back, encrypted with the secretKey_ (Service 0x0001, Command 0x0004).
AuthResult -- send a final confirmation, encrypted with the secretKey_ (Service 0x0001, Command 0x0005).
Done -- only now is the connection authenticated.

Custom TLV message formats. CRC checks. Service and command IDs. Application-level encryption. Millisecond-sensitive timing. All of this happens above the BLE stack, invisible to standard Bluetooth tools.

The QR code on the watch's screen is the shared secret. Without it, you can't derive the key. Without the key, you can't authenticate. Without authenticating, the watch gives you nothing.

Why Huawei Does This

Huawei might frame this as enhanced security. The practical effect is vendor lock-in.

High barrier to entry -- the protocol is undocumented. Reimplementing it requires reverse-engineering the Huawei Health app (13,000+ classes, 64,000+ methods [2]) or analyzing BLE traffic. This actively discourages third-party apps.
No interoperability -- standard fitness apps can't connect. The watch only completes its handshake with software that knows the proprietary steps -- primarily Huawei's own Health app.
Ecosystem control -- users are forced into Huawei Health and its cloud services. Switching devices or platforms later means losing your health data history.
Reduced user choice -- want to use an open-source app? Want more privacy control over your health data? Tough luck -- unless someone reverse-engineers the protocol first.

And here's the thing: this isn't unique to Huawei. The WatchWitch research project [3] documents how all major vendors -- Apple, Samsung, Xiaomi -- use proprietary BLE protocols to enforce ecosystem lock-in. Apple Watch is "incredibly tightly coupled with Apple's iPhone and iCloud ecosystem, using proprietary protocols that are unavailable to third parties." It's a systemic industry problem.

But Huawei's implementation is particularly aggressive. BLE allows custom services, sure. But replacing the fundamental authentication mechanism with a proprietary gatekeeper is a different game entirely.

The Security Irony

The obvious defense is "we do this for security." Let's examine that.

The BlueDoor vulnerability research from Tsinghua University [4] tested 16 BLE devices including the Honor Band 3 (same Huawei ecosystem) and achieved silent pairing without user authorization on most of them. The proprietary protocol didn't prevent this.

Meanwhile, the protocol itself has been reverse-engineered multiple times -- by the Gadgetbridge community, by the huawei-lpv2 project, by the researchers who presented at Easterhegg 2019 [2], and by me for D2Explorer. Security through obscurity with an expiration date.

The HMAC-SHA256 key derivation from the QR code is actually decent cryptography. But that's not the point. You could achieve the same security properties using standard BLE Secure Connections with an out-of-band pairing method (like NFC or QR code) -- without locking out every third-party application in the process.

The Community Fights Back

The community hasn't accepted this quietly.

Gadgetbridge

Gadgetbridge -- the open-source Android app for wearable devices -- now supports the Huawei Watch D2 [5]. You can pair your watch without Huawei's Health app. It took significant reverse-engineering effort (see PR #2462 [6]), and there are limitations -- ECG functionality is disabled when paired with Gadgetbridge [7] -- but it works.

The authentication implementation in Gadgetbridge handles auth version 3, calculating the bonding key from the pairing message (service 0x01, command 0x0e) and using it for decryption. A 17-digit Huawei account ID is required for the authentication key negotiation.

huawei-lpv2

The huawei-lpv2 project provides a pure Python implementation of Huawei's Link Protocol v2 [8]. It's maintained, has multiple forks, and serves as a reference for anyone building Huawei wearable integrations outside the official ecosystem.

D2Explorer

My own D2Explorer project took a different path -- building a C++ implementation using SimpleBLE that works on Linux and macOS. The work involved:

Implementing TLV serialization/deserialization (HuaweiProtocol).
Building precise message constructors (ProtocolMessageBuilder).
Getting the cryptographic steps right -- nonce generation, HMAC-SHA256, XOR encryption (CryptoOperations, CryptoUtils).
Managing strict state transitions and timing (HuaweiPairingProtocol, ProtocolStateManager).
Debugging failures caused by millisecond-level timing mismatches and subtle crypto errors.

D2Explorer exists because Huawei's protocol made it necessary. It's the workaround required for basic functionality outside the walled garden.

AsteroidOS

AsteroidOS 2.0 launched in February 2026 as a major update to the open-source Linux-based smartwatch OS [9]. It now supports ~30 devices including the Huawei Watch and Huawei Watch 2, with features like always-on display and Tilt-to-Wake. A full open-source alternative to Huawei's firmware.

The Regulatory Tide

The EU isn't just watching. The Digital Markets Act (DMA) is starting to force change [10].

In December 2025, Apple released iOS 26.3 with AirPods-like pairing for third-party devices -- including Huawei smartwatches -- specifically to comply with DMA requirements [11]. Background syncing between Huawei watches and iPhones is already operational in Europe.

The DMA mandates that gatekeepers provide interoperability for connected devices. This directly targets the kind of proprietary BLE lock-in that Huawei (and Apple, and everyone else) has been practicing. Full rollout of these interoperability features is expected throughout 2026.

This is significant. For the first time, there's regulatory pressure to standardize what vendors have deliberately kept proprietary. The technical community can reverse-engineer protocols one by one, but regulation can change the incentive structure for the entire industry.

What This Means

The Huawei Watch D2's pairing protocol is a case study in how custom protocols over standard transports can enforce vendor lock-in. The layers of proprietary cryptography, custom message formats, and timing-sensitive handshakes exist not because standard BLE can't handle authentication -- it can -- but because proprietary protocols keep users inside the ecosystem.

The picture is changing, though. Gadgetbridge gives you an alternative right now. The EU DMA is forcing interoperability at the regulatory level. And open-source projects like huawei-lpv2, D2Explorer, and AsteroidOS prove that the community will reverse-engineer what vendors try to lock down.

Building D2Explorer was less about Bluetooth and more about cryptographic detective work. It underscores something that shouldn't need underscoring: you should be able to access your own health data with the software of your choice.

References

1. huawei-lpv2: Pure Python implementation of Huawei BLE Link Protocol v2 -- Open-source reference implementation of the protocol.
2. All Your Fitness Data Belongs to You: Reverse Engineering the Huawei Health Android App -- Easterhegg 2019 conference talk documenting the reverse engineering effort. Slides (PDF).
3. WatchWitch: Academic Research on Smartwatch Interoperability -- Documents how all major vendors use proprietary protocols for ecosystem lock-in.
4. BlueDoor: Breaking the Secure Information Flow via BLE Vulnerability (Tsinghua University) -- Found silent pairing vulnerabilities in 16 BLE devices including Honor Band 3.
5. Gadgetbridge: Huawei/Honor Device Support -- Official support page for Huawei and Honor wearables.
6. Gadgetbridge PR #2462: Initial Huawei/Honor Support -- The pull request that added Huawei device support to Gadgetbridge.
7. Gadgetbridge Issue #4918: ECG Disabled with Gadgetbridge -- Known limitation when using Gadgetbridge instead of Huawei Health.
8. Gadgetbridge: Huawei/Honor Pairing Guide -- Step-by-step pairing instructions for Huawei devices.
9. AsteroidOS 2.0 Release -- Open-source smartwatch OS now supporting ~30 devices including Huawei watches.
10. EU Digital Markets Act: Interoperability Requirements -- DMA provisions mandating connected device interoperability.
11. iOS 26.3 DMA Features: Third-Party Smartwatch Pairing -- Apple's compliance with EU interoperability mandates for wearable devices.

BlueZ Pairing Fix: External Python Agent & D-Bus Polling -- the precursor to this investigation. Before we could tackle Huawei's proprietary protocol, we had to fix BlueZ's AuthenticationFailed errors with standard BLE pairing.
Fix Android Emulator Bluetooth on M1 Mac using Bumble & API 32 -- another BLE integration battle, this time bridging a Mac's physical Bluetooth radio into the Android Emulator.