Algorithmic Optimization for Accelerated UDS Fuzzing in Cyber–Physical Automotive Networks: The BB-FAST Approach on LIN-Bus

Abstract

In modern cyber–physical vehicle networks, the security of component-level Electronic Control Units (ECUs) is essential for overall system reliability. While Controller Area Network(CAN) security is well-studied, the Local Interconnect Network (LIN) has received less attention despite its growing role in critical functions and diagnostic services (UDS). The inherent constraints of the LIN protocol, specifically its low bandwidth and master–slave architecture, make traditional fuzz testing impractical due to extremely long execution times. This paper proposes Batch-based Binary-search Fuzzing and Accelerated Security Testing (BB-FAST), an optimized framework for faster vulnerability detection in LIN-based systems. By integrating batch processing and binary search techniques, BB-FAST overcomes communication bottlenecks and enables efficient error localization. Empirical evaluations on a physical automotive ECU demonstrate that BB-FAST achieves a significant reduction in testing time—up to 97.7% compared to traditional sequential methods. Notably, in scenarios involving critical controller failures, BB-FAST outperformed optimized batch-based approaches by 64.2% through its logarithmic error localization logic. By mitigating these physical limitations through algorithmic optimization, this work enables thorough security verification for LIN-based diagnostic interfaces that was previously constrained by protocol latency, thereby enhancing the integrity of cyber–physical automotive networks.

1. Introduction

With the rapid transition of the automotive industry toward software-defined vehicles (SDV) [1], modern vehicles have evolved into complex cyber–physical networks (CPNs) where the physical movement of the vehicle is governed by intricate electronic control units (ECUs). As advanced driver assistance systems (ADAS) and infotainment systems become more sophisticated, the functional significance of these ECUs has increased, making the reliability and security of component-level nodes critical factors in determining the overall safety and resilience of the vehicular ecosystem [2].

In these cyber–physical environments, a single vulnerable ECU can serve as an entry point to compromise the entire network’s functional integrity. While traditional automotive security focused on external interfaces—such as Wi-Fi, cellular, and Bluetooth—modern cybersecurity emphasizes the necessity of securing internal networks, including the Controller Area Network (CAN), Automotive Ethernet, and even low-speed protocols. Accordingly, international standards like ISO/SAE 21434 [3] and UN Regulation No. 155 (UNR 155) [4] now require rigorous security testing to ensure the trust and safety of internal communication architectures.

A key element in evaluating ECU security is the testing of Unified Diagnostic Services (UDS) [5]. Since UDS provides powerful control functions such as memory management and firmware updates, it is a primary target for adversaries seeking to exploit vehicular control systems. To proactively identify vulnerabilities in these diagnostic interfaces, fuzz testing—which injects malformed inputs to verify exception-handling capabilities—is widely utilized. While UDS-based fuzzing via CAN is a well-established requirement [6], research on other critical internal protocols has been comparatively limited.

Concurrently, the Local Interconnect Network (LIN) is an indispensable protocol used in various domains, including side mirror control, intelligent Heating, Ventilation, and Air Conditioning (HVAC) sensors, and Battery Management Systems (BMS) [7]. In next-generation architectures, LIN-based ECUs are increasingly undertaking more complex control functions, leading to a significant rise in the integration of UDS for advanced lifecycle management and maintenance. However, despite this growing importance, UDS-based fuzzing for LIN remains under-explored. Specifically, LIN is constrained by a limited bandwidth of up to 20 kbps and a rigid master–slave architecture. These physical communication constraints lead to severe performance bottlenecks, making conventional testing methodologies designed for CAN environments impractical for LIN-based cyber–physical nodes.

To bridge this gap, this paper proposes BB-FAST, an optimized UDS-based fuzzing framework specifically designed to overcome the inherent constraints of LIN communication. By introducing algorithmic optimizations such as batch processing and binary-search logic, our approach addresses the physical latency of LIN with cyber intelligence. This ensures deterministic efficiency and facilitates exhaustive security verification, enabling thorough vulnerability detection in bandwidth-limited environments that were previously difficult to test rigorously.

The remainder of this paper is organized as follows. Section 2 provides the theoretical background on LIN message structures and fuzzing techniques, followed by a review of related research. Section 3 details the proposed UDS-based fuzzing methodologies, optimized for the LIN environment through preliminary analysis. Section 4 presents a theoretical analysis and complexity modeling for each proposed method. Section 5 evaluates the effectiveness of the proposed approach through experimental validation on a representative LIN-based ECU. Section 6 discusses the significance of the findings and addresses the study’s limitations. Finally, Section 7 concludes the paper with a summary and future directions.

2. Background and Related Works

2.1. Background

2.1.1. Local Interconnect Network (LIN)

The local interconnect network (LIN) is a low-cost communication protocol developed to complement the cost limitations of the CAN, which handles high-speed communication within in-vehicle networks. LIN is primarily utilized in environments that do not require high bandwidth, such as for controlling seats, doors, and side mirrors, as well as for communication between various sensors. Currently, LIN is defined as an international standard through the ISO 17987 series and plays an essential role in vehicle networks [8].

In the case of CAN, it supports communication speeds of up to 1 Mbps and features a multi-master approach where multiple nodes can communicate simultaneously. Furthermore, it demonstrates high reliability due to structures such as Cyclic Redundancy Check (CRC) error detection and differential signaling (CAN High/Low). Conversely, LIN supports a relatively slow communication speed of up to 20 kbps—approximately 1/50th the speed of CAN—and is characterized by a single-master architecture where one master node controls all slave nodes [9]. Additionally, LIN features a simple structure using a single wire, resulting in lower message reliability compared to CAN but offering the advantage of being more cost-effective.

A LIN message frame, as shown in Figure 1, consists of a header frame transmitted by the master node and a response frame transmitted by either the master or a slave node depending on the specific identifier. The header frame comprises a break field, a sync field, and a protected identifier (PID) field, which respectively serve as a frame start notification, synchronization, and message ID value. Notably, PIDs ranging from 0 × 00 to 0 × 3B are used for signal transmission, while 0 × 3C is utilized for requests in diagnostic functions and 0 × 3D for responses. The response frame has a data field of up to 8 bytes and includes a 1-byte Checksum field for data integrity. Since LIN is based on the universal asynchronous receiver-transmitter (UART) communication method, every field constituting a LIN frame includes a start bit and a stop bit. That is, a field with a size of 1 byte (8 bits) consists of a total of 10 bits, including the start and stop bits.

Figure 1. Frame of the Local Interconnect Network (LIN) Message.

Unlike CAN, where all nodes act as master nodes, LIN has a structure with only one master node and multiple slave nodes associated with it. In this architecture, message transmission is conducted via a polling method where the master node transmits a header frame to the bus according to a schedule table to call a specific slave node. In particular, for diagnostic communication such as UDS as illustrated in Figure 2, the master node transmits a request header with a PID of 0 × 3C and the corresponding data to the bus. Subsequently, when the master node transmits a response header with a PID of 0 × 3D along with an empty data frame, the slave node corresponding to the node address (NAD) receives the 0 × 3D message, populates it with the response data, and transmits the response message to the bus. While this method prevents message collisions and ensures stable communication, it acts as a constraint that degrades overall latency and the efficiency of security testing, as the slave node must wait until it receives a polling header from the master node to respond.

Figure 2. Example of LIN Communication on Unified Diagnostic Services (UDS).

2.1.2. Unified Diagnostic Services (UDS)

