Automatic vulnerability mining method for Internet of Vehicles protocol

Abstract

The invention relates to an automatic vulnerability mining method for an Internet of Vehicles protocol. Comprising the following steps: establishing a test system, selecting a test target protocol and configuring corresponding test parameters: starting a protocol communication module in the test system according to configuration, establishing connection with target equipment, and obtaining initial seed data from the target equipment after connection; a variation strategy engine in the test system performs various random tampering on the initial seed data to generate variation test cases, and the variation test cases are sequentially sent to target equipment by a test case management mechanism; performing exception monitoring and strategy optimization: repeatedly executing the step 3 and the step 4 until a preset test termination condition is met; and after the test is finished, the system integrates all test results and generates a detailed vulnerability report. According to the method, the protocol stack compatibility is good, the multi-node collaborative test capability is high, the automation level and accuracy of Internet of Vehicles protocol vulnerability mining can be effectively improved, and the active detection capability is provided for system security.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data transmission, and particularly relates to a vehicle networking protocol automatic vulnerability mining method. TECHNICAL BACKGROUND

[0002] With the rapid development of vehicle networking technology, the network communication channels of vehicles are increasing, which also brings new security challenges. The security of vehicle networking protocols is directly related to the operation safety of vehicles and the protection of user privacy. Current industry practices show that traditional testing methods have the defect of lagging behind: firstly, the detection mechanism based on known attack characteristics cannot cope with zero-day vulnerabilities; secondly, static analysis technology is difficult to cover the timing security problems of protocol state machines. Therefore, it is urgent to build a vulnerability mining system with active defense characteristics. In order to improve the active security of vehicle networking systems, it is necessary to design and develop vehicle networking vulnerability mining tools to make early discovery and warning of vehicle communication security.

[0003] In the article "Fuzzing Test Technology for Vehicle Networking LTE-V2X Protocol (Liu Yichen. Shandong University, 2022. DOI: 10.27272 / d.cnki.gshdu.2022.003734.)", the given solution is designed for IP-based protocols or specific protocols, and its technical path can be divided into the following steps: 1. Protocol reverse and standardization processing 2. Generate legal test cases and send 3. Get abnormal messages by mutating legal messages and send 4. Monitor the process and locate the crash. There are the following problems:

[0004] 1. Insufficient protocol stack compatibility: This solution relies on srsLTE physical layer implementation, but does not fully adapt to the SPS (Semi-Persistent Scheduling) resource allocation mechanism defined in C-V2X standard (such as 3GPP TR 37.885), resulting in the inability to accurately simulate the channel characteristics (such as Doppler shift, delay spread) in V2X high dynamic scenarios.

[0005] 2. Insufficient multi-node collaborative testing capability: The current testing framework only supports single device (OBU or RSU) testing, and does not consider the timing problems (such as SPAT traffic light state misjudgment caused by message conflict) in V2X multi-vehicle cooperative communication.

[0006] 3. Tool chain efficiency and standardization defects: Wireshark plugins need to be customized and compiled, High maintenance costs .

[0007] 4、Solution is designed only for single protocol basic communication scene, without considering the multi-protocol heterogeneous fusion environment of Internet of Vehicles (such as cross-protocol interaction scene of CAN bus, BLE Bluetooth and DOIP Ethernet), which leads to the inability to find security defects of protocol data flow conversion (such as permission verification inconsistency of CAN message and BLE instruction). At the same time, since the mutation strategy only relies on random tampering and simple format mutation, without combining protocol semantic logic (such as ID priority field of CAN message and GATT service UUID format rule of BLE) for directional mutation, the test coverage of the key fields of the protocol is insufficient, and it is difficult to trigger deep logic vulnerabilities (such as state machine jump exception and permission boundary overflow). SUMMARY

[0008] The purpose of the present application is to provide a kind of Internet of Vehicles protocol automated vulnerability mining method, to overcome the protocol stack compatibility of prior art, multi-node collaborative test capability is insufficient, maintenance cost is high and the limitation problem of single function, there is also the problem of standardization and compatibility defects.

[0009] To achieve the above purpose, the technical scheme adopted by the present application is: a kind of Internet of Vehicles protocol automated vulnerability mining method, comprising the following steps:

