Multi-ECU (Electronic Control Unit) collaborative simulation vulnerability mining method and device for intelligent networked automobile

Abstract

The invention relates to a multi-ECU co-simulation vulnerability mining method and device for an intelligent networked automobile, and the method comprises the steps: carrying out the extraction according to the architecture data and firmware data of electronic control units corresponding to different architectures, and obtaining the interaction characteristics of the electronic control units of all architectures and peripherals, and the firmware configuration templates of the electronic control units of all architectures; integrating the data of the plurality of first simulators to obtain a second simulator; in the second simulator, restoring a network topology structure of a network layer corresponding to the firmware according to the interaction characteristics, and creating a plurality of firmware simulation examples according to the firmware configuration template and the network topology structure to obtain an in-vehicle network simulation environment; determining a network layer corresponding to the firmware according to the interaction characteristics, and performing firmware simulation in the network layer according to a firmware configuration template to obtain an in-vehicle network simulation environment; and running the test case for firmware vulnerability mining in the in-vehicle network simulation environment to obtain vulnerability information. By adopting the method, vulnerability mining can be performed on a multi-ECU interaction scene in a simulation environment.

Description

Technical Field

[0001] The present application relates to the field of intelligent connected vehicles, and in particular to a multi-ECU collaborative simulation vulnerability mining method and device for intelligent connected vehicles. Background Art

[0002] Electronic Control Units (ECUs) are crucial to today's connected vehicles, playing a crucial role in system control. ECUs manage and control core vehicle functions, including the engine, transmission, braking system, steering system, airbags, suspension, and other low-level critical systems, ensuring vehicle stability, responsiveness, and safety. Modern smart cars are often equipped with multiple ECUs, working together to maintain complex vehicle control and safety features.

[0003] With the increasing popularity of smart vehicles, the control scope and complexity of ECUs are also expanding. However, these core control systems face severe security challenges. ECUs are typically interconnected via bus protocols such as CAN (Controller Area Network) and Ethernet, forming a complex in-vehicle network. While this network structure improves the control efficiency and system integration of smart vehicles, it also provides potential attack points for attackers. If the security protection of the vehicle network is insufficient, attackers may use vulnerability exploitation and network attacks to interfere with or control underlying critical systems. For example, they can exploit vulnerabilities such as buffer overflows and memory out-of-bounds vulnerabilities to remotely control the vehicle, tamper with or block control signals, and cause vehicle loss of control, seriously endangering the lives of drivers and passengers. Therefore, ECU security testing is crucial to ensure the stability and reliability of the underlying systems in the face of various potential threats. Static analysis in related technologies has limited vulnerability discovery effectiveness, while dynamic simulation is costly. Applying this technology to ECU firmware presents significant difficulties and challenges, making dynamic simulation of multiple ECU firmware difficult.

[0004] There is currently no effective solution to the problem of difficulty in simulating and testing multi-ECU interactions in related technologies. Summary of the Invention

[0005] Based on this, it is necessary to provide a multi-ECU collaborative simulation vulnerability mining method and device for intelligent connected vehicles that can solve the difficulty of simulating and testing the interaction of multiple ECUs in response to the above technical problems.

[0006] First, in this embodiment, a multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles is provided, the method comprising:

[0007] Extracting, based on architecture data and firmware data corresponding to electronic control units of different architectures, interaction features between the electronic control unit and peripherals of each architecture, as well as firmware configuration templates in the electronic control unit of each architecture;

[0008] integrating data of the plurality of first simulators to obtain a second simulator;

[0009] In the second simulator, the network topology structure of the network layer corresponding to the firmware is restored according to the plurality of interaction features, and a plurality of firmware simulation instances are created according to the firmware configuration template and the network topology structure to obtain an in-vehicle network simulation environment;

[0010] In some embodiments, the firmware configuration templates in the electronic control units of different architectures are extracted based on the architecture data and firmware data of the electronic control units of different architectures, including:

[0011] Compiling the code in the architecture data to obtain symbolic information of the firmware;

[0012] Obtaining architectural features of the firmware according to the description document in the architecture data;

[0013] Obtaining semantic information of the firmware according to binary file data in the firmware data;

[0014] The firmware configuration template is constructed based on the symbolic information, the architectural features, the semantic information, and the descriptive information in the firmware data.

[0015] In some embodiments, constructing the firmware configuration template from the symbolic information, the architectural features, the semantic information, and the descriptive information in the firmware data includes:

[0016] verifying the semantic information based on the symbolic information;

[0017] The firmware configuration template is obtained by combining the symbolic information, the architectural features, the verified semantic information, and the descriptive information.

[0018] In some embodiments, extracting interaction features of peripherals in the electronic control unit based on architecture data and firmware data in the electronic control unit includes:

[0019] Compiling the code in the architecture data to obtain symbolic information of the firmware;

[0020] Determining an interaction interface between the electronic control unit and the peripheral device according to the description document in the architecture data;

[0021] determining interaction information between the electronic control unit and the peripheral device according to the reverse code information in the firmware data;

[0022] The interaction feature contained in the interaction information is extracted based on the symbol information and the interaction interface.

[0023] In some embodiments, integrating data from a plurality of first simulators to obtain a second simulator includes:

[0024] Extracting a plurality of first codes implementing CPU instructions from the first simulators;

[0025] transcribing the first code into a target programming language to obtain a second code;

[0026] A plurality of the second codes are integrated to obtain the second simulator.

[0027] In some embodiments, restoring the network topology of the network layer corresponding to the firmware based on the plurality of interaction features, and creating a plurality of firmware simulation instances in the network layer based on the firmware configuration template and the network topology to obtain an in-vehicle network simulation environment includes:

[0028] When it is determined based on the interaction characteristics that the firmware interacts with the network layer of the Ethernet, restoring the network topology of the Ethernet based on the interaction characteristics and the firmware data, and creating a firmware simulation instance based on the firmware configuration template at a node of the network topology;

[0029] When it is determined based on the interaction characteristics that the firmware interacts with the network layer of the controller area network, creating a firmware simulation instance based on the firmware configuration template, configuring a data interface of the network layer of the controller area network for the firmware simulation instance, and building a simulated controller area network bus to connect the node where the firmware simulation instance is located;

