Penetration test system and method of vehicle-mounted controller

Abstract

According to the penetration test system and method for the vehicle-mounted controller, various types of communication interfaces and equipment interfaces are integrated in the industrial personal computer, so that the rigid requirements for communication configuration in various test scenes are met. Furthermore, through division of a bus security test module, a system security test module and a communication security test module, each module can independently construct connection with a target vehicle-mounted controller based on a Vector tool chain, an ADB / SSH, a wireless network card and a Bluetooth adapter, parallel execution of multiple test cases is supported, and the test cases do not interfere with one another; and synchronous promotion of safety tests such as bus diagnosis, system login, wireless communication and the like is realized. The upper computer serves as a control core and can automatically drive any module or multiple modules to work cooperatively according to the target test case, and test instructions are issued in a unified mode through the VT test system, so that the test preparation time and the execution period are greatly shortened, and the effect of improving the penetration test efficiency of the vehicle-mounted controller is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automatic testing, in particular to a penetration testing system and method for a vehicle-mounted controller. BACKGROUND

[0002] The vehicle-mounted controller is one of the core components of the automotive electronic system, mainly responsible for coordinating and controlling the operation of each subsystem of the vehicle, and realizing intelligent management of the functions of the vehicle power, safety, comfort, etc. Correspondingly, penetration testing is a security testing method aimed at evaluating the security and stability of various functions of the vehicle-mounted controller. However, in the current penetration testing of the vehicle-mounted controller, since the vehicle-mounted controller can support more complex functions, different test equipment needs to be used based on the specific types of different test functions when penetration testing is performed on different functions of the vehicle-mounted controller, resulting in the problem of low test efficiency of penetration testing of the vehicle-mounted controller. SUMMARY

[0003] Based on the above problems, in order to improve the penetration testing efficiency of the vehicle-mounted controller, the embodiments of the present application provide a penetration testing method, system, electronic device and medium for a vehicle-mounted controller.

[0004] The embodiments of the present application disclose the following technical solutions: In a first aspect, the embodiments of the present application provide a penetration testing system for a vehicle-mounted controller, comprising: a VT testing system and an industrial computer, wherein the industrial computer integrates multiple types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet the communication configuration of different test cases; the industrial computer comprises: a host computer, a bus security testing module, a system security testing module and a communication security testing module; the bus security testing module constructs the connection between the target vehicle-mounted controller and the industrial computer through a Vector tool chain device, the system security testing module constructs the connection between the target vehicle-mounted controller and the industrial computer through remote SSH or wired ADB, and the communication security testing module constructs the connection between the target vehicle-mounted controller and the industrial computer through a wireless network card and a Bluetooth adapter; The bus security testing module, the system security testing module and the communication security testing module are all used to support multiple test cases for the target vehicle-mounted controller; The host computer is configured to drive at least one of the bus security testing module, the system security testing module and the communication security testing module to send a test instruction to the VT testing system according to a target test case, so as to realize penetration testing on the target vehicle-mounted controller through the VT system.

[0005] In a possible implementation, the test cases supported by the bus security test module include an ID sniffing test, a DOS attack test, and a random number test; the DOS attack test is a bus flooding attack test; The test cases supported by the system security test module include a login security test, a configuration security test, a port security test, and a data security test. The test cases supported by the communication security test module include a Bluetooth test and a wireless connection test.

[0006] In a possible implementation, the execution flow of the ID sniffing test includes: sending a diagnostic request instruction to the target vehicle-mounted controller based on a preset physical addressing range, to receive a response instruction fed back by the target vehicle-mounted controller for the diagnostic request instruction; determining a response address identifier of the target vehicle-mounted controller according to the response instruction, and establishing a bidirectional communication link between the host computer and the target vehicle-mounted controller based on a preset sending address identifier of the bus security test module; sending a preset service request set to the target vehicle-mounted controller through the bidirectional communication link, to receive a plurality of response results fed back by the target vehicle-mounted controller; analyzing the support states of the target vehicle-mounted controller for each service in the preset service request set according to the plurality of response results fed back by the target vehicle-mounted controller, to implement the ID sniffing test.

[0007] In a possible implementation, the execution flow of the DOS attack test includes: generating a flooding test packet matching the target test bus based on the target test bus; the flooding test packet contains a maximum data load specified by the type of the target test bus; sending the flooding test packet to the target vehicle-mounted controller based on a preset time length and the target test bus, to maintain the real-time load rate of the target bus above a preset first threshold; stopping sending the flooding test packet after the preset time length, and sending a function diagnostic request to the target vehicle-mounted controller, to receive a request response fed back by the target vehicle-mounted controller; judging whether the function of the target vehicle-mounted controller is normal according to the request response fed back by the target vehicle-mounted controller; The execution flow of the random number test includes: continuously obtaining a plurality of secure random numbers generated by the target vehicle-mounted controller within a single power-on cycle period of the target vehicle-mounted controller; performing repetition rate analysis on all the security random numbers to obtain a random number repetition rate for a plurality of the security random numbers; in a case where the random number repetition rate is less than a preset second threshold, determining that a random number test for the target vehicle-mounted controller passes; in a case where the random number repetition rate is not less than the preset second threshold, determining that the random number test for the target vehicle-mounted controller fails.

[0008] In a possible implementation, the host computer comprises a preset password set; and an execution flow of the login security test comprises: performing, by the host computer, an adb command, and performing a login cracking operation on the target vehicle-mounted controller based on the preset password set to verify whether the login cracking operation can log in to an operating system of the target vehicle-mounted controller; an execution flow of the configuration security test comprises: obtaining a firewall configuration, a control authority configuration, and a kernel symbol table protection configuration of the target vehicle-mounted controller; performing consistency judgment on the firewall configuration, the control authority configuration, and the kernel symbol table protection configuration and a preset calibration configuration.

[0009] In a possible implementation, an execution flow of the port security test comprises: performing, by an Nmap scanning instruction, port scanning on the target vehicle-mounted controller to obtain open port information of the target vehicle-mounted controller; comparing the open port information with at least one of a preset port list and a calibration port configuration document to verify whether the open port information matches the preset port list or the calibration port configuration document; an execution flow of the data security test comprises: obtaining a system data packet of the target vehicle-mounted controller; performing sensitive data analysis on the system data packet based on a preset sensitive data feature library to determine sensitive data in the system data packet that matches the preset sensitive data feature library; performing leakage risk analysis on the sensitive data to determine whether the sensitive data has a data leakage risk.

[0010] In a possible implementation, an execution flow of the Bluetooth test comprises: simulating generation of a first Bluetooth device and a second Bluetooth device, and controlling the target vehicle-mounted controller to establish a pairing connection with the first Bluetooth device; grabbing a Bluetooth communication data packet in a process of establishing a paired connection between the target vehicle-mounted controller and the first Bluetooth device, and analyzing whether the target vehicle-mounted controller adopts an SSP pairing mode based on the Bluetooth communication data packet; simulating a DOS attack on the target vehicle-mounted controller through the second Bluetooth device, and monitoring a connection state between the target vehicle-mounted controller and the first Bluetooth device in a process of the DOS attack in real time.

