Electric control unit safety detection method and system based on honeypot technology and medium

Abstract

The invention discloses an electronic control unit safety detection method and system based on a honeypot technology and a medium, and the method comprises the steps: building a honeypot detection environment based on a real vehicle control system, creating a virtual ECU honeypot, and configuring bait data and protocol simulation rules; loading firmware of the to-be-detected electronic control unit to the honeypot detection environment, and recording flow data and behavior data of the to-be-detected electronic control unit; performing security detection on the to-be-detected electronic control unit according to the flow data and the behavior data to obtain a security detection report; wherein the bait data is used for actively trapping attack behaviors, and the protocol simulation rule is used for simulating a real ECU communication protocol to trigger potential malicious operation. The method improves the accuracy of safety detection of the electronic control unit, and can be applied to the technical field of vehicle production.

Description

Technical Field

[0001] The present invention relates to the field of vehicle production technology, and in particular to a method, system and medium for detecting safety of an electronic control unit based on honeypot technology. Background Art

[0002] The electronic control unit (ECU) is the engine's integrated control device. Its function is to calculate, process, and judge various information input from the engine's sensors based on its stored programs, then output instructions to control the actions of relevant actuators, achieving the goal of rapid, accurate, and automatic control of engine operation. Therefore, in the automotive production process, the compliance inspection of incoming ECU materials is crucial.

[0003] The compliance testing of incoming materials for electronic control units usually includes the following aspects:

[0004] 1) Appearance inspection: Check whether the housing, connectors, labels, etc. of the electronic control unit are intact and free of damage, deformation or rust;

[0005] 2) Functional test: Test whether the various functions of the electronic control unit are normal, including communication, control, data processing, etc.;

[0006] 3) Performance testing: Testing the performance indicators of the electronic control unit, such as response time, accuracy, stability, etc., to ensure that it meets the requirements of the OEM;

[0007] 4) Safety test: Check whether the safety protection measures of the electronic control unit are in place, such as overcurrent protection, overvoltage protection, etc., to ensure that it can work normally under abnormal circumstances and protect the safety of the entire vehicle.

[0008] However, existing ECU safety testing solutions have the following disadvantages:

[0009] 1) Passivity: These rely on passive defense mechanisms and can typically only detect and respond to attacks after they occur. They lack the ability to actively attract and capture attackers, making it difficult to provide effective early warning and defense before an attack occurs.

[0010] 2) Limitations of detection technology: Current incoming material inspection methods mainly focus on the functions, performance and appearance of the electronic control unit, but it is difficult to effectively identify whether there is a backdoor reserved inside.

[0011] 3) Difficulty in simulating real-world attack scenarios: Simulating real-world control system environments and attack scenarios can lead to inaccurate evaluation results. This makes it difficult to effectively assess the performance and safety of the ECU in the face of real-world attacks.

[0012] The above problems need to be solved urgently. Summary of the Invention

[0013] The purpose of the present invention is to solve one of the technical problems existing in the prior art to at least a certain extent.

[0014] Therefore, an object of an embodiment of the present invention is to provide an electronic control unit security detection method based on honeypot technology, which improves the accuracy of the electronic control unit security detection.

[0015] Another object of an embodiment of the present invention is to provide an electronic control unit security detection system based on honeypot technology.

[0016] In order to achieve the above technical objectives, the technical solutions adopted by the embodiments of the present invention include:

[0017] In a first aspect, an embodiment of the present invention provides a method for detecting the security of an electronic control unit based on honeypot technology, comprising the following steps:

[0018] Build a honeypot detection environment based on the real vehicle control system, create a virtual ECU honeypot, and configure bait data and protocol simulation rules;

[0019] Loading the firmware of the electronic control unit to be tested into the honeypot detection environment, and recording the flow data and behavior data of the electronic control unit to be tested;

[0020] Performing a safety test on the electronic control unit to be tested according to the flow data and the behavior data to obtain a safety test report;

[0021] The bait data is used to actively trap attack behaviors, and the protocol simulation rules are used to simulate real ECU communication protocols to trigger potential malicious operations.

[0022] Furthermore, in one embodiment of the present invention, the honeypot detection environment is built based on the real vehicle control system, a virtual ECU honeypot is created, and bait data and protocol simulation rules are configured, which specifically includes:

[0023] Obtain the network topology and service configuration of the real vehicle control system, and build the honeypot detection environment according to the network topology and service configuration;

[0024] Creating the virtual ECU honeypot in the honeypot detection environment by using a virtualization tool;

[0025] Generate the bait data of multiple service types based on the network service of the real vehicle control system, and dynamically update the content of the bait data through a script;

[0026] The protocol simulation rules are generated based on the communication protocol of the real vehicle control system.

[0027] Furthermore, in one embodiment of the present invention, the step of loading the firmware of the electronic control unit to be tested into the honeypot detection environment and recording the flow data and behavior data of the electronic control unit to be tested specifically includes:

[0028] Using the Bootloader mode, the firmware of the electronic control unit to be tested is written into the honeypot detection environment, and the middleware and driver program that the electronic control unit to be tested depends on are loaded into the honeypot detection environment to simulate the real operating environment of the electronic control unit to be tested;

[0029] Using a network probe to monitor the CAN bus and Ethernet interface, capturing the original message of the electronic control unit to be tested, and obtaining the flow data;

[0030] The system call behavior, hardware operation behavior and access behavior of the electronic control unit to be tested are monitored at the kernel layer to obtain the behavior data.

[0031] Furthermore, in one embodiment of the present invention, the safety test of the electronic control unit to be tested is performed based on the flow data and the behavior data to obtain a safety test report, which specifically includes:

[0032] Performing flow analysis on the electronic control unit to be tested based on the flow data to determine whether there is a protocol anomaly;

[0033] Performing a behavioral benchmark analysis on the electronic control unit to be tested based on the behavioral data to determine whether there is behavioral abnormality;

[0034] When there is a protocol anomaly and / or a behavior anomaly, determine that the security test fails, and generate a corresponding security test report according to the anomaly type;

[0035] When there are no protocol anomalies and behavior anomalies, it is determined that the security test has passed, and the corresponding security test report is generated.

[0036] Furthermore, in one embodiment of the present invention, when there is a protocol anomaly and / or a behavior anomaly, the electronic control unit safety detection method further includes the following steps:

[0037] Aggregating the traffic data and the behavior data to generate a time series analysis chart;

[0038] The attack source location and attack path are determined according to the timing analysis chart.

[0039] Furthermore, in one embodiment of the present invention, before loading the firmware of the electronic control unit to be tested into the honeypot detection environment, the following steps are also included:

[0040] Common ECU attacks are simulated using penetration tools to verify whether the response of the virtual ECU honeypot meets expectations.

[0041] Furthermore, in one embodiment of the present invention, the electronic control unit safety detection method further includes the following steps:

[0042] Loading the firmware of the ECU to be tested into a real vehicle control system and recording the actual behavior of the ECU to be tested;

[0043] Identify potential backdoors or vulnerabilities of the electronic control unit to be tested based on the difference between the actual behavior and the behavior data.

[0044] In a second aspect, an embodiment of the present invention provides an electronic control unit security detection system based on honeypot technology, comprising:

[0045] Honeypot deployment module, used to build a honeypot detection environment based on the real vehicle control system, create a virtual ECU honeypot, and configure bait data and protocol simulation rules;

[0046] A flow behavior monitoring module, configured to load the firmware of the electronic control unit to be tested into the honeypot detection environment and record the flow data and behavior data of the electronic control unit to be tested;

[0047] a detection module, configured to perform a safety detection on the electronic control unit to be tested based on the flow data and the behavior data, and obtain a safety detection report;

[0048] The bait data is used to actively trap attack behaviors, and the protocol simulation rules are used to simulate real ECU communication protocols to trigger potential malicious operations.

[0049] In a third aspect, an embodiment of the present invention provides an electronic control unit security detection device based on honeypot technology, comprising:

[0050] at least one processor;

[0051] at least one memory for storing at least one program;

[0052] When the at least one program is executed by the at least one processor, the at least one processor implements the above-mentioned method for detecting security of an electronic control unit based on the honeypot technology.

[0053] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium storing a program executable by a processor, wherein the program executable by the processor is used to execute the above-mentioned method for detecting the security of an electronic control unit based on honeypot technology when executed by the processor.