[0030] When it is determined based on the interaction characteristics that the firmware interacts with the network layer of the Ethernet and the network layer of the controller area network, a firmware simulation instance is created at the network layer of the Ethernet based on the firmware configuration template, and a data interface of the network layer where the controller area network is located is configured for the firmware simulation instance, connecting the data interface of the network layer where the controller area network is located and the simulated controller area network bus.

[0031] In some embodiments, before executing a test case for firmware vulnerability discovery in the in-vehicle network simulation environment to obtain vulnerability information, the method further includes:

[0032] Obtaining a data transmission path based on firmware data in the electronic control unit and information identification during firmware operation;

[0033] The test case is generated according to the data transmission path.

[0034] Secondly, in this embodiment, a multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles is provided, the device comprising:

[0035] A simulator construction module, configured to integrate data of a plurality of first simulators to obtain a second simulator;

[0036] a firmware common feature extraction module, configured to extract firmware configuration templates in the electronic control units of different architectures based on architecture data and firmware data corresponding to the electronic control units of different architectures;

[0037] A peripheral device simulation module is configured to extract interaction features between the electronic control unit and the peripheral device of each architecture based on architecture data and firmware data corresponding to the electronic control unit of different architectures;

[0038] an in-vehicle network environment construction module, configured to restore, in the second simulator, a network topology structure of a network layer corresponding to the firmware based on the plurality of interaction features, and to create a plurality of firmware simulation instances based on the firmware configuration template and the network topology structure, thereby obtaining an in-vehicle network simulation environment;

[0039] The vulnerability mining module is used to run test cases for firmware vulnerability mining in the in-vehicle network simulation environment to obtain vulnerability information.

[0040] In some embodiments, the apparatus further includes: an automatic capture module; wherein the automatic capture module is configured to obtain architecture data, firmware data, and data of the first simulator of the electronic control unit.

[0041] In a third aspect, a computer device is provided in this embodiment, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles described in the first aspect above is implemented.

[0042] Fourthly, in this embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles described in the first aspect above is implemented.

[0043] In a fifth aspect, a computer program product is provided in this embodiment, including a computer program, which, when executed by a processor, implements the multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles described in the first aspect above.

[0044] The above-mentioned multi-ECU collaborative simulation vulnerability mining method and device for intelligent connected vehicles obtains firmware-related peripheral interaction characteristics and firmware configuration templates through the architecture data and firmware data of the electronic control unit, and quickly builds a high-fidelity ECU firmware simulation instance based on the peripheral interaction characteristics, firmware configuration template and the integrated simulator. By restoring the vehicle network topology and building a simulation network to connect each firmware simulation instance, an in-vehicle network simulation environment that supports multi-ECU firmware simulation operation is established. Collaborative testing of multiple ECUs is performed in the simulation environment, realizing vulnerability mining for multi-ECU interaction scenarios in the simulation environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 A hardware structure block diagram of a terminal for a multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles in one embodiment;

[0046] Figure 2 A flowchart of a multi-ECU collaborative simulation vulnerability discovery method for intelligent connected vehicles in one embodiment is provided;

[0047] Figure 3 A flowchart of vulnerability discovery steps for multi-ECU collaborative simulation of intelligent connected vehicles in another embodiment;

[0048] Figure 4 A structural block diagram of a multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles in one embodiment;

[0049] Figure 5 A structural block diagram of a multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles in another embodiment;

[0050] Figure 6 Schematic diagram of a firmware common feature extraction module in one embodiment;

[0051] Figure 7 A schematic diagram of a simulator building block in one embodiment;

[0052] Figure 8 is a schematic diagram of a peripheral simulation module in one embodiment;

[0053] Figure 9 is a schematic diagram of an in-vehicle network environment simulation module in one embodiment;

[0054] Figure 10 A schematic diagram of a vulnerability mining module in one embodiment;

[0055] Figure 11 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0057] Traditionally, a variety of techniques have been proposed for vulnerability discovery, including static analysis, fuzz testing, symbolic execution, and dynamic analysis. Static analysis is fast, comprehensive, and easy to develop, but it also has a high false positive rate and relies heavily on symbolic and decompiled information. Its effectiveness is very limited when targeting binary files like ECU firmware, which lack symbolic information. Symbolic execution offers high path coverage and can accurately locate vulnerabilities, but it places stringent demands on computer performance, and its analysis speed cannot meet the security testing requirements of ECU firmware. Simulator-based vulnerability discovery methods and fuzz testing can effectively identify issues that arise during firmware runtime. However, due to the high cost of implementing dynamic simulation for new architectures, applying this technology to ECU firmware presents significant difficulties and challenges, and security testing tools capable of dynamic simulation of multiple ECU firmware are few and far between.

[0058] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. For example, running on a terminal, Figure 1 This is a hardware structure diagram of a terminal for a multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles according to an embodiment of the present application. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown) a processor 102 and a memory 104 for storing data, wherein the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA. The above terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0059] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, implementing the above-mentioned method. The memory 104 may include a high-speed random access memory and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0060] The transmission device 106 is used to receive or send data via a network. The network may include a wireless network provided by the terminal's telecommunications provider. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0061] In one embodiment, Figure 2 As shown in FIG, a multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles is provided, which includes the following steps:

[0062] Step S202 : extracting interaction features between the electronic control unit of each architecture and the peripheral device, and a firmware configuration template in the electronic control unit of each architecture based on the architecture data and firmware data corresponding to the electronic control units of different architectures.

[0063] Among them, the architecture data is the sample code under different architectures, the composition of the hardware and software inside the ECU, and the description data of the architecture, including but not limited to the memory mapping table, addressing mode, machine instructions, register functions, etc. in the ECU. The firmware data is the disassembled / decompiled code of the ECU firmware and the OTA (Over-The-Air technology) firmware update package. The ECU interacts with a variety of peripherals, including but not limited to the ECU's input and output devices, sensors, actuators, etc. The interaction features include but are not limited to one or more of the following features: the communication interface used for interaction, the specific verification data sent during interaction, etc. The firmware configuration template is used to define the parameters and structure during firmware simulation. The firmware configuration template includes but is not limited to one or more of the following information: peripheral configuration, communication configuration, and configuration format.

