Intelligent connected vehicle system safety detection method, device, equipment, storage medium and product

Abstract

The application provides a smart connected vehicle system safety detection method, device, equipment, storage medium and product. The method comprises the following steps: analyzing a target code corresponding to a target vehicle system, determining a syntax tree and a calling component corresponding to the target code; performing vulnerability detection on the target code based on the syntax tree and a preset vulnerability library to obtain a first detection result; performing vulnerability analysis based on the calling component, locating a component containing risks, and obtaining a second detection result; performing fuzzy testing and communication protocol analysis on the target vehicle system to obtain a third detection result; and determining a safety detection result of the target vehicle system according to the first detection result, the second detection result and the third detection result. The safety monitoring can be performed comprehensively in the whole life cycle of software development, and the possible vulnerabilities of the software can be detected comprehensively.

Description

Technical Field

[0001] This application relates to the field of software testing, and in particular to a method, apparatus, equipment, storage medium, and product for safety testing of intelligent connected vehicle systems. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, in-vehicle systems are becoming increasingly complex, software scale is expanding, and the variety of in-vehicle and external communication protocols is increasing, along with the widespread use of open-source components. This has led to a more diversified and in-depth trend in the security threats faced by vehicles. While this trend is driving the intelligence and connectivity of automobiles, it is also significantly expanding the attack surface, transforming vehicle security from traditional physical protection to a multi-layered protection challenge encompassing software and communication security. In this context, traditional single-detection methods are no longer sufficient to cover systemic security risks from the code layer, component layer, to the communication layer.

[0003] In existing technologies, security testing tools are often independent and fragmented, with functions such as static analysis, dynamic testing, component analysis, and protocol verification scattered across different platforms, lacking effective collaboration and data integration. This situation makes it difficult to integrate security testing activities into the entire software development lifecycle, hindering automation and continuous monitoring, resulting in low testing efficiency and incomplete vulnerability discovery. Summary of the Invention

[0004] This application provides a method, apparatus, device, storage medium, and product for security testing of intelligent connected vehicle systems, aiming to solve the technical problem of incomplete vulnerability discovery in related technologies.

[0005] In a first aspect, this application provides a safety detection method for an intelligent connected vehicle system, the method comprising: Analyze the target code corresponding to the target vehicle system to determine the syntax tree and calling components corresponding to the target code; Based on the syntax tree and the preset vulnerability database, vulnerability detection is performed on the target code to obtain a first detection result; Based on the called components, vulnerability analysis is performed to locate components containing risks and obtain a second detection result; Fuzzy testing and communication protocol analysis were performed on the target vehicle system to obtain a third detection result; Based on the first detection result, the second detection result, and the third detection result, the safety detection result of the target vehicle system is determined.

[0006] In some possible implementations, the step of performing fuzz testing and communication protocol analysis on the target vehicle system to obtain a third detection result includes: Based on fuzz test cases, fuzz testing is performed on the target vehicle system to obtain fuzz test results. Based on the test message, the communication protocol corresponding to the target vehicle system is verified, and the protocol analysis results are obtained. Based on the fuzz test results and the protocol analysis results, a third detection result is obtained.

[0007] In some possible implementations, the step of performing fuzz testing on the target vehicle system based on fuzz test cases to obtain fuzz test results includes: Construct multiple fuzz test cases based on a pre-defined fuzz test dictionary; Based on the software interface corresponding to the target vehicle system, each of the fuzzy test cases is input into the target vehicle system and run; Obtain the execution results corresponding to each of the fuzz test cases to obtain the fuzz test results.

[0008] In some possible implementations, the step of verifying the communication protocol corresponding to the target vehicle system based on test messages and obtaining protocol analysis results includes: Generate test messages based on preset requirements; According to the communication protocol corresponding to the target vehicle system, the test message is sent to the target vehicle system. Based on the response of the target vehicle system to the test message, the protocol analysis results are obtained.

[0009] In some possible implementations, generating a test message based on preset requirement information includes: Based on the data model structure of the communication protocol corresponding to the target vehicle system, the generation conditions of the test message are configured according to the preset requirement information. The generation conditions include the data type, numerical boundary and integrity constraint conditions of each field in the test message. A test message is generated based on the given generation conditions.

[0010] In some possible implementations, the vulnerability analysis based on the calling component, locating the component containing the risk, and obtaining the second detection result includes: Based on the calling component, vulnerability analysis is performed to determine that the calling component contains risky component vulnerabilities; Perform vulnerability accessibility analysis on the aforementioned component vulnerabilities to determine whether the component vulnerabilities may be triggered and identify valid vulnerabilities with accessibility risks. Based on the valid vulnerability and the calling component corresponding to the valid vulnerability, a second detection result is obtained.

[0011] In some possible implementations, parsing the target code corresponding to the target vehicle system and determining the syntax tree and calling components corresponding to the target code includes: Read the source code file of the target vehicle system, parse the source code, and obtain the syntax tree corresponding to the target code; Based on the syntax tree, the code call relationship of the source code is determined, the component information of the relevant components in the source code is extracted, and the calling component corresponding to the target code is obtained.