[0054] The advantages and benefits of the present invention will be described in part in the following description and will become apparent from the following description or learned through practice of the present invention:

[0055] The embodiment of the present invention builds a honeypot detection environment based on a real vehicle control system, creates a virtual ECU honeypot, and configures bait data and protocol simulation rules, wherein the bait data is used to actively trap attack behaviors, and the protocol simulation rules are used to simulate the real ECU communication protocol to trigger potential malicious operations. The firmware of the electronic control unit to be tested is loaded into the honeypot detection environment, the flow data and behavior data of the electronic control unit to be tested are recorded, and the electronic control unit to be tested is subjected to security testing based on the flow data and behavior data to obtain a security testing report. The embodiment of the present invention simulates the real control system environment through the honeypot detection environment, actively traps attack behaviors through bait data, triggers potential malicious operations by simulating the real ECU communication protocol, and monitors the firmware behavior and communication traffic of the electronic control unit to be tested in real time, thereby achieving active trapping and precise positioning of supply chain threats such as backdoor programs and protocol attacks, improving the accuracy of electronic control unit security testing, and effectively protecting the supply chain security and data privacy of intelligent connected vehicles. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following introduction is made to the drawings required for use in the embodiments of the present invention. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0057] Figure 1 A flowchart of a method for detecting safety of an electronic control unit based on honeypot technology provided by an embodiment of the present invention;

[0058] Figure 2 A structural block diagram of an electronic control unit security detection system based on honeypot technology provided by an embodiment of the present invention;

[0059] Figure 3 This is a structural block diagram of an electronic control unit security detection device based on honeypot technology provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0060] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and are not to be construed as limiting the present invention. The step numbers in the following embodiments are provided for ease of explanation only and do not limit the order of the steps. The order of execution of the steps in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0061] In the description of the present invention, "a plurality" means two or more. The terms "first" and "second" are used solely to distinguish technical features and are not to be construed as indicating or implying relative importance, or as implicitly indicating the number of the indicated technical features, or as implicitly indicating the order of the indicated technical features. Furthermore, unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art.

[0062] Reference Figure 1 The embodiment of the present invention provides a method for detecting the security of an electronic control unit based on honeypot technology, which specifically includes the following steps:

[0063] S101. Build a honeypot detection environment based on the real vehicle control system, create a virtual ECU honeypot, and configure bait data and protocol simulation rules;

[0064] S102, loading the firmware of the electronic control unit to be tested into the honeypot detection environment, and recording the flow data and behavior data of the electronic control unit to be tested;

[0065] S103, performing a safety test on the electronic control unit to be tested based on the flow data and the behavior data, and obtaining a safety test report;

[0066] Among them, bait data is used to actively trap attack behaviors, and protocol simulation rules are used to simulate real ECU communication protocols to trigger potential malicious operations.

[0067] Specifically, the embodiment of the present invention simulates a real control system environment through a honeypot detection environment, actively traps attack behaviors through bait data, triggers potential malicious operations by simulating real ECU communication protocols, and monitors the firmware behavior and communication traffic of the electronic control unit under test in real time, thereby achieving active trapping and precise positioning of supply chain threats such as backdoor programs and protocol attacks, improving the accuracy of electronic control unit security detection, and effectively protecting the supply chain security and data privacy of intelligent connected vehicles.

[0068] As an optional implementation, a honeypot detection environment is built based on the real vehicle control system, a virtual ECU honeypot is created, and decoy data and protocol simulation rules are configured, which specifically include:

[0069] S1011. Obtain the network topology and service configuration of the real vehicle control system, and build a honeypot detection environment based on the network topology and service configuration;

[0070] S1012. Create a virtual ECU honeypot in the honeypot detection environment using a virtualization tool;

[0071] S1013, generating bait data of multiple service types based on the network service of the real vehicle control system, and dynamically updating the content of the bait data through a script;

[0072] S1014. Generate protocol simulation rules based on the communication protocol of the real vehicle control system.

[0073] Specifically, the embodiment of the present invention simulates a real control system environment, including network topology and service configuration, through a honeypot detection environment. It actively traps attack behaviors through bait data (such as forged sensitive register values) and triggers potential malicious operations by simulating real ECU communication protocols (SOME / IP, UDS). This helps evaluate the performance and security of the electronic control unit when facing real attacks. The specific process is as follows:

[0074] 1. Obtain real vehicle network topology and service configuration

[0075] 1) Network topology mapping

[0076] Obtain the vehicle's CAN bus, LIN bus, and other network architecture diagrams through physical access to the OBD-II port or reverse engineering, and determine the ECU node distribution (such as engine ECU, T-Box gateway, ADAS controller, etc.);

[0077] Use diagnostic tools (such as CANoe and Wireshark) to capture communication data streams, analyze inter-ECU communication paths and routing rules, and record key parameters: communication protocol type (CAN FD / Ethernet), message ID range, cycle characteristics, and encryption mechanism.

[0078] 2) Service configuration extraction

[0079] Parse vehicle diagnostic protocols (such as UDS and KWP2000) and extract service identifiers (SIDs) and sub-function parameters;

[0080] Identify remote service interfaces (such as the T-Box's 4G / 5G module and Bluetooth / Wi-Fi service ports) and record API interaction formats and authentication mechanisms.

[0081] 2. Build a honeypot detection environment

[0082] 1) Network environment construction

[0083] Build a virtualization platform based on VMware / Proxmox and deploy a three-layer architecture according to the real topology: physical layer (simulated OBD interface) → network layer (virtual CAN switch) → application layer (virtual ECU cluster);

[0084] Configure network isolation policies, use VLANs to divide the attack surface, and restrict external access paths through firewalls.

[0085] 2) Service simulation configuration

[0086] Deploy the Honeyd framework to simulate vehicle-specific services, such as OTA upgrade services (HTTP / HTTPS endpoints) and vehicle status query APIs (RESTful interfaces).

[0087] 3. Create a virtual ECU honeypot

[0088] 1) Hardware virtualization implementation

[0089] Use QEMU to emulate the target MCU architecture (such as ARM Cortex-R52) and load the preset firmware image;

[0090] Configure virtual peripherals: CAN controller (MCP2515 simulation), GPIO port mapping, ADC sampling virtual sensor.

[0091] 2) Software behavior simulation

[0092] Deploy a streamlined AUTOSAR system to implement the DEM module (generating false fault codes) and BSW basic services (periodic message sending).

[0093] Implant decoy logic (such as simulating a sudden change in the brake pedal signal).

[0094] 4. Bait data generation and dynamic update

[0095] 1) Service-based bait construction

[0096] Generate decoy datasets based on real protocols, for example: (1) Firmware upgrade: forge version number v2.3.15→v2.3.16 upgrade package; (2) Remote control: simulate door lock state switching instructions;

[0097] Use Python scripts to implement dynamic updates.

[0098] 2) Attack signature injection

[0099] Embed attack fingerprints in the bait data: abnormal message ID (such as 0x000), illegal SID code (such as 0xFF), CRC check error, etc.

[0100] 5. Communication protocol simulation rule formulation

[0101] 1) Protocol behavior modeling

[0102] Define state machine rules, for example, attack session: skip security access and send control instructions directly;

[0103] Configure message timing constraints, for example, diagnostic response delay < 50ms2.

[0104] 2) Abnormal traffic generation: Use Scapy to customize CAN protocol fuzz testing rules.

[0105] As an optional implementation, the firmware of the ECU to be tested is loaded into a honeypot detection environment, and the flow data and behavior data of the ECU to be tested are recorded, which specifically includes:

[0106] S1021. Use the Bootloader mode to write the firmware of the electronic control unit under test into the honeypot detection environment, load the middleware and driver that the electronic control unit under test depends on in the honeypot detection environment, and simulate the real operating environment of the electronic control unit under test;

[0107] S1022. Use a network probe to monitor the CAN bus and Ethernet interface, capture the original message of the electronic control unit to be tested, and obtain flow data;

[0108] S1023. Monitor the system call behavior, hardware operation behavior, and access behavior of the electronic control unit under test at the kernel layer to obtain behavior data.

[0109] Specifically, the firmware image of the supplier's ECU (electronic control unit under test) is loaded into the honeypot detection environment, the CAN / Ethernet traffic between the real test equipment and the ECU is copied to the honeypot analysis platform, and memory, file system, and register access are monitored in real time to achieve dynamic behavior monitoring of the electronic control unit under test. The specific process is as follows:

[0110] 1. Bootloader mode firmware writing and environment simulation

[0111] 1) Bootloader activation and firmware burning

[0112] Enter the ECU's Bootloader mode through a physical interface (such as JTAG / OBD-II) and use dedicated tools (such as the XCP protocol) to write the firmware to be tested into the virtualized honeypot environment;

[0113] Configure the QEMU virtualization platform to simulate the hardware architecture of the target ECU (such as ARM Cortex-M7) and retain the Bootloader partition structure when loading the firmware image.

[0114] 2) Middleware and driver loading

[0115] Deploy the AUTOSAR Classic Platform middleware in a virtual environment, configure the Basic Software Management Module (BSWM) and the Device Abstraction Layer (DAL) to drive virtual sensors and actuators, etc.

[0116] Inject the driver configuration parameters of the real ECU (such as CAN controller baud rate, ADC sampling frequency).

[0117] 3) Operational environment verification

[0118] Send UDS services (such as 0x22 to read DID data) through the diagnostic interface to verify the integrity of the firmware function;

[0119] Use the BusMaster tool to simulate ECU interaction and check the compliance of sending periodic messages (such as vehicle speed and rotational speed).

[0120] 2. Network probe deployment and traffic capture

[0121] 1) Dual-channel monitoring architecture

[0122] CAN bus monitoring: Deploy the PCAN-USB Pro FD hardware probe, configure the baud rate adaptive function from 500kbps to 2Mbps, use the candump tool to capture raw messages, and record the timestamp and channel ID.

[0123] Ethernet monitoring: Configure port mirroring policies to capture SOME / IP and DoIP protocol traffic through TAP devices.

[0124] 2) Protocol parsing and storage

[0125] Use Wireshark plug-ins to analyze vehicle protocols, such as SOME / IP serialized data analysis;

[0126] When storing raw traffic, context metadata is also recorded: message direction (ECU→gateway), encryption status, session ID, etc.

[0127] 3. Kernel layer behavior monitoring

[0128] 1) System call tracing

[0129] Implant eBPF probes to monitor key system calls, such as spi_async (hardware bus access) and request_firmware (firmware update behavior);

[0130] Build a system call relationship graph to identify abnormal call chains (such as diagnostic services triggering DMA operations).

[0131] 2) Hardware operation audit: The kernel module monitors behaviors such as ADC sampling frequency anomalies (exceeding the physical limit of the sensor) and watchdog reset events (anomalies triggering counter clearing).

[0132] 3) Access behavior analysis: Deploy LSM (Linux Security Module) in the kernel address space to audit write operations in firmware storage areas (such as Flash partitions) and monitor cross-domain access to DMA buffers.

[0133] As a further optional implementation, a safety test is performed on the electronic control unit to be tested based on the flow data and the behavior data to obtain a safety test report, which specifically includes:

[0134] S1031. Perform flow analysis on the electronic control unit to be tested based on the flow data to determine whether there is a protocol anomaly.

[0135] S1032: Perform a behavioral benchmark analysis on the electronic control unit under test based on the behavioral data to determine whether there is any behavioral abnormality;

[0136] S1033. When there is a protocol anomaly and / or a behavior anomaly, determine that the security test fails, and generate a corresponding security test report based on the anomaly type;

[0137] S1034. When there are no protocol anomalies and behavior anomalies, it is determined that the security test has passed, and a corresponding security test report is generated.

[0138] Specifically, the specific process of performing safety testing on the electronic control unit based on flow analysis and behavior benchmark analysis in the embodiment of the present invention is as follows:

[0139] 1. Traffic data analysis and protocol anomaly detection

[0140] 1) Protocol compliance verification

[0141] Based on CAN / Ethernet protocol specifications (such as ISO 15765-2 and DoIP), the message structure is parsed field by field to verify the message length, identifier range (such as whether the CAN ID is in the legal range of 0x000-0x7FF), checksum (CRC32), and service code (SID) compliance (such as whether the UDS service contains illegal 0xFF code);

[0142] Use Wireshark plug-ins or custom parsing tools to match protocol template libraries in real time and mark packets that violate standards.

