We recently came across reports covered by news outlets about electric vehicles, specifically e-rickshaws, being remotely hacked and stalled in the middle of busy roads. The attackers were using Android apps, some of which were available on the Google Play Store under names like BAT-BMS, Epoch Li-on and Overkill Solar. These apps were apparently able to connect to some specific brands of the Battery Management System (BMS) inside these vehicles over Bluetooth and shut down the power MOSFETs, effectively cutting power to the motor while the vehicle was in motion.
The Indian government responded by removing several of these apps from the Play Store. That seemed like a reasonable first step, but it immediately raised a question for us: does removing the app actually solve the problem, or is the real issue deeper than that?
We suspected the latter. If a third-party app, one not even made by the BMS manufacturer, could gain control over the battery's safety switches, then the vulnerability isn't in the app. It's in the BMS itself. Removing one app from the store doesn't stop anyone from writing another one, or from sending the same Bluetooth commands directly from a laptop or microcontroller.
So we decided to test it ourselves. We purchased three of the most widely used BMS brands in the consumer and light-EV market JBD (Jiabaida), Daly, and JK (Jikong) and set out to determine whether their Bluetooth Low Energy (BLE) interfaces had any meaningful security against unauthorized access. But what we found was more shocking! All three BMS platforms permitted unauthenticated remote control of their safety-critical MOSFETs. An attacker within BLE range can scan, connect, read live battery telemetry, and toggle the charge and discharge FETs without pairing, bonding, password verification, or any other form of firmware-level authentication.
To demonstrate the impact of these findings, we also built a proof-of-concept web application to visually demonstrate this vulnerability, and developed a hardware countermeasure that existing BMS owners can deploy right now to protect their systems. This article covers our complete journey through this investigation.
A Brief Primer on BLE
Before we examine the vulnerabilities identified during this research, it is useful to understand the Bluetooth Low Energy (BLE) concepts that make them possible. While BLE is designed for low-power, short-range wireless communication, it also includes a well-defined data model and several built-in security mechanisms. Understanding these fundamentals provides the context needed to see why the BMS devices we tested are vulnerable.
Bluetooth Low Energy (BLE), introduced as part of Bluetooth 4.0, differs significantly from Classic Bluetooth. Rather than exposing a continuous serial data stream through the Serial Port Profile (SPP), BLE organises communication using the Generic Attribute Profile (GATT). Under the GATT model, a device exposes its functionality through a hierarchy of Services, each identified by a unique UUID (Universally Unique Identifier). Each service contains one or more Characteristics, also identified by UUIDs, which represent individual pieces of data or control interfaces. A characteristic consists of the actual value along with a set of properties that define how it may be accessed.
In practice, a Service represents a logical grouping of related functionality, such as battery telemetry or configuration settings. Within that service, Characteristics expose specific values such as pack voltage, cell temperatures, state of charge, or control commands. BLE identifies these objects using UUIDs, which are 128-bit identifiers typically represented in hexadecimal. Standard BLE services use shortened 16-bit UUIDs; for example, 0x180F identifies the standard Battery Service, whereas vendor-specific implementations generally use custom 128-bit UUIDs.
Each characteristic also advertises one or more access properties that determine how a connected client may interact with it. The Read property allows a client such as a phone or laptop to retrieve the current value stored by the device. The Write property enables the client to send data or commands to the device, making it the mechanism through which configuration changes or control operations are typically performed. Some devices additionally support Write Without Response, which omits the acknowledgement normally returned by the device, improving throughput at the cost of reliability. The Notify property allows the device to asynchronously push updates to subscribed clients without requiring repeated polling, making it the standard mechanism for streaming live telemetry such as voltage, current, and temperature measurements.
BLE also includes a comprehensive security architecture designed to prevent unauthorized access. Pairing establishes a trusted relationship between two devices using methods such as Passkey Entry, Numeric Comparison, or Out-of-Band authentication. Once pairing has been completed, Bonding allows the generated security keys to be stored so that future connections can be established securely without repeating the pairing process. These keys are then used to enable Encryption, protecting all subsequent communication over the BLE link. At the application layer, Authorization provides an additional level of access control by allowing the device to determine whether a connected client is permitted to perform sensitive operations, such as modifying configuration parameters or issuing control commands.
The most important observation for this research is that BLE already provides the mechanisms necessary to secure sensitive devices such as Battery Management Systems. The vulnerabilities described in the following sections do not arise from weaknesses in the BLE protocol itself; rather, they resulted from manufacturers choosing not to implement pairing, encryption, authorization, or other available security controls, leaving critical functionality accessible to any nearby BLE client.
Our Investigation
Testing the Official Apps
We began our investigation not with code or protocol analysers, but with the official manufacturer of mobile apps. Our goal was simple: before we try to bypass anything, let's see what security the manufacturers themselves claim to provide.
JBD - "JBD BMS" and "XiaoXiang Electric"
JBD offers two apps that behave similarly. When a user connects to a JBD BMS as a guest, they can view battery information but cannot access control functions. To gain full control, the user must register a JBD account and bind the BMS device ID to that account. The binding is stored on JBD's cloud servers, and the app checks the cloud database for ownership before granting control access.
Here's the problem: if a BMS owner purchases the unit and does not register and bind it to their account, anyone else can create their own JBD account and bind that BMS to theirs, at which point they get full control through the official app itself. More importantly, even this account-binding mechanism is only enforced by the app. The BMS hardware itself, the JBD DP04S007 we tested, accepts control commands from any connected BLE device without authenticating anything. JBD does not provide any on-device password authentication option on the models we tested.
Daly - "DALY BMS"
Daly's official app does not require account creation. Any user can connect directly to the BMS. To access control functions like FET toggling, the app prompts for a password. The default password is `123456`, and users can change it. The password is stored on the BMS hardware itself.
However, our testing on the Daly 4S12V60A confirmed something important: the BMS firmware accepts control commands over BLE regardless of whether a password has been sent in the session. The password prompt exists only in the app's user interface. It is a client-side gate. If you bypass the app and send the control command directly to the BLE characteristic, the BMS executes it without question.
JK - "JK BMS"
JK's app follows a similar pattern to Daly. Users can connect and set a password to protect their BMS, and the password is stored on the BMS hardware. But once again, direct BLE command injection bypasses this password entirely. The JK-B2A8S20P we tested processes write commands to its control characteristics without checking any authentication state. The password is only verified by the official app, not by the firmware.
Going Deeper: Protocol-Level Analysis
After confirming that all three brands had either no app-level security or trivially bypassable security, we needed to verify whether the underlying BLE protocol itself enforced any restrictions.
Our approach involved connecting to each BMS and enumerating all GATT services and characteristics to identify which ones are used for data exchange. We analysed the properties of each characteristic to determine which support Write (for sending control commands) and Notify (for receiving telemetry). To characterise the BLE interface, we performed protocol analysis using publicly available resources and controlled experimentation. Once reliable communication had been established, we verified normal telemetry functionality before assessing the control operations.
For responsible disclosure reasons, we are deliberately not publishing the specific BLE service and characteristic UUIDs, the command byte sequences, or the frame structures used by any of the three brands. What we can say is that all three follow a broadly similar pattern: the client writes a binary command frame to the BMS's writable characteristic, and the BMS processes it and sends a response back via notifications. The command frame contains a header marker, a target address byte, a command ID, a data payload, and a checksum. Telemetry commands return pack voltage, current, cell voltages, temperatures, SOC, and MOSFET states. Control commands toggle the charge and discharge MOSFETs.
The fundamental finding is simple: the BMS firmware does not distinguish between a legitimate user and an attacker. Any device that can establish a BLE connection and write the correct bytes to the correct characteristic can issue control commands.
Comparative Vulnerability Analysis
The following table summarises our findings across all three BMS brands side by side.
| Security Dimension | JBD (DP04S007) | Daly (4S12V60A) | JK (B2A8S20P) |
| BLE Pairing Required | No | No | No |
| BLE Bonding / Encryption | None | None | None |
| App Password Protection | Account binding (cloud) | Yes (user-configurable) | Yes (user-configurable) |
| Password Stored On | JBD cloud servers | BMS hardware | BMS hardware |
| Password Enforced by BMS Firmware | No | No | No |
| Direct BLE Command Accepted | Yes - unrestricted | Yes - unrestricted | Yes - unrestricted |
| Telemetry Readable Without Auth | Yes | Yes | Yes |
| FET Control Without Auth | Yes | Yes | Yes |
| Third-Party App Control | Yes (Epoch Li-ion, Overkill Solar) | So far, none (Official Only) | So far, none (Official Only) |
| Firmware-Level Authentication Mechanism | None detected | None detected | None detected |
The bottom line is that all three brands fail at the most fundamental level. The BMS firmware itself has no mechanism to verify that the device issuing control commands is authorised to do so. The "security" offered by their official apps is entirely cosmetic; it exists only in the app UI and can be bypassed by anyone who communicates directly with the BLE interface.
Our Test Setup
All testing was conducted in a controlled laboratory environment using our own equipment. We used a 4-cell (4S) 18650 lithium-ion battery pack connected to an Electronic Load Measurement Tool for safe, controlled discharge testing. The BLE host was a Windows PC with a Bluetooth adapter running Python with the `bleak` BLE library. The three BMS units under test were the JBD DP04S007, the Daly 4S12V60A, and the JK-B2A8S20P. We verified MOSFET state changes through both BLE telemetry readback and physical measurement of load current on the electronic load.
Demonstrating the Vulnerability: The BMS Analyser App
To make this vulnerability tangible and visually demonstrable, we built a proof-of-concept web application called BMS Analyser. The app runs as a local web server on a PC with Bluetooth capability, and any device on the same WiFi network (a phone, tablet, or another laptop) can open its browser and interact with the BMS in real time. This approach lets us demonstrate the vulnerability to the viewer by seeing live battery data and interactive MOSFET toggle switches on their phone screen.
Architecture
The backend is written in Python using Flask. Since BLE operations are inherently asynchronous (using the bleak library), we run a dedicated asyncio event loop in a background thread. Flask's synchronous request handlers submit BLE coroutines to this loop and block until the result is available. This bridge pattern lets us keep the simplicity of Flask's REST API while still performing non-blocking BLE operations under the hood.
Driver Abstraction
We designed the BLE communication layer around a clean driver abstraction. An abstract BMSDriver base class defines the interface: scan, connect, disconnect, get_telemetry, set_charge_fet, and set_discharge_fet and three concrete implementations, JBDBLEDriver, DalyBLEDriver and JKBLEDriver, encapsulate all the brand-specific protocol details. Each driver handles BLE service discovery, command frame construction with proper headers, addresses, payloads and checksums, notification response parsing, and the protocol quirks unique to each brand. For instance, Daly streams cell voltages across multiple notification frames that need to be reassembled by frame number, while JK sends 300-byte cell info responses that arrive in BLE MTU-sized chunks and must be accumulated before parsing.
The User Interface
The frontend is a single-page HTML/CSS/JavaScript application that polls the backend every 1.5 seconds for telemetry data. It presents a BLE scanner panel where you select a brand and scan for nearby devices, with signal strength indicators and a scrollable device list. Once connected, a live telemetry dashboard shows pack voltage, current, power, SOC percentage with an animated progress bar, individual cell voltages rendered as a bar chart, and temperature readings. Below that sits the MOSFET control panel: two toggle switches for the charge and discharge FETs, with colour-coded status cards that update in real time.
One practical challenge sometimes in the UI is toggle switch glitching. Because telemetry is polled every 1.5 seconds, there's a race condition: when a user toggles a FET, the command takes 1-2 seconds to propagate to the BMS hardware. If a telemetry poll completes during that window, it reads the old MOSFET state and overwrites the switch position back, causing it to visually bounce between states.
The Solution: BMS Protector
Discovering a vulnerability without proposing a solution is only half the job. So we developed a hardware-based security shield that existing BMS owners can deploy immediately, without any modifications to their BMS itself.
The Core Insight
BLE peripherals like these BMS units typically support only one active GATT connection at a time. This is a fundamental limitation of most BLE peripheral firmware stacks; once a client is connected, the device stops advertising and rejects additional connection attempts. We realised we could exploit this limitation defensively: if a trusted device permanently occupies the BMS's only BLE connection slot, no attacker can connect.
How It Works
The ESP32 BMS Protector is a small, inexpensive microcontroller. We used the Seeed Studio XIAO ESP32-S3 for its tiny form factor that connects to your BMS via BLE and holds the connection 24/7. By maintaining the active BLE GATT session link, the protector keeps the connection slot occupied. Because the BMS's single connection slot is now permanently occupied by the ESP32, any external device, whether it's an attacker's phone or a malicious app that tries to scan and connect, will either not see the BMS at all or get a connection-refused error.
When you legitimately need to use your phone app or the BMS Analyser to check battery status, you can temporarily release the lock by pressing the ESP32's built-in BOOT button or by using its built-in Wi-Fi web portal. The protector disconnects from the BMS, giving you a configurable window (default: 5 minutes) to connect with your normal tools. Once the timer expires, the ESP32 automatically reconnects and re-locks the BMS.
On first power-up, the ESP32 has no saved configuration, so it enters CONFIG mode and creates a Wi-Fi access point called BMS-Shield-Setup. You connect your phone to this AP, open a browser, and a captive portal lets you select your BMS brand (JBD, Daly, or JK), scan for nearby BLE devices, and select your BMS from the list. The ESP32 saves this to non-volatile storage and reboots into LOCKED mode. From then on, it automatically connects to your BMS on every boot and holds the connection.
The onboard LED communicates the current state visually: a double-blink pulse in CONFIG mode, solid ON when locked and connected, slow blink when attempting to reconnect after a dropped connection, and fast blink during the temporary release window. A long press (5+ seconds) on the BOOT button triggers a factory reset, clearing the saved configuration and returning to CONFIG mode.
Limitations and Recommendations
The proposed solution is a mitigation rather than a permanent fix. It requires additional hardware for each BMS unit, and consumes a small amount of standby power. Additionally, a determined attacker with specialised radio equipment could potentially jam the BLE connection to force a disconnect. While these limitations make the workaround practical for many applications, they highlight that the underlying vulnerability remains within the BMS firmware itself.
The long-term solution must come from BMS manufacturers through the implementation of proper BLE security. At a minimum, devices should support BLE pairing with passkey entry, requiring a unique numeric passkey during the initial connection to prevent unauthenticated access. BLE bonding should be enabled so that only previously paired devices can reconnect, and all BLE communication should be encrypted using AES-CCM to protect against eavesdropping and packet injection.
At the firmware level, the most critical improvement is robust command authentication. Before executing any safety-critical command such as MOSFET control, parameter modification, or factory reset, the firmware should verify that the connected device has successfully authenticated using a secure challenge-response mechanism rather than relying on a plaintext password transmitted over BLE. Permission levels should also be separated, allowing unauthenticated users to read battery telemetry while restricting control functions exclusively to authenticated devices.
GitHub Repository
Conclusion
The BLE security vulnerability we discovered across JBD, Daly, and JK BMS units is not an edge case or an obscure protocol weakness. It is a systemic design failure, a conscious decision (or oversight) by manufacturers to ship thousands of units with no authentication on safety-critical control functions. The technology to fix this has existed for over a decade in the BLE specification itself. Pairing, bonding, encryption, and authorisation are all well-defined, well-supported standards. The missing ingredient is not capability; it is priority.
We hope this research serves as a signal to the BMS industry that security cannot be an afterthought. Until manufacturers respond with proper firmware-level security, the ESP32 BMS Protector offers a practical, deployable defence for the thousands of vulnerable units already in the field.
