Tweet
Tweet

Slide 1

Slide 1 text

ANALYZE AUTOMOTIVE ECU 〜ECUをハックした話〜 しゅーと(@shutingrz)

Slide 2

Slide 2 text

• カーセキュリティの基本とハックのアプローチについて ■目次 • カーハッキングの始まり • CANセキュリティ • メーターに対してスキャンを行い挙動を推測してみる • ECUセキュリティ • エンジンECUに対して診断を利用したハックの試行（失敗） 話すこと

Slide 3

Slide 3 text

• 本資料は私個人の調査結果によるものであり、所属組織・部門 は関係ありません • 発表資料はあとで公開します • 撮影は一部スライドを除いてOK おことわり

Slide 4

Slide 4 text

• しゅーと (@shutingrz) • セキュリティエンジニア • 元SOCアナリストで4月に異動 • ゲーム&IoTペネトレ初心者 • 7月からカーセキュリティに手 を出す • IoT 勉強中 WHO AM I

Slide 5

Slide 5 text

• 営業「来月からカーハッキングの案件始まるから」 • ハードウェア勉強開始２ヶ月初心者ぼく「え？」 • クルマわからないし、なんならIoTもハードもわか らない • みんなの足を引っ張るわけにはいかない！！！ • カーハッカーズハンドブックを読んで猛勉強 • 車載システムの仕組みからハックまで広く解説 ことのはじまり

Slide 6

Slide 6 text

• カーハッカーズハンドブックはクルマを持っている人向け • 一部はシミュレータに関する記述があるが・・・ • 中古車を買うとしても維持費考えたら高すぎる • 勉強用に買うのはさすがに・・・ 最大の障壁：クルマを買うお金がない

Slide 7

Slide 7 text

貧乏人だってカーハッキングしたい！

Slide 8

Slide 8 text

• 解体屋さんが廃車となった車 をバラしてパーツ売り • 色んなECUを売っている • 古い車種や不人気モデルは 笑っちゃうくらい安い • 送料には気をつけて ヤフオクでECUを買う

Slide 9

Slide 9 text

• CAN通信に対応 • デジタル表示がかっこいい • 色んな計器表示がある • 新しいのに安い（1000~2000円) • トヨタなので情報が豊富 アクアを選んだ理由

Slide 10

Slide 10 text

• 必要なもの • 12V電源（ACアダプタでOK） • ジャンパワイヤ • ブレッドボード • CAN-USBアダプタ • CANableがおすすめ • テスター • これだけなら7000円程度 • メータ合わせて1万かからない！ 参考:解析環境について

Slide 11

Slide 11 text

1. CANセキュリティ コンビネーションメーターの解析

Slide 12

Slide 12 text

• トヨタアクア(2013年製) 搭載のコンビネーションメーター • クルマのあらゆる情報を集約し、スピードや警告を表示する • 現代の車載コンピュータ(=ECU)はCANバスを通して情報を やりとりしている • ECU : Electric Control Unit もともとはエンジン制御用のため開発された経緯から Engine Control Unit の略だったのこと • さらに近年ではCAN FD/車載 Ethernet が普及の兆し？ 基本情報

Slide 13

Slide 13 text

CAN (Control Area Network) • バス型ネットワークでノイズに強い通信方式 •L1 および L2 のレイヤーの仕様 • 各ECUで2本の線をつなぎ合わせコリジョンを避けつつ通信 • CAN ID が小さい方が優先される / IDが大きい方は少し待って再送信 ノード ノード ノード ノード 送信 受信 受信 受信 バス ID: 123 Data: 00FF00...

Slide 14

Slide 14 text

• Linuxでは canX という形式のインターフェイス名で認識 • IDは 11bit CANの場合 0x000 ~ 0x7FF • データは最大 8 バイト • CAN FDという非互換のプロトコルでは 最大 32、64バイトなど CANデータの例

Slide 15

Slide 15 text

• 近年のクルマには必ず診断ポートが存在 • 世界各国で実装が義務付け • 診断ポートに様々な通信規格が同居 • 近年は大半がCANを使うように (Pin6, 14) 参考: 実車でのCANバスへのアクセス © Zepto~jawiki