Unified diagnostic services (UDS) is an automotive diagnostic communication protocol defined by the ISO 14229 standard [10], which supports standardized diagnostic communication at the application layer. This service facilitates standardized communication between in-vehicle ECUs and external diagnostic clients. It plays a critical role in vehicle service and maintenance by performing core functions such as controller configuration, memory dumps, and firmware updates.

The ISO 14229 standard assigns a unique service identifier (SID) to each service for vehicle diagnostics, and its primary functions are categorized as shown in Table 1. UDS operates on a request-response pair mechanism; when a client transmits a request frame containing a specific SID, the ECU returns either a positive response or a negative response frame. In this process, the SID of a positive response is the value of the request SID plus 0 × 40. Conversely, the SID of a negative response is 0 × 7F, which is returned along with a negative response code (NRC) that provides specific information regarding the nature of the response.

Table 1. Examples of Service ID on UDS Standard.

Request SID	Response SID	Service	Details
0 × 10	0 × 50	Diagnostic Session Control	Control which UDS services are available
0 × 11	0 × 51	ECU Reset	Reset the Electronic Control Unit(ECU)
0 × 27	0 × 67	Security Access	Enable use of security-critical services via authentication
0 × 22	0 × 62	Read Data By Identifier	Read data from targeted ECU
0 × 23	0 × 63	Read Memory By Address	Read data from physical memory
0 × 2E	0 × 6E	Write Data By Identifier	Program specific variables determined by data parameters
0 × 3D	0 × 7D	Write Memory By Address	Write information to the ECU’s memory
0 × 31	0 × 71	Routine Control	Initiate/stop routines
0 × 34	0 × 74	Request Download	Start request to add software/data to ECU
0 × 35	0 × 75	Request Upload	Start request to read software/data from ECU
0 × 36	0 × 76	Transfer Data	Perform actual transfer of data
	0 × 7F	Negative Response	Sent with a negative response code when a request cannot be handled

While the UDS protocol provides a consistent application layer interface, its implementation is tailored to the characteristics of the underlying physical and data link layers. Specifically, Part 7 of the ISO 14229 standard specifies the implementation of UDS over the LIN communication environment. To identify individual slave nodes on the LIN bus, a NAD value is utilized; this value is defined within the payload of the designated diagnostic PIDs, 0 × 3C (Request) and 0 × 3D (Response). As illustrated in Figure 3, a LIN diagnostic frame—which has a maximum data field of 8 bytes—consists of a 1-byte NAD, a 1-byte Protocol Control Information (PCI) field defining the frame type and data length, and a 1-byte SID. These are followed by up to 5 bytes of actual service data or parameters.

Figure 3. Example UDS frame on LIN.

2.1.3. Fuzz Testing

Fuzz testing (fuzzing) [11] is a dynamic analysis technique used to identify software defects and security vulnerabilities by continuously injecting random or abnormal data into a target system. Fuzzing is highly effective even in black-box environments where source code is unavailable, as it can trigger exception-handling logic or unexpected system crashes. This allows researchers to detect unknown vulnerabilities and evaluate software stability within undefined or undocumented regions.

Fuzz testing is primarily classified into two categories based on the methodology used to generate test cases [12]:

• Mutation-based Fuzz Testing: This approach generates modified data by applying techniques such as bit-flipping or random value injection to existing normal data packets, which serve as seed samples. It can be implemented without an in-depth understanding of complex protocol structures and is mainly utilized for testing simple network packets.
• Generation-based Fuzz Testing: This method creates new test data from scratch that complies with the rules of the target protocol, such as frame structures and checksums, based on its specification. This approach is particularly effective for testing sophisticated communication protocols and diagnostic services, such as UDS.

Furthermore, fuzzing techniques are categorized into three types based on the extent of information available regarding the target system’s internal logic and code:

• Black-box Fuzz Testing [13,14]: This method operates without any knowledge of the target system’s internal code or structure. It relies solely on the observation of input-output behaviors, such as diagnostic responses or communication timeouts. It is highly practical for testing third-party ECUs where source code is typically inaccessible due to intellectual property restrictions.
• White-box Fuzz Testing [15]: This approach requires full access to the source code and internal design of the system. It employs techniques like symbolic execution and data-flow analysis to explore all possible execution paths. While it provides high code coverage, it suffers from significant computational overhead and is often impractical for real-time embedded systems.
• Gray-box Fuzz Testing [16,17,18]: A hybrid approach that utilizes limited internal information, such as such as CAN communication databases and partial functional security specifications. It balances the efficiency of black-box testing with the depth of white-box testing. However, its application to automotive controllers can be challenging due to the resource constraints of low-end ECUs and the latency of feedback loops.

2.2. Related Works

2.2.1. Trends in Automotive Network Security Surveys

In-vehicle network (IVN) security has evolved significantly with the transition toward software-defined architectures. Rathore et al. [19] categorized in-vehicle communication architectures and primary internal protocols such as CAN, LIN, Flex-Ray, and Automotive Ethernet. They surveyed security solutions focused on machine learning-based Intrusion Detection Systems (IDS) and encryption-based authentication mechanisms. However, most of the presented security solutions and intrusion detection research were conducted on CAN-based internal networks, with limited coverage of security solution cases for LIN-based communication.

Luo et al. [20] provided a comprehensive classification of automotive cybersecurity testing methodologies, suggesting that penetration testing, vulnerability scanning, and fuzzing-based security verification are core technologies for vehicle security validation. Notably, this study analyzed that attack research targeting internal vehicle networks accounts for the largest proportion of automotive security literature. They reported numerous studies on fuzzing and penetration testing for major protocols like CAN, Scalable Service-Oriented Middleware over IP (SOME/IP), Diagnostics over IP (DoIP), and UDS. Conversely, security testing and fuzzing research for LIN were notably absent from the literature distribution. Beyond these surveys, several comprehensive studies have highlighted that while cyber–physical networks require holistic protection, research efforts remain disproportionately focused on high-speed protocols like CAN and Automotive Ethernet [21,22].

2.2.2. Fuzzing and Vulnerability Detection for In-Vehicle Networks

Automated fuzzing is a primary method for detecting implementation flaws in ECUs. I. Cho et al. [23] implemented a tool to scan sessions and services to understand ECU environments for security testing within UDS frameworks and conducted tests targeting the CAN environment of specific ECUs. This process effectively identified undocumented custom sessions and services within the ECUs. D. Kim et al. [24] analyzed the potential for detecting vulnerabilities in ECU internal software based on the CAN protocol, with the test subjects and fuzzing input structures designed according to the CAN frame format. However, their study did not include fuzzing experiments that considered the frame structure or the master–slave scheduling characteristics of the LIN protocol.

In parallel, recent research has explored intelligent fuzzing and mutation-based techniques to improve the detection rate of unknown vulnerabilities across various in-vehicle networks [25,26]. However, these frameworks often rely on the high bandwidth and multi-master capabilities of CAN and Automotive Ethernet, which allow for rapid feedback loops and high-concurrency testing. Such approaches are difficult to translate directly to the LIN protocol, where the rigid master–slave architecture and low baud rates impose significant physical communication constraints. Consequently, existing fuzzing methodologies frequently fail to account for the deterministic scheduling and inherent latency of LIN, necessitating a specialized optimization approach that considers the unique physical-layer characteristics of the bus.

2.2.3. Efficiency and Optimization in Security Testing

