AOSP Test Key Signed Updates

Three years after his initial reverse engineering of the 2021 Honda Civic headunit, security researcher Eric has published a major update: the headunit's update mechanism uses the publicly-known AOSP test key for signature verification. This means anyone with a USB drive can flash arbitrary code to the headunit.

Honda supports USB-based updates for the headunit. The process involves multiple Honda-specific checks, but ultimately the USB drive contains a signed AOSP update file that gets staged and applied via Android recovery. The critical flaw: the res/keys* file contains the AOSP test key, and the verify_file logic in the modified recovery binary matches stock AOSP. As long as the USB drive is formatted correctly and the payload is signed with the test key, the headunit accepts the update without conventional root access—no su with setuid needed.

Eric confirmed the test key is present on his own headunit, and he also verified that MRC_EU_SW_v12_4.zip, a publicly-available EU software update file downloaded from a forum, is test key signed. This strongly suggests all official updates use the same key, though Eric notes he hasn't tested every variant.

EvilValet Attack Vector

Eric dubs this an "evil valet attack"—a variant of the classic evil maid attack. An attacker with physical access to the car's cabin (e.g., a valet) can plug a USB drive into the front-most USB port, install a malicious update, and return the car with a compromised headunit. The driver would have no immediate indication of the modification.

Tools Released

Eric has published two tools to aid further research:

  • ota-builder: A tool that prepares update files accepted by the headunit. It can, for example, package an su binary with setuid to root the device.
  • apk-rebuilder: A tool that takes a Honda Civic update file (not hosted by Eric) and produces a clean directory tree of decompiled .smali code, resolved resources, repacked APKs, and extracted ramdisk. This avoids publishing Honda's proprietary code directly.

Call for Contributors

Eric outlines several areas where community help is needed:

  • Known Versions: The update process is version-sensitive. Contributors can add their headunit's software version to the repo's "Known Versions" section to help others avoid recovery loops.
  • Toolchain: Eric has an experimental Docker-based toolchain that compiles C code for ARMv7 with the same compiler flags as Honda's vendor binaries. He plans to publish a clean version.
  • Custom Themes: Currently infeasible due to Mitsubishi's fork of AOSP framework and hardcoded resource IDs in the headunit apps. Surgical editing of the vendor framework would be required.
  • AIDL Rebuilder: A work-in-progress tool to parse .smali files and map AIDL interfaces, enabling custom apps like virtual speedometers.

Technical Details

Eric's approach emphasizes tooling over documentation. He argues that since the headunit code is the source of truth, providing deterministic tools to decompile and analyze it is more maintainable than writing reference docs that can drift. For instance, connecting via ADB is documented, but explaining Java code is left to LLMs that can query the decompiled output.

Risks

Flashing an unsigned update carries risk. If the headunit variant differs from Eric's, the device could enter a recovery loop or softbrick. Eric advises caution and recommends reading the technical docs before attempting any modifications.

The full technical writeup is available in the project's repository.