特斯拉的OTA升級過程

來自專欄汽車電子設計13 人贊了文章

騰訊科恩實驗室的李兄給了我授權有關於《BlackHat 2018 | 對特斯拉汽車全方位的滲透測試》和Black Hat上的文章

• 《FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN BUS》
• 《OVER-THE-AIR: HOW WE REMOTELY COMPROMISED THE GATEWAY, BCM, AND AUTOPILOT ECUS OF TESLA CARS》

裡面有很大的一部分是利用Webkit漏洞進行滲透攻擊。我讀了以後覺得挺有趣的，其中主體分為兩部分：

• Tesla 的OTA的主要過程
• 滲透攻擊的過程（這個要花一些時間再學習下）

本文主要根據這些信息，梳理一下，Tesla 的OTA過程

特斯拉的OTA升級過程大致可由幾個關鍵步驟描述。

1）OTA過程雲端通過特斯拉自有的握手協議下發固件下載地址後，特斯拉中控屏上的cid-updater會從雲端下載固件，進行解密並校驗其完整性

• 通過類似於A/B Update的方式，車內其他強運算力的聯網組件（如IC、APE等）根據cid-updater提供的固件文件進行升級。
• CID-updater還會負責根據固件包中的目錄信息與車輛配置做比照，據此產生release.tgz文件，並和升級軟體boot.img一同提供給網關。然後網關執行上述升級軟體，更新在網關上連接的二十餘個ECU。

備註：Tesla的OTA機制中的一些關鍵文件，boot.img和release.tgz，負責向ECU提供固件。 這些文件無法直接在特斯拉伺服器發布的更新包中找到，關於如何從特斯拉的伺服器獲取更新包以及汽車方面的整個更新過程仍然不清楚，這個過程仍未公開。

1）整車企業的雲端：握手和固件包（FIRMWARE BUNDLE）

特斯拉有一個OTA框架，完成OTA程序需要這些模塊：

• Message box
• Firmware gathering
• Job management

大多數模塊放在CID上的QtCar和QtCarServer中，作為雲代理的一部分。 一旦建立了可信通道，代理就會設置一個埠，遠程伺服器可以將消息直接推送到汽車。必要時將從伺服器端消息框中提取未讀消息。 在OTA更新期間，這些代理主要用來傳遞信息，而不是執行實際更新操作。

FOTA過程以消息開頭，開始的時候用帶有命令initiate_firmware_handshake的消息，收到消息後，代理會將握手命令發送到cid-updater，與伺服器進行握手。 握手期間需要執行以下步驟：

• cid-updater把整車的硬體配置字元串和package_signature一起發送到遠程伺服器，package_signature是根據整車ECU現有版本生成
• 整車企業的雲端（固件伺服器）將驗證該信息，根據當前版本提供固件包（FIRMWARE BUNDLE），包括固件包的下載地址、校驗和和解密信息。 SquashFS包含除了Autopilot以外的其他所有ECU文件
• 固件包通過CDN加密渠道分發，cid-updater會進行下載、驗證和解密

一旦提供了合法固件，cid-updater根據汽車配置收集正確的文件，並將這些文件分發到汽車的ECU內。 在OTA更新過程中，作業管理器負責向遠程伺服器報告當前狀態和錯誤信息， 每個更新作業都有一個用於跟蹤使用情況的作業ID。

2）車輛端：乙太網連接的ECU

中控台和儀錶盤是特斯拉車中兩個主要的更新組建，都有一個名為cid-updater和ic-updater的updater守護進程，這些二進位文件之間共享了一些代碼，但這兩個守護進程的主要目的是不同的。

• cid-updater負責在可靠的通信通道建立後與遠程伺服器通信，獲取固件包，並提供必要的文件和信息作為輔助伺服器，
• ic-updater則專註於更新儀錶盤本身。可將cid-updater視為本地伺服器，ic-updater視為遠程代理。

cid-updater和ic-updater都有一個名為command_service_listener的服務，此服務將打開一個埠，伺服器可以執行RPC直接調用代理上的函數。一旦準備好所有內容，代理將使用此服務獲取客戶端的更新代理。伺服器使用以下過程式控制制遠程代理：

1.遠程單元將停止所有其他工作並準備好gostaged，會嘗試下載目標的文件包。

2.本地伺服器啟動HTTP伺服器並提供更新文件，文件準備好後，將通知遠程代理。

3.遠程代理下載更新文件，下載文件並驗證其簽名後，更新程序將進行分段

4.將更新文件刷入ECU，對於儀錶盤來說

• 假設當前在Part A運行
• 將新的rootfs圖像和DTB刷入 Part B
• 將新的Kernal寫入Part B
• 將主引導鏈和恢復引導鏈切換到Part B
• 檢查引導鏈以確保下次引導是可接受的

完成所有這些操作後，設備將處於暫停和非活動狀態。

5.經過最後的準備工作後，設備將重新啟動：代理和伺服器之間將持續連接，伺服器可以獲得有關當前更新狀態的最新信息

3）車輛端：網關轉換的CAN匯流排ECU

這些ECU的更新文件存儲在文件夾（squashfs-root）/ deploy / seed_artifacts_v2中 ：boot.img、release_version.txt 、version_map2.tsv和Signed_metadata_map.tsv、internal_option_defaults.tsv、ECUNAME/, like esp/, gtw/ etc

boot.img文件在升級時運行，並從release.tgz讀取固件文件。 boot.img包含一個簽名，在其原始EOF之後填充。 發送更新命令時，將檢查此簽名是否通過公鑰驗證。

Boot.img中的一個重要步驟是讀取固件包release.tgz，包含網關用來更新相應ECU的所有文件，每個ECU只有一個固件文件。 從ECUNAME / PROVIDERID / ECUFWNAME.hex複製特定的固件文件。 在打包tar文件時，cid-updater從網關獲取ECU信息和汽車信息，並根據signed_metadata_map.tsv中的表選擇正確的PROVIDERID，文件格式如下：

以下是刷寫ECU的關鍵步驟：

1.製作固件包，cid-updater將從網關獲得最新的ECU硬體信息。對於每個ECU，cid-updater將搜索signed_metadata_map.tsv以查看哪條線與當前汽車具有相同的Requirements欄位。找到後，它會將PATH_TO_FILE中的文件複製到名為New_name的tar文件中。為了簡化更新包，cid-updater只會將signed_metadata_map.tsv中的相應行複製到release.tgz中具有相同名稱的文件中。

2.根據更新模式，在SD卡中創建UPD文件, updater讀取此文件以了解其當前狀態。

3.更新程序boot.img上傳到SD卡，並使用文件名重新啟動。

當updater執行時，未修改的boot.img將每個文件讀入內存，使用signed_metadata_map.tsv中相應行中的前幾個欄位填充，並使用符號值和啟動時保存的公鑰驗證其簽名.IMG。更新程序一旦找到不正確的固件文件就會退出，更新將導致失敗。所有簽名和散列演算法都使用帶有SHA512的Ed25519，並仔細選擇所有公鑰和常量。

小結：周末花了挺長時間整理了一下，確實挺有意思的，供各位讀者參考，感謝科恩實驗室的研究和整理，我這裡主要做一些我看得懂的摘錄和整理