[0011] In a possible implementation, the execution process of the wireless connection test comprises: controlling the host computer to connect a wireless connection hotspot of the target vehicle-mounted controller to grab data stream information in a process of establishing a connection; judging whether the data stream information meets preset security architecture rules based on the preset security architecture rules; The wireless connection test further comprises a wireless connection phishing test, and an execution process of the wireless connection phishing test comprises: controlling the host computer to start a local network hotspot of the test system, and controlling the target vehicle-mounted controller to connect to the local network hotspot; starting an automatic connection function of the target vehicle-mounted controller for the local network hotspot after the target vehicle-mounted controller establishes a connection with the local network hotspot; disconnecting the target vehicle-mounted controller from the local network hotspot, and generating a simulation network hotspot; the simulation network hotspot is only different from the local network hotspot in a MAC address; detecting whether the target vehicle-mounted controller is automatically connected to the simulation network hotspot.

[0012] In a possible implementation, the system further comprises a cloud server, and the host computer is further configured to: obtain penetration test data for the target vehicle-mounted controller; generate a penetration test report according to the penetration test data, and upload the penetration test report to the cloud server.

[0013] In a second aspect, the embodiments of the present application provide a penetration testing method of a vehicle-mounted controller, applied to a penetration testing system, the penetration testing system comprising: a VT testing system and an industrial computer, the industrial computer integrating a plurality of types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet communication configurations of different test cases; the industrial computer comprising: an upper computer, a bus security testing module, a system security testing module and a communication security testing module; the bus security testing module constructing a connection between a target vehicle-mounted controller and the industrial computer through a Vector tool chain device, the system security testing module constructing a connection between the target vehicle-mounted controller and the industrial computer through remote SSH or wired ADB, and the communication security testing module constructing a connection between the target vehicle-mounted controller and the industrial computer through a wireless network card and a Bluetooth adapter; the bus security testing module, the system security testing module and the communication security testing module are all used to support a plurality of test cases for the target vehicle-mounted controller. The method comprises: controlling the upper computer to drive at least one of the bus security testing module, the system security testing module and the communication security testing module to send a test instruction to the VT testing system, so as to realize penetration testing of the target vehicle-mounted controller through the VT system according to a target test case.

[0014] Compared with the prior art, the application has the following beneficial effects: the embodiment of the application provides a penetration test system of a vehicle-mounted controller, the system comprises a VT test system and an industrial computer, the industrial computer integrates various types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet the communication configuration of different test cases; the industrial computer comprises a host computer, a bus security test module, a system security test module and a communication security test module; the bus security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through a Vector tool chain device, the system security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through remote SSH or wired ADB, and the communication security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through a wireless network card and a Bluetooth adapter; the bus security test module, the system security test module and the communication security test module are all used to support multiple test cases for the target vehicle-mounted controller; the host computer is used to drive at least one of the bus security test module, the system security test module and the communication security test module to send a test instruction to the VT test system according to a target test case, so as to realize the penetration test for the target vehicle-mounted controller through the VT system. In this way, the embodiment integrates various types of communication interfaces and device interfaces in the industrial computer, thereby adapting to the hard requirements for communication configuration in various test scenarios and avoiding the frequent replacement of test equipment due to the incompatibility of hardware interfaces. Further, the functions of the bus security test module, the system security test module and the communication security test module are divided, and each module can independently construct the connection with the target controller based on special devices such as the Vector tool chain, ADB / SSH, a wireless network card and a Bluetooth adapter, support multiple test cases to be executed in parallel and not interfere with each other, and realize the synchronous promotion of bus diagnosis, system login, wireless communication and other security tests. The host computer as the control core can automatically drive any module or multiple modules to work cooperatively according to the target test case, send a test instruction through the VT test system, form a full-process automatic closed loop of "configuration-execution-feedback", and thereby greatly shorten the test preparation time and execution period, and achieve the effect of improving the efficiency of the penetration test of the vehicle-mounted controller. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0016] Figure 1A structural schematic diagram of a penetration testing system of a vehicle-mounted controller provided by an embodiment of the present application is provided. Figure 2 A connection structural schematic diagram of hardware devices of a penetration testing system in an actual application scenario provided by an embodiment of the present application is provided. Figure 3 An execution flow schematic diagram of ID sniffing testing provided by an embodiment of the present application is provided. Figure 4 An execution flow schematic diagram of DOS attack testing provided by an embodiment of the present application is provided. Figure 5 An execution flow schematic diagram of random number testing provided by an embodiment of the present application is provided. Figure 6 An execution flow schematic diagram of data security testing provided by an embodiment of the present application is provided. Figure 7 An execution flow schematic diagram of Bluetooth testing provided by an embodiment of the present application is provided. DETAILED DESCRIPTION

[0017] To make the objectives, technical solutions and advantages of the present application clearer, further detailed description will be made to the present application with reference to the embodiments and the accompanying drawings. It should be particularly noted that the embodiments described in the embodiments of the present application are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0018] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be understood as the common meanings of the same by those skilled in the art to which the present application belongs. The terms “first”, “second” and similar terms used in the embodiments of the present application do not represent any order, number or importance, but are only used to distinguish different components. The terms “include” or “contain” and similar terms mean that the elements or objects before the terms cover the elements or objects listed after the terms and their equivalents, without excluding other elements or objects. The terms “connect” or “connected” and similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. The terms “up”, “down”, “left”, “right” and the like are only used to represent relative positional relationships, and when the absolute positions of the described objects change, the relative positional relationships may also change accordingly.

[0019] As described in the foregoing, the on-board controller is one of the core components of the automotive electronic system, mainly responsible for coordinating and controlling the operation of various subsystems of the vehicle, and realizing intelligent management of functions such as power, safety, and comfort of the vehicle. Correspondingly, penetration testing is a security testing method aimed at evaluating the security and stability of various functions of the on-board controller. However, in the current penetration testing of the on-board controller, due to the fact that the on-board controller can support more complex functions, different test equipment needs to be used based on the specific types of different test functions when penetration testing is performed on different functions of the on-board controller, resulting in the problem of low test efficiency of the penetration testing of the on-board controller.

[0020] To solve the above problems, the embodiment of the present application provides a penetration test system of a vehicle-mounted controller, which comprises a VT test system and an industrial computer. The industrial computer is integrated with multiple types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet the communication configuration of different test cases. The industrial computer comprises an upper computer, a bus security test module, a system security test module and a communication security test module. The bus security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through a Vector tool chain device. The system security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through remote SSH or wired ADB. The communication security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through a wireless network card and a Bluetooth adapter. The bus security test module, the system security test module and the communication security test module are used to support multiple test cases for the target vehicle-mounted controller. The upper computer is used to drive at least one of the bus security test module, the system security test module and the communication security test module to send a test instruction to the VT test system according to a target test case, so as to realize the penetration test of the target vehicle-mounted controller through the VT system. In this way, the embodiment integrates multiple types of communication interfaces and device interfaces in the industrial computer, thereby adapting to the hard requirements for communication configuration in various test scenarios and avoiding the frequent replacement of test equipment due to incompatible hardware interfaces. Further, the functions of the bus security test module, the system security test module and the communication security test module are divided, and each module can independently construct the connection with the target controller based on special devices such as the Vector tool chain, ADB / SSH, a wireless network card and a Bluetooth adapter, support the parallel execution of multiple test cases and do not interfere with each other, and realize the synchronous promotion of bus diagnosis, system login, wireless communication and other security tests. The upper computer as the control core can automatically drive any module or multiple modules to work cooperatively according to the target test case, send a test instruction through the VT test system, form a full-process automatic closed loop of "configuration-execution-feedback", thereby greatly shorten the test preparation time and execution period, and achieve the effect of improving the efficiency of the penetration test of the vehicle-mounted controller.

[0021] To make the personnel in the technical field better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by the person skilled in the art without creative labor are within the protection scope of the present application.