[0012] Secondly, this application provides a safety detection device for an intelligent connected vehicle system, the device comprising: The parsing module is used to parse the target code corresponding to the target vehicle system and determine the syntax tree and calling components corresponding to the target code. The detection module is used to perform vulnerability detection on the target code based on the syntax tree and a preset vulnerability database, and obtain a first detection result; The analysis module is used to perform vulnerability analysis based on the called component, locate the component containing the risk, and obtain a second detection result; The analysis module is also used to perform fuzz testing and communication protocol analysis on the target vehicle system to obtain a third detection result; The determination module is used to determine the safety detection result of the target vehicle system based on the first detection result, the second detection result, and the third detection result.

[0013] Thirdly, this application provides a security testing device for an intelligent connected vehicle system, the device comprising: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the security testing method for an intelligent connected vehicle system as described above.

[0014] Fourthly, this application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the intelligent connected vehicle system security detection method described above.

[0015] Fifthly, this application provides a computer program product in which the instructions are executed by the processor of an electronic device, causing the electronic device to perform the intelligent connected vehicle system security detection method as described above.

[0016] The intelligent connected vehicle system security detection method, apparatus, device, storage medium, and product provided in this application embodiment automatically parses the target code to generate a unified syntax tree and component list, providing a complete and accurate data foundation for subsequent analysis. Then, it performs vulnerability detection based on the syntax tree and component risk analysis based on the component list. Using the syntax tree-based vulnerability detection, it comprehensively investigates possible vulnerabilities in the source code, ensuring that the analysis and verification results of static-level vulnerabilities are not missed. Furthermore, based on the correlation analysis of the risks of components called in the code, it verifies the vulnerability risks and obtains the first detection result and the second detection result. Based on this, fuzz testing and communication protocol analysis are performed on the target vehicle system to comprehensively test various communication protocols used in the vehicle system, and to specifically verify high-risk interfaces and protocol logic to obtain a third detection result. By combining the first, second, and third detection results, the security detection result of the target vehicle system is determined. By using a comprehensive correlation analysis of the results of syntax tree-based vulnerability detection, code association component analysis, fuzz testing, and communication protocol analysis, security detection is carried out, which significantly improves the detection coverage and efficiency. It enables comprehensive security monitoring throughout the entire software development lifecycle and comprehensive detection of potential software vulnerabilities. Attached Figure Description

[0017] This application can be better understood from the following description of specific embodiments in conjunction with the accompanying drawings, wherein: Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings, wherein the same or similar reference numerals denote the same or similar features.

[0018] Figure 1 This is a flowchart of a security detection method for an intelligent connected vehicle system provided in one embodiment of this application; Figure 2 This is a flowchart of a safety detection method for an intelligent connected vehicle system provided in another embodiment of this application; Figure 3 This is a schematic diagram of a security detection system architecture provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of a safety detection device for an intelligent connected vehicle system provided in one embodiment of this application; Figure 5 This is a schematic diagram of the hardware structure of the intelligent connected vehicle system safety testing equipment provided in this application embodiment. Detailed Implementation

[0019] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0020] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0021] With the rapid development of intelligent connected vehicle technology, the demand for security testing of intelligent connected vehicle systems is becoming increasingly urgent. Current technologies lack security testing mechanisms for in-vehicle communication protocols, allowing attackers to control vehicles by forging protocol messages, causing serious security incidents. In-vehicle software is prone to defects such as buffer overflows and uninitialized variables, and traditional manual auditing struggles to cover complex logic. While many open-source components are currently used in intelligent connected vehicles, there is a lack of component vulnerability correlation capabilities, and third-party data auditing services pose a risk of data leakage. Existing security testing tools are significantly fragmented from the collaborative mechanisms across all stages of the software development lifecycle, resulting in low integration and hindering automation and continuous monitoring. Currently, there is an urgent need for a security testing method that integrates static analysis, dynamic testing, component analysis, and protocol verification to address the problems of low testing efficiency, incomplete testing, and fragmented testing processes in existing technologies.

[0022] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, storage medium, and product for security testing of intelligent connected vehicle systems. The security testing method for intelligent connected vehicle systems provided in this application embodiment will be described first below.

[0023] Figure 1A flowchart illustrating a security detection method for an intelligent connected vehicle system according to an embodiment of this application is shown. Figure 1 As shown, the method includes the following steps: S101 to S105.

[0024] S101: Parse the target code corresponding to the target vehicle system, and determine the syntax tree and calling components corresponding to the target code.

[0025] S102: Perform vulnerability detection on the target code based on the syntax tree and the preset vulnerability database to obtain the first detection result.

[0026] S103: Based on the calling components, perform vulnerability analysis, locate the components containing risks, and obtain a second detection result.

[0027] S104: Perform fuzzy testing and communication protocol analysis on the target vehicle system to obtain the third detection result.

[0028] S105: Determine the safety test results of the target vehicle system based on the first test result, the second test result, and the third test result.

[0029] In the specific implementation of S101, a code parsing tool is used to read the target code file and convert it into a structured syntax tree. The parsing process includes lexical analysis to decompose the code into token sequences, and then syntax analysis to construct a tree structure according to the syntax rules of the programming language to represent the logical hierarchy of the code. At the same time, during the parsing process, the calling components are determined by traversing the syntax tree and identifying function calls, library import statements and external dependency references in the code.