Slide 16

Slide 16 text

• ピンアサインの特定 • ピンは合計53pinある • 整備書を入手したほうが安全で早い • トヨタは車種ごとに電子技術マ ニュアルが存在する • CANと電源程度なら初心者でも雰 囲気で特定可能 • メータなので起動確認は容易 1. 起動

Slide 17

Slide 17 text

ファジングを行い挙動を観測 • CAN通信可能なUSB機器を通じてランダムデータを送信 • ECUに定義されたID・データと合致すると何かが起きる •挙動の種類によってそのクルマの各ECUが使うIDも特定可能 CANID: 123 Data: 1234... CANID: B3A Data: FFFF... 警告音 警告灯の点灯 車速の変化

Slide 18

Slide 18 text

ファジング時のメーターの挙動 https://youtu.be/rMZjkm46sYY

Slide 19

Slide 19 text

• 素直に反応するのでチェックサムやMACなど検証の仕組みはない • 単純に偽造データを信じてしまう • 車速は早い段階で上昇しすぐゼロに戻った • 警告灯関係は表示されたあとずっと表示される • データがオン/オフのスイッチの役割を果たす？ • 何度も試しても反応しない計器・表示灯がある • CANバスではない別の端子から信号が入力される？ 考察

Slide 20

Slide 20 text

挙動に対応するデータ構造の特定 000～7FF →反応 000～4FF →反応 000～2FF →無反応 300～4FF →反応 3B7 →反応 500～7FF →無反応 • どのIDで目的の挙動を示すかを二分探索 • ID特定時のデータは８バイトで全て「FF」 • 目的の ID が判明したら次はどのデータ部に反応するかをひたすら試行 FF FF FF FF FF FF FF FF →反応 00 00 00 00 FF FF FF FF →反応 … 04 … →無反応 … 08 … →反応 (5Byte目 の 4bit目) FF FF FF FF 00 00 00 00 →無反応 (略) ビットレベルで定義 されることも多い ID Data (略)

Slide 21

Slide 21 text

• candump (スニファ) / cangen (トラフィックジェネレータ) • ファジングデータの生成に使用 • cangen で ID: 000 ~ 7FF , Data:「全てFF」のデータを生成 • candumpでそれをテキストデータに落とし込む • canplayer & grep , head , tail • ファジングに使用 • テキストデータをもとにトラフィックを生成 • データ絞り込みのために一般的なLinuxコマンドが使える 特定のために使用するソフトウェア

Slide 22

Slide 22 text

• カーハッキングの十徳ナイフ • canplayer による絞り込みの 部分を対話的に行える • 他にも診断機能の特定など 様々なモジュールを備える CARING CARIBOU

Slide 23

Slide 23 text

調査結果 (データが多いので省略) https://www.shutingrz.com/post/aqua-meter-hack/

Slide 24

Slide 24 text

解析で得られた情報でシミュレーション https://youtu.be/5ZJSc0vtP5E

Slide 25

Slide 25 text

• 車載の様々な情報は CAN を利用している • 単純なファジングでも十分に解析ができる • 攻撃者からのニセデータで計器・運転手を騙すことが可能 • 運転中に警告を発火させ運転手を混乱させられる • 自動運転に車速データなどを利用していたら・・・？ コンビネーションメーター解析まとめ

Slide 26

Slide 26 text

• ゲートウェイの設置 • 機能に合わせてネットワーク を分離化 • ホワイトリストフィルタ • ただし診断通信は運用上 通さざるを得ない • MAC（メッセージ認証） • AUTOSARで文書化 • リアルタイム性との兼ね合い CANセキュリティの今 CGW パワートレイン系 ボディ系 マルチメディア系 OTA系

Slide 27

Slide 27 text

■ECUセキュリティ エンジンECUの解析

Slide 28

Slide 28 text

• やりたかったこと • ファームウェアを読みたい • ファームウェアを書き換えたい →セキュアなので読むことすらできませんでした • 調査を通じて現在のECUがどれだけ頑張っているのかを説明します おことわり

Slide 29

Slide 29 text

