Abusing Domestic EV Chargers through Bluetooth and USB

Abusing Domestic EV Chargers through Bluetooth and USB

Speakers: Riccardo Mori, Security Engineer, Quarkslab; Robin David, Software Security Researcher, Quarkslab

Conference: REcon 2025

YouTube: https://www.youtube.com/watch?v=cH0lDqTtFew

Overview

Electric vehicle (EV) adoption surged 25% worldwide in 2024, but the charging infrastructure expanding alongside it has not kept pace with basic security expectations. At REcon 2025, Quarkslab researchers Riccardo Mori and Robin David detailed a comprehensive security assessment of the Heltec (hotel) Maxi Charger AC — a Level 2 EVSE (Electric Vehicle Supply Equipment) device used both in domestic settings and commercial parking facilities. Their work, conducted as part of the Pwn2Own Automotive 2025 competition, uncovered a firmware encryption scheme that required novel cryptanalysis to defeat, a Bluetooth-based stack buffer overflow that chains into a jump-oriented programming exploit, a USB control endpoint vulnerability, and a persistence mechanism that survives over-the-air firmware updates by targeting the STM32 bootloader. The research demonstrates that a compromised EV charger is not just a broken device — it is a pivot point into home networks, a potential source of free electricity, and in extreme scenarios, a threat to the electric vehicle itself.

Background

▶ Watch: Introduction: EV charger target overview and OCPP protocol (1:28)

Level 2 EV chargers operate on AC power and provide a significant step up in charging speed over standard wall outlets. Increasingly they are connected devices — the Heltec Maxi Charger AC exposes Bluetooth Low Energy (BLE), Wi-Fi, Ethernet, NFC, USB-C, and a 4G/LTE interface. This broad connectivity reflects a design optimized for user convenience: a companion Android application provides over-the-air firmware updates, remote monitoring, and session management. From a security standpoint, each of these interfaces is an attack surface.

The Quarkslab team selected this specific device for two reasons: it was an available target in the Pwn2Own Automotive 2025 competition, and they had already purchased the hardware in a previous year. Their research followed a disciplined path from firmware acquisition through vulnerability discovery to reliable exploit development.

Key Findings

▶ Watch: Firmware decryption: brute-forcing the cipher key (7:23)

The research produced two independently confirmed code execution chains:

• CVE (Bluetooth/BLE): A stack buffer overflow in the BLE AT-command parser on the STM32 microcontroller, exploitable by any BLE-capable device within radio range. No user interaction required beyond the automatic "Just Works" BLE pairing.
• CVE (USB): A buffer over-read/overwrite via the wLength field of the USB control endpoint setup packet, exploitable over the physical USB port.

Both vulnerabilities were present in firmware that shipped with no exploit mitigations — no ASLR, no stack canaries, no W^X enforcement.

Technical Deep Dive

▶ Watch: Hardware teardown: STM32 power board and TFT display firmware (10:22)

Hardware Architecture

Before analyzing the firmware, the team mapped the device's internal topology. The control board contains:

• STM32 microcontroller: The main application processor running the device logic, connected directly to all critical subsystems.
• ESP32 module: Handles Bluetooth and Wi-Fi connectivity, translating BLE messages into AT commands sent over UART to the STM32.
• External Winbond flash storage: Stores the encrypted firmware used for OTA updates.
• NFC module: Connected over UART.
• 4G/LTE board: Connected over UART for cloud communication using the OCPP (Open Charge Point Protocol).
• Power board: A separate STM32 running its own firmware, connected to the control board over CAN bus and directly responsible for power delivery to the charging connector.

The control board is the critical target: it orchestrates all other components and can directly flash their firmware.

Firmware Acquisition

The device offers two update paths: Wi-Fi and Android Bluetooth application. The team chose the Android app route. The application was obfuscated with a commercial tool (Seeno), but Frida dynamic instrumentation allowed them to hook into the running process and dump DEX files from memory, reconstructing the application logic.

With the application reversed, they identified OTA endpoints that, when supplied with the correct authentication token, serial number, and device parameters, returned a download URL from the Heltec cloud. Downloading from this URL provided the firmware blob.

Firmware Decryption

The downloaded firmware was encrypted. The team's decryption analysis proceeded through several stages:

1. Entropy analysis: Low entropy across the blob suggested non-random ciphertext — a good indicator of a weak cipher or key-reuse.
2. Key length estimation (Kasiski test / Index of Coincidence): Assuming the key was XORed or similarly applied in a repeating pattern, the team used the Kasiski examination (computing GCDs of distances between repeated ciphertext blocks) and the Index of Coincidence (a classical cryptanalysis metric) to determine the key length. Both methods converged on 256 bytes.
3. Key recovery via known-plaintext attack: Firmware images typically contain long runs of zero bytes. If a key is XORed over zeros, the ciphertext is the key. By identifying a repeating 256-byte pattern that likely corresponded to an all-zero region, the team extracted a candidate key and applied it to the full firmware. Partial readable strings emerged.
4. SMT solver refinement: The partial decryption revealed the cipher was not simple XOR but a composition of multiple operations. The team used SMT solving to enumerate candidate operation combinations and keys that would produce valid output. They progressively added constraints: ASN.1 certificate framing (BEGIN CERTIFICATE), Base64 character class constraints, and hexadecimal format patterns. After several refinement iterations, the firmware was fully decrypted. The actual algorithm turned out to be a XOR with additional mixing operations (details held for Q&A).

Binary Analysis of the Decrypted Firmware

With the firmware available in plaintext, the team identified that it ran on FreeRTOS. Quarkslab's internal binary similarity tool accelerated reverse engineering by identifying FreeRTOS library functions automatically, allowing the team to focus on vendor-specific code rather than re-documenting known OS primitives.

Critical security observation: the firmware was compiled without any exploit mitigations — no ASLR, no stack canaries, no non-executable stack or heap. This made exploitation dramatically simpler.

BLE Stack Buffer Overflow (Primary Exploit Chain)

Communication model: An Android application communicates with the charger over BLE. The ESP32 receives BLE messages and translates them into AT commands, forwarding them over UART to the STM32. The STM32 parser must handle these AT commands.

Vulnerability: The STM32 AT command parser includes a handler for the BLECFGMTU command. When processing any AT command, the parser scans the 100-byte input buffer for the \r\n terminator and copies the content into an 8-byte stack buffer — a textbook stack buffer overflow.

Injection chain: An attacker cannot directly send a BLECFGMTU command via BLE. However, the AT command parser has a sequencing vulnerability: when processing a single payload that contains two commands (e.g., a READ followed by a WRITE with attacker-controlled data), the parser checks for specific commands only within limited offsets of the buffer. Because the BLECFGMTU command check occurs across the full 100-byte buffer, an attacker can embed a valid BLECFGMTU command string within the payload portion of a WRITE command. The parser's sequential command handling causes it to "discover" the injected command in the wrong context, triggering the vulnerable parsing path.

Exploit development:

The overflow is limited to 100 bytes (the parser's buffer size), which equals exactly the stack frame size — enough to overwrite the return address but not to build a conventional ROP chain. The team's approach:

1. Stage 1 — Store shellcode on the heap: A valid WRITE command causes the device to allocate a heap buffer and copy the attacker-supplied payload into it. The pointer to this buffer is stored at a known, static location (BLMP_BUFF) in the data section. This provides a reliable staging area for shellcode, unaffected by any stack layout variance.

1. Stage 2 — Jump-Oriented Programming (JOP): With control over registers R4–R11 from the overflowed stack frame, the team built a three-gadget JOP chain to:

• Load the heap buffer pointer from BLMP_BUFF into a register.
• Set the LSB of the pointer to 1 (to signal Thumb mode execution) and store the result in an unused scratch area in memory.
• Load the Thumb-mode address back and branch to it.

1. Stage 1 shellcode: Rather than executing arbitrary logic directly (which would crash the FreeRTOS task), the first-stage shellcode called xTaskCreate() with the second-stage shellcode as the task entry point, then returned normally to restore the FreeRTOS scheduler state. This produced a 100%-reliable code execution path that kept the charger fully operational.

A live demo showed this exploit being triggered from an ESP32 over BLE.

USB Buffer Over-Read/Overwrite

The USB vulnerability is simpler: the setup packet for the control endpoint includes a wLength field specifying how many bytes to transfer. The firmware performs no bounds check on this value, allowing an attacker with physical USB access to trigger both an over-read (leaking memory) and an overwrite (corrupting memory) of arbitrary length, depending on the request type.

Post-Exploitation: Persistence

After achieving code execution on the control board, the team established persistence through two escalating methods:

1. OTA image patching: The external Winbond flash chip stores the encrypted OTA firmware image. Because the team had decrypted the firmware, they could patch it and re-encrypt it. The STM32 bootloader would apply the patched image on the next update. Limitation: A subsequent legitimate OTA update overwrites the implant.

1. Bootloader-level persistence: The STM32 bootloader occupies approximately 40 KB of flash that is never touched by OTA updates. By placing an implant in the bootloader region, the team achieved persistence that survives any number of firmware updates. The implant runs before any other code on every boot.

Lateral Movement and Impact Scenarios

From a compromised charger, the attack surface extends well beyond the device itself:

• IoT pivot: Using the ESP32's Wi-Fi and BLE radios, an attacker can reach devices on the home network (cameras, NAS, smart home controllers) without any further network-level vulnerability.
• Botnet construction: The Heltec mobile application displays a map of all devices globally, including their GPS coordinates and distance from the user. The approximately 200 devices visible in Paris alone illustrate how a single exploit could be propagated at scale.
• OCPP protocol attacks: The charger communicates with Heltec's cloud backend via OCPP. From the compromised device, an attacker could intercept legitimate user authentication tokens and redirect billing to victim accounts, enabling free electricity through billing fraud.
• Free electricity via power board: The power board governs actual current delivery. Having compromised the control board, which can re-flash the power board, an attacker can strip all billing checks and enforce maximum current delivery regardless of session state.
• Electric vehicle attack: The charging connector carries not just power but signaling. Sending invalid signals to the vehicle through the connector has the potential to damage EV charging circuitry.

Demo / Proof of Concept

▶ Watch: Exploit development: storing shellcode via write command (16:22)

The team demonstrated the BLE exploit on video. An ESP32 development board was used to scan for BLE devices, identify the Heltec charger by name, and deliver the exploit payload. The payload embedded the BLECFGMTU string within a crafted WRITE command, triggered the stack overflow, executed the JOP chain, and launched the second-stage shellcode as a FreeRTOS task — all while the charger continued normal operation.

Two CVEs were issued for the vulnerabilities (specific CVE numbers displayed at the end of the talk).

Defensive Implications

▶ Watch: Firmware persistence: patching the OTA update firmware (22:16)

For device manufacturers:

• Enable compiler mitigations: Stack canaries, ASLR (where the microcontroller supports it), and W^X memory permissions eliminate entire exploit technique classes. These are available for ARM Cortex-M devices at low cost.
• Validate all length fields: The USB wLength vulnerability is a trivially preventable bounds-checking failure. Every network or bus input that specifies a length must be validated against allocation sizes.
• Restrict AT command injection: The BLE-to-UART translation layer should enforce a whitelist of permissible AT commands and validate that multi-command payloads cannot smuggle unexpected commands.
• Encrypt bootloader separately: Protecting the bootloader flash region from write access via read protection (RDP) levels prevents bootloader-level persistence.

For security assessors and asset owners:

• Level 2 EVSE devices are network-connected computers with wide-area radio interfaces. They must be treated as managed devices with full asset lifecycle management, patching programs, and network segmentation (separate VLAN from internal networks).
• BLE "Just Works" pairing provides no authentication. Any device within BLE range can initiate the exploit. Physical proximity is the only barrier.

Key Takeaways

1. The Heltec Maxi Charger AC was protected by a custom firmware encryption scheme that could be broken using classical cryptanalysis (Kasiski test, Index of Coincidence) combined with SMT solver-assisted key recovery.
2. No exploit mitigations (no ASLR, no stack canaries) in the firmware made development of reliable exploits straightforward despite memory size constraints.
3. A BLE stack buffer overflow in the STM32 AT command parser can be exploited by any device within radio range using automatic "Just Works" BLE pairing — zero user interaction required.
4. The exploit uses Jump-Oriented Programming to work within the 100-byte overflow constraint, using a three-gadget JOP chain to redirect execution to heap-staged shellcode.
5. Bootloader-level persistence in unused STM32 flash survives all OTA firmware updates.
6. A compromised EVSE provides a platform for billing fraud, free electricity, IoT pivoting, botnet participation, and vehicle-targeting attacks, making it a high-value target for financially motivated attackers.

About the Speaker(s)

▶ Watch: Real-world impact: free electricity and charger denial-of-service (25:16)

Riccardo Mori is a Security Engineer at Quarkslab, a Paris-based security research firm. His work focuses on embedded systems and hardware security, including vulnerability research on automotive and IoT targets.

Robin David is a Software Security Researcher at Quarkslab. He also presented separately at REcon 2025 on QSynthesis and synthesis-based program analysis techniques. His research spans binary analysis, program synthesis, and automated vulnerability discovery.

Both researchers participated in the Pwn2Own Automotive 2025 competition as part of the Quarkslab team alongside Alex Sazaryan.