[0022] Referring to Figure 1 and Figure 2 , Figure 1A structure diagram of a penetration testing system of a vehicle-mounted controller provided in an embodiment of the present application, Figure 2 A connection structure diagram of various hardware devices of a penetration testing system in an actual application scenario provided in an embodiment of the present application.

[0023] As Figure 1 shown, in the penetration testing system provided in the embodiment of the present application, an industrial computer 100 and a VT testing system 600 are arranged, and an upper computer 200, a bus security testing module 300, a system security testing module 400, and a communication security testing module 500 are arranged in the industrial computer 100, and different security testing modules are used to execute different test cases. In order to ensure that the communication configuration requirements of different test cases can be met when different test cases are executed, various types of wired communication interfaces, wireless communication modules, and peripheral device interfaces, such as USB interfaces, CAN bus interfaces, Ethernet interfaces, video interfaces, and the like, are integrated in the industrial computer.

[0024] On the basis of dividing three test modules, a dedicated connection mode is divided for each test module in this embodiment, so as to ensure that the penetration testing system provided in this embodiment effectively supports various test instances. Among them, the bus security testing module relies on Vector tool chain devices (such as VN1640, VH6501, etc.) to build the CAN / CANFD connection between the target vehicle-mounted controller and the industrial computer. The Vector tool chain device not only can support high-precision bus signal acquisition, but also can simulate the load pressure of the real vehicle-mounted network, so as to ensure the accuracy of the test cases such as diagnosis ID sniffing and DOS attack. For example, when performing bus DOS attack test, the Vector device can accurately control the message sending frequency and load rate, and cooperate with the script automatic execution of the industrial computer, so as to realize the continuous monitoring of the response capability of the vehicle-mounted controller under high load, and avoid the test error caused by the insufficient signal processing precision of the general device.

[0025] The system security testing module builds the connection between the industrial computer and the target vehicle-mounted controller through remote SSH or wired ADB. This design takes into account the flexibility of remote debugging and local control. For example, for the controller supporting remote management, non-intrusive security detection (such as port scanning, login brute force cracking) can be performed through SSH. For the device that needs bottom-layer debugging, the wired ADB connection can ensure the stability of the instruction issuing, and avoid the delay or disconnection problem that may be introduced by wireless communication. Further, the communication security testing module integrates WiFi and Bluetooth testing into the same hardware system with the help of a wireless network card and a Bluetooth adapter. For example, in the WiFi phishing test, the MAC address of the simulated network can be quickly switched through the wireless network card, and the automatic connection behavior of the device under test is controlled through ADB. This kind of software and hardware collaborative design can make the simulation of complex communication scenarios become efficient and controllable.

[0026] Correspondingly, the host computer as an interactive terminal between the penetration testing system and the user drives at least one of the bus security testing module, the system security testing module and the communication security testing module to send a test instruction to the VT testing system through a target test case selected by the user on the interactive terminal interface, so as to realize penetration testing on the target vehicle controller through the VT system.

[0027] The VT system is a professional vehicle network testing and simulation platform in the field of automotive electronics, mainly used for functional testing, security verification and performance analysis of vehicle controllers, bus protocols and whole vehicle networks. The system supports multiple vehicle communication protocols such as CAN, CAN FD, LIN, Ethernet / IP, FlexRay, etc., has core functions such as network simulation, message transmission and reception, fault injection, automatic script running, etc., and can simulate a real vehicle network environment and monitor controller interaction data in real time, so it is the main body of various test cases in this embodiment.

[0028] The host computer as the "nerve center" of the penetration testing system in this embodiment realizes full automation of the test process and parallel processing capability of multiple test tasks by uniformly driving the collaborative work between the three modules and the VT testing system. When the user selects a target test case on the human-computer interaction interface of the industrial computer, (such as simultaneously carrying out bus diagnostic service scanning and WiFi phishing attack simulation), the host computer needs to drive the operation of the three test modules according to the target test case selected by the user. Taking the simultaneous driving of the bus security testing module and the communication security testing module as an example, the host computer automatically calls the Vector device of the bus security module to send a UDS diagnostic instruction, and simultaneously drives the wireless network card of the communication security module to create a fake hotspot. The two modules run independently through the power control and signal isolation mechanism of the VT system and do not interfere with each other. Compared with the traditional single-threaded test, this parallel test mode significantly improves the penetration testing efficiency of the target vehicle controller.

[0029] In addition, the integrated use of hardware resources by the penetration testing system in this embodiment also reduces the test cost and the operation threshold. In the past, test personnel needed to master multiple protocol tools (such as manually operating CANoe to analyze the bus and using Nmap to scan the port), now through module encapsulation and script automation, only the selection of the test case is needed to trigger the collaborative work of the corresponding tool chain. For example, in the port security test, the system security testing module automatically calls Nmap to scan the open port of the controller, and analyzes the potential risks in combination with the built-in vulnerability database, without manual instruction writing throughout, which greatly shortens the test execution period and improves the test efficiency.

[0030] In particular, in the penetration testing system of the embodiment of the present application, a cloud server is further arranged, which is used as a core hub for data storage and management, and is configured to receive a penetration testing report generated by the host computer based on penetration testing data. After the host computer completes the testing of the bus security module, the system security module, and the communication security module, the host computer automatically integrates multi-dimensional penetration testing data, i.e., the execution log of each test case, the communication traffic file, the sensitive data detection report, and the device state feedback data. After the data is de-duplicated and compressed, the host computer automatically generates a penetration testing report according to a preset template. After the report is generated, the host computer establishes an encrypted connection with the cloud server through a secure API interface, and automatically uploads the report and the original test log. The cloud server has a hierarchical storage and permission management function, and can establish an index directory according to the project name, the test time, and the controller model, and support quick retrieval of historical reports through a web end or a special client, and trace the security performance of a specific version of the controller.

[0031] The above is the introduction of the connection relationship and control logic of various hardware devices in the penetration testing system of the embodiment of the present application. As known from the foregoing introduction of the three types of test modules, the three types of security test modules in the embodiment are respectively configured to execute different test cases. The bus security test module supports test cases including ID sniffing test, DOS attack test, and random number test. The ID sniffing test is a node identifier enumeration test, and the DOS attack test is a bus flooding attack test.

[0032] The system security test module supports test cases including login security test, configuration security test, port security test, and data security test. The communication security test module supports test cases including Bluetooth test and wireless connection test. Next, the execution process of each type of test case will be introduced in combination with specific embodiment drawings.

[0033] First, the execution process of the ID sniffing test will be introduced. In the embodiment of the present application, the ID sniffing test includes diagnostic ID sniffing test and service ID sniffing test, i.e., node identifier enumeration and diagnostic service enumeration test. Referring to Figure 3 , which is an execution process schematic diagram of the ID sniffing test provided by the embodiment of the present application, and specifically includes the following steps: S101: sending a diagnostic request instruction to the target vehicle-mounted controller based on a preset physical addressing range, to receive a response instruction fed back by the target vehicle-mounted controller for the diagnostic request instruction; S102: determining the response address identifier of the target vehicle-mounted controller according to the response instruction, and establishing a bidirectional communication link between the host computer and the target vehicle-mounted controller based on the preset sending address identifier of the bus security test module.