The efficiency of security testing is a critical factor in cyber–physical systems where resource constraints are significant. General research in the field of software testing has long utilized batch-processing and adaptive search algorithms to optimize search space exploration [27,28,29]. In the automotive domain, some attempts have been made to reduce testing time through structural-aware fuzzing or predictive models [25]. Nevertheless, systematic optimization of the fuzzing process for low-bandwidth protocols like LIN—specifically addressing the bottleneck of master–slave scheduling and recovery time—remains a largely unexplored area. This research gap necessitates a dedicated research and framework, which optimizes communication overhead while ensuring the resilience of the testing process.

3. Proposed Methodology

Conventional UDS fuzzing methodologies have primarily been researched for CAN-based systems; however, applying them directly to the LIN protocol reveals clear limitations due to fundamental architectural disparities. While CAN environments support high bandwidth and asynchronous, event-driven communication—enabling immediate response verification with negligible overhead—LIN is constrained by its low bandwidth and master–slave architecture. Specifically, verifying a response in LIN necessitates that the master issues a dedicated 0 × 3D slot (Slave Response) for every polling process, which introduces substantial cumulative latency for each test case. Furthermore, the deterministic nature of the schedule table and the resource-constrained characteristics of LIN-based ECUs often lead to synchronization failures with the fuzzer due to timing jitter under heavy diagnostic traffic.

Therefore, to overcome these physical and structural constraints of the LIN protocol and maximize testing efficiency, we propose a novel UDS fuzzing methodology that integrates schedule-aware batch processing and an efficient error-recovery mechanism. The proposed approach is designed to resolve the inherent bottlenecks of the LIN protocol, thereby maximizing testing throughput while ensuring robust synchronization during large-scale security audits.

Also, the proposed methodologies are engineered as protocol-level efficiency optimizers that are fundamentally agnostic to the specific fuzzing mode—whether Black-box, Gray-box, or White-box. While the fuzzing technique for generating test cases may vary depending on the degree of knowledge regarding the target system, such as access to source code or internal architecture, the core mechanisms—synchronizing batch sizes with the LIN schedule and optimizing error recovery—remain consistent across diverse testing environments. As illustrated in Figure 4, the proposed system consists of three primary stages: scanning UDS sessions and services present in the target ECU, identifying valid services based on the scan results, and executing fuzz tests for each identified service using optimized algorithms.

Figure 4. Overview of the proposed fuzz testing system./ECU: Electronic Control Unit.

The UDS session and service scanning processes build upon the research of I. Cho et al. [23], but have been advanced through specialized steps tailored for the LIN environment and an optimized logic that eliminates redundant operations upon encountering negative responses. From the perspective of component-level ECU testing within a LIN environment, the normal operation of the controller during the fuzz testing is verified by checking for a valid response to the UDS request message. Furthermore, this paper proposes three distinct methodologies for verifying the operational integrity and normal behavior of the ECU during the fuzzing process.

3.1. Session & Service Scan

To perform fuzzing in a UDS environment, the client scans all active diagnostic sessions on the target ECU and explores a session transition diagram based on the breadth-first search (BFS) algorithm. Upon identifying all sessions, the proposed methodology navigates through each session according to the session transition diagram to enumerate all active services and their sub-functions.

The active sessions on the target ECU are determined through positive or negative responses to Diagnostic Session Control (0 × 10) service requests. Figure 5 illustrates the message flow between the client and the target ECU for session scanning. The client transmits a Diagnostic Session Control (0 × 10) request message using PID 0 × 3C to scan for active sessions and generates a polling message to the ECU node to receive the response.

Figure 5. Flow graph of the scanning session step.

In response to the request, the target ECU populates the received polling message frame with the appropriate PCI, SID, payload, and checksum values. In this study, the responses returned by the target ECU for session scanning are categorized into the following three cases:

• Case 1: If a positive response with SID 0 × 50 is returned for a SID 0 × 10 request, it is determined that the target session is accessible from the current session.
• Case 2: If a negative response with NRC 0 × 7F 0 × 12 (Sub-function Not Supported) is returned for a SID 0 × 10 request, it is determined that the target session is inaccessible from the current session.
• Case 3: If a negative response with an NRC value other than 0 × 12 is returned for a SID 0 × 10 request, the client directly determines the accessibility of the target session based on the specific NRC received.

Algorithm 1 illustrates the algorithm for discovering all sessions within the ECU. Starting from the default session (0 × 01), the algorithm identifies all accessible sessions from the current state and sequentially explores them based on the BFS algorithm.

Algorithm 1: BFS-based Diagnostic Session Scan

Require:$\mathrm{Default} \mathrm{session} s_0$$, \mathrm{candidate} \mathrm{session} \mathrm{set} \mathcal{S}$, $NAD$$, \mathrm{retry} \mathrm{limit} K$  Ensure:$\mathrm{Shortest} \mathrm{transition} \mathrm{paths} paths\left[s\right]$$, \mathrm{transition} \mathrm{edges} E$ 1: $paths\leftarrow \{s_0:\left[s_0\right]\}$ 2: $E \leftarrow \mathrm{\varnothing }$ 3: $Q\leftarrow queue initialized with{ s}_0$ 4: 5: while $Q$ is not empty do 6:   $u\leftarrow \mathrm{pop}\left(Q\right)$ 7:   $P_u\leftarrow paths\left[u\right]$ 8:   SendUDS($NAD,0\times 10,s_0$) //reset to default session 9:   for all $x\in P_u$ do 10:     $ok\leftarrow \mathrm{false}$ 11:     for $i = 1$ to $K$ do 12:       $resp \leftarrow$ SendUDS($NAD, 0\times 10, x$) 13:       if $resp==\mathrm{POS}\left(0\times 50,x\right)$ then 14:         $ok\leftarrow \mathrm{true}$; break 15:       end if 16:     end for 17:     if $ok==\mathrm{false}$ then 18:       continue while-loop 19:      end if 20:   end for 21:   for all $v\in \mathcal{S}$ do 22:     if $v \in paths$ or $v == u$ then 23:       continue 24:     end if 25:     $ok\leftarrow \mathrm{false}$ 26:     for $i = 1$ to $K$ do 27:       $resp \leftarrow$ SendUDS($NAD, 0\times 10, v$) 28:       if $resp==\mathrm{POS}\left(0\times 50,v\right)$ then 29:         $ok\leftarrow \mathrm{true}$; break 30:       end if 31:     end for 32:     if $ok==\mathrm{true}$ then 33:       $E\leftarrow E\cup \left(u,v\right)$ 34:       $paths\left[v\right]\leftarrow P_u\oplus \left[v\right]$ 35:       push($Q, v$) 36:     end if 37:     SendUDS($NAD,0\times 10,s_0$) 38:     for all $x\in P_u$ do 39:       SendUDS($NAD, 0\times 10, x$) 40:     end for 41:    end for 42: end while 43: 44: return $paths, E$

Subsequently, after accessing each session based on the transition diagram explored during the session scanning process, the client scans for the list of active services and the available sub-function values for each service. Figure 6 shows the message flow for scanning services and sub-functions within each session. The client transmits a request message for the diagnostic service to be scanned using PID 0 × 3C and delivers a polling message to the ECU node to receive a response. For services that support sub-functions, their availability is verified by sequentially incrementing the sub-function value from 0 × 00 within a predefined range. Additionally, the Tester Present (0 × 3E) service is invoked to maintain the non-default session state, preventing an automatic reversion to the default session due to timeout during the scanning process.

Figure 6. Flow graph of the scanning service step.

The target ECU responds to the service request by populating the received polling message frame with the appropriate PCI, SID, payload, and checksum values. In this study, the response cases that the target ECU can return during service scanning are classified into the following three categories:

• Case 1: If a positive response (0 × SV + 0 × 40) is returned for a specific service (0 × SV) request, it is determined that the target service exists within the current session.
• Case 2: If a negative response with NRC 0 × 7F 0 × 11 (Service Not Supported) is returned for a specific service (0 × SV) request, it is concluded that the target service does not exist in the current session. Consequently, the process bypasses any subsequent sub-function discovery for that service and immediately proceeds to the next service ID to optimize scanning efficiency.
• Case 3: If a negative response with an NRC value other than 0 × 11 is returned for a specific service (0 × SV) request, the client directly determines the existence of the target service based on the received NRC.

Algorithm 2 illustrates the algorithm for traversing all services within the ECU. Service and sub-function scans are performed sequentially across all active sessions identified during the session scanning phase.

Algorithm 2: Path-aware UDS Service Scan with NRC = 0 × 11 Shortcut

Require$: \mathrm{Discovered} \mathrm{paths} paths\left[s\right]$$, \mathrm{service} \mathrm{ID} \mathrm{range} \mathcal{D}$$, \text{sub-function} \mathrm{set} \mathcal{F}$, $NAD$ Ensure$: \mathrm{Result} \mathrm{table} T\left(session,path,SID,SUB,code\right)$ 1: $\mathbf{for} \mathbf{all} s \in paths$ sorted by path length do 2:   $P\leftarrow paths\left[s\right]$ 3:   SendUDS$(NAD, 0\times 10, 0\times 01$) //reset to default session 4:   $\mathbf{for} \mathbf{all} x \in P$ do 5:     $resp \leftarrow$ SendUDS($NAD, 0\times 10, x$) 6:     $\mathbf{if} resp \ne$ POS($0\times 50, x$) then 7:       continue next session 8:     end if 9:   end for 10:   $\mathbf{for} \mathbf{all} SID\in \mathcal{D}$ do 11:     $res{p}_0\leftarrow$ SendUDS($NAD, SID, 0\times 00$) 12:     $\mathbf{if} res{p}_0==$ NEG($0\times 7F, SID, 0\times 11$) then//NRC 0 × 11 Shortcut 13:       $\mathbf{for} \mathbf{all} SUB\in \mathcal{F}$ do 14:         $\mathrm{Append}(T,\left(s,P,SID,SUB,11\right)$) 15:       end for 16:       continue next SID 17:     end if 18:     $\mathbf{for} \mathbf{all} SUB\in \mathcal{F}$ do 19:       $resp \leftarrow$ SendUDS($NAD, SID, SUB$) 20:       $code \leftarrow$ Interpret($resp, SID$) 21:       Append($T,\left(s,P,SID,SUB,code\right)$) 22:     end for 23:   end for 24: end for 25: 26$: \mathrm{return} T$

3.2. Select Valid Services

The selection of target UDS services for fuzz testing is a critical step that bridges the gap between initial scanning and actual test execution. Rather than performing an exhaustive, brute-force search across all possible services, which is often inefficient and time-consuming in a resource-constrained LIN environment, this study utilizes the sub-function and session information identified during the scanning phase to select targets strategically. We adopt a risk-based approach as emphasized in international cybersecurity standards such as ISO/SAE 21434 and UN R155 (Vehicle Type Approval). This methodology focuses on the critical attack surface of the ECU, ensuring that the fuzzing process remains both efficient and relevant to realistic threat scenarios.

The target services, as shown in Table 2, are categorized into three primary security domains based on their potential impact on the vehicle’s security posture and functional safety. The selection criteria for each domain are detailed as follows:

Table 2. Recommended service to select for fuzz testing.

Request SID	Service	Selection
0 × 10	DiagnosticSessionControl	◎
0 × 11	EcuReset	○
0 × 19	ReadDTCInformation	○
0 × 22	ReadDataByIdentifier	◎
0 × 23	ReadMemoryByAddress	◎
0 × 27	SecurityAccess	◎
0 × 28	CommunicationControl	○
0 × 2C	DynamicallyDefineDataIdentifier	◎
0 × 2E	WriteDataByIdentifier	◎
0 × 2F	Input/OutputControlByIdentifier	◎
0 × 31	RoutineControl	◎
0 × 34	RequestDownload	◎
0 × 35	RequestUpload	◎
0 × 36	TransferData	◎
0 × 3D	WriteMemoryByAddress	◎
0 × 3E	TesterPresent	○
0 × 83	AccessTimingParameters	○
0 × 85	ControlDTCSetting	○
0 × 86	ResponseonEvent	○
0 × 87	LinkControl	○

◎: Mandatory, ○: Recommend./DTC: Diagnostic Trouble Code

• Information retrieval and diagnostic monitoring: Services related to data reading are prioritized to assess the risk of Information Disclosure and unauthorized asset access. Read Data by Identifier (0 × 22) and Read Memory by Address (0 × 23) are critical pathways for retrieving sensitive information, such as Vehicle Identification Numbers (VIN), software versions, and internal calibration data. Furthermore, monitoring services like Read DTC Information (0 × 19) and Dynamically Define Data Identifier (0 × 2C) are included to verify if the ECU erroneously exposes internal states or violates memory boundaries when subjected to malformed diagnostic requests.
• Data configuration and parameter modification: Services that allow modification of the ECU’s operational logic or parameters are defined as core attack surfaces. Unauthorized configuration changes via Write Data by Identifier (0 × 2E) or Write Memory by Address (0 × 3D) can lead to system malfunctions. Specifically, services involved in large-scale data transmission, such as Request Download/Upload (0 × 34/0 × 35) and Transfer Data (0 × 36), are designated as mandatory targets. These are critical for assessing the ECU’s resilience against unauthorized firmware updates or integrity bypass attempts, which are high-priority risks in cybersecurity audits.
• Authentication, session management, and system control: This category focuses on services directly linked to privilege escalation and physical actuator control. Security Access (0 × 27) serves as the primary gateway for privileged operations; any logic flaw in this authentication process can compromise the entire system’s security perimeter. Diagnostic Session Control (0 × 10) and ECU Reset (0 × 11) are assessed for their ability to force state transitions that might disable security features. Most importantly, Input/Output Control by Identifier (0 × 2F) and Routine Control (0 × 31) is prioritized as a high-risk target because it enables the remote execution of specific ECU functions, posing a direct threat to functional safety if manipulated.

3.3. Methods for Fuzz Testing

Fuzzing is conducted based on the previously scanned session and service lists to detect vulnerabilities—such as improper exception handling for abnormal inputs and unexpected system crashes—and to evaluate stability within undefined regions of the target ECU. Furthermore, this study aims to perform UDS-based fuzzing to verify the security of component-level ECUs within a LIN network.

Considering the specific characteristics of LIN, such as its master–slave architecture—where slave nodes can only respond through the master node’s polling messages—and its relatively low transmission speed, this paper proposes three UDS-based fuzzing methodologies categorized by the approach used to verify malfunctions and anomalies. Each proposed method transmits separate UDS request messages to monitor normal processing and valid responses, thereby identifying potential ECU malfunctions.

3.3.1. Sequential Discovery Fuzzing (SDF)

The Sequential Discovery Fuzzing (SDF) test conducts fuzzing on a per-service basis and verifies the normal operation status of the ECU by transmitting a polling message for every individual fuzzing request. While this approach is similar to standard fuzzing procedures where responses are monitored for all test cases to determine malfunctions, the inherent characteristics of LIN communication require the master node to transmit an individual polling message to retrieve each response. The input data for the test consists of a list of N test messages, each of test messages is composed of either random or ascending values of a specified length. The detailed operational algorithm for this method is illustrated in Algorithm 3.

