Honda Civics and the Evil Valet

Three years ago, Eric McDonald started picking apart the headunit in his 2021 Honda Civic. What began as personal curiosity about his car's infotainment system has evolved into a project that exposes uncomfortable truths about how automakers approach software security.

The core discovery is straightforward but consequential. Honda supports firmware updates via USB, and the process relies on signed AOSP (Android Open Source Project) update files. The company modified the recovery binary and added Honda-specific checks, creating what appears to be a custom security layer. But they left the publicly-known AOSP test key in res/keys, and the signature verification logic matches stock AOSP exactly.

The implication is significant. Anyone who can format a USB drive and sign it with this widely-available test key can install arbitrary software on the headunit. No root access, no su binary with setuid, no exploits required. Just physical access to the front-most USB port while the unit has power.

McDonald calls this the "EvilValet" attack, a play on the classic "evil maid" scenario. The threat model shifts from a hotel room to a car cabin. A journalist hands their keys to a valet. The valet, potentially working for a surveillance operation, plugs in a prepared USB drive. When the car returns, the headunit has been modified, and the driver has no visual indication that anything changed.

The research team (Juniperspring) has published tools to demonstrate and build on this finding. ota-builder allows anyone to prepare update files that the headunit will accept. apk-rebuilder automates the reverse engineering pipeline: resolving resources, reconstructing .smali code, repacking APK files, and extracting ramdisks. These tools solve a real problem. Honda won't publish their source code, but they will publish update files. The tools bridge that gap, converting vendor binaries back into readable forms.

Honda's approach reflects a pattern common across the automotive industry. Car manufacturers are software companies now, whether they acknowledge it or not. Their vehicles run millions of lines of code, much of it built on Android or Linux foundations. But the security practices often lag behind what the software industry learned years ago. Using test keys for production firmware is the kind of shortcut that seems harmless in isolation but creates systemic risk.

The counter-argument has merit: physical access attacks are inherently limited. An attacker needs proximity to the vehicle, a USB drive, and knowledge of the update process. This isn't a remote exploit that can be weaponized at scale. The attack surface is narrow compared to, say, a cellular-connected telematics unit that can be reached from anywhere on the internet.

But that framing misses the point. Physical access attacks are precisely the kind that matter for targeted surveillance. Journalists, activists, political figures, and corporate executives all face threats that don't require remote exploitation. The valet scenario isn't theoretical. It's the kind of operation that intelligence agencies and corporate espionage units run regularly.

More broadly, the discovery raises questions about Honda's development practices. The AOSP test key is publicly documented. It exists specifically for development and testing. Using it in production firmware suggests either a deliberate choice to prioritize convenience over security, or a lack of awareness that this constitutes a meaningful vulnerability. Neither explanation reflects well on the company's security posture.

McDonald's project also highlights an interesting tension in documentation philosophy. Rather than maintaining extensive reference documentation, the team focuses on building deterministic tools that transform Honda's code into digestible forms. The idea is that users can then query these transformed outputs with LLMs to answer specific questions. This approach sidesteps the maintenance burden of keeping documentation synchronized with actual firmware, while still making the information accessible.

The project is seeking contributors in several areas. The update process relies heavily on version numbers, and the team needs data on which versions different headunit variants expect. There's work to do on AIDL interface parsing to enable custom apps. Custom themes would require editing Mitsubishi's fork of the AOSP framework, since headunit apps expect hardcoded resource IDs. And there's an experimental toolchain for compiling C code that matches the original vendor binaries' compiler version and build flags.

The broader pattern here extends beyond Honda. As vehicles become increasingly software-defined, the security of their infotainment and telematics systems becomes a public safety concern. The automotive industry's approach to software updates, code signing, and vulnerability disclosure is still maturing. Research like McDonald's forces that maturation by demonstrating what's possible when security takes a backseat to shipping features.

The headunit in question runs Android. Honda modified the recovery process but didn't meaningfully secure it. The tools to exploit this are now public. The question for Honda, and for the industry, is whether this kind of discovery prompts genuine security improvements or whether it simply becomes another data point in the growing list of automotive security failures.