Intelligent network connected vehicle ethernet fuzzy test method and system

Abstract

The application provides an intelligent networked vehicle Ethernet fuzzy test method and system, which comprises the following steps: based on the protocol knowledge base, the field boundary, the field semantics and the constraint relationship of the seed message are analyzed; the block structured variation is performed on the protocol field, the candidate variation field and the associated field are checked and corrected according to the field semantics, and the variation test message is recombined and sent to the device under test; the communication response, the device state and the program execution coverage data are collected, the safety critical fault is determined by using the safety area, the output barrier function and the fault tolerance count, and the seed queue and the variation parameter are fed back and updated. The application considers the variation diversity and the effectiveness of the message structure, can reduce the invalid test message, improve the deep protocol path reach rate, the program coverage rate and the test resource utilization rate, suppress the false alarm caused by the accidental communication jitter, improve the identification accuracy of the non-collapse type safety critical fault, and realize the closed-loop test driven by the coverage feedback.

Description

Technical Field

[0001] This invention relates to the field of automotive network security testing technology, and in particular to a method and system for Ethernet fuzz testing of intelligent connected vehicles. Background Technology

[0002] As intelligent connected vehicles evolve towards a centrally integrated electronic and electrical architecture, in-vehicle Ethernet (100BASE-T1 / 1000BASE-T1) is gradually replacing traditional CAN / LIN buses as the backbone network within the vehicle. Upper-layer protocols such as DoIP (Diagnostic over Internet Protocol) defined by ISO 13400 and SOME / IP (Scalable service-oriented middleware over IP) defined by AUTOSAR are widely deployed in gateways, domain controllers, and intelligent driving ECUs.

[0003] However, the increasing complexity and code size of automotive Ethernet protocol stacks expose ECUs to more unknown vulnerability risks. ISO / SAE 21434 (Road Vehicle Cybersecurity Engineering Standard) requires that vehicle electronic systems undergo thorough security testing and verification during the development phase. Fuzzing, an automated testing technique that discovers software vulnerabilities by injecting malformed or random data, has become a key means of verifying automotive cybersecurity.

[0004] Existing fuzzing methods typically generate test packets using random bit flipping, random byte replacement, field insertion, or field deletion. Because these methods lack identification of protocol field boundaries, field semantics, and inter-field constraints, they easily violate fundamental conditions such as packet length, checksum, and protocol state. This results in a large number of generated test packets being discarded in the early stages of protocol parsing, making it difficult for them to enter the deeper processing logic of the protocol stack. While some protocol template-based fuzzing methods can generate packets according to a preset format, their mutation methods and parameters are relatively fixed, making it difficult to simultaneously ensure packet structure validity and the degree of mutation propagation. Furthermore, when dealing with various automotive Ethernet protocols, significant manual costs are required to maintain the protocol templates and mutation rules.

[0005] Furthermore, existing testing methods typically diagnose faults based on a single phenomenon such as no response, connection interruption, or device reset, or directly output abnormal results after detecting a single response timeout. However, in-vehicle Ethernet communication may experience occasional network jitter, packet loss, and response delays, and a single out-of-bounds error can easily lead to misdiagnosis of a fault. Meanwhile, security issues that do not cause program crashes, such as incorrect service identifiers, abnormal response content, or deviations in device status, may not be detected through traditional crash monitoring methods. At the same time, existing testing processes often lack effective correlation between program execution coverage information, security fault detection results, and seed scheduling and mutation parameter adjustments. Testing resources are easily wasted on protocol paths that are already fully covered, affecting the efficiency of discovering deep vulnerabilities. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the present invention aims to provide an Ethernet fuzz testing method and system for intelligent connected vehicles, which aims to improve the effectiveness and diversity of mutated test messages, enable test messages to reach the deep processing path of the protocol stack, and accurately determine and provide feedback-driven testing for safety-critical faults of the device under test.

[0007] To achieve the above objectives, in a first aspect, the present invention provides: a method for Ethernet fuzz testing of intelligent connected vehicles, comprising the following steps: Obtain the protocol configuration information and normal communication data of the device under test, and perform protocol parsing on the vehicle Ethernet packets in the normal communication data based on the protocol knowledge base to obtain the seed packet and the field boundaries, field semantics and constraint relationships of each protocol field in the seed packet; Select target seed messages from the seed queue, group the target seed messages according to the field boundaries, perform multiple rounds of structured mutation on the grouping results, and use a permutation congruent random number generator to generate the random parameters required for each round of structured mutation to obtain candidate mutation fields; Based on the semantics of the field, the protocol constraint verification rules corresponding to the candidate mutation fields are determined, and the protocol constraint verification rules and the constraint relationships are used to perform protocol constraint verification and related field correction on the candidate mutation fields. The verified mutation fields are then reassembled into mutation test messages. The mutation test message is injected into the device under test via the vehicle Ethernet, and the testable output data and execution coverage data corresponding to the device under test are collected. The output barrier function value is calculated based on the pre-established safety zone for the measurable output data, and the safety-critical fault of the device under test is determined based on the output barrier function value and the preset fault tolerance number.

[0008] According to one aspect of the above technical solution, the protocol knowledge base stores protocol templates, field constraint relationships, and state transition rules corresponding to one or more protocols among DoIP, SOME / IP, TSN, and UDPNM; the semantics of the protocol fields include length, checksum, type, and payload fields.

