Why does my battery have Bluetooth?

Why does my battery have Bluetooth?

Speakers: Marc Newlin, Principal Reverse Engineer, SkySafe

Conference: DistrictCon

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

Overview

In a compelling presentation at DistrictCon, Marc Newlin, a Principal Reverse Engineer at SkySafe, delved into the unexpected presence of Bluetooth connectivity in modern portable power banks. Titled "Why does my battery have Bluetooth?", the talk originated from a simple question posed by Newlin's wife, leading him down a rabbit hole of discovery into significant security vulnerabilities within Anker's popular battery products. Newlin's research uncovered a startling lack of fundamental security practices, enabling potential drive-by firmware updates and raising serious questions about the safety and integrity of these ubiquitous devices.

Newlin, known for his expertise in reverse engineering drones and a penchant for "hacking anything with a radio," leveraged his skills to expose critical flaws in the Anker Prime Power Bank (A1340) and the Anker Solix Portable Power Station (A1727/C200D). His findings highlight a common pitfall in IoT device development: prioritizing features and telemetry over robust security. The implications of these vulnerabilities extend beyond mere data leakage, potentially allowing attackers to install malicious firmware that could compromise device functionality, user privacy, or, in the most extreme scenarios, even trigger physical hazards.

The talk serves as a stark reminder that even products from reputable manufacturers can harbor severe security oversights. Newlin's meticulous methodology, from analyzing verbose application logs to soldering onto debug headers, provides a blueprint for effective embedded device reverse engineering. More importantly, it underscores the urgent need for comprehensive security-by-design principles in the development of all connected devices, especially those that manage significant power reserves.

Background

▶ Watch: Introduction: Why does my battery have Bluetooth? (0:00)

The genesis of this research was Marc Newlin's wife asking why her Anker battery had Bluetooth. Initially, Newlin speculated it was for telemetry gathering, a common practice in modern smart devices. However, his curiosity quickly shifted from a casual inquiry to a full-fledged security investigation. Recognizing the platform's potential for exploitation—a device with high-capacity batteries, USB ports, a microcontroller, a display, and Bluetooth—Newlin saw an opportunity for significant security research, particularly if custom firmware could be pushed to the device. This initial spark led him to purchase the battery himself and embark on a detailed reverse engineering journey.

The primary targets for his investigation were two Anker products: the Anker Prime Power Bank model A1340 and the Anker Solix Portable Power Station model A1727 (also referred to as C200D). The A1340 is a popular, high-rate charging power bank, while the A1727 is designed for solar energy capture and storage, featuring different battery chemistry (LE SO4 instead of LiPo). While these devices serve different functions, Newlin suspected, and later confirmed, that they shared fundamental security weaknesses due to common communication protocols and development practices across Anker's product lines.

The overarching problem identified by Newlin was a pervasive lack of security considerations across the firmware, hardware, and wireless interfaces of these devices. This "forgot to do security" approach manifested in several critical areas, forming the foundation for the key findings. The research was driven by the principle that any device with a radio could be a target, and Newlin's previous experiences in IoT hackery made him uniquely suited to uncover these vulnerabilities. His work shines a light on the often-overlooked security posture of consumer electronics that are increasingly becoming "smart" and connected.

Key Findings

▶ Watch: Core vulnerabilities: Unsigned firmware and no BLE authentication (12:30)

Newlin's investigation revealed a series of critical security oversights that collectively enabled a potent "drive-by firmware update" attack against Anker's smart batteries. The core findings are:

