車用診斷鏈論文閱讀分析：很多車輛真正先出事的，不是控制權被搶，而是診斷流程先被做壞

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：The Vehicle May Be Sick: Denial of Diagnostic Services by Exploiting the CAN Transport Protocol
• 作者：Seungjin Baek、Seonghoon Jeong、Huy Kang Kim
• 年份：2026
• 來源：arXiv:2604.23617
• 論文連結：https://arxiv.org/abs/2604.23617
• DOI：10.48550/arXiv.2604.23617
• 主題：Automotive Security、CAN Bus、ISO-TP、Unified Diagnostic Services、Vehicle Diagnostics、Denial of Service

很多人談車用資安，第一反應還是 remote unlock、ECU firmware、車載 infotainment、無線介面入侵，或者更直接的 CAN 訊框注入。這些都重要，但有個很容易被低估的面向：當車子沒有被直接控制、也沒有立刻失控時，攻擊者仍然可以先把「你用來判斷它有沒有生病」的那套診斷流程弄壞。

這篇 The Vehicle May Be Sick 最值得看的地方，不是它又多找到一個 application-layer UDS 漏洞，而是它把刀往更底層插：直接從 ISO 15765-2，也就是 CAN 上承載診斷通訊的 transport protocol 本身下手。

這篇真正想補的洞，不是「某個診斷服務有沒有少做認證」，而是「就算上層診斷邏輯沒寫錯，只要底下那層分段、流控、重組機制能被玩壞，整個診斷結果一樣可能不可信」。

這篇在打哪個痛點？

現代車輛診斷仰賴 UDS（Unified Diagnostic Services）與 OBD/OBDonUDS，讓技師或診斷工具可以：

• 讀 fault codes
• 看感測器資料
• 做模組測試與維護
• 在某些情境下重刷或重新設定 ECU

問題是，這一切表面上看起來像在做高層 service，其實底下都踩在 ISO-TP（ISO 15765-2）這種 transport layer 機制上：訊息切片、First Frame、Consecutive Frame、Flow Control、timeout、sequence number，全都在這層決定。

而作者指出的核心問題很直接：ISO-TP 當年設計時，重點是怎麼在 CAN 上把大封包拆開重送，不是怎麼面對惡意對手。 於是很多「原本為了可靠傳輸而設計的機制」，一旦攻擊者能碰到 CAN bus，就可能反過來變成 denial-of-diagnostic-service 的槓桿。

作者最重要的一刀：別只盯 UDS 服務，transport layer 本身就是攻擊面

過去不少車用診斷攻擊研究，都集中在 application layer：

• 認證流程弱點
• Security Access seed-key 問題
• 特定 diagnostic service 被濫用
• 可直接影響煞車、轉向、重開機等高風險指令

這篇論文換了一個視角：如果攻擊者根本不需要偽造完整診斷服務語意，只要在傳輸過程中動手腳，能不能讓合法的診斷流程自己失真、卡死、或者回出異常結果？

作者答案是可以，而且不只一種。他們系統性整理出 8 種利用 ISO-TP frame characteristics、transmission mechanisms 與 error handling 的攻擊情境，包括：

• Preceding FlowControl Attack
• FlowStatus Wait Attack
• FlowStatus Overflow Attack
• DataLength Attack
• SequenceNumber Attack
• Session Override Attack
• Reserved Value Attack
• Timeout Attack

它們的共同點不是「奪取車輛控制權」，而是讓診斷流程中止、被覆寫、被誤導，或者產出不正常結果。這種路線很像在打醫療檢驗流程：不是直接把病人殺掉，而是先讓醫生拿到錯報告。

為什麼這個 framing 很重要？

因為很多防守方對車用資安的直覺，還停在「只要行車功能沒被直接接管，風險就比較次要」。但診斷這條鏈如果失真，後果不一定比較小：

• 故障可能被隱藏，技師看不到真正 fault
• 感測器讀值可能被操弄，導致誤判維修方向
• 診斷 session 反覆失敗，讓必要維護流程無法完成
• 安全相關問題可能延後發現，最後變成實際行車風險

也就是說，攻擊者不一定要立刻控制方向盤，先讓你失去判斷車況真假的能力，本身就是很危險的攻擊目標。

很多車用資安真正缺的，不只是保護控制功能不被濫用，而是保護「判斷系統是否正常」的那條診斷鏈，不要先被做壞。

這篇最有價值的地方：它不是只談理論，而是上真車驗

如果這篇只是標準條文分析，價值會少很多。它真正加分的地方，在於作者不是停在 spec-level 推演，而是拿 2021 Hyundai Elantra CN7 與兩種不同診斷工具上車驗證。

