Pwning Electric Motorcycles

Pwning Electric Motorcycles

Speakers: Mitchell and Panie, Security Researchers, Veraritoss

Conference: BSides Seattle

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

Overview

Mitchell and Panie, security researchers sponsored by Veraritoss, present their deep-dive into the firmware security of an electric motorcycle manufacturer they pseudonymously call "Moto Motorcycles" due to ongoing disclosure constraints. Despite the manufacturer's aggressive efforts to prevent reverse engineering -- including potting circuit boards in polyurethane resin, refusing to sell parts without VIN numbers, and ignoring five months of disclosure attempts -- the researchers found critical vulnerabilities that could allow an attacker to remotely flash malicious firmware, control motor torque at highway speeds, disable safety systems, and potentially cause serious injury or death.

The research demonstrates a complete attack chain: reverse engineering the mobile app to extract hardcoded bearer tokens and firmware signing salts, downloading firmware from an unauthenticated update server, decompiling the ARM Cortex firmware in Ghidra with original function symbols, and building two exploit tools -- a Frida-based Bluetooth attack via the companion app and a $100 Raspberry Pi CANbus flashing tool. The manufacturer has not responded to any disclosure attempts over five months.

This is a safety-critical vulnerability disclosure with life-threatening implications, making it one of the most consequential talks at the conference.

Background

▶ Watch: Introduction to 'Moto Motorcycles' and responsible disclosure constraints (0:30)

Modern electric vehicle manufacturers increasingly use over-the-air (OTA) updates to push firmware to vehicles, avoiding the cost and inconvenience of dealership visits. This manufacturer supports OTA updates over 4G cellular connections, with a Bluetooth-based fallback process through a companion mobile app. The central component is the Main Bike Board (MBB), which functions as the equivalent of an ECU in traditional vehicles but handles significantly more functionality.

The researchers chose motorcycles because their employer would not fund a $60,000 electric car for research, but several electric motorcycle manufacturers offered the same OTA attack surface at a more accessible price point. The initial plan was hardware-based analysis of the MBB, but the manufacturer only sells replacement parts to customers with a valid VIN number. An MBB obtained through eBay for approximately $400 turned out to be encased in a polyurethane potting compound that resisted methylene chloride dissolution. The proper solvent mixture -- 70% dichloromethane, 20% dimethylformamide, and 10% methanol -- is a Class 2 carcinogen and costs $200 per liter, pushing the researchers toward software-based attack vectors instead.

Key Findings

▶ Watch: Pivoting to Bluetooth app interception as firmware delivery vector (6:15)

The research uncovered five critical vulnerabilities:

1. Static firmware signing salt: The firmware signing mechanism uses a SHA-512 hash of the firmware concatenated with a hardcoded salt that is identical across all bikes. Knowing the salt allows an attacker to sign arbitrary firmware that the bike will accept as legitimate.

1. Absence of asymmetric cryptography: The entire system relies on symmetric cryptography with discoverable salts rather than RSA or similar asymmetric signatures. This means there is no private key protecting firmware integrity -- anyone who discovers the salt (which is embedded in the app and firmware) can forge any firmware or authentication response.

1. No root detection or app authentication bypass: The companion app has no root detection, and Frida hooks can bypass any firmware upload authentication, allowing a rooted phone to push arbitrary firmware over Bluetooth.

1. Unauthenticated CANbus flashing: The OBD2 port provides direct access to the CANbus with zero authentication. A $100 Raspberry Pi Zero tool can connect and upload arbitrary firmware to the Battery Management System (BMS).

1. Hardcoded developer credentials: The firmware contains hardcoded credentials for developer access, including a static salt for the challenge-response authentication system that governs privilege levels.

Technical Deep Dive

▶ Watch: Ghidra analysis with ARMLink symbols reveals hardcoded signing salt (13:50)

App reverse engineering: The researchers downloaded the official app from Google Play onto a virtual Android device using Aurora Store, extracted the APK via ADB, and decompiled it in Jadex. The DEX files preserved original function names and namespaces, making reverse engineering straightforward -- the developers had not obfuscated symbols. They identified the firmware update endpoint at fa-server.motomotorcycles.com/update, a custom Moto 1.0 user agent, and critically, a static bearer token hardcoded for the update API's authorization header. Using a simple curl command with the spoofed user agent and bearer token, they downloaded a zip file containing multiple firmware versions.

Firmware analysis: The zip file contained not only firmware binaries but also ARMLink dump files used in the build process. These dump files include memory table information and function symbols mapped to addresses -- an extraordinary reverse engineering gift. The firmware targets XMC 4500 and XMC 4800 automotive chips (ARM Cortex architecture). The researchers wrote a Ghidra Jython script to import the ARMLink symbols, producing cleanly labeled decompiled code with original function names.

