A field researcher's technical breakdown of an unauthenticated BLE vulnerability in the Fire-Boltt BSW013 smartwatch — allowing notification spoofing, plaintext device fingerprinting, and live heart-rate disclosure to any nearby attacker.
Wearables quietly collect some of the most personal data we generate — location, notifications, and increasingly, our heart rate. That makes the security of the radio link between a smartwatch and the outside world just as important as the security of the app that talks to it.
This advisory documents three related findings in the Fire-Boltt BSW013 smartwatch (firmware V0.0.8), all stemming from the same root cause: the watch's custom BLE command protocol performs no authentication, no session binding, and no freshness validation on incoming writes. The only integrity check present is a CRC-16 checksum — which confirms a packet is well-formed, not that it came from someone the watch should trust.
Bluetooth Low Energy devices are expected to gate sensitive functionality behind pairing and bonding. When that gate is missing, anyone with a $20 BLE-capable radio and no prior relationship to the device can talk to it as if they were the paired phone. That's the situation uncovered here across three independent findings, ranging from Medium to High severity.
The research began with HCI snoop logging on an Android device paired with the target watch, capturing tens of thousands of real BLE packets during normal phone-to-watch operation. Those packets were parsed down through the HCI → L2CAP → ATT protocol stack to isolate GATT write traffic, which was then subjected to entropy and structural analysis.
This surfaced dozens of unique command signatures across a single GATT characteristic. The packet checksum algorithm was empirically reverse-engineered by testing standard CRC16 variants against real (data, checksum) pairs pulled from the capture, which confirmed a CRC-16/ARC implementation. Proof-of-concept behavior was then validated from an independent Linux laptop with no prior pairing relationship to the watch.
Byte-level entropy across the captured write traffic measured roughly 4.2 bits out of a possible 8 — consistent with structured, unencrypted binary data rather than anything cryptographically protected. No session tokens, nonces, or message authentication codes were found anywhere in the capture, and identical payloads were observed recurring byte-for-byte with no variation, confirming there's no per-message freshness mechanism at all.
An attacker within BLE range can open an independent GATT connection to the watch — no pairing or bonding required — and write a crafted command to the watch's custom characteristic. The watch immediately vibrates and displays attacker-supplied title and body text as a notification, with zero interaction required from the wearer. Testing confirmed this works with fully custom, non-replayed content, meaning an attacker has real control over what appears on the victim's wrist, not just the ability to replay a captured message.
Sending a specific identity/handshake command causes the watch to surface its native pairing confirmation prompt to the wearer. If the wearer taps Accept, the watch transmits a plaintext data dump over the notification channel containing the device name, Bluetooth MAC address, chipset vendor, and internal model identifiers. Critically, the underlying BLE connection remains in a "Not Bonded" state throughout — the watch's on-screen pairing dialog is disconnected from actual link-layer authentication, so this data goes out over an unbonded, unencrypted connection regardless of what the prompt implies to the user.
The most severe finding requires no custom protocol knowledge at all. The watch exposes the standard Bluetooth SIG Heart Rate Measurement characteristic to any client that subscribes to it — no pairing, bonding, or confirmation of any kind. While the wearer has heart rate monitoring active (common during workouts), a nearby attacker can silently read live BPM readings for as long as that session runs. This was verified directly with a standard BLE inspection tool, on a connection that remained explicitly "Not Bonded" throughout.
No evidence of arbitrary code execution or firmware-level compromise was found; this research did not extend to firmware analysis.
All three findings trace back to the same design gap: the watch's proprietary command protocol — running over a custom GATT service resembling the Nordic UART pattern — never verifies who's on the other end of the connection, never binds a session, and never checks that a command hasn't been seen before.
Our security team can help you investigate, contain, and remediate.
Contact Our Security Experts