[0034] ID sniffing test is the core part of bus security test, and its core goal is to verify whether the protection mechanism of the target vehicle controller for diagnostic service ID is sound by simulating the probing behavior of a malicious node to the controller diagnostic communication interface, and to avoid subsequent attack risks caused by exposure of diagnostic ID. The whole test process closely relies on the Vector tool chain device (such as VN1640, VH6501) at the hardware layer and the CANoe software of the host computer to work together, and through the standardized UDS protocol interaction, the comprehensive probing of the diagnostic communication link of the target vehicle controller is realized.

[0035] Firstly, a diagnostic request instruction needs to be sent to the target vehicle controller based on a preset physical addressing range (in this embodiment, 0x700-0x7FF can be used). The setting of the physical addressing range is derived from the common ECU physical addressing specification in the vehicle network, which covers the potential communication addresses of most controllers. The host computer needs to continuously send diagnostic instructions in the form of broadcast or unicast through the CAN bus interface of the Vector device. When the target vehicle controller receives the validly addressed diagnostic request, it will return a message containing its response address identifier (i.e. response ID), and the unmatched addresses remain silent. The host computer can accurately capture the actual request ID (i.e. the source address used by the host computer when sending the diagnostic instruction) and the response ID (i.e. the target address when the target vehicle controller replies) of the target vehicle controller by analyzing these response messages. These two key identifiers constitute the "digital house number" of the subsequent two-way communication.

[0036] S103: Through the two-way communication link, a preset service request set is sent to the target vehicle controller to receive a plurality of response results fed back by the target vehicle controller.

[0037] After establishing the two-way communication link, the host computer automatically generates a preset service request set through the script, which includes common diagnostic services in the UDS protocol (such as session control $10, reset control $11, fault code clearing $14, data reading $22, security access $27, communication control $28, etc.), and iteratively tests each service sub-function (such as DID data identifier under $22 service). At this time, the Vector device simulates the nodes in the real vehicle network to send service requests to the target vehicle controller at a legal or abnormal frequency, while the CANoe software in the host computer captures the response results of the target vehicle controller in real time, focusing on two key response codes: if NRC7F (service temporarily not supported) is returned, it means that the service is not activated in the current session and needs to be retested after switching to the extended session through the $10 instruction; if NRC33 (security access denied) is returned, the subsequent security unlocking process (such as calling $27 service request seed and key) is triggered to verify whether the security authentication mechanism of the target vehicle controller is effective.

[0038] S104: According to the response results fed back by the target vehicle-mounted controller, the support state of the target vehicle-mounted controller for each service in the preset service request set is analyzed to implement the ID sniffing test.

[0039] When the traversal test of the preset service set is completed, the host computer needs to analyze all the response results based on the built-in security standard library. First, it needs to identify whether there are unauthorized open services or services that should be supported but have not responded by comparing the support service list declared in the development document. Second, the distribution of NRC error codes in the response message is counted. If a certain type of error code appears abnormally frequently, it may indicate that there is a vulnerability in the logic processing of the target vehicle-mounted controller. Finally, the bus load and response time during the test process are monitored in combination with the automated script to determine whether the target vehicle-mounted controller has abnormal performance due to service detection. In this way, the ID sniffing test for the target vehicle-mounted controller can be implemented.

[0040] The above is an introduction to the execution process of the ID sniffing test. Next, the DOS attack test and the random number test supported by the bus security test module will be introduced in turn.

[0041] Referring to Figure 4 , the figure is an execution process schematic diagram of a DOS attack test provided by an embodiment of the present application, which specifically includes the following steps: S201: Based on the target test bus, a flooding test message matching the target test bus is generated; the flooding test message contains the maximum data load specified by the target test bus type.

[0042] Before the DOS attack test is started, the host computer needs to automatically generate a flooding test message that meets the protocol specification according to the target bus type (CAN or CANFD). For a traditional CAN bus, the message data field is filled with 8 bytes of all 0xFF (i.e. 0xFFFFFFFFFFFFFFFF), which is the maximum data load (8 bytes) supported by a single CAN protocol frame. If it is a CANFD bus, 64 bytes of all 0xFF are used (the maximum support of the CANFD extended data field is 64 bytes). This "full load" design aims to maximize the occupancy rate of single-frame messages on the bus bandwidth. The message ID is usually preset as 0x01, which is a fixed identifier for attack messages, so that the interference traffic can be accurately identified during subsequent monitoring.

[0043] S202: Based on a preset time length and the target test bus, the flooding test message is sent to the target vehicle-mounted controller to maintain the real-time load rate of the target bus above a preset first threshold.

[0044] When the flooding message starts to send, the target bus immediately enters the "overload mode", that is, a large number of high-density messages occupy the communication bandwidth, thereby simulating the flooding attack scene by forging a legitimate ID. The host computer collects the load rate of the target bus in real time through the CANoe software. Once the load rate drops below the first preset threshold of 80%, the message sending rate will be automatically increased to maintain the pressure threshold through closed-loop control. This continuous impact needs to be maintained for at least a preset time (2 minutes) to cover the possible short-term cache overflow, processor overload and other delay faults of the controller.

[0045] S203: After the preset time, the sending of the flooding test message is stopped, and a function diagnosis request is sent to the target vehicle-mounted controller to receive the request response feedback by the target vehicle-mounted controller; S204: According to the request response feedback by the target vehicle-mounted controller, it is judged whether the function of the target vehicle-mounted controller is normal.

[0046] After the preset time, the sending of the flooding test message is stopped, and a function diagnosis request is sent to the target vehicle-mounted controller to receive the request response feedback by the target vehicle-mounted controller;

[0047] In one possible implementation, by comparing the message interaction logs before and after the attack, it can be seen whether there are phenomena such as abnormal closing of diagnostic services (such as not maintaining a normal security session), high-frequency occurrence of error codes (such as NRC04, request out of range), etc. For example, after the DOS attack, the target vehicle-mounted controller can respond to the diagnostic request, but the response time for the "0x22" data reading service is extended from the normal state of 10ms to 200ms. This implicit performance degradation will be automatically captured and classified as "potential vulnerability" by the script. For controllers supporting CANFD, the test system will also specially verify whether it correctly switches to the fault-tolerant mode under high load to avoid bus lock due to too short frame interval.

[0048] The above is the test flow introduction for DOS attack test, and next, the random number test is introduced.

[0049] Referring to Figure 5 , the figure is an execution flow diagram of a random number test provided by an embodiment of the application, which specifically includes the following steps: S301: In a single power cycle of the target vehicle controller, continuously obtain a plurality of security random numbers generated by the target vehicle controller.

[0050] Before the random number test starts, the host computer performs a power-off and power-on operation on the target vehicle controller through the relay module to ensure that it enters a completely new single power cycle, thereby ensuring the accuracy of the test. After the target vehicle controller initializes, the host computer sends a security access request in the UDS protocol through the CAN interface of the Vector device. Upon receiving the request, the target vehicle controller activates the built-in random number generation module to generate a security random number and returns it to the host computer through the CAN message. To ensure that enough samples are collected, the host computer script sends the "request seed" instruction at an interval of 200 ms (at least 1000 samples are collected in a single cycle) to cover the random number generation of the controller in different operating states (such as entropy source fluctuations during idling and load changes).

[0051] S302: Analyze the repetition rate of all security random numbers to obtain the random number repetition rate for a plurality of security random numbers.