[0010] Step one, build test system, select the target protocol of test and configure corresponding test parameters:

[0011] The test system includes protocol communication module and fuzzy test module, the fuzzy test module includes mutation strategy engine, test case management mechanism, real-time feedback mechanism, genetic optimization strategy, exception monitoring mechanism and result analysis module;

[0012] Step two, according to the configuration, start the protocol communication module in the test system, establish connection with target device, obtain initial seed data from target device after connection;

[0013] Step three, the mutation strategy engine in the test system carries out various random tampering on initial seed data, generates mutation test case, and the mutation test case is sent to the target device by the test case management mechanism in turn;

[0014] Step four, exception monitoring and strategy optimization:

[0015] In the process of sending test case, the exception monitoring mechanism in the system monitors the response of the target device in real time and continuously, and once the abnormal behavior is detected, the result analysis module will analyze the exception log and preliminarily locate the possible vulnerability field or processing logic. Then, the mutation strategy engine adjusts the mutation strategy according to the monitoring feedback, and the mutation strategy engine adjusts the genetic optimization strategy according to the real-time feedback mechanism monitoring feedback for strategy optimization.

[0016] Step five, repeat step three and step four until the preset test termination condition is reached.

[0017] Step six, after the test, the system integrates all test results to generate a detailed vulnerability report.

[0018] Further, the test termination condition of step five is the test duration or the number of vulnerabilities found.

[0019] Further, in step four, the abnormal behavior of the target device includes communication interruption, ECU crash or response timeout abnormal phenomenon; continuously monitor the response change of the target system to the malformed packet.

[0020] Further, the vulnerability report contains descriptions of abnormal conditions found, triggering steps, related packet information, and repair suggestions, and supports export in CSV or JSON format.

[0021] Further, the mutation strategy engine is a dynamic mutation strategy engine based on protocol semantics and state machine.

[0022] Further, the real-time feedback mechanism is a real-time feedback mechanism combining path coverage and branch coverage.

[0023] Further, the test parameters in step one include the bit flip probability of mutation and the maximum length of field insertion / deletion.

[0024] Further, the bit flip probability is set to 10%-30%.

[0025] Compared with the prior art, the present application has the following beneficial effects:

[0026] 1. Protocol stack compatibility: In step one, a multi-protocol stack scheduling model and a unified hardware adaptation layer are used to simulate the SPS (Semi-Persistent Scheduling) resource allocation mechanism in the C-V2X standard, restore the channel characteristics in high dynamic scenarios, dynamically adjust the resource reservation period and scheduling window, and accurately simulate the channel characteristics (such as Doppler shift, delay spread) in V2X high dynamic scenarios. At the same time, it supports the communication interface adaptation of multiple types of protocols such as CAN, BLE, DOIP, etc., so the protocol stack compatibility is good; adapting the C-V2X SPS resource allocation mechanism, the simulation accuracy of high dynamic scenarios is improved from 65% to 92%.

[0027] 2. Multi-node cooperative testing capability: In step one, a multi-node cooperative testing framework is used, combined with the concurrent control mechanism (multi-threading / multi-processing) of step four, to realize communication synchronization, test timing control and result comparison between multiple devices of OBU and RSU, effectively find timing problems (such as SPAT signal light state misjudgment caused by message conflict) in cross-node communication, so the multi-node cooperative testing capability is strong. Multi-threading cooperative testing makes the scene coverage from 30% to 75%, and the test time is shortened by 40%.

[0028] 3. Tool chain efficiency and standardization without defects:

[0029] In the genetic optimization strategy adopted, a standardized ASN.1 encoding and decoding tool chain (such as asn1c compiler) is used to automatically generate protocol data structures and encoding and decoding logic, replacing the manual implementation process, while providing a Wireshark plugin templated interface to avoid frequent recompilation of custom plugins, reduce deviation from ETSI / 3GPP standards, and reduce the need for customized compilation of templated plugins, thereby reducing maintenance and deployment costs. Therefore, the tool chain efficiency and standardization have no defects. asn1c automatic encoding and decoding eliminates ETSI standard deviation, and the maintenance cost of Wireshark plugins is reduced by 90%.