[0064] Optionally, relevant data of electronic control units under different architectures are obtained, and the data related to each electronic control unit are classified according to the architecture. One or more peripherals that interact with the electronic control unit are determined based on the architecture data and firmware data of the electronic control unit under the same classification, and interaction characteristics are obtained based on the communication process when the electronic control unit interacts with the peripherals. Based on the architecture data and firmware data of the electronic control unit under the same classification, the common characteristics of multiple firmware configurations under the same architecture classification are obtained, and based on the common characteristics of the firmware, a universal configuration module supporting a single architecture, i.e., a firmware configuration template, is obtained. Furthermore, by collecting corresponding data of multiple different architectures, firmware configuration templates under different architecture classifications are constructed respectively, and a firmware configuration template library supporting multiple architectures is constructed.

[0065] Step S204: integrating data of multiple first simulators to obtain a second simulator.

[0066] The first simulator may be a single simulator or may include multiple simulators. The second simulator is a multi-architecture simulator constructed by combining the single simulator and / or multiple simulators. Optionally, a simulator that can accommodate multiple simulator codes can be obtained, and the codes of the multiple simulators can be written and integrated under the simulator to obtain the second simulator.

[0067] Step S206 , in the second simulator, the network topology structure of the network layer corresponding to the firmware is restored according to the multiple interaction features, and multiple firmware simulation instances are created according to the firmware configuration template and the network topology structure to obtain an in-vehicle network simulation environment.

[0068] The network layer includes an Ethernet network layer and / or a controller area network network layer. Optionally, based on the interaction characteristics between the firmware and the peripheral device, the network layer involved in the firmware interaction is determined, and the network topology is constructed. Based on the network topology, multiple firmware simulation instances are established in the network layer according to the firmware configuration template to achieve collaborative simulation of multiple firmwares.

[0069] Step S208 : running a test case for firmware vulnerability mining in the in-vehicle network simulation environment to obtain vulnerability information.

[0070] Optionally, static taint analysis methods are used to analyze firmware data, and / or dynamic analysis methods are used to analyze the running firmware to identify potential attack points and attack paths. Based on this information, test cases are then developed to identify firmware vulnerabilities. Optionally, the test cases trigger vulnerabilities in the ECU firmware via a communication network within an in-vehicle network simulation environment to obtain vulnerability information.

[0071] In the above-mentioned multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles, a second simulator is constructed to support the collaborative simulation of multiple heterogeneous ECUs, a firmware configuration template is constructed to meet the needs of quickly building firmware simulation instances, and peripheral modeling is performed by obtaining the interaction characteristics between firmware and peripherals to obtain a highly realistic firmware simulation environment. By restoring the network topology and building a simulation network, the collaborative interconnection of ECU firmware is supported to obtain a highly realistic in-vehicle network simulation environment, effective ECU firmware security testing is carried out, and potential vulnerabilities in the collaborative operation of multiple ECU firmware are mined, solving the problem of difficulty in simulation testing in multi-ECU interaction scenarios.

[0072] In one embodiment, based on the architecture data and firmware data of electronic control units corresponding to different architectures, a firmware configuration template in the electronic control units of each architecture is extracted, including: compiling the code in the architecture data to obtain symbolic information of the firmware; obtaining architectural features of the firmware based on the description document in the architecture data; obtaining semantic information of the firmware based on the binary file data in the firmware data; and constructing a firmware configuration template based on the symbolic information, architectural features, semantic information and descriptive information in the firmware data.

[0073] The firmware's symbolic information includes data generated during the firmware compilation process, including but not limited to the names of symbols such as functions and variables in the firmware program. The firmware's semantic information is used to describe the firmware's logic for executing corresponding functions, processing data, and interacting with the outside world. The firmware's architectural characteristics are the characteristics of the firmware's organizational structure. Optionally, the firmware's metadata, name, and functional overview are obtained based on the OTA firmware update package data in the firmware data, and descriptive information is obtained by integrating the firmware's metadata, name, functional overview, and other information.

[0074] Optionally, the architecture data includes architecture example code and architecture document. The architecture example code is processed by the forward compilation method to obtain firmware with symbolic information. The AI ​​(Artificial Intelligence) large model is pre-trained to obtain a first model with the function of extracting semantic information. The semantic information in the architecture document is extracted by the first model to obtain the architectural features of the firmware. The semantic information in the firmware is obtained by disassembling / compiling the code of the ECU firmware. The AI ​​large model is pre-trained to obtain a second model with the functions of semantic organization and template construction. The symbolic information, architecture features and semantic information are input into the second model, and the common features of the firmware are extracted by the second model, thereby constructing a universal firmware configuration template.

[0075] In related technologies, due to the strong coupling between software and hardware, ECUs lack an operating system and interact directly with hardware. This requires manual organization and implementation of the firmware startup process, increasing the workload of dynamic simulation and requiring manual ECU simulation, leading to high labor costs for ECU simulation. In this embodiment, by constructing a firmware configuration template, firmware simulation of multiple firmware can be quickly and cost-effectively implemented, significantly reducing the labor costs required for running firmware simulations.

[0076] Furthermore, in one embodiment, a firmware configuration template is constructed from symbolic information, architectural features, semantic information, and descriptive information in the firmware data, including: verifying the semantic information based on the symbolic information; and obtaining the firmware configuration template by combining the symbolic information, architectural features, verified semantic information, and descriptive information. Optionally, after obtaining the semantic information in the firmware by reverse-analyzing the ECU firmware, the semantic information is verified based on the symbolic information to ensure the accuracy of the semantic information obtained during the reverse analysis process. Common features in the verified semantic information and architectural data are extracted to obtain the firmware configuration template. In this embodiment, accurate semantic information is obtained through the verification method, thereby improving the accuracy of the constructed firmware configuration template.

[0077] In one embodiment, interaction features of peripherals in the electronic control unit are extracted based on architecture data and firmware data in the electronic control unit, including: compiling the code in the architecture data to obtain symbolic information of the firmware; determining the interaction interface between the electronic control unit and the peripherals based on the description document in the architecture data; determining the interaction information between the electronic control unit and the peripherals based on the reverse code information in the firmware data; and extracting interaction features contained in the interaction information based on the symbolic information and the interaction interface.