• トヨタアクア(2013年製) 搭載のECM (Engine Control Module) • かつては ECU (Engine Control Unit) という名称 • 様々なセンサー情報をもとにスロッ トル等を調整 • クルマを動かすのに一番大事な所 基本情報 ※ヤフオクで500円

Slide 30

Slide 30 text

ECUのリバースエンジニアリングについて 前提となる情報の紹介

Slide 31

Slide 31 text

• 一般車ではECUにてエンジンリミッ ターがかけられている • モータースポーツ界隈ではそのリ ミッターを外しパフォーマンスを得 る試みがある • ROMチューン • リプログラミング • ファームウェア・テーブル書き換え • クルマ業界では「リプロ」という ECUのリバースエンジニアリング

Slide 32

Slide 32 text

• ホビー用途でリミッター解除をする のは大きな問題ではない • リプロとは、全ての挙動を書き換え られるということ • 攻撃者が他人の車で悪用したら？ • いわゆる「マルウェア感染」 • 高速道路で突然停止 • 歩行者を検知した瞬間急加速 リプロ対策はなぜ必要？

Slide 33

Slide 33 text

• Uconnectという車載ナビに脆弱性 • 携帯電話網を使ってナビやWifi AP機能 などを提供する • リモートでファームウェアをリプロし、 任意のCANメッセージを出せるように • 運転アシスト用ECUのCANメッセージを 偽造しアクセルやハンドル操作 参考: リモートから攻撃されたジープ http://illmatics.com/Remote%20Car%20Hacking.pdf https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

Slide 34

Slide 34 text

• クルマはIoT機器の一種 • 一般的なハードウェアハックのアプローチが有効 1. ROMに直接アクセス 2. デバッグ機能でアクセス 3. 車両診断機能でアクセス 番外: 脆弱性を悪用（Jeepのような） • リッチなECUならまだしも単機能ECUではほぼ見つからない リプロの手法

Slide 35

Slide 35 text

• 昔はよく使われていた手法 • 微細化が激しいがMSOPサイズな ら素人でもできる • 近年ではフラッシュ内蔵のSoCが 普及しており本手法は困難に • 外付けでEEPROMにファームウェ アが存在するのは稀 1. ROMに直接アクセス ・メーターの走行距離が保存されるROM ホットエアーで外しSOP8変換基板に再実装

Slide 36

Slide 36 text

• 昔〜近年のECUで可能な手法 • SoCによってはJTAGなどのデバッ グポートが存在し、ロックがか かっていないことがある • これを利用したデバッグやFlash の読み書きが可能 ※シリアルポートも同様 2. デバッグ機能でアクセス SH70XXのBootmodeを使った読み書き

Slide 37

Slide 37 text

• NECのMCUをカスタマイズした 「76F00XX」シリーズが搭載され ている • “プログラミングポート”が存在 • これらを利用した ECU Tuning 製 品が出ている • NECのマイコンにある機能: NBD (Non-Break Debug)を利用する 参考: 2013年頃のレクサスのエンジンECU

Slide 38

Slide 38 text

参考: NBDを利用したFLASH READ https://youtu.be/vF2B9le-uY4

Slide 39

Slide 39 text

• LEXUSと同じDenso MCU • 76F0085が搭載 • プログラミングポートは未搭載 • パターンが外に出ていない • 俗称"Toyota Denso Gen1 ECU"シ リーズ以降は全てこの仕様らしい • レクサスのECUを入手してピンア サインを比較・特定すれば行ける かも？（今回は断念） アクアのエンジンECUの場合

Slide 40

Slide 40 text

• "MCU NEC 76F0085を搭載した Toyota Denso Gen1 ECUの最新バー ジョンは小さな金属ケースに入っ ており、NBD / JTAGポートはあ りません。(略) したがって、このECUタイプは一 般的な方法では読み取ることがで きません。" • "ファームウェアはBGAを外すか、 トヨタから入手する必要がありま す" (要約) 参考: リプロツール業者の記事 http://bitbox.ru/en/news/68

Slide 41

Slide 41 text