[0030] 4. Dynamic switching mode for different protocol types, and through the coverage feedback optimization mutation strategy, the vulnerability discovery rate is improved by 40%, the test case coverage rate is improved by 60%, and the false negative rate is reduced by 35%; the average vulnerability discovery time is shortened from 60 minutes to 30 minutes; the present application effectively improves the automation level and accuracy of vehicle networking protocol vulnerability mining, and provides active detection capability for system security. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical scheme and advantages of the application clearer, the application will be described in detail below in combination with embodiments.

[0032] The present application provides a kind of vehicle networking protocol automatic vulnerability mining method, comprising the following steps:

[0033] Step one, build test system, select the target protocol of test and configure corresponding test parameters:

[0034] The test system includes protocol communication module and fuzzy test module, the fuzzy test module includes mutation strategy engine, test case management mechanism, real-time feedback mechanism, genetic optimization strategy, abnormal monitoring mechanism and result analysis module.

[0035] The protocol communication module includes three types of communication protocols, i.e., a vehicle-mounted bus, a wireless radio frequency and an Ethernet, supports CAN, LIN, FlexRay, DSRC, C-V2X, BLE, Wi-Fi and Ethernet communication units to access different types of vehicle-mounted networks, and introduces a unified hardware adaptation layer to realize automatic identification and parameter configuration of multiple radio frequency / network devices such as HackRF, Ubertooth and Proxmark3. The architecture not only improves the breadth and depth of protocol support, but also significantly reduces the threshold of multi-device collaborative testing, and adapts to the requirements of heterogeneous links and physical layer timing accuracy in complex vehicle networking test scenarios. The protocol in the embodiment includes a controller area network CAN, a Bluetooth low energy BLE or a diagnostic protocol DOIP, and the embodiment is aimed at the controller area network CAN.

[0036] The mutation strategy engine is a dynamic mutation strategy engine based on protocol semantics and state machine driving. The dynamic mutation strategy engine intelligently generates high-quality abnormal test cases for different protocol scenarios by performing bit flipping, field insertion, state mutation and other operations, and is used for the execution flow inside the engine.

[0037] The real-time feedback mechanism is a real-time feedback mechanism combining path coverage and branch coverage, uses a genetic optimization strategy to screen high-value seed samples, and constructs an automatically evolved sample library. The abnormal monitoring mechanism captures reset, communication interruption and memory crash of the target system in real time, and combines log and signal feedback to locate the abnormal path.

[0038] The test parameters include the bit flipping probability of mutation and the maximum length of field insertion / deletion, and the bit flipping probability is 20% in the embodiment. These parameters can be dynamically adjusted according to the field length of the selected protocol to ensure the rationality of the mutated input to maintain the protocol format. The purpose of this step is to determine the test scene and the mutation strength, and to make good initialization configuration for subsequent fuzzy testing.

[0039] Step two: according to the configuration, start the protocol communication module in the test system, establish a connection with the target device, and obtain initial seed data from the target device after the connection. For example, for the CAN protocol, use SocketCAN to start CAN bus listening; for the BLE protocol, use the Bluetooth API to connect the vehicle-mounted Bluetooth device; for the DOIP protocol, establish a diagnostic connection through the Ethernet interface. After the communication is established, the system starts to capture normal communication data packets as initial seed data seed for the mutation strategy engine. This stage is responsible for opening the communication link between software and hardware, and provides effective input samples for subsequent fuzzy testing.

[0040] Step three: The mutation strategy engine in the test system performs various random tampering on the initial seed data to generate mutation test cases, which are sent to the target device by the test case management mechanism. Common tampering includes bit-flip on the ID field in the CAN message, random byte replacement on the data field, and insertion of abnormal data based on the selection of "attention field" according to security risk analysis. This method of mutation fuzz testing based on the fuzz testing module helps to discover the processing defects of the system for abnormal messages.

[0041] Step four: Abnormality monitoring and strategy optimization

[0042] During the sending of test cases, the abnormality monitoring mechanism in the system continuously captures and monitors the response of the target device in real time. Once abnormal behavior is detected, the result analysis module will analyze the abnormal logs and preliminarily locate the possible vulnerability fields or processing logic. The abnormal behavior of the target device includes communication interruption, ECU crash, or response timeout.