[0009] According to one aspect of the above technical solution, the step of selecting the target seed message from the seed queue specifically includes: Extract legitimate messages that conform to the corresponding protocol structure and protocol status from the normal communication log as seed messages, and write various sub-messages along with their protocol type, field boundaries, field semantics, constraint relationships, field coverage bitmap and priority weight into the seed queue; The target seed packet is selected from the seed queue based on the priority weight and the field coverage bitmap.

[0010] According to one aspect of the above technical solution, the structured mutation adopts a data block iterative mutation strategy based on Feistel networks, and the specific steps of the data block iterative mutation strategy include: The protocol fields are concatenated according to their arrangement order in the target seed message to obtain the byte sequence to be mutated, and the byte sequence to be mutated is divided into a first data block and a second data block according to the byte length. Feistel iteration is performed on the first data block and the second data block according to the preset number of mutation rounds. In each Feistel iteration, the second data block obtained in the previous iteration is used as the first data block obtained in the current iteration. The second data block obtained in the previous iteration and the round key of the current iteration are input into the round function. The first data block obtained in the previous iteration is bitwise XORed with the output of the round function to obtain the second data block obtained in the current iteration. The calculation expressions for the first and second data blocks after this iteration are as follows: ; ; in, and These represent the first and second data blocks obtained in the previous iteration, respectively. and These represent the first and second data blocks obtained in this iteration, respectively. F represents bitwise XOR. Represents the round function. This represents the round key for the i-th round; After completing the Feistel iteration, the resulting obfuscated byte sequence is mapped back to the candidate variant field according to the reverse process of field segmentation.

[0011] According to one aspect of the above technical solution, the round function includes one or more of the following: field swap sub-operation, random offset injection sub-operation, and nonlinear permutation sub-operation. The hybrid mutation orchestrator selects the corresponding sub-operation according to the current operation weight, and when multiple sub-operations are selected, they are executed in the order of field swap, random offset injection, and nonlinear permutation.

[0012] According to one aspect of the above technical solution, the permutation congruent random number generator uses 128 internal states and generates an internal state sequence through linear congruent operations, wherein the internal states are updated according to the following formula: ; In the formula, This indicates the internal state before the update. This represents the updated internal state, where M and C are preset large prime constants; At each output, the internal state is obfuscated using a nonlinear permutation function, and the output permutation relationship is expressed as: ; In the formula, For output, This represents the current internal state. This indicates a circular right shift operation. Indicates a right shift operation, S and This indicates the PCG output permutation parameters. This represents the intermediate state obtained by XOR shifting the internal state; Each round's key is derived from the initial seed of the permutation congruent random number generator and the current round number, based on the following formula: ; In the formula, This represents the initial seed of the PCG unbiased random generator, and i represents the round number of the current Feistel iteration. This represents the round operation function.

[0013] According to one aspect of the above technical solution, the steps of protocol constraint verification and associated field correction specifically include: Based on the semantics of the candidate mutation fields, the corresponding protocol constraint verification rules are matched from the protocol knowledge base; Verify the consistency between the length field and the actual load length, and the consistency between the checksum field and the load content; When the candidate mutation field violates the corresponding protocol constraints, the corresponding length field, checksum field or other related fields are updated according to the actual payload length or payload content. After verification and correction, the candidate mutation fields and associated fields are reorganized according to the message structure of the target protocol to obtain the mutation test message.

[0014] According to one aspect of the above technical solution, the measurable output data is determined based on the collected communication response data and device status data; The communication response data includes DoIP ACK messages, DoIP NACK messages, SOME / IP Response messages, SOME / IP Error messages, response delays, and TCP connection state changes; The device status data includes the status message, diagnostic response, and error indicator signal output by the device under test via the CAN bus; The security constraints corresponding to the security zone include a valid response message format, a response delay within a preset range, and the return of the correct service identifier.

[0015] According to one aspect of the above technical solution, the execution coverage data is collected through the JTAG debugging interface, the SWD debugging interface, or software instrumentation. The current program execution coverage data is compared with the historical program execution coverage data to obtain the code branch coverage increment; When the mutation test message triggers a new code block or a new branch execution path, the mutation test message is written as a new seed into the seed queue, and the priority weight of the new seed is increased. Based on the incremental code branch coverage and the results of safety-critical fault detection, the mutation round number, PCG seed distribution, weight of mutation operation type, S-box selection, seed mutation probability, and mutation intensity of the Feistel network are adjusted, and the adjusted mutation parameters are used in the next round of testing.

[0016] On the other hand, the present invention also provides a system for implementing the intelligent connected vehicle Ethernet fuzz testing method described above, comprising: The parsing module is used to obtain the protocol configuration information and normal communication data of the device under test. Based on the protocol knowledge base, it performs protocol parsing on the vehicle Ethernet packets in the normal communication data to obtain the seed packet and the field boundaries, field semantics and constraint relationships of each protocol field in the seed packet. The mutation module is used to select target seed packets from the seed queue, group the target seed packets according to the field boundaries, perform multiple rounds of structured mutation on the grouping results, and use a permutation congruent random number generator to generate random parameters required for each round of structured mutation to obtain candidate mutation fields. The correction module is used to determine the protocol constraint verification rules corresponding to the candidate mutation fields based on the field semantics, and to perform protocol constraint verification and related field correction on the candidate mutation fields based on the protocol constraint verification rules and the constraint relationship, and to reassemble the verified mutation fields into mutation test messages. The execution module is used to inject the mutation test message into the device under test via the vehicle Ethernet, and to collect the testable output data and execution coverage data corresponding to the device under test. The monitoring module is used to calculate the output barrier function value based on the safety zone pre-established for the measurable output data, and to determine whether the device under test has experienced a safety-critical fault based on the output barrier function value and the preset fault tolerance number.

