Honda Civicと悪意あるバレーパーキング
(juniperspring.org)- 2021年型 Honda Civic のヘッドユニットは、USBアップデート経路で公開 AOSP テストキーで署名された更新を受け入れられるため、物理アクセス可能な攻撃者が任意コードを実行できる
- Honda の更新は Android recovery を通じて適用され、
recoveryバイナリが改変されていても、verify_file署名検証ロジックは標準 AOSP と一致する - 公開 AOSP テストキーで署名し、USB ドライブの形式を合わせれば、
suとsetuidがなくても任意のコードを導入でき、これを EvilValet 攻撃と呼ぶ - 新しいツール ota-builder はヘッドユニットが受け入れる更新ファイルの準備を容易にし、apk-rebuilder は更新ファイルをリバースエンジニアリングに必要な出力ツリーへ変換する
- プロジェクトは調査作業の大半を完了したが、リポジトリは放棄されておらず、バージョン情報・ツールチェーン・カスタムテーマ・AIDL マッピング改善への貢献が求められている
プロジェクト更新の背景
- 3年前、2021年型 Honda Civic のヘッドユニットを理解しリバースエンジニアリングするための初期作業が公開され、今回の更新ではその後の進展が整理されている
- 初期の反応は非常に励みになり、最大の進展は更新プロセスの解明から生まれた
王国の鍵
- Honda は USB によるヘッドユニット更新をサポートしており、最終的に USB ドライブ内の署名済み AOSP 更新ファイルが Android recovery を通じて準備・適用される
- Honda 独自のチェックはいくつも存在するが、
res/keysには公開されているAOSP テストキーが残っており、改変されたrecoveryバイナリのverify_file署名ロジックも標準 AOSP と一致している - USB ドライブを適切にフォーマットし、公開 AOSP テストキーで署名すれば、既存の root アクセスなしでもヘッドユニットに任意の内容を導入できる
suにsetuidを設定するような一般的な root 取得は不要- ヘッドユニットの電源が入っていて、攻撃者が最前面の USB ポートに物理的にアクセスできれば、この更新経路を通じてヘッドユニット上で任意コード実行が可能
- この攻撃は、ホテルの部屋に物理アクセスする evil maid attack に似ているが、車内にアクセスする必要があるため EvilValet と呼ばれる
- 例として、ホテルのバレーパーキング担当者が USB で更新を導入した場合、車が返却された後も運転者はヘッドユニットの変更に気づかない
- この記事は技術詳細ドキュメントではなく、詳しくは Display Audio Update Files を参照
- 新ツール ota-builder により、ヘッドユニットが受け入れる更新ファイルを容易に準備できる
- 初期段階ではあるが、たとえば
setuidが設定されたsuバイナリを導入する更新ファイルの作成は些細な作業になった
- 初期段階ではあるが、たとえば
- すべての更新が公開 AOSP テストキーで署名されていると考える強い理由はあるが、可能なすべての公式更新ファイルや、すべてのヘッドユニット亜種のファイルシステムにアクセスできたわけではない
- 確認されたヘッドユニットでは
res/keysに AOSP テストキーが存在したが、HondaHack の導入履歴があり、キーストアにキーが注入されていた可能性もある - 公開入手可能な EU ソフトウェア更新ファイル
MRC_EU_SW_v12_4.zipはテストキーで署名されており、公開フォーラムから取得した未改変ファイルである - すべての更新が AOSP テストキーで署名されている可能性は非常に高いが、この仮説を裏付ける、または反証する貢献が必要
- 確認されたヘッドユニットでは
ツール構築
- 更新プロセス以外で最も有用だった作業は apk-rebuilder の開発だった
- apk-rebuilder はインターネット上で入手した Honda Civic 更新ファイルを入力として受け取り、リバースエンジニアが手作業で行うべき処理を自動化した、整理された出力ファイルツリーを生成する
- リソース解析を行う
.smaliコード再構成を行う- APK ファイル再パッケージ化を行う
- ramdisk 抽出を行う
- その他の処理も行う
- 実際の Honda ソースコードを公開できないため、apk-rebuilder は公開リポジトリでホストされていない更新ファイルを入力として受け取り、Honda の
.smaliコードや画像アセットなどを出力する関数として機能する - 生成された出力物は明確なディレクトリ構造に従っており、機密ファイル自体をアップロードせずとも文書内から参照できる
残作業と貢献募集
-
既知バージョン
- 更新プロセスは脆弱で、バージョン番号に大きく依存している
- バージョン番号は偽装できるため、署名されていないコードの実行能力を制限しない
- 更新ファイルを作るには、ヘッドユニットが期待するバージョンを知る必要がある
- 使用中のビルドと一致しないヘッドユニットソフトウェア変更は、予期しない動作や recovery loop につながる可能性がある
- 10代目 Honda Civic を運転していて技術に詳しいユーザーは、リポジトリの Known Versions, Display Audio Software セクションに貢献できる
- 特に大胆なユーザーは
ota-builderのコードを読んで更新書き込みを試せるが、ヘッドユニットが基準デバイスと異なれば recovery loop に陥り、デバイスがソフトブリックする可能性がある
-
ツールチェーン
- ローカルマシンには実験的で開発途中のツールチェーンが存在する
- このツールチェーンは候補
.cコードを受け取り、元のベンダーバイナリと同じコンパイラバージョンおよびビルドフラグで ARMv7 向けにコンパイルする - 更新プロセス理解の作業において、このツールチェーンは不可欠だった
- 現状では Docker を多用しており雑然としていて、特定ワークフローに強く依存しているが、より整理された実装を公開したいとしている
-
カスタムテーマ
- apk-renderer を vibe-coding している途中で、カスタムテーマも一部調査した
- カスタムテーマは Mitsubishi の AOSP framework フォーク内にあり、ヘッドユニットアプリはハードコードされたリソース ID を前提に縮小化されているため、配布は難しい可能性が高い
- カスタムテーマを配布するには、ベンダー framework を外科手術的に修正し、それを自動化するツールを書く必要がある可能性が高い
- この作業は簡単ではなく、労力に見合わないかもしれないが、貢献者は歓迎される
-
aidl-rebuilder 改善
.smaliファイルを解析し、ヘッドユニットの全AIDL インターフェースを生成・マッピングするツールの作業が始まっている- ツールは動作するが、正確性を十分に検証できていない
- この作業は仮想スピードメーターのようなカスタムアプリの可能性を開く
ドキュメント化と LLM についての考え
- 参照ドキュメントよりもツール化に重点を置いている
- 信頼できて決定的なツールがヘッドユニットコードをより理解しやすい形へマッピングすれば、ユーザーはその形を LLM で問い合わせて具体的な質問に答えられる
- ヘッドユニットコードが真実の源泉であるため、実際のコードとずれる可能性のある参照ドキュメントを維持する負担を減らせる
- ADB でヘッドユニットに接続するユーザーガイドは依然として有用
- Java コード自体を LLM が利用できる状況では、Java コードの動作を別文書として維持するのは保守負担になる
まとめ
- ヘッドユニットについて意図していた調査作業の大半は完了した
- 継続的に取り組めるプロジェクトではあるが、今後は別のプロジェクトへ移る可能性が高い
- リポジトリは放棄されておらず、PR はいつでも歓迎される
1件のコメント
Hacker Newsのコメント
このバージョンチェックは回避可能で、パッケージは公開されている AOSPテストキー で署名されているため、前面USBポートへの物理アクセスさえあれば任意のパッケージに署名して書き込み、ヘッドユニット上で任意コード実行が可能
root/su は不要で、2021年型 Civic で最後まで実行確認しており、公式のEU向けアップデートファイルもAOSPテストキー署名を使っていることを別途確認した
2026年3月のオーストラリア政府 Information Security Manual には、政府機器を車両のインフォテインメントに接続しないこと、また接続された車両の中や近くで機微な資料を閲覧したり機微な会話をしたりしないこと、という管理策が追加された
https://www.cyber.gov.au/business-government/asds-cyber-secu...
こうした攻撃に脆弱でありうる人たちには、業務遂行のための手順や信頼できる機器が別にあり、米国の警察機関も OnStar 登場後、レンタカーについて同様の規則を設けていた
一般人にとって危険なテレマティクス情報の大半は、どうせすでに売られている
技術における脅威モデルは常に、攻撃者が機器への物理アクセス権と時間を持てば終わり、という前提だった
今のように、車が運転中ずっと利用者を監視する プライバシー侵害装置 でありながら、少し関心のある人にもそのデータを渡してしまう 安全でない装置 という中途半端な状態が最悪だ
押収されうるならデータはローカルに保存しない方がよく、法によっては解除を強制されることもあるが、米国ではパスワードの提供を拒否しても安全であるべきだ
技術的には Google と Apple が物理セキュリティを大きく改善しており、GrapheneOS はその土台の上で攻撃対象領域を減らし、優れた機能を追加してさらに一歩進めている。特に 自動再起動 が広く採用されつつあることで、スマートフォンでは「物理アクセスがあれば終わり」という結論は修正できる
https://grapheneos.org/features#auto-reboot
https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
十分に高度で執拗な攻撃者が物理アクセスによってどんな機器でも掌握できるとしても、だからといって誰でも簡単にできるようにしてよいという意味ではない
車に物理アクセスできる悪意あるバレー係なら、ヘッドユニットのハッキングに時間を無駄にせず、ただ車のどこかに盗聴器を隠すだろう
それに Civic の運転者が情報機関の標的になることもないと思う
ヘッドユニットには通常、同期後に残った連絡先の SQLite データベース、位置履歴、テレメトリやログファイルに残った過去データなどの 履歴情報 が入っている
さらにヘッドユニットは車内バスにアクセスできることが多く、Gateway モジュールのようなファイアウォールがあってもたいてい弱い。Honda ではヘッドライトなどと同じ CAN バス経由で、暗号情報なしに解錠と始動許可が可能だった有名な事例もあり、インフォテインメントは単なる追跡装置よりはるかに強力になりうる
しかもヘッドユニットにコードを仕込んだり既存データを抜き出したりする方が、別のトラッカーを取り付けるより痕跡をはるかに残しにくい
Civic は最も一般的な車の一つで背景に溶け込みやすく、科学者、エンジニア、ジャーナリスト、弁護士のような「普通に見える」人たちも Honda Civic に乗っていることは十分ありうる
車内に隠した盗聴器は見つかる可能性があるが、車両ファームウェア内に直接仕込んだものは見つかる可能性がさらに低い
だが実際に問われていたのは、社内の義務要件に関連してファームウェアが署名されているかどうかであって、ファームウェア更新手順が署名を検証するか ではなかった。そして実際にはまったく検証していなかった
「でないと署名アルゴリズムをどうやって更新するんだ」という話で、最悪なのは、かつては正しくできていたという点
セキュリティチームが「ポスト量子安全」な署名を要求したことで署名方式が変わり、その過程で回帰バグとして入り込んだものだった
しかし、こうした車が10年以上経って、いじる気のある人たちの手に渡るようになれば、ソフトウェアを開いてカスタマイズできる能力は大きな利点になるだろう
有用な改造を作るコミュニティが生まれ、機器の寿命が延びるとよい。最終ユーザーが純正ヘッドユニットを取り外して、Honda の装置よりセキュリティや工学品質が劣る可能性が高い AliExpress 風の「Android タブレット」ユニットを入れるより、はるかにましに見える
更新をデフォルトで全面的に信頼しないのであれば、実際の所有者が更新を承認できる仕組みを用意すべきだった
本当に意図したものなら、特殊キーが必要なアンロック可能ブートローダーや、アクセスしにくいスイッチのような形になっていただろう
Honda Civic の1世代にしか通用しない方法より多くのブランドで使えるし、設置もおそらくもっと速い
どの時点においても、プロジェクトのすべての文書がコードと最新状態で一致している可能性は本当に低い
おおむねこの方向性には同意するが、前提はあくまでコードが うまく設計されている ことだ
テストは意図された使い方や興味深い境界事例を示せるし、継続的に実行されて通っているので最新状態だと分かる
これは、より多くのテストを追加する際に過小評価されがちな大きな利点だ
開発者がある動作や境界事例について尋ねそうなら、再び推論させるより、質問への答えをその場で証明できるテストを用意する価値がある