[0078] Interaction features include the firmware's interaction rules between the CPU and peripherals, as well as the peripheral classification logic. This classification logic can be used to derive information about the type and interface of the peripherals interacting with the CPU. Information about interactions between the electronic control unit and peripherals includes, but is not limited to, instructions sent by the ECU to the peripherals, data collected by the peripherals and fed back to the ECU, and feedback data generated by the peripherals in response to ECU instructions.

[0079] Optionally, the code in the architecture data is an architecture example code, and the architecture example code is processed by a forward compilation method to obtain firmware with symbolic information. Optionally, a large AI model is pre-trained to obtain a third model with a semantic information extraction function, and the third model outputs information involved in the firmware interaction process such as peripheral addresses and register types in the architecture according to the architecture document. Optionally, the code in the firmware data is reverse analyzed to obtain reverse code information and determine the interaction information; based on the symbolic information and interaction interface, the interaction rules contained in the interaction information are extracted for different architecture data respectively, and the interaction rules of different peripherals are summarized to obtain the peripheral classification logic.

[0080] Furthermore, after extracting the interaction features, peripheral modeling can be implemented based on the interaction features in the in-vehicle network simulation environment. Optionally, the interface for interaction between the firmware and the peripheral is determined based on the interaction features. When the ECU firmware requests peripheral input, the data from the firmware-peripheral interaction is obtained based on the interaction features and input into the firmware-peripheral interaction interface to ensure successful peripheral modeling. If no relevant interaction rules specify data for the firmware-peripheral interaction interface, random input is provided.

[0081] ECU firmware frequently interacts with numerous peripherals, including sensors, actuators, and buses. This requires simulating these peripherals simultaneously with the ECU, significantly increasing the difficulty and workload of dynamic ECU firmware simulation. This, combined with the lack of universal peripheral simulation methods, results in low code coverage during firmware simulation. In this embodiment, extracting interaction features allows for the provision of appropriate peripheral input during firmware simulation, ensuring the reliability and integrity of the firmware simulation and significantly improving code coverage within the simulated environment.

[0082] In one embodiment, integrating data of multiple first simulators to obtain a second simulator includes: extracting first codes that implement CPU instructions in multiple first simulators; transcribing the first codes into a target programming language to obtain second codes; and integrating multiple second codes to obtain the second simulator.

[0083] The first code implementing the CPU instructions is the CPU (Central Processing Unit) instruction implementation code for a single architecture in the first simulator; the second simulator can be obtained by integrating the CPU instruction implementation codes of multiple different architectures. Optionally, after extracting the CPU instructions of the first simulator, the CPU instruction implementation code is transcribed and / or translated into code in a unified target programming language, and the transcribed and / or translated CPU instruction implementation code is integrated and compiled to obtain the second simulator.

[0084] Due to the heterogeneity of the CPUs used in ECUs, their architectures and instruction sets vary and are incompatible with mainstream IoT chip architectures, making it difficult to dynamically simulate heterogeneous ECU firmware using a single universal simulator tool. In this embodiment, by extracting the CPU instructions of the first simulator, the second simulator can support the simulation of CPUs with multiple architectures, achieving heterogeneous support. Based on a universal simulator capable of supporting the simulation of heterogeneous in-vehicle ECUs, i.e., the second simulator, the testability and test efficiency of ECU firmware can be greatly improved, thereby solving the problem of supporting the simulation of multiple heterogeneous ECUs.

[0085] In related technologies, different ECU firmware uses different channels and protocols for communication, including the Ethernet network layer in addition to the CAN bus. In the absence of design documentation for intelligent connected vehicles, restoring the network topology of the ECU firmware becomes a major challenge in multi-ECU simulation.

[0086] In response to the problem in related technologies that the in-vehicle network structure cannot be restored to perform multi-ECU simulation, in one embodiment, the network topology structure of the firmware corresponding to the network layer is restored according to multiple interaction characteristics, and multiple firmware simulation instances are created in the network layer according to the firmware configuration template and the network topology structure to obtain an in-vehicle network simulation environment, including: when it is determined based on the interaction characteristics that the firmware interacts with the network layer of Ethernet, the network topology structure of Ethernet is restored according to the interaction characteristics and firmware data, and a firmware simulation instance is created according to the firmware configuration template at the node of the network topology structure; when it is determined based on the interaction characteristics that the firmware interacts with the network layer of the controller area network, a corresponding firmware simulation instance is created according to the firmware configuration template, and a data interface of the network layer of the controller area network is configured for the firmware simulation instance, and a simulated controller area network bus is constructed to connect the node where the firmware simulation instance is located; when it is determined based on the interaction characteristics that the firmware interacts with the network layer of Ethernet and the network layer of the controller area network, a firmware simulation instance is created according to the firmware configuration template at the network layer of Ethernet, and a data interface of the network layer of the controller area network is configured for the firmware simulation instance, and the data interface of the network layer where the controller area network is located is connected to the simulated controller area network bus.

[0087] Among them, the interaction features include but are not limited to the network layer that interacts with the firmware, and the interface for the firmware to interact with peripherals. Optionally, when the network layer is the network layer of Ethernet, the network layer and interface for the firmware to interact with peripherals, and the OTA firmware update package information are obtained based on the interaction features when multiple firmware interact with peripherals, and the network topology structure of the Ethernet network layer is constructed; optionally, the central gateway is the one with more than or equal to 1 interaction interface, and the rest are domain control gateways, such as the body control domain, etc.; the domain control gateways are connected to the central gateway respectively to construct the network topology structure of the Ethernet network layer. Construct a simulation network with reference to the network topology structure, set a container at each node of the network topology structure, and create corresponding firmware simulation instances in each container set in the Ethernet network layer according to the firmware configuration template.

[0088] Optionally, when the network layer is the network layer of a controller area network, after firmware emulation is performed on the network layer of the controller area network, the data interfaces of the network layer of the controller area network in each firmware emulation instance are connected to construct a communication loop for the network layer of the controller area network. Based on the descriptive information in the OTA firmware update package, the domain to which the firmware belongs is determined; further, the data interface of the network layer of the controller area network configured in the firmware emulation instance is connected to the virtual bus of the controller area network, and a separate controller area network virtual bus is constructed for each domain to facilitate the broadcast of CAN signals within the domain.