• リプロ最後の砦 • ECUはOBDポートを用いて診断を行う • 近年はCANバス上で診断(DoCAN) • ファームウェア更新のときにも診断機 能を用いる • メーカー・車種・生産年代によって仕 組みが異なり、最近ではセキュリティ も強固 3. 車両診断機能でアクセス ©Saitobesho

Slide 42

Slide 42 text

• ECUが検出した故障を診断機が受け取るための仕組み • クルマを全て分解して不具合を特定するのは大変なため • 問題の切り分けのため診断機からECUに各種機能をオン オフさせることも可能 →アクティブテスト • 様々な診断プロトコルがある • OBD2, KWP2000, UDS… (後述) 車両診断とは

Slide 43

Slide 43 text

アクア エンジンECUの解析 車両診断機能を使ったリプロの試み

Slide 44

Slide 44 text

• ピンアサインの特定 • ピンは合計195pinある • 整備書を使って特定 • メータと同じく気合でもいける • LED等はないので正常に起動し たか調べるにはCAN通信を見る 必要がある • しかし起動しても能動的に CAN通信は流れてこない 1. 起動

Slide 45

Slide 45 text

• OBD2 • 故障診断のために作られ、古くから用いられている • 仕様策定の段階でコネクタ形状まで統一され以後使い続けられる • KWP2000 • より高度な診断、更新のために作成された • メーカーにより実装がバラバラ • UDS • KWP2000の実装依存の部分をちゃんと仕様化 • それでもメーカーが従うかは別・・・ • 現在はUDSが標準になってきている 参考: 車両診断機能の一覧

Slide 46

Slide 46 text

• OBD2 • 故障診断のために作られ、古くから用いられている • 仕様策定の段階でコネクタ形状まで統一され以後使い続けられる • KWP2000 • より高度な診断、更新のために作成された • メーカーにより実装がバラバラ • UDS • KWP2000の実装依存の部分をちゃんと仕様化 • それでもメーカーが従うかは別・・・ • 現在はUDSが標準になってきている 参考: 車両診断機能の一覧

Slide 47

Slide 47 text

• OBD2は仕様としてエンジンに関する様々な項目を取得できる • エンジン回転数や燃料・温度... • 世界的に搭載を義務付けられているため、ECMが動いているかの 確認にも使える • リクエストペイロードは２バイト • 1バイト目: サービスID • 2バイト目: パラメータ • サービスIDが「何をするか」、パラメータは「何に対して」 • KWP2000・UDSではパラメータはSubFunctionという OBD2を用いた生存確認

Slide 48

Slide 48 text

• リクエスト •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..?...'

Slide 49

Slide 49 text

• Caring Caribouの uds discovery • CANID: 7DF, 7E0 に反応 •7DFはCAN上診断のブロードキャスト を示す リクエスト用CANIDは7E0だろう • このECUはUDS亜種 •機能はUDS、SIDだけKWP2000 KWP2000・UDSの機能の確認 $ ./cc.py uds discovery ------------------- CARING CARIBOU v0.3 ------------------- Loaded module 'uds' (snip) Identified diagnostics: +------------+------------+ | CLIENT ID | SERVER ID | +------------+------------+ | 0x000007df | 0x000007e8 | | 0x000007e0 | 0x000007e8 | +------------+------------+

Slide 50

Slide 50 text

• 全般 •DiagnosticSessionControl •セッション切り替え（後述） •SecurityAccess •セキュリティ機構 •これを突破しないと診断以外の機能は基本的に使えない UDSで定義されている、リプロに有用なサービス

Slide 51

Slide 51 text

• メモリ読み書き系 •ReadMemoryByAddress : •指定したメモリアドレスの読み込み •RequestUpload : •指定したメモリアドレス範囲の転送(ECU→Client) •WriteMemoryByAddress : •指定したメモリアドレスの書き込み •RequestDownload : •指定したメモリアドレス範囲の転送(Client→ECU) UDSで定義されている、リプロに有用なサービス

Slide 52

Slide 52 text

