Fuzzy test method, device and equipment for CAN (Controller Area Network) bus and medium

Abstract

The invention discloses a CAN bus fuzzy test method, device and equipment and a medium, and relates to the technical field of automotive electronics and industrial automation. According to the scheme, the target field in the CAN bus log file is extracted, and the target variation action is generated according to the target field, the strategy network and the historical reward, so that variation parameters are dynamically adjusted according to the real-time communication state and the historical reward, the blind measurement limitation of a fixed strategy is avoided, and the vulnerability coverage range is remarkably expanded; a target variation point is further determined according to a target field and a variation point prediction model, a test message is generated according to the target field and a target variation action, and the test message is input into a tested target according to a scheduling algorithm based on the target variation point, so that an area where abnormity is most likely to be triggered can be focused, and invalid injection is reduced; meanwhile, monitoring data fed back by the tested target is continuously obtained in the testing process, comprehensive analysis is conducted on the monitoring data, manual intervention is not needed, and higher self-adaptive capacity and testing efficiency are achieved.

Description

Technical Field

[0001] The present application relates to the fields of automotive electronics and industrial automation technology, and in particular to a CAN bus fuzzy testing method, device, equipment and medium. Background Art

[0002] The Controller Area Network (CAN) bus is widely used in automotive electronics and industrial automation due to its efficient communication capabilities. However, its openness also raises security concerns, making fuzz testing of the CAN bus particularly important.

[0003] Current fuzz testing methods for the CAN bus, such as random mutation and rule-based mutation strategies, can detect some vulnerabilities, but lack adaptability and are difficult to cope with changing attack environments. Furthermore, these testing tools often require extensive manual operation and configuration, increasing testing difficulty and cost.

[0004] In view of the above, how to solve the problem that the current CAN bus fuzzy testing method lacks adaptive capabilities and requires a lot of manual intervention is an urgent problem that needs to be solved by technicians in this field. Summary of the Invention

[0005] The purpose of this application is to provide a CAN bus fuzzy testing method, device, equipment and medium to solve the problem that the current CAN bus fuzzy testing method lacks self-adaptation and requires a lot of manual intervention.

[0006] To solve the above technical problems, the present application provides a CAN bus fuzzy testing method, comprising:

[0007] Extract the target field from the CAN bus log file;

[0008] Generate a target variant action based on the target field, the policy network, and the historical rewards; wherein the policy network is a neural network model pre-trained based on the historical field for generating corresponding variant actions; and the historical rewards are rewards corresponding to the variant actions generated by the policy network based on the historical field;

[0009] Determining a target variation point based on the target field and a variation point prediction model; wherein the variation point prediction model is a neural network model pre-trained based on historical fields for determining variation points in each data bit of a CAN message payload whose risk level meets preset requirements;

[0010] generating a test message according to the target field and the target mutation action, and inputting the test message into the target under test according to a scheduling algorithm based on the target mutation point to perform fuzz testing;

[0011] Obtain monitoring data fed back by the measured target and perform comprehensive analysis on the monitoring data.

[0012] On the one hand, the target fields in the CAN bus log file are extracted, including:

[0013] Collecting binary log files or text log files output by a network bus development tool to obtain the CAN bus log file;

[0014] Extracting a frame identifier, a data length code, a CAN payload, a timestamp, and an error flag of each CAN message frame in the CAN bus log file to extract an initial field;

[0015] Data cleaning is performed on each of the initial fields to obtain the target field.

[0016] On the other hand, data cleaning is performed on each of the initial fields, including:

[0017] Removing non-CAN message frames and invalid repeated CAN message frames in each of the error identifiers;

[0018] Converting each frame identifier into a hexadecimal representation;

[0019] The time difference between adjacent frames is calculated according to the timestamps, and the target fields obtained after buffering the data are cleaned.

[0020] On the other hand, a target mutation action is generated according to the target field, the policy network and the historical rewards, including:

[0021] Calculating the byte entropy and 0 / 1 ratio of the CAN payload of each CAN message frame;

[0022] Counting the average time interval, time interval standard deviation and burst length of the same frame identifier;

[0023] Determine the number of triggering rules for the preceding identifier to trigger the following identifier according to a priori algorithms;

[0024] Normalizing the byte entropy, the 0 / 1 ratio, the average time interval, the time interval standard deviation, the burst length, and the number of trigger rules and concatenating them in a fixed order to generate a 128-dimensional feature vector;

[0025] The 128-dimensional feature vector and the most recent historical reward are input into the policy network to generate the target mutation action; wherein the target mutation action includes a target frame identifier, a byte index, a bit mask, and a flip rate; the policy network is composed of two fully connected layers, a ReLU activation function, and a Softmax output layer;

[0026] After inputting the test message into the target under test, obtaining a target triggering event fed back by the target under test;

[0027] Determining a target reward value corresponding to the target trigger event based on reward values ​​corresponding to each trigger event of the reward function; wherein the trigger event of the reward function includes at least an electronic control unit reset, a bus shutdown, a frame error, a delay greater than a threshold without abnormality, and a normal frame;

[0028] Fine-tune the policy network according to the target reward value and the policy gradient algorithm.

[0029] On the other hand, determining the target variation point according to the target field and the variation point prediction model includes:

[0030] Expanding a first preset number of CAN message frames closest to the current moment into a two-dimensional matrix in ascending order of the corresponding frame identifiers;

[0031] Normalizing each data bit in each of the two-dimensional matrices according to a corresponding real level, and filling missing marks between frames to pre-process each of the two-dimensional matrices;

[0032] Outputting each of the preprocessed two-dimensional matrices to the variation point prediction model to output a risk score for each data bit of the CAN message frame payload; wherein the variation point prediction model is composed of a first convolutional layer, a second convolutional layer, a global average pooling layer, and a fully connected layer;

[0033] Generate a corresponding risk matrix based on each of the risk scores and set a dynamic risk threshold;

[0034] Adding data bits corresponding to the risk matrix that are greater than the dynamic risk threshold into a risk queue;

[0035] Determining whether the number of data bits in the risk queue is less than a bit number threshold;

[0036] If so, randomly selecting data bits corresponding to the risk matrix that are not greater than the dynamic risk threshold and adding them to the risk queue until the number of data bits in the risk queue is not less than the bit number threshold;

[0037] If not, each data bit in the risk queue is sorted in descending order according to the corresponding risk score, and written into a target variation point queue; wherein the target variation point queue contains a plurality of target variation points.

[0038] On the other hand, generating a test message according to the target field and the target variation action includes:

[0039] combining the frame identifier, the data length code, and the CAN payload according to the target variation action to generate the test message;

[0040] Performing a cyclic redundancy check on the test message, and caching the test message that passes the check into a ring queue;

[0041] Correspondingly, inputting the test message into the target under test according to the scheduling algorithm based on the target variation point includes:

[0042] Determine the unmeasured number of each target variation point in the target variation point queue;

[0043] determining a test priority for each target variation point according to the number of untested times and the risk score of each target variation point;

[0044] The test messages are injected into the corresponding target variation points in descending order of the test priorities; when the CAN bus load is greater than a preset load threshold, or the response delay of the target under test is greater than a first preset time, the injection of the test message is paused for a second preset time, and random jitter is applied to the time difference.

[0045] On the other hand, obtaining monitoring data fed back by the measured target includes:

[0046] Acquiring frame-level data fed back by the measured target according to a first sampling frequency; wherein the frame-level data includes at least an error frame count, a confirmation error, and a format error;

[0047] Acquiring node-level data fed back by the measured target according to a second sampling frequency; wherein the node-level data at least includes an electronic control unit reset flag and a bus off count;

[0048] Obtaining bus-level data fed back by the measured target according to a third sampling frequency; wherein the bus-level data at least includes bus occupancy and number of arbitration failures;

[0049] Determine the abnormal CAN message frame that triggers the abnormality based on the frame-level data, the node-level data, and the bus-level data, and record the corresponding event payload; wherein the event payload includes a timestamp, a frame identifier, a bit mask, and an electronic control unit state;

[0050] The repeated abnormal CAN message frames are removed according to the corresponding event payload, and the abnormal CAN message frames are replayed in a CAN network development environment.

[0051] On the other hand, a comprehensive analysis of the monitoring data is performed, including:

[0052] Obtaining a frame identifier, a bit mask, an electronic control unit status, and an error type in the event payload of each of the abnormal CAN message frames;

[0053] Performing error mapping on the hardware error code of each abnormal CAN message frame; wherein the error type includes reset, bus off, confirmation error, format error and timeout;