[0030] In order to accurately determine the syntax tree and the calling component, the above S101 may include the following steps: S1011 to S1012.

[0031] S1011: Read the source code file of the target vehicle system, parse the source code, and obtain the syntax tree corresponding to the target code.

[0032] S1012: Determine the code call relationship of the source code based on the syntax tree, extract the component information of relevant components in the source code, and obtain the calling component corresponding to the target code.

[0033] In the specific implementation of S1011, one or more source code files from the target vehicle system are loaded through the file system interface. Subsequently, a lexical analyzer and a syntax analyzer matching the source code are invoked to process the loaded source code character stream. The lexical analyzer converts the source code character stream into a series of tokens conforming to the language syntax, such as keywords, identifiers, operators, and constants. The syntax analyzer then organizes the token sequence into a hierarchical, structured tree representation, i.e., a syntax tree, according to predefined language syntax rules. Each node in the syntax tree represents a grammatical structure in the source code.

[0034] In the specific implementation of S1012, a depth-first or breadth-first traversal of the syntax tree is performed. During the traversal, all nodes representing code call relationships are identified and recorded. Specifically, this includes identifying function call expression nodes to record internal function calls, identifying nodes containing file instructions to record header file and external library dependencies, and identifying linker descriptions or library import statements. For each identified call relationship, its associated component information is extracted to obtain the calling component corresponding to the target code.

[0035] The above-described embodiments of this application read the source code file of the target vehicle system, parse the source code, obtain the syntax tree corresponding to the target code, then determine the code call relationship of the source code based on the syntax tree, extract the component information of relevant components in the source code, and obtain the calling component corresponding to the target code, thereby accurately determining the syntax tree and the calling component.

[0036] In the specific implementation of S102, vulnerability detection is performed based on the generated syntax tree and a preset vulnerability database. Specifically, this involves traversing the nodes of the syntax tree and applying rules from the preset vulnerability database for pattern matching. The preset vulnerability database stores signatures of known vulnerabilities, and static analysis algorithms are used to identify potential vulnerabilities during detection. For example, if a "memcpy" function call appears in the syntax tree without checking the buffer size, it matches a vulnerability database rule and is marked as high-risk. The matching results are then summarized into a first detection result, which includes the vulnerability type, location description, and severity level, and output in a structured report format.

[0037] In the specific implementation of S103, vulnerability analysis is performed based on the invoked components. Specifically, this involves querying external vulnerability databases to compare the names and versions of the invoked components. The analysis process includes retrieving known public vulnerability entries for the components and assessing their relevance to the target vehicle system. For example, for components included in the invoked component list, the existence of the component version in the vulnerability database is checked, and relevant high-risk components are located. The location results are then integrated into a second detection result, which details the risk component identifier, vulnerability description, and impact assessment.

[0038] In order to obtain an accurate second detection result, the above S103 may include the following steps: S1031 to S1033.

[0039] S1031: Perform vulnerability analysis based on the called components to identify component vulnerabilities that are risky within the called components.

[0040] S1032: Perform vulnerability accessibility analysis on component vulnerabilities to determine whether the component vulnerability may be triggered and identify valid vulnerabilities with accessibility risks.

[0041] S1033: Based on the valid vulnerability and the calling component corresponding to the valid vulnerability, the second detection result is obtained.

[0042] In the specific implementation of S1031, the information of each component in the list of called components is first used as query input to access one or more authoritative vulnerability databases through a programmatic interface. During the analysis, the component identifier is precisely or fuzzily matched with the records in the vulnerability database to retrieve all publicly disclosed vulnerability entries affecting the specific component and its corresponding version. Subsequently, the matched vulnerability entries are initially filtered and correlated to exclude vulnerabilities that are clearly not applicable to the current target system architecture or environment, thereby initially screening out a set of potential risk component vulnerabilities directly related to the called component.

[0043] In the specific implementation of S1032, context-sensitive analysis is performed based on the parsed source code and syntax tree. For each component vulnerability, the analysis engine traces its call source, locating all specific locations in the source code that call the risky component. Then, through data flow and control flow analysis, it determines whether the parameters or input data passed to the component might originate from untrusted or controllable external interfaces. Simultaneously, it analyzes whether there are corresponding security checks or mitigation measures in the code that could block the vulnerability triggering path. If the analysis indicates that there is at least one code execution path from an external input point to the vulnerability call point that is not adequately blocked by security measures, then the component vulnerability is determined to be accessible in the target system, meaning there is a possibility of successful exploitation, and it is marked as a valid vulnerability.

[0044] In the specific implementation of S1033, each entry marked as a valid vulnerability is bound to the detailed information of its associated calling component, and a risk level assessment is performed on each valid vulnerability according to a predefined evaluation model. Subsequently, all assessed and bound valid vulnerability entries are sorted and organized according to risk level or component classification to generate a detection result report, which serves as the second detection result.

[0045] The above-described implementation method of this application calls a component to perform vulnerability analysis, determines that the called component contains a component vulnerability with risk, and then performs vulnerability accessibility analysis on the component vulnerability to determine whether the component vulnerability may be triggered, and determines that there is a valid vulnerability with accessibility risk. Based on the valid vulnerability and the called component corresponding to the valid vulnerability, an accurate second detection result is obtained.