[0052] After the sample size is collected, the host computer converts all random numbers to hash values, unifies different length values to fixed length feature codes for efficient comparison. The traditional line-by-line comparison algorithm (such as Bloom filter) is optimized here, using a parallel computing framework to speed up duplicate retrieval, ensuring that thousands of samples are analyzed within seconds. The repetition rate calculation follows the formula "number of repetitions / total number of samples", but special attention is paid to two abnormal patterns: "continuous repetition" and "interval repetition". The former refers to two adjacent random numbers being exactly the same (such as 0x1234 returned twice in a row), and the latter refers to non-adjacent samples having the same value (such as the 10th and 100th random numbers being the same). Both of these cases are considered direct evidence of entropy source failure.

[0053] The setting of the preset second threshold value is strongly related to the security level of the vehicle controller. For core controllers involving key exchange, the threshold value is usually set to 0.1% (i.e., 1 repetition allowed in 1000 samples), while non-critical nodes such as body controllers can be relaxed to 0.5%. If the repetition rate exceeds the threshold during analysis, the system will automatically trigger the "abnormal sample tracing" mechanism: retrieve the bus load data corresponding to the timestamp, investigate whether the entropy source sampling is interrupted due to CPU overload, and compare the target vehicle controller's diagnostic logs to see if the random number generation module has reported initialization errors. For example, if a controller has a 0.8% repetition rate in sample analysis, further tracing reveals that the temperature sensor data it relies on for generating random numbers fails to update in real time due to bus congestion, resulting in a single entropy source input. This hidden defect is precisely located through testing.

[0054] S303: determining whether the repetition rate of the random number is less than a preset second threshold value; S304: in the case where the repetition rate of the random number is less than the preset second threshold value, determining that the random number test for the target vehicle-mounted controller is passed; S305: in the case where the repetition rate of the random number is not less than the preset second threshold value, determining that the random number test for the target vehicle-mounted controller is failed.

[0055] If the repetition rate is lower than the threshold value, and there is no continuous repetition or regular repetition phenomenon, it is determined that the random number test is passed, indicating that the security authentication basis of the target vehicle-mounted controller is solid and can resist attacks based on random number prediction. In a possible implementation, if the repetition rate exceeds the threshold value, the system will immediately start a secondary verification: first, the power supply of the target vehicle-mounted controller is cut off through a relay and then powered on again, and the test is repeated in the new power-on period to distinguish between "accidental failure" and "systematic defect" - if the high repetition rate appears in three tests, it is determined as a deterministic vulnerability. Secondly, the spectrum analysis is performed on the samples exceeding the threshold value to check whether the value distribution presents periodicity (such as the same value appearing every 50 samples), which usually indicates that the pseudo-random number generation algorithm (PRNG) lacks the participation of a hardware entropy source and has a predictable risk.

[0056] The above is the introduction of the test flow for the random number test. Next, the execution flow of the login security test and the configuration security test will be introduced.

[0057] The login security test and the configuration security test both belong to the test cases supported by the system security test module, and the execution flow of the login security test specifically includes the following step: Step one, executing an adb command through the host computer, and performing a login cracking operation on the target vehicle-mounted controller based on the preset password set to verify whether the login cracking operation can log in to the operating system of the target vehicle-mounted controller.

[0058] The login security test is a key link for verifying the access control mechanism of the operating system, and the core is to simulate the behavior of a malicious user trying to log in by using a weak password or a default password, so as to test whether the target vehicle-mounted controller has effective identity authentication protection capability.