[0043] Subsequently, the mutation strategy engine adjusts the mutation strategy according to the monitoring feedback. The mutation strategy engine adjusts the genetic optimization strategy according to the real-time feedback mechanism monitoring feedback, performs strategy optimization, such as increasing the mutation frequency of the abnormal field that has been triggered or changing the mutation mode.

[0044] Step five, repeat steps three and four until the preset test termination condition is reached, the test termination condition is the test duration or the number of vulnerabilities discovered.

[0045] Step six: After the test is completed, the system integrates all test results to generate a detailed vulnerability report. The vulnerability report includes descriptions of discovered abnormal conditions, triggering steps, related packet information, and repair suggestions, and supports export in CSV or JSON format, facilitating subsequent analysis and reproduction by users. Through the report, testers can intuitively understand the test coverage and discovered security issues, thereby improving the security and reliability of the vehicle networking system.

[0046] The following is the test process of the present application, including five stages:

[0047] I. Test preparation phase (T0-T10 minutes): The goal of this phase is to verify the security of typical protocols for the Internet of Vehicles, focusing on the CAN protocol (Controller Area Network), the BLE protocol (Bluetooth Low Energy), and the DOIP protocol (Diagnosis Communication Protocol), covering three types of communication scenarios: vehicle bus, wireless radio frequency, and Ethernet. The test objects include vehicle electronic control units (ECUs), vehicle Bluetooth devices (such as Bluetooth keys), and Ethernet diagnostic interfaces, aiming to discover vulnerabilities in protocol processing logic (such as crashes caused by malformed packets, communication anomalies, etc.) through automated fuzz testing.

[0048] (I) First, perform test system setup and hardware configuration. Hardware environment deployment includes protocol communication module deployment and fuzz testing host configuration:

[0049] The protocol communication module is deployed as follows:

[0050] a) Bus communication unit: Configure CANable device through SocketCAN driver, enable CAN bus listening (support CAN2.0A / B standard, baud rate 500kbps), connect vehicle CAN bus physical interface (such as OBD-II interface).

[0051] b) Radio communication unit: Deploy UbertoothOne Bluetooth sniffer (support BLE5.0 protocol) and HackRF One radio frequency device for vehicle Bluetooth communication capture and radio frequency signal simulation, respectively.

[0052] c) Ethernet communication unit: Connect vehicle diagnostic Ethernet port through Gigabit Ethernet interface, configure static IP address (such as 192.168.1.100) to support DOIP protocol communication.

[0053] The fuzz testing host is configured with Ubuntu 22.04 operating system, Intel Core i7 processor, 32GB memory, and 1TB SSD storage, connected to the above hardware devices through USB 3.0 interface, ensuring low latency (≤10ms) of communication link.

[0054] (II) Software and tool chain initialization, start protocol communication module and fuzz testing module of test system, load preset protocol parsing library (such as SocketCAN library for CAN protocol, BlueZ library for BLE protocol, Scapy library for DOIP protocol). Enable asn1c compiler to automatically generate protocol data structure and encoding / decoding logic, ensuring compatibility with ETSI and 3GPP standards. Deploy Wireshark plugin templated interface, no need to customize compilation to real-time parse CAN, BLE, DOIP packets, reduce tool maintenance cost.

[0055] Among them, in terms of test parameter configuration, the following parameter settings are completed through the system configuration interface to ensure that the test scene is comprehensive and conforms to the actual vehicle networking communication characteristics:

[0056] a) Protocol and communication parameters, as shown in the following table:

[0057]

[0058] Among them, the fuzzy test parameters are as follows:

[0059] a) Mutation strategy: bit flip probability 20%, field insertion / deletion maximum length 8 bytes, enable genetic algorithm optimization mutation seed (iteration number 100 rounds).

[0060] b) Abnormal monitoring threshold: communication interruption judgment time 500ms, ECU crash log keywords "reset" "crash", memory leakage threshold 10MB / 5min.

[0061] Among them, in the multi-node cooperative configuration, the communication scene of simulating 3 OBUs (on-board units) and 1 RSU (roadside unit) is simulated, the message synchronization delay between nodes is 100ms, and the SPS (semi-persistent scheduling) resource allocation mechanism is enabled to simulate the high dynamic channel characteristics (such as Doppler shift, delay spread).