1. Unencrypted and Unsigned Firmware Updates: At the time of the research, firmware updates for both the Anker Prime and Solix batteries were served unencrypted and, crucially, unsigned. This means there was no cryptographic integrity check to verify that a firmware image had not been tampered with, nor was there any confidentiality to protect the firmware's contents during transit. The only integrity check observed was a simple CRC (Cyclic Redundancy Check) or potentially an MD5 hash, which is trivial to spoof for an attacker.
2. Lack of Bluetooth Low Energy (BLE) Authentication: The batteries exhibited no application-layer authentication over their BLE interface. Any Bluetooth client could connect to the battery as long as it wasn't already actively connected to the owner's phone and was within Bluetooth range. This effectively treated the wireless BLE interface as an unauthenticated physical USB port, eliminating a significant barrier to attack.
3. Publicly Accessible Firmware Images: Firmware images were hosted on unsigned AWS S3 links. These URLs, discovered through API responses during firmware update processes, were not time-limited or authenticated. An attacker could simply copy and paste these URLs into a web browser to download official firmware images, facilitating analysis and modification.
4. Excessively Verbose Logging: The Android companion app, as well as the firmware on the embedded microcontrollers, featured "incredibly verbose logging." This logging included sensitive information such as key exchange parameters, specific AES keys used for encryption, plaintext payloads, and their encrypted/decrypted equivalents. For Newlin, this logging effectively served as "documentation," drastically simplifying the reverse engineering process by revealing the internal workings of the communication protocols.
5. Debug Functionality Enabled on ESP32: On the Anker Solix A1727, Newlin discovered unpopulated through-holes on the circuit board that were silk-screened as a debug header for the Espressif ESP32 System on Chip (SOC). Critically, the debug functionality was left enabled, allowing him to solder wires onto these pins and use standard UART tools (like an FTDI adapter) to dump the entire 4MB flash memory of the ESP32 without fully disassembling the battery.
6. "Pointless" Application-Layer Key Exchange: While an application-layer key exchange mechanism was implemented for BLE communications, it was fundamentally flawed. The AES key was derived using a user identifier provided by the cloud API. However, the battery would accept any key provided by any connecting Bluetooth client, rendering the key exchange mechanism effectively useless for authentication or secure session establishment.
7. Vulnerability to Modified Firmware Injection: By combining these findings, Newlin successfully demonstrated the ability to create modified firmware images for both the Telink BLE MCU and the Giga Devices ARM MCU. He could then push these modified, unsigned, and unauthenticated firmware images to a target battery over BLE, achieving a full drive-by firmware update attack.

These findings collectively painted a picture of a system where basic security principles were overlooked, creating a wide-open avenue for malicious actors to compromise the devices.

Technical Deep Dive

▶ Watch: The 'pointless' key exchange and authentication flaws (34:00)

Newlin's technical deep dive involved dissecting the hardware and software components of both Anker battery models.

Anker Prime Power Bank (A1340) Architecture

The A1340 features a dual-microcontroller architecture:

• Telink BLEM MCU (TLSR8253 or TLSR8252): This Bluetooth Low Energy (BLE) System on Chip (SOC) handles wireless communication. Newlin noted that Telink is a popular Bluetooth SOC vendor, often described as a "Chinese Nordic" due to similar product sets and good SDK support. Unlike most modern MCUs, Telink uses its own TC32 Instruction Set Architecture (ISA), not ARM. Fortunately for Newlin, a Ghidra processor module for the TC32 ISA was already available, allowing for straightforward firmware analysis and pseudo-code generation. The Telink MCU communicates with the main application processor via a serial interface.
• Giga Devices ARM MCU (GD32 series): This is the primary application processor, resembling STM32 MCUs in its ARM ISA and peripheral set. It controls the battery's display, interacts with USB Power Delivery (PD) controllers, and manages firmware updates for both itself and the Telink BLE SOC. The GD32 MCU supports readout protection, but Newlin's cursory assessment didn't confirm if it was enabled, though he later stated it was not.

The firmware update process for the A1340 is complex, involving multiple hops:

1. Firmware image originates in the cloud.
2. Downloaded by the Android phone app.
3. Transferred over-the-air (OTA) to the Telink BLE SOC via Bluetooth.
4. Sent from the Telink BLE SOC to the Giga Devices ARM MCU over a serial interface.
5. The ARM MCU caches the BLE firmware, performs integrity checks (CRC/MD5), and updates its own firmware.
6. Finally, the ARM MCU pushes the Telink firmware back to the Telink BLE SOC over the serial interface.

This multi-stage process creates numerous potential points of failure and, as Newlin discovered, opportunities for interception and manipulation.

Anker Solix Portable Power Station (A1727/C200D) Architecture

The A1727 presented a different architecture:

• Espressif ESP32: This SOC serves as the main application processor, integrating both Bluetooth and Wi-Fi capabilities. It typically features 4MB of flash memory, largely occupied by application data. The ESP32 allows for a more direct telemetry connection to the internet via Wi-Fi, bypassing the need for a phone proxy, though the Bluetooth interface still serves a similar proxy function.
• Debug Header Discovery: A significant finding on the A1727 was the presence of unpopulated, silk-screened debug headers for the ESP32. Crucially, Anker had left the debug functionality enabled. Newlin was able to solder wires onto these pins without full disassembly and use standard ESP32 tooling to dump the entire flash memory, providing direct access to the firmware.

Reverse Engineering Methodology

Newlin employed a multi-pronged approach:

• Bluetooth Snoop (BT Snoop): This Android mechanism allows recording BLE communications between an Android app and a device without requiring a rooted phone. This provided a low-level view of the Bluetooth protocol.
• Android App Analysis: The Android app, built using the Flutter framework (using the Dart language), proved to be a treasure trove of information.
• Certificate Pinning: Anker implemented certificate pinning, making it difficult to Man-in-the-Middle (MITM) cloud API requests with standard web proxies.
• Whitebox Crypto Library: A custom whitebox cryptographic library was present, though its full purpose wasn't entirely clear. Newlin speculated it was for small binary blobs, not whole-app obfuscation.
• Verbose App Logs: The most critical discovery was the "amazing level of verbosity" in the app_log.log file on a rooted Android phone. These logs contained plaintext key material, specific AES keys, encrypted and decrypted payloads, and even parameter annotations, effectively documenting the entire communication protocol between the app, the cloud, and the batteries. Newlin noted that some comments in the logs were in Chinese, which he translated using Chrome.

Protocol Reconstruction

Through these methods, Newlin reconstructed the communication protocols:

• App-to-Cloud: Communications over MQTT, with encrypted payloads using keys established during a key exchange between the app and the cloud.
• App-to-Battery (BLE): This channel initially lacked authentication. The protocol is a simple nested TLV (Type-Length-Value) structure. While a key exchange occurs, it's "pointless" from a security perspective. The cloud API provides a user identifier used as a seed for an AES key, which the phone then sends to the battery. However, the battery accepts any key from any connecting Bluetooth client, providing no real authentication. Newlin quickly validated this by using a key extracted from logs to decrypt payloads with a simple Python script.
• Telink-to-ARM (Serial): Internal serial communications between the two MCUs on the A1340. The Telink MCU often acts as a proxy, dispatching commands to the ARM MCU based on the command type.

Firmware Acquisition and Manipulation

Newlin discovered that during a firmware update, the Android app's API responses listed unsigned and non-time-limited AWS S3 URLs for the firmware images. This allowed him to download official firmware images directly. With the firmware images and a detailed understanding of the protocol (thanks to verbose logs), Newlin determined that the firmware images lacked cryptographically secure integrity checks, relying only on simple CRCs. This meant an attacker could modify the firmware, update the CRC, and potentially push malicious code.

The verbose logging on the Telink and Giga Devices MCUs also provided significant context, filling in gaps not present in the Android app logs and clarifying the full flow of updates between components.

Demo / Proof of Concept

▶ Watch: Demonstrating firmware modification (visual proof) (41:30)