Challenge-response authentication: The firmware implements a four-level privilege system with challenge-response authentication. The challenge is generated by the MBB, and the response is computed using a symmetric salted hash with a hardcoded static salt discovered in the firmware. The researchers identified both the salt and the computation process, making it trivial to write a standalone challenge-response generator without needing the manufacturer's authentication server.

Bluetooth exploit tool: A 1,200-line Frida hook (which the researchers candidly describe as "vibe coded" with AI assistance) force-navigates the app to the Bluetooth pairing activity, scans for nearby Bluetooth-enabled motorcycles, spams BLE connection requests, signs custom firmware with the known salt, and uploads it via the firmware update flow. The bike must be in pairing mode (kickstand down, mode button held for 5 seconds), but bikes that have never been paired with a phone do not even require explicit pairing mode.

CANbus exploit tool: For approximately $100, a Raspberry Pi Zero connects to the bike's CANbus through the OBD2 port, accessing the Battery Management System directly. This path is completely unauthenticated -- no replay protection, no access controls, nothing. A controller script automates the firmware upload process.

Demo / Proof of Concept

▶ Watch: Five critical vulnerabilities summarized: static salts, no asymmetric crypto,... (17:20)

The researchers did not have access to a physical motorcycle for live demonstration, so the talk focused on the reverse engineering process and the theoretical impact of the vulnerabilities. They showed the decompiled code in Jadex, the Ghidra analysis with imported symbols, the curl command that downloads firmware using the hardcoded bearer token, and the architecture of both exploit tools.

They also scaffolded C++ pseudocode for a C2 receiver that would leverage the bike's built-in 4G LTE cellular modem. The C2 hooks into the existing cellular communications module, replaces the normal heartbeat to Moto servers with beacons to an attacker-controlled server containing speed, GPS coordinates, timestamps, and battery status, and listens for commands to execute any of the vulnerable functions.

Defensive Implications

▶ Watch: Five months of ignored disclosure attempts across every channel (24:00)

The safety implications of this research are severe. An attacker who successfully flashes malicious firmware could manipulate motor torque output (applying maximum torque suddenly or cutting it at highway speeds), force the bike into full reverse while in motion, activate full regenerative braking causing sudden deceleration, tell the bike it is charging (cutting all motor power), disable emergency shutdown safety controls for battery fires or collisions, and track the rider's GPS location via heartbeat messages. None of these actions have speed-based lockouts -- they function while the bike is in motion.

For the specific manufacturer, the researchers note that firmware modification is "potentially invisible" compared to physical tampering like cutting brake lines. The attack can be delivered over Bluetooth during a test ride at a dealership or via the CANbus after briefly accessing the bike. The chip has ample unused space (~18 KB available, with identified code caves) for inserting malicious payloads.

For the broader vehicle industry, this research highlights systemic failures: the use of symmetric cryptography with static salts instead of asymmetric signing, unauthenticated CANbus access, hardcoded credentials, and the absence of basic app security measures like symbol stripping and root detection. Vehicle manufacturers implementing OTA update systems should audit for these exact patterns.

Users of these motorcycles have essentially no defensive options short of rewriting the MBB firmware themselves or physically removing the Bluetooth module -- neither of which is practical. The researchers are working with Carnegie Mellon CERT for coordinated disclosure after the manufacturer ignored five months of direct outreach.

Key Takeaways

• An electric motorcycle's firmware update system uses symmetric cryptography with hardcoded static salts instead of asymmetric signing, allowing anyone to forge valid firmware
• A static bearer token hardcoded in the companion app provides unauthenticated access to the firmware download server
• Two exploit tools were built: a 1,200-line Frida hook for Bluetooth-based firmware upload and a $100 Raspberry Pi CANbus flasher
• Malicious firmware could control motor torque, braking, power cutoff, and GPS tracking with no speed-based safety lockouts
• The manufacturer ignored five months of disclosure attempts across email, phone, LinkedIn, and sales contacts
• The manufacturer's anti-repair practices (VIN-gating parts, refusing manuals, subscription-locking hardware features) did not prevent the vulnerability discovery but did prevent responsible disclosure

About the Speaker(s)

Mitchell and Panie are security researchers at Veraritoss, which sponsored this research project. Mitchell handled much of the app reverse engineering and disclosure coordination, while Panie focused on firmware analysis and exploit development. Mitchell describes himself as "lazy by nature" and reluctantly used AI tooling (Jadex, Ghidra, and Frida MCP servers with Claude) to accelerate the Kotlin reverse engineering, while maintaining a critical stance on AI's broader implications. The team demonstrated resourcefulness in working around significant obstacles including potted hardware, VIN-gated parts procurement, and a completely unresponsive manufacturer.