[0046] In the specific implementation of S104, fuzzing and communication protocol analysis are performed on the target vehicle system. Specifically, fuzzing tools generate random or mutated input data and inject it into the target vehicle system's interface. Simultaneously, system behavior (such as crashes, abnormal outputs, or memory leaks) is monitored to identify potential vulnerabilities. Simultaneously, communication protocol analysis is performed by capturing network traffic and parsing protocol formats to detect defects in protocol implementation, such as authentication bypass or data tampering risks. Finally, the results of fuzzing and protocol analysis are combined into a third detection result.

[0047] To obtain appropriate third-party test results, refer to Figure 2 The above S104 may include the following steps: S201 to S203.

[0048] S201: Based on fuzz test cases, perform fuzz testing on the target vehicle system and obtain fuzz test results.

[0049] S202: Based on the test message, verify the communication protocol corresponding to the target vehicle system and obtain the protocol analysis results.

[0050] S203: Based on the fuzz test results and protocol analysis results, the third detection result is obtained.

[0051] In the specific implementation of S201, a large amount of unexpected or malformed input data is first generated by the fuzzing engine according to predefined protocols or interface specifications. Then, these test cases are automatically and iteratively injected into the interface under test of the target vehicle system. For example, CAN bus message sequences containing abnormal length fields or invalid checksums are sent to the vehicle's electronic control unit via a hardware interface card. During the injection process, the operating status of the target system is monitored synchronously, recording whether it experiences crashes, restarts, memory errors, assertion failures, or functional abnormalities. Finally, all detected abnormal events, the test case data that triggered these events, and the corresponding system status logs are correlated and summarized to form structured fuzzing results.

[0052] To conduct comprehensive software testing, the above S201 may include the following steps: S2011 to S2013.

[0053] S2011: Construct multiple fuzz test cases based on a preset fuzz test dictionary.

[0054] S2012: Based on the software interface corresponding to the target vehicle system, input each fuzzy test case into the target vehicle system and run it.

[0055] S2013: Obtain the execution results corresponding to each fuzz test case to obtain the fuzz test results.

[0056] In the specific implementation of S2011, one or more pre-defined fuzzy test dictionary files are first loaded. These files predefine seed data, data mutation rules, and data pattern templates for generating abnormal input data. Then, a fuzzy test case generation engine automatically constructs a large number of unconventional test cases based on the dictionary content using algorithms. During the construction process, normal or basic message structure templates are read from the dictionary, and mutation rules defined in the dictionary are applied to key fields. These rules indicate operations such as replacing, expanding, truncating, bit-flipping, or inserting random bytes into field values. This yields multiple test cases, each encapsulated in a data format recognizable by the target system interface.

[0057] In the specific implementation of S2012, physical or logical connections are identified and established with the software interfaces of the functional modules or services under test in the target vehicle system. Then, through a test execution controller, data for each fuzzy test case is sent to the target system one by one through the established interfaces, in a preset or random order. The input process needs to simulate the timing and protocol stack of real communication. For example, for test cases sent via the CAN bus, the test controller needs to encapsulate them into CAN data frames with valid identifiers and conforming to bus timing before transmission. For IP services of the vehicle gateway, the test case data needs to be encapsulated into application layer messages conforming to the vehicle Ethernet protocol through socket programming before transmission. Simultaneously with the input of each test case, it is ensured that the target vehicle system enters the corresponding operating state to process the input.

[0058] In the specific implementation of S013, during and after the input operation of each fuzz test case, the operating status feedback of the target system is collected in parallel through multiple monitoring methods. These monitoring methods include, but are not limited to, continuously capturing and recording bus message streams from the target system or the entire vehicle network using bus monitoring tools to observe for abnormal error frames, diagnostic fault code messages, or unexpected response messages. The internal status registers, memory data, or system logs of the target system processor are read through hardware debugging interfaces or embedded log output ports to detect memory access violations. External sensors or actuator status monitoring devices are used to observe whether the vehicle system exhibits any functional abnormalities. Subsequently, each fuzz test case is timestamped and correlated with all monitoring data collected after its input. Finally, all correlated data is analyzed and formatted, and entries indicating system defects, faults, or abnormal behavior are filtered and confirmed, summarizing to form the fuzz test results.

[0059] The above-described implementation method of this application constructs multiple fuzzy test cases according to a preset fuzzy test dictionary, and then inputs each fuzzy test case into the target vehicle system and runs it based on the software interface corresponding to the target vehicle system, thereby obtaining the running results corresponding to each fuzzy test case and obtaining fuzzy test results. Through fuzzy testing, comprehensive software testing is performed.

[0060] In the specific implementation of S202, the communication traffic of the target vehicle's internal network is first monitored in real time through message capture to obtain the actual communication message sequence, or a series of test messages that conform to and violate the protocol specifications are actively constructed according to the protocol standard document and sent to the network. Subsequently, the acquired messages are deeply analyzed, and their compliance is verified according to the protocol format specifications and state machine logic. The analysis process may include checking whether the message identifier and data length code match, whether the signal value is within the valid range, whether the sequence of multi-packet transmission is correct, whether session control processes such as secure access are correctly followed, and whether the periodicity of communication and response timeouts meet the requirements. All discovered protocol violations, inconsistencies, and potential logical defects are categorized and recorded to form the protocol analysis results.