• 要求が受け入れられる場合はサービスIDに+40したレスポンスIDが返る • Positive Resonse • 受け入れられない場合はレスポンスIDが「7F」でそのあとにエラーコード • Negative Response (ちなみにCode22はconditionsNotCorrect ) 参考: UDSのデータ形式 Client ECU 10 01 50 01 10 02 7F 10 22 通常セッションに切り替え要求 Positive Response リプロセッションに切り替え要求 Negative Response (ErrCode 22)

Slide 53

Slide 53 text

• SID 0x00 ~ 0xFF 、 SubID: 00 でひたすらリクエストを送って 応答を確認 •サービスが存在しない場合はCode11が返るためそれ以外を探す • Caring Caribou の uds services が使えるが、取りこぼしが多い •改良版をPull Request中 3. 対応サービスのスキャン

Slide 54

Slide 54 text

• 診断用のサービスIDがあるがメモリ読み書き系は全く無い •別の診断セッションに切り替えられれば出てくるかもしれない • メーカ独自定義のサービスが割と多い（やめてほしい。。） • SIDの割り振り方はKWP2000 •しかし中身(SubFuncのIDなど)はUDSというちぐはぐな仕様 3. 対応サービスのスキャン(結果) SID Name Desc 10 DiagnosticSessionControl 診断セッション切り替え 21 ReadDataByIdentifier 各種情報の読み取り 27 SecurityAccess セキュリティ認証機構 30 InputOutputControlByIdentifier 各種入出力機能の制御 3B WriteDataByIdentifier 各種情報の書き込み A1 ~ A4 , A7, A8 *[Defined By Vehicle Manufacturer] メーカ独自定義 ↑スキャンの結果 ECUが反応したSID (一部抜粋)

Slide 55

Slide 55 text

• セッションは複数種類ある •通常セッション、リプロセッション、 拡張セッション... • デフォルトは通常セッション • 通常セッションはできることは殆どない • メモリ読み書きしたいなら他セッション • 他セッションは原則SecurityAccessを 突破したうえで切り替える • 突破せずとも切り替えられるパターンも • メモリ読み書き系は実装により突破しな いと拒否されることもある 診断セッションについて ISO 14229より引用

Slide 56

Slide 56 text

• SID: 10でSubIDを00~FFで試す →5つのセッションが見つかった • リプロセッションが存在 • ただSecurityAccessを突破しない と入れない模様 • 他セッションはSecurityAccess突 破なしでも切り替えられた • 全てメーカ独自のセッションID • 独自なので何ができるか全く不 明 • メモリ読み書き系は見つからない 診断セッションの切り替え ID セッションの種類 Resp Code 意味 01 Default 50 Positive Response 02 Programming 22 conditionsNotCorrect 40 vehicleManufactur erSpecific 50 PositiveResponse 5f vehicleManufactur erSpecific 50 40 PositiveResponse 61 systemSupplierSpe cific 50 PositiveResponse

Slide 57

Slide 57 text

• 最後の望みはリプロセッション • ファームを書き換えるので機能も きっとあるはず！ • リプロセッションに切り替えるた めにSecurity Accessの突破が必須 診断セッションの切り替え ID セッションの種類 Resp Code 意味 01 Default 50 Positive Response 02 Programming 22 conditionsNotCorrect 40 vehicleManufactur erSpecific 50 PositiveResponse 5f vehicleManufactur erSpecific 50 40 PositiveResponse 61 systemSupplierSpe cific 50 PositiveResponse

Slide 58

Slide 58 text

Security Access の突破 試行錯誤の日々・・・

Slide 59

Slide 59 text

• チャレンジ&レスポンスの認証方式。SeedをもらってKeyを送る • 実装方法は自由なのでメーカ・車両・年代で変わる • 故障診断以外の機能は認証を突破しないと使えない Security Access Client ECU 27 01 67 01 72 70 8D 9D 27 02 12 34 56 78 7F 27 35 Level 01 の Seed をください Seed: 72 70 8D 9D Seedに対応のKeyは12 34 56 78？ ちがうわ！！ ( Invalid Key)

Slide 60

Slide 60 text

• Seedに対するKeyを導出する式（暗号化アルゴリズム） を見つけることがゴール • ファームウェアを抜き出し解析するのが一番早い • それができるなら苦労しない Security Access のゴール