Algorithm 3: Sequential Discovery Fuzzing (SDF)

Input: TestMessagesList T$\left[N\right]$ Output: ErrorList 1: $\mathbf{for} i = 1$ to $N$ do 2:   send_fuzz_message($T\left[i\right]$) 3:   $response \leftarrow$ send_polling_message() //Polling (e.g., TesterPresent 0 × 3E) 4:   $\mathbf{if} response==\mathrm{NO}\_\mathrm{RESPONSE}$ or $response==\mathrm{ERROR}$ then 5:     $\mathrm{ErrorList}.\mathrm{add}\left(T\right[i]$) 6:     reset_ecu_power()//Hard Reset via Relay or Power Supply 7:     re-enter_session($0\times 10$)//Diagnostic Session Control 8:   end if 9: end for

3.3.2. Batch-Based Sequential Fuzzing (BSF)

The Batch-based Sequential Fuzzing (BSF) test executes the fuzzing process by dividing the total test message lists (T[N]) into batches of a specific size (m). Also, the input data for the test consists of a list of N test messages, each of test messages is composed of either random or ascending values of a specified length. Unlike the previously proposed SDF test, the BSF method just transmits all fuzz messages within a defined batch consecutively. To verify the operational integrity and processing status of the ECU after batch transmission, the system sends a session transition (re-entry) request to the current diagnostic session followed by a polling message, determining the state based on the response from the target node.

If a positive response is received, the test proceeds to the next batch and repeats the process. If a negative response is returned, the system performs an SDF procedure within that specific batch range to identify the exact error-inducing message. Once the fault is pinpointed, the BSF process resumes from the subsequent message with a full batch size, continuing the cycle. The detailed operational algorithm for this methodology is illustrated in Algorithm 4.

Algorithm 4: Batch-based Sequential Fuzzing (BSF)

Input: TestMessagesList $T\left[N\right]$, BatchSize $m$ Output: ErrorList 1: $i \leftarrow 1$ 2: while $i \le N$ do 3:   $upper\_limit\leftarrow \min \left(i+m-1,N\right)$ 4: 5:   for $j = i$ to $upper\_limit$ do//1. Batch Transmission 6:     send_fuzz_message($T\left[j\right]$) 7:   end for 8: 9:    $status \leftarrow$ check_session_and_polling() //2. Verification 10:   if $status == SUCCESS$ then 11:     $i \leftarrow upper\_limit + 1$ 12:   else 13:     reset_ecu_power() 14:     re-enter_session($0\times 10$) 15:     for $k = i$ to $upper\_limit$ do 16:       send_fuzz_message($T\left[k\right]$) 17:       if check_polling() $== FAIL$ then 18:         ErrorList.add($T\left[k\right]$) 19:         reset_ecu_power() 20:         re-enter_session($0\times 10$) 21:         $i \leftarrow k + 1$ 22:         break 23:       end if 24:     end for 25:   end if 26: end while

3.3.3. Batch-Based Binary-Search Fuzzing and Accelerated Security Testing (BB-FAST)

Similar to the BSF test, the Batch-based Binary-search Fuzzing and Accelerated Security Testing (BB-FAST) test divides total test message lists (T[N]) into batches of a specific size (m). Also, the input data for the test consists of a list of N test messages, each of test messages is composed of either random or ascending values of a specified length. It transmits all fuzz messages within a batch and then evaluates the operational integrity and processing status of the ECU by sending a session transition (re-entry) request to the current session followed by a polling message.

For a positive response, the process proceeds to the subsequent batch. In contrast to the BSF test, if a negative response is returned, the BB-FAST identifies the error-triggering message through a binary search. Within the batch range where the error occurred, the algorithm explores the messages using a binary search mechanism; at each step of this search, the system transmits a session transition (re-entry) request and a polling message to verify the response of the target node.

Upon identifying the message that induced the error, the BB-FAST process resumes from the next message with a full batch size, repeating the sequence. The detailed operational algorithm for this methodology is illustrated in Algorithm 5.

Algorithm 5: Batch-Based Binary-Search Fuzzing and Accelerated Security Testing (BB-FAST)

Input: TestMessagesList $T\left[N\right]$, BatchSize $m$ Output: ErrorList 1: function FindErrorBinary($low, high$) 2:   if $low == high$ then 3:     return $low$ 4:   end if 5:   $mid \leftarrow \lfloor (low + high)/2 \rfloor$ 6:    7:   for $j = low$to $mid$ do //Test left half 8:     send_fuzz_message($T\left[j\right]$) 9:   end for 10:   $status \leftarrow$ check_session_and_polling() 11:   if $status == FAIL$ then 12:     reset_ecu_power() 13:     re-enter_session($0\times 10$) 14:     return FindErrorBinary($low, mid$) //Narrow down to left half 15:   else//Left is normal, error is in the right half 16:     return FindErrorBinary($mid + 1, high$) 17:   end if 18: end function 19: 20: $i \leftarrow 1$ 21: while $i \le N$ do 22:   $upper\_limit\leftarrow \min \left(i+m-1,N\right)$ 23:   for $j = i$ to $upper\_limit$ do 24:     send_fuzz_message($T\left[j\right]$) 25:   end for 26:   $status \leftarrow$ check_session_and_polling() 27:   if $status == SUCCESS$ then 28:     $i \leftarrow upper\_limit + 1$ 29:   else 30:     reset_ecu_power() 31:     re-enter_session($0\times 10$) 32:     $error\_idx \leftarrow$ FindErrorBinary($i, upper\_limit$) 33:     ErrorList.add($error\_idx$) 34:     reset_ecu_power() 35:     re-enter_session($0\times 10$) 36:     $i \leftarrow error\_idx + 1$ 37:   end if 38: end while

4. Theoretical Analysis on Proposed Methods

This chapter evaluates the three proposed fuzzing methodologies introduced in Section 3 by calculating their respective time complexities and providing a comparative analysis. Variables that significantly impact the performance of the fuzzing process—including the total number of messages, batch size, and the number of identified vulnerabilities or errors are defined. By establishing these time complexity models, we analyze the most effective fuzzing approach across different experimental conditions and scenarios.

4.1. Time-Complexity Analysis

To calculate the time complexity for each of the three proposed fuzzing methodologies, the variables that impact performance are defined in Table 3.

Table 3. Variable symbols with time-complexity.

Symbol	Description	Unit
$N$	Total number of fuzzing messages (packets)
$m$	Batch size
$k$	$\mathrm{Number} \mathrm{of} \mathrm{errors} \left(\mathrm{vulnerabilities}\right) \mathrm{in} \mathrm{the} \mathrm{target} \mathrm{controller} (k\ll N)$
$T_f$	Transmission time for each fuzzing message	$ms$
$T_p$	Session Re-entry and Polling Message Verification Time	$ms$
$T_r$	ECU initialization time (power re-application, boot-up, etc.)	$ms$

For SDF, polling process is performed for each of the $N$ fuzzing packets to verify the response. Furthermore, for every error identified in the target ECU, additional time is required for a power cycle (power cycling the ECU to perform a hard reset). The time complexity of SDF testing is expressed as Equation (1):

$$T_{SDF}=N\left(T_f+T_p\right)+k·T_r$$

(1)

