Vulnerability mining method and device for vehicle-mounted protocol

Abstract

The invention discloses a vulnerability mining method and device for a vehicle-mounted protocol. The method comprises the following steps: acquiring the vehicle-mounted protocol and vehicle sensor data; generating a target test case according to the vehicle-mounted protocol and the vehicle sensor data; according to the target test case, executing a fuzzy test to obtain a test result; and verifying the potential vulnerability according to the test result to obtain a vulnerability verification result. The method can improve the vulnerability mining efficiency and accuracy of the vehicle-mounted protocol, and can be widely applied to the technical field of vehicle-mounted network security.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle-mounted network security, and in particular to a method and device for mining vulnerabilities of a vehicle-mounted protocol. Background Art

[0002] With the rapid development of network communication technology and the automotive industry, data interactions within the Internet of Vehicles are frequent, and security issues are becoming increasingly prominent. Fuzz testing has been introduced as a solution to address security threats in the Internet of Vehicles. Fuzz testing discovers possible crashes and security vulnerabilities in the protocol stack when processing unexpected inputs by inputting random, abnormal, or invalid data into the system. Fuzz testing is highly effective and practical for vulnerability mining of the in-vehicle CANbus protocol. However, the fuzz testing technology for in-vehicle protocols can only perform single-step operations, which limits the degree of automation of the test. It is impossible to simulate complex interaction scenarios, which may involve multiple steps or sequences of commands. This may lead to insufficient test coverage and inability to fully discover potential vulnerabilities and defects. More manual intervention is required at this time, reducing the efficiency and continuity of the test. Summary of the invention

[0003] In view of this, the main purpose of the embodiments of the present invention is to provide a method and device for vulnerability mining of vehicle-mounted protocols, in order to solve at least one of the problems of the prior art. The present invention can improve the efficiency and accuracy of vulnerability mining of vehicle-mounted protocols.

[0004] To achieve the above purpose, an embodiment of the present invention provides a method for discovering vulnerabilities in an in-vehicle protocol, including:

[0005] Obtain vehicle protocols and vehicle sensor data;

[0006] Generate a target test case according to the vehicle protocol and the vehicle sensor data;

[0007] According to the target test case, perform fuzz testing to obtain test results;

[0008] According to the test results, the potential vulnerability is verified to obtain a vulnerability verification result.

[0009] In some embodiments, generating a target test case according to the vehicle protocol and the vehicle sensor data comprises the following steps:

[0010] Determine the type of the vehicle-mounted protocol, and if the vehicle-mounted protocol is a public protocol, obtain first vehicle-mounted protocol knowledge of the public protocol by analyzing the protocol standard text; if the vehicle-mounted protocol is an undisclosed protocol, obtain second vehicle-mounted protocol knowledge of the undisclosed protocol by machine learning or reverse engineering;

[0011] Constructing a protocol message data model according to the first vehicle-mounted protocol knowledge and the second vehicle-mounted protocol knowledge;

[0012] The target test case is generated according to the protocol message data model and the vehicle sensor data.

[0013] In some embodiments, generating the target test case according to the protocol message data model and the vehicle sensor data comprises the following steps:

[0014] According to the vehicle sensor data, simulate vehicle driving conditions and generate a test scenario;

[0015] Obtaining a message frame in the protocol message data model;

[0016] Generate a first test case according to the message frame through a mutation strategy;

[0017] Generate a second test case according to the message frame by generating a strategy;

[0018] The target test case is obtained according to the test scenario, the first test case and the second test case.

[0019] In some embodiments, performing fuzz testing according to the target test case to obtain a test result includes the following steps:

[0020] Create several simulation nodes;

[0021] Establishing a communication channel between the simulation node and the device under test;

[0022] Sending a first legal request and a first fuzzy message to the device under test according to the target test case through the communication channel, monitoring a response of the device under test, and obtaining the test result;

[0023] The simulation node is used to simulate the behavior of the electronic control unit in the vehicle protocol.

[0024] In some embodiments, verifying the potential vulnerability according to the test result to obtain the vulnerability verification result includes the following steps:

[0025] According to the test result, obtaining a third test case having a potential vulnerability in the target test case;

[0026] According to the third test case, a second legal request and a second fuzzy message are sent to the device under test, a response of the device under test is monitored, and the vulnerability verification result is obtained.

[0027] In some embodiments, after verifying the potential vulnerability according to the test result and obtaining the vulnerability verification result, the following steps are also included:

[0028] Assess the impact of the potential vulnerabilities described;

[0029] According to the vulnerability verification results and the impact of the potential vulnerability, a POC is written to demonstrate the potential vulnerability.

[0030] To achieve the above purpose, another aspect of an embodiment of the present invention provides a vulnerability mining device for an in-vehicle protocol, the device comprising:

[0031] The first module is used to obtain vehicle protocols and vehicle sensor data;

[0032] The second module is used to generate a target test case according to the vehicle protocol and the vehicle sensor data;

[0033] The third module is used to perform fuzz testing according to the target test case and obtain the test result;

[0034] The fourth module is used to verify the potential vulnerability according to the test result to obtain the vulnerability verification result.

[0035] To achieve the above-mentioned purpose, another aspect of an embodiment of the present invention provides an electronic device, which includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, it implements the vulnerability mining method of the vehicle-mounted protocol described above.

[0036] To achieve the above-mentioned purpose, another aspect of an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the vulnerability mining method of the vehicle-mounted protocol described above is implemented.

[0037] To achieve the above-mentioned purpose, another aspect of an embodiment of the present invention provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device can read the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the aforementioned method for exploiting vulnerabilities in an in-vehicle protocol.

[0038] The embodiments of the present invention include at least the following beneficial effects: The present invention provides a method and device for exploiting vulnerabilities in vehicle-mounted protocols, which obtains vehicle-mounted protocols and vehicle sensor data; generates target test cases based on the vehicle-mounted protocols and the vehicle sensor data; performs fuzzy testing based on the target test cases to obtain test results; and verifies potential vulnerabilities based on the test results to obtain vulnerability verification results, thereby improving the degree of automated utilization of fuzzy testing of vehicle-mounted protocols, thereby improving the efficiency and accuracy of vulnerability exploitation in vehicle-mounted protocols. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0040] Figure 1 It is a flow chart of a method for exploiting vulnerabilities in an in-vehicle protocol provided by an embodiment of the present invention;

[0041] Figure 2 It is a schematic diagram of the main payload of the message frame of the CANbus protocol provided by an embodiment of the present invention in the Identifier (ID) segment and the Data segment of the message;

[0042] Figure 3 It is a schematic diagram of a process of performing fuzzy testing based on machine learning protocol analysis provided by an embodiment of the present invention;

[0043] Figure 4 It is a schematic diagram of an optional implementation process of vulnerability mining of an in-vehicle protocol provided by an embodiment of the present invention;

[0044] Figure 5 It is a schematic diagram of the hardware structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of the present invention, and they are only examples of devices and methods consistent with some aspects of the embodiments of the present invention as detailed in the attached claims.

[0046] It should be noted that, although the functional modules are divided in the system schematic diagram and the logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than the module division in the system or the flow chart. The terms "first / S100" and "second / S200" in the specification and claims and the above-mentioned drawings may be used to describe various concepts in this article, but unless otherwise specified, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiment of the present invention, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the words "if" and "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determination".

[0047] The terms "at least one", "multiple", "each", "any", etc. used in the present invention, at least one includes one, two or more, multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0048] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present invention belongs. The terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.

[0049] Before describing the embodiments of the present invention in detail, some nouns and terms involved in the embodiments of the present invention are first described. The nouns and terms involved in the embodiments of the present invention are subject to the following explanations.

[0050] CAN protocol (Controller Area Network Protocol): CAN protocol is a serial communication protocol, originally developed by BOSCH of Germany for the automotive industry, used to achieve data communication between multiple electronic control units (ECUs). It is a multi-host communication protocol with high reliability, high real-time performance and strong anti-interference ability.

[0051] CANbus protocol: CANbus protocol refers to a communication network based on CAN protocol, which allows multiple devices to communicate through a pair of twisted pair wires. CANbus protocol supports five types of frames: data frame, remote frame, error frame, overload frame and frame interval.

[0052] CAN Identifier segment (CAN ID): In the CAN protocol, each data frame has a unique identifier (Identifier) ​​to distinguish different messages. The CAN ID is included in the message frame and is mainly used for arbitration of the CAN bus. The lower the ID value, the higher the message priority. The CAN ID can be 11 bits (standard format) or 29 bits (extended format).

[0053] Data segment: The Data segment is the part of the CAN data frame used to transmit actual data. It can send 0 to 8 bytes of data. The content of the Data segment is the data that the controller actively sends by assembling a packet, which is useful information for us.

[0054] POC (Proof of Concept) is a method used to verify the feasibility of new ideas, new technologies or new processes. It aims to prove whether a concept is feasible through actual small-scale implementation, and is usually used for evaluation before formal implementation.

[0055] A device under test (DUT) is a manufactured product that is tested when it is first manufactured or later in its life cycle as part of ongoing functional testing and calibration checks.