Slide 61

Slide 61 text

• Keyが何バイトかは実装依存 • UDSではエラーコードに "Incorrect message length or invalid format (0x13)"がある • これを利用してサイズを特定 • 0x13ではなく0x35(Invalid Key) になるバイト数を探す →4バイトであることが判明 STEP1: KEYサイズの特定 can0 7E0 [3] 27 02 00 can0 7E8 [3] 7F 27 13 can0 7E0 [4] 27 02 00 00 can0 7E8 [3] 7F 27 13 can0 7E0 [5] 27 02 00 00 00 can0 7E8 [3] 7F 27 13 can0 7E0 [6] 27 02 00 00 00 00 can0 7E8 [3] 7F 27 35 can0 7E0 [7] 27 02 00 00 00 00 00 can0 7E8 [3] 7F 27 13

Slide 62

Slide 62 text

• 認証回数は9回まで • 10回目は回数超過としてコード 0x36 (Exceeded number of attempts) • 認証回数が超過するまでは何度でも同じ Seedが返される • 再起動するとSeedがかわる • Seedの生成に偏りがある • 1バイト目はほぼ4通りしかない • 起動ごとにだいたい決まる • 4バイト目は時間ベースで増加 • 約1500回周期でSeedが被ることがある →リプレイアタックが有効 （今回は意味無し） STEP2: 認証仕様の特定 Seed: 41 a2 43 81 Seed: 01 7d 9f 82 Seed: 01 65 82 87 Seed: c1 89 60 89 Seed: 82 72 98 8a Seed: 41 af 40 8f Seed: 41 b6 46 90 Seed: 01 7c 89 95 Seed: c1 bb 4c 97 Seed: 82 72 8a 98 Seed: 41 a1 5c 9d

Slide 63

Slide 63 text

• チャレンジ&レスポンスなのでアルゴリズムから推測が必要 • パスワードではないので総当りはほぼ不可能 • チャレンジ一回につき4バイト=2^32通りが考えられる • でもやらなきゃ始まらない・・・ STEP3: 暗号化アルゴリズム&KEYの特定

Slide 64

Slide 64 text

• Seed関係なく特定のバイト • いわゆる「パスワード」=総当りで解ける • 初期のECUではよくあった • ビットシフト • 単純なXOR • この年代のECUでよくある模様？ • 上記+バイトの足し引き • 長い鍵+AESによる暗号化 • これは鍵を手に入れないと突破は不可能 様々なECUでのKEYの生成パターン

Slide 65

Slide 65 text

• この年代は単純な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

Slide 66

Slide 66 text

• 以下の想定 1. 4byteXORとみなし、1バイトずつ のXOR比較をしていると仮定 2. 1バイト目が正解なら2バイト目の 比較に移行し、不正解ならreturn されるため命令数の差異が発生 →正しい組み合わせのときだけ平均レ スポンス時間が長くなるのでは？ 試行2: タイミング攻撃⏱ 一致？ エラー InputByte++ KeyByte++ 最終？ 認証成功 初期化: InputByte KeyByte Yes Yes No No ↑1バイト目が正しかった場合、 1ループ分余計に時間がかかる？

Slide 67

Slide 67 text

• 1つの組み合わせにつき50回試行 →全通りで有意な差はでなかった • 複数回試行で順位が何回も変わる • もし時間がかわるとしてもリモート 測定では様々な要因で正確な計測は できないかも 試行2: タイミング攻撃⏱ (失敗) Source code: https://github.com/shutingrz/aqua-engine-ecu-hack/blob/master/check_key_timing.py $ python3 ./check_key_timing.py endByte test: 12740 / 12750 (XORCand: 0x000000fe, ETA(s): 0:00:00) finish. sort: key: 0x25, time: 0.004235796928405761 key: 0x26, time: 0.004141133308410644 key: 0x76, time: 0.004133680820465088 (snip) topByte test: 12740 / 12750 (XORCand: 0xfe000000, ETA(s): 0:00:00) finish. sort: key: 0xea, time: 0.004177097320556641 key: 0x7c, time: 0.004164288997650147 key: 0xe7, time: 0.004154132843017578 (snip)