For BSF, fuzzing messages are sent for all $N$ packets, while polling messages are transmitted for every batch of size $m$ to verify the response. For each detected error, the ECU undergoes one power cycle, followed by an SDF procedure within the batch range to pinpoint the specific error. Assuming that errors are uniformly distributed within the batch of size $m$, the average number of attempts required to identify a single error is defined as ${\displaystyle \frac{m+1}{2}}$, based on the expected value of a discrete uniform distribution. For the purpose of complexity analysis, this expected value is simplified to ${\displaystyle \frac{m}{2}}$. The total time complexity of BSF testing is expressed as Equation (2):

$$T_{BSF}=\left(N·T_f+{\displaystyle \frac{N}{m}}{T}_p\right)+k\left(2T_r+{\displaystyle \frac{m}{2}}\left(T_f+T_p\right)\right)$$

(2)

BB-FAST operates similarly to BSF, but it utilizes a binary search within the batch range of size $m$ for each detected error to identify the specific error-inducing message. The total time complexity of BB-FAST is expressed as Equation (3):

$$T_{BB-FAST}=\left(N·T_f+{\displaystyle \frac{N}{m}}{T}_p\right)+k\left(2T_r+\sum _{i=1}^{{\log }_{2}m}\left({\displaystyle \frac{m}{2^i}}{T}_f+T_p+T_r\right)\right)$$

(3)

The calculated time complexities are represented using Big-O notation for worst-case scenarios in Table 4, considering the parameters $N$, $m$, and $k$, which determine the system scale and status. The analysis results demonstrate that the proposed batch-based techniques (BSF and BB-FAST) achieve superior efficiency compared to SDF by drastically reducing the frequency of response verifications from the total number of messages ($N$) to the batch unit (${\displaystyle \frac{N}{m}}$). In particular, BB-FAST maintains high stability and minimizes performance degradation, even in environments with frequent communication delays or ECU resets, by reducing the recovery complexity from linear ($m$) to logarithmic ($\log m$).

Table 4. Comparison of theoretical time complexity for the proposed fuzzing methods.

Method	Time-Complexity (Big-O)
Sequential Discovery Fuzzing (SDF)	$O(N+k)$
Batch-based Sequential Fuzzing (BSF)	$O({\displaystyle \frac{N}{m}}+km)$
Batch-Based Binary-Search Fuzzing and Accelerated Security Testing (BB-FAST)	$O({\displaystyle \frac{N}{m}}+k\log m)$

Notes: N = total test cases, k = number of errors, m = batch size.

4.2. Performance Evaluation via Numerical Simulation

In this section, numerical simulations are performed under various environments to compare and evaluate the practical efficiency of the three proposed fuzzing methodologies. These simulations reflect the actual constraints of the LIN bus environment, such as the potential number of errors ($k$), the practical ECU recovery time ($T_r$), and the polling cost ($T_p$) for verifying normal operation. The variables used in the simulations follow the definitions in Table 3, and the common parameters are established in Table 5.

Table 5. Fixed Parameters for numerical simulation.

Symbol	Default Value	Notes
$N$	65,536	2-byte range (0 × 0000~0 × FFFF)
$T_f$	10 ms	Frame transmission time at LIN 20 kbps
$T_p$	100 ms	0 × 10 Service polling latency included

4.2.1. Simulation According to ERROR Density (k)

This subsection analyzes the performance of each fuzzing methodology based on the number of vulnerabilities present in the target ECU. The parameters established for this analysis are as follows:

• k: 1 to 100 (independent variable);
• m: 512 (fixed value);
• T_r: 2.0 s (fixed value; reflects the human reaction limit for controllability as specified in ISO 26262-3 [30]).

Figure 7 illustrates the simulated test duration as a function of the number of errors, the independent variable. As the number of errors increases, BB-FAST demonstrates a gentler rate of time increase compared to BSF due to its search efficiency. This indicates that even when numerous vulnerabilities are detected in a large-scale test case environment, the time required to pinpoint the error locations remains controlled below a certain threshold, thereby ensuring overall test availability.

Figure 7. Simulation results according to error density.

4.2.2. Analysis According to ECU Recovery Time (T_r)

This subsection evaluates the performance of the fuzzing methodologies according to the time required for ECU recovery after an error occurs. The parameters for this analysis are:

• k: 10 (fixed value);
• m: 512 (fixed value);
• T_r: 0.5 s to 5.0 s (independent variable).

Figure 8 presents the simulated test duration as a function of the ECU recovery time. The results indicate that with a batch size of 512, a recovery time of approximately 3 s serves as the crossover point where the time efficiency of BB-FAST surpasses that of BSF. However, in environments where the batch size is set larger, considering scenarios where $N$ exceeds 2 bytes (e.g., 3 bytes), BB-FAST is expected to maintain its performance advantage through its efficient search structure, even in high-performance ECU environments with significant recovery times.

Figure 8. Simulation results according to ECU recovery time.

4.2.3. Simulation According to Batch Size (m)

This subsection analyzes the performance of each fuzzing methodology relative to the batch size. The parameters for this analysis are:

• k: 10 (fixed value);
• m: 10 to 1000 (independent variable);
• T_r: 2.0 s (fixed value; reflects the human reaction limit for controllability as specified in ISO 26262-3 [30]).

Figure 9 shows the simulated test duration between BSF and BB-FAST based on the batch size. An intersection in performance between BSF and BB-FAST occurs at a batch size of approximately 300. Notably, from a batch size of approximately 100, the test duration for BSF begins to increase at a much steeper gradient compared to BB-FAST.

Figure 9. Simulation results according to batch size.

4.2.4. Summary of Simulation Results

The results of the numerical simulations conducted in this section confirm that the proposed BB-FAST methodology demonstrates the highest scalability in environments with limited bandwidth and significant reset overhead, such as the LIN bus. The key findings and academic implications derived from the simulations are as follows:

• Strategic Selection of Parameter m: As confirmed in Section 4.2.3, the theoretical optimal batch size varies depending on error density (k) and recovery time (T_r). However, this paper adopts m = 512 as a strategic standard, comprehensively considering the scalability for future tests (e.g., 3-byte search spaces), the minimization of polling overhead, and the implementation efficiency of the binary search algorithm. This design ensures universal performance across diverse vehicle network environments rather than seeking a local optimum for a specific scenario.
• Ensuring Feasibility for Large-scale Search Spaces: The simulation results show that an m = 512 configuration suppresses the frequency of polling—the dominant bottleneck in total execution time—to 1/512 of the original rate. This minimizes the time delay caused by polling overhead (T_p) even in vast search spaces exceeding 2 bytes, thereby guaranteeing deterministic throughput to complete fuzz tests within restricted project schedules.
• Optimization of Search Efficiency Under Physical Constraints: Even in environments with high reset overhead (e.g., T_r = 2.0 s), BB-FAST maintains efficient performance in locating error points through binary search. While the linear search cost of BSF increases sharply as the batch size grows, BB-FAST exhibits a gentle logarithmic increase, demonstrating robustness against system instability (presence of multiple errors) or large-scale batch environments.

In conclusion, considering the characteristics of LIN communication and the physical constraints of actual vehicle controllers, BB-FAST-based testing is the most stable and efficient approach for performing UDS-based fuzzing.

5. Experimental Results

In this section, we evaluate the proposed system by performing fuzz tests on an actual automotive ECU equipped with LIN-based UDS. We developed specific tools to implement the three proposed fuzzing methodologies and conducted 2 types of experiments on the target controller within a standardized experimental environment.

5.1. Experimental Setup

