Android車載ヘッドユニットが通信の踏み台に？確認方法と対策

今回確認されたのは、車両全体の乗っ取りや遠隔操作ではありません。対象は、DoFunのソフトウェアと更新用システムアプリ「TWCore」を採用した複数モデルのAndroid車載ヘッドユニットです。感染した端末が、第三者の通信を中継するプロキシボットネットの一部として使われる問題です。

この記事の結論

確認されたのは車両全体の侵害ではなく、DoFunのソフトウェアと正規アプリTWCoreを採用する複数のAndroid車載ヘッドユニットへのマルウェア配布です。端末はプロキシ通信の踏み台になり得ます。対象モデルと既存端末の復旧基準は公開資料で確認できないため、端末情報で窓口確認し、回答不能時は専門調査へ進む判断が必要です。

Securelistの調査とKasperskyの発表によると、本来は正規のソフトウェア更新に使われる機能がマルウェアの紹介に悪用されました。この記事では、2026年8月25日時点の公開情報を基に、設置済み端末の確認方法、通信対応の選択条件、問い合わせ先が分からない場合の分岐を補足として整理します。

DoFun・TWCore事案の概要

ヘッドユニットとは、ナビゲーションや音楽などを扱うダッシュボード上の端末です。機種によっては一部の車両機能とも連携しますが、今回の公開資料に、走行や操舵などの車両制御が攻撃されたとの記載はありません。

感染経路になったTWCoreは、利用状況の分析データを収集し、ヘッドユニットのソフトウェアを更新する正規のシステムアプリです。更新サーバーからアプリの追加や更新に関する指示を受け取る機能があり、この経路から「JarService」という不正なドロッパーが紹介されました。ドロッパーとは、別の不正プログラムを端末内へ展開する入口になるプログラムです。

JarServiceには利用者向けの画面がなく、複数段階のプログラムを読み込んでバックグラウンドで動作します。利用者が非公式サイトから手動で入れたのではなく、端末が信頼していた組み込みの更新機能から紹介された点が重要です。ナビや音楽が普段どおり動いていても、画面表示だけでは感染の有無を判定できません。

Android Autoとの違い

「Android Autoを使っていること」と「車載機自体がAndroidで動いていること」は別です。Android Open Source Projectの説明では、Android Autoはスマートフォン上で動作し、その画面を対応する車載ディスプレイへ投影する仕組みです。一方、Android Automotiveは車載ハードウェア上で直接動作するOSとプラットフォームです。

今回調査されたのは、DoFunのヘッドユニット上で直接動くAndroidソフトウェアとTWCoreです。そのため、スマートフォンのAndroid Autoを利用しているという事実だけでは対象条件になりません。ただし、投影先のヘッドユニット自体がDoFunのソフトウェアやTWCoreを採用している可能性は別途確認します。また、Android上で直接動く市販の車載機が、すべてAndroid Automotiveに該当するわけでもありません。

不正機能と通信の確認結果

解析された第3段階のプログラムには、HTTP通信、Webページ上の操作、追加コードの取得と実行など9種類のコマンドが実装されていました。これらは広告表示や広告詐欺に利用できる能力を示します。ただし、公開時点の実際の攻撃で使用が確認されたコマンドは、追加モジュールを読み込む「loadlib2」とHTTP通信を行う「http」です。実装されていた能力と、観測された実行内容は分けて考える必要があります。

loadlib2で追加された「zhima」モジュールには、感染端末をリバースプロキシにする機能がありました。これは第三者の通信を感染端末とそのIPアドレス経由で中継する仕組みです。ヘッドユニットは、監視カメラやルーターなどのIoT機器と同様に、利用者の知らないところで通信の踏み台として使われる可能性があります。

第3段階のプログラムは標準設定で約90分ごとに外部サーバーへPOST通信を行い、画面解像度、端末モデル、接続中のWi-FiのSSID、MACアドレスなどを送信していました。SSIDはWi-Fiネットワークの名前、MACアドレスはネットワーク機器の識別に使われる情報です。常に大量の通信が続く仕組みではないため、短時間の観察で目立つ通信がないことは安全確認になりません。