[0054] Performing feature vector extraction based on a frame identifier, a bit mask, an electronic control unit state, and an error type in the event payload to generate a 32-dimensional feature vector;

[0055] Performing DBSCAN clustering on the 32-dimensional feature vector to output a clustering result; wherein the clustering result includes a cluster label, a unique omission list, and statistical data;

[0056] Deduplication of vulnerabilities is performed based on the payloads of each event and the clustering result, and a target event payload is determined;

[0057] Perform a CVSS risk rating on the target event payload and generate a corresponding vulnerability risk report; wherein the vulnerability risk report at least includes a vulnerability summary, a trigger sequence, a CVSS score, and a remediation suggestion.

[0058] On the other hand, vulnerability deduplication is performed based on each of the event payloads and the clustering result to determine the target event payload, including:

[0059] determining the event payloads having the same corresponding frame identifier, bit mask, and error type as the same vulnerability and merging them;

[0060] Recording only once the event payload having the same frame identifier and bit mask and being repeatedly triggered within a third preset time;

[0061] The event payloads having different corresponding frame identifiers and / or bit masks and the same corresponding clustering labels are determined to be the same vulnerability and merged.

[0062] On the other hand, it also includes:

[0063] Determine the effective trigger count, the total number of injected frames, the average round-trip delay and the bus occupancy rate according to the frame-level data, the node-level data and the bus-level data fed back by the measured target;

[0064] Determining a trigger rate according to the valid trigger count and the total number of injected frames;

[0065] adjusting a flip rate upper limit according to the bus occupancy rate, and determining a stress state of an electronic control unit according to the average round-trip delay;

[0066] Adjusting the flip rate and the time difference according to the trigger rate and the trigger rate threshold to obtain a new flip rate and a new time difference; wherein the flip rate and the time difference have corresponding upper and lower limits for adjustment respectively;

[0067] The new flip rate and the new time difference are written into the configuration area of ​​the policy network through the shared memory to update the mutation parameters.

[0068] On the other hand, it also includes:

[0069] Monitor the CAN bus communication process and identify abnormal events in the communication process based on statistical baseline algorithms, machine learning algorithms, and rule signature algorithms;

[0070] Performing event correlation analysis on each of the abnormal events according to a preset time window, merging repeated abnormal events and establishing a causal chain between the abnormal events to obtain the correlated abnormal events;

[0071] The corresponding operation alarm information is determined according to the event type of each of the associated abnormal events, and the corresponding operation alarm processing action is triggered.

[0072] On the other hand, it also includes:

[0073] Obtaining the vulnerability risk report, the operational warning information, and baseline data from the historical test warehouse;

[0074] Determine vulnerability severity distribution, exploitation difficulty coefficient, electronic control unit coverage, and time trend based on the vulnerability risk report, the operation alarm information, and the baseline data;

[0075] Normalizing the vulnerability severity distribution, the exploit difficulty coefficient, the electronic control unit coverage, and the time trend;

[0076] Determining a comprehensive risk score based on the normalized vulnerability severity distribution, the exploitation difficulty coefficient, the electronic control unit coverage, the time trend, and the corresponding weight vectors;

[0077] The risk level of this fuzzy test is determined based on the comprehensive risk score and level classification rules.

[0078] To solve the above technical problems, the present application also provides a CAN bus fuzzy testing device, comprising:

[0079] Extraction module, used to extract target fields from CAN bus log files;

[0080] A generation module, configured to generate a target variant action based on the target field, the policy network, and historical rewards; wherein the policy network is a neural network model pre-trained based on the historical field for generating corresponding variant actions; and the historical rewards are rewards corresponding to the variant actions generated by the policy network based on the historical field;

[0081] a determination module for determining a target variation point based on the target field and a variation point prediction model; wherein the variation point prediction model is a neural network model pre-trained based on historical fields for determining variation points in each data bit of a CAN message payload whose risk level meets preset requirements;

[0082] A testing module, configured to generate a test message according to the target field and the target mutation action, and input the test message into the target under test according to a scheduling algorithm based on the target mutation point to perform fuzz testing;

[0083] The analysis module is used to obtain the monitoring data fed back by the measured target and perform comprehensive analysis on the monitoring data.

[0084] To solve the above technical problems, the present application also provides a CAN bus fuzzy testing device, comprising:

[0085] memory for storing computer programs;

[0086] A processor is used to implement the steps of the above-mentioned CAN bus fuzzy testing method when executing the computer program.

[0087] In order to solve the above technical problems, the present application also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned CAN bus fuzzy testing method are implemented.

[0088] The CAN bus fuzz testing method provided in the present application extracts the target field in the CAN bus log file, generates the target mutation action according to the target field, policy network and historical rewards, realizes the dynamic adjustment of mutation parameters according to the real-time communication status and historical rewards, avoids the blind test limitations of fixed strategies, and significantly expands the vulnerability coverage; further determines the target mutation point according to the target field and mutation point prediction model, generates the test message according to the target field and target mutation action, and inputs the test message into the target under test according to the scheduling algorithm based on the target mutation point, which can focus on the area that is most likely to trigger anomalies and reduce invalid injection; at the same time, the monitoring data fed back by the target under test is continuously obtained during the test process, and the monitoring data is comprehensively analyzed without manual intervention, with stronger adaptability and testing efficiency.

[0089] In addition, the present application also provides a CAN bus fuzzy testing device, equipment and medium, with the same effect as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0090] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0091] Figure 1 A flowchart of a CAN bus fuzzy testing method provided in an embodiment of the present application;

[0092] Figure 2 A schematic diagram of a CAN bus fuzzy testing device provided in an embodiment of the present application;

[0093] Figure 3 A schematic diagram of a CAN bus fuzzy testing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0094] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0095] The core of this application is to provide a CAN bus fuzzy testing method, device, equipment and medium to solve the problem that the current CAN bus fuzzy testing method lacks adaptive capabilities and requires a lot of manual intervention.

[0096] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0097] With the development of automotive electronics and industrial automation technology, the CAN bus has been widely used in vehicles and industrial control systems due to its efficient communication capabilities, but its openness brings security risks. Existing CAN bus fuzz testing methods mainly rely on fixed mutation strategies and cannot dynamically adapt to different communication environments and attack modes, resulting in low test coverage and efficiency. Common methods such as random mutation and rule-based mutation strategies can discover some vulnerabilities, but lack adaptive capabilities and are difficult to cope with diverse attack scenarios. In addition, these tools often require a lot of manual operation and configuration, which increases the difficulty and cost of testing. Therefore, in order to solve the above problems, this application provides a CAN bus fuzz testing method.

[0098] Figure 1 This is a flow chart of a CAN bus fuzzy testing method provided in an embodiment of the present application. Figure 1 As shown, the method includes:

[0099] S10: Extract the target field in the CAN bus log file.

[0100] To implement CAN bus fuzz testing, the hardware architecture must first be established. For example, the Vector VN1630A can be used as an interface device to stably inject ≥10kfps at 1Mbit / s. Furthermore, 2.5kV optical isolation is implemented to prevent the test frames from affecting other vehicle nodes. Finally, the target (ECU) under test is mounted on a hardware-in-the-loop test bench, facilitating replication and protecting real vehicle safety.

[0101] During the test, the target field in the CAN bus log file is extracted and used as the basic data for generating mutation actions and mutation points. It should be noted that the specific method for extracting the target field in the CAN bus log file is not limited in this embodiment and depends on the specific implementation situation.

[0102] S11: Generate target mutation actions based on target field, policy network and historical rewards.

[0103] Among them, the policy network is a neural network model pre-trained according to the historical field for generating corresponding mutation actions; the historical reward is the reward corresponding to the mutation action generated by the policy network based on the historical field.

[0104] Furthermore, based on the extracted target field, the policy network and historical rewards are used to generate target mutation actions.

[0105] It should be noted that the policy network is a neural network model that is pre-trained based on historical fields and is used to generate corresponding variant actions. Among them, the historical field is the historical target field extracted from the historical CAN bus log file, and the historical reward is the reward corresponding to the variant action generated by the policy network based on the historical field. It is understandable that the policy network has a corresponding reward function, and the reward function contains multiple different trigger events, each trigger event corresponding to a different reward value. In this embodiment, there is no restriction on the specific process of generating target variant actions based on the target field, policy network and historical rewards. In this embodiment, the policy network is used to analyze historical test data and dynamically adjust the mutation strategy.

[0106] S12: Determine the target mutation point based on the target field and the mutation point prediction model.