這點很重要，因為 transport-layer 攻擊常有一個現實問題：標準允許的邊界行為，不代表 OEM 實作一定會真的中招。 有些廠商會在 stack 裡補判斷、有些不會，有些工具會優雅處理 timeout，有些直接 abort。

作者最後的結果不是誇張地說 8 種全打通，而是比較可信地指出：8 種場景裡有 3 種在真實車輛診斷過程中成功造成 denial of diagnostic services，並導致 concealed faults、操弄後的 sensor readings 等異常診斷結果。

這種結果其實比「8/8 全通」更值得信。它表示作者不是把實驗設計成只為了衝 headline，而是真的在區分：

• 哪些是 spec 上的 logical weakness
• 哪些能穿透到 OEM / tool 的現實實作
• 哪些最後會影響技師看到的診斷世界

8 種攻擊裡，最值得記住的是它們都在利用「正常可靠性機制」

這篇一個很漂亮的點，是它提醒我們：很多安全問題不是來自明顯危險功能，而是來自那些原本被當成可靠性與互通性保障的設計。

例如：

• Flow Control 原本是為了讓接收端控制節奏，避免 buffer 撐爆，結果可被偽造來中斷或拖垮傳輸
• Sequence Number 原本是為了確保重組順序正確，結果也可被刻意違反來逼迫 session abort
• Timeout 原本是為了處理遺失與壅塞，結果只要高優先權訊框大量灌入，就能被拿來當拒絕服務開關
• Session Override 原本是為了允許新的接收流程接手，結果反而可被用來踢掉合法診斷流程

這種結構很值得延伸思考。很多協定真正危險的，不是它明文允許一個惡意操作，而是它假設大家都只是想把系統用好，沒把 adversarial manipulation 當成設計前提。

我覺得這篇最有啟發性的，不是車，而是「診斷面」這個安全觀點

這篇表面是 automotive security，但其實它點出一個更廣的安全問題：很多系統最脆弱的，不是 production path，而是 observability path。

當一個系統越來越依賴自動診斷、遠端檢測、維修工具、健康檢查流程時，你真正該問的不只是：

• 系統有沒有被直接控制？
• 功能有沒有被直接破壞？

還要問：

• 我看到的診斷結果還可信嗎？
• 這條檢查鏈本身有沒有被攻擊者先接管？
• 維護者是不是正在根據錯誤世界模型做決策？

這也是我覺得這篇比一般「車載 CAN 攻擊又一篇」更有味道的地方。它不是在談炫技，而是在談安全判斷能力本身也會成為攻擊面。

這篇的邊界也要講清楚

當然，這篇不是說所有車都會被同一招打穿，幾個現實邊界還是要先講：

• 前提仍是攻擊者得先碰到 CAN bus：不論透過 infotainment、ECU 弱點、無線介面或惡意 OBD dongle，這不是零成本前提
• 實作差異很大：ISO-TP 是共通標準，但 OEM 與工具的具體實作、容錯與防護並不一致
• 這篇重點是診斷可用性與完整性，不是直接接管行車控制：它更像 maintenance trust attack，而非 immediate safety takeover
• 真實攻擊鏈仍要結合入侵入口：單靠這篇不能解釋完整攻擊面，但它把「入侵後能做什麼」往更實際的維修與誤診場景拉近了一步

但這些限制不會讓它失色，反而讓它更像一篇值得工程團隊真的拿去做 stack review 的論文。

對車廠與供應鏈最實際的提醒

作者也沒有只停在攻擊展示，而是很明確地把球丟回 OEM 與診斷工具供應鏈：

• 你們有沒有驗證自己的 ISO-TP stack 對這些異常 frame 的處理？
• 有沒有在 diagnostic tool 與 ECU 端做更嚴格的 state validation？
• timeout、FlowControl、session override 這些機制，有沒有被當成 adversarial input 重新檢查？
• 診斷結果異常時，tool 端有沒有機會辨識「這不是普通通訊不穩，而是惡意操控」？

這些問題其實不只屬於車廠，也屬於所有建立在 legacy industrial protocols 上的系統：只要協定當初主要為可靠運作而設計，而不是為 hostile environment 設計，後面多半都得補一輪安全語意。

一句話總結

這篇論文最值得看的地方，不是它又多列了幾種 CAN 攻擊，而是它提醒我們：很多車用系統真正先失守的，不是控制功能本身，而是那條原本用來判斷車輛到底有沒有出事的診斷鏈。