本田思域车机疑信任 AOSP test key：USB 漏洞背后，是量产安全纪律掉线

有些车机漏洞，危险不在“黑客多高明”，而在门槛低得让人不舒服。

研究者 Eric McDonald 把这条攻击路径叫 EvilValet。名字借的是安全圈的 evil maid attack：别人短暂接触你的设备，趁你不在，改掉它。这里的场景更汽车化——代泊、维修、洗车，或者任何能碰到车内前置 USB 口的人。

这次材料指向的不是远程入侵。攻击者需要物理接触车辆 USB 口，车机还得有电。也没有证据证明它能直接控制刹车、转向或动力系统。

但这不等于小事。因为它打到的是车机更新链路，是量产软件最该守住的门。

USB 更新走到 Android recovery，问题卡在那把 test key

研究者梳理第十代本田思域车机更新机制后发现，USB 更新最终会走到 Android recovery。

更新包是 AOSP 风格的签名包。本田做了一些自己的检查，但关键验签逻辑 verify_file 接近 stock AOSP。真正扎眼的是 res/keys：其中疑似存在公开的 AOSP test key。

AOSP test key 是开发测试用的公开钥匙。它的存在不是秘密，也不该成为量产系统的信任根。

如果车机信任这把钥匙，攻击者就可能构造一个被车机接受的更新包，再通过 USB 更新路径拿到车机任意代码执行能力。

这里必须把边界说清。

研究者怀疑更多官方更新也使用 test key，但这还需要社区继续验证。作者还提到一个不确定性：他的车机装过 HondaHack，不能完全排除 key 是后续工具注入的可能。

所以，不能把它写成“所有本田车都中招”。更准确的说法是：第十代思域相关车机变体存在同类风险的嫌疑，且已经有公开更新包把问题推到了厂商必须解释的位置。

受影响的人，不该只看热闹

这件事对不同人群的意义不一样。

对第十代思域车主，短期动作很朴素：别把车交给不可信的人长时间独处；维修、代泊、改装后，留意车机是否出现异常应用、异常设置或不明更新。它不是让你立刻停开车，也不是让你恐慌拆车机。现实风险来自“有人能碰到 USB 口”，不是隔空打进来。

对汽车安全研究者，这条链路的价值在于可复现。研究者已经发布 ota-builder 和 apk-rebuilder：前者降低构建可被车机接受更新包的门槛，后者方便从更新包里还原 APK、资源、smali、ramdisk 等内容。社区接下来要做的，不是转发结论，而是验证更多地区、年份、车机版本的更新包。

对汽车软件团队，这是一张检查清单：量产包还信不信 test key？recovery 里 res/keys 是否可被审计？官方更新是否全部使用厂商私钥？有没有撤销旧 key 的机制？供应商交付件是否经过独立验签？

这些问题不性感，但会决定车机安全是工程，还是运气。

目前材料没有提供本田官方回应。接下来最该看的也不是公关话术，而是三个硬变量：是否确认受影响范围，是否移除 test key，是否给出可验证的修复更新。

漏洞本身不稀奇，test key 留在信任链里才离谱

复杂系统一定有漏洞。汽车软件更复杂，供应商更多，版本碎片也更严重。

但公开 test key 进入量产信任链，是另一类问题。它不属于“高手攻破高墙”，更像出厂时门禁还认施工钥匙。

“千里之堤，溃于蚁穴。”这句话放在这里不夸张。蚁穴不是某个炫技 exploit，而是签名、验签、撤销、版本控制这些基本纪律没有闭环。

汽车行业过去可以把车机当附件。屏幕能亮，导航能跑，蓝牙能连，就算交差。可今天的车机已经越来越像一台 Android 设备。它连着账号、地图、蓝牙、麦克风、车辆状态和售后更新流程。

既然吃 Android 生态的便利，就要接受 Android 安全工程的约束。

手机行业早就被 OTA、签名链、回滚保护、密钥管理反复教育过。汽车行业不能一边卖智能座舱，一边把安全纪律停在外包项目交付单上。

我更在意的不是这次能不能“黑进车机”。那只是结果。

更要命的是，如果公开测试钥匙真的被量产更新链路信任，说明内部安全评审没有把“谁能签一个系统更新包”当成高危问题。这个口子一旦存在，后面所有智能化叙事都会变轻。

车机越像手机，厂商越不能只学界面和应用生态。还得学手机行业摔过的跤：钥匙不能乱放，测试环境不能混进生产，更新链路不能靠没人研究来保平安。