[0056] With the rapid development of network communication technology and the automobile industry, data interactions in the Internet of Vehicles are frequent, and security issues are becoming increasingly prominent. Fuzz testing has been introduced as a solution to deal with security threats in the Internet of Vehicles. Since the intelligent Internet of Vehicles involves in-vehicle wired network protocols and in-vehicle wireless communication technologies, these protocols have large differences in data format, transmission rate, communication content, etc., which increases the complexity of testing. Fuzz testing discovers possible crashes and security vulnerabilities in the protocol stack when processing unexpected inputs by inputting random, abnormal or invalid data into the system. It has important applications in the security assurance of intelligent connected vehicle protocols, including three categories: penetration testing, fuzz testing, and compliance testing. Fuzz testing is practical and effective for vulnerability mining of the in-vehicle CANbus protocol. However, the fuzz testing technology for in-vehicle protocols can only perform single-step operations, which limits the degree of automation of the test. It is impossible to simulate complex interaction scenarios, which may involve multiple steps or sequences of commands. This may lead to insufficient test coverage and inability to fully discover potential vulnerabilities and defects. At this time, more manual intervention is required, which reduces the efficiency and continuity of the test.

[0057] In view of this, if Figure 1 As shown, an embodiment of the present invention provides a method for exploiting vulnerabilities in an in-vehicle protocol, which may include but is not limited to steps S100 to S400:

[0058] Step S100, obtaining vehicle protocol and vehicle sensor data;

[0059] Step S200, generating a target test case according to the vehicle protocol and the vehicle sensor data;

[0060] Step S300, performing fuzzy testing according to the target test case to obtain a test result;

[0061] Step S400: verify the potential vulnerability according to the test result to obtain a vulnerability verification result.

[0062] In step S100 of some embodiments, to perform fuzzy testing on the vehicle-mounted protocol, it is first necessary to obtain the format of the vehicle-mounted protocol and divide the vehicle-mounted protocol into two categories: public protocols and undisclosed protocols. In addition, it is also necessary to obtain vehicle sensor data. By integrating data from multiple sensors, complex interactions and state changes in the real world can be simulated, thereby comprehensively evaluating the performance and performance of the vehicle-mounted system in a changing environment. By collecting data from vehicle sensors in real time, the real-time internal state and external environmental conditions of the vehicle can be analyzed. By obtaining the vehicle-mounted protocol and vehicle sensor data, a good foundation is laid for the subsequent generation of target test cases.

[0063] In some embodiments, step S200 may include but is not limited to steps S210 to S230:

[0064] Step S210, determining the type of the vehicle-mounted protocol, if the vehicle-mounted protocol is a public protocol, acquiring first vehicle-mounted protocol knowledge of the public protocol by analyzing the protocol standard text; if the vehicle-mounted protocol is an undisclosed protocol, acquiring second vehicle-mounted protocol knowledge of the undisclosed protocol by machine learning or reverse engineering;

[0065] Step S220, constructing a protocol message data model according to the first vehicle-mounted protocol knowledge and the second vehicle-mounted protocol knowledge;

[0066] Step S230: generating the target test case according to the protocol message data model and the vehicle sensor data.

[0067] In step S210 of some embodiments, the acquired vehicle-mounted protocols are classified and judged to determine the type of the vehicle-mounted protocols. If the vehicle-mounted protocols are public protocols, the first vehicle-mounted protocol knowledge of the public protocols can be obtained by analyzing the protocol standard text to prepare for defining the data model and state transition model of the protocol message. For example, common public vehicle-mounted protocols include:

[0068] 1. Standard CAN (CAN 2.0A): This is the most basic CAN protocol version, which uses an 11-bit identifier (ID) to distinguish different messages and has a maximum transmission rate of 1Mbps.

[0069] 2. Extended CAN (CAN 2.0B): This version expands on the standard CAN, uses a 29-bit identifier (ID), provides more address space, and is suitable for scenarios that require more devices or message types.

[0070] In addition, it also includes low-speed CAN (ISO 11898-3), CAN (ISO 11898-2), CAN FD (CAN with Flexible Data-Rate), etc.

[0071] If the in-vehicle protocol is an undisclosed protocol, the second in-vehicle protocol knowledge of the undisclosed protocol is obtained through machine learning or reverse engineering. In actual applications, different automobile manufacturers or equipment developers may customize or extend the CAN protocol they use to meet specific needs. These customizations may include private message IDs, data formats, or communication parameters. Therefore, although the basic CAN protocol is public and standardized, these customizations or extensions may be undisclosed and need to be obtained through reverse engineering or machine learning-based protocol analysis. There are the following machine learning and reverse engineering methods:

[0072] 1. Machine learning methods: such as Generative Adversarial Networks (GAN) or Long Short-Term Memory Networks (LSTM), learn protocol knowledge from intercepted communication traffic and then construct test data. Optionally, a machine learning algorithm, especially a machine learning-based protocol analysis using deep learning technology, is used to analyze and learn the communication mode and behavior characteristics of the CAN protocol. This method uses protocol messages as data sets and trains the model to identify the legitimate behavior and potential abnormal behavior of the protocol through machine learning, thereby improving the accuracy and efficiency of subsequent fuzz testing. For example, Figure 3 As shown in the figure, the steps of fuzz testing based on machine learning protocol analysis are as follows:

[0073] (1) Data collection: First, collect a large amount of CAN communication data, including normal communication data and known attack or abnormal data. This data will be used to train the machine learning model.

[0074] (2) Feature extraction: Then, useful features are extracted from the raw CAN data, such as CAN ID, data length, data field, etc. These features will serve as input to the machine learning model.

[0075] (3) Model training: Next, the extracted features are used to train a machine learning model, such as a support vector machine (SVM) or a deep neural network (DNN). The goal of the machine learning model is to learn patterns that distinguish normal communication from abnormal behavior.

[0076] (4) Model validation: After the machine learning model training is completed, the validation set is used to evaluate the performance of the machine learning model, such as accuracy, recall, etc. If the performance of the machine learning model meets the requirements, it can be used for real-time protocol analysis.

[0077] (5) Real-time monitoring: Finally, the trained machine learning model is deployed in the test environment to monitor CAN communication data in real time and use the model to identify potential abnormal behaviors or attacks.

[0078] 2. Reverse Engineering: Reverse engineering analyzes protocol traffic and identifies the characteristics and structure of the protocol, which helps define the data model of the protocol message. Reverse engineering analyzes the message format through pattern recognition and can reconstruct the protocol handshake process, which is also a key prerequisite for building the protocol message data model.

[0079] Among them, vehicle protocol knowledge refers to the sum of theoretical knowledge, technical specifications, implementation methods and application practices related to the protocol. The protocol is the rules and standards that are jointly followed by two or more communicating parties in order to achieve effective communication. Protocol knowledge may include but is not limited to the data exchange format, sequence, timing and error handling mechanism defined by the protocol; protocol layers, such as the physical layer, data link layer, network layer, transport layer, session layer, presentation layer and application layer in the OSI model; protocol types, such as network protocols, transport protocols, application protocols, etc.; the syntax, semantics and synchronization rules of the protocol described in the protocol specification; and understanding of factors affecting protocol performance, such as latency, throughput and reliability.

[0080] In step S220 of some embodiments, the first vehicle-mounted protocol knowledge after analyzing the protocol standard text and the second vehicle-mounted protocol knowledge obtained by machine learning-based protocol analysis or reverse engineering are combined to construct a protocol message data model, laying a solid foundation for the subsequent generation of test cases.

[0081] In step S230 of some embodiments, in the intelligent driving system, the data collected by the vehicle sensors (such as cameras, radars, laser radars, etc.) can be transmitted to the bus through the CAN communication protocol, and then the data is transmitted to the electronic control unit. This transmission method ensures efficient communication between each sensor and the vehicle control system. By integrating the data of multiple sensors, complex interactions and state changes in the real world can be simulated, so as to comprehensively evaluate the performance and performance of the vehicle-mounted system under a variable environment. Based on these sensor data, combined with the data in the protocol message data model, the method of adaptive multimodal input can be used to create and execute test cases. Through adaptive multimodal input, a more realistic and complex test environment can be simulated, which helps to reveal problems that may be overlooked under simple test conditions, thereby significantly improving the safety and reliability of the vehicle-mounted system. Exemplarily, by collecting vehicle sensor data that can reflect the external environment and internal state of the vehicle in real time, using these multimodal data inputs, a series of complex test scenarios can be generated to simulate various situations that the vehicle may encounter in actual driving. For example, the driving performance of the vehicle under different weather conditions or the reaction in traffic congestion can be simulated. At the core of this example process is an intelligent test case generator that dynamically adjusts test cases based on the collected data to ensure that the test covers all possible operations and interaction scenarios. The intelligent test case generator can create test cases that comply with protocol specifications and cover a variety of operational scenarios. Optionally, these multimodal input data can be used to analyze the format of unknown protocols based on machine learning protocol analysis, and the structure and communication mode of the protocol can be learned and inferred from the data through deep learning technology. Then, the protocol knowledge obtained from the machine learning model analysis is combined with the on-board protocol knowledge in the protocol message data model to generate target test cases.

[0082] In some embodiments, step S230 may include but is not limited to steps S231 to S235:

[0083] Step S231, simulating vehicle driving conditions and generating a test scenario according to the vehicle sensor data;

[0084] Step S232, obtaining a message frame in the protocol message data model;

[0085] Step S233, generating a first test case according to the message frame through a mutation strategy;

[0086] Step S234, generating a second test case according to the message frame by generating a strategy;

[0087] Step S235: Obtain the target test case according to the test scenario, the first test case and the second test case.