[0061] In order to conduct a comprehensive test of the communication protocol, the above S202 may include the following steps: S2021 to S2023.

[0062] S2021: Generate test messages based on preset requirements.

[0063] S2022: Send a test message to the target vehicle system according to the communication protocol corresponding to the target vehicle system.

[0064] S2023: Based on the target vehicle system's response to the test message, obtain the protocol analysis results.

[0065] In the specific implementation of S2021, a configuration file or database containing specific test requirements is loaded. This requirement information predefines the test objectives, protocol specification entries to be verified, and message construction rules. Subsequently, based on these requirements, a series of test messages are automatically or semi-automatically constructed through a protocol editor or script engine. During the specific generation process, the standard format of the target protocol is parsed, and one or more fields of the message are assigned or modified based on the requirement information. For example, to test the robustness of communication initialization, the requirement might instruct the generation of a transport layer protocol data unit with a sequence number out of range; or, to verify authentication logic, the requirement might instruct the construction of a diagnostic session control request message with a forged or expired security token. This generates a set of test messages with a well-defined structure and clear test objectives.

[0066] In the specific implementation of S2022, a physical and logical connection with the target vehicle system's communication network is first established, and the communication interface parameters are configured to match the target system's protocol stack. Then, using a protocol stack-compatible sending tool, each test message is sent according to the timing, frame format, and communication rules of the corresponding protocol. The sending process must simulate the behavior of a real network node. This step ensures that the test messages are accurately injected into the target vehicle system's network environment in the manner expected by the protocol, so that they can be received and processed by communication entities such as the target electronic control unit or gateway.

[0067] In the specific implementation of S023, all communication traffic on the vehicle network is continuously captured using a bus monitoring tool or network sniffer while and after sending test messages. Subsequently, the captured response messages are timestamped and compared with the original sent test messages. The specific analysis process includes checking the existence of response messages, whether the response delay complies with the protocol timeout rules, whether the response message format conforms to the protocol specification, and whether any error response codes defined by the protocol standard appear. Simultaneously, it monitors whether the network experiences unexpected global impacts due to the injection of test messages, such as abnormal switching of network management modes, a surge in bus error frames, or other abnormal broadcasts. All observed responses, violations, and anomalies are recorded, classified, and evaluated to obtain the protocol analysis results.

[0068] The above-described implementation method of this application generates a test message by pre-setting requirement information, and then sends the test message to the target vehicle system according to the communication protocol corresponding to the target vehicle system. Based on the response of the target vehicle system to the test message, the protocol analysis result is obtained, and a comprehensive test of the communication protocol is performed.

[0069] In order to obtain a suitable test message, the above S2021 may include the following steps: S20211 to S20212.

[0070] S20211: Based on the data model structure of the communication protocol corresponding to the target vehicle system, configure the generation conditions of the test message according to the preset requirement information. The generation conditions include the data type, numerical boundary and integrity constraints of each field in the test message.

[0071] S20212: Generate a test message based on the generation conditions.

[0072] In the specific implementation of S20211, a standardized data model file describing the target communication protocol format is parsed. This data model file defines a structured template for communication messages. Subsequently, based on preset requirements, such as the scenarios to be verified listed in the test plan document, like "verifying signal out-of-range processing" or "verifying the integrity of multi-frame transmission," specific generation conditions are configured for one or more key fields or signals specified in the data model. The data type, numerical boundaries, and integrity constraints for each selected field in this test are clearly defined.

[0073] In the specific implementation of S20212, the set of generation condition rules output from the aforementioned steps is read and executed. A specific numerical value is instantiated for each field. For data types and numerical boundary conditions, values ​​can be selected from preset equivalence classes or boundary values, or test values ​​can be generated within or outside specified boundaries using a random number generator. For integrity constraints, after all field values ​​are instantiated, the correct or incorrect values ​​of the relevant dependent fields are dynamically calculated according to the defined constraint rules. The instantiated values ​​of each field are assembled into a complete and logically coherent protocol message. Finally, this logical message is converted into the original data format that conforms to the requirements of the target network's physical layer and data link layer to obtain the test message.

[0074] The above-described implementation of this application uses a data model structure based on the communication protocol corresponding to the target vehicle system to configure the generation conditions of the test message according to preset requirement information. The generation conditions include the data type, numerical boundaries and integrity constraints of each field in the test message, and then generate the test message according to the generation conditions to obtain a suitable test message.

[0075] In the specific implementation of S203, the raw result data generated in the aforementioned two steps is read and parsed. First, the two types of results are deduplicated and correlated. For example, system anomalies triggered by malformed packets in fuzzing are correlated with corresponding packet format violations found in protocol analysis, thereby confirming the complete trigger path of the vulnerability. Next, the correlated security events are subject to risk assessment and classification. Assessment factors may include the exploitability of the vulnerability, the degree of impact on vehicle functional safety, and whether exploitation conditions such as network physical access are required. Then, all correlated and assessed security issues are summarized in a unified output format. Each entry clearly describes the vulnerability phenomenon, root cause, associated test cases or examples of violating packets, and the identified risk level. Finally, a third detection result is generated. This result serves as a comprehensive security detection sub-report, centrally reflecting the security risks of the target vehicle system at the runtime and communication levels discovered through dynamic testing and protocol conformance testing.