[0059] Specifically, before testing, the target vehicle controller needs to be connected directly to the host computer through a USB cable, ensuring that its ADB debugging interface is active. When the ADB connection is stable, the host computer will enter the Linux terminal environment of the target vehicle controller (assuming the controller is based on the Android or QNX system) through the adb shell command. At this point, the test enters the login cracking implementation phase. The automated script calls the login command at a frequency of 5-10 times per second, each attempt carrying an entry from the preset password set, and capturing the terminal return result in real time: if a "Permission denied" prompt appears, the password is incorrect; if it returns "Login successful" or gets the administrator permission prompt (#), it is determined that the login cracking is successful.

[0060] When the preset password set is exhausted, the host computer will perform multi-dimensional analysis on the login cracking results. First, count the number of successful login passwords. If the default password is found to be unmodified, it is immediately marked as a high-risk vulnerability. Second, check if the controller has a login failure protection mechanism - for example, whether it triggers account locking after 5 consecutive password errors, or whether it records login logs. If such mechanisms are lacking, even if the password strength meets the standard, it is still determined to be a defect in the authentication system.

[0061] Next, the execution process of the configuration security test is introduced, which specifically includes the following two steps: Step one, obtain the firewall configuration, control permission configuration and kernel symbol table protection configuration of the target vehicle controller; Step two, consistency judgment of the firewall configuration, control permission configuration and kernel symbol table protection configuration with the preset calibration configuration.

[0062] Configuration security testing is the core link to verify whether the underlying security policy of the target vehicle controller is compliant, mainly checking the firewall rules, access control permissions and kernel protection mechanisms of the operating system.

[0063] Before testing, the host computer will establish a secure connection with the target vehicle controller through the ADB debugging interface or SSH service, and use the privileged account reserved during development to perform login operations, in order to obtain the firewall configuration, control permission configuration and kernel symbol table protection configuration of the target vehicle controller.

[0064] After the configuration data collection is completed, the host computer compares the three types of configuration data with the preset calibration configuration (derived from the safety baseline defined in the development phase) item by item. The consistency judgment follows the whitelist priority principle. That is, the firewall rule needs to completely match the allowed port in the baseline, and any unauthorized port opening or policy missing (such as not prohibiting UDP broadcast) is considered a high-risk item. In the control authority configuration, if there is an account outside the baseline (such as the "admin" account not registered in the configuration file) or the authority amplification phenomenon, it is immediately marked as a medium-risk vulnerability. The kernel symbol table protection configuration requires that kernel.kptr_restrict must be equal to 2, and the number of exported symbols must not exceed the baseline threshold (such as the production version should be reduced by more than 70% of unnecessary symbols compared to the development version).

[0065] For the difference items found in the comparison process, the system will automatically classify them according to the degree of security impact: inconsistent firewall configuration may lead to external attack vector exposure, such as hackers breaking through the open SSH port brute force, abnormal control authority configuration may cause internal authority abuse, such as low-privilege processes obtaining file tampering capabilities, and missing kernel symbol table protection directly threatens the integrity of the system kernel. The test script generates a visual difference report, marking the actual value and baseline value of the specific configuration item.

[0066] The above is the test process introduction for login security testing and configuration security testing. Next, the execution process of port security testing and data security testing will be introduced.

[0067] First, the execution process of port security testing is introduced, which specifically includes the following two steps: Step 1: Perform port scanning on the target vehicle controller through Nmap scanning instructions to obtain open port information of the target vehicle controller.

[0068] Before performing port security testing, the target vehicle controller needs to be connected with the host computer through USB, Ethernet, or wireless WiFi interface. For wired scenarios, activate the data channel through ADB debugging port or SSH service; for wireless scenarios, first connect to the hotspot (such as WiFi named "MAXUS") created by the target vehicle controller through EDIMAX device to ensure network layer connectivity. Then, the host computer runs Nmap scanning instructions through Kali system to obtain open port information of the target vehicle controller.

[0069] Step 2: Compare the open port information with at least one of the preset port list and the calibration port configuration document to verify whether the open port information matches the preset port list or the calibration port configuration document.

[0070] After obtaining the open port information of the target vehicle controller, the host computer needs to compare it with at least one of the preset port list and the calibration port configuration document. The preset port list contains a minimum necessary port set for different controller models (such as domain controller only allows CAN diagnostic port and HTTPS 443 port open, vehicle controller prohibits all TCP ports), and the calibration port configuration document is derived from the security baseline defined in the development stage, which details the purpose of each port, authorized access IP range and security protocol requirements (such as 22 port only allows internal test IP segment access, and needs to enable key authentication instead of password login). The comparison logic follows the minimization principle, that is, any port not registered in the preset list is directly marked as a high-risk item. If the port is in the list but the configuration is abnormal (such as 80 port does not enable HTTPS encryption), it is determined as a medium-risk vulnerability.

[0071] Next, the execution flow of the data security test is introduced, see Figure 6 , which is a data security test execution flow diagram provided by an embodiment of the present application, specifically including the following steps: S401: Obtain the system data packet of the target vehicle controller; The data security test aims to ensure that there is no information leakage risk in the running process of the target vehicle controller through tracking and risk deduction of sensitive data. First, the host computer needs to comprehensively collect data carriers (i.e. system data packets) that may contain sensitive information. For the static layer, pull the system partition file from the Android system controller through the ADB tool, or package the / etc, / var configuration directory through SSH login Linux system.

[0072] S402: Perform sensitive data analysis on the system data packet based on a preset sensitive data feature library to determine sensitive data in the system data packet that matches the preset sensitive data feature library; S403: Perform leakage risk analysis on the sensitive data to determine whether the sensitive data has a data leakage risk.

[0073] Based on the analysis link of the preset sensitive data feature library, the accurate screening and risk positioning of the system data packet are realized through the combination of the rule engine and the AI model. The preset feature library is customized for the vehicle-mounted scene and contains core detection dimensions such as identity identification, VIN code, IMEI, mobile phone number, key certificate, user privacy, etc. Through regular expression matching, keyword scanning and file format analysis, sensitive data in plaintext or coded form is quickly identified. For complex scenarios that are difficult for the rule engine to cover, the AI analysis program constructs an abstract syntax tree to analyze whether file reading and writing, network transmission and other operations are related to sensitive data through code semantic analysis and data flow tracking, and identifies abnormal data aggregation or unauthorized transmission behavior in combination with the normal data baseline trained by machine learning. Thereafter, the risk authenticity is verified through simulated attack paths, the risk level is divided according to the exposure path and the influence degree, and a test report containing sensitive data details and risk repair suggestions is automatically generated to realize the full-process automatic analysis from data collection to risk judgment, and to ensure that the vehicle-mounted controller avoids sensitive information leakage hazards in design and operation.

[0074] The above is the test process introduction for data security testing. Next, the execution process of Bluetooth testing is introduced. Referring to Figure 7 , which is a schematic diagram of an execution process of Bluetooth testing provided by an embodiment of the present application, and specifically includes the following steps: S501: Simulate a first Bluetooth device and a second Bluetooth device, and control the target vehicle-mounted controller to establish a paired connection with the first Bluetooth device; S502: Capture Bluetooth communication data packets in the process of establishing a paired connection between the target vehicle-mounted controller and the first Bluetooth device, and analyze whether the target vehicle-mounted controller adopts an SSP pairing mode based on the Bluetooth communication data packets; S503: Simulate a DOS attack on the target vehicle-mounted controller through the second Bluetooth device, and monitor the connection state of the target vehicle-mounted controller and the first Bluetooth device in the process of the DOS attack in real time.

[0075] In the Bluetooth test process of the vehicle-mounted controller, the host computer first generates a first Bluetooth device and a second Bluetooth device through the Kali system simulation to build a double-device test environment to verify the Bluetooth security mechanism of the target vehicle-mounted controller. Then, the host computer issues a pairing instruction to the target vehicle-mounted controller through the ADB command, forcing it to establish a connection with the simulated first Bluetooth device. In the process, the Bluetooth packet capture tool of the Kali system is started synchronously to capture link layer communication data packets in real time. The captured data packets are automatically parsed, and the use of the Secure Simple Pairing (SSP) mode in the pairing process is analyzed in detail. If the key exchange field specific to the SSP protocol does not appear in the data packet or a traditional PIN code pairing is used, it is determined that there is a security risk in the pairing mode, and further verification of the configuration strategy is required.

[0076] After completing the pairing mode verification, the test enters the DOS attack simulation link. The second Bluetooth device will continuously send a large number of meaningless Bluetooth data packets (such as fixed format empty data frames) to the target vehicle-mounted controller through the l2ping tool or custom script, pushing the target bus load to more than 80% and lasting for 2 minutes, simulating the resource exhaustion attack of malicious devices on the Bluetooth channel. In this process, the host computer monitors the connection state of the first Bluetooth device and the target vehicle-mounted controller in real time, and judges whether abnormal disconnection, reconnection failure, or service interruption occurs through ADB logs and device state feedback. If the connection remains stable during the attack and the target vehicle-mounted controller can normally handle legitimate communication requests, it proves that it has anti-interference ability; if frequent disconnection or resource occupation leads to functional paralysis, it is located as a high-risk vulnerability. In addition, the test also synchronously analyzes the Bluetooth protocol stack log of the target vehicle-mounted controller to check for potential security defects such as buffer overflow and unauthorized access, ensuring that no sensitive information is leaked through the Bluetooth channel during the attack. The entire test process is controlled by software and hardware cooperation, realizing full-link verification from pairing security to anti-attack ability, covering the main security risk points of Bluetooth connection in the vehicle scene, and providing quantitative evaluation basis for the security of the Bluetooth module of the controller.

[0077] The above is an introduction to the test process for Bluetooth testing. Next, the execution process of the wireless connection test is introduced.

[0078] Specifically, the execution process of the wireless connection test in the embodiments of the present application is realized through the following two steps: Step one controls the wireless connection hotspot of the target vehicle-mounted controller connected to the host computer to capture data stream information in the connection process.

[0079] Similar to the Bluetooth connection test, in the wireless connection test process for the vehicle controller, first, a test environment is constructed by the wireless network card of the hardware layer and the EDIMAX device, and the target vehicle controller is controlled by the host computer through the ADB command to open the wireless connection function (WiFi hotspot function) with the preset name "MAXUS". At the same time, it is ensured that the target vehicle controller and the host computer maintain a debugging connection through a wired interface, so as to obtain real-time state feedback. After the hotspot is activated, the host computer actively connects the WiFi network, and in this process, the packet capture tool of the Kali system is enabled to capture the complete data stream generated in the connection process in real time, including key information such as DHCP negotiation messages, ARP request responses, WPA / WPA2 / WPA3 key exchange handshake packets, etc. The captured data stream is automatically parsed to extract the core parameters of the hotspot: WiFi name (SSID), MAC address, etc.

[0080] Step two, based on the preset security architecture rule, it is judged whether the data stream information meets the preset security architecture rule.

[0081] The analysis link based on the preset security architecture rule aims to verify whether the security parameters in the data stream meet the industry standards. For example, it is mandatory to use WPA3 encryption instead of the easily broken WPA2, it is prohibited to disclose the device model or user information in the hotspot name, it is necessary to randomize the MAC address to avoid physical location tracking, and it is necessary to check whether there is a replay attack vulnerability in the key exchange process. If it is detected that a weak encryption algorithm, insufficient password strength, or plaintext transmission configuration information is used, it is directly determined as a security risk. In addition, the test also simulates malicious device MAC address spoofing attacks and DOS attacks on the hotspot through preset scripts. The former verifies whether the target vehicle controller has MAC filtering or access authentication mechanism, and the latter detects whether the hotspot will be interrupted or abnormally restarted under high load by continuously sending a large number of invalid connection requests. For the WiFi phishing scene, the host computer will first create a false network with the same hotspot name and encryption method as the target vehicle controller, but with a different MAC address, and observe whether the target vehicle controller will mistakenly access the phishing network when automatically reconnecting, and verify whether it has network identity authentication capability. All detection results will be combined with the protocol vulnerability characteristics in the data stream (such as whether there is a publicly disclosed WiFi driver vulnerability) to classify the risks, and finally generate a test report containing security parameter details, vulnerability points and repair suggestions, to ensure that the WiFi module of the vehicle controller has the ability to resist network eavesdropping, access attacks and phishing fraud in an open environment, and to build a secure defense line for wireless connection from the communication link layer.

[0082] In a possible implementation, the wireless connection test further includes a wireless connection phishing test, and the execution process of the wireless connection phishing test includes the following four steps: Step one, turn on the local network hotspot of the test system through the host computer, and control the target vehicle-mounted controller to connect with the local network hotspot; Step two, after the target vehicle-mounted controller establishes a connection with the local network hotspot, start the automatic connection function of the target vehicle-mounted controller for the local network hotspot; Step three, disconnect the target vehicle-mounted controller from the local network hotspot, and generate a simulated network hotspot; the simulated network hotspot only differs from the local network hotspot in MAC address; Step four, detect whether the target vehicle-mounted controller is automatically connected to the simulated network hotspot.

[0083] In the prior art, vehicle-mounted devices may be mistakenly connected to maliciously imitated networks due to defects in network identification mechanisms, resulting in data leakage or illegal acquisition of control authority. To solve this problem, the wireless connection phishing test method proposed in the embodiment realizes the security verification of the network automatic connection strategy of the vehicle-mounted controller by constructing a standardized test process and a precise simulation environment. The specific execution process is mainly based on "local network hotspot construction-device connection configuration-simulation network switching-automatic connection capability detection", relying on the automatic control capability of the host computer to ensure the standardization of the test process and the reliability of the results.

[0084] First, the host computer turns on the local network hotspot (such as a special hotspot generated by the Kali system) of the test system to build an initial connection environment "local network hotspot". This hotspot serves as a benchmark network, and its configuration parameters (such as SSID, encryption method, authentication protocol, etc.) are completely consistent with the legal network in the actual application scenario of the vehicle-mounted controller, ensuring that the device under test can be normally identified and connected. Subsequently, the host computer issues instructions to the target vehicle-mounted controller through ADB and other control interfaces, forcing it to establish a connection with the local network hotspot and activating the "automatic connection" function of the target vehicle-mounted controller. This step simulates the typical scenario of "remembering frequently used networks and automatically reconnecting" in daily use, covering the network connection strategies of the vehicle-mounted controller in factory preset or user configuration. In this process, the test system synchronously records the underlying data such as connection time, authentication protocol type, and key negotiation process, providing a benchmark reference for subsequent comparison and analysis.

[0085] After the target vehicle-mounted controller is stably connected with the local network hotspot, the host computer disconnects the device from the original hotspot, and then generates a "simulation network hotspot". The core feature of the simulation network is that "there is only a MAC address difference with the local network hotspot, and the rest of the configuration is completely consistent" - that is, the same SSID, encryption algorithm, authentication parameters (such as PSK key), frequency band and other key information are retained, and only the MAC address identification of the physical layer is modified. This design accurately simulates the "fishing means" of malicious attackers in reality - by forging the SSID and configuration of a legitimate network and only changing the MAC address to bypass simple network identification mechanisms, it induces the vehicle-mounted device to misconnect.

[0086] In the detection stage, the test system continuously monitors the network connection state of the target vehicle-mounted controller and observes whether it is automatically connected to the simulation network hotspot. If the device only relies on upper-layer configuration information such as SSID and encryption method for network identification and does not perform legality verification on the MAC address, it may misjudge the simulation network as a legitimate network, trigger automatic connection, and expose the security vulnerability of "verifying only network configuration and ignoring physical layer identification". On the contrary, if the device checks the legality of the MAC address in the automatic connection strategy, it will refuse to connect to the simulation network, indicating that it has the ability to resist phishing attacks. This test controls a single variable to explicitly verify the network identification logic of the vehicle-mounted controller, providing a direct basis for evaluating its security level.

[0087] In particular, in another possible implementation, the DOS attack test method applied in the Bluetooth test in the above embodiment can also be applied to the wireless connection test for the target vehicle-mounted controller, and this embodiment will not repeat the description.

[0088] The embodiment of the application provides a penetration test system of a vehicle-mounted controller, the system comprises a VT test system and an industrial computer, the industrial computer is integrated with various types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet the communication configuration of different test cases; the industrial computer comprises a host computer, a bus security test module, a system security test module and a communication security test module; the bus security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through a Vector tool chain device, the system security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through remote SSH or wired ADB, and the communication security test module constructs the connection between the target vehicle-mounted controller and the industrial computer through a wireless network card and a Bluetooth adapter; the bus security test module, the system security test module and the communication security test module are all used for supporting multiple test cases for the target vehicle-mounted controller; the host computer is used for driving at least one of the bus security test module, the system security test module and the communication security test module to send a test instruction to the VT test system according to a target test case, so that the penetration test for the target vehicle-mounted controller is realized through the VT system. In this way, the embodiment integrates various types of communication interfaces and device interfaces in the industrial computer, thereby adapting to the hard requirements for communication configuration in various test scenarios, and avoiding the frequent replacement of test equipment caused by the incompatibility of hardware interfaces. Further, through the function division of the bus security, system security and communication security three test modules, each module can independently construct the connection with the target controller based on special devices such as the Vector tool chain, ADB / SSH, a wireless network card and a Bluetooth adapter, supports the parallel execution of multiple test cases and does not interfere with each other, and realizes the synchronous promotion of bus diagnosis, system login, wireless communication and other security tests. The host computer as the control core can automatically drive any module or multiple modules to work cooperatively according to the target test case, sends a test instruction through the VT test system, forms a full-process automatic closed loop of "configuration-execution-feedback", and thus greatly shortens the test preparation time and the execution period, and achieves the effect of improving the efficiency of the penetration test of the vehicle-mounted controller.

[0089] The embodiment of the application further provides a penetration test method of a vehicle-mounted controller, which is applied to a penetration test system, the penetration test system comprising: a VT test system and an industrial computer, the industrial computer integrating various types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet communication configurations of different test cases; the industrial computer comprising: an upper computer, a bus security test module, a system security test module and a communication security test module; the bus security test module constructing a connection between a target vehicle-mounted controller and the industrial computer through a Vector tool chain device, the system security test module constructing the connection between the target vehicle-mounted controller and the industrial computer through remote SSH or wired ADB, and the communication security test module constructing the connection between the target vehicle-mounted controller and the industrial computer through a wireless network card and a Bluetooth adapter; the bus security test module, the system security test module and the communication security test module are all used to support multiple test cases for the target vehicle-mounted controller. The method comprises: controlling the upper computer to drive at least one of the bus security test module, the system security test module and the communication security test module to send a test instruction to the VT test system according to a target test case, so as to realize penetration test for the target vehicle-mounted controller through the VT system.

[0090] It should be noted that each of the embodiments in the specification adopts a progressive manner for description, and the same and similar parts between each embodiment can be referred to each other, and each embodiment mainly describes the difference from other embodiments. Especially, since the method and the system are basically similar to the method embodiment, the description is relatively simple, and the related parts can be referred to the part of the method embodiment. The method and the system described above are only illustrative, wherein the units described as separate components can be or can not be physically separated, and the components prompted as units can be or can not be physical units, that is, they can be located in one place, or can be distributed on multiple network units. According to the actual needs, part or all of the modules can be selected to achieve the purpose of the embodiment scheme. Those skilled in the art can understand and implement without creative labor.

[0091] The above is only one specific embodiment of the application, but the protection scope of the application is not limited to this, any skilled person in the art can easily think of changes or replacements within the technical range disclosed in the application, which should be covered in the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims.

Claims

1. A penetration testing system for a vehicle controller, characterized in that: include: VT test system and industrial computer, the industrial computer integrates multiple types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet the communication configuration of different test cases; the industrial computer includes: a host computer, a bus security test module, a system security test module and a communication security test module; the bus security test module establishes a connection between the target vehicle controller and the industrial computer through the Vector tool chain device, the system security test module establishes a connection between the target vehicle controller and the industrial computer through remote SSH or wired ADB, and the communication security test module establishes a connection between the target vehicle controller and the industrial computer through a wireless network card and a Bluetooth adapter; The bus security test module, the system security test module and the communication security test module are all used to support multiple test cases for the target vehicle controller; The host computer is used to drive at least one of the bus security test module, the system security test module and the communication security test module to send a test instruction to the VT test system according to the target test case, so as to implement a penetration test on the target vehicle controller through the VT system.

2. The system according to claim 1, wherein: The test cases supported by the bus security test module include: ID sniffing test, DOS attack test and random number test; the DOS attack test is a bus flooding attack test; The test cases supported by the system security test module include: login security test, configuration security test, port security test and data security test; The test cases supported by the communication security test module include: Bluetooth test and wireless connection test.

3. The system according to claim 2, characterized in that The execution process of the ID sniffing test includes: Sending a diagnosis request instruction to the target vehicle controller based on a preset physical addressing range, so as to receive a response instruction fed back by the target vehicle controller in response to the diagnosis request instruction; Determine the response address identifier of the target vehicle controller according to the response instruction, and establish a two-way communication link between the host computer and the target vehicle controller based on the preset sending address identifier of the bus safety test module; traversally sending a preset service request set to the target vehicle controller via the bidirectional communication link to receive multiple response results fed back by the target vehicle controller; According to the multiple response results fed back by the target vehicle controller, the support status of the target vehicle controller for each service in the preset service request set is analyzed to implement the ID sniffing test.

4. The system according to claim 2, wherein: The execution process of the DOS attack test includes: Based on a target test bus, generating a flood test message matching the target test bus; the flood test message includes a maximum data payload specified by the target test bus type; Sending the flooding test message to the target vehicle controller based on a preset duration and the target test bus to maintain the real-time load rate of the target bus above a preset first threshold; After the preset time period, the sending of the flood test message is stopped, and a function diagnosis request is sent to the target vehicle controller to receive a request response fed back by the target vehicle controller; Determining whether the function of the target vehicle-mounted controller is normal according to the request response fed back by the target vehicle-mounted controller; The execution process of the random number test includes: Continuously obtaining a plurality of secure random numbers generated by the target vehicle-mounted controller within a single power-on cycle of the target vehicle-mounted controller; Performing repetition rate analysis on all of the secure random numbers to obtain random number repetition rates for a plurality of the secure random numbers; When the random number repetition rate is less than a preset second threshold, determining that the random number test for the target vehicle controller passes; When the random number repetition rate is not less than the preset second threshold, it is determined that the random number test for the target vehicle controller has failed.

5. The system according to claim 2, wherein: The host computer includes: a preset password set; the execution process of the login security test includes: Executing an adb command on the host computer and performing a login cracking operation on the target vehicle-mounted controller based on the preset password set to verify whether the login cracking operation can log into the operating system of the target vehicle-mounted controller; The execution process of the configuration security test includes: Obtaining the firewall configuration, control authority configuration, and kernel symbol table protection configuration of the target vehicle controller; The firewall configuration, control authority configuration and kernel symbol table protection configuration are judged to be consistent with the preset calibration configuration.

6. The system according to claim 2, wherein: The execution process of the port security test includes: Perform port scanning on the target vehicle controller using the Nmap scanning command to obtain open port information of the target vehicle controller; Comparing the open port information with at least one of a preset port list and a calibrated port configuration document to verify whether the open port information matches the preset port list or the calibrated port configuration document; The execution process of the data security test includes: Obtaining a system data packet of the target vehicle-mounted controller; Performing sensitive data analysis on the system data packet based on a preset sensitive data signature library to determine sensitive data in the system data packet that matches the preset sensitive data signature library; Perform a leakage risk analysis on the sensitive data to determine whether there is a data leakage risk for the sensitive data.

7. The system according to claim 2, wherein: The execution process of the Bluetooth test includes: Simulating a first Bluetooth device and a second Bluetooth device, and controlling the target vehicle controller to establish a pairing connection with the first Bluetooth device; capturing a Bluetooth communication data packet during the process of establishing a pairing connection between the target vehicle controller and the first Bluetooth device, and analyzing whether the target vehicle controller adopts the SSP pairing mode based on the Bluetooth communication data packet; A DOS attack on the target vehicle controller is simulated by the second Bluetooth device, and the connection status between the target vehicle controller and the first Bluetooth device is monitored in real time during the DOS attack.

8. The system according to claim 2, wherein: The execution process of the wireless connection test includes: Controlling the host computer to connect to the wireless connection hotspot of the target vehicle-mounted controller to capture data flow information during the connection establishment process; Based on a preset security architecture rule, determining whether the data flow information satisfies the preset security architecture rule; The wireless connection test further includes: a wireless connection fishing test, and the execution process of the wireless connection fishing test includes: Opening the local network hotspot of the test system through the host computer, and controlling the target vehicle controller to connect to the local network hotspot; After the target vehicle-mounted controller establishes a connection with the local network hotspot, starting an automatic connection function of the target vehicle-mounted controller to the local network hotspot; Disconnecting the target vehicle controller from the local network hotspot and generating a simulated network hotspot; the simulated network hotspot differs from the local network hotspot only in the MAC address; Detect whether the target vehicle controller is automatically connected to the simulated network hotspot.

9. The system according to claim 1, wherein: Also includes: a cloud server; the host computer is also used for: Obtaining penetration test data for the target vehicle controller; Generate a penetration test report based on the penetration test data, and upload the penetration test report and the penetration test data to the cloud server.

10. A penetration testing method for a vehicle controller, characterized in that: Applied to a penetration testing system, the penetration testing system includes: a VT testing system and an industrial computer, the industrial computer integrates multiple types of wired communication interfaces, wireless communication modules and peripheral device interfaces to meet the communication configuration of different test cases; the industrial computer includes: a host computer, a bus security test module, a system security test module and a communication security test module; the bus security test module establishes a connection between the target vehicle controller and the industrial computer through a Vector tool chain device, the system security test module establishes a connection between the target vehicle controller and the industrial computer through remote SSH or wired ADB, and the communication security test module establishes a connection between the target vehicle controller and the industrial computer through a wireless network card and a Bluetooth adapter; the bus security test module, the system security test module and the communication security test module are all used to support multiple test cases for the target vehicle controller; The method comprises: Control the host computer and, based on the target test case, drive at least one of the bus security test module, the system security test module, and the communication security test module to send a test instruction to the VT test system, so as to implement a penetration test on the target vehicle controller through the VT system.

Images