[0062] (Three), initial seed data collection preparation:

[0063] a) Communication link verification, the system automatically performs link connectivity test: send a preset normal message (such as CAN door control instruction 0x1A4, BLE device pairing request, DOIP diagnostic session establishment request) to the target device, and confirm that the target device responds normally (response time ≤200ms).

[0064] b) Seed data capture initialization, start packet capture function, real-time monitor CAN bus, BLE communication link and Ethernet interface, and prepare to collect normal communication data packets as initial seed data (seed). The capture rule is set as: only save the messages containing valid checksum and conforming to the protocol format, to ensure the validity of the seed data (efficiency ≥95%).

[0065] (Four), stage verification and readiness confirmation, perform stage check at T10 minutes to ensure:

[0066] a) The hardware device connection is normal, there is no communication interruption or driver error (verify device status by "dmesg" command).

[0067] b) The software module runs stably, the fuzzy test engine, mutation strategy engine and abnormal monitoring mechanism are in active state (process CPU occupancy rate ≤30%).

[0068] c) The initial seed data capture link is open, and real-time reception of normal communication messages from the target device (such as CAN bus receiving messages ≥ 50 per second) is possible.

[0069] d) After confirming that all conditions are met, the system enters the "ready state" and waits for the test case generation and execution phase to start.

[0070] II. Test execution phase (T10-T180 minutes)

[0071] (I) Communication establishment and initial seed data acquisition (T10-T25 minutes)

[0072] Protocol communication link establishment and multi-protocol connection initialization:

[0073] a) CAN protocol: Execute the sudoiplinksetcan0uptypecanbitrate500000 command through the SocketCAN interface to start CAN bus listening, bind the vehicle OBD-II interface and the test host, and establish a physical layer communication link. The system automatically sends initialization messages (such as 0x001 standard frames) to verify the effectiveness of the connection, and confirms that the target ECU (such as the body control module) responds normally (response time ≤ 200 ms).

[0074] b) BLE protocol: Call the Bluetooth API (BlueZ library) to scan for vehicle Bluetooth devices (such as Bluetooth key modules), establish GATT connection through MAC address (such as 7C:B0:64:8F:02:91), and enable notification function to receive device status messages.

[0075] c) DOIP protocol: Send a TCP connection request to the target device (such as a diagnostic gateway) through the Ethernet interface, port number 6801, complete the handshake, establish a diagnostic session, and confirm support for ISO14229-3 standard diagnostic services.

[0076] (II) Perform initial seed data capture, and the system enters the normal and abnormal monitoring mechanism to continuously capture legal data packets from the target device:

[0077] For CAN bus, capture valid messages containing door control (0x1A4), light adjustment (0x1B0), etc. Collect 200 complete communication sequences as seed data, covering data frames, remote frames, etc.

[0078] For BLE protocol, record the GATT characteristic value changes of device pairing and instruction transmission (such as unlock instruction 0x01), and obtain 150 characteristic value write / read messages.

[0079] For DOIP protocol, capture the packets of diagnostic session establishment (0x01), data transmission (0x02) and other processes, and store 80 standard diagnostic sequences.

[0080] Seed data is automatically stored in the test case management mechanism and marked as "initial valid sample".

[0081] (Three): Generation and sending of mutation test cases (T25-T150 minutes), mutation strategy engine is executed, the process is as follows:

[0082] a) Dynamic mutation rule application

[0083] The mutation strategy engine starts multi-dimensional mutation operation based on the initial seed data:

[0084] Basic mutation: Perform bit flipping on the CAN message ID field (e.g. flip the 3rd bit of 0x1A4 to generate 0x1A0), perform random byte replacement on the data field (e.g. replace 0x01 with 0xFF), insert super-long bytes into BLE feature values (e.g. append 16 bytes of random data after an 8-byte instruction), and perform out-of-bound modification on the DOIP message length field (e.g. change 0x08 to 0xFF).