DoFun側の修正申告と未公開事項

Kasperskyが問題を通知した後、DoFunはセキュリティ上の問題を修正したと報告しています。そのため、紹介経路が現在も未修正だとは扱えません。一方、更新経路の修正と、すでに不正プログラムを受け取った可能性がある個々の端末の診断・復旧は別の確認事項です。

確認した公開資料には、正確な対象モデル一覧、影響台数、安全とされるファームウェア版、既存感染を利用者が判定する方法、機種別の駆除・復旧手順が掲載されていません。ファームウェアとは、ヘッドユニットの基本動作や機器制御を担う組み込みソフトウェアで、Android版やアプリ版とは異なる番号で管理される場合があります。

本稿では、①販売ブランド、②型番、③ファームウェア版、④Android版、⑤正規アプリTWCore（パッケージ名com.tw.core）の有無と、画面に表示できる場合のTWCoreアプリ版をまとめて「端末識別情報」と呼びます。取得できない項目には「設定画面に表示なし」などの理由を記録します。JarServiceや後段の不正プログラムは、一般利用者が版番号を控える対象ではなく、専門担当者が侵害指標と照合する対象です。

DoFunの公開ページには公式ファームウェアや問い合わせ先の案内があります。ただし、確認したページだけでは本件の対象型番、安全な版番号、復旧方法を特定できません。公開されていない一覧との自己照合ではなく、端末ごとの回答を得る必要があります。

設置済み端末で確認したい条件

以下は、端末を特定して機種別の判断へつなぐためにブログ側で整理した確認順序です。運転中には操作せず、安全な場所に停車して確認します。

1. 端末識別情報の記録：設定画面、取扱説明書、保証書、購入履歴、取付記録を確認します。表示できない項目も空欄にせず、確認できなかった理由を残します。
2. DoFun・TWCore採用の確認：システムアプリを表示できる場合はTWCoreを確認し、表示できなければ型番を基に販売元、取付店またはメーカーへ採用の有無を尋ねます。
3. 更新履歴の記録：最後に更新した時期、通知が表示された場所、Wi-Fi、テザリング、内蔵回線など更新時の接続方法を控えます。この履歴だけで感染判定はできませんが、調査材料になります。
4. 機種別判断の照会：端末識別情報を伝え、今回の影響対象か、安全な版は何か、通信や利用の制限が必要か、既存感染をどう診断するか、復旧には何が必要かを確認します。
5. 案内された手順の適用：対象型番について回答した窓口が案内するファイルと手順だけを使います。型番の異なる製品向けファームウェアや、出所を確認できない紹介ファイルは使用しません。

回答待ちの端末は、感染確認済みとも安全確認済みとも扱わず、「影響未判定」として管理します。車両機能に安全上の異常がある場合や、メーカー・取付店から停止を指示された場合は、その案内を優先します。

窓口が不明・回答不能の場合

販売元や取付店が回答しない、廃業している、購入元を特定できない場合でも、影響未判定のまま判断を止める必要はありません。購入メール、決済履歴、保証書、取付伝票からブランドや型番を探し、次に製品ブランドのサポートまたはDoFunへ照会します。工場装着品や車両機能との連携がある端末は車両販売店・車両メーカー、社用車やリース車は管理部門・リース会社も確認先になります。

ブランドや型番自体を特定できない場合は、車載電装品を扱う整備事業者や取付店に、まず端末の製造元と型番の特定を依頼します。この段階で安全宣言を求めるのではなく、回答できるメーカー窓口へつなぐための識別が目的です。

窓口が見つからない状態で、Securelist掲載の悪性側の侵害指標との一致、セキュリティ製品による該当検出、または約90分の間隔をまたいでも続く説明不能な外向き通信がある場合は、通信ログと端末を扱える専門担当者による調査へ移ります。未知の宛先や通信量の多さだけでは感染の証明になりませんが、調査を始める理由にはなります。

未判定中に利用者が決められるのは、出所不明の更新を適用しないこと、記録を残すこと、安全や契約サービスへ影響しない範囲で任意のWi-Fiやテザリングを減らすことまでです。感染の有無、全回線隔離、駆除完了、安全なファームウェア版は推測で確定しません。

