The Vehicle May Be Sick: Denial of Diagnostic Services by Exploiting the CAN Transport Protocol Seungjin Baek1 , Seonghoon Jeong2 , and Huy Kang Kim1 School of Cybersecurity, Korea University, Seoul, Republic of Korea [email protected], [email protected] 2 Division of Artificial Intelligence Engineering, Sookmyung Women’s University, Seoul, Republic of Korea [email protected]
arXiv:2604.23617v1 [cs.CR] 26 Apr 2026
1
Abstract. Vehicle diagnostics has become essential for detecting in-vehicle errors and ensuring safety. While the Unified Diagnostic Services (UDS) protocol is widely adopted for diagnostic operations, it relies on the ISO 15765-2 standard as the transport protocol over the Controller Area Network (CAN), which was designed without inherent security considerations. In this paper, we identify eight novel attack scenarios that exploit specific transport layer mechanisms in the ISO 15765-2 standard, including Flow Control manipulation, Sequence Number violations, and error handling abuses. We evaluate these attacks on a real passenger vehicle using two distinct diagnostic tools to demonstrate their practical impact. Our results confirm that three of these attack scenarios successfully induce denial of diagnostic services, leading to abnormal diagnostic results such as concealed faults and manipulated sensor readings. These findings highlight critical vulnerabilities that can deceive technicians and drivers, potentially exposing vehicles to significant safety risks. Keywords: Attack Scenario · CAN Transport Protocol · Cybersecurity · ISO 15765-2 · UDS · Vehicle Diagnostics · Vehicle Security
1
Introduction
As modern vehicles integrate an increasing number of technologies and functions, in-vehicle complexity continues to grow, which can lead to potential errors and defects [1, 14]. Vehicle diagnostics has therefore become essential as a technology for detecting errors and defects within internal vehicle systems and for enabling smooth maintenance, management, and testing throughout the vehicle life cycle. Diagnostic services provide direct access to Electronic Control Units (ECUs) through standardized protocols such as Unified Diagnostic Services (UDS) [9], allowing technicians to read fault codes, monitor sensor data, and reprogram vehicle systems. However, because diagnostic interfaces provide direct access to internal vehicle systems, they present an attractive attack surface for adversaries [3, 19]. If vehicle diagnostic functions are exploited or compromised, the consequences can severely impact vehicle safety and reliability. Prior research has confirmed vulnerabilities in vehicle diagnostic services that can threaten occupant safety during driving, with exploitation methods focusing primarily on the application layer [2, 6, 16].
For instance, attackers who gain access to the Controller Area Network (CAN) bus through compromised infotainment systems [20], ECU vulnerabilities [4,7], or wireless interface flaws [3] can inject malicious messages that disrupt diagnostic operations, potentially masking critical fault conditions or preventing necessary maintenance. While existing research has primarily focused on application-layer attacks against diagnostic protocols [24], the transport layer remains largely unexplored from a security perspective. The ISO 157652 standard [11], commonly known as CAN Transport Protocol (CAN-TP) or ISO-TP, defines the transport protocol for diagnostic communication over CAN, yet it was designed without considering security implications. This presents a significant research gap, as the transport layer handles message segmentation, flow control, and reassembly—mechanisms that, if exploited, can fundamentally disrupt diagnostic communication regardless of application-layer protections. Furthermore, the widespread adoption of the ISO 15765-2 standard as the mandatory transport protocol for emissionsrelated On-Board Diagnostics (OBD) [8, 18] and OB-
2
Baek et al.
DonUDS [17] means that vulnerabilities at this layer could affect vehicles across multiple manufacturers. This paper addresses this research gap by focusing on the transport layer and deriving eight novel attacks that exploit frame characteristics, transmission mechanisms, and error handling in the ISO 15765-2 standard. We analyze the impact of these attacks on actual vehicle diagnostic processes, demonstrating that specific exploitations can induce denial of diagnostic services that prevents proper vehicle diagnosis. Through comprehensive experiments targeting a 2021 Hyundai Elantra CN7 passenger vehicle with two distinct diagnostic tools, we demonstrate that three of these eight attack scenarios successfully impact the real-world diagnostic process. The contributions of this paper can be summarized as follows: – This research is the first to derive eight novel attacks based on the ISO 15765-2 standard and demonstrate their impact on diagnostic communication in a real passenger vehicle. – We identify fundamental design flaws in the CAN transport protocol resulting from a lack of security considerations, and present countermeasures for each attack. – We provide motivation for vehicle Original Equipment Manufacturers (OEMs) to verify whether their vehicles are vulnerable to the proposed attacks and whether adequate mitigations exist, given the widespread adoption of the ISO 157652 standard.
Diagnostic tool
ECU
Diagnostic servic
es request
Data Length XX XX XX XX XX XX
SF, Data: 02 XX
Diagnostic servic
es request
Data Length XX XX XX 1A XX XX XX 10 ta: Da FF, Flow Status FC, Data: 30 03 05 XX XX XX XX XX er Sequence Numb XX XX XX XX XX XX CF, Data: 21 XX Block Size
CF, Data: 22 XX CF, Data: 23 XX
Diagnostic tool
XX XX XX XX
XX XX
XX XX XX XX
XX XX
ECU
ECU
STmin
ECU
Well-crafted diagnostic message
Adversary Physical hacking via OBD-II port
CAN bus Infotainment system
Remote hacking via a vulnerable device
Fig. 1: Benign transmission sequence and the adversary model
is designed to overcome the data size limitations inherent in CAN messages, coordinate sender-receiver interactions through flow control mechanisms, and minimize data loss during transmission. Fig. 2 illustrates the data field formats of CAN messages exchanged beThe remainder of this paper is organized as follows: tween sender and receiver during diagnostic communiSection 2 provides background on the ISO 15765-2 cation. standard and related works. Section 3 describes the Single Frame (SF). This frame is used when the diadversary model and prerequisites. Section 4 presents agnostic data fits within a single CAN message, elimthe eight attack scenarios derived from the ISO 15765- inating the need for fragmentation and flow control. 2 standard. Section 5 describes the experimental setup The first byte contains a 4-bit Data Length (DL) field and results. Finally, Section 6 discusses the implica- indicating the length of the diagnostic data payload. tions of our findings and future work. The receiver ignores frames where SF_DL is 0. First Frame (FF). This frame signals the start of a multi-frame transmission when diagnostic data exceeds 2 Background the capacity of a single CAN message, and includes a 12-bit DL field. When the diagnostic data size exceeds 2.1 ISO 15765-2: Diagnostic Communication the maximum FF_DL value of 4,095, an escape seover CAN quence extends the data length specification to 4 bytes, The ISO 15765-2 standard defines the transport pro- supporting transmissions of up to approximately 4 GB. tocol and network layer for diagnostic communication The receiver ignores frames where FF_DL is 7 or less, over in-vehicle CAN. This transport protocol enables or where FF_DL does not match the actual diagnostic the transmission of large diagnostic data by segmenting data size. it into multiple fragments and reconstructing the orig- Consecutive Frame (CF). This frame carries the reinal data through sequential reassembly. The protocol maining diagnostic data in sequence according to flow
The Vehicle May Be Sick
3
CAN Data Field (Maximum 8 Bytes) Byte[0] SF FF DL ≤ 4095
FF DL > 4095
CF
FC
Byte[1]
Byte[2]
Byte[3]
Byte[4]
Byte[5]
0
DL
Diagnostic data or padding
4 bits
4 bits
7 bytes
Byte[6]
Byte[7]
1
FF_DL
Diagnostic data or padding
4 bits
12 bits
6 bytes
1
not used
Extended FF_DL
Diagnostic data or padding
4 bits
12 bits
4 bytes
2 bytes
2
SN
Diagnostic data or padding
4 bits
4 bits
7 bytes
3
FS
BS
STmin
Padding
4 bits
4 bits
1 byte
1 byte
5 bytes
Fig. 2: Data field structures for SF, FF, CF, and FC frames control parameters and includes a 4-bit Sequence Number (SN). The CF_SN increments by 1 for each consecutively transmitted CF and wraps around to 0 upon reaching the maximum value. Each CF must maximize its diagnostic data payload; only the final CF in a transmission may contain padding. Flow Control (FC). Upon receiving an FF, the receiver uses this frame to regulate the flow of subsequent CFs based on its reception capability. This frame contains a 4-bit Flow Status (FS), a 1-byte Block Size (BS), and a 1-byte Separation Time minimum (STmin). The FS field defines four possible values: FS_ContinueToSend (CTS) to proceed with transmission, FS_Wait to pause reception for a system-defined duration, FS_Overflow to indicate that the received FF_DL exceeds the buffer capacity, and FS_Reserved for undefined values. Notably, FS_Wait may be transmitted consecutively up to Wait Frame Transmission max (WFTmax) times; FS_Overflow is valid only in the first FC following an FF; and FS_Reserved terminates message transmission as it represents an invalid state. FC_BS specifies the number of CFs that can be received before requiring another FC; a value of 0 indicates that all remaining frames should be transmitted without additional flow control. FC_STmin defines the minimum time interval between consecutive CFs, supporting intervals up to 127 ms. When FS is set to Wait or Overflow, the FC_BS and FC_STmin fields are ignored. All frames must use system-configured padding; minimizing padding can reduce bus load. Fig. 1 illustrates the frame transmission process during diagnostic communication. The receiver ignores any frames transmit-
ted before receiving an initial SF or FF. When fullduplex communication is supported, endpoints can simultaneously transmit and receive with different peers. If an SF or FF is received during an ongoing reception, the current session is terminated and a new reception session begins. A timeout occurs if the receiver does not receive the expected frame at the correct time or in the proper sequence. 2.2
Related Works
Kurachi et al. [13] demonstrated a Man-in-the-Middle attack vulnerability where, following successful authentication between an ECU and a diagnostic tool, an attacker intercepts the communication, blocks messages from the diagnostic tool, and directly transmits malicious service requests that the ECU accepts as valid commands. Nie et al. [15] discovered seed-and-key vulnerabilities in the UDS Security Access authentication mechanism that enabled unauthorized ECU access. Similarly, Kiley [12] identified Security Access vulnerabilities in in-vehicle modules and demonstrated that exploiting these flaws could enable unauthorized battery management system firmware uploads. More recent research has revealed that diagnostic services lacking authentication requirements can also be exploited. Chatterjee et al. [2] investigated the security impact on medium and heavy-duty vehicles through exploitation of UDS diagnostic services and ISO-TP. Their work demonstrated that attackers can interrupt periodic ECU message transmissions and induce denial of both diagnostic sessions and diagnostic communication. Han et al. [6] further demonstrated that permit-
4
Baek et al.
ted diagnostic services in certain vehicles can trigger sudden vehicle movements or stops during driving, directly threatening occupant safety. Ren et al. [16] similarly revealed that UDS diagnostic service injection and session attacks can reboot ECUs or cause denial of steering and throttle control while driving. Regarding defensive measures, Yekta et al. [23] proposed a methodology for detecting sophisticated UDS attacks within a Vehicle Security Operations Center. Their approach, combining logging, contextual log data, and detection mechanisms, achieved higher attack detection coverage for known UDS attacks compared to existing AUTOSAR security events. Weiss et al. [21] proposed a methodology for automatically detecting endpoints in in-vehicle CAN communication using ISO-TP. By addressing limitations of existing application-layer-based endpoint detection, they demonstrated improved detection reliability in real vehicles, reducing potential attack surfaces and highlighting implications for future penetration testing and security analysis. Researchers have also investigated methods to provide confidentiality, integrity, and authentication for CAN message transmission. Yushev et al. [25] designed, implemented, and evaluated a secure communication channel for applying transport layer security to the CAN bus. They demonstrated feasibility for low time-sensitivity applications through optimization leveraging the ISO-TP segmentation and reassembly mechanism. The research surveyed above primarily focuses on application-layer vulnerabilities and their exploitation, with countermeasure research following similar trends. This application-layer focus presents a limitation: the attacks proposed in this paper operate at the transport layer and therefore remain unaffected by such countermeasures. Accordingly, this paper proposes eight novel attacks exploiting the frame characteristics, transmission mechanisms, and error handling defined in the ISO 15765-2 standard, thereby addressing this research gap and demonstrating their impact on the vehicle diagnostic process.
3
Adversary Model
Prerequisites. We assume the attacker has direct access to the target CAN bus, enabling both passive monitoring of transmitted CAN messages and active injection of arbitrary CAN messages. Such access can be achieved through the methods discussed in Section 1, including compromised infotainment systems, ECU vulnerabilities, and wireless interface exploits.
Additionally, attackers can leverage vulnerable OBD dongles [5, 22] to gain the required CAN bus access. Knowledge. The attacker must identify the CAN identifier range used for diagnostic communication within the target vehicle. For emissions-related diagnostic services, the ISO 15765-4 standard [10] legally mandates a specific addressing scheme. This standard requires diagnostic tools to use 0x7DF for functional addressing (broadcast requests to multiple ECUs), 0x7E0–0x7E7 for physical addressing (requests to specific ECUs), and 0x7E8–0x7EF for ECU responses. For UDS-based enhanced diagnostic services, 0x7DF is commonly used for broadcast requests, while other addressing follows OEM-specific definitions, requiring CAN bus monitoring for identification. Through such monitoring, the attacker can observe that the arbitration ID range 0x700–0x7FF is typically used for diagnostic communication. This design choice assigns diagnostic identifiers a lower arbitration priority than driving-related identifiers, preventing interference with safety-critical vehicle functions. Goal. The attacker’s objective is to induce denial of diagnostic services by exploiting vulnerabilities in the ISO 15765-2 transport protocol implementation. Successful attacks prevent diagnostic sessions from completing normally or cause them to produce abnormal results, effectively disrupting vehicle maintenance and fault detection capabilities.
4
Attack Scenarios
This section details eight novel attack scenarios A1 – A8 from an attacker’s perspective, illustrated in Fig. 3. Each scenario is structured to first explain the relevant protocol mechanism, followed by the attacker’s method of exploitation, and finally the resulting disruption to the diagnostic process. A1 Preceding FlowControl Attack: In diagnostic communication, the FC frame regulates the reception of CFs transmitted by the ECU. By exploiting frame characteristics and transmission mechanisms, the attacker monitors CF reception and preemptively transmits a manipulated FC frame at the expected timing of the legitimate FC response, as shown in Fig. 3a. Since the protocol may accept parameters from a subsequent FC that differ from those of the preceding one, the attacker can set the Block Size (FC_BS) to a minimum value, causing the omission of subsequent CFs.
The Vehicle May Be Sick
5
Table 1: Systematic classification of proposed ISO 15765-2 transport layer attacks categorized by frame types, exploited protocol mechanisms, and relevant standard clauses. Attacks A1 A2 A3 A4 A5 A6 A7 A8
Preceding FlowControl Attack FlowStatus Wait Attack FlowStatus Overflow Attack DataLength Attack SequenceNumber Attack Session Override Attack Reserved Value Attack Timeout Attack
Frame Characteristics
Transmission
Error
ISO 15765-2
SF
FC
Mechanism
Handling
Clause
✓ ✓ ✓
✓
FF
CF
✓ ✓
✓
✓ ✓
✓ ✓
✓
✓ ✓ ✓
✓ ✓
§9.6.5.6 §9.6.5.1, §9.8.4 §9.6.5.1 §9.6.3.2 §9.6.4.4 §9.8.3 §9.6.5.2 §9.8.2
A2 FlowStatus Wait Attack: The Flow Status 0x0 to 0xF. Any violation of this rule causes the (FC_FS) parameter manages CF reception. The receiver to abort reception. As shown in Fig. 3e, system limits the maximum number of consecuthe attacker monitors CF reception and injects a tive FC frames with FS_Wait status using the CF with an arbitrary SN, deliberately violating the WFTmax parameter. If transmission resumes with sequence rule and forcing the receiver to terminate an FS_CTS frame after the maximum FS_Wait the session. count is reached but reception performance re- A6 Session Override Attack: The protocol dictates that if an SF or FF is received from the quirements are not met, the system treats this as same CAN identifier during an active reception, an error and aborts reception. As shown in Fig. 3b, the current reception is terminated and a new one the attacker exploits this by transmitting the maxis initiated. The attacker exploits this mechanism imum allowable number of FS_Wait frames at (Fig. 3f) by transmitting an arbitrary SF or FF the expected timing of the normal FC response. via physical addressing to a specific ECU, thereby Immediately following this, the attacker sends an overriding and terminating the legitimate reception FS_CTS frame, causing the system to terminate process. message reception due to exceeding performance A7 Reserved Value Attack: Values in the range limits. 0x3–0xF for the FC_FS field are reserved. The A3 FlowStatus Overflow Attack: An FC frame transmitter treats any FC frame containing a rewith FS_Overflow status is valid only when reserved value as an error and aborts transmission. sponding to the first received FF and causes imAs shown in Fig. 3g, the attacker monitors CF remediate termination of message transmission. As ception and transmits an FC frame with a reserved shown in Fig. 3c, the attacker exploits this mechaFC_FS value at the expected timing of a normal nism by injecting an FS_Overflow FC frame immeFC response, causing immediate termination of the diately after detecting the first FF, thereby forcing message transmission. the termination of the ongoing message transmisA8 Timeout Attack: Timeouts are implemented sion. during CF and FC reception to ensure system reA4 DataLength Attack: The FF_DL field indiliability in cases of frame loss, bus congestion, or cates the size of the diagnostic data payload. The delays. While the system allows a tolerance marreceiver considers it an error if FF_DL exceeds gin (up to 50% relative to the lower limit), a timeits available buffer size. Exploiting this error hanout event is treated as an error that terminates dling mechanism (Fig. 3d), the attacker transtransmission. The attacker exploits this (Fig. 3h) mits an FF with FF_DL set to the maximum by flooding the bus with high-priority CAN mes12-bit value (4,095) or the maximum 32-bit value sages, intentionally causing delays that trigger a (4,294,967,295) using the escape sequence, causing timeout and abort the diagnostic session. the receiver to abort message reception. A5 SequenceNumber Attack: The CF_SN must Through an exhaustive analysis of logical flaws and increment sequentially by one within the range of edge cases in the ISO 15765-2 standard, we identified
6
Baek et al. Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
First Frame(FF), Data: 10 57 XX XX XX XX XX XX
First Frame(FF), Data: 10 57 XX XX XX XX XX XX
First Frame(FF), Data: 10 57 XX XX XX XX XX XX Attacker Flow Control(FC), Data: 32 00 00 00 00 00 00 00
Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 27 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 27 XX XX XX XX XX XX XX
Attacker Flow Control(FC), Data: 30 01 05 00 00 00 00 00
Attacker Flow Control(FC), Data: 31 00 00 00 00 00 00 00
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 28 XX XX XX XX XX XX XX
Attacker Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Consecutive Frame(CF), Data: 29 XX XX XX XX XX XX XX
Error Occurred Diagnostic tool
ECU
(a) A1 Preceding FlowControl Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
Diagnostic tool
ECU
(b) A2 FlowStatus Wait
Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
Attacker First Frame(FF), Data: 1F FF XX XX XX XX XX XX
Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 25 XX XX XX XX XX XX XX Consecutive Frame(CF), Data: 26 XX XX XX XX XX XX XX
OR Attacker First Frame(FF), Data: 10 00 FF FF FF FF XX XX
Consecutive Frame(CF), Data: 25 XX XX XX XX XX XX XX Attacker
Error Occurred
ECU
(d) A4 DataLength
Diagnostic tool
ECU
(e) A5 SequenceNumber
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Attacker Single Frame(FF), Data: 02 XX XX 00 00 00 00 00 OR Attacker First Frame(FF), Data: 10 XX XX XX XX XX XX XX
Error Occurred
Error Occurred
Diagnostic tool
First Frame(FF), Data: 10 57 XX XX XX XX XX XX
First Frame(FF), Data: 10 57 XX XX XX XX XX XX Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
ECU
(c) A3 FlowStatus Overflow
Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
First Frame(FF), Data: 10 57 XX XX XX XX XX XX
Diagnostic tool
Diagnostic tool
ECU
(f) A6 Session Override
Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
Diagnostic request Single Frame(SF), Data: 02 XX XX 00 00 00 00 00
First Frame(FF), Data: 10 57 XX XX XX XX XX XX
First Frame(FF), Data: 10 57 XX XX XX XX XX XX
Flow Control(FC), Data: 30 08 05 00 00 00 00 00
Flow Control(FC), Data: 30 08 05 00 00 00 00 00 Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 21 XX XX XX XX XX XX XX
Consecutive Frame(CF), Data: 27 XX XX XX XX XX XX XX
Attacker High Priority CAN Message Injection
Attacker Flow Control(FC), Data: 35 XX XX 00 00 00 00 00
Error Occurred
Consecutive Frame(CF), Data: 27 XX XX XX XX XX XX XX
Error Occurred
Diagnostic tool
ECU
(g) A7 Reserved Value
Diagnostic tool
ECU
(h) A8 Timeout
Fig. 3: Detailed flow of ISO 15765-2 standard based attack scenarios
The Vehicle May Be Sick
7
Kvaser 1
G-Scan 3
Laptop 1
OBD-II Port G-Scan 3
Kvaser 2 Power Supply
Kvaser 1
Laptop 2
(a) Using the Hyundai Motor Group OEM-level G-Scan3 diagnostic tool
CAN Bus
Laptop 1
(b) Configuration for practicing diagnostics and attacks in a 2021 Hyundai Elantra CN7 passenger vehicle
Fig. 4: The setup also configures an OBDSCAN4.0 diagnostic tool based on ELM327 instead of G-Scan3. Laptop 1 performs the role of an attacker using Kvaser 1, and Laptop 2 monitors the CAN bus using Kvaser 2. these non-heuristic attacks based on frame characteris- for Hyundai/Kia vehicles. Although this experimental tics, transmission mechanisms, and error handling. Ta- setup employs two diagnostic tools with distinct charble 1 summarizes these findings. acteristics within a single vehicle, it can be configured with various OEM vehicles and diagnostic tools.
5
Experimental Evaluation
5.1
Diagnostic Tools
The experimental setup follows the configuration in Fig. 4 to demonstrate the impact of attacks through the use of two diagnostic tools with distinct characteristics. OBDSCAN4.0 is an affordable and easily accessible OBD-II aftermarket diagnostic tool that requests diagnostic services and displays results through compatible free diagnostic applications such as Car Scanner and Torque. Specifically, it provides services to retrieve in-vehicle Diagnostic Trouble Codes (DTCs) and ECU information, monitor onboard sensors, and record data. However, the tool does not support Secure Gateway (SGW) security authentication, restricting it to limited services. Furthermore, reliability issues may arise because the tool relies on an external CAN database to interpret results, rather than querying the vehicle directly. The G-Scan3 (Fig. 4a), developed by GIT (an affiliate of Hyundai Motor Group), supports OEM-level diagnostics for Hyundai/Kia vehicles. This tool performs SGW security authentication, enabling access to restricted diagnostic services such as variant coding, actuation tests, emission tests, and sensor calibration. This ensures highly reliable diagnostic results
5.2
Attack Validation
We execute each attack in the real vehicle diagnostic environment shown in Fig. 4b and analyze the resulting responses at the diagnostic communication level. Notably, significant results were observed for only a subset of attacks. Fig. 5a shows the normal diagnostic communication process during the execution of the ‘ECU Identifiers’ vehicle diagnostic function. In Fig. 5g and Fig. 5h, the attacker sends an FF and an SF using physical addressing to induce the termination of the active reception session. Because the attack does not generate an error, the CFs appeared to be transmitted normally afterward; however, abnormal diagnostic results were observed. This indicates that the active reception session was interrupted by the initiation of a new reception session, overwriting the previous diagnostic data. In Fig. 5e, the attacker sends an FF with the FF_DL set to the maximum value, thereby exceeding the receiver’s buffer size and inducing message reception termination. Although message reception did not cease immediately, abnormal diagnostic results were observed. This indicates that the induced error corrupted the results, or
8
Baek et al. DR SF FF FC CF
Preceding
0.00
0.02
0.04
0.06
Time (s)
0.08
0.10
0.12
(a) Normal
(b) A1 Preceding FlowControl
FS_Wait FS_CTS No Effect
FS_Overflow
(c) A2 FlowStatus Wait
No Effect
(d) A3 FlowStatus Overflow Time Gap
Error Occurs or Reception Ends Invalid SN
(e) A4 DataLength
Retransmission Routine
(f) A5 SequenceNumber Terminates Reception
Terminates Reception
(g) A6 Session Override (SF) Reserved
No Effect
(h) A6 Session Override (FF) No Effect
No Effect
High Priority
(i) A7 Reserved Value
(j) A8 Timeout
Fig. 5: CAN message traces for normal communication and each attack scenario. Green and red markers indicate normal and attack frames, respectively. that a session-override behavior analogous to A6 was triggered. In Fig. 5f, the attacker induces message reception termination by transmitting CFs that violate SN continuity. Following the attack, CF transmission ceased immediately, and after a period of unresponsive delay, a diagnostic request retransmission routine occurred a fixed number of times to resume the diagnostic service. This indicates that the in-vehicle transport protocol implementation recognized the error and halted message reception, successfully inducing abnormal diagnostic results. Other attacks demonstrated no influence on the diagnostic results, although they were executed as intended. For Figs. 5b to 5d, we can infer that the in-vehicle transport protocol implementation is designed to ignore or reject additionally transmitted FC frames. Furthermore, for Figs. 5i and 5j, we sus-
pect that the implementation similarly ignores frames where the FC_FS is set to a reserved value, or that the configured timeout margin is sufficiently wide. 5.3
Attack Impact
Focusing on the A4 – A6 attacks, which successfully induced abnormal diagnostic results, we explain their impact and potential risks to vehicle diagnostic functions using two distinct diagnostic tools. ECU Identifiers. The ECU identification function of the Car Scanner diagnostic application retrieves software versions, Vehicle Identification Numbers (VINs), and manufacturing and supply information for invehicle ECUs that are difficult to access directly. Attacks A4 , A5 , and A6 cause diagnostic result omission by terminating the active reception session
The Vehicle May Be Sick
or interrupting message flow. In particular, these attacks increase the diagnostic time by up to six times the normal duration. Furthermore, A6 induces ‘diagnostic data spraying’ where a new reception session overwrites parts of the valid diagnostic results with initialization values. These results render the identification of in-vehicle information and status through diagnostics impossible. DTC Inquiry. In-vehicle ECUs detect system errors and record them as DTCs to enable subsequent diagnosis. Attacks A4 , A5 , and A6 interfere with this detection process and manipulate the count of queried DTCs. Specifically, the G-Scan3 failed to receive DTC inquiry data normally; it displayed ‘0’, a presumed default value, without indicating an error. These results expose the vehicle to potential risks by concealing internal errors during the reporting process. Functional Test. Evaporative emission leak tests inspect the evaporative emission system for gas leaks to maintain vehicle performance and safety. Although the G-Scan3 normally reports no leaks while the vehicle remains stationary, attacks A4 , A5 , and A6 manipulate these test results. Specifically, the tool failed to receive valid leak test data and displayed “gas leak detected”—likely a default state—without triggering an error code. These results deceive in-vehicle systems, which can impact emissions-related inspections and lead to regulatory violations. Variant Coding. Variant coding functions allow for modifying specific ECU options or setting specification information. This capability adapts common hardware properties to specific vehicle configurations, activating necessary functions. Attacks A4 , A5 , and A6 interfered with the transmission of coding request data and disrupted the normal operation of G-Scan3’s coding functions. These results can hinder the replacement of faulty vehicle components or restrict the activation of specific functions.
9
Table 2: Brief mitigation strategies for attack scenarios based on the ISO 15765-2 standard. Attack
Mitigation Strategy
A1
Stateful tracking to prevent inconsistencies between FF_DL and FC parameters
A2
Validation of FC frame counting and state synchronization between sender and receiver
A3
Validation of FC frame counting and state synchronization between sender and receiver
A4
Service-based allow-listing for escape sequences in high-volume diagnostics
A5
Immediate discard of discontinuous CF_SN frames, with logging and IDS hooking against sophisticated attacks
A6
FIFO queue-based sequential management for reception sessions
A7
Immediate discard of frames with undefined FC_FS values
A8
Dynamic timeout management based on CAN bus load
ecution. To address this, future standards must incorporate security-oriented enhancements, and vehicle OEMs need to consider appropriate mitigation measures when implementing in-vehicle transport protocols based on the ISO 15765-2 standard. However, existing countermeasure frameworks such as AUTOSAR SecOC and ISO/SAE 21434 do not fully cover the attack surface addressed in this work. SecOC authenticates PDU payloads at the application layer and therefore cannot detect adversarial manipulation of transportlayer control fields (e.g., FF_DL, CF_SN, FC_FS) or session-override attempts that abort reception below the PDU boundary. ISO/SAE 21434 prescribes a riskmanagement process but does not mandate transport6 Discussion and Future Work layer controls. Consequently, attacks A4 – A6 remain The eight novel attacks derived in this paper are effective even in vehicles that deploy SecOC. To address based on the ISO 15765-2 standard, and vehicles this gap in current automotive security standards, Taadopting the Controller Area Network Flexible Data- ble 2 briefly proposes mitigation strategies for each deRate (CAN-FD) protocol may also be affected. As we rived attack. Furthermore, beyond the transmission of demonstrated in our evaluations, these attacks can de- in-vehicle diagnostic data, it is necessary to validate the grade vehicle safety and reliability, exposing the sys- derived attacks and evaluate their extended impact in tem to potential risks and leading to non-compliance broader contexts, such as general vehicle control. with emission regulations. Furthermore, they can impact the data transmission processes for ECU flash- Acknowledgments. This work was supported by the ing and firmware updates, disrupting their normal ex- National Research Foundation of Korea (NRF) grant
10
Baek et al.
funded by the Korea government (MSIT) (No. RS-202400359621).
References 1. Charette, R.N.: How software is eating the car. IEEE Spectrum (2021), https://spectrum.ieee.org/ software-eating-car 2. Chatterjee, R., Green, C., Daily, J.: Exploiting diagnostic protocol vulnerabilities on embedded networks in commercial vehicles. In: Proceedings of the Symposium on Vehicle Security and Privacy (VehicleSec). pp. 1–12 (2024) 3. Checkoway, S., McCoy, D., Kantor, B., Anderson, D., Shacham, H., Savage, S., Koscher, K., Czeskis, A., Roesner, F., Kohno, T.: Comprehensive experimental analyses of automotive attack surfaces. In: Proceedings of the 20th USENIX Security Symposium. pp. 1–16 (2011) 4. Dürrwang, J., Braun, J., Rumez, M., Kriesten, R.: Security evaluation of an airbag-ecu by reusing threat modeling artefacts. In: Proceedings of the International Conference on Computational Science and Computational Intelligence (CSCI). pp. 11–18 (2017) 5. Gesteira-Miñarro, R., Gutiérrez, I., Palacios, R., López, G.: pwnobd: Offensive cybersecurity toolkit for vulnerability analysis and penetration testing of obd-ii devices. IEEE Access. pp. 126925–126934 (2025) 6. Han, S., Oh, S., Song, J.: Udsoncan attacks: Discovering safety-critical risks by fuzzing. In: Proceedings of the DEFCON 32 Car Hacking Village (2024), https://www.carhackingvillage.com/defcon-32talks#button-block-yui_3_17_2_1_1721393317940_ 63666-2 7. Van den Herrewegen, J., Garcia, F.D.: Beneath the bonnet: A breakdown of diagnostic security. In: Proceedings of the 23rd European Symposium on Research in Computer Security (ESORICS). pp. 305–324 (2018) 8. International Organization for Standardization: Road vehicles – implementation of world-wide harmonized on-board diagnostics (wwh-obd) communication requirements part 3: Common message dictionary. Standard ISO 27145-3, International Organization for Standardization (2012), https://www.iso.org/standard/ 46277.html 9. International Organization for Standardization: Road vehicles – unified diagnostic services (uds) part 1: Application layer. Standard ISO 14229-1, International Organization for Standardization (2020), https: //www.iso.org/standard/72439.html 10. International Organization for Standardization: Road vehicles – diagnostic communication over controller area network (docan) part 4: Requirements for emissions-related systems. Standard ISO 15765-4, International Organization for Standardization (2021), https://www.iso.org/standard/78384.html
11. International Organization for Standardization: Road vehicles – diagnostic communication over controller area network (docan) part 2: Transport protocol and network layer services. Standard ISO 15765-2, International Organization for Standardization (2024), https: //www.iso.org/standard/84211.html 12. Kiley, P.: The uds security model of the tesla can bus and battery management system. In: Proceedings of the RSA Conference (2021), https: //www.rsaconference.com/Library/presentation/ USA/2021/the-uds-security-model-of-the-teslacan-bus-and-battery-management-system 13. Kurachi, R., Takada, H., Takei, K., Iinuma, T., Satoh, Y., Nakano, M., Matsushima, H., Anzai, J., Nakano, T.: Evaluation of security access service in automotive diagnostic communication. In: Proceedings of the IEEE 89th Vehicular Technology Conference (VTC2019Spring). pp. 1–7 (2019) 14. McKinsey & Company: The case for an endto-end automotive-software platform. https: //www.mckinsey.com/industries/automotiveand-assembly/our-insights/the-case-for-anend-to-end-automotive-software-platform (2022) 15. Nie, S., Liu, L., Du, Y.: Free-fall: Hacking tesla from wireless to can bus. In: Proceedings of the Black Hat USA. pp. 1–16 (2017) 16. Ren, S., Guo, Z., Ning, Y., Yu, Q., Yu, L.: In-vehicle network attack based on can and uds: Demonstration and analysis. In: Proceedings of the 5th International Conference on Internet of Things, Automation and Artificial Intelligence (IoTAAI 2023). pp. 23–29 (2023) 17. SAE International: E/e diagnostic test modes: Obdonuds. Standard SAE J1979-2, SAE International (2021), https://doi.org/10.4271/J1979-2_202104 18. SAE International: E/e diagnostic test modes. Standard SAE J1979, SAE International (2025), https: //doi.org/10.4271/J1979_202505 19. Valasek, C., Miller, C.: A survey of remote automotive attack surfaces. In: Proceedings of the Black Hat USA. pp. 1–94 (2014) 20. Valasek, C., Miller, C.: Remote exploitation of an unaltered passenger vehicle. In: Proceedings of the Black Hat USA. pp. 1–91 (2015) 21. Weiss, N., Renner, S., Mottok, J., Matoušek, V.: Transport layer scanning for attack surface detection in vehicular networks. In: Proceedings of the ACM Computer Science in Cars Symposium (CSCS). pp. 1–8 (2020) 22. Wen, H., Chen, Q.A., Lin, Z.: Plug-n-pwned: Comprehensive vulnerability analysis of obd-ii dongles as a new over-the-air attack surface in automotive iot. In: Proceedings of the 29th USENIX Security Symposium. pp. 949–965 (2020) 23. Yekta, A.R., Loza, N., Gramm, J., Schneider, M.P., Katzenbeisser, S.: From ecu to vsoc: Uds security monitoring strategies. In: Proceedings of the 19th Inter-
The Vehicle May Be Sick national Conference on Emerging Security Information, Systems and Technologies (SECURWARE 2025). pp. 1–8 (2025) 24. Yekta, A.R., Loza, N., Schneider, M.P., Gramm, J., Katzenbeisser, S.: Uds attack taxonomy: Systematic classification of vehicle diagnostic threats. In: Proceedings of the 10th IEEE International Workshop on Cyber-Physical Systems Security (CPS-Sec). pp. 1–8 (2025) 25. Yushev, A., Barghash, M., Nguyen, M.P., Walz, A., Sikora, A.: Tls-over-can: An experimental study of internet-grade end-to-end communication security for can networks. IFAC PapersOnLine 51-6 pp. 96–101 (2018)
11