Slide 68

Slide 68 text

突破は無理なのか・・・？

Slide 69

Slide 69 text

プリウスなら誰かやってないか・・・？

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

• IOActiveが出した2車種のレポート • Ford Escape / TOYOTA Prius • 様々な手法で実車をハックしている • 診断機を解析することで SecurityAccessを突破 • 暗号化仕様も詳細に記載 • 著者はCODEBLUE2014で同レポー トに関連する発表をしている PRIUS HACKレポート https://ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_Control_Units.pdf https://www.slideshare.net/codeblue_jp/chris-valasek-japub

Slide 73

Slide 73 text

• 診断機は車の診断のほかECUの 更新機能ももつ • J2534規格によるリプロの標準化 • 個人でもリプロができる時代 • 規格対応のI/Fは必要 • トヨタはtechstreamという診断ソ フトウェアを提供 診断機を使ったリプロ機能の解析

Slide 74

Slide 74 text

• トヨタでは個人でもECUの更新 ファームウェアが入手可能 • $60/2days のライセンス... • ECUに対応した更新ファイルが 提供されていれば、それを用い て更新が可能 • techstreamの静的解析と通信解 析を行えば仕様は丸裸に 診断機を使ったリプロ機能の解析

Slide 75

Slide 75 text

• Techstream同梱のECU更新ソフ トにSecurityAccessのクライア ントがある • IDAで解析しアルゴリズム特定 • Keyの算出は4バイトXOR プリウスのSecurityAccess

Slide 76

Slide 76 text

• Techstream同梱のECU更新ソフ トにSecurityAccessのクライア ントがある • IDAで解析しアルゴリズム特定 • Keyの算出は4バイトXOR • キーは 0xXXXXXXXX プリウスのSecurityAccess 公開用

Slide 77

Slide 77 text

アクアの認証仕様と比較してみる Aqua ECM Prius ECM 年代 2013年 2010年 ECMの診断用CANID 0x7E0 0x7E0 SendKeyのLevel 0x02 0x02 Seedの長さ 4バイト 4バイト Keyの長さ 4バイト 4バイト 認証試行回数限度 9回 9回 Seedのライフタイム 試行超過するまで同じ値 試行超過するまで同じ値 • 同じ認証仕様と推察される • 他にもレポート記載のSeed例についても類似点がみられた

Slide 78

Slide 78 text