[0017] Compared with existing technologies, the advantages of this invention are as follows: It identifies the protocol type, field boundaries, field semantics, field constraint relationships, and state transition relationships of vehicular Ethernet packets through a protocol knowledge base, providing a data foundation for seed packet selection and protocol-aware block-based structured mutation; it performs block-based structured mutation on the byte sequence to be mutated formed by protocol fields, and can adopt different implementation methods such as Feistel network mutation or hash block mutation, improving mutation diversity and data diffusion while adapting to different computing power conditions and testing requirements; based on field semantics, it verifies and corrects the length, checksum, legal value range, field dependency, and state transition of candidate mutation fields and their associated fields, enabling the mutation results to be reconstructed into test packets conforming to the basic structure of the target protocol. This approach reduces the likelihood of test packets being discarded during the initial protocol parsing stage, improving accessibility to deeper protocol logic. It establishes secure regions by combining communication response data, device status data, and program execution coverage data. By using output barrier functions and fault tolerance counts to determine deviations from continuous secure regions, it reduces false alarms caused by occasional network jitter or response timeouts and identifies safety-critical faults that do not manifest as program crashes. Furthermore, it updates the seed queue, seed scheduling priority, and block-based structured variation parameters based on code coverage increments and safety-critical fault detection results, forming a closed-loop testing process driven by coverage feedback. This improves the automation level, effective testing rate, path coverage capability, fault determination accuracy, and reproducibility of test results in multi-protocol automotive Ethernet fuzz testing. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the Ethernet fuzzy testing method for intelligent connected vehicles in the first embodiment of the present invention. Figure 2 This is a structural block diagram of the intelligent connected vehicle Ethernet fuzzy testing system in the second embodiment of the present invention; Figure 3 This is a deployment architecture diagram of the intelligent connected vehicle Ethernet fuzz testing system in the second embodiment of the present invention; The following detailed description, in conjunction with the accompanying drawings, will further illustrate the present invention. Detailed Implementation

[0019] To facilitate understanding of the present invention, a more complete description will be given below with reference to the accompanying drawings. Several embodiments of the invention are illustrated in the drawings. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] Example 1 The first embodiment of this invention provides a method for Ethernet fuzz testing of intelligent connected vehicles. This method is applicable to the automated security vulnerability detection of devices under test running one or more of the following in-vehicle Ethernet protocols: DoIP, SOME / IP, TSN, and UDPNM. Wherein, DoIP represents an IP-based diagnostic protocol, SOME / IP represents an IP-based scalable service-oriented middleware, TSN represents Time-Sensitive Networking, UDPNM represents the UDP network management protocol, PCG represents a permutation congruence generator, and S-box represents a nonlinear permutation table.

[0022] Please see Figure 1 The figure shows a flowchart of the Ethernet fuzz testing method for intelligent connected vehicles in the first embodiment of the present invention. As shown in the figure, the method includes the following steps: Step S100: Obtain the protocol configuration information and normal communication data of the device under test. Based on the protocol knowledge base, perform protocol parsing on the vehicular Ethernet packets in the normal communication data to obtain seed packets and the field boundaries, semantics, and constraint relationships of each protocol field in the seed packets. In this embodiment, during the protocol identification, field parsing, and seed queue establishment process, the protocol configuration file and normal communication log of the device under test are obtained. The protocol knowledge base is called to identify the protocol type of the vehicular Ethernet packets in the normal communication log. Protocol fields are extracted according to the corresponding protocol template, the semantics of the fields are labeled, the field boundaries and the legal value range of the fields are identified, and the constraint relationships between the fields and the corresponding protocol state transition relationships are determined.

[0023] The protocol knowledge base stores protocol templates, field constraints, and state transition rules for one or more of the following protocols: DoIP, SOME / IP, TSN, and UDPNM. For DoIP, the knowledge base stores message templates and state transition rules for vehicle discovery, route activation, and diagnostic message transmission as specified in ISO 13400-2. For SOME / IP, the knowledge base stores message templates and state transition rules for storage service discovery, remote procedure calls, and event notifications. For TSN, the knowledge base stores field templates for time-aware shaping fields in IEEE 802.1Qav and IEEE 802.1Qbv. For UDPNM, the knowledge base stores field templates and state transition rules for UDP network management messages.

[0024] The protocol knowledge base also stores the constraint relationships between different protocol fields, such as the consistency relationship between the DoIP message total length field and the actual message length, and the correspondence between the SOME / IP Length field and the Payload range. The semantics of protocol fields include length, checksum, type, and payload fields. Based on the valid value range of a field, candidate mutation values ​​corresponding to minimum, maximum, boundary, and out-of-bounds values ​​can be generated for subsequent structured mutations and corrections of related fields.

