世界を動かす技術を、日本語で。

ホンダ・シビックと悪徳バレーター

概要

  • 2021年式Honda Civicのヘッドユニット逆コンパイル・解析プロジェクトの進捗報告
  • USB経由でのアップデート経路から発見された重大な脆弱性「EvilValet」
  • AOSPテストキーによる任意コード実行の可能性
  • 解析・ツール開発状況と今後の貢献者募集
  • ドキュメントよりもツール自動化重視の方針

Honda Civicヘッドユニット逆コンパイル進捗報告

  • 3年前に公開した Honda Civic 2021年式ヘッドユニット逆コンパイル に関する初期研究の続報
  • USB経由アップデート の解析が最大の進展点
  • HondaはUSBドライブによるアップデートをサポート
    • AOSP署名済みアップデートファイル を適用
    • recoveryバイナリは改変されているが verify_file署名ロジックはAOSP準拠
  • AOSP公開テストキー がres/keys*に残存
    • 適切なUSBフォーマットとAOSPテストキー署名で 任意のアップデート適用が可能
  • 通常のroot化(su/setuid)は不要
  • 物理的にUSBポートへアクセスできれば 任意コード実行 が可能
    • これを「 EvilValet(イービルバレイ)攻撃」と命名
  • 例:バレーパーキング従業員がジャーナリストの車に 不正アップデート を適用
  • 技術詳細は 技術ドキュメント 参照
  • ota-builder ツールを公開
    • 誰でもヘッドユニットが受け入れるアップデートファイルを作成可能

脆弱性の考察と現状

  • すべてのアップデートがAOSPテストキー署名かは未検証
    • MRC_EU_SW_v12_4.zip (EU向け公式アップデート)がテストキー署名であることを確認
    • 他のヘッドユニットやアップデートファイルの検証協力を募集

解析補助ツールの開発状況

  • apk-rebuilder ツール開発
    • Honda Civic向けアップデートファイルから
      • リソース解決
      • .smaliコード再構築
      • APK再パック
      • ramdisk抽出
      • その他自動化
    • Hondaソースコード自体を公開せず、 変換関数のみ公開 することで法的リスク回避
    • 出力ディレクトリ構造を明確化し、ドキュメント参照を容易に

今後の課題・貢献者募集

  • Known Versions (既知バージョン)情報の収集
    • アップデートはバージョン番号依存
    • バージョンスプーフィングは可能だが 期待バージョンの把握が前提
    • 10th gen Honda Civic所有の技術者は 「Known Versions, Display Audio Software」 への情報提供を推奨
  • ota-builder のコード確認やアップデート適用テストに挑戦可能
    • 自己責任:リカバリーループやソフトブリックのリスク
  • ARMv7向けクロスコンパイルツールチェーン はローカルで実験中
    • Docker活用、今後クリーンな実装公開予定
  • カスタムテーマ はMitsubishiのAOSPフォークやminifyされたリソースIDの問題で困難
    • 自動編集ツール開発や貢献者歓迎
  • aidl-rebuilder で.smaliからAIDLインターフェース自動抽出
    • カスタムアプリ(例:バーチャルスピードメーター)開発の基礎
    • 精度検証・改善の貢献者歓迎

ドキュメントとLLM活用方針

  • 参照ドキュメントよりも ツール自動化重視
    • ヘッドユニットコードを より扱いやすい形に変換 するツールを提供
    • LLM(大規模言語モデル)によるコード解析・質問対応を想定
  • ADB接続ガイドなど 実用的なユーザーガイド は有用
  • Javaコード解説など コードが直接参照できる場合はドキュメント省略

今後の展望・謝辞

  • ヘッドユニット解析は 一区切り
    • 今後は他プロジェクトへの移行を予定
    • リポジトリは継続的にPR歓迎
  • Tunas8Hackaday への謝辞
  • 興味ある方は GitHubリポジトリ や技術ドキュメント参照を推奨

参考資料

  • Honda Civic Infotainment Reverse-Engineering: https://news.ycombinator.com/item?id=36052753
  • ota-builder, apk-rebuilder, Known Versions等:各GitHubリポジトリ参照

Hackerたちの意見

10世代のホンダシビックをアップデートするために、ホンダは特別なフォーマットのUSBドライブでアップデートを配布してるんだ。基本的にはAndroid 4.2.2rc1時代のリカバリーパッケージで、ホンダが追加したバージョンチェックが入ってる(これは偽装できるけど)。パッケージは公開されているAOSPのテストキーで署名されているから、フロントUSBポートに物理的にアクセスできれば、自分のパッケージを署名してフラッシュして、ヘッドユニットで任意のコードを実行できるんだ。ルート権限は必要ないよ。自分の2021年シビックでエンドツーエンドで試したし、公式のEUアップデートファイルもAOSPテストキーの署名が入ってることを確認した。詳しいツールや手順は投稿に書いてあるよ。

他のいくつかの車のインフォテインメントシステムもASOPをベースにしてるよ。自分のヒュンダイのアップデートをダウンロードしたときも、基本的にはAndroidイメージだったのを覚えてる。

AOSPは、バブルの外にいる人のためのAndroidオープンソースプロジェクトだよ!

分析ありがとう!こういう怠慢な仕事を暴く調査があるから、ハッカーニュースが好きなんだよね。

これを使ってLineage OSを動かすことはできる?

できるけど、彼らのカーネルを使うから、Lineageの全機能が動くわけじゃないよ。

できるけど、もしこのユニットが俺のCR-Vと同じなら、古い遅いOMAPプロセッサと4GBのRAM(確か)だと思う。編集:このモデルはTegra 3みたいだけど、俺の予想ではRAMが少ないだろうね。

ますます多くのプロジェクトが「よく設計されたコードはLLMでクエリできる」という考えでコードドキュメントを避けて、より機能的なランブックスタイルのドキュメントに移行しているのを見かける。プロジェクトのドキュメントが常にコードと一致していることは、実際にはほとんどないと思う。自分もこの考えには賛成だけど、「よく設計された」コードが前提になってるのが気になる。

ユニットテストをドキュメントとして見たいな。テストは意図された使い方を示したり、面白いコーナーケースを見せたりできるし、常に実行されてパスしてるから最新の状態だって分かる。もっとテストを追加することで得られる大きなメリットだと思う。もし開発者が何かの動作やコーナーケースについて質問するだろうなと思ったら、それに対する証拠をすぐに見られるテストがあってもいいんじゃない?

プロダクトマネージャーが、自社の内部署名サービスを使ってファームウェアが署名されたって自慢してるのを聞いたことがある(いいね)。もちろん、明示的に聞かれていたのはファームウェアが署名されているかどうかで、ファームウェアのアップデートプロセスが実際に署名をチェックしているかどうかではなかった(もちろん、チェックしてなかったけど)。

BobbyTables2って名前の人が、メールのPGP署名を確認する正しい方法にすぐ行かなかったのは意外だな…。

似たような「解決策」に出くわしたことがある。署名アルゴリズムがアップデートパッケージから直接実行されてたんだ。じゃないと、どうやって署名アルゴリズムを更新できるんだ?最悪だったのは、ある時点では正しかったってこと。セキュリティチームが「ポスト量子安全」署名を要求するようになったせいで、署名変更による後退が起こったんだ。

Hacker Newsで議論の続きを見る