[0088] In step S231 of some embodiments, data collected by vehicle-mounted sensors simulates complex vehicle driving interaction situations in the real world to generate test scenarios. These data include not only external environmental information of the vehicle, but also internal status information of the vehicle, providing rich context for subsequent testing.

[0089] In steps S232 to S235 of some embodiments, since the main load of the message frame of the CANbus protocol is in the CAN Identifier segment and the Data segment of the message (such as Figure 2 As shown), test cases can be generated for these two data segments through mutation strategies and generation strategies. Optionally, by obtaining the main payload of the message frame in the protocol message data model, test cases are generated for the main payload of the message frame in the CAN Identifier segment and the Data segment of the message through the following mutation strategy and generation strategy:

[0090] 1. Mutation strategy

[0091] The mutation strategy is based on the modification of existing valid input data (seed) to generate new test cases. Since the mutation strategy can quickly generate a large amount of mutation data, it is suitable for black box testing of embedded devices. For example, there is a valid CAN message frame with the following format:

[0092] ID:0x123

[0093] Data:[0x01,0x02,0x03,0x04]

[0094] The mutation strategy can make the following modifications to the message frame data:

[0095] Byte flip: flip a byte in the data, for example, change 0x02 to 0xFF.

[0096] Insert data: Insert extra bytes into the data, for example, change the data to [0x01, 0xFF, 0x02, 0x03, 0x04].

[0097] Delete byte: Delete a byte in the data, for example, change the data to [0x01, 0x03, 0x04].

[0098] Change ID: Change the message ID to another value, for example, change 0x123 to 0x456.

[0099] These mutations can help discover potential vulnerabilities in protocol implementations, such as improperly handled boundary conditions or anomalous data.

[0100] 2. Generate strategy

[0101] The generation strategy is to systematically generate new test cases according to the structure defined by the protocol specification. This strategy usually requires a deep understanding of the detailed specification of the protocol. For example, assume that the specification of the CAN protocol defines the format of the message ID and data fields. Generate new test cases according to the format defined by these specifications:

[0102] 1) Generate a valid message: Generate a new CAN message frame according to the specification:

[0103] ID:0x456

[0104] Data:[0x05,0x06,0x07,0x08]

[0105] 2) Generate boundary messages: Generate boundary condition messages according to the protocol definition, for example:

[0106] ID: 0x000 (minimum value)

[0107] Data:[0x00,0x00,0x00,0x00](all zero data)

[0108] or

[0109] ID: 0x7FF (maximum value)

[0110] Data:[0xFF,0xFF,0xFF,0xFF](Full maximum data)

[0111] The generation strategy can ensure that the generated test cases meet the protocol specifications and cover different parts of the protocol. By combining the mutation strategy and the generation strategy, test cases for the vehicle CANbus protocol can be effectively generated. This method can not only quickly discover potential vulnerabilities, but also ensure the effectiveness and coverage of test cases. The mutation strategy is suitable for quickly generating diverse inputs, while the generation strategy ensures that the inputs meet the protocol specifications. The combination of the two can improve the effect of fuzz testing. Combining the test cases generated by the mutation strategy and the generation strategy with the test scenarios generated by the vehicle sensor data, the target test cases can be obtained.

[0112] In step S300 of some embodiments, according to the target test case, fuzzy test is performed to obtain test results. During the fuzzy test, the test environment and the system under test are also monitored in real time to timely discover abnormal situations in the test process, such as connection interruption, host crash, response timeout, etc. Exemplarily, in the test execution and monitoring process of the vehicle-mounted CANbus protocol, simulated communication nodes and monitoring components are involved. Simulated communication nodes refer to creating one or more nodes in the test environment, which simulate the behavior of the electronic control unit (ECU) in the actual CAN network and are used to establish a communication channel with the device under test (DUT). This process includes sending fuzzy messages to the DUT and observing the response of the DUT, such as randomly generated CAN ID and data load to discover potential vulnerabilities and abnormal behaviors. Monitoring components refer to tools and methods for real-time monitoring of the test environment and the system under test during the test execution process. During the test process, various monitoring tools can be used to check the network status and system performance. Optionally, EC-Inspector is used to monitor the communication quality of the EtherCAT network, including signal integrity, return loss and bit error rate. You can also use open source monitoring systems such as Prometheus to collect and analyze vehicle network performance indicators, such as CPU usage, memory usage, network latency, etc. In actual test execution and monitoring, for vehicle protocols, you may also need to pay attention to some specific test cases, such as terminal resistance test, low-voltage communication range test, etc., and pay attention to the status of physical devices such as lights, dashboards, and doors.

[0113] In some embodiments, step S300 may include but is not limited to steps S310 to S330:

[0114] Step S310, creating several simulation nodes;