[0107] Among them, the variation point prediction model is a neural network model that is pre-trained based on historical fields and is used to determine the variation points in each data bit of the CAN message payload whose risk level meets the preset requirements.

[0108] Subsequently, the target mutation point is determined based on the target field and the mutation point prediction model. It should be noted that the mutation point prediction model is a neural network model pre-trained based on historical fields to determine the mutation point in each data bit of the CAN message payload whose risk level meets the preset requirements.

[0109] It should be noted that the CAN message payload is Data[0-7], specifically the 8 data bytes (Data Byte 0 to Data Byte 7) in each CAN message frame.

[0110] The risk level of each data bit in the CAN message payload refers to the corresponding risk confidence level, which ranges from 0 to 1: when it is close to 1, the model determines that the bit is likely to trigger an anomaly after being flipped; when it is close to 0, the model believes that flipping it will basically have no effect. In this embodiment, there is no restriction on the preset requirements that the risk level must meet. For example, it can be specifically that the risk level is greater than a fixed threshold, or it can be that the risk level is greater than a dynamic threshold, depending on the specific implementation situation. At the same time, in this embodiment, there is no restriction on the specific process of determining the target variation point based on the target field and variation point prediction model. In this embodiment, the target field is extracted from the CAN communication data through a deep learning algorithm to identify high-risk areas.

[0111] S13: Generate a test message according to the target field and the target mutation action, and input the test message into the target under test according to a scheduling algorithm based on the target mutation point to perform fuzz testing.

[0112] After determining the target mutation action and target mutation point, a test message is first generated based on the target field and target mutation action. It should be noted that this embodiment does not restrict the specific process of generating the test message. Subsequently, using a scheduling algorithm based on the target mutation point, the test message is injected into the scheduler and a throttling policy is set to perform fuzz testing. This embodiment also does not restrict the specific process of executing the fuzz test.

[0113] S14: Obtain monitoring data fed back by the measured target and perform comprehensive analysis on the monitoring data.

[0114] Finally, during the test, monitoring data provided by the target is continuously monitored and acquired, and comprehensive analysis is performed on the data. This monitoring data may include, but is not limited to, frame-level, node-level, and bus-level data; Furthermore, the analysis of this monitoring data may include, but is not limited to, vulnerability identification and risk rating. The specific acquisition and analysis process for monitoring data is not restricted in this embodiment and will be determined based on specific implementation circumstances.

[0115] In this embodiment, by extracting the target field in the CAN bus log file, generating the target mutation action according to the target field, policy network and historical rewards, the mutation parameters are dynamically adjusted according to the real-time communication status and historical rewards, avoiding the blind test limitations of fixed strategies, and significantly expanding the vulnerability coverage; further, the target mutation point is determined according to the target field and mutation point prediction model, and the test message is generated according to the target field and target mutation action. The test message is input into the target under test according to the scheduling algorithm based on the target mutation point, which can focus on the area that is most likely to trigger anomalies and reduce invalid injections; at the same time, the monitoring data fed back by the target under test is continuously obtained during the test process, and the monitoring data is comprehensively analyzed without manual intervention, with stronger adaptability and testing efficiency.

[0116] It should also be noted that the policy network and mutation point prediction model provided in this application are trained using historical training data, which can improve the accuracy of the mutation strategy. Specifically, in order to train the neural network module, data preparation and labeling are first required. Specifically, CAN bus logs and real vehicle-mounted collection data are obtained, with a scale of 200GB. The collected data is deduplicated, sorted by FrameID, and missing bits are filled. After completing the data cleaning, the label definition is performed, and the risk bit corresponding to the mutation point prediction model is specifically set: the high-risk bit (label1) is the bit that has triggered an anomaly; the normal bit (label0) is the bit that has never triggered an anomaly; the reward r_t corresponding to the policy network is set as the offline Q learning target.

[0117] Furthermore, data augmentation and segmentation were performed. Specifically, random bit flipping was performed by 5% to improve the robustness of the neural network; timing jitter was set to ±2% to simulate different bus clock offsets; and cross-ECU merging was implemented to increase interoperability across multiple devices. It should be noted that the data was segmented into 70% training data, 15% validation data, and 15% test data, with data segmentation based on chronological order to prevent data leakage. Further neural network model training was then performed.

[0118] The mutation prediction model was trained using PyTorch 2.1, with hyperparameters of batch size 512, learning rate 1e-3, and optimizer Adam. The weighting of positive and negative samples was 1:5. Results included a test set AUC of 0.92 and an F value of 10.78. Offline training of the policy network used the DQN + Prioritized Replay algorithm. The state space consisted of a 128-dimensional feature vector F_hist combined with the previous action feedback, for a total dimension of 132. The action space consisted of 1k top-risk positions and random exploration positions. Training was repeated until convergence. Training was terminated when the average estimated Q-value improved by 18% and the offline policy coverage increased by 22%. Finally, model version management and deployment use MLflow Tracking + Artifacts as the version library. Each submission is replayed through unit-test replay 5000 historical frames to achieve compatibility verification. The latest stable tag is automatically pushed to the test platform through the continuous integration / continuous deployment (CI / CD) pipeline, thus completing the training and deployment of the mutation point prediction model and policy network.

[0119] Based on the above embodiment, in some embodiments, extracting the target field in the CAN bus log file includes:

[0120] S101: collecting binary log files or text log files output by a network bus development tool to obtain a CAN bus log file;

[0121] S102: extracting the frame identifier, data length code, CAN payload, timestamp and error flag of each CAN message frame in the CAN bus log file to extract the initial field;

[0122] S103: Perform data cleaning on each initial field to obtain a target field.

[0123] In order to extract the target field, in this embodiment, the binary (.blf) log file or text (.asc) log file output by the network bus development tool (CANoe) is collected to obtain the CAN bus log file. The frame identifier (FrameID), data length code (Data Length Code, DLC), CAN payload Data [0 7], timestamp T and error flag of each CAN message frame in the CAN bus log file are further extracted to extract the initial field.

[0124] Subsequently, data cleaning is performed on each initial field to obtain the target field. Specifically, data cleaning is performed on each initial field, including:

[0125] S104: Remove non-CAN message frames and invalid repeated CAN message frames from each error identifier.

[0126] S105: Convert each frame identifier into a hexadecimal representation.

[0127] S106: Calculate the time difference between adjacent frames according to the timestamps, and cache the target fields obtained after data cleaning.

[0128] To perform data cleansing, first remove non-CAN message frames from each error identifier, specifically non-ISO11898-1 frames, and also remove invalid duplicate CAN message frames. Next, convert each FrameID to hexadecimal representation. Based on each timestamp T, calculate the time difference Δt between adjacent frames. This is calculated by subtracting the previous frame's timestamp from the next frame's timestamp to obtain the transmission interval. This method then generates the target fields. Finally, cache the cleaned target fields, for example, in SQLite for fast indexing.

[0129] In this embodiment, the target field is extracted as the basic data for generating mutation actions and mutation points, so as to facilitate the subsequent execution of fuzz testing.

[0130] Based on the above embodiments, in some embodiments, generating a target mutation action based on the target field, the policy network, and the historical rewards includes:

[0131] S111: Calculate the byte entropy and 0 / 1 ratio of the CAN payload of each CAN message frame.

[0132] S112: Counting the average time interval, time interval standard deviation, and burst length of the same frame identifier.

[0133] S113: Determine the number of triggering rules for the preceding identifier to trigger the following identifier according to a priori algorithms.

[0134] S114: The byte entropy, 0 / 1 ratio, average time interval, time interval standard deviation, burst length, and number of triggering rules are normalized and concatenated in a fixed order to generate a 128-dimensional feature vector.

[0135] S115: Input the 128-dimensional feature vector and the most recent historical reward to the current moment into the policy network to generate the target mutation action.

[0136] The target mutation action includes the target frame identifier, byte index, bit mask and flip rate; the policy network consists of two fully connected layers, ReLU activation function and Softmax output layer.

[0137] S116: After the test message is input to the target under test, a target triggering event fed back by the target under test is obtained.

[0138] S117: Determine a target reward value corresponding to the target trigger event according to the reward values ​​corresponding to each trigger event of the reward function.

[0139] The triggering events of the reward function include at least electronic control unit reset, bus shutdown, frame error, delay greater than a threshold without abnormality, and normal frame.

[0140] S118: Fine-tune the policy network based on the target reward value and the policy gradient algorithm.