[0076] The above-described implementation method of this application uses fuzz test cases to perform fuzz testing on the target vehicle system, obtains fuzz test results, and then verifies the communication protocol corresponding to the target vehicle system based on the test messages to obtain protocol analysis results. Based on the fuzz test results and protocol analysis results, a third detection result is obtained, thereby obtaining a suitable third detection result.

[0077] In the specific implementation of S105, the security detection result of the target vehicle system is determined based on the first detection result, the second detection result, and the third detection result. Specifically, all results are integrated by using a rule engine or a weighted scoring algorithm. The evaluation process includes prioritizing the severity of vulnerabilities in each detection result, such as assigning higher weights to high-risk vulnerabilities. It can also check the consistency between results, such as verifying the correlation between static detection and dynamic testing. For example, if the first detection result indicates that there is a buffer overflow in the code, and the third detection result confirms the exploitability of the vulnerability through fuzz testing, then the overall security detection result is marked as "unsafe".

[0078] The intelligent connected vehicle system security detection method provided in this application generates a unified syntax tree and component list by automatically parsing the target code, providing a complete and accurate data foundation for subsequent analysis. Then, it performs syntax tree-based vulnerability detection and component list-based component risk analysis. Using syntax tree-based vulnerability detection, it comprehensively investigates potential vulnerabilities in the source code, ensuring that no static-level vulnerability analysis and verification results are missed. Further, based on the correlation analysis of component risks called in the code, it verifies vulnerability risks, obtaining a first detection result and a second detection result. On this basis, it performs fuzz testing and communication protocol analysis on the target vehicle system to comprehensively test various communication protocols used in the vehicle system, specifically verifying high-risk interfaces and protocol logic, obtaining a third detection result. Combining the first, second, and third detection results, it determines the security detection result of the target vehicle system. By comprehensively analyzing the results of syntax tree-based vulnerability detection, code-related component analysis, fuzz testing, and communication protocol analysis, it performs security detection, significantly improving detection coverage and efficiency. It enables comprehensive security monitoring throughout the entire software development lifecycle, comprehensively detecting potential software vulnerabilities.

[0079] In one embodiment of this application, the application's structure and code logic are obtained by scanning the source code. The source code is parsed into a syntax tree, providing an easy-to-understand way to view the application's structure and components. Then, a built-in vulnerability library and rules are used for detection. These vulnerabilities are established based on known security threats and attack methods. Algorithms are also used to discover unknown vulnerabilities, and new rules are automatically created to update the detection library. Fuzzing is performed, supporting methods such as seed mutation, traversal, and file sample sets through a fuzzy dictionary. Related interfaces are exposed, allowing for the implementation of new algorithms, network flow acquisition, and input-feedback-based generation based on agreed-upon interfaces. The generated fuzzy test cases implement specific fuzzy attack processes. The attack algorithms for general protocols are mainly implemented by the module's core engine, while the test cases mainly implement the interactive processing of specific protocols. Expert protocols contain more specialized attack algorithms, and the attack process is more complex and flexible. In most cases, the fuzzing test cases run the above methods in combination.

[0080] Static analysis based on code snippets accurately identifies the list of components actually called in a project. Combined with vulnerability accessibility analysis, it precisely locates risky components and vulnerabilities, reducing the cost of ineffective vulnerability remediation and improving software supply chain security. A custom testing approach is employed, configuring various model structures and components to achieve broader test coverage and improve test accuracy, breaking down data communication barriers between development, testing, maintenance, and management personnel.

[0081] refer to Figure 3During the source code audit process, source code defect detection is performed. It supports source code defect detection for dozens of common programming languages ​​and frameworks, containing over a thousand detection rules. Detectable defect types include buffer overflows, SQL injection, cross-site scripting, code quality issues, and dangerous functions. It pinpoints security issues to specific lines of code and provides detailed information and remediation suggestions for each discovered problem, facilitating more effective problem fixing. The security compliance check section supports source code compliance reviews of various security standards and specifications.

[0082] During fuzzing, a fuzzy dictionary is generated using various methods such as seed mutation, traversal, and file sample sets. Related interfaces are also provided to implement new algorithms, network flow acquisition, and generation based on input feedback. Fuzzy test cases are run, combining general and expert protocol methods to implement specific fuzzy attack processes. A fuzzy virtual terminal, also called a task engine, is run; it is a collection of all testing modules, and several virtual terminals can exist within the same system.

[0083] During software component analysis, multiple programming languages ​​are supported, enabling dependency management and security auditing during the development phase. By combining static and dynamic information, it is used in source-code-less environments such as firmware and images, including intelligent connected vehicle devices and embedded systems. During protocol analysis, a data model is first defined. Fields are added via simple drag-and-drop or right-click selection, defining data types, default values, and constraints. Basic data types are configured, allowing selection and configuration of options such as ordinary elements, strings, integers, bits, and arrays. Different mutation strategies can be defined and selected to mutate existing test cases to generate new ones, recording and tracking the generation and changes of the data model. The number of test sets can be specified, and the system monitors the execution process to ensure coverage of as many scenarios as possible during mutation testing. Real-time monitoring and feedback are provided, including the execution status, execution time, and resulting exceptions for each test case. When potential vulnerabilities are discovered, a detailed vulnerability report is generated. The protocol's state flow is defined, including input / output, function calls, monitoring, and replication, reflecting problems exposed at different stages of the testing process. It integrates a state machine and a packet sender, enabling users to apply the state machine to testing. By embedding the monitor into the protocol's state machine flow, it can accurately pinpoint the state that triggers the vulnerability, helping users analyze the testing process.