[0089] In this embodiment, a virtual simulation environment for in-vehicle network testing is accurately constructed through interactive features, ensuring that multiple ECU firmware simulation instances can run simultaneously and communicate with each other normally.

[0090] In one embodiment, in a second simulator, a test case for firmware vulnerability mining is run in an in-vehicle network simulation environment. Before obtaining vulnerability information, the method further includes: obtaining a data transmission path based on the firmware data in the electronic control unit and the information during firmware runtime; and generating a test case based on the data transmission path.

[0091] The data transmission path includes potential attack entries and attack paths during the operation of the firmware. Optionally, the firmware data is statically analyzed to obtain potential attack entries and / or attack paths. In vehicle simulation, the running firmware is dynamically analyzed by a dynamic instrumentation method to obtain attack entries and / or attack paths. Combining the output information of static analysis and dynamic instrumentation analysis, the data transmission path is obtained, and then the potential attack path is inferred. Optionally, a fuzz testing engine is used to generate test cases based on the potential attack path. In this embodiment, constructing test cases by analyzing the data transmission path helps to form a low-cost, fast and effective method for multi-ECU firmware vulnerability mining on board.

[0092] In one embodiment, another multi-ECU firmware collaborative simulation vulnerability mining method for intelligent connected vehicles is provided to address the problems of high overhead, slow speed, low detection coverage and inability to test multi-ECU interactions in traditional testing tools for ECU firmware.

[0093] Figure 3 A flowchart of another multi-ECU firmware collaborative simulation vulnerability mining method for intelligent connected vehicles is provided, such as Figure 3 As shown, the steps include:

[0094] Step S301: Collect architecture data, firmware data, and first simulator data for different architectures. The architecture data includes architecture documentation and architecture sample code, the firmware data includes multiple existing ECU firmwares, and the first simulator data includes simulator source code and / or tools corresponding to different architectures.

[0095] Optionally, the firmware data collection process includes one or more of the following methods: crawling publicly available ECU firmware resources online; automating and maximizing ECU firmware acquisition by intercepting firmware download links during remote updates. Remote updates can be over-the-air (OTA) firmware updates. After acquiring the firmware data, a firmware dataset containing multiple architectures and versions is created based on the architecture and firmware version.

[0096] Step S302: extract common features between heterogeneous ECU firmware with different functions and generate a universal firmware configuration template. The universal firmware configuration module can reduce the threshold and labor cost of creating subsequent firmware simulation running instances.

[0097] Optionally, the architecture sample code collected in step S301 is forward compiled to obtain firmware with symbolic information. A first model is used to extract architecture documentation and OTA package information to obtain information such as the firmware startup process, memory layout and allocation mode, exception and interrupt handling methods, called libraries, and APIs (Application Programming Interfaces). The first model is an AI model with semantic extraction capabilities. The ECU firmware is reverse analyzed to obtain basic semantic information about the firmware. A binary program analysis technique that integrates reverse disassembly and forward compilation uses symbolic information obtained through forward compilation to verify the semantic information obtained through firmware reverse analysis, inferring the basic semantic information of the firmware and ensuring the accuracy of reverse restoration of the semantic information. A second model infers common features between heterogeneous ECU firmware based on this basic semantic information and information such as the firmware startup process, memory layout and allocation mode, exception and interrupt handling methods, and called libraries and APIs. These common features include the basic logical framework and core functions of firmware operation. The second model generates a firmware configuration template for the firmware simulation instance based on these common features between ECU firmware.

[0098] Step S303, building a heterogeneous compatible simulator. Among them, by identifying and extracting the CPU instruction implementation code for a single architecture in the existing simulator, automatically transcribing it into C code and integrating it into a single platform, a heterogeneous compatible ECU simulator is formed. Among them, C code is a target programming language that can be adopted. It is understandable that the target programming language can also be set to other programming languages ​​according to application requirements. Optionally, static analysis tools and scripts are used to extract the instruction implementation code of the CPU architecture from the existing single-architecture simulator, and the instruction implementation code is placed in the virtual QEMU (Quick EMUlator) source code directory. After defining the CPU core parameters, register and state management functions, and instruction decoding functions through the preset CPU model file, QEMU is uniformly compiled and installed to form a multi-architecture compatible simulator.

[0099] Step S304: Model the peripherals. The architecture data and firmware data collected in step S301 are used to categorize the peripherals, summarize interaction rules for the peripherals under different categories, and create automatic classification logic for the peripherals based on these interaction rules. After determining the interface for interaction between the ECU and the peripherals based on the interaction rules and automatic classification logic, appropriate data is provided to the interface to model the peripherals and improve code coverage for the firmware simulation run.

[0100] Interaction rules include information such as the characteristics of CPU-peripheral interactions and communication protocols; classification logic includes information such as peripheral types and interfaces for interacting with the outside world. Optionally, by analyzing architecture-related documentation and sample firmware, applicable peripheral interaction rules are extracted for different architectures, and classification logic is created based on the interaction characteristics of different peripherals. Ultimately, during firmware simulation, the following automated peripheral simulation process is formed: "Binary analysis tools scan firmware—identify the types and number of peripherals the firmware interacts with based on peripheral classification logic—trigger interrupts during firmware runtime to call corresponding interaction functions—and input the required data into specific firmware interfaces based on peripheral interaction rules."

[0101] Peripherals of the same architecture are typically designed according to specific rules and provide the required inputs to the ECU through specific communication interfaces, enabling the ECU to execute normally. Alternatively, taking the simulation of peripherals in the ARM (Advanced RISC Machines) architecture as an example, peripherals in the ARM architecture include status registers, data registers, and control registers. The simulation of the three registers during the interaction process is determined based on the peripheral interaction rules, including: determining the data required by the ECU based on the interaction rules, inputting the required data to the register interface, and inputting random data if the data register does not correspond to the interaction rules, so that the ECU determines that it is interacting with a real peripheral.

[0102] Step S305: Constructing a multi-ECU collaborative simulation environment. This includes creating multiple simulation instances to simulate different firmware on the same vehicle, establishing simulated CAN (Controller Area Network) and Ethernet (Ethernet) communication loops to connect the simulation instances, and creating a simulation environment that closely resembles a real-world in-vehicle network structure.