[0025] Specifically, legitimate messages that conform to the corresponding protocol structure and protocol status are extracted from the normal communication log as seed messages, and various sub-messages, along with their protocol types, field boundaries, field semantics, constraint relationships, field coverage bitmaps, and priority weights, are written into the seed queue, thereby completing the initialization of the seed queue.

[0026] Step S200: Select target seed messages from the seed queue, group the target seed messages according to the field boundaries, perform multiple rounds of structured mutation on the grouping results, and use a permutation congruent random number generator to generate random parameters required for each round of structured mutation to obtain candidate mutation fields.

[0027] During target seed selection and multiple rounds of structured mutation, the target seed message is selected from the seed queue based on the priority weight of the seed message and the field coverage bitmap. The PCG random output can also be used to determine whether to use a uniform random strategy or a coverage-weighted random strategy to select the target seed message.

[0028] After selecting the target seed message, the protocol fields in the target seed message are grouped according to the protocol field parsing results. Let the target seed message be (P), and it be divided into (n) protocol fields according to field semantics, field boundaries, and field constraint relationships: Field segmentation is performed according to the protocol specification corresponding to the target seed packet. For example, for a DoIP packet, its four-byte header is used as the first protocol field. The source logical address and the destination logical address are used as subsequent protocol fields. The load data is .

[0029] By concatenating the protocol fields according to their order of appearance in the target seed message, a sequence of bytes to be mutated is obtained. This sequence is then divided into first data blocks according to their byte length. Second data block ,Right now: ; Perform Feistel iterations on the first and second data blocks according to the preset number of mutation rounds. For ,implement: ; ; in, and These represent the first and second data blocks obtained in the previous iteration, respectively. and These represent the first and second data blocks obtained in this iteration, respectively. F represents bitwise XOR. Represents the round function. This represents the round key for the i-th round.

[0030] Round function The process includes three sub-operations: field swapping, PCG random offset injection, and S-box nonlinear permutation. The hybrid mutation orchestrator selects one or more sub-operations from these three sub-operations according to the operation weights corresponding to the current adaptive mutation strategy. When multiple sub-operations are selected, they are executed in the order of field swapping, PCG random offset injection, and S-box nonlinear permutation.

[0031] The field swap sub-operation is as follows: Generate two random indices idx1 and idx2 based on the PCG unbiased random generator, and swap the positions of the idx1-th byte and the idx2-th byte in the current data block to be processed.

[0032] The PCG random offset injection sub-operation is: for each byte of the current data block to be processed. The PCG unbiased random integers in the range of 0 to 255 are generated, and the corresponding bytes are updated according to the following formula: ; in, This indicates that the PCG unbiased random generator returns an unbiased random integer within the interval ([0,255]); The S-box nonlinear permutation sub-operation involves replacing the byte sequence in the current data block with bytes using a predefined 16x16 nonlinear permutation table. The nonlinear permutation table has a difference uniformity of no more than four and a linear deviation of no more than thirty-two, to ensure sufficient confusion during the nonlinear permutation.

[0033] Each round key is derived from the initial seed of the PCG generator and the current round number. The derivation relationship of the round key in round (i) is as follows: In the formula, represents the initial seed of the PCG unbiased random generator, and i represents the round number of the current Feistel iteration.

[0034] The PCG unbiased random generator uses 128 internal states, and first generates the internal state sequence through linear congruential operations: ; in, This indicates the internal state before the update. This represents the updated internal state, where M and C are preset large prime constants.

[0035] Each time an output is made, instead of directly returning the low-order bits of the internal state, the internal state is obfuscated using a non-linear permutation function. The output permutation relationship is expressed as follows: ; in, For output, This represents the current internal state. This indicates a circular right shift operation. Indicates a right shift operation, S and This indicates the PCG output permutation parameters. This represents the intermediate state obtained by XOR shifting the internal state; The PCG unbiased random generator is also used for multiple random decision nodes in the fuzzy testing process. For mutation location selection, the following is adopted: Determine the starting byte offset of the mutation, where, Indicates the byte length of the target seed message. For the mutation operation type selection, use: Determine the current mutation operation type in field swapping, PCG random offset injection, or S-box nonlinear permutation, where, This indicates the number of optional mutation operation types. For Feistel round key derivation, the aforementioned method is used. Generate a round key for each Feistel iteration.

[0036] After completing R rounds of Feistel iterations, the obfuscated byte sequence is obtained. The inverse process of splitting by field maps it back to the candidate variant field. The mathematical guarantee of the inverse transform is that for any valid original message, there always exists a unique mutation sequence.

[0037] The Feistel network is reversible when using the same round key sequence in reverse order; therefore, a corresponding structured mutation sequence can be determined for any original message. A change in one bit in the original data can change approximately 50% of the bits in the output after multiple iterations. In a mutation strength analysis, approximately 90% avalanche coverage can be achieved with 4 mutation rounds (R=4), and a near-complete avalanche effect is achieved with 8 mutation rounds (R=8).

[0038] In other embodiments of this application, a hash-based block mutation method can be used instead of the Feistel network. Specifically, rolling hash blocks and differential mutations are used to perform structured mutations on protocol fields. For example, BLAKE3 hashes are used to divide the message into fixed-length blocks, and then random mutations are performed on each block. This method cannot guarantee the global reversibility and avalanche effect of the Feistel network, but it has lower computational overhead and is suitable for embedded test platforms with limited computing power.