Marc Newlin's demonstration focused on proving the feasibility of modifying and injecting custom firmware onto the Anker batteries. While a full live firmware update demo encountered issues with a newly purchased battery running a different patched firmware version, he successfully showcased the critical key exchange process and detailed his methodology for firmware modification.

The core of the proof of concept involved:

1. Establishing Unauthenticated BLE Connection: Newlin created a Python script that could connect to the Anker A1340 battery via Bluetooth, even without prior pairing or authentication.
2. Performing the "Pointless" Key Exchange: The script then executed the application-layer key exchange protocol. Despite its security flaws (accepting any key), successfully completing this exchange was necessary to establish the session key that encrypts subsequent communications. Newlin demonstrated how his script could generate and display this session key, along with other key exchange parameters, by leveraging the information gleaned from Anker's own verbose application logs.
3. Firmware Modification Strategy:

• Telink BLE SOC: For the Bluetooth microcontroller, Newlin aimed for a simple, visually verifiable change: altering the device's broadcasted BLE name. He proposed changing "Anker Prime Power Bank" to "Anker LoL Power Bank." This involved a straightforward string find-and-replace operation within the firmware binary, followed by recalculating and updating the CRC to maintain integrity from the battery's perspective (since no cryptographic signature was present).
• Giga Devices ARM MCU: Modifying the ARM MCU firmware presented a greater challenge due to the risk of bricking the device. Newlin focused on altering the battery's LCD display. He hypothesized that the display used embedded bitmap fonts. Through extensive manual analysis of the firmware's hex display in Ghidra, he identified data structures that appeared to be font glyphs, characterized by a width and height followed by width height 2 bytes (implying two bytes per pixel). He wrote a script to extract these potential images and, through trial and error, found contiguous regions corresponding to numerical fonts. His chosen modification was to horizontally reverse the 16-bit pixels within these font data structures. This allowed for a visible change on the display without altering any critical logic that could brick the battery.

1. Successful Firmware Injection: Newlin confirmed that he was able to successfully modify the firmware for both the Telink BLE MCU and the Giga Devices ARM MCU. By pushing these modified images via the unauthenticated BLE connection and the vulnerable DFU (Device Firmware Update) protocol, he observed the intended visual changes: the altered BLE broadcast name and the horizontally flipped numerical characters on the battery's display. This definitively proved that an attacker could inject arbitrary, malicious firmware onto target batteries.

The demo underscored the severe implications of the discovered vulnerabilities. While the live demonstration itself was limited due to Anker's subsequent protocol changes, the detailed explanation of the methodology and the successful prior proof of concept were compelling evidence of the attack's viability.

Defensive Implications

▶ Watch: Disclosure process and Anker's (partial) remediation efforts (50:00)

The vulnerabilities identified by Marc Newlin have profound defensive implications for both Anker and its users, highlighting critical security gaps in connected consumer electronics.

Attack Requirements and Blast Radius

The attack is alarmingly simple to execute, requiring only three conditions:

• The target battery must have Bluetooth enabled.
• The target battery must not be actively connected to the user's paired phone. This means if the owner's phone is out of Bluetooth range or has Bluetooth disabled, the battery becomes vulnerable.
• The attacker must be within Bluetooth range of the target battery.

The blast radius of a successful attack is concerningly broad and speculative. Newlin raised several critical, yet ethically un-tested, questions:

• Thermal Events and Fires: Could modified firmware trigger a thermal event or even cause the battery to catch fire? Given that these devices manage significant power, this is a severe physical safety concern. Newlin explicitly stated he did not feel safe exploring this potential.
• Self-Propagating Malware ("Batnet"): Is it possible to create self-propagating malware that spreads from one compromised battery to others? This could lead to a "botnet of battery fires," a technically fascinating but catastrophic scenario that Newlin strongly cautioned against.
• Remote Command and Control (C2): While not fully investigated, the presence of Wi-Fi on Solix batteries and the telemetry collection raises questions about potential remote command and control capabilities if exploited.

Recommendations to Anker