[0085] Semantic-driven mutation: Implement targeted mutation on key fields of the protocol (e.g. priority bit of CAN, UUID format of BLE, diagnostic service ID of DOIP), such as modifying the RTR bit (remote transmission request bit) of CAN message to an invalid value or tampering with the service type identifier of BLE UUID.

[0086] Genetic algorithm optimization: Combine real-time feedback mechanism to increase the mutation weight of seeds that trigger abnormal responses (e.g. cause

[0087] ECU delayed response messages), generate the next generation of test cases through crossover and mutation operations, and retain 1000 high-value mutation samples after 100 iterations.

[0088] b) Multi-node collaborative test scheduling

[0089] Enable OBU and RSU multi-node simulation framework, achieve through multi-thread concurrent control:

[0090] Simulate 3 OBU nodes sending cooperative messages to RSU (e.g. vehicle location information in V2X environment), introduce timing conflicts when sending mutated messages (e.g. message sending interval of node 1 and node 2 ≤ 50ms), and test the processing capability of the target device for message conflicts.

[0091] For CAN bus, simulate the scenario of multiple ECUs sending messages simultaneously to verify whether there are vulnerabilities in the bus arbitration mechanism; for BLE protocol, simulate multiple device connection requests to test the device connection management logic.

[0092] c) Test case sending and execution

[0093] The test case management mechanism sends variation messages in batches: 100 variation test cases are sent in each batch, with an interval of 100 ms, to ensure that the target device has sufficient processing time. For the CAN protocol, malformed frames are sent to the can0 interface through the cansend tool; for the BLE protocol, the gatttool is called to write the variation characteristic value; for the DOIP protocol, malformed diagnostic messages are constructed and sent through Scapy.

[0094] (Four), abnormal monitoring and strategy optimization (T150-T170 minutes)

[0095] The abnormal monitoring mechanism monitors the target device state through multiple dimensions:

[0096] In terms of communication state monitoring:

[0097] For the CAN bus, error frames (such as format errors, CRC errors) are captured through candump, and when the error frame proportion ≥ 5%, it is marked as abnormal; monitor whether the ECU appears bus offline (response time ≥ 1s).

[0098] For the BLE protocol, record the connection disconnection event (disconnection reason code is not normal disconnection 0x05), monitor whether the device appears broadcast storm or connection rejection exception.

[0099] For the DOIP protocol, monitor whether the TCP connection is abnormally closed, and whether the diagnostic session is unresponsive (more than 5s without reply).

[0100] In terms of system behavior analysis:

[0101] Read the ECU status code through the vehicle diagnostic interface, if the fault codes such as "0x05 (internal error)" "0x0A (memory overflow)" appear, trigger the abnormal mark.

[0102] Real-time sampling (every 100ms) is performed on the CPU occupancy rate and memory usage of the target device, if the memory surge ≥ 20MB or the CPU occupancy rate continues ≥ 90%, it is determined as a potential vulnerability trigger.

[0103] After that, the strategy is dynamically optimized, feedback-driven adjustment, and the result analysis mechanism attributes the abnormal event: when the CAN bus crashes due to long data frames (> 8 bytes), the variation strategy engine increases the variation frequency of the data length field from 20% to 40%; when the BLE device disconnects due to UUID format error, increase the bit flipping and format tampering operations on the UUID field to generate more malformed format samples.

[0104] Based on the optimized strategy, a new batch of test cases (500) is generated, and the send-monitoring process is repeated, focusing on covering the field combinations that have triggered exceptions, such as the "ID+data length" combination of CAN and the "feature value length+content" combination of BLE.

[0105] IV. Test termination and data recording (T170-T180 minutes)

[0106] When any of the following conditions are met, the system terminates the test:

[0107] a) Test cases are sent (cumulative 8000, covering preset variation types).

[0108] b) No new exceptions are found for 30 consecutive minutes (confirming that high-value variation paths have been covered).

[0109] c) The target device experiences an unrecoverable failure (such as ECU complete offline), triggering an emergency stop mechanism.

[0110] Among them, the process data is recorded:

[0111] The system automatically records test data throughout the process:

[0112] a) Variation case details (original seed, variation type, sending time).

[0113] b) Exception event log (exception type, triggering message, device state snapshot).

[0114] c) Coverage statistics (protocol field coverage 92%, state machine path coverage 88%).