The hardware and software environments for the UDS-based fuzz tests on the LIN bus are configured as detailed in Table 6 and Table 7. Based on the system mechanism proposed in Section 3, we developed a testing tool and executed it on the physical ECU.

Table 6. Hardware configuration and specifications.

Component	Specification	Role
Laptop	Intel(R) Core(TM) Ultra 7, 32 GB RAM	developing tool, controlling fuzz testing scripts
PEAK PLIN-USB	supports all LIN specifications	USB to LIN bus converter
Automotive ECU	LIN-based Electronic Control Unit	experimental target
Power Relay	12 V/5 A, 1-Channel Relay	ECU power relay and reset

Table 7. Software and development environment.

Component	Specification	Role
Operating System	Windows 11 Pro
Language	Python 3.13.9	script developing, test controlling
Module	PLinApi	LIN communication API
	numpy, matplotlib	data processing, simulation and result plotting
Monitoring	PLIN-View	real-time LIN monitoring

5.2. Experiment Process

In this study, to verify the performance of the proposed BB-FAST framework from various perspectives, two distinct experimental scenarios were designed according to the fuzz testing methodology described in Section 2.1.3. All experiments were conducted on a real-world automotive ECU in a black-box environment, where the recovery time ($T_r$) required for an ECU power cycle upon error detection was fixed at 2 s.

The adoption of a black-box environment is strategically intended to reflect the most challenging conditions where knowledge is highly restricted, while accounting for the realistic constraints of automotive security testing. In typical industrial scenarios, security researchers must perform vulnerability assessments on individual units or vehicle-integrated ECUs without access to proprietary source code or internal architectural designs. By evaluating the proposed methodologies in this information-restricted setting, we verify their practical applicability and robustness in identifying undefined vulnerabilities and stability issues solely through standard protocol responses. Furthermore, demonstrating high efficiency in a black-box environment—the most demanding case—effectively underscores the potential for the universal deployment of our optimization mechanisms across diverse testing paradigms.

5.2.1. Scenario 1: Generation-Based Service Fuzzing

The first scenario involves generation-based fuzz testing based on UDS services identified through the Session & Service Scan stage. The overall experimental procedure follows the methodology described in Section 3 and detailed parameters except error ($k$) are configured identically to the values in Section 4.2.1. First, individual diagnostic sessions and the available services for each session in the target ECU are identified. Subsequently, a specific service is selected, and appropriate payloads are constructed based on the UDS standard. In this paper, the experiment focuses on the Read Data by Identifier (SID 0 × 22) service. The Data Identifier (DID) size is set to the commonly used 2-byte range (0 × 0000–0 × FFFF), and the inputs are constructed and injected sequentially to evaluate the framework’s exhaustive search efficiency.

5.2.2. Scenario 2: Mutation-Based Frame Fuzzing

The second scenario is mutation-based fuzz testing, which identifies anomalies by generating random values within the message frames of UDS on LIN. This scenario evaluates the robustness of the UDS frame structure itself rather than the stability of specific UDS services. The experiment targets the raw message frames used in the LIN transport layer. Following the structure defined in Figure 3 of Section 2.1.2, the Node Address (NAD) is fixed, while the remaining 7 bytes of the data field are configured as random input datasets to be injected into the target ECU. Total test messages count ($N$) will be set to 10,000, and other detailed parameters, except error (k), are configured identically to the values in Section 4.2.1.

5.3. Experiment Results

This section analyzes and compares the results of the three proposed fuzzing methodologies (SDF, BSF, and BB-FAST) based on the experimental environment established in Section 5.1 and the two experimental procedures described in Section 5.2.

5.3.1. Result Analysis of Scenario 1: Generation-Based Service Fuzzing

The results of the session and service scanning for the target ECU are summarized in Table 8, which identifies a total of three sessions and seven services per session. Among the identified services, fuzzing was performed on the 2-byte data field of the Read Data by Identifier (SID 0 × 22) service; as shown in Table 9, the target ECU responded normally to all requests without any anomalies, such as abnormal terminations or communication delays.

Table 8. Session & Service scanning results.

Session ID	0 × 01	0 × 02	0 × 03
Service ID
0 × 10 (DiagnosticSessionControl)	O	O	O
0 × 11 (EcuReset)	O	O	O
0 × 22 (ReadDataByIdentifier)	O	O	O
0 × 27 (SecurityAccess)	O	O	O
0 × 2E (WriteDataByIdentifier)	O	O	O
0 × 31 (RountineControl)	O	O	O
0 × 3E (TesterPresent)	O	O	O

Table 9. Fuzz testing measurement results in scenario 1.

Session	Service ID	Execution Time (SDF)	Execution Time (BSF)	Execution Time (BB-FAST)
0 × 01	0 × 22	121 min 48 s	7 min 53 s	7 min 51 s
0 × 02	0 × 22	17 min 56 s	7 min 50 s	7 min 49 s
0 × 03	0 × 22	121 min 48 s	7 min 53 s	7 min 51 s

The experimental results show that in Session 0 × 01 and Session 0 × 03, the batch-based algorithms (BSF and BB-FAST) achieved a time reduction of approximately 93.44% compared to the traditional sequential approach (SDF). In Session 0 × 02, a time reduction of approximately 55.56% was observed. This efficiency gain is attributed to the minimization of network idle time and physical response latency through batch processing. Notably, Session 0 × 02, being a programming session, demonstrated a faster processing speed compared to other sessions due to its specialized response handling.

In this specific test, the execution times for BSF and BB-FAST were nearly identical. This is because, in the “Best Case” scenario where no errors occur, BB-FAST executes the same batch verification logic as BSF. Although the binary search-based error identification logic—the core feature of BB-FAST—was not activated, the results confirm that BB-FAST maintains the same high-performance levels as BSF under normal operational conditions.

5.3.2. Result Analysis of Scenario 2: Mutation-Based Frame Fuzzing

In Scenario 2, random mutation-based fuzzing was conducted to evaluate the system’s ability to detect unexpected defects in a black-box environment. Out of the 10,000 test messages, a critical malfunction occurred at approximately the 75% mark, causing the target ECU to stop responding and undergo a power shutdown. The performance metrics for each methodology are detailed in Table 10.

Table 10. Fuzz testing measurement results in scenario 2.

Proposed Method	Initial Discovery Time	In-Batch Localization Time	Reset Overhead (Tr × reset count)	Total Identification Time
SDF	57 min 45 s	-	-	57 min 45 s
BSF	1 min 2 s	2 min 34 s	2 s (2 s × 1)	3 min 38 s
BB-FAST	1 min 2 s	8 s	8 s (2 s × 4)	1 min 18 s

The results demonstrate a pronounced contrast in efficiency when an actual error is encountered. The traditional SDF approach required 57 min and 45 s to reach the error point, suffering from the massive cumulative latency of LIN’s sequential polling. While BSF utilized batch processing to achieve an Initial Discovery Time of 1 min and 2 s, it encountered a significant bottleneck during the In-batch localization phase. BSF spent an additional 2 min and 34 s to pinpoint the specific error index, resulting in a total execution time of 3 min and 38 s.

In contrast, BB-FAST completed the entire process in just 1 min and 18 s. Although it incurred a higher reset count compared to BSF, its optimized binary search logic reduced the In-batch Localization Time to a mere 8.2 s. This represents a time reduction of approximately 97.7% compared to SDF and 64.2% compared to BSF. These findings highlight that BB-FAST’s primary strength lies in its worst-case handling; by minimizing idle synchronization wait times during the localization process, it ensures that exhaustive security audits remain feasible even in environments requiring frequent controller resets.