[0039] In other embodiments of this application, a state-space traversal guided by a deterministic finite automaton can be used instead of random mutation. By establishing a protocol state machine, state transition paths and boundary conditions are systematically enumerated. This approach has strong covering determinism, but it is limited by state-space explosion in complex protocols.

[0040] In a performance analysis, assuming that a traditional random mutation has an 80% probability of breaking the validity of the message format, only about 20% of test cases can enter the deep protocol processing logic. Structured mutation based on the Feistel network can increase the effective test rate from 20% to 30% of the traditional random mutation method to 60% to 80% while maintaining the protocol syntax, thus improving the efficiency of test resource utilization by two to three times.

[0041] While maintaining nanosecond-level generation speed, PCG improves the Dieharder statistical test pass rate from approximately 65% ​​for LCG to over 95%. In related experiments, PCGAFL++ outperforms the original AFL++ on 60% of the test targets. With the adoption of p-fault tolerance boundaries, approximately 95% of occasional false alarms can be filtered in a typical (p=3) configuration. In addition to supporting DoIP, SOME / IP, TSN, and UDPNM, the protocol knowledge base can be extended to proprietary multimedia protocols or diagnostic protocols by adding protocol templates, field semantics, and constraint relationships. The method can be used to implement the safety testing and verification of automotive electronic systems as required by ISO / SAE 21434.

[0042] Step S300: Determine the protocol constraint verification rule corresponding to the candidate mutation field based on the field semantics, and perform protocol constraint verification and associated field correction on the candidate mutation field based on the protocol constraint verification rule and the constraint relationship, and reassemble the verified mutation field into a mutation test message.

[0043] During the protocol constraint verification and correction process for candidate variant fields and associated fields, the corresponding protocol constraint verification rules are matched from the protocol knowledge base based on the field semantics of the candidate variant fields, and the candidate variant fields and their associated fields are verified according to the matched protocol constraint verification rules.

[0044] The verification includes the consistency between the length field and the actual payload length, the consistency between the checksum field and the payload content, the consistency between field values ​​and their legal value ranges, the dependencies between different fields, and the protocol state transition relationships. When a candidate mutation field violates the corresponding protocol constraints, the corresponding length field, checksum field, or other related fields are updated according to the actual payload length or payload content; or the field value is reselected according to the legal value range of the corresponding protocol field. After completing the checksum correction, the candidate mutation fields and related fields are reorganized according to the message structure of the target protocol to obtain the complete mutation test message P'.

[0045] Step S400: Inject the mutation test message into the device under test via the vehicle Ethernet, and collect the testable output data and execution coverage data corresponding to the device under test.

[0046] During the transmission of mutation test messages and the acquisition of test data, mutation test messages (P') are sent to the device under test through the 100BASE-T1 or 1000BASE-T1 vehicle Ethernet physical layer, and communication response data, device status data and program execution coverage data of the device under test are collected.

[0047] The communication response data includes DoIP ACK messages, DoIP NACK messages, SOME / IP Response messages, SOME / IP Error messages, response latency, and TCP connection status changes. The device status data includes status messages output by the device under test via the CAN bus, diagnostic responses, and error indicator signals; it may also include power consumption changes and electromagnetic radiation anomalies of the device under test. Program execution coverage data is collected via the JTAG debugging interface, SWD debugging interface, or software instrumentation, including the code branch coverage of the device under test and whether the current mutation test message triggers a new code block or a new branch execution path.

[0048] Step S500: Calculate the output barrier function value based on the safety zone pre-established for the measurable output data, and determine whether the device under test has experienced a safety-critical fault based on the output barrier function value and the preset fault tolerance number.

[0049] In the process of monitoring safe zones and identifying safety-critical faults, a safe zone S is pre-established according to the safety specifications of the device under test (DUT), and the measurable output y(t) of the DUT is determined based on the collected communication response data and device status data. The safety constraints corresponding to the safe zone include valid response message format, response delay within a preset range, return of the correct service identifier, and no unexpected electronic control unit reset. As a specific example of response delay constraints, the allowable response delay range is set to [1ms, 50ms].

[0050] The output barrier function takes the measurable output y(t) that can be acquired from the device under test (DUT) as input, without needing to estimate the entire internal state of the DUT. For the response delay, the output barrier function is defined as: B(y) = min(T) max -T resp(y) ,T resp(y) -T min ); Where T resp(y) For the observed response delay, T min and T max The user-defined safe delay interval. When B(y) > 0, the DUT is within the safe interval; when B(y) ≤ 0, it indicates that the DUT's response behavior deviates from the safe specification.

[0051] To distinguish between "infrequent timeouts / bit errors (noise)" and "genuine protocol stack failures," a p-fault tolerance counter is introduced. Specifically: Initialize fault counter ; Each sampling period determines : ,but ;like ,but ; when Upon confirmation of a safety-critical failure, a failure report is output (including timestamp, barrier function value, safety zone deviation, and currently injected test cases). ); The p-value is adaptively set according to the safety criticality level of the DUT: for ASIL-D level ECUs... (Zero tolerance), ASIL-B / C (Tolerance for occasional jitter), QM level is taken (High tolerance).

[0052] Furthermore, the method also includes updating the seed queue and the mutation parameters used for subsequent structured mutations based on program execution coverage data. Specifically, the current program execution coverage data is compared with historical program execution coverage data to obtain the code branch coverage increment; when the current mutation test message triggers a new code base block or a new branch execution path, the current mutation test message is written as a new seed into the seed queue, and the priority weight of the new seed is increased.