[0141] To generate the target mutation action, this embodiment specifically calculates the byte entropy and 0 / 1 ratio of the CAN payload of each CAN message frame to identify high-entropy anomalous bytes. The average time interval Δt-mean, time interval standard deviation Δt-std, and burst length BurstLength for the same FrameID are calculated to capture periodic mutations and burst traffic. Subsequently, an apriori algorithm is used to determine the number of triggering rules for a leading identifier (ID) to trigger a trailing identifier, thereby identifying cross-frame dependencies.

[0142] Furthermore, the byte entropy, 0 / 1 ratio, average time interval Δt-mean, time interval standard deviation Δt-std, burst length BurstLength, and number of triggering rules are normalized (e.g., using Min-Max or Z-Score processing) and concatenated in a fixed order to generate a 128-dimensional feature vector F_hist. It should be noted that the 128-dimensional vector F_hist is a comprehensive feature representation of the "recent communication history" of each FrameID. It compresses key information about the same frame in three dimensions: content, temporal behavior, and cross-frame relationships, into a fixed length of 128 dimensions, making it easier for deep networks to process and maintaining semantic integrity.

[0143] The 128-dimensional feature vector and the most recent historical reward r_{t1} are then input into the policy network to generate a target mutation action. It's important to note that the target mutation action a_t is a specific instruction given by the reinforcement learning policy network at a specific moment regarding how to mutate the next frame. It drives the fuzz injector to send anomaly frames to the CAN bus to verify whether the system has triggered an anomaly. The target mutation action consists of the target frame identifier FrameID, the byte index ByteIdx, the bit mask BitMask, and the flip rate FlipRate. The target frame identifier FrameID is the ID of the target message and determines the ECU to be injected. ByteIdx is a byte index between 0 and 7 that specifies which byte in the 8-byte data area to mutate. BitMask is an 8-bit mask, such as 0x40, indicating the specific bit to flip (flipping 1 and maintaining 0). FlipRate is the bit flip probability or injection frequency, which controls the intensity of the mutation to avoid blocking the CAN bus by injecting too many bits at once.

[0144] It should also be noted that in this embodiment, the policy network consists of two fully connected layers. The first layer has an input dimension of 128 and an output dimension of 256; the second layer has an input dimension of 256 and an output dimension of 128, and is composed of a ReLU activation function and a Softmax output layer.

[0145] Furthermore, after inputting the test message into the target under test, the target trigger event feedback from the target under test is obtained. The target reward value corresponding to the target trigger event is determined based on the reward values ​​corresponding to each trigger event in the reward function. It should be noted that the reward r_t is used to measure the effectiveness of the system after executing a_t, thereby driving the learning of the policy network. The trigger events of the reward function include at least an electronic control unit reset (ECUReset), bus off (Busoff), frame error (FrameError), delay greater than a threshold with no anomalies, and normal frame; the corresponding reward values ​​r_t are: +5 for ECUReset, +3 for Busoff, +1 for FrameError, −0.5 for delay greater than a threshold with no anomalies, and −0.1 for normal frame.

[0146] At the end of this example, the policy network is fine-tuned based on the target reward value and the policy gradient algorithm. The reward function uses a sliding average as the baseline b, and the gradient update formula is: θ + α ∇θ log π (a_t) (r_t − b). Specifically, the sliding average baseline b serves as a smoothing reference for the reward r_t, reducing the gradient variance caused by high reward volatility. Specifically, the exponentially weighted average of the rewards for the last N steps is calculated as b_t = β·b_{t-1} + (1-β)·r_t. This has the advantage that when r_t and b_t are close, (r_t - b_t) ≈ 0, and the update amplitude is automatically reduced, making training more stable. Here, θ represents the policy network parameters, α is the learning rate, logπ(a_t) is the logarithmic probability of executing action a_t, ∇θlogπ(a_t) is the policy gradient, which tells the parameters to adjust in a direction that increases the probability of this action, and (r_t - b) is the "centralized reward" after removing the baseline, that is, the actual gain or loss. The baseline b is used to balance rewards and punishments, and the gradient term makes the policy network more inclined to repeat the variant actions with "higher than average rewards" and stay away from the actions with "lower than average rewards" to achieve adaptive optimization.

[0147] Based on the above embodiments, in some embodiments, determining a target variation point according to a target field and a variation point prediction model includes:

[0148] S121: Expand a first preset number of CAN message frames closest to the current moment into a two-dimensional matrix in ascending order of corresponding frame identifiers.

[0149] S122: normalizing each data bit in each two-dimensional matrix according to the corresponding real level, and filling the missing mark between frames to pre-process each two-dimensional matrix.

[0150] S123: Outputting each pre-processed two-dimensional matrix to the variation point prediction model to output the risk score of each data bit corresponding to the CAN message frame payload.

[0151] Among them, the mutation point prediction model consists of the first convolutional layer, the second convolutional layer, the global average pooling layer and the fully connected layer.

[0152] S124: Generate a corresponding risk matrix based on each risk score and set a dynamic risk threshold.

[0153] S125: Add the data bits whose corresponding risk matrix is ​​greater than the dynamic risk threshold into the risk queue.

[0154] S126: Determine whether the number of data bits in the risk queue is less than the bit number threshold; if so, proceed to step S127; if not, proceed to step S128.

[0155] S127: Randomly select data bits corresponding to the risk matrix that are not greater than the dynamic risk threshold and add them to the risk queue until the number of data bits in the risk queue is not less than the bit number threshold.

[0156] S128: Sort the data bits in the risk queue in descending order according to the corresponding risk scores, and write them into the target mutation point queue.

[0157] The target mutation point queue includes multiple target mutation points.

[0158] To identify target mutation points, this embodiment first expands a first preset number N of CAN message frames closest to the current moment into a two-dimensional matrix N × 8 (bytes) × 8 (bits) in ascending order of their corresponding frame identifiers, FrameID. This first preset number is not restricted in this embodiment. Subsequently, each data bit in each two-dimensional matrix is ​​normalized to its corresponding real-world level, mapping the bit values ​​to {0, 1}. Missing frames are then padded between frames to mark missing frames. Specifically, when the cache contains fewer than N frames, empty rows are filled with all 1s or -1s. This allows the model to distinguish between real and missing frames, thereby pre-processing each two-dimensional matrix. Furthermore, 256 copies of the N × 8 × 8 two-dimensional matrix can be packed together and fed into the GPU for parallel inference. For example, if N = 64, the GPU actually processes a tensor of size 256 × 64 × 8 × 8. Due to graphics card memory limitations, large batch sizes can improve convolution kernel reuse. For example, in FP32, 256 × 64 × 8 × 8 is approximately 1MB, which is suitable for graphics cards with 8GB of memory.

[0159] Furthermore, each preprocessed two-dimensional matrix is ​​output to the mutation point prediction model to output the risk score for each data bit in the CAN message frame payload. It is important to note that the structure of the mutation point prediction model includes a first convolutional layer (3×3 convolution kernel, 32 channels, output dimension N×32), which is used to extract local patterns, a second convolutional layer (3×3 convolution kernel, 64 channels, output dimension N×64), which is used to deepen the feature hierarchy, a global average pooling layer (GAP), with an output dimension of 64, which is used for dimensionality reduction and anti-overfitting, and finally a fully connected layer (FC), which is used to reduce the dimension from 64 to 1, contains a sigmoid activation function, and has an output dimension of 1, which is used to output the risk probability, that is, the risk score for each data bit in the CAN message frame payload.

[0160] In addition, the loss function of the mutation point prediction model is weighted BCE, and the positive sample ratio is 1:10. Its training data consists of a historical vulnerability trigger point annotation set and normal communication bits. Among them, the historical vulnerability trigger point annotation set is a specific set of bits that have actually triggered anomalies (ECUReset, Bus-off, FrameError, etc.) in previous fuzz testing or penetration testing.<FrameID,ByteIdx,BitPos> The combination is labeled as a positive sample (label 1). Normal communication bits are bits that have never triggered any anomalies during long-term bench sampling and are considered negative samples (label 0). Both types of training data are derived from a standard frame set after data cleaning.

[0161] Subsequently, a corresponding risk matrix R(i, j) is generated based on each risk score p output by the mutation point prediction model. This represents the confidence level of high risk output for each specific data bit in the matrix (the jth bit of FrameID-i), with values ​​ranging from 0 to 1. A dynamic risk threshold is also set: θ = median(R) + 0.2·std(R). Here, median(R) is the median of all p-values ​​in the risk matrix, representing the "typical risk level of half the bit." Std(R) is the standard deviation of the same batch of p-values, measuring the dispersion of the distribution. 0.2·std(R) adds 0.2 standard deviations to the median, roughly equivalent to setting the threshold at the 58th percentile of the distribution (slightly above average risk). Risk distributions may be narrow or dispersed for different ECUs in different scenarios, making a fixed threshold prone to inefficiency. Using median + 0.2·std automatically adjusts the threshold based on real-time distribution, ensuring that neither too many nor too few "high-risk bits" are screened out. On this basis, set the cache rules of the risk matrix and set the sliding window update to keep the latest data within 1 second.