Newlin provided Anker with clear recommendations for hardening their devices:

1. Firmware Image Signing: Implement cryptographic signatures for all firmware update images. This is the most crucial step to ensure integrity and authenticity, preventing attackers from injecting modified firmware. At a minimum, this should be prioritized over encryption.
2. Firmware Image Encryption: Encrypt firmware update images to protect their confidentiality during transit and storage.
3. PKI-based Authentication for BLE: Adopt a Public Key Infrastructure (PKI)-based authenticated protocol for BLE connections. This would ensure that only authorized clients (e.g., the user's phone or a trusted server) can establish a secure connection with the battery, eliminating the "pointless key exchange" vulnerability.
4. Reduce Verbose Logging: Remove verbose logging, especially of sensitive information like encryption keys and plaintext payloads, from production firmware and the Android application. While helpful for debugging and reverse engineering, such logging in deployed products is a significant security risk.

Anker's Remediation Efforts

Anker's response to the disclosure was described as "very good response all things considered," but with caveats:

• Telink SOC Logging: Anker did remove verbose logging related to the old encryption scheme from the Telink BLE SOC's patched firmware. However, they added new logging about the new encryption scheme, indicating a partial, rather than comprehensive, fix.
• Other Logging: Critically, Anker did not remove the verbose logging from the Android app, the Giga Devices ARM MCU, or the Espressif ESP32. This means much of the "documentation" that enabled Newlin's research remains accessible to other researchers or attackers.
• Protocol Changes: Anker appears to have introduced some changes to their BLE protocol and encryption schemes, as evidenced by Newlin's DFU client failing on a newly purchased battery with updated firmware. This indicates an attempt to improve security, but the extent and effectiveness of these changes were not fully characterized in the talk.

In summary, while Anker has taken some steps, significant vulnerabilities persist, particularly regarding the ease of reverse engineering due to excessive logging and the potential for unauthenticated access. Defenders (i.e., Anker and other IoT manufacturers) must prioritize fundamental security practices like cryptographic signing and robust authentication to prevent such widespread vulnerabilities in devices that can pose physical risks.

Key Takeaways

• Fundamental Security Lapses in IoT: Many connected consumer devices, even from reputable brands, often lack basic security features like cryptographically signed firmware and authenticated communication protocols.
• Verbose Logging is a Security Risk: While useful for development, leaving verbose logs (especially those containing sensitive information like encryption keys and plaintext data) in production software is a significant security oversight that drastically simplifies reverse engineering and exploitation.
• "Pointless" Authentication is No Authentication: Implementing a key exchange or authentication mechanism that accepts any input, or where keys are easily derived and exposed, provides no real security and creates a false sense of protection.
• Drive-by Firmware Updates are a Real Threat: Unauthenticated wireless interfaces, combined with unsigned firmware, enable attackers to push malicious firmware to devices within Bluetooth range, potentially leading to device compromise or physical harm.
• Physical Safety Implications: Vulnerabilities in power-managing devices carry the severe risk of triggering thermal events or battery fires, underscoring the critical need for robust security in hardware that interacts with significant energy sources.
• Vendor Response Varies, Vigilance Remains Key: While Anker made some remediation efforts, partial fixes and remaining verbose logging mean that the ecosystem still presents opportunities for further research and potential exploitation. Consumers and security researchers must remain vigilant.

About the Speaker(s)

Marc Newlin is a Principal Reverse Engineer at SkySafe, a company focused on drone security. In his role, he specializes in reverse engineering various drone technologies, a field he describes as "an absolute blast." Newlin has a distinguished background, having been a frequent competitor in several DARPA competitions, showcasing his deep technical skills and problem-solving abilities. He characterizes himself as someone who will "hack anything with a radio," a passion that led him to investigate the surprising presence of Bluetooth in Anker power banks. His work often involves delving into IoT security, making him a prominent voice in uncovering and addressing vulnerabilities in connected devices.