[0053] Based on the incremental code branch coverage and the results of safety-critical fault detection, the mutation rounds, PCG seed distribution, weights of mutation operation types, S-box selection, seed mutation probability, and mutation strength of the Feistel network are adjusted, and the adjusted mutation parameters are used in the next round of testing. This shifts test resources from the already fully covered shallow protocol paths to the still-uncovered deep protocol logic branches.

[0054] In one DoIP protocol test embodiment, the DoIP protocol configuration file and normal communication logs of the device under test are imported into the protocol knowledge base. Based on the corresponding protocol template of ISO 13400-2, vehicle discovery messages, route activation messages, and diagnostic message transmission messages are identified, and legitimate normal messages are extracted as seed messages. The protocol field parser divides the DoIP message into a four-byte header, source logical address field, destination logical address field, and payload field, and identifies the length field, type field, and payload field and their constraints.

[0055] Based on priority weights and field coverage bitmaps, a DoIP seed packet is selected from the seed queue. Its protocol fields are concatenated and divided into a first data block and a second data block. Structured mutation is then performed using two to sixteen rounds of Feistel iterations. Each round follows the following procedure: ; The corresponding round key is derived, and candidate mutation fields are generated through field swapping, PCG random offset injection, and S-box nonlinear permutation. After completing the Feistel iteration, the mutation results are mapped back to the DoIP protocol fields according to the reverse process of field grouping, and the consistency between the total message length field and the actual payload length is verified. When the two are inconsistent, the total message length field is updated, and then the DoIP mutation test message is reassembled.

[0056] DoIP mutation test messages are sent to the device under test (DUT) via the vehicle Ethernet physical layer. DoIP ACK or DoIP NACK messages, response delay, TCP connection status, CAN side status messages, diagnostic responses, and program execution coverage data are collected. When using [1ms, 50ms] as the response delay safety interval, the p-fault tolerance counter is updated based on the output barrier function value. When the fault counter reaches the (p) value set according to the DUT's ASIL level, a corresponding fault report is output.

[0057] When a DoIP mutation test message triggers a new code base block, the DoIP mutation test message is added to the seed queue and its priority weight is increased. Then, the mutation round number, PCG seed distribution, and weight of mutation operation type in the next round of the Feistel network are adjusted according to the code branch coverage increment.

[0058] In summary, the intelligent connected vehicle Ethernet fuzzy testing method in the above embodiments of the present invention identifies the protocol type, field boundaries, field semantics, field constraint relationships, and state transition relationships of in-vehicle Ethernet packets through a protocol knowledge base, providing a data foundation for seed packet selection and protocol-aware block-based structured mutation. By performing block-based structured mutation on the byte sequence to be mutated formed by the protocol fields, and employing different implementation methods such as Feistel network mutation or hash block mutation, it improves mutation diversity and data diffusion while adapting to different computing power conditions and testing requirements. Based on the field semantics, it verifies and corrects the length, checksum, legal value range, field dependency, and state transition of candidate mutation fields and their associated fields, enabling the mutation results to be reconstructed to conform to the basic structure of the target protocol. The test messages are structured to reduce the number of test messages that are directly discarded in the early stages of protocol parsing, thereby improving the accessibility of deep protocol logic. A safe zone is established by combining communication response data, device status data, and program execution coverage data. Deviations from continuous safe zones are judged by output barrier functions and fault tolerance counts, which can reduce false alarms caused by occasional network jitter or response timeouts and identify safety-critical faults that do not manifest as program crashes. Furthermore, the seed queue, seed scheduling priority, and block structured variation parameters are updated based on code coverage increments and safety-critical fault detection results, forming a coverage feedback-driven closed-loop testing process. This improves the automation level, effective testing rate, path coverage capability, fault determination accuracy, and test result reproducibility of multi-protocol automotive Ethernet fuzz testing.

[0059] Example 2 like Figure 2 As shown, the second embodiment of the present invention provides an Ethernet fuzz testing system for intelligent connected vehicles, comprising: The parsing module 100 is used to obtain the protocol configuration information and normal communication data of the device under test, and to perform protocol parsing on the vehicle Ethernet packets in the normal communication data based on the protocol knowledge base to obtain the seed packet and the field boundaries, field semantics and constraint relationships of each protocol field in the seed packet; The mutation module 200 is used to select target seed messages from the seed queue, group the target seed messages according to the field boundaries, perform multiple rounds of structured mutation on the grouping results, and use a permutation congruent random number generator to generate random parameters required for each round of structured mutation to obtain candidate mutation fields. The correction module 300 is used to determine the protocol constraint verification rule corresponding to the candidate mutation field based on the field semantics, and to perform protocol constraint verification and associated field correction on the candidate mutation field based on the protocol constraint verification rule and the constraint relationship, and to reassemble the verified mutation field into a mutation test message. The execution module 400 is used to inject the mutation test message into the device under test via the vehicle Ethernet, and to collect the testable output data and execution coverage data corresponding to the device under test. The monitoring module 500 is used to calculate the output barrier function value based on the safety area pre-established for the measurable output data, and to determine whether the device under test has experienced a safety-critical fault based on the output barrier function value and the preset fault tolerance number.

