x
H H
← All Research Unauthenticated BLE Command Injection in the Fire-Boltt BSW013 Smartwatch — banner
IoT Security Featured

Unauthenticated BLE Command Injection in the Fire-Boltt BSW013 Smartwatch

By Pratham A Gowda · Cyber Security Researcher Aug 4, 2026 9 min read
#Bluetooth Low Energy#BLE Security#Smartwatch Vulnerability#CWE-306#Wearable Privacy

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.

1. Why This Matters

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.

2. Methodology

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.

Fire-Boltt BSW013 BLE vulnerability diagram

3. Entropy and Authentication Analysis

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.

4. Finding A — Unauthenticated Notification Injection

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.

5. Finding B — Pairing-Triggered Plaintext Information Disclosure

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.

6. Finding C — Unauthenticated Live Heart Rate Disclosure

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.

7. Impact

  • Notification spoofing: arbitrary, legitimate-looking alerts can be pushed to a victim's wrist from up to 10–30m away, with no interaction — useful for harassment, spam, or social engineering.
  • Device fingerprinting: a successful spoofed-pairing social engineering attempt yields plaintext hardware identifiers useful for tracking or targeting.
  • Sensitive health data exposure: live heart rate can be silently harvested by anyone nearby, without the wearer's knowledge — a genuine privacy exposure of personal health information.

No evidence of arbitrary code execution or firmware-level compromise was found; this research did not extend to firmware analysis.

8. Root Cause

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.

["Unauthenticated notification injection with vibration alert — zero user interaction required", "Pairing-triggered plaintext disclosure of MAC address, chipset, and model identifiers, even while the BLE link remains unbonded", "Live heart-rate data readable by any nearby unbonded, unauthenticated attacker whenever monitoring is active", "Root cause is a complete absence of authentication, session binding, and replay protection in the watch's BLE command protocol"]
["Enforce BLE bonding (e.g. LE Secure Connections) before accepting any GATT write to command characteristics or subscriptions to sensitive characteristics like Heart Rate Measurement", "Bind app-layer session state to real BLE bonding so a device can't appear 'paired' at the app level without genuine link-layer authentication", "Add replay protection via a rolling nonce, counter, or timestamp validated device-side", "Never transmit device-identifying information in response to an unauthenticated or newly-unbonded connection"]
PDF
Full Research Report
Download the complete write-up as a PDF
Download PDF

Need help responding to a threat like this?

Our security team can help you investigate, contain, and remediate.

Contact Our Security Experts