[0084] During source code auditing, the source code is read and scanned, examining all files, directories, and libraries in the project, and generating a codebase representing the application's structure. The source code is parsed into a syntax tree, providing an easy-to-understand way to view the application's structure and components. Detection is performed using a built-in vulnerability database and rules, while also employing proprietary algorithms to discover unknown vulnerabilities and automatically creating new rules to update the detection database. Multiple techniques are used to reduce false positives. For example, vulnerabilities existing in specific contexts are marked as low-priority, facilitating developer review. The scan results are generated into an easy-to-understand report, covering all discovered vulnerabilities and recommended remediation measures.

[0085] In the fuzzing process, the input interfaces of the target system are identified, and then test cases are generated or modified and input into the target system. System behavior is monitored, including crashes, assertion failures, and abnormal exits. Test cases that cause abnormal behavior are recorded.

[0086] Based on the intelligent connected vehicle system security detection method provided in the above embodiments, this application also provides specific implementation methods of the intelligent connected vehicle system security detection device. Please refer to the following embodiments.

[0087] First see Figure 4 The intelligent connected vehicle system safety detection device 400 provided in this application embodiment includes the following modules: Parsing module 401 is used to parse the target code corresponding to the target vehicle system and determine the syntax tree and calling components corresponding to the target code.

[0088] The detection module 402 is used to perform vulnerability detection on the target code based on the syntax tree and the preset vulnerability database to obtain the first detection result.

[0089] Analysis module 403 is used to perform vulnerability analysis based on the called components, locate components containing risks, and obtain a second detection result.

[0090] Analysis module 403 is also used to perform fuzz testing and communication protocol analysis on the target vehicle system to obtain a third detection result.

[0091] The determination module 404 is used to determine the safety test results of the target vehicle system based on the first test result, the second test result, and the third test result.

[0092] As one implementation of this application, the analysis module 403 includes: The test unit is used to perform fuzz testing on the target vehicle system based on fuzz test cases and obtain fuzz test results.

[0093] The verification unit is used to verify the communication protocol corresponding to the target vehicle system based on the test message and obtain the protocol analysis results.

[0094] The determination unit is used to obtain the third detection result based on the fuzzy test results and the protocol analysis results.

[0095] As one implementation of this application, the test unit includes: Construct sub-units to build multiple fuzz test cases based on a preset fuzz test dictionary.

[0096] The input subunit is used to input and run various fuzzy test cases into the target vehicle system based on the software interface corresponding to the target vehicle system.

[0097] The sub-unit is used to obtain the running results corresponding to each fuzz test case, thus obtaining the fuzz test results.

[0098] As one implementation of this application, the verification unit includes: The generation subunit is used to generate test messages based on preset requirements.

[0099] The sending subunit is used to send test messages to the target vehicle system according to the communication protocol corresponding to the target vehicle system.

[0100] The sub-unit is determined to obtain protocol analysis results based on the target vehicle system's response to the test message.

[0101] As one implementation of this application, generating sub-units includes: The generation subunit is also used to configure the generation conditions of test messages based on the data model structure of the communication protocol corresponding to the target vehicle system and according to the preset requirement information. The generation conditions include the data type, numerical boundaries and integrity constraints of each field in the test message.

[0102] The generation subunit is also used to generate test messages based on the generation conditions.

[0103] As one implementation of this application, the analysis module 403 includes: The identification unit is used to perform vulnerability analysis based on the invoked components and to identify component vulnerabilities that are risky within the invoked components.

[0104] The judgment unit is used to perform vulnerability accessibility analysis on component vulnerabilities, determine whether the component vulnerability may be triggered, and identify valid vulnerabilities with accessibility risks.

[0105] The determination unit is used to obtain the second detection result based on the valid vulnerability and the calling component corresponding to the valid vulnerability.

[0106] As one implementation of this application, the parsing module 401 includes: The reading unit is used to read the source code file of the target vehicle system, parse the source code, and obtain the syntax tree corresponding to the target code.

[0107] The determination unit is used to determine the code call relationship of the source code based on the syntax tree, extract the component information of relevant components in the source code, and obtain the calling component corresponding to the target code.

[0108] Each module in the intelligent connected vehicle system security detection device provided in this application embodiment can implement each step in the above-mentioned intelligent connected vehicle system security detection method and achieve the corresponding effect. For the sake of brevity, it will not be described in detail here.

[0109] Figure 5 A schematic diagram of the structure of the security detection hardware for the intelligent connected vehicle system provided in an embodiment of this application is shown.

[0110] The safety testing equipment for intelligent connected vehicle systems may include a processor 501 and a memory 502 storing computer program instructions.

[0111] Specifically, the processor 501 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0112] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 502 is non-volatile solid-state memory.