5.3.3. Comparison and Discussion with Theoretical Analysis

The experimental results from Scenarios 1 and 2 provide strong empirical evidence for the theoretical time complexity models derived in Section 4.2. By mapping the measured execution times to the established formulas, we can analyze the efficiency of the proposed algorithms from both communication and recovery perspectives.

In Scenario 1, where no ECU errors occurred ($k=0$), the execution times of BSF and BB-FAST converged as predicted by the theoretical models. According to the Equations (1) and (4):

$$T_{BSF}\approx T_{BB-FAST}\approx N·T_f+{\displaystyle \frac{N}{m}}{T}_p$$

(4)

The experimental data showed a 93.44% time reduction in Sessions 0 × 01 and 0 × 03. This gain is mathematically attributed to the term ${\displaystyle \frac{N}{m}}{T}_p$. In LIN-based UDS communication, the physical response latency ($T_p$) and master–slave polling delay constitute the dominant overhead. By grouping $m$ messages into a single batch, the algorithm effectively reduces the cumulative polling wait time by a factor of $m$. The convergence of BSF and BB-FAST at approximately 7 min and 50 s proves that under the best-case complexity of $\mathsf{\Omega }\left({\displaystyle \frac{N}{m}}\right)$, both algorithms maintain optimal performance by minimizing network idle time.

Scenario 2, where one ECU error occurred ($k=1$), reveals a pronounced divergence between the algorithms, validating the worst-case complexity analysis. The core difference lies in the in-batch localization phase, where the specific error index is identified.

• BSF: The localization term for BSF is defined as $k\left(2T_r+{\displaystyle \frac{m}{2}}\left(T_f+T_p\right)\right)$. Although BSF reduced the initial discovery time, it suffered from a linear search complexity of $O\left(km\right)$. In the experimental environment, this resulted in an isolation time of 154 s. This confirms that for larger batch sizes ($m$), the sequential approach within a failed batch becomes a significant bottleneck, especially when each retry is subject to physical protocol delays.
• BB-FAST: BB-FAST optimizes this process using binary search, with a complexity of $O\left({\displaystyle \frac{N}{m}}+k {\log }_2 m\right)$. The localization time was reduced to only 8.2 s, despite a higher reset count. This demonstrates a critical trade-off: although BB-FAST triggers more power cycles ($k\sum T_r$), the logarithmic reduction in the number of test cases $\left(\sum {\displaystyle \frac{m}{2^i}}{T}_f+T_p\right)$ far outweighs the reset overhead.

6. Discussions and Limitations

The experimental results validate that BB-FAST effectively overcomes the inherent performance bottlenecks of the LIN protocol, which have long hindered comprehensive security testing. As demonstrated in Section 5.3, the proposed framework achieved a massive time reduction—reaching up to 97.7% compared to the traditional SDF approach. This stark contrast highlights that the sequential master–slave polling in SDF is no longer a viable option for exhaustive security audits in modern vehicular environments.

A key finding of this study is the pronounced performance evolution from SDF to BB-FAST, particularly in error-prone environments. While BSF successfully reduced the communication overhead of SDF through batch processing, it encountered a linear search bottleneck during error localization. In Scenario 2, BB-FAST achieved a 64.2% time reduction even compared to BSF, proving that the binary search-based recovery logic is essential for handling the physical latency of power cycles ($T_r$). These results confirm that while BSF improves the best-Case, BB-FAST provides the only scalable solution for the worst-case involving frequent controller resets.

From a practical perspective, the primary significance of this study lies in its ability to close the security blind spot in low-bandwidth in-vehicle networks. Due to the 20 kbps baud rate limit of LIN, researchers have often simplified or omitted security verification for LIN-based ECUs. BB-FAST transforms this burden into a feasible industrial process. By ensuring that rigorous UDS-based fuzzing can be completed within a practical timeframe, even during worst-case scenarios, our framework provides a robust tool for meeting the strict demands of UN R155 and ISO/SAE 21434 compliance.

Regarding the limitations and future research directions, first, this study primarily focuses on fuzzing injections based on Single Frames (SF). While the LIN transport layer standard (ISO 17987-2) supports multi-frame transmissions consisting of First Frames (FF) and Consecutive Frames (CF), it differs structurally from CAN’s ISO-TP by omitting Flow Control (FC, 0 × 30) frames and relying on the master’s schedule for continuous transmission. Since UDS service requests (SID) and core parameters are generally determined within the FF, service-level availability testing can be largely addressed through the current single-frame fuzzing approach. However, in multi-frame scenarios, subsequent CFs may contain unexpected anomalous payloads, which are critical targets for security verification as they can trigger buffer overflows or logical malfunctions within the protocol stack. Therefore, future research should extend the batch processing and binary search logic of BB-FAST to multi-frame units to precisely identify error-inducing points within complex data structures.

Second, the empirical experiments were limited to a single LIN-based controller and a 2-byte payload range. In complex vehicular architectures, recovery times ($T_r$) and response behaviors may vary significantly across different ECU types. Additionally, high-bandwidth protocols like Automotive Ethernet or data-heavy systems like In-Vehicle Infotainment (IVI) present different challenges in terms of protocol complexity and data volume. Therefore, subsequent studies should focus on verifying the scalability of BB-FAST across diverse hardware architectures and advancing toward multivariate fuzzing algorithms with expanded payload ranges to detect more sophisticated, unknown vulnerabilities.

7. Conclusions

This study presented BB-FAST, an optimized fuzzing framework designed to overcome the inherent communication bottlenecks and recovery delays of the LIN protocol in automotive cybersecurity testing. By integrating batch-based request processing with a binary search-based error localization logic, this research bridge the gap between theoretical algorithmic efficiency and physical network constraints. Based on the empirical validation across multiple scenarios, the final conclusions are as follows:

• Validation of Algorithmic Efficiency: Experimental results confirmed that BB-FAST achieves a massive time reduction—up to 97.7% compared to traditional SDF—by optimizing the ${\displaystyle \frac{N}{m}}$ communication overhead. This proves that the theoretical complexity established in this study is highly consistent with real-world controller behavior, transforming exhaustive LIN-based security audits from an impractical task into a feasible industrial process.
• Superior Resilience in Error Scenarios: A key contribution of this study is the demonstration of BB-FAST’s superiority in worst-case scenarios. While conventional batch methods (BSF) suffer from linear search bottlenecks during error localization, BB-FAST achieved a 64.2% performance gain over BSF in error-triggering environments. By reducing the localization time to a logarithmic scale ($O\left(k\log m\right)$), the framework effectively suppresses the impact of physical reset latencies ($T_r$), ensuring high test availability even under frequent controller failures.
• Elimination of Security Blind Spots: By maximizing test feasibility within practical timeframes, BB-FAST allows for the inclusion of low-bandwidth LIN components—which were previously overlooked—into the standard security verification suite. This ensures that core diagnostic protocols are thoroughly verified, facilitating compliance with rigorous international standards such as UN R155 and ISO/SAE 21434.

While this study focused on specific LIN-based ECUs, the underlying logic of the proposed optimization is theoretically extensible to various automotive communication architectures, suggesting its potential for broader application. Future research will aim to advance toward intelligent, multivariate fuzzing to enhance detection rates for unknown vulnerabilities and verify the scalability of this methodology in high-speed networks like Automotive Ethernet. We expect these findings to serve as a foundational benchmark for establishing standardized, high-efficiency automotive cybersecurity verification methodologies.