IoTSecJP Version.6.0 #IoTSecJP で発表したカーハッキングの資料 (公開用)
Please contact me at Twitter mention or DM (@shutingrz) for any questions or comments.
ANALYZEAUTOMOTIVEECU〜ECUをハックした話〜しゅーと(@shutingrz)
View Slide
• カーセキュリティの基本とハックのアプローチについて■目次• カーハッキングの始まり• CANセキュリティ• メーターに対してスキャンを行い挙動を推測してみる• ECUセキュリティ• エンジンECUに対して診断を利用したハックの試行（失敗）話すこと
• 本資料は私個人の調査結果によるものであり、所属組織・部門は関係ありません• 発表資料はあとで公開します• 撮影は一部スライドを除いてOKおことわり
• しゅーと (@shutingrz)• セキュリティエンジニア• 元SOCアナリストで4月に異動• ゲーム&IoTペネトレ初心者• 7月からカーセキュリティに手を出す• IoT 勉強中WHO AM I
• 営業「来月からカーハッキングの案件始まるから」• ハードウェア勉強開始２ヶ月初心者ぼく「え？」• クルマわからないし、なんならIoTもハードもわからない• みんなの足を引っ張るわけにはいかない！！！• カーハッカーズハンドブックを読んで猛勉強• 車載システムの仕組みからハックまで広く解説ことのはじまり
• カーハッカーズハンドブックはクルマを持っている人向け• 一部はシミュレータに関する記述があるが・・・• 中古車を買うとしても維持費考えたら高すぎる• 勉強用に買うのはさすがに・・・最大の障壁：クルマを買うお金がない
貧乏人だってカーハッキングしたい！
• 解体屋さんが廃車となった車をバラしてパーツ売り• 色んなECUを売っている• 古い車種や不人気モデルは笑っちゃうくらい安い• 送料には気をつけてヤフオクでECUを買う
• CAN通信に対応• デジタル表示がかっこいい• 色んな計器表示がある• 新しいのに安い（1000~2000円)• トヨタなので情報が豊富アクアを選んだ理由
• 必要なもの• 12V電源（ACアダプタでOK）• ジャンパワイヤ• ブレッドボード• CAN-USBアダプタ• CANableがおすすめ• テスター• これだけなら7000円程度• メータ合わせて1万かからない！参考:解析環境について
1. CANセキュリティコンビネーションメーターの解析
• トヨタアクア(2013年製) 搭載のコンビネーションメーター• クルマのあらゆる情報を集約し、スピードや警告を表示する• 現代の車載コンピュータ(=ECU)はCANバスを通して情報をやりとりしている• ECU : Electric Control Unitもともとはエンジン制御用のため開発された経緯から EngineControl Unit の略だったのこと• さらに近年ではCAN FD/車載 Ethernet が普及の兆し？基本情報
CAN (Control Area Network)• バス型ネットワークでノイズに強い通信方式•L1 および L2 のレイヤーの仕様• 各ECUで2本の線をつなぎ合わせコリジョンを避けつつ通信• CAN ID が小さい方が優先される / IDが大きい方は少し待って再送信ノードノード ノードノード送信受信受信受信バスID: 123Data: 00FF00...
• Linuxでは canX という形式のインターフェイス名で認識• IDは 11bit CANの場合 0x000 ~ 0x7FF• データは最大 8 バイト• CAN FDという非互換のプロトコルでは 最大 32、64バイトなどCANデータの例
• 近年のクルマには必ず診断ポートが存在• 世界各国で実装が義務付け• 診断ポートに様々な通信規格が同居• 近年は大半がCANを使うように (Pin6, 14)参考: 実車でのCANバスへのアクセス© Zepto~jawiki
• ピンアサインの特定• ピンは合計53pinある• 整備書を入手したほうが安全で早い• トヨタは車種ごとに電子技術マニュアルが存在する• CANと電源程度なら初心者でも雰囲気で特定可能• メータなので起動確認は容易1. 起動
ファジングを行い挙動を観測• CAN通信可能なUSB機器を通じてランダムデータを送信• ECUに定義されたID・データと合致すると何かが起きる•挙動の種類によってそのクルマの各ECUが使うIDも特定可能CANID: 123 Data: 1234...CANID: B3A Data: FFFF...警告音警告灯の点灯車速の変化
ファジング時のメーターの挙動https://youtu.be/rMZjkm46sYY
• 素直に反応するのでチェックサムやMACなど検証の仕組みはない• 単純に偽造データを信じてしまう• 車速は早い段階で上昇しすぐゼロに戻った• 警告灯関係は表示されたあとずっと表示される• データがオン/オフのスイッチの役割を果たす？• 何度も試しても反応しない計器・表示灯がある• CANバスではない別の端子から信号が入力される？考察
挙動に対応するデータ構造の特定000～7FF→反応000～4FF→反応000～2FF→無反応300～4FF→反応3B7→反応500～7FF→無反応• どのIDで目的の挙動を示すかを二分探索• ID特定時のデータは８バイトで全て「FF」• 目的の ID が判明したら次はどのデータ部に反応するかをひたすら試行FF FF FF FF FF FFFF FF→反応00 00 00 00 FF FFFF FF→反応… 04 …→無反応… 08 …→反応(5Byte目 の 4bit目)FF FF FF FF 00 0000 00→無反応(略)ビットレベルで定義されることも多いID Data(略)
• candump (スニファ) / cangen (トラフィックジェネレータ)• ファジングデータの生成に使用• cangen で ID: 000 ~ 7FF , Data:「全てFF」のデータを生成• candumpでそれをテキストデータに落とし込む• canplayer & grep , head , tail• ファジングに使用• テキストデータをもとにトラフィックを生成• データ絞り込みのために一般的なLinuxコマンドが使える特定のために使用するソフトウェア
• カーハッキングの十徳ナイフ• canplayer による絞り込みの部分を対話的に行える• 他にも診断機能の特定など様々なモジュールを備えるCARING CARIBOU
調査結果(データが多いので省略)https://www.shutingrz.com/post/aqua-meter-hack/
解析で得られた情報でシミュレーションhttps://youtu.be/5ZJSc0vtP5E
• 車載の様々な情報は CAN を利用している• 単純なファジングでも十分に解析ができる• 攻撃者からのニセデータで計器・運転手を騙すことが可能• 運転中に警告を発火させ運転手を混乱させられる• 自動運転に車速データなどを利用していたら・・・？コンビネーションメーター解析まとめ
• ゲートウェイの設置• 機能に合わせてネットワークを分離化• ホワイトリストフィルタ• ただし診断通信は運用上通さざるを得ない• MAC（メッセージ認証）• AUTOSARで文書化• リアルタイム性との兼ね合いCANセキュリティの今CGWパワートレイン系ボディ系マルチメディア系OTA系
■ECUセキュリティエンジンECUの解析
• やりたかったこと• ファームウェアを読みたい• ファームウェアを書き換えたい→セキュアなので読むことすらできませんでした• 調査を通じて現在のECUがどれだけ頑張っているのかを説明しますおことわり
• トヨタアクア(2013年製) 搭載のECM(Engine Control Module)• かつては ECU (Engine Control Unit)という名称• 様々なセンサー情報をもとにスロットル等を調整• クルマを動かすのに一番大事な所基本情報※ヤフオクで500円
ECUのリバースエンジニアリングについて前提となる情報の紹介
• 一般車ではECUにてエンジンリミッターがかけられている• モータースポーツ界隈ではそのリミッターを外しパフォーマンスを得る試みがある• ROMチューン• リプログラミング• ファームウェア・テーブル書き換え• クルマ業界では「リプロ」というECUのリバースエンジニアリング
• ホビー用途でリミッター解除をするのは大きな問題ではない• リプロとは、全ての挙動を書き換えられるということ• 攻撃者が他人の車で悪用したら？• いわゆる「マルウェア感染」• 高速道路で突然停止• 歩行者を検知した瞬間急加速リプロ対策はなぜ必要？
• Uconnectという車載ナビに脆弱性• 携帯電話網を使ってナビやWifi AP機能などを提供する• リモートでファームウェアをリプロし、任意のCANメッセージを出せるように• 運転アシスト用ECUのCANメッセージを偽造しアクセルやハンドル操作参考: リモートから攻撃されたジープhttp://illmatics.com/Remote%20Car%20Hacking.pdfhttps://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
• クルマはIoT機器の一種• 一般的なハードウェアハックのアプローチが有効1. ROMに直接アクセス2. デバッグ機能でアクセス3. 車両診断機能でアクセス番外: 脆弱性を悪用（Jeepのような）• リッチなECUならまだしも単機能ECUではほぼ見つからないリプロの手法
• 昔はよく使われていた手法• 微細化が激しいがMSOPサイズなら素人でもできる• 近年ではフラッシュ内蔵のSoCが普及しており本手法は困難に• 外付けでEEPROMにファームウェアが存在するのは稀1. ROMに直接アクセス・メーターの走行距離が保存されるROMホットエアーで外しSOP8変換基板に再実装
• 昔〜近年のECUで可能な手法• SoCによってはJTAGなどのデバッグポートが存在し、ロックがかかっていないことがある• これを利用したデバッグやFlashの読み書きが可能※シリアルポートも同様2. デバッグ機能でアクセスSH70XXのBootmodeを使った読み書き
• NECのMCUをカスタマイズした「76F00XX」シリーズが搭載されている• “プログラミングポート”が存在• これらを利用した ECU Tuning 製品が出ている• NECのマイコンにある機能: NBD(Non-Break Debug)を利用する参考: 2013年頃のレクサスのエンジンECU
参考: NBDを利用したFLASH READhttps://youtu.be/vF2B9le-uY4
• LEXUSと同じDenso MCU• 76F0085が搭載• プログラミングポートは未搭載• パターンが外に出ていない• 俗称"Toyota Denso Gen1 ECU"シリーズ以降は全てこの仕様らしい• レクサスのECUを入手してピンアサインを比較・特定すれば行けるかも？（今回は断念）アクアのエンジンECUの場合
• "MCU NEC 76F0085を搭載したToyota Denso Gen1 ECUの最新バージョンは小さな金属ケースに入っており、NBD / JTAGポートはありません。(略)したがって、このECUタイプは一般的な方法では読み取ることができません。"• "ファームウェアはBGAを外すか、トヨタから入手する必要があります" (要約)参考: リプロツール業者の記事http://bitbox.ru/en/news/68
• リプロ最後の砦• ECUはOBDポートを用いて診断を行う• 近年はCANバス上で診断(DoCAN)• ファームウェア更新のときにも診断機能を用いる• メーカー・車種・生産年代によって仕組みが異なり、最近ではセキュリティも強固3. 車両診断機能でアクセス©Saitobesho
• ECUが検出した故障を診断機が受け取るための仕組み• クルマを全て分解して不具合を特定するのは大変なため• 問題の切り分けのため診断機からECUに各種機能をオンオフさせることも可能→アクティブテスト• 様々な診断プロトコルがある• OBD2, KWP2000, UDS… (後述)車両診断とは
アクア エンジンECUの解析車両診断機能を使ったリプロの試み
• ピンアサインの特定• ピンは合計195pinある• 整備書を使って特定• メータと同じく気合でもいける• LED等はないので正常に起動したか調べるにはCAN通信を見る必要がある• しかし起動しても能動的にCAN通信は流れてこない1. 起動
• OBD2• 故障診断のために作られ、古くから用いられている• 仕様策定の段階でコネクタ形状まで統一され以後使い続けられる• KWP2000• より高度な診断、更新のために作成された• メーカーにより実装がバラバラ• UDS• KWP2000の実装依存の部分をちゃんと仕様化• それでもメーカーが従うかは別・・・• 現在はUDSが標準になってきている参考: 車両診断機能の一覧
• OBD2は仕様としてエンジンに関する様々な項目を取得できる• エンジン回転数や燃料・温度...• 世界的に搭載を義務付けられているため、ECMが動いているかの確認にも使える• リクエストペイロードは２バイト• 1バイト目: サービスID• 2バイト目: パラメータ• サービスIDが「何をするか」、パラメータは「何に対して」• KWP2000・UDSではパラメータはSubFunctionというOBD2を用いた生存確認
• リクエスト•CAN IDは 7DF (CAN上の診断でのブロードキャストのようなもの)•ペイロードは "01 00"「対応している項目を教えて」• レスポンス※返ってきているのでECUはちゃんと動いている！•CAN IDは7E8 (本来のリクエストCAN IDに+8したものがレスポンス)→ つまりECMのOBD2のCAN IDは 7E0※先頭バイトに余計なものがついているのは ISO-TPのカプセル化によるフレームを跨いだデータ通信を可能にする（詳細割愛）OBD2を用いた生存確認can0 TX - - 7DF [8] 02 01 00 00 00 00 00 00 '........'can0 RX - - 7E8 [8] 06 41 00 BE 3F A8 13 00 '.A..?...'
• Caring Caribouの uds discovery• CANID: 7DF, 7E0 に反応•7DFはCAN上診断のブロードキャストを示すリクエスト用CANIDは7E0だろう• このECUはUDS亜種•機能はUDS、SIDだけKWP2000KWP2000・UDSの機能の確認$ ./cc.py uds discovery-------------------CARING CARIBOU v0.3-------------------Loaded module 'uds'(snip)Identified diagnostics:+------------+------------+| CLIENT ID | SERVER ID |+------------+------------+| 0x000007df | 0x000007e8 || 0x000007e0 | 0x000007e8 |+------------+------------+
• 全般•DiagnosticSessionControl•セッション切り替え（後述）•SecurityAccess•セキュリティ機構•これを突破しないと診断以外の機能は基本的に使えないUDSで定義されている、リプロに有用なサービス
• メモリ読み書き系•ReadMemoryByAddress :•指定したメモリアドレスの読み込み•RequestUpload :•指定したメモリアドレス範囲の転送(ECU→Client)•WriteMemoryByAddress :•指定したメモリアドレスの書き込み•RequestDownload :•指定したメモリアドレス範囲の転送(Client→ECU)UDSで定義されている、リプロに有用なサービス
• 要求が受け入れられる場合はサービスIDに+40したレスポンスIDが返る• Positive Resonse• 受け入れられない場合はレスポンスIDが「7F」でそのあとにエラーコード• Negative Response (ちなみにCode22はconditionsNotCorrect )参考: UDSのデータ形式Client ECU10 0150 0110 027F 10 22通常セッションに切り替え要求Positive Responseリプロセッションに切り替え要求Negative Response (ErrCode 22)
• SID 0x00 ~ 0xFF 、 SubID: 00 でひたすらリクエストを送って応答を確認•サービスが存在しない場合はCode11が返るためそれ以外を探す• Caring Caribou の uds services が使えるが、取りこぼしが多い•改良版をPull Request中3. 対応サービスのスキャン
• 診断用のサービスIDがあるがメモリ読み書き系は全く無い•別の診断セッションに切り替えられれば出てくるかもしれない• メーカ独自定義のサービスが割と多い（やめてほしい。。）• SIDの割り振り方はKWP2000•しかし中身(SubFuncのIDなど)はUDSというちぐはぐな仕様3. 対応サービスのスキャン(結果)SID Name Desc10 DiagnosticSessionControl 診断セッション切り替え21 ReadDataByIdentifier 各種情報の読み取り27 SecurityAccess セキュリティ認証機構30 InputOutputControlByIdentifier 各種入出力機能の制御3B WriteDataByIdentifier 各種情報の書き込みA1 ~ A4 , A7, A8 *[Defined By Vehicle Manufacturer] メーカ独自定義↑スキャンの結果 ECUが反応したSID (一部抜粋)
• セッションは複数種類ある•通常セッション、リプロセッション、拡張セッション...• デフォルトは通常セッション• 通常セッションはできることは殆どない• メモリ読み書きしたいなら他セッション• 他セッションは原則SecurityAccessを突破したうえで切り替える• 突破せずとも切り替えられるパターンも• メモリ読み書き系は実装により突破しないと拒否されることもある診断セッションについてISO 14229より引用
• SID: 10でSubIDを00~FFで試す→5つのセッションが見つかった• リプロセッションが存在• ただSecurityAccessを突破しないと入れない模様• 他セッションはSecurityAccess突破なしでも切り替えられた• 全てメーカ独自のセッションID• 独自なので何ができるか全く不明• メモリ読み書き系は見つからない診断セッションの切り替えID セッションの種類 RespCode意味01 Default 50 Positive Response02 Programming 22 conditionsNotCorrect40 vehicleManufacturerSpecific50 PositiveResponse5f vehicleManufacturerSpecific50 40 PositiveResponse61 systemSupplierSpecific50 PositiveResponse
• 最後の望みはリプロセッション• ファームを書き換えるので機能もきっとあるはず！• リプロセッションに切り替えるためにSecurity Accessの突破が必須診断セッションの切り替えID セッションの種類 RespCode意味01 Default 50 Positive Response02 Programming 22 conditionsNotCorrect40 vehicleManufacturerSpecific50 PositiveResponse5f vehicleManufacturerSpecific50 40 PositiveResponse61 systemSupplierSpecific50 PositiveResponse
Security Access の突破試行錯誤の日々・・・
• チャレンジ&レスポンスの認証方式。SeedをもらってKeyを送る• 実装方法は自由なのでメーカ・車両・年代で変わる• 故障診断以外の機能は認証を突破しないと使えないSecurity AccessClient ECU27 0167 01 72 70 8D 9D27 02 12 34 56 787F 27 35Level 01 の Seed をくださいSeed: 72 70 8D 9DSeedに対応のKeyは12 34 56 78？ちがうわ！！ ( Invalid Key)
• Seedに対するKeyを導出する式（暗号化アルゴリズム）を見つけることがゴール• ファームウェアを抜き出し解析するのが一番早い• それができるなら苦労しないSecurity Access のゴール
• Keyが何バイトかは実装依存• UDSではエラーコードに"Incorrect message length orinvalid format (0x13)"がある• これを利用してサイズを特定• 0x13ではなく0x35(Invalid Key)になるバイト数を探す→4バイトであることが判明STEP1: KEYサイズの特定can0 7E0 [3] 27 02 00can0 7E8 [3] 7F 27 13can0 7E0 [4] 27 02 00 00can0 7E8 [3] 7F 27 13can0 7E0 [5] 27 02 00 00 00can0 7E8 [3] 7F 27 13can0 7E0 [6] 27 02 00 00 00 00can0 7E8 [3] 7F 27 35can0 7E0 [7] 27 02 00 00 00 00 00can0 7E8 [3] 7F 27 13
• 認証回数は9回まで• 10回目は回数超過としてコード 0x36(Exceeded number of attempts)• 認証回数が超過するまでは何度でも同じSeedが返される• 再起動するとSeedがかわる• Seedの生成に偏りがある• 1バイト目はほぼ4通りしかない• 起動ごとにだいたい決まる• 4バイト目は時間ベースで増加• 約1500回周期でSeedが被ることがある→リプレイアタックが有効（今回は意味無し）STEP2: 認証仕様の特定Seed: 41 a2 43 81Seed: 01 7d 9f 82Seed: 01 65 82 87Seed: c1 89 60 89Seed: 82 72 98 8aSeed: 41 af 40 8fSeed: 41 b6 46 90Seed: 01 7c 89 95Seed: c1 bb 4c 97Seed: 82 72 8a 98Seed: 41 a1 5c 9d
• チャレンジ&レスポンスなのでアルゴリズムから推測が必要• パスワードではないので総当りはほぼ不可能• チャレンジ一回につき4バイト=2^32通りが考えられる• でもやらなきゃ始まらない・・・STEP3: 暗号化アルゴリズム&KEYの特定
• Seed関係なく特定のバイト• いわゆる「パスワード」=総当りで解ける• 初期のECUではよくあった• ビットシフト• 単純なXOR• この年代のECUでよくある模様？• 上記+バイトの足し引き• 長い鍵+AESによる暗号化• これは鍵を手に入れないと突破は不可能様々なECUでのKEYの生成パターン
• この年代は単純な4Byte XORが流行ってる情報がある• 総当りして試してみよう→ 0 ~ FFFFFFFF まで試行して最大213日かかる計算に (1auth / 0.004sec)• そもそも4byteXOR以外なら213日を無駄にすることに• すぐに諦めて別の方法を模索試行1: 単純な総当り (失敗)Source code:https://github.com/shutingrz/aqua-engine-ecu-hack/blob/master/brute_key_xor.py
• 以下の想定1. 4byteXORとみなし、1バイトずつのXOR比較をしていると仮定2. 1バイト目が正解なら2バイト目の比較に移行し、不正解ならreturnされるため命令数の差異が発生→正しい組み合わせのときだけ平均レスポンス時間が長くなるのでは？試行2: タイミング攻撃⏱一致？ エラーInputByte++KeyByte++最終？ 認証成功初期化:InputByteKeyByteYesYesNoNo↑1バイト目が正しかった場合、1ループ分余計に時間がかかる？
• 1つの組み合わせにつき50回試行→全通りで有意な差はでなかった• 複数回試行で順位が何回も変わる• もし時間がかわるとしてもリモート測定では様々な要因で正確な計測はできないかも試行2: タイミング攻撃⏱ (失敗)Source code:https://github.com/shutingrz/aqua-engine-ecu-hack/blob/master/check_key_timing.py$ python3 ./check_key_timing.pyendByte test:12740 / 12750 (XORCand: 0x000000fe, ETA(s): 0:00:00)finish.sort:key: 0x25, time: 0.004235796928405761key: 0x26, time: 0.004141133308410644key: 0x76, time: 0.004133680820465088(snip)topByte test:12740 / 12750 (XORCand: 0xfe000000, ETA(s): 0:00:00)finish.sort:key: 0xea, time: 0.004177097320556641key: 0x7c, time: 0.004164288997650147key: 0xe7, time: 0.004154132843017578(snip)
突破は無理なのか・・・？
プリウスなら誰かやってないか・・・？
• IOActiveが出した2車種のレポート• Ford Escape / TOYOTA Prius• 様々な手法で実車をハックしている• 診断機を解析することでSecurityAccessを突破• 暗号化仕様も詳細に記載• 著者はCODEBLUE2014で同レポートに関連する発表をしているPRIUS HACKレポートhttps://ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_Control_Units.pdfhttps://www.slideshare.net/codeblue_jp/chris-valasek-japub
• 診断機は車の診断のほかECUの更新機能ももつ• J2534規格によるリプロの標準化• 個人でもリプロができる時代• 規格対応のI/Fは必要• トヨタはtechstreamという診断ソフトウェアを提供診断機を使ったリプロ機能の解析
• トヨタでは個人でもECUの更新ファームウェアが入手可能• $60/2days のライセンス...• ECUに対応した更新ファイルが提供されていれば、それを用いて更新が可能• techstreamの静的解析と通信解析を行えば仕様は丸裸に診断機を使ったリプロ機能の解析
• Techstream同梱のECU更新ソフトにSecurityAccessのクライアントがある• IDAで解析しアルゴリズム特定• Keyの算出は4バイトXORプリウスのSecurityAccess
• Techstream同梱のECU更新ソフトにSecurityAccessのクライアントがある• IDAで解析しアルゴリズム特定• Keyの算出は4バイトXOR• キーは 0xXXXXXXXXプリウスのSecurityAccess 公開用
アクアの認証仕様と比較してみるAqua ECM Prius ECM年代 2013年 2010年ECMの診断用CANID 0x7E0 0x7E0SendKeyのLevel 0x02 0x02Seedの長さ 4バイト 4バイトKeyの長さ 4バイト 4バイト認証試行回数限度 9回 9回Seedのライフタイム 試行超過するまで同じ値 試行超過するまで同じ値• 同じ認証仕様と推察される• 他にもレポート記載のSeed例についても類似点がみられた
アクアで試してみたcan0 7E0 [2] 27 01can0 7E8 [6] 67 01 72 70 D3 C3can0 7E0 [6] 27 02 72 10 B3 C3can0 7E8 [2] 67 02~can0 7E0 [2] 27 01can0 7E8 [6] 67 01 00 00 00 00Request SeedResponse Seed (7270D3C3)Send Key (7210B3C3)Auth Success (Positive Response)Request Seed (認証済みか確認）Authenticated ( 00000000 )• 成功した※認証後にSeedを要求された場合は 00000000 を返す仕様なので、それで認証成功を確認できる
• アルゴリズム自体は正しかった• ずっと回していれば1日でたどり着く値だった試行1: 単純な総当り (失敗)について 公開用
Security Access 突破後におけるメモリ読み書き機能の調査
• 認証突破前はエラー• コード22 「条件不足」• 突破後に試したところ成功• リプロセッションに入れた!• それでもメモリ読み書き系のサービスは存在せず。。• UDSの仕様は無視されてるリプロセッションへの切り替えcan0 7E0 [2] 10 02can0 7E8 [3] 7F 10 22can0 7E0 [2] 27 01can0 7E8 [6] 67 01 F1 76 2A 3Ccan0 7E0 [6] 27 02 F1 16 4A 3Ccan0 7E8 [2] 67 02can0 7E0 [2] 10 02can0 7E8 [1] 50セッション切替（失敗）セッション切替（成功）認証（成功）
• レポートによるとリプロは以下の手順1. リプロセッション切替2. リプロ用CANIDの切替送信3. ファームバージョンごとに設定されたTargetData(パスワード)を送信4. 正しい場合、ECUから0x3Cが返る5. ライタプログラムを送信6. ファームウェアを送信※完全に独自実装参考: 診断ソフトがリプロを行う際の手順ファームウェアを含むキャリブレーションデータ(.cuwファイル）
• レポートではリプロ時に下記の機能があるとの記載が• GetMemoryInfo(メモリレイアウトの要求)• CheckBlock (書き込み可能か確認）• EraseBlock (メモリのクリア)• WriteBlock / WriteBlockWithAddress(メモリの書き込み)• VerifyBlock(書き込まれたデータの読み出し）• ただしTargetDataを送信後に初めて使えるようになる参考: リプロ手順中のコマンド
• 更新手順上ではWriteBlockでメモリを書き込んだあとに呼び出し• 「応答」と「書き込んだはずのデータ」を診断ソフトが見比べて差異がないかを確かめる• これを使えばメモリの読み出しができるのでは？？？VerifyBlock？？
• リプロ用コマンドはTargetDataを送信した後に使える• TargetDataはファームウェアのバージョンごとに異なり、更新ファイルにのみそれが記載• 法則性はなく推測は難しい• ファーム更新がなければ更新ファイルは存在せず、知ることは不可能大きな壁: TargetDataフォーラムで稀に投稿されることも（TOYOTA MR2の更新ファイル）
• 総当りを試してみよう→ 0 ~ FFFFFFFF まで試行して最大245日かかる計算に (1auth / 0.004sec)• パスワードなので全通りやれば必ず当たるとはいえ非現実的• 諦めた（燃え尽きた）試行: Target Dataの総当り (失敗)Source code:https://github.com/shutingrz/aqua-engine-ecu-hack/blob/master/brute_targetdata.py
まとめ
• トヨタのECUは2013年時点でも十分に強かった• 車両診断では更新ファイルがなければパスワードが推測が必須であり強固• 診断ソフトを解析されてもまだ侵害できないのは強い• ただ同一バージョンのECUを10台入手し並行で総当りすることで、理論上24.5日で判明するはず（今回は不採用）• あえてUDSの仕様に従わないことで対策を講じている？• 隠すセキュリティまとめ 1/3
• このモデルなら、ハードウェアアプローチであればファームウェアが抜き出せる• 抜き出し、解析すればTargetDataも判明する• ただし抜き出せてもセキュアブートなどがあれば不正な書き換えは防止できる（試したかった・・・）まとめ 2/3
• スバル(2007~)・三菱の一部車種は診断経由でファームウェアを読み書き可能な模様• SecurityAccess・リプロ手順が解析されツール化している• 汎用的に利用できるのでTargetDataなどの対策が存在しないと思われる• お金持ちになったら試したい（ヤフオクで1万超えとか）まとめ 3/3野良リプロソフト「ecuflash」のコード(Themidaでパッキングされてた）
おわり※コントローラでメーターを操作したい！という方のためにソースコードを置いていますhttps://github.com/shutingrz/aqua-meter-joy※総当りやSecurityAccessを解除するスクリプト、SEEDデータは下記に置いていますhttps://github.com/shutingrz/aqua-engine-ecu-hack
shutingrz
masasuzu
clairegiordano
dahatake
sansantech
tkikuchi1002
poteboy
nwiizo
chiroito
knsg16
lemiorhan
naohachi89
aki_iinuma
jonyablonski
skipperchong
ddemaree
pauljervisheath
malarkey
jensimmons
geoffreycrofte
vanstee
cassininazir
philhawksworth
bkeepers