[0060] like Figure 3 As shown, in one specific deployment method, the system adopts a four-layer architecture, including a hardware layer, a protocol parsing layer, a fuzzing engine layer, and a security monitoring and barrier function layer from bottom to top. The parsing module is deployed in the protocol parsing layer; the mutation module and the correction module are deployed in the fuzzing engine layer; the execution module sends mutation test messages to the device under test and collects test data through the hardware layer; the monitoring module and the update module are deployed in the security monitoring and barrier function layer.

[0061] The hardware layer includes the host computer, Ethernet switch, device under test (DUT), CAN gateway, and corresponding physical layer interfaces. The host computer uses an x86 or ARM architecture computing platform, such as an Intel Core i7 processor, Intel Core i9 processor, or NVIDIA Jetson Orin platform, and runs an Ubuntu or real-time Linux operating system to perform protocol parsing, test case generation, security monitoring, and feedback control.

[0062] The Ethernet switch supports one or both of the 100BASE-T1 and 1000BASE-T1 automotive Ethernet physical layers and provides a Layer 2 switching channel between the test host computer and the device under test (DUT). The Ethernet switch also supports port mirroring to monitor complete communication traffic during testing. The DUT runs one or more protocol stacks of DoIP, SOME / IP, TSN, and UDPNM and connects to the program execution coverage acquisition unit via a JTAG debug interface or an SWD debug interface.

[0063] The CAN gateway supports the CAN FD protocol for acquiring status messages, diagnostic responses, or error indicator signals output by the device under test (DUT) via a traditional vehicle bus. The physical layer interface includes one or more of the following: 100BASE-T1, 1000BASE-T1, CANFD, FlexRay, and OBD. Depending on testing needs, power consumption detection and electromagnetic radiation detection interfaces can also be configured to acquire data on power consumption changes and electromagnetic radiation anomalies in the DUT.

[0064] The protocol parsing layer includes a protocol knowledge base and a protocol field parser. The protocol knowledge base stores the protocol templates, field semantics, valid field value ranges, field constraints, and state transition rules for each automotive Ethernet protocol. The protocol field parser is used to match protocol configuration information and normal communication logs with the protocol templates in the protocol knowledge base, identify the protocol type, and extract each protocol field.

[0065] The fuzz testing engine layer includes the Feistel network mutation engine, the PCG unbiased random generator, the test case scheduler, the hybrid mutation orchestrator, and the protocol constraint correction unit. These components are used to complete target seed selection, protocol field grouping, multi-round structured mutation, random parameter generation, protocol constraint verification, correlation field correction, and mutation test message reassembly.

[0066] The safety monitoring and barrier function layer is used to establish safety regions, calculate output barrier function values, perform p-fault tolerance verification, generate fault reports, and update the seed queue and mutation parameters based on code branch coverage increments and safety-critical fault detection results.

[0067] The parsing module 100, mutation module 200, correction module 300, execution module 400, and monitoring module 500 can be software functional modules running on the same test host computer, or they can be deployed separately on test control equipment, message generation equipment, response acquisition equipment, and program execution coverage acquisition equipment. The modules transmit seed messages, protocol parsing results, mutation parameters, mutation test messages, communication response data, device status data, and program execution coverage data through a shared storage area, message queue, or network communication interface, thereby collaboratively executing the aforementioned intelligent connected vehicle Ethernet fuzzy testing method.

[0068] The embodiments described above merely illustrate specific implementation methods of this application, and while the descriptions are detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for Ethernet fuzz testing of intelligent connected vehicles, characterized in that, Includes the following steps: Obtain the protocol configuration information and normal communication data of the device under test, and perform protocol parsing on the vehicle Ethernet packets in the normal communication data based on the protocol knowledge base to obtain the seed packet and the field boundaries, field semantics and constraint relationships of each protocol field in the seed packet; Select target seed messages from the seed queue, group the target seed messages according to the field boundaries, perform multiple rounds of structured mutation on the grouping results, and use a permutation congruent random number generator to generate the random parameters required for each round of structured mutation to obtain candidate mutation fields; Based on the semantics of the field, the protocol constraint verification rules corresponding to the candidate mutation fields are determined, and the protocol constraint verification rules and the constraint relationships are used to perform protocol constraint verification and related field correction on the candidate mutation fields. The verified mutation fields are then reassembled into mutation test messages. The mutation test message is injected into the device under test via the vehicle Ethernet, and the testable output data and execution coverage data corresponding to the device under test are collected. The output barrier function value is calculated based on the pre-established safety zone for the measurable output data, and the safety-critical fault of the device under test is determined based on the output barrier function value and the preset fault tolerance number.

2. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 1, characterized in that, The protocol knowledge base stores protocol templates, field constraint relationships, and state transition rules corresponding to one or more protocols among DoIP, SOME / IP, TSN, and UDPNM. The semantics of the protocol fields include length, checksum, type, and payload fields.

3. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 1, characterized in that, The step of selecting the target seed message from the seed queue specifically includes: Extract legitimate messages that conform to the corresponding protocol structure and protocol status from the normal communication log as seed messages, and write various sub-messages along with their protocol type, field boundaries, field semantics, constraint relationships, field coverage bitmap and priority weight into the seed queue; The target seed packet is selected from the seed queue based on the priority weight and the field coverage bitmap.