[0143] 2) Statistical analysis of traffic characteristics

[0144] Extract timing features: bus load rate (an alarm is triggered when the CAN bus load is continuously >80%), session response delay (a diagnostic service response timeout >50ms is considered an abnormality), etc.

[0145] Establish a traffic baseline model: Use a sliding window algorithm (window size 1 minute) to calculate the mean and standard deviation, and dynamically update the normal traffic threshold.

[0146] 3) Deep Learning Anomaly Detection

[0147] Deploy the LSTM-Autoencoder model, using input features such as packet ID distribution entropy, session type ratio, and payload byte change rate.

[0148] Calculate the reconstruction error (MSE) to determine abnormalities: when the error is greater than 3 times the historical median, it is determined to be a protocol layer attack (such as replay attack, fuzz testing).

[0149] 2. Behavioral Data Analysis and Benchmarking

[0150] 1) System call sequence modeling

[0151] Collect kernel events through eBPF: hardware access path (spi_async→GPIO control) and operation behavior (copy_from_user→ioremap);

[0152] Construct a Markov state transition matrix and count the probability of a normal call sequence. For example, the diagnostic service must follow the legal path of TesterP resent → SecurityAccess → WriteDataByIdentifier.

[0153] 2) Hardware operation frequency analysis

[0154] Monitor sensor / actuator interface behavior:

[0155] Watchdog reset interval (trigger alarm when shorter than 50% of the design value);

[0156] GPIO trigger times (for example, if the brake light is triggered more than 10 times per second, it is considered a malicious operation).

[0157] 3) Resource access anomaly detection

[0158] Deploy LSM module monitoring:

[0159] DMA buffer cross-domain reading and writing (such as entertainment system accessing power domain memory);

[0160] Abnormal firmware update request (Flash write operation not using the OTA channel).

[0161] 3. Safety status assessment and report generation

[0162] 1) Multi-dimensional abnormal correlation analysis

[0163] Establish spatiotemporal correlation rules: If both the abnormal CAN ID 0x7E0 message (protocol layer) and a surge in SPI bus access (behavioral layer) are detected, it is determined to be a coordinated attack event;

[0164] Severity rating: Level 1 (single protocol anomaly), Level 2 (multiple protocol anomaly), Level 3 (combined protocol + behavior anomaly).

[0165] 2) Automatic generation of test reports

[0166] Rejected report contents: Attack impact analysis (such as power control loss, privacy data leakage); repair suggestions (updating encryption algorithms, closing high-risk ports).

[0167] Pass report content: Compliance confirmation (such as compliance with ISO 21434 standards); optimization suggestions (increasing sampling frequency, enhancing session authentication).

[0168] 3) Dynamic feedback mechanism: The detection results are injected back into the honeypot system to generate new bait data based on the attack characteristics (such as simulating tampered DID responses).

[0169] As a further optional implementation, when there is a protocol anomaly and / or a behavior anomaly, the ECU safety detection method further includes the following steps:

[0170] S10331. Aggregate traffic data and behavior data to generate a time series analysis chart;

[0171] S10332. Determine the attack source location and attack path based on the timing analysis chart.

[0172] Specifically, the original traffic data (such as PCAP files and NetFlow logs) and behavioral data (system call logs and hardware operation records) are deduplicated, outliers are filtered, and fields are standardized. Feature extraction is performed from the traffic dimension (number of packets per second (PPS), protocol distribution ratio (CAN / Ethernet), and single IP request frequency) and behavioral dimension (system call frequency (such as can_send call volume), and hardware interrupt triggering times (such as GPIO port status changes)). Then, time series data is aggregated to obtain a visual time series analysis chart. Through Whois query and threat intelligence library (such as AlienVault OTX), known malicious IPs are matched, and TCP / IP fingerprints (TTL value, Window Size) are analyzed to identify forged source IPs, thereby determining the location of the attack source. Attack path restoration is performed based on multi-hop path tracing, protocol feature chain analysis, and spatiotemporal association rules. Maltego is used to draw an attack topology diagram, including key nodes of the penetration path (such as the hijacked OTA server) and lateral movement trajectories (from the infotainment system to the power domain controller). The above steps can determine the attack source location and attack path, thereby achieving active trapping and precise positioning of supply chain threats such as backdoor programs and protocol attacks.