[0162] Furthermore, the data bits whose corresponding risk matrix is ​​greater than the dynamic risk threshold, that is, R>θ, are added to the risk queue Q_high. It is determined whether the number of data bits in the risk queue Q_high is less than the bit number threshold. In this embodiment, there is no restriction on the size of the bit number threshold, for example, it can be 16. If it is confirmed that the number of data bits in the risk queue Q_high is less than the bit number threshold, then the data bits whose corresponding risk matrix is ​​not greater than the dynamic risk threshold are randomly selected and added to the risk queue until the number of data bits in the risk queue is not less than the bit number threshold. If it is confirmed that the number of data bits in the risk queue Q_high is not less than the bit number threshold, then each data bit in the risk queue Q_high is sorted in descending order according to the corresponding risk score p, and written into the target variation point queue. It can be understood that the target variation point queue contains multiple target variation points, so that test messages can be injected into each variation point during testing. On this basis, the aging rule of the risk queue Q_high can also be set: the tested bits are not added repeatedly within 2s to avoid wasteful injection.

[0163] In this embodiment, a convolutional neural network is used to perform risk scoring on the frame-bit matrix, and high-scoring bytes and bits are preferentially selected for mutation, focusing on areas that are most likely to trigger anomalies, thereby reducing invalid injections.

[0164] Based on the above embodiment, in some embodiments, generating a test message according to a target field and a target variation action includes:

[0165] S131: Combining a frame identifier, a data length code, and a CAN payload according to a target variation action to generate a test message.

[0166] S132: Perform a cyclic redundancy check on the test message, and cache the test message that passes the check in a ring queue.

[0167] To generate a test message, this embodiment combines the frame identifier FrameID, the data length code DLC, and the CAN payload Data[0-7] bit flip result based on the target mutation action a_t. A cyclic redundancy check is then performed on the test message, and any test messages that pass the check are cached in a circular queue. The circular queue caches 1024 frames, ensuring zero latency during high-frequency injection.

[0168] Correspondingly, the test message is input into the target under test according to the scheduling algorithm based on the target variation point, including:

[0169] S133: Determine the unmeasured times of each target variation point in the target variation point queue.

[0170] S134: Determine the test priority of each target variation point according to the number of untested times and the risk score of each target variation point.

[0171] S135: Inject test messages into corresponding target mutation points in descending order of test priority.

[0172] When the CAN bus load is greater than a preset load threshold, or the response delay of the target under test is greater than a first preset time, the injection of the test message is suspended for a second preset time, and random jitter is applied to the time difference.

[0173] During the message injection process, the number of untested instances of each target variation point in the target variation point queue is determined. The test priority of each target variation point is determined based on the number of untested instances and its risk score. Specifically, the test priority is calculated as follows: test priority = risk score × number of untested instances, with the top value taken from the MaxHeap. Test messages are injected into the corresponding target variation points in descending order of test priority. In other words, among the target variation points to be tested, the bits that are most likely to trigger vulnerabilities and have not yet been fully tested are prioritized for message injection. Furthermore, throttling strategies and timing perturbations must be considered during the injection process. Specifically, when the CAN bus load exceeds a preset load threshold, such as 80%, or the response delay of the target under test exceeds a first preset time (e.g., 20ms), test message injection is paused for a second preset time (e.g., 5ms), and random jitter, such as ±10%, is applied to the time difference ΔT to simulate a real-world jitter scenario.

[0174] In this way, injection scheduling and throttling of test messages are realized.

[0175] Based on the above embodiment, in some embodiments, obtaining monitoring data fed back by the measured target includes:

[0176] S141: Acquire frame-level data fed back by the measured target according to a first sampling frequency.

[0177] The frame-level data includes at least error frame count, confirmation error and format error.

[0178] S142: Acquire node-level data fed back by the measured target according to the second sampling frequency.

[0179] The node-level data at least includes an electronic control unit reset flag and a bus off count.

[0180] S143: Obtain bus-level data fed back by the measured target according to the third sampling frequency.

[0181] The bus-level data at least includes bus occupancy and the number of arbitration failures.

[0182] S144: Determine the abnormal CAN message frame that triggers the abnormality based on the frame-level data, the node-level data, and the bus-level data, and record the corresponding event payload.

[0183] The event payload includes a timestamp, a frame identifier, a bit mask, and the ECU status.

[0184] S145: removing duplicate abnormal CAN message frames according to corresponding event payloads, and replaying the abnormal CAN message frames in the CAN network development environment.

[0185] Specifically, during the test, the monitoring data fed back by the target under test is continuously monitored. Specifically, the frame-level data fed back by the target under test is obtained based on a first sampling frequency (e.g., 1kHz), including at least the error frame count ErrorFrameCnt, the confirmation error AckErr, and the format error FormErr. The node-level data fed back by the target under test is obtained based on a second sampling frequency (e.g., 100Hz), including at least the electronic control unit reset (ECU Reset) flag and the bus off (Bus off) count. The bus-level data fed back by the target under test is obtained based on a third sampling frequency (e.g., 100Hz), including at least the bus occupancy rate and the number of arbitration failures. It should be noted that the above monitoring data is transmitted back to the host computer via the CAN FD channel with a delay of ≤2ms.

[0186] Next, the abnormal CAN message frame that triggered the anomaly is identified based on the frame-level, node-level, and bus-level data, and the corresponding Event Payload is recorded. The Event Payload includes a timestamp, frame identifier (FrameID), bit mask (BitMask), and ECU status. Finally, duplicate abnormal CAN message frames are removed based on the corresponding Event Payload and replayed in the CAN network development environment to reproduce the anomaly. Furthermore, hashing can be performed based on the FrameID + BitMask to avoid duplicate vulnerability statistics.

[0187] In summary, accurate monitoring of test results is achieved, which facilitates more accurate subsequent comprehensive data analysis.

[0188] Based on the above embodiments, in some embodiments, comprehensive analysis of monitoring data includes:

[0189] S151: Obtain the frame identifier, bit mask, electronic control unit status and error type in the event payload of each abnormal CAN message frame.

[0190] S152: Perform error mapping on the hardware error code of each abnormal CAN message frame.

[0191] Error types include reset, bus off, acknowledge error, format error, and timeout.

[0192] S153: Perform feature vector extraction based on the frame identifier, bit mask, electronic control unit status, and error type in the event payload to generate a 32-dimensional feature vector.

[0193] S154: Perform DBSCAN clustering processing on the 32-dimensional feature vector to output a clustering result.

[0194] The clustering results include cluster labels, unique omission lists, and statistics.

[0195] S155: De-duplication of vulnerabilities is performed based on the payloads of each event and the clustering results, and the target event payload is determined.

[0196] S156: Perform CVSS risk rating on the target event payload and generate a corresponding vulnerability risk report.

[0197] Among them, the vulnerability risk report includes at least vulnerability summary, trigger sequence, CVSS score and repair suggestions.

[0198] In order to achieve comprehensive analysis of monitoring data, in this embodiment, it is first necessary to obtain the frame identifier FrameID, bit mask BitMask, ECU status, and corresponding error type ErrorType in the event payload Event Payload of each abnormal CAN message frame. Subsequently, error mapping is performed on the hardware error code of each abnormal CAN message frame, and a total of five types of exceptions are mapped: Reset, Bus off, confirmation error AckErr, format error FormErr, and timeout Timeout. It can be understood that the hardware error code is obtained from the CAN interface and driver layer, and can be monitored and obtained using CANoe. There will also be fields in the .blf / .asc file, and it can also be obtained in real time through the CANoe API function.

[0199] Further anomaly clustering is performed. Specifically, feature vectors are extracted based on the frame identifier FrameID, bit mask BitMask, ECU status, and error type ErrorType in the event payload Event Payload to generate a 32-dimensional feature vector. The 32-dimensional feature vector is then subjected to DBSCAN clustering processing (neighborhood radius ε=0.5, minimum number of points minPts=3) to output the clustering results, thereby discovering areas with dense abnormal patterns. It should be noted that the clustering results include cluster labels, unique omission lists, and statistical data. Among them, the cluster label is the cluster ID of each event, indicating which type of vulnerability pattern it belongs to. The unique vulnerability list retains the first representative event for each cluster, and the remaining events in the same cluster are counted in the trigger count but are no longer listed separately. The statistical data is the number of triggers for each cluster and the set of FrameIDs covered, which are used for subsequent CVSS scoring and report presentation.