[0115] Step S320, establishing a communication channel between the simulation node and the device under test;

[0116] Step S330, sending a first legal request and a first fuzzy message to the device under test through the communication channel according to the target test case, monitoring a response of the device under test, and obtaining the test result;

[0117] The simulation node is used to simulate the behavior of the electronic control unit in the vehicle protocol.

[0118] In steps S310 to S330 of some embodiments, one or more simulation nodes are created in the test environment, a communication channel is established between the simulation node and the device under test (DUT), complex interaction processes and state transitions are simulated according to the target test case, fuzz testing is performed, and the response of the system is monitored to obtain test results. In the process of simulating complex interaction processes and state transitions according to the target test case and performing fuzz testing, a multi-step execution model is utilized, and the simulation node sends multi-step legal requests and fuzzy messages to the device under test through the communication channel. The multi-step execution model refers to the simulation of complex interaction processes and state transitions in fuzz testing, which can be generally understood as simulating a series of sequential operation steps, each of which may affect the execution of subsequent steps. This model can better evaluate the behavior of the system when processing multi-step operations. Exemplarily, an automatic parking system of an intelligent connected vehicle is tested, wherein the automatic parking process has the following steps:

[0119] 1. Start parking mode: The driver selects the "automatic parking" mode through the vehicle system, and the system begins to prepare to enter the parking state.

[0120] 2. Scan the surroundings: The vehicle uses sensors to scan the surroundings and identify available parking spaces.

[0121] 3. Select a parking space: The system selects a suitable parking space based on the scanning results and confirms it with the driver.

[0122] 4. Execute parking operation: The vehicle starts to automatically control the steering wheel and throttle to perform parking operations.

[0123] 5. Parking completed: After the vehicle is successfully parked in the parking space, the system prompts the driver that parking is completed.

[0124] The following steps are used to perform fuzz testing on the automatic parking system of intelligent connected vehicles using a multi-step execution model:

[0125] Step 1: Send a valid request to start parking mode.

[0126] Step 2: When the device under test starts to scan the surrounding environment, the simulated node sends interference signals or abnormal data to simulate sensor failure.

[0127] Step 3: While the device under test is selecting a parking space, the simulated node sends conflicting instructions or data (such as sending a request for the vehicle to turn immediately) to simulate the impact of external interference on the decision-making process.

[0128] Step 4: When the device under test performs a parking operation, the simulated node sends a random or abnormal CAN ID and data payload to test the device under test's ability to handle abnormal communications.

[0129] During the entire test process, observe and record the response and behavior of the device under test, especially the response to ambiguous messages, check whether there are abnormal conditions (including but not limited to system crashes, response timeouts, error messages, unexpected system behaviors, etc.), and obtain test results. In the test execution and monitoring link of the in-vehicle CANbus protocol, the analysis and utilization of test results involves recording and analyzing the captured abnormal conditions, as well as verifying and utilizing the discovered vulnerabilities. Exemplarily, the method of recording abnormal conditions may include:

[0130] (1) Logging: Use logging tools, such as the ELK (Elasticsearch, Logstash, Kibana) stack, to collect and standardize the log data generated during the test. These log data can include timestamps, test case IDs, system responses, error codes, and other information.

[0131] (2) Real-time monitoring: Use monitoring tools, such as intrusion detection systems (IDS / IPS) or security event logs (SIEM), to monitor system behavior in real time during the test execution process. Once abnormal behavior is found, record the relevant logs immediately for subsequent analysis.

[0132] By using a multi-step execution model for fuzz testing, you can ensure the stability and security of the system when processing a series of complex operations. This approach can reveal problems that may not be discovered when testing alone, because some problems only appear in the context of a specific series of operations.

[0133] In some embodiments, step S400 may include but is not limited to steps S410 to S420:

[0134] Step S410, obtaining a third test case having a potential vulnerability in the target test case according to the test result;

[0135] Step S420: According to the third test case, a second legal request and a second fuzzy message are sent to the device under test, a response of the device under test is monitored, and the vulnerability verification result is obtained.

[0136] In some embodiments, in steps S410 to S420, the test results are analyzed, that is, the captured abnormal state is recorded and analyzed, the abnormal state is regarded as a potential vulnerability, and a test case with a potential vulnerability is obtained. The test case with the potential vulnerability is further tested to confirm the existence of the vulnerability. After the vulnerability is verified, its degree of harm and potential attack scenarios can also be evaluated, and a POC is written based on the vulnerability verification results and the degree of harm of the potential vulnerability and the potential attack scenarios to demonstrate the vulnerability. The relevant steps for vulnerability verification are as follows:

[0137] (1) Reproduction test: Try to repeatedly execute the test case that causes the abnormal state to confirm whether the problem can be reproduced.