[0173] As an optional implementation, before loading the firmware of the electronic control unit to be tested into the honeypot detection environment, the following steps are further included:

[0174] Use penetration tools to simulate common ECU attacks and verify whether the response of the virtual ECU honeypot meets expectations.

[0175] Specifically, before loading the firmware of the electronic control unit to be tested, common ECU attacks are simulated through penetration tools to verify whether the response of the virtual ECU honeypot meets expectations. If so, the firmware of the electronic control unit to be tested can be loaded for subsequent testing. If not, the virtual ECU honeypot needs to be redeployed.

[0176] As an optional embodiment, the electronic control unit safety detection method further includes the following steps:

[0177] S201, loading the firmware of the electronic control unit to be tested into the real vehicle control system, and recording the real behavior of the electronic control unit to be tested;

[0178] S202. Identify potential backdoors or vulnerabilities of the electronic control unit under test based on the difference between the actual behavior and the behavior data.

[0179] Specifically, the firmware of the electronic control unit to be tested is also loaded into the real vehicle control system, and its actual behavior under the real vehicle control system is recorded. Then, the actual behavior is compared with its behavior data in the virtual ECU honeypot, and potential backdoors or vulnerabilities of the electronic control unit to be tested are identified based on the behavioral differences.

[0180] The above describes the method steps of the embodiment of the present invention. It is understood that the embodiment of the present invention simulates a real control system environment through a honeypot detection environment, actively traps attack behaviors through bait data, triggers potential malicious operations by simulating real ECU communication protocols, and monitors the firmware behavior and communication traffic of the ECU under test in real time. This allows for the active trapping and precise location of supply chain threats such as backdoor programs and protocol attacks, thereby improving the accuracy of ECU security testing and effectively protecting the supply chain security and data privacy of intelligent connected vehicles.

[0181] Reference Figure 2 The embodiment of the present invention provides an electronic control unit security detection system based on honeypot technology, including:

[0182] Honeypot deployment module, used to build a honeypot detection environment based on the real vehicle control system, create a virtual ECU honeypot, and configure bait data and protocol simulation rules;

[0183] The traffic behavior monitoring module is used to load the firmware of the electronic control unit under test into the honeypot detection environment and record the traffic data and behavior data of the electronic control unit under test;

[0184] A detection module is used to perform safety detection on the electronic control unit to be tested based on flow data and behavior data, and obtain a safety detection report;

[0185] Among them, bait data is used to actively trap attack behaviors, and protocol simulation rules are used to simulate real ECU communication protocols to trigger potential malicious operations.

[0186] The contents of the above method embodiments are all applicable to the present system embodiments. The functions specifically implemented by the present system embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0187] Reference Figure 3 The embodiment of the present invention provides an electronic control unit security detection device based on honeypot technology, comprising:

[0188] at least one processor;

[0189] at least one memory for storing at least one program;

[0190] When the at least one program is executed by the at least one processor, the at least one processor implements the above-mentioned method for detecting security of an electronic control unit based on the honeypot technology.

[0191] The contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0192] An embodiment of the present invention further provides a computer-readable storage medium storing a program executable by a processor. When the program is executed by the processor, it is used to perform the above-mentioned method for detecting the security of an electronic control unit based on the honeypot technology.

[0193] A computer-readable storage medium according to an embodiment of the present invention can execute an electronic control unit security detection method based on honeypot technology provided by an embodiment of the method of the present invention, can execute any combination of implementation steps of the method embodiment, and has the corresponding functions and beneficial effects of the method.

[0194] The embodiment of the present invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs Figure 1 The method shown.

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

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

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

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

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

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

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

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

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

Claims

1. A method for detecting the safety of an electronic control unit based on honeypot technology, characterized in that: The following steps are involved: Build a honeypot detection environment based on the real vehicle control system, create a virtual ECU honeypot, and configure bait data and protocol simulation rules; Loading the firmware of the electronic control unit to be tested into the honeypot detection environment, and recording the flow data and behavior data of the electronic control unit to be tested; Performing a safety test on the electronic control unit to be tested according to the flow data and the behavior data to obtain a safety test report; The bait data is used to actively trap attack behaviors, and the protocol simulation rules are used to simulate real ECU communication protocols to trigger potential malicious operations.