[0103] Optionally, after obtaining the ECU firmware, the peripheral type with which the firmware interacts is determined according to the output of step S304, and the position of the firmware in the vehicle network topology is inferred using the peripheral type, and it is determined whether the firmware belongs to the underlying CAN bus or the upper Ethernet network bus.

[0104] For the CAN network layer, it's necessary to build a CAN simulation bus and run firmware simulation instances. This involves running the QEMU program in a local environment to simulate the ECU running the firmware and configuring a virtual CAN bus interface for it. Building the CAN simulation bus involves connecting all firmware simulation instances deployed on the underlying CAN bus using a virtual CAN bus, as the CAN bus is a broadcast bus. This creates a CAN bus network and ensures that all simulation instances can receive information sent by the gateway firmware.

[0105] For the Ethernet network layer, it is necessary to create an Ethernet communication loop and run a firmware simulation instance. Among them, running the firmware simulation instance includes: creating a firmware simulation running instance in each Docker container of the Ethernet network layer respectively, so that it can directly receive network layer data. Constructing the Ethernet communication loop includes: obtaining the network interface and the number of network interfaces for the firmware to interact with the external connection according to the output of step S304. The network interface number is greater than or equal to 1, which is the central gateway, and the rest are domain control gateways, such as the body control domain, etc. The network topology of the Ethernet layer can be restored by connecting the domain control gateway to the central gateway respectively. Use Docker container automation to connect each firmware simulation running node according to the constructed network topology. When the firmware interacts with Ethernet and CAN bus at the same time, the CAN bus interface in the Docker container is exposed to the external environment and connected to the virtual CAN bus to achieve connectivity between the Ethernet network layer and the CAN bus layer.

[0106] Step S306: Conduct vehicle-wide vulnerability mining. Based on the existing threat model for intelligent connected vehicles, a fuzz testing engine is used to generate specific test cases for the boundary software. The boundary software is typically the attack surface / entry point for vulnerability exploitation and can be the software through which users interact with the vehicle. The test cases are fed into the boundary software, triggering vulnerabilities in the onboard ECU firmware through in-vehicle network communication, enabling rapid and effective vehicle-wide ECU firmware vulnerability mining.

[0107] Optionally, the network layer runtime boundary binary file corresponding to the firmware's interface with peripherals is first obtained. Based on the firmware's runtime environment characteristics, potential attack interfaces are identified within the boundary binary file. Because it runs on the Ethernet network layer and Unix-like systems, it frequently interacts with the outside world and users through specific channels such as Bluetooth, Wi-Fi, and cellular networks, making it a primary target for hackers. Therefore, by filtering out the boundary binary file to obtain interfaces for security testing, vulnerabilities that can be exploited in real-world environments and conditions are discovered. Static tainting is then used to analyze the transmission of external input within the firmware and record possible transmission paths. Dynamic code instrumentation and debugging techniques are used within an in-vehicle network simulation environment to obtain logs recording firmware execution. Information obtained from static and dynamic analysis is combined to infer potential attack paths. Based on these potential attack paths, a fuzz testing engine generates test cases for firmware vulnerability discovery. These test cases are then fed into the boundary software, triggering vulnerabilities in the onboard ECU firmware via the in-vehicle communication network, enabling rapid and effective vulnerability discovery for the entire vehicle's ECU firmware.

[0108] In this embodiment, by constructing a universal simulator for heterogeneous on-board ECU simulation, the testability and test efficiency of the on-board ECU firmware are greatly improved; by constructing a firmware configuration template, the firmware simulation cost is reduced while the test efficiency is improved; the detection coverage is improved through peripheral simulation; thereby, test cases are executed in the multi-ECU collaborative simulation environment of the in-vehicle network, solving the technical problems of existing test tools such as high ECU firmware testing overhead, slow speed, low detection coverage, and inability to test multi-ECU interactions.

[0109] It should be understood that, although the various steps in the flow charts involved in the above-mentioned embodiments are shown in sequence according to the indication of the arrows, these steps are not necessarily performed in sequence according to the order indicated by the arrows. Unless clearly stated herein, the execution of these steps is not strictly restricted in order, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flow charts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with at least a portion of the steps or stages in other steps or other steps. For example, steps S302, S303 and S304 can be performed synchronously or asynchronously.

[0110] Based on the same inventive concept, the embodiments of the present application also provide a multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles, which is used to implement the multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles. The implementation solution provided by the device is similar to the implementation solution described in the above method. Therefore, the specific limitations of one or more embodiments of the multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles provided below can be found in the above-mentioned limitations of the multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles, and will not be repeated here.

[0111] In one embodiment, Figure 4 As shown, a multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles is provided, including: a simulator construction module, a firmware common feature extraction module, a peripheral simulation module, an in-vehicle network environment construction module and a vulnerability mining module, wherein:

[0112] a simulator construction module for integrating data from multiple first simulators to obtain a second simulator; a firmware common feature extraction module for extracting firmware configuration templates in electronic control units of different architectures based on architecture data and firmware data corresponding to electronic control units of different architectures;

[0113] The peripheral simulation module is used to extract the interaction characteristics between the electronic control unit of each architecture and the peripherals based on the architecture data and firmware data corresponding to the electronic control unit of different architectures;

[0114] an in-vehicle network environment construction module, configured to restore the network topology of the network layer corresponding to the firmware in the second simulator based on the multiple interaction features, and to create multiple firmware simulation instances based on the firmware configuration template and the network topology to obtain the in-vehicle network simulation environment;

[0115] The vulnerability mining module is used to run test cases for firmware vulnerability mining in the in-vehicle network simulation environment to obtain vulnerability information.

[0116] In one embodiment, the multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles further includes an automatic capture module configured to obtain architecture data, firmware data, and data of the first simulator of the electronic control unit.

[0117] In one embodiment, the in-vehicle network environment construction module extracts a firmware configuration template based on the architecture data and firmware data in the electronic control unit, including: compiling the code in the architecture data to obtain the firmware's symbolic information; obtaining the firmware's architectural features based on the description document in the architecture data; obtaining the firmware's semantic information based on the binary file data in the firmware data; and constructing the firmware configuration template from the symbolic information, architectural features, semantic information, and descriptive information in the firmware data. Optionally, constructing the firmware configuration template from the symbolic information, architectural features, semantic information, and descriptive information in the firmware data includes: verifying the semantic information based on the symbolic information; and combining the symbolic information, architectural features, verified semantic information, and descriptive information to obtain the firmware configuration template.

