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

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 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 method-ologies, 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,9,10].

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 [11]. 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 0x00 to 0x3B are used for signal transmission, while 0x3C is utilized for requests in diagnostic functions and 0x3D 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.

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 0x3C and the corresponding data to the bus. Subsequently, when the master node transmits a response header with a PID of 0x3D along with an empty data frame, the slave node corresponding to the node address (NAD) receives the 0x3D 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.

2.1.2. Unified Diagnostic Services (UDS)

Unified diagnostic services (UDS) is an automotive diagnostic communication protocol defined by the ISO 14229 standard [12,13], 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 0x40. Conversely, the SID of a negative response is 0x7F, which is returned along with a negative response code (NRC) that provides specific information regarding the nature of the response.

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 [14] 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, 0x3C(Request) and 0x3D(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.

2.1.3. Fuzz Testing

Fuzz testing (fuzzing) 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:

• Mutation-based Fuzzing: 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 Fuzzing: 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.

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. [15] 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, the majority 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. [16] 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 [17,18].

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. [19] 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. [20] 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 [21,22]. 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 [23,24,25]. In the automotive domain, some attempts have been made to reduce testing time through structural-aware fuzzing or predictive models [21]. 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

This chapter introduces the proposed system and fuzzing methodologies for performing UDS-based fuzz tests in a LIN environment. As illustrated in Figure 4, the proposed system operates in three primary stages: scanning the UDS sessions and services present in the target ECU, identifying valid services, and executing fuzz tests for each identified service.

The UDS session and service scanning processes build upon the research of I. Cho et al. [19], 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 (0x10) 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 (0x10) request message using PID 0x3C to scan for active sessions and generates a polling message to the ECU node to receive the response.

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 0x50 is returned for a SID 0x10 request, it is determined that the target session is accessible from the current session.
• Case 2: If a negative response with NRC 0x7F 0x12 (Sub-function Not Supported) is returned for a SID 0x10 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 0x12 is returned for a SID 0x10 request, the client directly determines the accessibility of the target session based on the specific NRC received.

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

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 7 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 0x3C 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 0x00 within a predefined range. Additionally, the Tester Present (0x3E) 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.

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 (0xSV + 0x40) is returned for a specific service (0xSV) request, it is determined that the target service exists within the current session.
• Case 2: If a negative response with NRC 0x7F 0x11 (Service Not Supported) is returned for a specific service (0xSV) 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 0x11 is returned for a specific service (0xSV) request, the client directly determines the existence of the target service based on the received NRC.

Figure 8 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.

3.2. Select Valid Services

Based on the sub-function information of available sessions and services identified through the scanning process, the target UDS services for fuzzing are selected. This stage can be conducted using distinct selection methodologies depending on the requirements of various stakeholders—such as the testing entity, ECU manufacturer, or cybersecurity audit manager—as well as compliance with diverse certification regulations.

As presented in Table 2, the proposed methodology prioritizes active services that support sub-functions or additional parameters as primary fuzzing targets. Specifically, it is proposed that fuzzing be mandatory for core functions related to security authentication, data retrieval, and operational control, such as Security Access (0x27), Read Data by Identifier (0x22), and Routine Control (0x31). Furthermore, undocumented custom services and services without additional parameters may also be included within the scope of the test.

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 for 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 detailed operational algorithm for this method is illustrated in Figure 9.

3.3.2. Batch-Based Sequential Fuzzing (BSF)

The Batch-based Sequential Fuzzing(BSF) test executes the fuzzing process by dividing the total test range(N) into batches of a specific size(m). 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 Figure 10.

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 the total test range(N) into batches of a specific size(m). 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 Figure 11.

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.

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_{BBF}=\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 packets($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$).

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.

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 sec (fixed value; reflects the human reaction limit for controllability as specified in ISO 26262-3 [26])

Figure 12 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.

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 sec to 5.0 sec (independent variable)

Figure 13 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 seconds 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.

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 1,000 (independent variable)
• T_r: 2.0 s (fixed value; reflects the human reaction limit for controllability as specified in ISO 26262-3 [26])

Figure 14 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.

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 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.

5.2. Experiment Process

The overall experimental procedure follows the methodology described in Section 3. First, we identify the available services for each session in the target ECU through a session and service scan. Subsequently, a specific service is selected to perform a comparative performance experiment among the three proposed fuzzing techniques.

The experiment assumes a black-box environment where internal structures and vulnerability information of the target ECU are unknown. The total execution time is measured as the primary metric for evaluating the efficiency of each methodology. Detailed parameters are configured identically to the values in Section 4.2.1. Specifically, in the event of an error requiring an ECU power cycle, the recovery time ($T_r$) from the moment of the error to the resumption of the test is fixed at 2 seconds.

In this experiment, Read Data by Identifier(SID 0x22) was selected from the identified sessions, and the performance of the three fuzzing techniques was verified by transmitting 65,536 payloads (equivalent to a 2-byte range) for that service.

5.3. Experiment Results

This subsection analyzes and compares the results of the three proposed fuzzing methodologies (SDF, BSF, and BB-FAST) based on the established experimental environment and procedures.

5.3.1. Measurement of Execution Time and Analysis of Results

The results of scanning the sessions and services in the target ECU and performing fuzzing on a 2-byte data field for a selected service are summarized in Table 8. With experimental ECU, a total of three sessions and seven services were identified. During the experiment, the target ECU responded normally to all requests without any anomalies, such as abnormal terminations or communication delays.

The experimental results show that in Session 0x01 and Session 0x03, 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 0x02, 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 0x02, being a programming session, demonstrated a faster processing speed compared to other sessions due to its specialized response handling.

5.3.2. Analysis of Performance in Error-Free Scenarios

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.3. Comparison and Discussion with Theoretical Analysis

The similarity in execution times for BSF and BB-FAST in this experiment can be further explained through the time complexity analysis conducted in Section 4.2. According to the theoretical analysis, the complexity of both algorithms converges to $\mathsf{\Omega }\left({\displaystyle \frac{N}{m}}\right)$ in the best-case scenario where no errors are detected. The fact that both techniques achieved a significant reduction in execution time compared to SDF proves that the theoretical efficiency of batch processing remains valid in actual controller environments. Although the binary search logic of BB-FAST was not triggered due to the absence of ECU errors (corresponding to $k$=0 as defined in Section 4.2.1), it is expected that BB-FAST would outperform BSF in environments where errors occur, as demonstrated in our previous complexity analysis.

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 significant time reductions—55.56% and 93.44% depending on the session—compared to traditional SDF. These results confirm that the theoretical model ($\mathsf{\Omega }\left({\displaystyle \frac{N}{m}}\right)$) established in Section 4.2 is highly consistent with real-world controller behavior. Notably, even in the best-case scenario where no errors occur ($k$=0), BB-FAST maintains performance equivalent to the optimized BSF without introducing additional computational or communication overhead.

From a practical perspective, the primary significance of this study lies in its ability to close the security gap in low-bandwidth in-vehicle networks. Due to the extremely slow baud rate of LIN (up to 20 kbps), performing exhaustive UDS-based fuzzing has often been considered impractical, leading to a tendency to either simplify or entirely omit security verification for LIN-based ECUs. BB-FAST transforms this time-consuming burden into a feasible industrial process. By significantly reducing the testing duration and ensuring high test availability through its binary search logic—especially when dealing with the significant latency of power cycles ($T_r$) —our framework allows for rigorous and exhaustive security audits that were previously avoided due to time constraints.

Regarding the limitations of this study, while the theoretical analysis and simulations suggest consistent performance across various environments, 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 data volume and protocol complexity. Therefore, future research 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 complex, unknown vulnerabilities.

7. Conclusions

This study proposed BB-FAST, an optimized framework designed to address the critical time constraints and test availability issues in LIN-based cybersecurity testing. Based on the modeling of the controller fuzzing environment and verification through empirical experiments, the final conclusions are as follows:

• Solving the LIN Performance Bottleneck: By restructuring fuzzing requests into batch units, BB-FAST achieved a substantial reduction in execution time—specifically by 55.56% and 93.44%—proving that algorithmic optimization can effectively mitigate the physical limitations of low-bandwidth protocols.
• Ensuring Resilience in Error Scenarios: Through the integration of binary search logic, the framework maintains high efficiency under normal conditions while effectively suppressing time delays during error-induced resets to a logarithmic scale, ensuring a robust and uninterrupted testing process.
• Expanding the Scope of Practical Security Testing: This research provides a scalable solution to include LIN-based components, which were previously difficult to test rigorously, into the standard security verification suite. By maximizing test feasibility, BB-FAST ensures that core diagnostic protocols in modern cyber-physical automotive systems are thoroughly verified against potential threats.

While the results of this study were derived from specific controller and protocol environments, the underlying logic of the proposed algorithms is extensible to various automotive communication architectures. Future research will focus on integrating intelligent fuzzing logic to enhance detection rates for unknown vulnerabilities and ensuring scalability toward high-speed networks, such as Automotive Ethernet. We expect the findings of this study to serve as foundational data for establishing standardized methodologies for automotive cybersecurity verification.