[0200] Subsequently, vulnerability deduplication is performed based on the payload of each event and the clustering results to determine the target event payload. In this embodiment, there is no restriction on the specific rules for vulnerability deduplication, which depends on the specific implementation situation. Finally, the target event payload is rated for CVSS risk and a corresponding vulnerability risk report is generated. Among them, the vulnerability risk report includes at least a vulnerability summary, a trigger sequence, a CVSS score, and a repair suggestion. It can be understood that CVSS is an open framework and industry standard for evaluating and measuring the severity of software vulnerabilities.

[0201] In summary, after the test is completed, the monitoring data is comprehensively analyzed and a report containing CVSS indicators, vulnerability classification and repair suggestions is automatically generated, providing users with a quantitative basis for subsequent adjustments and maintenance.

[0202] Based on the above embodiments, in some embodiments, vulnerability deduplication is performed based on each event payload and clustering results to determine the target event payload, including:

[0203] S157: Event payloads with the same corresponding frame identifier, bit mask, and error type are determined to be the same vulnerability and merged.

[0204] S158: The event payload having the same corresponding frame identifier and bit mask and being repeatedly triggered within the third preset time is recorded only once.

[0205] S159: Event payloads with different corresponding frame identifiers and / or bit masks and the same corresponding clustering labels are determined to be the same vulnerability and merged.

[0206] In a specific implementation, the vulnerability removal rules specifically include: determining each event payload with the same corresponding frame identifier FrameID, bit mask BitMask, and error type ErrType as the same vulnerability and merging them. The event payload with the same corresponding frame identifier FrameID and bit mask BitMask and repeatedly triggered within a third preset time (for example, 10s) is recorded only once. Finally, the event payload with different corresponding frame identifiers FrameID and / or bit masks BitMask and the same corresponding clustering labels is determined to be the same vulnerability and merged. In this way, vulnerability deduplication is achieved.

[0207] In order to improve the accuracy of variant action generation, it is also necessary to dynamically adjust the variation parameters of the policy network based on real-time test feedback. Specifically, based on the above embodiment, in some embodiments, the method further includes:

[0208] S161: Determine the effective trigger count, the total number of injected frames, the average round-trip delay, and the bus occupancy rate based on the frame-level data, node-level data, and bus-level data fed back by the measured target.

[0209] S162: Determine a trigger rate according to the valid trigger count and the total number of injected frames.

[0210] S163: Adjust the upper limit of the flip rate according to the bus occupancy rate, and determine the pressure state of the electronic control unit according to the average round-trip delay.

[0211] S164: Adjust the toggle rate and the time difference according to the trigger rate and the trigger rate threshold to obtain a new toggle rate and a new time difference.

[0212] Among them, the flip rate and time difference have corresponding upper and lower limits of adjustment respectively.

[0213] S165: Write the new flip rate and the new time difference into the configuration area of ​​the policy network through the shared memory to update the mutation parameters.

[0214] Specifically, based on the frame-level, node-level, and bus-level data fed back by the target under test, the valid trigger count N_v, the total number of injected frames N_inj, the average round-trip delay Avg_RTT, and the bus occupancy Bus_Load are determined. It can be understood that the valid trigger count N_v represents the number of ECUReset / Busoff frames; the total number of injected frames N_inj represents the number of injected frames per unit time; the average round-trip delay Avg_RTT represents the average ECU response delay; and the bus occupancy Bus_Load represents the real-time bus occupancy.

[0215] Subsequently, the trigger rate p_vul is determined based on the valid trigger count N_v and the total number of injected frames N_inj: p_vul = N_v / N_inj, with a sliding window of 1 second. The upper limit of the flip rate is adjusted based on the bus occupancy. For example, when Bus_Load > 85%, the upper limit of the flip rate FlipRate is forced to be lowered. The ECU stress state is also determined based on the average round-trip delay Avg_RTT. For example, when Avg_RTT > 25ms, the ECU is considered to be in a state of increasing stress.

[0216] Further parameter adjustment is carried out, specifically adjusting the flip rate FlipRate and the time difference ΔT according to the trigger rate p_vul and the trigger rate threshold, so as to obtain a new flip rate and a new time difference. For example, when p_vul≥0.03, the flip rate FlipRate×0.8, and the time difference ΔT−5%; when 0.01<p_vul<0.03, the flip rate FlipRate remains unchanged, and the time difference ΔT remains unchanged; when p_vul≤0.01, the flip rate FlipRate×1.2 (upper limit 0.5), and the time difference ΔT+5%. It can be understood that there are corresponding upper and lower limits for adjusting the flip rate FlipRate and the time difference ΔT, and boundary protection can be imposed on both: the range of the flip rate FlipRate is [0.01,0.5], and the jitter range of ΔT is [−20%,+20%].

[0217] Finally, write the new flip rate FlipRate and the new time difference ΔT into the configuration area of the policy network through shared memory to update the mutation parameters, and the subsequent injection scheduler reads the new parameters and applies them within 10 ms. If the trigger rate p_vul is still abnormal within 3 s after the parameters take effect, enter the protection mode (pause injection for 50 ms).

[0218] In order to monitor CAN bus communication in real-time and detect anomalies, based on the above embodiments, in some embodiments, the method further includes:

[0219] S171: Monitor the communication process of the CAN bus, and identify abnormal events in the communication process according to the statistical baseline algorithm, machine learning algorithm, and rule signature algorithm.

[0220] S172: Perform event correlation analysis on each abnormal event according to a preset time window, merge duplicate abnormal events above, and establish a causal chain between each abnormal event to obtain each associated abnormal event.