2. The method for detecting safety of an electronic control unit based on honeypot technology according to claim 1, characterized in that: The honeypot detection environment is built based on the real vehicle control system, a virtual ECU honeypot is created, and bait data and protocol simulation rules are configured, which specifically includes: Obtain the network topology and service configuration of the real vehicle control system, and build the honeypot detection environment according to the network topology and service configuration; Creating the virtual ECU honeypot in the honeypot detection environment by using a virtualization tool; Generate the bait data of multiple service types based on the network service of the real vehicle control system, and dynamically update the content of the bait data through a script; The protocol simulation rules are generated based on the communication protocol of the real vehicle control system.

3. The method for detecting safety of an electronic control unit based on honeypot technology according to claim 1, characterized in that: The step of loading the firmware of the electronic control unit to be tested into the honeypot detection environment and recording the flow data and behavior data of the electronic control unit to be tested specifically includes: Using the Bootloader mode, the firmware of the electronic control unit to be tested is written into the honeypot detection environment, and the middleware and driver program that the electronic control unit to be tested depends on are loaded into the honeypot detection environment to simulate the real operating environment of the electronic control unit to be tested; Using a network probe to monitor the CAN bus and Ethernet interface, capturing the original message of the electronic control unit to be tested, and obtaining the flow data; The system call behavior, hardware operation behavior and access behavior of the electronic control unit to be tested are monitored at the kernel layer to obtain the behavior data.

4. The method for detecting safety of an electronic control unit based on honeypot technology according to claim 1, characterized in that: The safety test of the electronic control unit to be tested is performed based on the flow data and the behavior data to obtain a safety test report, which specifically includes: Performing flow analysis on the electronic control unit to be tested based on the flow data to determine whether there is a protocol anomaly; Performing a behavioral benchmark analysis on the electronic control unit to be tested based on the behavioral data to determine whether there is behavioral abnormality; When there is a protocol anomaly and / or a behavior anomaly, determine that the security test fails, and generate a corresponding security test report according to the anomaly type; When there are no protocol anomalies and behavior anomalies, it is determined that the security test has passed, and the corresponding security test report is generated.

5. The method for detecting safety of an electronic control unit based on honeypot technology according to claim 4, characterized in that: When there is a protocol anomaly and / or a behavior anomaly, the electronic control unit safety detection method further includes the following steps: Aggregating the traffic data and the behavior data to generate a time series analysis chart; The attack source location and attack path are determined according to the timing analysis chart.

6. The method for detecting safety of an electronic control unit based on honeypot technology according to claim 1, characterized in that: Before loading the firmware of the electronic control unit to be tested into the honeypot detection environment, the following steps are also included: Common ECU attacks are simulated using penetration tools to verify whether the response of the virtual ECU honeypot meets expectations.

7. The method for detecting safety of an electronic control unit based on honeypot technology according to any one of claims 1 to 6, characterized in that: The electronic control unit safety detection method further comprises the following steps: Loading the firmware of the ECU to be tested into a real vehicle control system and recording the actual behavior of the ECU to be tested; Identify potential backdoors or vulnerabilities of the electronic control unit to be tested based on the difference between the actual behavior and the behavior data.

8. An electronic control unit security detection system based on honeypot technology, characterized in that: include: Honeypot deployment module, used to build a honeypot detection environment based on the real vehicle control system, create a virtual ECU honeypot, and configure bait data and protocol simulation rules; A flow behavior monitoring module, configured to load the firmware of the electronic control unit to be tested into the honeypot detection environment and record the flow data and behavior data of the electronic control unit to be tested; a detection module, configured to perform a safety detection on the electronic control unit to be tested based on the flow data and the behavior data, and obtain a safety detection report; The bait data is used to actively trap attack behaviors, and the protocol simulation rules are used to simulate real ECU communication protocols to trigger potential malicious operations.

9. An electronic control unit security detection device based on honeypot technology, characterized in that: include: at least one processor; at least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the electronic control unit security detection method based on honeypot technology according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that: The program executable by the processor is used to execute the electronic control unit security detection method based on honeypot technology as claimed in any one of claims 1 to 7 when executed by the processor.

Images