• Source: https://openatomworkshop.csdn.net/6645aedeb12a9d168eb6cb3e.html
• 
• 刷寫前，刷寫工具讀取ECU 的Boot 軟體版本號(F180)、軟體版本(F188)、 VIN(F190)、 硬體版本(F191)，根據從ECU 取得到的相關資訊到刷寫資料庫中尋找對應的升級檔。如果不是連續的，刷寫設備應該為每個要刷寫的資料塊發送一個單獨的請求。檢查刷寫的資料的完整性，確定來源合法，透過CRC、雜湊、數位簽章等方法，保證刷寫過程中不會出錯，且刷寫的資料是來自合法的提供者。

• 使用CANoe 等工具刷寫時，開發環境後台幫助我們完成了許多工作，平常大家很少注意到背後到底發生了什麼事。下面就來看看整個刷寫流程。
• 
• 刷寫過程定義了刷寫前、刷寫中、刷寫後三個階段， 負責將正確的刷寫檔案( S19 或HEX) 下載到ECU 中。

• 刷寫前，刷寫工具讀取ECU 的Boot 軟體版本號(F180)、軟體版本(F188)、 VIN(F190)、 硬體版本(F191)，根據從ECU 取得到的相關資訊到刷寫資料庫中尋找對應的升級檔。維修店代碼或診斷設備序號(F198)、刷寫日期(F199)在刷寫啟動時寫入，用於追溯先前的刷寫操作。
• 刷寫準備階段需要確認待刷寫控制器的相關版本信息， 設定刷寫網路等。這個階段在整車各控制器的應用程式中執行， 此階段， 使用功能位址向網路上的各控制器發出診斷請求進行網路設定。

• 預設狀態下ECU 在01 預設會話中,使用UDS 會話切換(10 03)進入拓展會話。

• 整車廠通常會定義一些控制器刷寫的前提條件，例如車速要低於3km/h等,這一步就可以檢查刷寫前提條件是否滿足。不同的OEM/Tier1可能有不同的檢查條件。常見的前置條件如下，
  • ECU 的電源電壓不能太高或太低(9V-16V)
  • 車輛處於IGN On 狀態， 但不在Ready 狀態
  • 車輛處於靜止狀態，車速為0km/h
• 具體實作上，使用31服務執行檢查程式條件的例程routine，如條件不滿足(例如車速過高等)，則退出刷寫。

• 刷寫過程中，控制器功能不正常，可能無法收發匯流排訊息，這種情況下，需要避免在這個過程中觸發故障碼儲存。使用85診斷故障碼設定服務設定故障碼設定類型為OFF(02)關閉DTC的儲存。

• 刷寫過程中，因為傳輸的資料較多，因此停用通訊封包的傳送可以降低匯流排負載。
• 使用28服務關閉與診斷無關的封包，將節約出來的通訊資源用於刷寫軟體，提升刷寫速度。

刷寫中先進行身份認證，而後可以寫入指紋，然後執行刷寫擦除內存，向指定地址下載固件，並檢查寫入是否正確。

• 刷寫過程必須要在程式設計會話中才可以進行。使用會話控制服務10 02 切換到programming session。

• 27 安全存取服務保證是有權限的人員或裝置才能夠進行刷寫，安全存取服務子功能請求種子向ECU 要求安全認證種子。

• 診斷設備收到種子後，將種子作為輸入，使用雙方已知的演算法，計算得到Key。然後使用子功能發送秘鑰將計算得到的秘鑰發送給ECU。 ECU使用相同的演算法計算出秘鑰並與收到的值進行對比，相同則認證通過。
• 如果連續多次認證失敗，安全存取會暫停服務一段時間。每認證失敗一次，ECU安全存取失敗計數器就會加1。當錯誤次數達到3次後，將收到0x36(嘗試次數超限)的否定回應碼，並延遲10秒。 10秒之內請求會收到0x37(延遲時間未到)的否定回應碼，10s之後才能再次發起認證請求。

• 記錄刷寫時間(F198)、寫入指紋資訊(F199)，標示寫軟體人的身分(維修店編號、診斷設備序號)。