4. The Ethernet fuzz testing method for intelligent connected vehicles according to claim 1, characterized in that, Structured mutation employs a data block iterative mutation strategy based on the Feistel network. The specific steps of the data block iterative mutation strategy include: The protocol fields are concatenated according to their arrangement order in the target seed message to obtain the byte sequence to be mutated, and the byte sequence to be mutated is divided into a first data block and a second data block according to the byte length. Feistel iteration is performed on the first data block and the second data block according to the preset number of mutation rounds. In each Feistel iteration, the second data block obtained in the previous iteration is used as the first data block obtained in the current iteration. The second data block obtained in the previous iteration and the round key of the current iteration are input into the round function. The first data block obtained in the previous iteration is bitwise XORed with the output of the round function to obtain the second data block obtained in the current iteration. The calculation expressions for the first and second data blocks after this iteration are as follows: ； ； in, and These represent the first and second data blocks obtained in the previous iteration, respectively. and These represent the first and second data blocks obtained in this iteration, respectively. F represents bitwise XOR. Represents the round function. This represents the round key for the i-th round; After completing the Feistel iteration, the resulting obfuscated byte sequence is mapped back to the candidate variant field according to the reverse process of field segmentation.

5. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 4, characterized in that, The round function includes one or more of the following: field swap sub-operation, random offset injection sub-operation, and nonlinear permutation sub-operation. The hybrid mutation orchestrator selects the corresponding sub-operation according to the current operation weight, and when multiple sub-operations are selected, they are executed in the order of field swap, random offset injection, and nonlinear permutation.

6. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 5, characterized in that, The permutation congruential random number generator uses a 128-bit internal state and generates an internal state sequence through linear congruential operations, wherein the internal state is updated according to the following formula: ； In the formula, This indicates the internal state before the update. This represents the updated internal state, where M and C are preset large prime constants; At each output, the internal state is obfuscated using a nonlinear permutation function, and the output permutation relationship is expressed as: ； In the formula, For output, This represents the current internal state. This indicates a circular right shift operation. Indicates a right shift operation, S and This indicates the PCG output permutation parameters. This represents the intermediate state obtained by XOR shifting the internal state; Each round's key is derived from the initial seed of the permutation congruent random number generator and the current round number, based on the following formula: ； In the formula, This represents the initial seed of the PCG unbiased random generator, and i represents the round number of the current Feistel iteration. This represents the round operation function.

7. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 1, characterized in that, The steps for protocol constraint verification and associated field correction specifically include: Based on the semantics of the candidate mutation fields, the corresponding protocol constraint verification rules are matched from the protocol knowledge base; Verify the consistency between the length field and the actual load length, and the consistency between the checksum field and the load content; When the candidate mutation field violates the corresponding protocol constraints, the corresponding length field, checksum field or other related fields are updated according to the actual payload length or payload content. After verification and correction, the candidate mutation fields and associated fields are reorganized according to the message structure of the target protocol to obtain the mutation test message.

8. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 1, characterized in that, The measurable output data is determined based on the collected communication response data and device status data; The communication response data includes DoIP ACK messages, DoIP NACK messages, SOME / IP Response messages, SOME / IP Error messages, response delays, and TCP connection state changes; The device status data includes the status message, diagnostic response, and error indicator signal output by the device under test via the CAN bus; The security constraints corresponding to the security zone include a valid response message format, a response delay within a preset range, and the return of the correct service identifier.

9. The Ethernet fuzzy testing method for intelligent connected vehicles according to claim 1, characterized in that, The execution coverage data is collected through the JTAG debugging interface, SWD debugging interface, or software instrumentation. The current program execution coverage data is compared with the historical program execution coverage data to obtain the code branch coverage increment; When the mutation test message triggers a new code block or a new branch execution path, the mutation test message is written as a new seed into the seed queue, and the priority weight of the new seed is increased. Based on the incremental code branch coverage and the results of safety-critical fault detection, the mutation round number, PCG seed distribution, weight of mutation operation type, S-box selection, seed mutation probability, and mutation intensity of the Feistel network are adjusted, and the adjusted mutation parameters are used in the next round of testing.

10. A system for implementing the Ethernet fuzz testing method for intelligent connected vehicles according to any one of claims 1-9, characterized in that, include: The parsing module is used to obtain the protocol configuration information and normal communication data of the device under test. Based on the protocol knowledge base, it performs protocol parsing on the vehicle Ethernet packets in the normal communication data to obtain the seed packet and the field boundaries, field semantics and constraint relationships of each protocol field in the seed packet. The mutation module is used to select target seed packets from the seed queue, group the target seed packets according to the field boundaries, perform multiple rounds of structured mutation on the grouping results, and use a permutation congruent random number generator to generate random parameters required for each round of structured mutation to obtain candidate mutation fields. The correction module is used to determine the protocol constraint verification rules corresponding to the candidate mutation fields based on the field semantics, and to perform protocol constraint verification and related field correction on the candidate mutation fields based on the protocol constraint verification rules and the constraint relationship, and to reassemble the verified mutation fields into mutation test messages. The execution module is used to inject the mutation test message into the device under test via the vehicle Ethernet, and to collect the testable output data and execution coverage data corresponding to the device under test. The monitoring module is used to calculate the output barrier function value based on the safety zone pre-established for the measurable output data, and to determine whether the device under test has experienced a safety-critical fault based on the output barrier function value and the preset fault tolerance number.

Images