[0138] (2) Impact assessment: Analyze the impact that the vulnerability may have on the system, including data leakage, service interruption, loss of system control, etc.

[0139] (3) Attack simulation: Simulate scenarios where attackers exploit vulnerabilities to assess the actual threat posed by the vulnerabilities, which may include attempts to exploit the vulnerabilities to gain unauthorized access to data, execute malicious code, or control critical functions of the vehicle.

[0140] (4) Script writing: Based on the verification results of the vulnerability, write a proof of concept to demonstrate the vulnerability.

[0141] refer to Figure 4 , Figure 4 An optional implementation process of vulnerability mining of the vehicle-mounted protocol provided by an embodiment of the present invention is illustrated as follows:

[0142] Step 1: Obtain vehicle-mounted sensor data and vehicle-mounted protocols, and obtain the real-time internal status and external environmental conditions of the vehicle based on the vehicle-mounted sensor data. For public vehicle-mounted protocols, define the data model of the protocol message by analyzing the protocol standard text; for undisclosed vehicle-mounted protocols, define the protocol message data model through machine learning protocol analysis or reverse engineering.

[0143] Step 2: Obtain the target test case through the intelligent test case generator by obtaining the real-time internal status of the vehicle, external environmental conditions, and data model of the protocol message.

[0144] Step 3: According to the target test case, use the multi-step execution model to test, monitor and record the system response and abnormal status in real time, obtain the test results, and analyze the test results to obtain potential vulnerabilities and their corresponding test cases.

[0145] Step 4: Use the test cases corresponding to the potential vulnerabilities to verify the vulnerabilities. If the vulnerability verification is successful, that is, the abnormal state is reproduced, then record the vulnerability verification results and write a poc to demonstrate the vulnerability. If the vulnerability verification fails, that is, the abnormal state does not appear, then return to step 2.

[0146] The embodiment of the present invention further provides a vehicle-mounted protocol vulnerability mining device, which can implement the above-mentioned vehicle-mounted protocol vulnerability mining method, and the device includes:

[0147] The first module is used to obtain vehicle protocols and vehicle sensor data;

[0148] The second module is used to generate a target test case according to the vehicle protocol and the vehicle sensor data;

[0149] The third module is used to perform fuzz testing according to the target test case and obtain the test result;

[0150] The fourth module is used to verify the potential vulnerability according to the test result to obtain the vulnerability verification result.

[0151] It can be understood that the contents of the above method embodiments are all applicable to the present device embodiments, the functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0152] The embodiment of the present invention further provides an electronic device, which includes a processor and a memory, wherein the memory stores a computer program, and the processor implements the above-mentioned method for exploiting a vulnerability in a vehicle protocol when executing the computer program. The electronic device may be any intelligent terminal including a tablet computer, a vehicle-mounted computer, etc.

[0153] It can be understood that the contents of the above method embodiments are all applicable to the present device embodiments, the functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0154] refer to Figure 5 , Figure 5 The hardware structure of an electronic device of another embodiment is illustrated, and the electronic device includes:

[0155] The processor 501 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present invention.

[0156] The memory 502 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 502 can store an operating system and other applications. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 502, and the processor 501 calls and executes a method for exploiting vulnerabilities in a vehicle-mounted protocol according to an embodiment of the present invention;

[0157] Input / output interface 503, used to implement information input and output;

[0158] Communication interface 504, used to realize communication interaction between the device and other devices, which can be realized through wired mode (such as USB, network cable, etc.) or wireless mode (such as mobile network, WI FI, Bluetooth, etc.);

[0159] A bus 505 that transmits information between the various components of the device (e.g., the processor 501, the memory 502, the input / output interface 503, and the communication interface 504);

[0160] The processor 501 , the memory 502 , the input / output interface 503 and the communication interface 504 are connected to each other in communication within the device via the bus 505 .

[0161] An embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the above-mentioned method for exploiting vulnerabilities in a vehicle-mounted protocol.

[0162] It can be understood that the contents of the above method embodiments are all applicable to the present storage medium embodiments, the functions specifically implemented by the present storage medium embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0163] The embodiment of the present invention further provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device can read the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the aforementioned method for exploiting vulnerabilities in an in-vehicle protocol.

[0164] In summary, the method and device for exploiting a vulnerability in an in-vehicle protocol according to an embodiment of the present invention have the following advantages:

[0165] 1. The embodiment of the present invention optimizes the fuzz testing scheme of the vehicle-mounted protocol to simulate more complex interaction scenarios, improves the degree of automation of the fuzz testing of the vehicle-mounted protocol, and thus improves the efficiency and accuracy of vulnerability mining of the vehicle-mounted protocol.