アクアで試してみた can0 7E0 [2] 27 01 can0 7E8 [6] 67 01 72 70 D3 C3 can0 7E0 [6] 27 02 72 10 B3 C3 can0 7E8 [2] 67 02 ~ can0 7E0 [2] 27 01 can0 7E8 [6] 67 01 00 00 00 00 Request Seed Response Seed (7270D3C3) Send Key (7210B3C3) Auth Success (Positive Response) Request Seed (認証済みか確認） Authenticated ( 00000000 ) • 成功した ※認証後にSeedを要求された場合は 00000000 を返す仕様なので、それで認証成功を確認できる

Slide 79

Slide 79 text

• アルゴリズム自体は正しかった • ずっと回していれば1日でたどり着く値だった 試行1: 単純な総当り (失敗)について 公開用

Slide 80

Slide 80 text

Security Access 突破後における メモリ読み書き機能の調査

Slide 81

Slide 81 text

• 認証突破前はエラー • コード22 「条件不足」 • 突破後に試したところ成功 • リプロセッションに入れた! • それでもメモリ読み書き系 のサービスは存在せず。。 • UDSの仕様は無視されてる リプロセッションへの切り替え can0 7E0 [2] 10 02 can0 7E8 [3] 7F 10 22 can0 7E0 [2] 27 01 can0 7E8 [6] 67 01 F1 76 2A 3C can0 7E0 [6] 27 02 F1 16 4A 3C can0 7E8 [2] 67 02 can0 7E0 [2] 10 02 can0 7E8 [1] 50 セッション切替 （失敗） セッション切替 （成功） 認証（成功）

Slide 82

Slide 82 text

• レポートによるとリプロは以下の手順 1. リプロセッション切替 2. リプロ用CANIDの切替送信 3. ファームバージョンごとに設定された TargetData(パスワード)を送信 4. 正しい場合、ECUから0x3Cが返る 5. ライタプログラムを送信 6. ファームウェアを送信 ※完全に独自実装 参考: 診断ソフトがリプロを行う際の手順 ファームウェアを含むキャリブレーションデータ (.cuwファイル）

Slide 83

Slide 83 text

• レポートではリプロ時に下記の機能があるとの記載が • GetMemoryInfo(メモリレイアウトの要求) • CheckBlock (書き込み可能か確認） • EraseBlock (メモリのクリア) • WriteBlock / WriteBlockWithAddress(メモリの書き込み) • VerifyBlock(書き込まれたデータの読み出し） • ただしTargetDataを送信後に初めて使えるようになる 参考: リプロ手順中のコマンド

Slide 84

Slide 84 text

• レポートではリプロ時に下記の機能があるとの記載が • GetMemoryInfo(メモリレイアウトの要求) • CheckBlock (書き込み可能か確認） • EraseBlock (メモリのクリア) • WriteBlock / WriteBlockWithAddress(メモリの書き込み) • VerifyBlock(書き込まれたデータの読み出し） • ただしTargetDataを送信後に初めて使えるようになる 参考: リプロ手順中のコマンド

Slide 85

Slide 85 text

• 更新手順上ではWriteBlockでメモリを書き込んだあとに 呼び出し • 「応答」と「書き込んだはずのデータ」を診断ソフトが 見比べて差異がないかを確かめる • これを使えばメモリの読み出しができるのでは？？？ VerifyBlock？？

Slide 86

Slide 86 text

• リプロ用コマンドはTargetDataを 送信した後に使える • TargetDataはファームウェアの バージョンごとに異なり、更新 ファイルにのみそれが記載 • 法則性はなく推測は難しい • ファーム更新がなければ更新ファイル は存在せず、知ることは不可能 大きな壁: TargetData フォーラムで稀に投稿されることも （TOYOTA MR2の更新ファイル）

Slide 87

Slide 87 text

• 総当りを試してみよう → 0 ~ FFFFFFFF まで試行して最大245日かかる計算に (1auth / 0.004sec) • パスワードなので全通りやれば必ず当たるとはいえ非現実的 • 諦めた（燃え尽きた） 試行: Target Dataの総当り (失敗) Source code: https://github.com/shutingrz/aqua-engine-ecu-hack/blob/master/brute_targetdata.py

Slide 88

Slide 88 text

まとめ

Slide 89

Slide 89 text

• トヨタのECUは2013年時点でも十分に強かった • 車両診断では更新ファイルがなければパスワードが推測が 必須であり強固 • 診断ソフトを解析されてもまだ侵害できないのは強い • ただ同一バージョンのECUを10台入手し並行で総当りする ことで、理論上24.5日で判明するはず（今回は不採用） • あえてUDSの仕様に従わないことで対策を講じている？ • 隠すセキュリティ まとめ 1/3

Slide 90

Slide 90 text

• このモデルなら、ハードウェアアプローチであれば ファームウェアが抜き出せる • 抜き出し、解析すればTargetDataも判明する • ただし抜き出せてもセキュアブートなどがあれば 不正な書き換えは防止できる（試したかった・・・） まとめ 2/3

Slide 91

Slide 91 text

• スバル(2007~)・三菱の一部車種 は診断経由でファームウェアを 読み書き可能な模様 • SecurityAccess・リプロ手順が 解析されツール化している • 汎用的に利用できるので TargetDataなどの対策が存在し ないと思われる • お金持ちになったら試したい （ヤフオクで1万超えとか） まとめ 3/3 野良リプロソフト「ecuflash」のコード (Themidaでパッキングされてた）

Slide 92

Slide 92 text

おわり ※コントローラでメーターを操作したい！という方のためにソースコードを置いています https://github.com/shutingrz/aqua-meter-joy ※総当りやSecurityAccessを解除するスクリプト、SEEDデータは下記に置いています https://github.com/shutingrz/aqua-engine-ecu-hack