[0221] S173: Determine the corresponding running alarm information according to the event type of each associated abnormal event, and trigger the corresponding running alarm handling action. [[ID=1​​​During the monitoring process, anomalies in communication are identified using statistical baseline algorithms, machine learning algorithms, and rule-based signature algorithms. The statistical baseline algorithm uses EWMA to monitor frame rate and error frames, with a trigger condition of deviation > 3σ, where σ is the standard deviation. The machine learning algorithm uses an LSTM autoencoder to reconstruct the error, with a trigger condition of mean square error > 0.15. The rule-based signature algorithm matches known attack sequences, with a trigger condition of hitting a blacklisted ID sequence. These three detection methods operate in parallel, and any triggering of any of these conditions generates an anomaly event.

[0224] Subsequently, event correlation analysis is performed on each abnormal event within a preset time window (e.g., 1 second). Repeated abnormal events are merged and a causal chain is established between them to obtain the associated abnormal events. For example, if the same FrameID is abnormal multiple times within a window, they are merged into a single event and a causal chain is established based on the ECU_ID to identify broadcast attacks.

[0225] Finally, the corresponding operational alarm information is determined based on the event type of each associated abnormal event, and the corresponding operational alarm processing action is triggered. For example, three different alarm levels are set: high risk, medium risk, and low risk. The high risk trigger condition is ECU reset / bus-off, and the corresponding action is to issue a gateway drop rule to disconnect the abnormal ID communication; the medium risk trigger condition is five consecutive frame errors, and the corresponding action is to send an email and webhook push; the low risk trigger condition is a single format error, and the corresponding action is to only write to Elasticsearch for subsequent analysis. This achieves real-time monitoring and anomaly detection of CAN bus communication.

[0226] In order to comprehensively analyze the test data and evaluate the system security, based on the above embodiments, in some embodiments, the method further includes:

[0227] S181: Obtain vulnerability risk reports, operational alert information, and baseline data from the historical test repository.

[0228] S182: Determine vulnerability severity distribution, exploit difficulty coefficient, electronic control unit coverage, and time trend based on vulnerability risk reports, operational alarm information, and baseline data.

[0229] S183: Normalize vulnerability severity distribution, exploit difficulty coefficient, electronic control unit coverage, and time trend.

[0230] S184: Determine a comprehensive risk score based on the normalized vulnerability severity distribution, exploit difficulty coefficient, electronic control unit coverage, time trend, and their corresponding weight vectors.

[0231] S185: Determine the risk level of this fuzzy test based on the comprehensive risk score and level classification rules.

[0232] Specifically, we first obtain the baseline data for vulnerability risk reports, operational alerts, and the historical test repository. Key fields in vulnerability risk reports include CVE_ID, CVSS score, and trigger sequence. Key fields in operational alerts include timestamp T, error type ErrType, and ECU ID. Key fields in baseline data include the previous RiskIndex and vulnerability trend.

[0233] Furthermore, vulnerability severity distribution, exploit difficulty, ECU coverage, and time trend are determined based on vulnerability risk reports, operational alerts, and baseline data. It should be noted that vulnerability severity distribution has three levels: high (>7), medium (4-7), and low (<4), and the percentage is calculated based on the CVSS classification. The exploit difficulty is calculated using the message sequence length L, where Difficulty = log2(L+1). ECU coverage is specifically the ratio of the number of tested ECUs to the total number of ECUs. Time trend, or ΔRisk per Day, is calculated by taking the difference between the two most recent RiskIndex values.

[0234] Subsequently, the vulnerability severity distribution, exploit difficulty coefficient, electronic control unit coverage, and time trend are normalized, and each indicator is scaled to 0-1. Finally, the comprehensive risk score is determined based on the normalized vulnerability severity distribution, exploit difficulty coefficient, electronic control unit coverage, time trend, and their corresponding weight vectors. The formula is as follows:

[0235] RiskIndex=ΣW_i×M_i;

[0236] Among them, RiskIndex is the comprehensive risk score, Wi is the weight vector corresponding to the vulnerability severity distribution Severity, exploitation difficulty coefficient Difficulty, electronic control unit coverage or time trend Trend, for example, W=[Severity0.4, Difficulty0.2, Coverage0.2, Trend0.2]; Mi is the vulnerability severity distribution Severity, exploitation difficulty coefficient Difficulty, electronic control unit coverage or time trend Trend.

[0237] Finally, a grading process is performed to determine the risk level of this fuzz test based on the comprehensive risk score and grading rules. For example, a comprehensive risk score of 0-0.3 indicates a low risk level; a comprehensive risk score of 0.3-0.6 indicates a medium risk level; and a comprehensive risk score of 0.6-1 indicates a high risk level. It is understood that the above weights and grading thresholds can be adjusted in YAML to adapt to different organizational policies.

[0238] The above embodiment details the CAN bus fuzz testing process. In practice, this embodiment can be executed using an automated testing process: During the test preparation phase, a test task is created through the Command Line Interface (CLI) or REST POST / jobs, generating a unique ID; a configuration file containing interface type, injection rate limit, and threshold parameters is read; hardware interface connectivity is verified; the latest checkpoints for the mutation point prediction model and policy network model are loaded; a log directory is created, and database tables are initialized. Subsequently, the pipeline is executed in parallel, specifically log replay (Thread-Replay, the corresponding thread / process, replays historical frames for reference modeling); policy inference (Process-Policy, the corresponding thread / process, runs the policy network and mutation point prediction inference on the GPU); message injection (Thread-Inject, the corresponding thread / process, sends frames to the CAN bus according to the scheduler); and status monitoring (Thread-Monitor, the corresponding thread / process, collects error frames and payload). Error handling and retries are then performed. Specifically, the driver is automatically restarted if no ACK is detected within 3 seconds. Injection is paused for 200ms when bus occupancy exceeds 90%. The Supervisor automatically starts and records the stack trace when the exit code is not 0. Further results are collected and packaged, with each child process sending events to the aggregator via ZeroMQ PUSH-PULL. The aggregator refreshes to SQLite every 5 seconds to prevent memory surges and calls a generated HTML file after the task is completed. Finally, CI / CD integration is executed, specifically triggering the GitLab CI webhook to upload the report to Artifacts. If the number of new vulnerabilities with a CVSS score of >7 exceeds 0, the pipeline is automatically marked as failed to prevent it from going online. This achieves automated fuzz testing of the CAN bus.

[0239] In the above embodiments, the CAN bus fuzzy testing method is described in detail. The present application also provides corresponding embodiments of the CAN bus fuzzy testing device.

[0240] Figure 2 This is a schematic diagram of a CAN bus fuzzy test device provided in an embodiment of the present application. Figure 2 As shown, the method includes:

[0241] The extraction module 10 is used to extract the target field in the CAN bus log file.

[0242] Generation module 11 is used to generate a target mutation action based on the target field, the policy network and the historical rewards; wherein the policy network is a neural network model pre-trained based on the historical field for generating corresponding mutation actions; and the historical rewards are the rewards corresponding to the mutation actions generated by the policy network based on the historical fields.

[0243] Determination module 12 is used to determine the target mutation point based on the target field and the mutation point prediction model; wherein the mutation point prediction model is a neural network model pre-trained based on historical fields to determine the mutation point in each data bit of the CAN message payload whose risk level meets preset requirements.

[0244] The testing module 13 is used to generate a test message according to the target field and the target mutation action, and input the test message into the target under test according to a scheduling algorithm based on the target mutation point to perform fuzz testing.

[0245] The analysis module 14 is used to obtain monitoring data fed back by the measured target and perform comprehensive analysis on the monitoring data.

[0246] Since the embodiments of the apparatus part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the apparatus part, and they will not be repeated here.

[0247] Figure 3 A schematic diagram of a CAN bus fuzzy test device provided in an embodiment of the present application. Figure 3 As shown, the CAN bus fuzz testing equipment includes:

[0248] Memory 20, for storing computer programs;

[0249] The processor 21 is configured to implement the steps of the CAN bus fuzzy testing method mentioned in the above embodiment when executing a computer program.

[0250] The CAN bus fuzzy testing device provided in this embodiment may include but is not limited to a smart phone, a tablet computer, a laptop computer, or a desktop computer.

[0251] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented in at least one hardware form: a digital signal processor (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing the content required to be displayed on the display screen. In some embodiments, the processor 21 may also include an artificial intelligence (AI) processor, which is responsible for processing computing operations related to machine learning.

[0252] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory, and non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 20 is at least used to store the following computer program 201, wherein, after the computer program is loaded and executed by the processor 21, it can implement the relevant steps of the CAN bus fuzzy testing method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include but is not limited to data involved in the CAN bus fuzzy testing method.

[0253] In some embodiments, the CAN bus fuzzy testing device may further include a display screen 22 , an input / output interface 23 , a communication interface 24 , a power supply 25 , and a communication bus 26 .

[0254] Those skilled in the art will understand that Figure 3 The structure shown in the figure does not constitute a limitation on the CAN bus fuzz testing device, and may include more or fewer components than shown in the figure.

[0255] Finally, the present application also provides an embodiment corresponding to a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps described in the above method embodiment.

[0256] It is understandable that if the method in the above embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or 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 executes all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program code.

[0257] The above is a detailed introduction to a CAN bus fuzzy testing method, device, equipment and medium provided by the present application. The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same and similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of this application.

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

Claims

1. A CAN bus fuzzy testing method, characterized in that: include: Extract the target field from the CAN bus log file; Generate a target variant action based on the target field, the policy network, and the historical rewards; wherein the policy network is a neural network model pre-trained based on the historical field for generating corresponding variant actions; and the historical rewards are rewards corresponding to the variant actions generated by the policy network based on the historical field; Determining a target variation point based on the target field and a variation point prediction model; wherein the variation point prediction model is a neural network model pre-trained based on historical fields for determining variation points in each data bit of a CAN message payload whose risk level meets preset requirements; generating a test message according to the target field and the target mutation action, and inputting the test message into the target under test according to a scheduling algorithm based on the target mutation point to perform fuzz testing; Obtain monitoring data fed back by the measured target and perform comprehensive analysis on the monitoring data.

2. The CAN bus fuzzy testing method according to claim 1, characterized in that: Extract target fields from CAN bus log files, including: Collecting binary log files or text log files output by a network bus development tool to obtain the CAN bus log file; Extracting a frame identifier, a data length code, a CAN payload, a timestamp, and an error flag of each CAN message frame in the CAN bus log file to extract an initial field; Data cleaning is performed on each of the initial fields to obtain the target field.

3. The CAN bus fuzzy testing method according to claim 2, characterized in that: Performing data cleaning on each of the initial fields includes: Removing non-CAN message frames and invalid repeated CAN message frames in each of the error identifiers; Converting each frame identifier into a hexadecimal representation; The time difference between adjacent frames is calculated according to the timestamps, and the target fields obtained after buffering the data are cleaned.

4. The CAN bus fuzzy testing method according to claim 3, characterized in that: Generate target mutation actions based on the target field, policy network, and historical rewards, including: Calculating the byte entropy and 0 / 1 ratio of the CAN payload of each CAN message frame; Counting the average time interval, time interval standard deviation and burst length of the same frame identifier; Determine the number of triggering rules for the preceding identifier to trigger the following identifier according to a priori algorithms; Normalizing the byte entropy, the 0 / 1 ratio, the average time interval, the time interval standard deviation, the burst length, and the number of trigger rules and concatenating them in a fixed order to generate a 128-dimensional feature vector; The 128-dimensional feature vector and the most recent historical reward are input into the policy network to generate the target mutation action; wherein the target mutation action includes a target frame identifier, a byte index, a bit mask, and a flip rate; the policy network is composed of two fully connected layers, a ReLU activation function, and a Softmax output layer; After inputting the test message into the target under test, obtaining a target triggering event fed back by the target under test; Determining a target reward value corresponding to the target trigger event based on reward values ​​corresponding to each trigger event of the reward function; wherein the trigger event of the reward function includes at least an electronic control unit reset, a bus shutdown, a frame error, a delay greater than a threshold without abnormality, and a normal frame; Fine-tune the policy network according to the target reward value and the policy gradient algorithm.

5. The CAN bus fuzzy testing method according to claim 3, characterized in that: Determining a target variation point according to the target field and the variation point prediction model includes: Expanding a first preset number of CAN message frames closest to the current moment into a two-dimensional matrix in ascending order of the corresponding frame identifiers; Normalizing each data bit in each of the two-dimensional matrices according to a corresponding real level, and filling missing marks between frames to pre-process each of the two-dimensional matrices; Outputting each of the preprocessed two-dimensional matrices to the variation point prediction model to output a risk score for each data bit of the CAN message frame payload; wherein the variation point prediction model is composed of a first convolutional layer, a second convolutional layer, a global average pooling layer, and a fully connected layer; Generate a corresponding risk matrix based on each of the risk scores and set a dynamic risk threshold; Adding data bits corresponding to the risk matrix that are greater than the dynamic risk threshold into a risk queue; Determining whether the number of data bits in the risk queue is less than a bit number threshold; If so, randomly selecting data bits corresponding to the risk matrix that are not greater than the dynamic risk threshold and adding them to the risk queue until the number of data bits in the risk queue is not less than the bit number threshold; If not, each data bit in the risk queue is sorted in descending order according to the corresponding risk score, and written into a target variation point queue; wherein the target variation point queue contains a plurality of target variation points.

6. The CAN bus fuzzy testing method according to claim 5, characterized in that: Generating a test message according to the target field and the target mutation action includes: combining the frame identifier, the data length code, and the CAN payload according to the target variation action to generate the test message; Performing a cyclic redundancy check on the test message, and caching the test message that passes the check into a ring queue; Correspondingly, inputting the test message into the target under test according to the scheduling algorithm based on the target variation point includes: Determine the unmeasured number of each target variation point in the target variation point queue; determining a test priority for each target variation point according to the number of untested times and the risk score of each target variation point; The test messages are injected into the corresponding target variation points in descending order of the test priorities; when the CAN bus load is greater than a preset load threshold, or the response delay of the target under test is greater than a first preset time, the injection of the test message is paused for a second preset time, and random jitter is applied to the time difference.

7. The CAN bus fuzzy testing method according to claim 1, characterized in that: Obtaining monitoring data fed back by the measured target, including: Acquiring frame-level data fed back by the measured target according to a first sampling frequency; wherein the frame-level data includes at least an error frame count, a confirmation error, and a format error; Acquiring node-level data fed back by the measured target according to a second sampling frequency; wherein the node-level data at least includes an electronic control unit reset flag and a bus off count; Obtaining bus-level data fed back by the measured target according to a third sampling frequency; wherein the bus-level data at least includes bus occupancy and number of arbitration failures; Determine the abnormal CAN message frame that triggers the abnormality based on the frame-level data, the node-level data, and the bus-level data, and record the corresponding event payload; wherein the event payload includes a timestamp, a frame identifier, a bit mask, and an electronic control unit state; The repeated abnormal CAN message frames are removed according to the corresponding event payload, and the abnormal CAN message frames are replayed in a CAN network development environment.

8. The CAN bus fuzzy testing method according to claim 7, characterized in that: Performing a comprehensive analysis of the monitoring data, including: Obtaining a frame identifier, a bit mask, an electronic control unit status, and an error type in the event payload of each of the abnormal CAN message frames; Performing error mapping on the hardware error code of each abnormal CAN message frame; wherein the error type includes reset, bus off, confirmation error, format error and timeout; Performing feature vector extraction based on a frame identifier, a bit mask, an electronic control unit state, and an error type in the event payload to generate a 32-dimensional feature vector; Performing DBSCAN clustering on the 32-dimensional feature vector to output a clustering result; wherein the clustering result includes a cluster label, a unique omission list, and statistical data; Deduplication of vulnerabilities is performed based on the payloads of each event and the clustering result, and a target event payload is determined; Perform a CVSS risk rating on the target event payload and generate a corresponding vulnerability risk report; wherein the vulnerability risk report at least includes a vulnerability summary, a trigger sequence, a CVSS score, and a remediation suggestion.

9. The CAN bus fuzzy testing method according to claim 8, characterized in that: Deduplication of vulnerabilities is performed based on the event payloads and the clustering results to determine the target event payload, including: determining the event payloads having the same corresponding frame identifier, bit mask, and error type as the same vulnerability and merging them; Recording only once the event payload having the same frame identifier and bit mask and being repeatedly triggered within a third preset time; The event payloads having different corresponding frame identifiers and / or bit masks and the same corresponding clustering labels are determined to be the same vulnerability and merged.

10. The CAN bus fuzzy testing method according to claim 7, characterized in that: Also includes: Determine the effective trigger count, the total number of injected frames, the average round-trip delay and the bus occupancy rate according to the frame-level data, the node-level data and the bus-level data fed back by the measured target; Determining a trigger rate according to the valid trigger count and the total number of injected frames; adjusting a flip rate upper limit according to the bus occupancy rate, and determining a stress state of an electronic control unit according to the average round-trip delay; Adjusting the flip rate and the time difference according to the trigger rate and the trigger rate threshold to obtain a new flip rate and a new time difference; wherein the flip rate and the time difference have corresponding upper and lower limits for adjustment respectively; The new flip rate and the new time difference are written into the configuration area of ​​the policy network through the shared memory to update the mutation parameters.

11. The CAN bus fuzzy testing method according to claim 8, characterized in that: Also includes: Monitor the CAN bus communication process and identify abnormal events in the communication process based on statistical baseline algorithms, machine learning algorithms, and rule signature algorithms; Performing event correlation analysis on each of the abnormal events according to a preset time window, merging repeated abnormal events and establishing a causal chain between the abnormal events to obtain the correlated abnormal events; The corresponding operation alarm information is determined according to the event type of each of the associated abnormal events, and the corresponding operation alarm processing action is triggered.

12. The CAN bus fuzzy testing method according to claim 11, characterized in that: Also includes: Obtaining the vulnerability risk report, the operational warning information, and baseline data from the historical test warehouse; Determine vulnerability severity distribution, exploitation difficulty coefficient, electronic control unit coverage, and time trend based on the vulnerability risk report, the operation alarm information, and the baseline data; Normalizing the vulnerability severity distribution, the exploit difficulty coefficient, the electronic control unit coverage, and the time trend; Determining a comprehensive risk score based on the normalized vulnerability severity distribution, the exploitation difficulty coefficient, the electronic control unit coverage, the time trend, and the corresponding weight vectors; The risk level of this fuzzy test is determined based on the comprehensive risk score and level classification rules.

13. A CAN bus fuzzy testing device, characterized in that: include: Extraction module, used to extract target fields from CAN bus log files; A generation module, configured to generate a target variant action based on the target field, the policy network, and historical rewards; wherein the policy network is a neural network model pre-trained based on the historical field for generating corresponding variant actions; and the historical rewards are rewards corresponding to the variant actions generated by the policy network based on the historical field; a determination module for determining a target variation point based on the target field and a variation point prediction model; wherein the variation point prediction model is a neural network model pre-trained based on historical fields for determining variation points in each data bit of a CAN message payload whose risk level meets preset requirements; A testing module, configured to generate a test message according to the target field and the target mutation action, and input the test message into the target under test according to a scheduling algorithm based on the target mutation point to perform fuzz testing; The analysis module is used to obtain the monitoring data fed back by the measured target and perform comprehensive analysis on the monitoring data.

14. A CAN bus fuzzy testing device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the CAN bus fuzzy testing method according to any one of claims 1 to 12 when executing the computer program.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the CAN bus fuzzy testing method according to any one of claims 1 to 12.

Images