• 在向ECU 的記憶體區域下載資料之前， 需要先擦除記憶體區域已有資料。
• 採用31 例程控制服務FF00 擦除內存，根據控制器位址空間分配和晶片擦除能力，單次擦除所有或多次分段擦除。
• 31 01 FF 00 擦​​除起始位址擦除長度

• 傳送軟體至ECU前需要指定寫入的位址和資料的大小。
• 刷寫設備使用34 請求下載服務向ECU 指定刷寫起始位址和刷寫資料的大小， 請求下載($34) 服務指定的記憶體從起始到結束應該是連續的。如果不是連續的，刷寫設備應該為每個要刷寫的資料塊發送一個單獨的請求。
• 34 資料格式識別碼 位址和長度格式標識記憶體位址記憶體大小

• 軟體下載服務，將資料下載到上一步指定的記憶體。
• 刷寫設備使用36 傳輸數據服務向ECU 記憶體區域傳輸刷寫的數據，一個數據塊通常需要多條傳輸數據服務傳輸。
• 36 資料塊順序計數器數據

• 37 服務退出目前連續記憶體區域的刷寫，將在肯定回應中攜帶校驗和，校驗最近的一條請求下載請求服務指定的記憶體區域。
• 傳回的校驗和與刷寫設備計算的校驗和進行比較，如果不相同，將重新使用36 數據傳輸服務下載數據，多次校驗不通過，刷寫將會中斷。

• 檢驗刷寫的資料的可靠性，在軟體/資料刷寫完畢時，刷寫設備透過例行程序服務來驗證刷寫到記憶體區域的每塊資料是否成功。
• 檢查刷寫的資料的完整性，確定來源合法，透過CRC、雜湊、數位簽章等方法，保證刷寫過程中不會出錯，且刷寫的資料是來自合法的提供者。

• 使用31 例程控制服務FF01 確認刷入的軟體和ECU的硬件，基礎軟體是相符的。

• 整個刷寫完成後，刷寫設備要求ECU 硬體重位， ECU 進入應用程式。
• 11 重設服務重啟ECU，使刷寫的新軟體生效。

• 刷寫後的步驟與刷寫前的步驟是對應的，啟用刷寫前停用的通訊等。
• 此時網路恢復到正常的模式， ECU 以預設的波特率進行正常的通信，並能進行故障碼的偵測和儲存。刷寫結束後要求各ECU 恢復非診斷訊息的發送及接收。

• 預設狀態下ECU 在01 預設會話中,使用UDS 會話切換(10 03)進入拓展會話。在拓展會話中，啟用非診斷通訊、清除刷寫階段產生的故障碼、各ECU 恢復故障碼的偵測。

• 使用28 通訊控制服務啟用在刷寫前停止收發的一般通訊封包。

• 恢復故障碼偵測，使用85診斷故障碼設定服務設定故障碼設定類型為ON(01)恢復DTC的儲存。

• 從拓展會話切換回預設會話。

• 刷寫中最主要的安全維修就是安全存取被突破，而後就能取得ECU中的軟體/資料以及刷入竄改的韌體。

• 安全存取演算法一般採用對稱加密演算法，通常還是簡單的移位演算法，演算法強度較低。
• 故障注入：演算法大部分主機廠自己設計實現的，演算法本身的安全性很少驗證。使用故障注入等方式存在被繞過認證的可能。
  • 
• 洩漏： 主機廠/供應商代碼、企標等在網路上外洩。
  • 
• 易被逆向： seed2key 一般以so 檔案存在，對韌體、診斷儀中的庫檔案逆向得到安全存取演算法。
  • 

• 設定問題：Key的有效長度過短，CVE-2017-14937 安全氣囊安全存取（SA）Key為2個位元組，第一個位元組恆為0x01，那麼氣囊點火演算法只有256個可能的金鑰對。

• 除了演算法本身以外，最重要的就是安全常數。安全常數通常為4個位元組。
• 安全常數硬編碼：安全常數硬編碼在so庫中，逆向安全存取演算法得到安全常數。
  • 
