How Public AOSP Test Keys Compromise Automotive Headunits

Embedded security models often depend entirely on the integrity of cryptographic trust chains. When the root of trust is compromised, downstream security mechanisms collapse. A recent reverse-engineering effort targeting the infotainment headunit of a 10th-generation (specifically 2021) Honda Civic highlights a classic failure in signing-key hygiene: shipping production firmware validated by publicly known development keys.

The vulnerability, dubbed "EvilValet," allows an attacker with physical access to the vehicle's cabin to execute arbitrary code on the headunit. The exploit bypasses conventional security barriers not through a complex memory corruption exploit, but by taking advantage of default configurations left in the update pipeline.

The Mechanics of the Update Verification Failure

Honda's infotainment system supports firmware updates delivered via a physical USB drive. The update process relies on a standard Android Open Source Project (AOSP) recovery mechanism. When an update is initiated, the system stages a signed AOSP update file and applies it via the Android recovery binary.

During a standard AOSP recovery update, the system verifies the cryptographic signature of the update package against a keyring stored in the recovery partition at /res/keys. The verification is performed using the standard verify_file signature logic.

In the case of the Honda Civic headunit, developers modified the recovery binary but left the signature verification logic intact. Crucially, they also left the publicly-known AOSP test key inside /res/keys. Because the system still trusts this default development key, any update package signed with the publicly available AOSP test key is treated as an official, authentic update by the recovery environment.

The "EvilValet" Attack Vector

Because the headunit accepts packages signed with the public AOSP test key, an attacker does not need to find a software exploit or obtain conventional root access (such as executing su via a local privilege escalation vulnerability) to compromise the system.

Instead, the attack vector requires only physical access to the vehicle's front-most USB port while the headunit has power:

Advertisement

Shadow GPS — know where it is, always Real-time GPS tracking for vehicles, gear and loved ones. No monthly contracts.

1. Payload Preparation: An attacker packages their desired payload—such as an update that installs an su binary with the setuid bit set—into an OTA update zip file.
2. Signing: The attacker signs the update package using the publicly-known AOSP test key.
3. Deployment: The attacker inserts the USB drive into the vehicle's front USB port and triggers the update process.

Because the signature matches the test key embedded in the recovery image, the headunit installs the package, granting the attacker arbitrary code execution at the system level. The researcher termed this an "evil valet" attack, drawing a parallel to the classic "evil maid" physical-access exploit but adapted for the automotive context where a valet or service technician has temporary, unsupervised access to the vehicle cabin.

Corroborating the Pipeline Leak

A key question in hardware reverse engineering is whether a discovered vulnerability is an artifact of a specific, previously modified device or a systemic issue present across the entire production fleet.

In this case, the researcher's own headunit contained the AOSP test key in /res/keys, but because the device had previously run "HondaHack" (a third-party modification tool), there was a possibility that the key had been injected post-manufacture. To verify if the vulnerability was present in stock configurations, the researcher analyzed an unmodified, official European software update file: MRC_EU_SW_v12_4.zip.

Analysis of this official, publicly available update file confirmed that it was signed with the same publicly-known AOSP test key. This strongly indicates that the manufacturer's official build and release pipeline uses development keys to sign production-grade firmware, exposing all compatible vehicles running this software version to the same exploit.

Reverse Engineering the Headunit Environment

To facilitate further analysis and development on the platform, several open-source tools have been developed to automate the extraction and packaging of the headunit's software:

• ota-builder: A utility designed to package and sign custom update files so they are formatted correctly for acceptance by the headunit's recovery binary.
• apk-rebuilder: An automation tool that takes a raw Honda update file, resolves resources, reconstructs .smali code, repacks APK files, and extracts the ramdisk. This allows developers to inspect the proprietary software without hosting or redistributing copyrighted binaries.
• ARMv7 Toolchain: A Docker-based compilation environment configured to compile C code for the ARMv7 architecture using the exact compiler versions and build flags utilized by the original vendor.

Under the hood, the headunit's applications run on a fork of the AOSP framework maintained by Mitsubishi. Modifying the user interface or applying custom themes remains difficult because the vendor applications are minified and rely on hardcoded resource IDs within this custom framework. However, tools like aidl-rebuilder are being developed to map out the system's AIDL interfaces by parsing .smali files, which could allow custom applications to interact with vehicle subsystems to display data like virtual speedometers.

Lessons for Embedded Pipelines

The exposure of the AOSP test key in production vehicles serves as a stark reminder of the importance of key hygiene in CI/CD pipelines. Default keys provided by upstream frameworks (like AOSP) are meant solely for initial hardware bring-up and local testing.

When transitioning from development to production, embedded software pipelines must enforce strict key rotation. Automated compliance checks should be integrated into the build process to scan the final recovery ramdisk and filesystem images, ensuring that default development keys are stripped and replaced with secure, hardware-backed production keys before firmware is released to the public.