[0115] Data is uniformly stored in the result analysis module, providing original basis for subsequent report generation.

[0116] V. Test results and analysis

[0117] This test targets the CAN, BLE, and DOIP protocols of the Internet of Vehicles, with the following core coverage indicators:

[0118] a) Protocol scenario coverage: covering CAN bus control (doors, lights), BLE device interaction (pairing, instruction transmission), and DOIP diagnostic session full process, involving 12 ECU nodes and 23 BLE feature values, with protocol function scenario coverage exceeding 85%.

[0119] b) Variation strategy coverage: performing basic variations (bit flipping, byte replacement), semantic-driven variations (key field targeted tampering), and genetic algorithm optimized variations, with the three types of strategies accounting for 40%, 35%, and 25%, respectively, generating a total of 18500 test cases.

[0120] Key vulnerability discovery

[0121] 8 security vulnerabilities were found, of which 3 were high-risk: CAN protocol data length overflow vulnerability: long data frame (> 8 bytes) causes ECU to enter error passive state, bus error rate increases from 0.5% to 12%, triggers vehicle door control delay ≥ 1s; BLE protocol buffer overflow vulnerability: writing long data (> 16 bytes) to GATT feature value causes device to crash and restart, needs to be re-paired, log records "memory access overflow"; DOIP protocol session timing vulnerability: multiple node concurrent requests (interval ≤ 30ms) cause gateway session sequence number to jump, some requests return error response (0x05). 5 medium-risk vulnerabilities, including CAN RTR bit invalid value processing defects, BLE UUID format verification vulnerabilities, etc., mainly manifested as response delay or connection exception.

[0122] The above is a description of the specific implementation of the present application, not a limitation of the present application. Those skilled in the art can make various equivalent technical solutions without departing from the scope of the present application, therefore all equivalent technical solutions should be included in the protection scope of the present application.

Claims

1. A method for automated vulnerability discovery in vehicle networking protocols, characterized in that: The method comprises the following steps: Step one, build a test system, select the target protocol for testing and configure the corresponding test parameters: The test system includes a protocol communication module and a fuzz testing module, the fuzz testing module includes a mutation strategy engine, a test case management mechanism, a real-time feedback mechanism, a genetic optimization strategy, an exception monitoring mechanism and a result analysis mechanism; Step two, according to the configuration, start the protocol communication module in the test system, establish a connection with the target device, and obtain the initial seed data from the target device after the connection; Step three, the mutation strategy engine in the test system randomly tampers the initial seed data to generate mutation test cases, which are sent to the target device by the test case management mechanism; Step four, abnormal monitoring and strategy optimization: During the sending of test cases, the exception monitoring mechanism in the system monitors the response of the target device in real time and continuously, and once an abnormal behavior is detected, the result analysis mechanism analyzes the abnormal log to preliminarily locate the possible vulnerability field or processing logic; then, the mutation strategy engine adjusts the mutation strategy according to the monitoring feedback, and the mutation strategy engine adjusts the genetic optimization strategy according to the real-time feedback mechanism to optimize the strategy; Step five, repeat steps three and four until the preset test termination condition is reached; Step six, after the test is completed, the system integrates all test results to generate a detailed vulnerability report. 2.The method of claim 1, wherein: The test termination condition of step five is the test duration or the number of vulnerabilities found. 3.The method of claim 2, wherein: In step four, the abnormal behavior of the target device includes communication interruption, ECU crash or response timeout exception phenomenon; Continuously monitor the response of the target system to the abnormal packet.

4. The method of claim 3, wherein the method further comprises: The vulnerability report in step five includes the description of the discovered abnormal situation, the triggering step, the related data packet information and the repair suggestion, and supports export in CSV or JSON format.

5. The method of claim 4, wherein: The mutation strategy engine is a dynamic mutation strategy engine based on protocol semantics and state machine driving.

6. The method of claim 5, wherein: The real-time feedback mechanism is a real-time feedback mechanism combining path coverage and branch coverage.

7. The method of claim 6, wherein the method further comprises: The test parameters in step one include the bit flip probability of mutation and the maximum length of field insertion / deletion. 8.The method of claim 7, wherein: The bit flip probability is set to 10%-30%.

Images