[0118] In one embodiment, the peripheral simulation module extracts the interaction features of the peripherals in the electronic control unit based on the architecture data and firmware data in the electronic control unit, including: compiling the code in the architecture data to obtain the symbolic information of the firmware; determining the interaction interface between the electronic control unit and the peripherals based on the description document in the architecture data; determining the interaction information between the electronic control unit and the peripherals based on the reverse code information in the firmware data; and extracting the interaction features contained in the interaction information based on the symbolic information and the interaction interface.

[0119] In one embodiment, the simulator construction module integrates data of multiple first simulators to obtain a second simulator, including: extracting first codes that implement CPU instructions in multiple first simulators; transcribing the first codes into a target programming language to obtain second codes; and integrating multiple second codes to obtain a second simulator.

[0120] In one embodiment, the in-vehicle network environment construction module restores the network topology structure of the network layer corresponding to the firmware based on multiple interaction characteristics, and creates multiple firmware simulation instances in the network layer based on the firmware configuration template and the network topology structure to obtain the in-vehicle network simulation environment, including: when it is determined based on the interaction characteristics that the firmware interacts with the network layer of the Ethernet, the network topology structure of the Ethernet is restored based on the interaction characteristics and the firmware data, and a firmware simulation instance is created based on the firmware configuration template at the node of the network topology structure; when it is determined based on the interaction characteristics that the firmware interacts with the network layer of the controller local area network, the firmware simulation instance is created based on the firmware configuration template, and the data interface of the network layer where the controller local area network is located is configured for the firmware simulation instance, and a simulated controller local area network bus is constructed to connect the node where the firmware simulation instance is located; when it is determined based on the interaction characteristics that the firmware interacts with the network layer of the Ethernet and the network layer of the controller local area network, the firmware simulation instance is created based on the firmware configuration template at the network layer of the Ethernet, and the data interface of the network layer where the controller local area network is located is configured for the firmware simulation instance, and the data interface of the network layer where the controller local area network is located is connected to the simulated controller local area network bus.

[0121] In one embodiment, the vulnerability mining module restores the network topology structure of the network layer corresponding to the firmware in the second simulator based on multiple interaction features, and creates multiple firmware simulation instances based on the firmware configuration template and the network topology structure. Before obtaining the in-vehicle network simulation environment, the execution method also includes: obtaining potential attack entries and attack paths based on the firmware identification of the electronic control unit; generating test cases based on the attack entry, attack path and firmware runtime information.

[0122] In one embodiment, Figure 5 Another multi-ECU firmware collaborative simulation vulnerability mining device for intelligent connected vehicles is provided, such as Figure 5 As shown, the device includes the following modules: an automatic crawling module, a simulator construction module, a firmware common feature extraction module, a peripheral simulation module, an in-vehicle network environment construction module, and a vulnerability mining module. Among them, the automatic crawling module is used to collect ECU firmware of different architectures, and classify the ECU firmware of different architectures according to the firmware architecture and car model, so as to facilitate the subsequent extraction of common features and whole vehicle environment simulation based on the classified ECU firmware; the automatic crawling module is also used to crawl ECU firmware and OTA firmware update packages that need to be simulated, as well as crawl existing ECU architecture data, wherein the architecture data includes architecture sample code and architecture documents, so as to facilitate the two-way collaboration of reverse disassembly and forward compilation based on the architecture data, and realize the information extraction and verification of firmware semantics; the automatic crawling module is also used to crawl the existing simulator source code and program of different architectures, so as to facilitate the subsequent construction of multi-architecture simulators. Among them, the simulator obtained by the automatic crawling module is the first simulator in the above embodiment, and the multi-architecture simulator constructed is the second simulator.

[0123] The firmware common feature extraction module is used to extract the common features of firmware of the same architecture and generate a universal firmware configuration template for simulation based on the common features of the firmware. Figure 6 A schematic diagram of a firmware common feature extraction module is provided, such as Figure 6 As shown, the firmware common feature extraction module includes units with forward compilation and reverse analysis functions; the firmware common feature extraction also includes a first model for analyzing text information in the architecture document and a second model for implementing template configuration.

[0124] The simulator building module is used to generate heterogeneous compatible simulators. Figure 7 A schematic diagram of the simulator building blocks is provided, e.g. Figure 7 As shown, in order to build a simulator that supports the simulation of a certain architecture ECU, the simulator construction module can extract the CPU instruction implementation code in the existing simulator so that the constructed simulator can support the simulation of the CPU of this architecture, and transcribe and translate the extracted code into C code according to the QEMU instruction interface. Then, the CPU instruction implementation codes of multiple architectures are integrated into the QEMU source code and automatically compiled and installed to obtain a heterogeneous compatible simulator, that is, the second simulator.

[0125] The peripheral simulation module is used to output peripheral interaction rules and peripheral interaction logic, and the peripheral interaction rules and peripheral interaction logic can provide appropriate peripheral input when the firmware simulation is running. Figure 8 A schematic diagram of a peripheral simulation module is provided, such as Figure 8 As shown, the peripheral simulation module includes units for forward compilation and reverse analysis, and a third model for analyzing architecture documents. Forward compilation is used to analyze architecture sample codes. The reverse analysis unit can analyze the forward compilation unit and the third model to generate interaction rules and classification logic between firmware and peripherals in the same architecture.

[0126] The in-vehicle network environment simulation module is used to create a virtual in-vehicle network environment and multi-ECU simulation instances based on the heterogeneous compatible simulator output by the simulator construction module, the general configuration module of the firmware output by the firmware common feature extraction module, and the peripheral interaction rules and classification logic output by the peripheral simulation module. Figure 9 A schematic diagram of an in-vehicle network environment simulation module is provided. Figure 9As shown in the figure, the in-vehicle network environment simulation module can create a simulation instance of the CAN layer firmware based on the ECU firmware, build a CAN virtual bus and connect the network interface of the CAN layer firmware to restore the network topology of the CAN layer. It can also restore and build the network topology of the Ethernet layer according to the output of the peripheral simulation module, automatically create the Ethernet network layer environment using the Docker container, and create an Ethernet layer firmware simulation instance in the Docker container. By connecting the firmware simulation instances, an in-vehicle network multi-ECU collaborative simulation environment close to the real scenario is formed.