[0166] 2. The embodiment of the present invention proposes to use two methods, namely, protocol analysis based on machine learning and multi-step execution model, to improve the efficiency and accuracy of vehicle-mounted CANbus protocol fuzz testing, thereby improving the efficiency and accuracy of vehicle-mounted protocol vulnerability mining.

[0167] 3. The embodiment of the present invention simulates a more realistic and complex test environment through adaptive multi-modal input, including the external environment information of the vehicle and the internal state information of the vehicle, providing rich context for fuzz testing. Combined with machine learning-based protocol analysis and multi-step execution model, the fuzz testing of the vehicle protocol is optimized and automated, improving the efficiency and coverage of the test.

[0168] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of technology. The disclosed method is not limited to the operation and logic flow presented herein. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part for which is described as a larger operation is performed independently.

[0169] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise specified, one or more of the functions and / or features described may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. More specifically, in view of the properties, functions, and internal relationships of the various functional modules in the device disclosed herein, the actual implementation of the module will be understood within the conventional skills of the engineer. Therefore, those skilled in the art can implement the present invention set forth in the claims without excessive experimentation using ordinary techniques. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0170] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0171] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in conjunction with such instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in conjunction with such instruction execution systems, devices or apparatuses.

[0172] More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be a paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering or, if necessary, processing in another suitable manner, and then stored in a computer memory.

[0173] It should be understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0174] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0175] Although the embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.

[0176] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the described embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present invention.

Claims

1. A method for exploiting a vulnerability in an in-vehicle protocol, characterized in that: The following steps are involved: Obtain vehicle protocols and vehicle sensor data; Generate a target test case according to the vehicle protocol and the vehicle sensor data; According to the target test case, perform fuzz testing to obtain test results; According to the test results, the potential vulnerability is verified to obtain a vulnerability verification result.

2. The method for exploiting a vulnerability in an in-vehicle protocol according to claim 1, characterized in that: The generating of a target test case according to the vehicle-mounted protocol and the vehicle sensor data comprises the following steps: Determine the type of the vehicle-mounted protocol, and if the vehicle-mounted protocol is a public protocol, obtain first vehicle-mounted protocol knowledge of the public protocol by analyzing the protocol standard text; if the vehicle-mounted protocol is an undisclosed protocol, obtain second vehicle-mounted protocol knowledge of the undisclosed protocol by machine learning or reverse engineering; Constructing a protocol message data model according to the first vehicle-mounted protocol knowledge and the second vehicle-mounted protocol knowledge; The target test case is generated according to the protocol message data model and the vehicle sensor data.

3. The method for exploiting a vulnerability in an in-vehicle protocol according to claim 2, characterized in that: The step of generating the target test case according to the protocol message data model and the vehicle sensor data comprises the following steps: According to the vehicle sensor data, simulate vehicle driving conditions and generate a test scenario; Obtaining a message frame in the protocol message data model; Generate a first test case according to the message frame through a mutation strategy; Generate a second test case according to the message frame by generating a strategy; The target test case is obtained according to the test scenario, the first test case and the second test case.

4. The method for exploiting a vulnerability in an in-vehicle protocol according to claim 1, characterized in that: The method of performing fuzz testing according to the target test case to obtain a test result includes the following steps: Create several simulation nodes; Establishing a communication channel between the simulation node and the device under test; Sending a first legal request and a first fuzzy message to the device under test according to the target test case through the communication channel, monitoring a response of the device under test, and obtaining the test result; The simulation node is used to simulate the behavior of the electronic control unit in the vehicle protocol.

5. The method for exploiting a vulnerability in an in-vehicle protocol according to claim 4, characterized in that: According to the test results, the potential vulnerability is verified to obtain the vulnerability verification result, including the following steps: According to the test result, obtaining a third test case having a potential vulnerability in the target test case; According to the third test case, a second legal request and a second fuzzy message are sent to the device under test, a response of the device under test is monitored, and the vulnerability verification result is obtained.

6. The method for exploiting a vulnerability in an in-vehicle protocol according to claim 1, characterized in that: After verifying the potential vulnerability according to the test result and obtaining the vulnerability verification result, the following steps are also included: Assess the impact of the potential vulnerabilities described; According to the vulnerability verification results and the impact of the potential vulnerability, a POC is written to demonstrate the potential vulnerability.

7. A vehicle-mounted protocol vulnerability mining device, characterized in that: include: The first module is used to obtain vehicle protocols and vehicle sensor data; The second module is used to generate a target test case according to the vehicle protocol and the vehicle sensor data; The third module is used to perform fuzz testing according to the target test case and obtain the test result; The fourth module is used to verify the potential vulnerability according to the test result to obtain the vulnerability verification result.

8. An electronic device, characterized in that: including a processor and a memory; The memory is used to store programs; The processor executes the program to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The storage medium stores a program, and the program is executed by a processor to implement the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images