[0113] The memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the intelligent connected vehicle system security detection method according to any embodiment of this disclosure.

[0114] The processor 501 reads and executes computer program instructions stored in the memory 502 to implement any of the intelligent connected vehicle system safety detection methods in the above embodiments.

[0115] In one example, the intelligent connected vehicle system safety testing equipment may also include a communication interface 503 and a bus 510. For example, Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.

[0116] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0117] Bus 510 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0118] Furthermore, in conjunction with the methods for security detection of intelligent connected vehicle systems described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the security detection methods for intelligent connected vehicle systems described in the above embodiments.

[0119] This application also provides a computer program product, including a computer program, which, when executed, implements any of the methods for safety detection of intelligent connected vehicle systems described in the above embodiments.

[0120] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0121] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0122] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0123] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can also be implemented by an FPGA performing the specified functions or actions, or can be implemented by a combination of an FPGA and computer instructions.

[0124] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A safety detection method for an intelligent connected vehicle system, characterized in that, The method includes: Analyze the target code corresponding to the target vehicle system to determine the syntax tree and calling components corresponding to the target code; Based on the syntax tree and the preset vulnerability database, vulnerability detection is performed on the target code to obtain a first detection result; Based on the called components, vulnerability analysis is performed to locate components containing risks and obtain a second detection result; Fuzzy testing and communication protocol analysis were performed on the target vehicle system to obtain a third detection result; Based on the first detection result, the second detection result, and the third detection result, the safety detection result of the target vehicle system is determined.

2. The safety detection method for intelligent connected vehicle systems according to claim 1, characterized in that, The third detection result obtained by performing fuzz testing and communication protocol analysis on the target vehicle system includes: Based on fuzz test cases, fuzz testing is performed on the target vehicle system to obtain fuzz test results. Based on the test messages, the communication protocol corresponding to the target vehicle system is verified, and the protocol analysis results are obtained. Based on the fuzz test results and the protocol analysis results, a third detection result is obtained.

3. The safety detection method for intelligent connected vehicle systems according to claim 2, characterized in that, The step of performing fuzz testing on the target vehicle system based on fuzz test cases to obtain fuzz test results includes: Construct multiple fuzz test cases based on a pre-defined fuzz test dictionary; Based on the software interface corresponding to the target vehicle system, each of the fuzzy test cases is input into the target vehicle system and run; Obtain the execution results corresponding to each of the fuzz test cases to obtain the fuzz test results.

4. The safety detection method for intelligent connected vehicle systems according to claim 2, characterized in that, The step of verifying the communication protocol corresponding to the target vehicle system based on test messages and obtaining protocol analysis results includes: Generate test messages based on preset requirements; According to the communication protocol corresponding to the target vehicle system, the test message is sent to the target vehicle system. Based on the response of the target vehicle system to the test message, the protocol analysis results are obtained.

5. The safety detection method for intelligent connected vehicle systems according to claim 4, characterized in that, The step of generating a test message based on preset requirement information includes: Based on the data model structure of the communication protocol corresponding to the target vehicle system, the generation conditions of the test message are configured according to the preset requirement information. The generation conditions include the data type, numerical boundary and integrity constraint conditions of each field in the test message. A test message is generated based on the given generation conditions.

6. The safety detection method for intelligent connected vehicle systems according to claim 1, characterized in that, The vulnerability analysis based on the called component, locating components containing risks, and obtaining a second detection result includes: Based on the calling component, vulnerability analysis is performed to determine that the calling component contains risky component vulnerabilities; Perform vulnerability accessibility analysis on the aforementioned component vulnerabilities to determine whether the component vulnerabilities may be triggered and identify valid vulnerabilities with accessibility risks. Based on the effective vulnerability and the calling component corresponding to the effective vulnerability, a second detection result is obtained.

7. The safety testing method for intelligent connected vehicle systems according to any one of claims 1 to 6, characterized in that, The process of parsing the target code corresponding to the target vehicle system and determining the syntax tree and calling components corresponding to the target code includes: Read the source code file of the target vehicle system, parse the source code, and obtain the syntax tree corresponding to the target code; Based on the syntax tree, the code call relationship of the source code is determined, the component information of the relevant components in the source code is extracted, and the calling component corresponding to the target code is obtained.

8. A safety detection device for an intelligent connected vehicle system, characterized in that, The device includes: The parsing module is used to parse the target code corresponding to the target vehicle system and determine the syntax tree and calling components corresponding to the target code. The detection module is used to perform vulnerability detection on the target code based on the syntax tree and a preset vulnerability database, and obtain a first detection result; The analysis module is used to perform vulnerability analysis based on the called component, locate the component containing the risk, and obtain a second detection result; The analysis module is also used to perform fuzz testing and communication protocol analysis on the target vehicle system to obtain a third detection result; The determination module is used to determine the safety detection result of the target vehicle system based on the first detection result, the second detection result, and the third detection result.

9. A safety testing device for intelligent connected vehicle systems, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the intelligent connected vehicle system safety detection method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the intelligent connected vehicle system safety detection method as described in any one of claims 1-7.

11. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the functions as described in the claims.

7. Safety testing method for intelligent connected vehicle system as described in any one of the above.

Images