[0127] The vulnerability mining module is based on an environment constructed by ECU firmware with different structures and the in-vehicle network environment simulation module. It automatically mines potential vulnerabilities in the interaction between automobile ECUs through test cases and outputs vulnerability reports. Figure 10 A schematic diagram of a vulnerability mining module is provided, such as Figure 10 As shown, specifically, the vulnerability mining module can identify the boundary binary files during ECU firmware runtime and obtain potential attack entry points; analyze ECU firmware through a static taint analysis engine to obtain potential attack paths for multi-firmware interactions; combine potential attack entry points, potential attack paths, firmware operation logs, and interaction information, and use a fuzz testing engine to generate test cases for firmware vulnerability mining, automatically input test cases to carry out vulnerability mining, and output vulnerability reports.

[0128] Each module in the aforementioned multi-ECU collaborative simulation vulnerability discovery device for intelligent connected vehicles can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or stored in a computer device's memory in software form, allowing the processor to call and execute the corresponding operations of each module.

[0129] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 11As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data of electronic control units of different architectures. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles is implemented.

[0130] Those skilled in the art will understand that Figure 11 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0131] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0132] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0133] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0134] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0135] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0136] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A multi-ECU collaborative simulation vulnerability mining method for intelligent connected vehicles, characterized by: The method comprises: Extracting, based on architecture data and firmware data corresponding to electronic control units of different architectures, interaction features between the electronic control unit and peripherals of each architecture, as well as firmware configuration templates in the electronic control unit of each architecture; integrating data of the plurality of first simulators to obtain a second simulator; In the second simulator, the network topology structure of the network layer corresponding to the firmware is restored according to the plurality of interaction features, and a plurality of firmware simulation instances are created according to the firmware configuration template and the network topology structure to obtain an in-vehicle network simulation environment; A test case for firmware vulnerability mining is run in the in-vehicle network simulation environment to obtain vulnerability information.

2. The method according to claim 1, characterized in that Extracting a firmware configuration template in the electronic control unit of each architecture according to architecture data and firmware data corresponding to the electronic control unit of different architectures includes: Compiling the code in the architecture data to obtain symbolic information of the firmware; Obtaining architectural features of the firmware according to the description document in the architecture data; Obtaining semantic information of the firmware according to binary file data in the firmware data; The firmware configuration template is constructed based on the symbolic information, the architectural features, the semantic information, and the descriptive information in the firmware data.

3. The method according to claim 2, characterized in that Constructing the firmware configuration template based on the symbolic information, the architectural features, the semantic information, and the descriptive information in the firmware data includes: verifying the semantic information based on the symbolic information; The firmware configuration template is obtained by combining the symbolic information, the architectural features, the verified semantic information, and the descriptive information.

4. The method according to claim 1, wherein Extracting interaction features of peripherals in the electronic control unit based on architecture data and firmware data in the electronic control unit includes: Compiling the code in the architecture data to obtain symbolic information of the firmware; Determining an interaction interface between the electronic control unit and the peripheral device according to the description document in the architecture data; determining interaction information between the electronic control unit and the peripheral device according to the reverse code information in the firmware data; The interaction feature contained in the interaction information is extracted based on the symbol information and the interaction interface.

5. The method according to claim 1, wherein Integrating data from a plurality of first simulators to obtain a second simulator includes: Extracting a plurality of first codes implementing CPU instructions from the first simulators; transcribing the first code into a target programming language to obtain a second code; A plurality of the second codes are integrated to obtain the second simulator.

6. The method according to claim 1, characterized in that Restoring the network topology of the network layer corresponding to the firmware according to the plurality of interaction features, and creating a plurality of firmware simulation instances in the network layer according to the firmware configuration template and the network topology to obtain an in-vehicle network simulation environment, including: When it is determined based on the interaction characteristics that the firmware interacts with the network layer of the Ethernet, restoring the network topology of the Ethernet based on the interaction characteristics and the firmware data, and creating a firmware simulation instance based on the firmware configuration template at a node of the network topology; When it is determined based on the interaction characteristics that the firmware interacts with the network layer of the controller area network, creating a firmware simulation instance based on the firmware configuration template, configuring a data interface of the network layer of the controller area network for the firmware simulation instance, and building a simulated controller area network bus to connect the node where the firmware simulation instance is located; When it is determined based on the interaction characteristics that the firmware interacts with the network layer of the Ethernet and the network layer of the controller area network, a firmware simulation instance is created at the network layer of the Ethernet based on the firmware configuration template, and a data interface of the network layer where the controller area network is located is configured for the firmware simulation instance, connecting the data interface of the network layer where the controller area network is located and the simulated controller area network bus.

7. The method according to claim 1, characterized in that Before executing a test case for firmware vulnerability mining in the in-vehicle network simulation environment to obtain vulnerability information, the method further includes: Obtaining a data transmission path based on firmware data in the electronic control unit and information identification during firmware operation; The test case is generated according to the data transmission path.

8. A multi-ECU collaborative simulation vulnerability mining device for intelligent connected vehicles, characterized in that: The device comprises: A simulator construction module, configured to integrate data of a plurality of first simulators to obtain a second simulator; a firmware common feature extraction module, configured to extract firmware configuration templates in the electronic control units of different architectures based on architecture data and firmware data corresponding to the electronic control units of different architectures; A peripheral device simulation module is configured to extract interaction features between the electronic control unit and the peripheral device of each architecture based on architecture data and firmware data corresponding to the electronic control unit of different architectures; an in-vehicle network environment construction module, configured to restore, in the second simulator, a network topology structure of a network layer corresponding to the firmware based on the plurality of interaction features, and to create a plurality of firmware simulation instances based on the firmware configuration template and the network topology structure, thereby obtaining an in-vehicle network simulation environment; The vulnerability mining module is used to run test cases for firmware vulnerability mining in the in-vehicle network simulation environment to obtain vulnerability information.

9. The device according to claim 8, characterized in that The device further includes an automatic capture module, wherein the automatic capture module is used to obtain architecture data, firmware data of the electronic control unit and data of the first simulator.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

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

Images