通信調査と対応段階の判断条件

侵害指標（IoC：Indicators of Compromise）とは、既知の攻撃との一致を調べるためのファイル情報、通信先、検出名などです。通信停止や隔離を検討する直接の条件は、悪性側のIoCとの一致、検知製品による該当検出、または販売元・メーカーから対象端末として通信停止の指示を受けた場合です。いずれかに該当しても、既知回線だけを止めるか全回線を隔離するかは、端末構成を確認できる責任者や専門担当者が決めます。

普段と異なる通信だけが見つかった段階では原因調査を始め、短時間に通信が見えない場合も安全確認済みとは扱いません。この選択条件を前提に、対応段階を次のように分けます。

状態	選択条件	主な実施者	完了条件	位置付け
接続削減	影響未判定で、任意の接続を安全に減らせる場合	一般利用者	不要なWi-Fiやテザリングの切断を端末画面で確認	予防的な削減。内蔵SIMなどが残る可能性があり、隔離ではありません
既知回線の停止	IoC一致、検出、停止指示のいずれかがあり、把握済みの経路を先に止める場合	販売元・取付店・管理者	列挙したWi-Fi、テザリング、内蔵SIM、有線接続などの停止状態を記録	部分的な封じ込め。未把握の経路までは保証しません
全回線隔離	同じ判断材料があり、責任者が全経路の遮断を必要と判断した場合	権限を持つ管理者・専門担当者	全ネットワークインターフェースを棚卸しし、端末側とネットワーク側の両方で遮断を確認	通信の封じ込め。不正プログラムを除去した状態とは異なります

Securelistが示す悪性側の指標には、JarService、後段のローダー、zhimaモジュールの検体ハッシュ、マルウェアのドメインとIPアドレス、JarServiceのダウンロード先、Kasperskyの検出名があります。一方、TWCoreとパッケージ名com.tw.core、正規TWCoreのハッシュは正規アプリの識別情報です。TWCoreの存在だけでは感染や隔離の根拠になりません。

通信調査では観測地点をルーター、テザリング元、管理ゲートウェイなどに定め、端末、時刻、接続経路、通信量、宛先、通信間隔を記録します。標準の約90分間隔をまたぐ観測は補助材料になりますが、通信量だけで感染を確定しません。駆除・復旧については公開された利用者向け手順がないため、初期化、再書き込み、部品交換のどれが必要かを機種別に確認します。

新規購入で確認したい条件

これからAndroidベースのヘッドユニットを購入する場合は、画面サイズやOSの新しさだけでなく、問題発生後も更新と復旧を管理できる製品かを確認します。

• 端末の開発元と更新サービスの提供元
• DoFunのソフトウェアやTWCoreを採用しているか
• 端末識別情報を利用者が確認できるか
• セキュリティ告知を掲載する公式ページと問い合わせ窓口
• 更新の提供期間とサポート終了後の扱い
• 問題発生時の診断、再更新、交換の条件

購入後も回答を得られる窓口があり、更新期間と復旧条件が明確な製品なら候補にしやすくなります。回答が得られない場合は購入判断を待つ余地があります。高価なセキュリティ製品を先に追加するより、正規の情報源を継続して確認し、対象型番と提供元が一致する更新だけを適用する運用が現実的です。

事業者による一括管理

営業車や配送車を複数管理する事業者は、車両ごとに端末識別情報、DoFun・TWCore採用の回答、最終更新日、利用回線、問い合わせ状況を記録します。取得できない項目も空欄にせず、理由を残します。

管理状態は「対象外」「影響未判定」「悪性指標との一致」「復旧確認済み」に分けます。同じ外観や型番という理由だけで全端末を感染扱いせず、対象外や復旧確認済みへの変更には、メーカー回答や専門調査などの根拠を残します。通信ログを扱える担当者と隔離判断者もあらかじめ決めておくと、検出後の判断が止まりにくくなります。

補足FAQ

次の行動は、端末識別情報を一枚に記録し、回答を得られる最初の照会先を特定して本件の対象可否を問い合わせることです。

---