• 預設:使用預設的安全常數，在滲透測試中曾多次遇到，0xc541a9是最常見的安全常數。
• 使用相同常數：使用同一種演算法的ECU依賴不同的安全常數來保障安全性。不會因為一個模組演算法和常數分析出來之後，直接影響到另外一個模組上。此外，同一車型同一類型ECU的常量通常相同，很少有實現一機一密的。

• 種子可預測：某車型中的種子是基於時間產生，取得到Mask後，能夠預測到後續的種子。預測種子能夠縮減破解的時間。

• static uint32 UDS_GenerateSeed(void)
  {
  
     uint32 u32LocalSeedValue;
  
     u32LocalSeedValue = STM0_TIM0.U;
  
     u32LocalSeedValue ^= UDS_ku32LocLevel01;
  
     u32LocalSeedValue = ( u32LocalSeedValue << 7 ) | ( u32LocalSeedValue >> 24 );
    
     return u32LocalSeedValue;
  
  }

• 種子隨機性：種子隨機性較弱，多次要求出現相同種子的情況。
• 固定種子：每次取得到的種子相同，這使得爆破出Key成為了可能。
• 種子恢復：ECU復位後種子相同，每認證一次後復位一次，能夠有效降低爆破的數量級。

• 直接從應用層繞過，對一些實現了遠端診斷的車型，直接調用應用層，操作敏感功能，而無需要關注安全存取。
• ECU Reset 重置繞過安全存取延時。
• 安全存取延時繞過，2010 年的VW Golf 轉向ECU 在K線上實現的UDS，使用低權限的使用者登入後認證失敗計算器就是清零。在爆破高權限時，在中間穿插一些低權限使用者登入就能持續爆破。

• 持續發送錯誤的訊息，將觸發10s延時認證，影響正常的刷寫。
• 31 服務擦除內存，使ECU 變磚。
• 刷寫前提條件不健全，如車輛在運作中執行刷寫流程，影響行車安全；正常行駛中，停止通訊訊息發送，出現異常。

• 由於CAN廣播傳輸的特性，任何節點都能接收到發送的訊息。下載韌體時，如果韌體沒有加密傳輸(在請求下載中指定為不加密) ，持續監聽總線，執行ECU升級時，能夠監聽獲取到韌體。

• 34、36 缺乏身份認證，在未經身份認證的情況下刷寫。
• 安全認證被突破，刷入非法韌體。

• 經過認證後，透過篡改韌體或發送偽造訊息啟用需要額外付費的功能。

• 使用非對稱演算法: 使用29服務取代27服務，29服務支援非對稱演算法，安全性能夠得到很大的提升。即使演算法洩露，也不會造成影響。
• 安全常數採用安全儲存：自行實現的對稱加密演算法安全常數通常硬編碼在so庫中，容易被逆向出。安全常量應採用安全存放。
• 演算法邏輯安全： ECU復位後，產生的種子每次都一樣，應避免採用類似缺陷的演算法；敏感功能都受到安全存取保護。
• 安全配置：Key 的有效長度能夠有效防禦暴力破解等；刷寫前置條件健全，在特定條件下方能執行刷寫流程。
• 安全啟動：應用程式安全啟動，當安全存取被突破後，拒絕啟動刷入經過篡改的韌體。
• 安全傳輸：韌體採用加密傳輸，請求下載資料傳輸標識指明為加密傳輸，並對應使用加密韌體。
• 監測：偵測潛在的攻擊，及時阻斷。
• 還原：偵測到被竄改，透過備份、雲端等資訊恢復。

• ISO14229 Unified diagnostic services (UDS) — Part 1
• XXXX ECU刷新規範
• 車連網安全事件時間軸
• 汽車安全
• Bootloder開發方案(基於UDS)
• 基於UDS的ECU軟體刷寫流程
• UDS診斷服務基礎篇之27
• CANoe中使用CAPL刷寫流程詳解(Trace圖解)
• 【VCU】詳解S19檔（S-record）
• SREC (file format) - Wikipedia
• Intel HEX file format
• Intel HEX - Wikipedia
• us-18-Milburn-There-Will-Be-Glitches-Extracting-And-Analyzing-Automotive-Firmware-Efficiently

• 23 person(s) visited this page until now.
• Back UDS Topics