Machine learning-based intelligent testing method and system for vulnerabilities of internet of things protocols

Abstract

The present application relates to the technical field of Internet of Things security, and more particularly to an intelligent testing method and system for Internet of Things protocol vulnerabilities based on machine learning, which generates an initial seed corpus of state transition path coverage by constructing a protocol state machine and a semantic constraint model, generates a mutated test message by weighting and mutating the seed message according to state coverage feedback, forms an abnormal message feature set by executing fuzzy testing and extracts a vulnerability feature fingerprint library, dynamically adjusts the network access control strategy based on the vulnerability feature fingerprint library to realize real-time interception rule updating and priority sorting, thereby improving the fuzzy testing efficiency and vulnerability discovery capability and realizing continuous dynamic defense for Internet of Things devices.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security technology, and in particular to a machine learning-based intelligent testing method and system for IoT protocol vulnerabilities. Background Technology

[0002] In the current field of IoT protocol fuzzing, conventional practices mainly rely on random or template-based test case generation methods. These methods use predefined protocol message formats as input and subject the target device to large-scale random mutations. The testing process typically ignores the dynamic changes of the device's internal protocol state machine, focusing only on anomaly triggers at the individual message level, lacking systematic coverage of protocol state transition paths. Some advanced solutions introduce state machine models, but only record discrete events of state transitions, failing to deeply extract semantic constraints between protocol fields, such as field length, type validation, and cyclic redundancy checks. This results in generated test cases that cannot accurately target weaknesses in the protocol logic. At the defense level, existing mechanisms mostly employ post-event remediation strategies, i.e., manually analyzing vulnerability characteristics and updating firewall or intrusion detection rules after anomalies are discovered during fuzzing. This static defense model has significant lag, failing to synchronize with the fuzzing process, and rule updates are usually based on isolated message characteristics, lacking correlation identification of protocol-level attack patterns.

[0003] The core flaws of conventional approaches lie in two aspects. During the testing and optimization phase, the neglect of the correlation between protocol field semantic constraints and state coverage leads to a lack of target-oriented mutation of seed packets. Random or simple coverage-driven mutation methods easily get bogged down in repetitive testing of high-frequency states, while potential vulnerabilities in low-coverage state paths are overlooked for extended periods, resulting in wasted testing resources and the risk of missed detections. During the defense phase, the lack of an automated mapping mechanism between vulnerability features and network access control policies means that abnormal packet feature sets are only used as analysis material and cannot trigger dynamic adjustments to interception rules in real time. This isolated approach leaves newly discovered vulnerabilities exposed before security policy updates, and rule priorities cannot be dynamically ordered based on exploit risk, leading to a disconnect between defense response and the actual severity of the vulnerability. These flaws collectively restrict the timeliness and accuracy of IoT protocol security protection, especially in complex heterogeneous protocol environments where traditional solutions are significantly less adaptable. Summary of the Invention

[0004] This invention provides a machine learning-based intelligent testing method and system for IoT protocol vulnerabilities, which can solve the problems in the prior art.

[0005] A first aspect of this invention provides a machine learning-based intelligent testing method for IoT protocol vulnerabilities, comprising: The protocol interaction behavior of the target IoT device is modeled, a protocol state machine is constructed, and the semantic constraint relationship of the protocol fields is extracted to form a protocol semantic constraint model. Based on the protocol semantic constraint model, an initial seed corpus is generated, which contains a set of test messages covering each state transition path of the protocol state machine. Based on the protocol state coverage feedback information, weighted mutations are performed on the seed messages in the test message set. The mutation weights of the seed messages are dynamically adjusted according to the coverage frequency of each state transition path. Structural mutations are applied to the seed messages corresponding to state paths with coverage frequencies lower than a preset frequency threshold first. A coverage-guided mutation test message set is generated. The coverage-guided mutation test message set is input into the target IoT device to perform fuzz testing. The messages that trigger abnormal responses and their corresponding state transition paths are recorded during the test to form an abnormal message feature set. Vulnerability patterns are extracted from the abnormal message feature set to identify protocol field combination features associated with abnormal responses and construct a vulnerability feature fingerprint database. Based on the vulnerability feature fingerprint database, the network access control policy of the target IoT device is dynamically adjusted. Real-time interception rule updates are triggered for inbound messages that match the vulnerability feature fingerprint, and the priority of the interception rules is dynamically sorted according to the vulnerability exploitation risk level.

[0006] The specific steps for modeling the protocol interaction behavior of the target IoT device, constructing a protocol state machine, extracting semantic constraint relationships of protocol fields, and forming a protocol semantic constraint model include: Using the session phase division results experienced by the target IoT device during the protocol interaction process as the basis for defining state nodes, the handshake phase, authentication phase, data transmission phase and session termination phase are respectively mapped to independent state nodes of the protocol state machine. The change in the value of the control field that triggers state switching in the protocol message is used as the state transition condition extraction mechanism. The correspondence between each control field and the state node is analyzed to form a set of state transition conditions. For the field type constraint dimension of the protocol fields, the data type definition of each field is identified and a field type constraint mapping table is established. For the value range constraint dimension of protocol fields, the value distribution range of each field in legal interaction messages is statistically analyzed to determine the upper and lower bounds of each field's value. For the time dependency constraint dimension of protocol fields, the constraint relationship between the value of the preceding message field and the value of the subsequent message field in the same state transition path is extracted to establish a field time dependency graph. The field type constraint mapping table, the value range constraint boundary, and the field time dependency graph are integrated to form the protocol semantic constraint model.

[0007] Based on the aforementioned protocol semantic constraint model, the step of generating an initial seed corpus, wherein the initial seed corpus contains a set of test messages covering each state transition path of the protocol state machine, specifically includes: Based on the triggering frequency and state coverage contribution of each state transition path in the protocol state machine, the state transition paths are prioritized and the state transition paths with a triggering frequency lower than a preset frequency threshold and a state coverage contribution higher than a preset contribution threshold are marked as high priority paths. For high-priority paths, seed messages are selected from legal messages that satisfy all constraints in the protocol semantic constraint model according to the path coverage depth, and messages with a path coverage depth greater than a preset depth threshold are preferentially included in the initial seed corpus. The test message set is constructed using a layered construction approach. In the base layer, state trigger messages covering each state node are constructed. In the extension layer, boundary coverage messages are constructed based on the field constraint boundaries of high-priority paths. In the depth layer, a multi-step interaction message sequence across state transition paths is constructed. The messages at each layer are deduplicated, and messages that trigger the same state transition result in the protocol state machine as existing seed messages are removed, while messages that trigger different state transition results are retained to form the initial seed corpus.

[0008] The steps of performing weighted mutation on the seed packets in the test packet set based on the protocol state coverage feedback information specifically include: The number of triggers for each state transition path in each round of fuzz testing is counted, and the real-time coverage frequency of each path is calculated as the ratio of the number of triggers to the total number of test rounds, forming a coverage frequency vector. Based on the coverage frequency vector, mutation weights are assigned to various sub-messages, and structural mutations are implemented on the length boundaries, type constraints, and inter-field dependencies of the protocol fields according to the protocol semantic constraint model. The structural mutations include three types of operations: field truncation, field padding, and cross-field constraint violation. The mutated message and the original seed message are weighted and sampled according to their respective mutation weights to form a cover-guided mutation test message set. After the cover-guided mutation test message set is input into the target IoT device, the device response status is collected in real time. Messages that trigger unexpected state transitions or abnormal response codes, along with their state transition paths, are recorded together to form the abnormal message feature set.

[0009] The steps of weighting and sampling the mutated messages and the original seed messages according to their respective mutation weights to form a set of mutation test messages guided by coverage include: Field truncation operations are divided into two dimensions based on the length boundary constraints of protocol fields: boundary value truncation and out-of-bounds truncation. Boundary value truncation adjusts the field length to the minimum or maximum value specified in the protocol specification, while out-of-bounds truncation sets the field length to a value that exceeds the maximum value or is lower than the minimum value. Field filling operations are divided into two dimensions according to type constraints: legal type boundary filling and illegal type filling. Legal type boundary filling overwrites the field content with extreme value data that conforms to the field type constraints, while illegal type filling overwrites the field with data format that violates the field type definition. Cross-field constraint violation operations are divided into two dimensions based on the inter-field dependency relationship: length reference violation and check integrity violation. Length reference violation modifies the value of the length indicator field in the message to a value that is inconsistent with the actual payload length, while check integrity violation modifies the check value in the message containing the check field to a value that does not match the payload calculation result. The mutation results of each dimension of the above three types of operations are labeled with the corresponding mutation type tags and incorporated into the mutation test message set guided by the coverage.

[0010] The steps for dynamically adjusting the network access control policy of the target IoT device based on the vulnerability fingerprint database specifically include: For each vulnerability feature fingerprint in the vulnerability feature fingerprint database, a multi-dimensional matching rule is constructed. The multi-dimensional matching rule covers protocol field offset, field value range threshold, and field combination association constraints. Real-time feature parsing is performed on the inbound packets received by the target IoT device. The parsing results are compared with the multi-dimensional matching rule item by item. When the comparison results meet the matching conditions, an interception rule generation instruction is triggered. Based on the interception rule generation instruction, an interception rule update message is pushed to the network access control policy module. The interception rule update message includes the target protocol field identifier, the interception action type, and the rule effective timestamp. The vulnerability exploitation risk level is determined for the vulnerability feature fingerprint that triggers the matching. The vulnerability exploitation risk level is calculated based on the historical trigger frequency of the vulnerability feature fingerprint, the severity of the associated abnormal response, and the exposure range of the protocol state transition path. Based on the vulnerability exploitation risk level, all currently effective interception rules are dynamically prioritized and sorted. Interception rules corresponding to high risk levels are scheduled to the first position in the priority matching queue, while interception rules corresponding to low risk levels are moved to the next position in sequence, thus completing continuous dynamic defense against the target IoT device.

[0011] The specific steps of generating instructions to push interception rule update messages to the network access control policy module based on the interception rules include: The target protocol field identifier carried by the interception rule generation instruction is parsed to identify the set of protocol fields that have association constraints with the target protocol field in the protocol semantic constraint model, and the set of protocol fields is included in the linkage detection scope of the interception rule. Based on the aforementioned linkage detection range, a joint matching condition for associated fields is constructed, the single-field interception condition is expanded into a multi-field composite interception condition, and the multi-field composite interception condition is encapsulated into the rule body field of the interception rule update message; Perform coverage redundancy detection on the already effective blocking rules, mark existing rules that have an inclusion relationship with the matching coverage of the newly generated blocking rules as redundant rules, and revoke the redundant rules from the network access control policy module; A rule activation confirmation mechanism is set for the interception rule update message. Before the network access control policy module returns a rule activation confirmation response, the corresponding inbound message that triggers the matching is placed in a deferred processing queue to complete the continuous dynamic defense against the target IoT device.

[0012] A second aspect of this invention provides an intelligent testing system for IoT protocol vulnerabilities based on machine learning, comprising: The protocol modeling unit is used to model the protocol interaction behavior of the target IoT device, build the protocol state machine, extract the semantic constraint relationship of the protocol fields, and form a protocol semantic constraint model. The seed generation unit is used to generate an initial seed corpus based on the protocol semantic constraint model. The initial seed corpus contains a set of test messages covering each state transition path of the protocol state machine. The mutation testing unit is used to perform weighted mutations on the seed messages in the test message set based on the protocol state coverage feedback information, dynamically adjust the mutation weights of the seed messages according to the coverage frequency of each state transition path, prioritize the application of structural mutations to the seed messages corresponding to low coverage state paths, generate a coverage-guided mutation test message set, input the coverage-guided mutation test message set into the target IoT device to perform fuzz testing, record the messages that trigger abnormal responses and the corresponding state transition paths during the test, and form an abnormal message feature set. The feature extraction unit is used to extract vulnerability patterns from the abnormal message feature set, identify the protocol field combination features associated with the abnormal response, and construct a vulnerability feature fingerprint database. The dynamic defense unit is used to dynamically adjust the network access control policy of the target IoT device based on the vulnerability feature fingerprint database, trigger real-time interception rule updates for inbound packets that match the vulnerability feature fingerprint, and dynamically sort the priority of the interception rules according to the vulnerability exploitation risk level, so as to complete the continuous dynamic defense of the target IoT device.

[0013] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0014] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0015] The establishment of the protocol state machine and semantic constraint model accurately characterizes the protocol interaction behavior of IoT devices, extracts the semantic dependencies between fields, and enables the initial seed corpus to comprehensively cover all state transition paths of the protocol, significantly reducing redundant test messages and improving the targeting and efficiency of fuzz testing. The integration of semantic constraints ensures that the generated messages conform to the protocol specifications, avoids invalid testing, and accelerates the vulnerability discovery process.

[0016] The coverage-guided weighted mutation mechanism dynamically adjusts the mutation weights of seed packets based on state coverage feedback, prioritizing structural mutations on low-coverage state paths. This effectively balances test resource allocation, prevents testing from getting bogged down in local hotspots, and encourages fuzz testing to delve deeper into weak points, significantly increasing the probability of exposing deep vulnerabilities. System records and vulnerability pattern extraction from abnormal response packets construct a precise vulnerability signature fingerprint database, providing high-quality attack signature data for subsequent defense.

[0017] The vulnerability signature fingerprint database drives real-time dynamic adjustments to network access control policies. When an inbound packet matches a signature fingerprint, it immediately triggers an update of the interception rules and prioritizes the rules according to the vulnerability exploitation risk level, achieving precise and rapid proactive defense response. This method organically integrates fuzz testing and dynamic defense, efficiently locating vulnerabilities during the testing phase and continuously resisting attacks during the operational phase, forming a closed-loop feedback between testing and defense, significantly enhancing the attack resistance and security resilience of IoT devices. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating a machine learning-based intelligent testing method for IoT protocol vulnerabilities. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0021] Figure 1 This is a flowchart illustrating the intelligent testing method for IoT protocol vulnerabilities based on machine learning, as described in an embodiment of the present invention. The intelligent testing method for IoT protocol vulnerabilities based on machine learning includes: Model the protocol interaction behavior of the target IoT device, construct the protocol state machine, extract the semantic constraint relationship of the protocol fields, and form a protocol semantic constraint model; Based on the protocol semantic constraint model, an initial seed corpus is generated, which contains a set of test messages covering each state transition path of the protocol state machine. Based on the protocol state coverage feedback information, weighted mutations are performed on the seed messages in the test message set. The mutation weights of the seed messages are dynamically adjusted according to the coverage frequency of each state transition path. Structural mutations are applied to the seed messages corresponding to low coverage state paths first, generating a coverage-guided mutation test message set. The coverage-guided mutation test message set is input into the target IoT device to perform fuzz testing. Messages that trigger abnormal responses and their corresponding state transition paths are recorded during the test to form an abnormal message feature set. Vulnerability pattern extraction is performed on the abnormal message feature set to identify the protocol field combination features associated with the abnormal response and to construct a vulnerability feature fingerprint database. Based on the vulnerability feature fingerprint database, the network access control policy of the target IoT device is dynamically adjusted. Real-time interception rules are updated for inbound packets that match the vulnerability feature fingerprint. The priority of the interception rules is dynamically sorted according to the vulnerability exploitation risk level to complete the continuous dynamic defense of the target IoT device.

[0022] The specific steps for modeling the protocol interaction behavior of the target IoT device, constructing a protocol state machine, extracting semantic constraint relationships of protocol fields, and forming a protocol semantic constraint model include: Using the session phase division results experienced by the target IoT device during the protocol interaction process as the basis for defining state nodes, the handshake phase, authentication phase, data transmission phase and session termination phase are respectively mapped to independent state nodes of the protocol state machine. The change in the value of the control field that triggers state switching in the protocol message is used as the state transition condition extraction mechanism. The correspondence between each control field and the state node is analyzed to form a set of state transition conditions. For the field type constraint dimension of the protocol fields, identify the data type definition to which each field belongs and establish a field type constraint mapping table; For the constraint dimension of the value range of protocol fields, the distribution range of the values ​​of each field in the legal interaction messages is statistically analyzed to determine the upper and lower bounds of the values ​​of each field; For the temporal dependency constraint dimension of protocol fields, extract the constraint relationship between the values ​​of preceding message fields and the values ​​of subsequent message fields in the same state transition path, and establish a field temporal dependency graph; The field type constraint mapping table, value range constraint boundary, and field temporal dependency graph are integrated to form the protocol semantic constraint model.

[0023] When modeling the protocol interaction behavior of target IoT devices, it is necessary to first conduct in-depth observation of the device's complete communication process. This is achieved by deploying a traffic mirroring device between the target device and its legitimate communication peer, continuously capturing the protocol message sequences of bidirectional interactions. For common IoT protocols such as MQTT, CoAP, Zigbee, or Modbus, the entire interaction cycle is divided into several typical session stages based on their communication characteristics.

[0024] The handshake phase typically involves connection establishment and protocol version negotiation. The message characteristics of this phase are that the client sends a connection request, and the server returns a connection confirmation. Taking the MQTT protocol as an example, the client sends a CONNECT message, and the server responds with a CONNACK message; this interaction sequence constitutes the typical characteristics of the handshake phase. This phase can be defined as the initial state node in the state machine. This node represents the initial state where the device has not yet established a valid connection.

[0025] The authentication phase involves identity verification and authorization mechanisms. The messages in this phase contain authentication credential fields such as username, password, token, or certificate. In the MQTT protocol, these credentials are typically encoded in the variable header and payload of the CONNECT message, and the server returns different return codes based on the validity of the credentials. The authentication phase is mapped to state nodes. This node represents an intermediate state where the device has established a physical connection but has not yet been authenticated.

[0026] The data transmission phase is the core of the protocol interaction, involving various operation types such as subscribing to topics, publishing messages, and receiving acknowledgments. During this phase, the client can send messages such as SUBSCRIBE and PUBLISH, and the server responds with acknowledgment messages such as SUBACK and PUBACK. The data transmission phase is defined as a state node. This node indicates that the device has completed authentication and is in a normal data exchange state.

[0027] The session termination phase involves connection disconnection and resource release. This phase is triggered when the client sends a DISCONNECT message or detects a network anomaly. This phase is mapped to a termination state node. This node represents the final state where the session has ended and the resources have been released.

[0028] Extracting state transition conditions relies on precise parsing of protocol message control fields. Taking the MQTT protocol as an example, the message type field is located in the high four bits of a fixed header, and its value directly determines the state transition direction. When the message type field is 1, it indicates a CONNECT message, triggering a transition from... arrive The state transition; a value of 2 indicates a CONNACK message, while a return code field of 0 indicates a successful connection, triggering a transition from... arrive The transfer, if the return code is non-zero, remains in Or revert to By traversing all valid message samples, the values ​​of control fields such as message type, return code, and flags are extracted to form a set of state transition conditions. Each of the conditions Represented as a triple , which represent the field name, comparison operator, and trigger value, respectively.

[0029] When constructing the protocol semantic constraint model, a systematic analysis is first performed on the field type constraint dimension. By parsing the protocol specification document and inferring the type from the byte sequence of captured messages, the data type attribute of each field is identified. For example, the Remaining Length field in the MQTT protocol uses a variable-length encoding mechanism, and its type is defined as a variable-length integer; the Client Identifier field is a UTF-8 encoded string; and the Keep-On Time field is a 16-bit unsigned integer. A field type constraint mapping table is then established. Each entry in the table is a record. Clearly define the correspondence between field names, data types, and encoding schemes.

[0030] To address the constraint on the value range, a statistical analysis was performed on the historical set of valid interaction messages. Taking the MQTT keep-alive time field as an example, by traversing all captured CONNECT messages, a sample set of values ​​for this field was extracted, and the minimum value of the sample was calculated. With the maximum value If the statistical analysis shows that the value range of this field is between 60 and 3600 seconds, then the lower bound of the field's value is determined to be 60, and the upper bound to be 3600. For enumerated type fields such as the service quality level field, its valid value set is... Any value outside this set violates the constraint. Record the value range constraints for all fields as follows: ,in Used to store the set of valid values ​​for an enumeration type.

[0031] Extracting time-series dependency constraints requires analyzing the relationships between fields across messages. In the MQTT protocol, the message identifier field in a PUBLISH message must remain consistent with the message identifier field in a subsequent PUBACK message, constituting a typical time-series dependency constraint. By tracing the message sequence within the same session, a specific field in a preceding message can be identified. The value of affects the fields in subsequent messages. The constraints arising from the values ​​of the elements. Establish a field sequence dependency graph. In the diagram, nodes represent protocol fields, and directed edges... Representation field For fields Temporal dependencies exist, and the edge weights record the dependency types, including equality dependencies, incremental dependencies, and referential dependencies. For example, an equality dependency exists between the message identifier in a SUBSCRIBE message and the message identifier in a SUBACK message, represented as an edge. .

[0032] For complex cross-state temporal dependencies, analysis needs to be performed in conjunction with state machine paths. For example, when a device... The CONNECT message sent in the state carries a clear session flag, and the value of this flag will affect subsequent events. Session recovery behavior under a state. If the clear session flag is set to 1, the server does not retain the previous session state, and the client needs to resubscribe to the topic after reconnecting; if it is set to 0, the server retains the session state, and the client can resume the previous subscription. This cross-state field dependency relationship is represented in the time-series dependency graph as directed edges across state nodes, with the edge attributes indicating state transition path information.

[0033] When integrating the constraint information from the above three dimensions, a unified protocol semantic constraint model data structure is constructed. This model is organized in a hierarchical architecture: the top layer is a state machine topology, recording the set of state nodes. And state transition relationships; the middle layer is the field constraint layer, which contains the field type constraint mapping table. And a value range constraint table; the underlying layer is a time-series dependency layer, storing the field time-series dependency graph. The model supports a constraint query interface. Inputting a field name will return the field's type definition, value range, and its temporal dependencies with other fields.

[0034] In practical modeling, heuristic inference mechanisms are used to supplement constraint information for protocol extended fields or custom fields. When encountering fields not explicitly defined in the protocol specification, their possible data types are inferred by analyzing the value distribution characteristics of the field in different message samples. For example, if a field takes the value of an integer in the range of 0 to 255 in all samples, its type is inferred to be an 8-bit unsigned integer; if the value exhibits a clear string pattern, it is inferred to be a text type. For the inference of temporal dependencies, association rule mining algorithms are used to analyze the co-occurrence patterns between fields. With fields When messages with adjacent times frequently appear with the same value, it can be inferred that there may be an equal dependency relationship between them.

[0035] The constructed protocol semantic constraint model provides precise constraint boundaries for subsequent seed corpus generation and mutation testing. Field type constraints recorded in the model ensure that the generated test messages conform to the protocol encoding specifications at the byte level; value range constraints guide mutation operations to explore within legal limits; and temporal dependency constraints guarantee the logical consistency of the generated message sequence. The completeness of this model directly affects the coverage and vulnerability detection capabilities of subsequent fuzzing.

[0036] Based on the aforementioned protocol semantic constraint model, the step of generating an initial seed corpus, wherein the initial seed corpus contains a set of test messages covering each state transition path of the protocol state machine, specifically includes: Based on the triggering frequency and state coverage contribution of each state transition path in the protocol state machine, the state transition paths are prioritized and the state transition paths with low triggering frequency and high state coverage contribution are marked as high priority paths. For high-priority paths, seed messages are selected from the legal messages that satisfy all constraints in the protocol semantic constraint model according to the path coverage depth, and messages with large path coverage depth are preferentially included in the initial seed corpus. The test message set is constructed using a layered construction approach. In the base layer, state trigger messages covering each state node are constructed. In the extension layer, boundary coverage messages are constructed based on the field constraint boundaries of high-priority paths. In the depth layer, a multi-step interaction message sequence across state transition paths is constructed. The messages at each layer are deduplicated, and messages that trigger the same state transition result in the protocol state machine as existing seed messages are removed, while messages that trigger different state transition results are retained to form the initial seed corpus.

[0037] When constructing the initial seed corpus, the first step is to quantitatively evaluate all state transition paths in the protocol state machine. This is done by statistically analyzing the historical interaction logs of the target IoT device in a test execution environment, extracting the number of times each state transition path is triggered under normal business scenarios. For example, regarding the CoAP protocol interaction behavior of a smart lock device, it might be found that the transition path from the initial state to the authentication state is triggered 9500 times in 10000 normal interactions, while the abnormal path of directly reverting from the data transmission state to the initial state is triggered only 15 times. The trigger frequency of each path is recorded as follows: subscript This represents the identifier of the specific state transition path.

[0038] The calculation of state coverage contribution needs to comprehensively consider path length and path reachability. For a given path, if the number of state nodes it connects is... If the path is the only or primary way to reach certain critical states, then its coverage contribution is... This can be represented as the sum of the weights of state nodes traversed by the path that are not fully covered by other high-frequency paths. For example, if a path can reach an error handling state that has never appeared in high-frequency paths, the coverage contribution of that path is significantly improved. This is achieved through calculation... Sort the paths by priority, where and The balance coefficient is usually taken as... , , This represents the maximum trigger frequency across all paths. The calculation results show... Paths with higher values ​​are high-priority paths that require special attention. These paths often correspond to logical branches in which the device handles abnormal situations or boundary conditions.

[0039] Selecting seed packets for high-priority paths requires introducing a metric for path coverage depth. Path coverage depth Defined as the minimum number of state transitions required to reach the endpoint state of a path starting from the initial state node of the protocol state machine. For example, a path directly transitioning from the initial state to the authentication state has a depth of 1, while a path requiring sequential transitions through the initial state, temporary connection state, pre-authentication state, and finally to the formal authentication state has a depth of 3. To construct a message that triggers a path of depth 3, while satisfying the field type constraints, numerical range constraints, and temporal dependency constraints in the protocol semantic constraint model, it is necessary to ensure that the field values ​​in each step of the message sequence strictly adhere to the sequential dependencies defined in the field dependency graph. For example, if the field... The value range depends on the fields in the preceding message. The value of the result must be guaranteed when generating the message sequence. First, a value is assigned, and its value is within the constraints. Then... The assignment needs to be based on The actual value is adjusted within the range of values.

[0040] The base layer of the layered construction strategy focuses on reachability verification of single-state nodes. For each identified state node in the protocol state machine... Construct a message that can reach the current state from the initial state via the shortest path. For example, for the data transmission state, generate a message containing valid authentication credentials and setting the message type field to data transmission request. The construction of base layer messages must strictly adhere to the protocol specifications, ensuring that the field length field matches the actual payload length, the checksum field is correctly calculated using the specified algorithm, and the sequence number field conforms to monotonically increasing or protocol-specific rules. For the MQTT protocol, base layer messages must include a CONNECT message to trigger the transition from the initial state to the connected state, a PUBLISH message to trigger the entry into the data transmission state, and a DISCONNECT message to trigger the arrival of the terminated state.

[0041] The boundary coverage message construction of the extension layer performs boundary value testing on key fields involved in high-priority paths. Field constraints corresponding to these paths are extracted from the protocol semantic constraint model, and test samples are generated for numeric fields, including their lower bound, lower bound minus one, upper bound, and upper bound plus one. For example, if the protocol specifies that the legal range for the message length field is 64 to 1024 bytes, messages with lengths of 64, 63, 1024, and 1025 bytes are generated. For enumerated fields, all legal enumerated values ​​and one undefined illegal enumerated value are generated. For string fields, empty strings, single characters, strings with the maximum allowed length, excessively long strings, and strings containing special control characters are constructed. In the Modbus protocol test of an IoT gateway device, all standard function codes covering 0x01 to 0x06, as well as undefined function codes like 0xFF, are generated for the function code field, effectively triggering the device's processing logic for illegal function codes.

[0042] The deep layer constructs multi-step interaction message sequences to simulate complex state transition scenarios in real business processes. High-priority paths requiring multiple intermediate states to reach the target state are selected, and message sequences are constructed according to the state transition order. Each message must carry a specific combination of fields required to trigger the corresponding state transition, and related fields such as session identifiers and transaction IDs in subsequent messages must be consistent with those in preceding messages. For example, a complete device firmware upgrade process message sequence is constructed, including firmware version query messages, upgrade request messages, data fragment transmission message sequences, and upgrade completion confirmation messages. During the data fragment transmission phase, the sequence number field of each fragment message must strictly increment, the fragment offset field must match the cumulative length of the preceding fragment, and the end flag of the last fragment must be correctly set. For RTSP protocol interactions with smart cameras, a complete session establishment and termination sequence including OPTIONS, DESCRIBE, SETUP, PLAY, and TEARDOWN is constructed, ensuring that each step carries the correct Session field and CSeq sequence number.

[0043] The deduplication mechanism avoids corpus redundancy through state transition equivalence determination. For two seed messages, if they trigger state transitions with the same starting and ending points in the protocol state machine, and the intermediate state sequences they pass through during the transitions are completely identical, then the two messages are considered equivalent at the state coverage level. State transition path fingerprinting technology is used to encode the state transition sequence triggered by each message into a hash value. The specific calculation method involves representing the state transition sequence as a concatenated string of state node identifiers, for example, " The string is hashed using SHA-256. Before adding a new message to the initial seed corpus, its state transition path fingerprint is calculated and compared with the fingerprints of existing messages. If a fingerprint collision is found, the differences between the two messages at the field level are further compared. If the key field values ​​are exactly the same, the new message is discarded; if the key fields are different, the new message is retained but its association with existing messages is marked.

[0044] Identifying differentiated state transition results requires fine-grained feature extraction. Besides changes in state nodes, it's also necessary to record the device's response message type, response latency, and status code field values ​​within the response message during the state transition. For example, two messages might both trigger a transition from the initial state to the authentication state, but the first message might receive a 0x00 response status code indicating successful authentication, while the second message might receive a 0x01 response status code indicating authentication failure but allowing retry. Although these two messages trigger the same state transition, their response characteristics differ significantly and should be retained simultaneously. This is achieved by constructing a state transition result vector. ,in For source status identifier, For target status identification, In response to message type, In response to the status code, To identify the response delay interval, the state transition results of different messages are vectorized, and the degree of difference in the results is determined by using cosine similarity or Euclidean distance.

[0045] The final quality of the initial seed corpus is validated using a coverage metric. This involves calculating the coverage of state nodes triggered by messages within the corpus. ,in The number of state nodes triggered by at least one seed message. This represents the total number of state nodes in the protocol state machine. The state transition edge coverage rate is also calculated. ,in The number of state transition edges that are triggered. This represents the total number of state transition edges in the protocol state machine. For industrial-grade IoT protocols, the requirement is... and This serves as the quality baseline for the initial seed corpus. If the coverage does not meet the standard, it is necessary to reverse-analyze the preconditions of the uncovered state nodes and construct additional messages that satisfy these preconditions.

[0046] In the step of performing weighted mutation on seed packets in the test packet set based on protocol state coverage feedback information: The number of times each state transition path is triggered in each round of fuzz testing is counted, and the real-time coverage frequency of each path is calculated by the ratio of the number of triggers to the total number of test rounds, forming a coverage frequency vector; Based on the coverage frequency vector, mutation weights are assigned to various sub-messages. Seed messages associated with state transition paths whose coverage frequency is lower than the preset coverage frequency threshold are given higher mutation weights, while seed messages whose coverage frequency is higher than the preset coverage frequency threshold are given lower mutation weights. For seed messages that are assigned high mutation weights, structural mutations are performed on the length boundaries, type constraints, and inter-field dependencies of the protocol fields according to the protocol semantic constraint model. The structural mutations include three types of operations: field truncation, field padding, and cross-field constraint violation. The mutated messages and the original seed messages are weighted and sampled according to their respective mutation weights to form a set of mutation test messages guided by coverage. After the mutation test message set guided by the coverage is input into the target IoT device, the device response status is collected in real time. The messages that trigger unexpected state transitions or abnormal response codes, along with the state transition paths they have experienced, are recorded together to form the abnormal message feature set.

[0047] During each round of fuzz testing, a real-time statistical mechanism for the number of state transition path triggers is first established. For each state transition path defined in the protocol state machine, an independent trigger counter is set. When a test message triggers a specific state transition, the counter for the corresponding path is incremented. After completing a single round of testing, the accumulated value of each path's counter is extracted, and the result is used to determine the trigger count. The number of times a state transition path is triggered is denoted as At the same time, record the total number of rounds of the current test. By calculating the ratio The real-time coverage frequency of the path is obtained, reflecting the relative frequency with which the path is triggered during the test. After performing the same calculation on all state transition paths, the coverage frequencies of each path are arranged in order of path index to form a coverage frequency vector. ,in This represents the total number of state transition paths in the protocol state machine. Each component of this vector directly corresponds to the current coverage status of a state transition path, providing a quantitative basis for subsequent mutation weight allocation.

[0048] Based on the constructed coverage frequency vector, differentiated mutation weights are assigned to various sub-packets in the test packet set. A preset coverage frequency threshold is set. This threshold is typically set based on protocol complexity and testing objectives, with a typical range of 0.1 to 0.3. For coverage frequency vectors that satisfy... Paths with insufficient coverage in the current test are identified as low-coverage paths, potentially hiding unexplored protocol state spaces. Seed packets directly associated with these low-coverage paths—those that trigger these paths in the protocol state machine—are assigned high mutation weights. Conversely, for coverage frequencies that satisfy... The path, whose corresponding seed message has been thoroughly tested, has had its mutation weight reduced to [value missing]. The weighting is based on an inverse proportional relationship, and the specific calculation formula is as follows: ,in This is the weighting amplification factor, used to adjust the overall level of mutation intensity. When the path coverage frequency is close to zero, the corresponding seed packet receives the maximum mutation weight, ensuring that test resources are prioritized for insufficiently covered protocol state areas.

[0049] For seed messages assigned high mutation weights, structural mutation operations conforming to the protocol semantic constraint model are performed. This process differs from traditional random byte flipping; instead, it intentionally disrupts the semantic structure of protocol fields. Field truncation, for variable-length fields or fields containing nested structures, artificially sets the actual length field value to a mismatch with the payload length. For example, when a protocol field is defined using length prefix encoding, and the length field declares a subsequent payload of 128 bytes, the truncation operation reduces the actual payload length to 64 bytes while keeping the length field value unchanged, constructing a malformed message with inconsistent lengths. Field padding performs the opposite logic: with a declared length of 64 bytes, it pads the payload area with 128 bytes of data, observing the device's ability to handle excessively long data. The padding content can use repetitive patterns, incremental sequences, or valid data fragments extracted from the protocol semantic constraint model, increasing the probability of triggering memory vulnerabilities such as buffer overflows.

[0050] Cross-field constraint violation operations precisely break the dependencies between fields defined in the protocol semantic constraint model. This involves extracting field pairs with dependencies from the field temporal dependency graph, such as field... The validity depends on the field Specific values. Normally, when When the value is a specific flag bit, This should appear in the message. Cross-field constraint breaking operations intentionally violate this rule. Forced insertion without setting the corresponding flag Fields, or Require Delete it if it exists. For numerical dependencies, if the field... The defined quantity value should match the number of subsequent subfields of a certain type. Constraint violation operations set the quantity field to a mismatched state with the actual number of subfields. This type of structural variation can effectively trigger state synchronization errors and exception handling branches in the protocol parser.

[0051] After structural mutation is completed, a weighted sampling mechanism is established between the mutated message and the original seed message. Each mutated message is paired with its corresponding original seed message, and weighted sampling is performed according to the previously assigned mutation weight values. Let the set of original seed messages be... The set of messages generated after mutation is The weights corresponding to each message are: The sampling process employs a weighted random selection strategy, and the message... The probability of being selected is proportional to the ratio of its weight value to the sum of the weights of all messages. Through multiple rounds of sampling, a fixed number of test messages are extracted from the mixed set of the original seed messages and mutated messages to form the overlay-guided mutated test message set. This set, while retaining the original valid seeds, significantly increases the proportion of mutated packets for low-coverage paths, enabling adaptive allocation of test resources.

[0052] After inputting the constructed, coverage-guided mutation test message set into the target IoT device, a real-time response status acquisition system is established. This system activates a status monitoring module simultaneously with message transmission, capturing the device's returned response messages and parsing the status code fields. For protocols supporting multi-state responses, the system extracts the status identifier, error code, or exception flags contained in the response messages. Simultaneously, it monitors the device's state transition behavior, identifying any unexpected state transitions by comparing the device state before and after message transmission. For example, if the test message should trigger a transition from state according to the protocol specification... to state The transfer was not observed, but the device was actually put into operation. When this occurs, it is determined to be an unexpected state transition event.

[0053] For messages that trigger an abnormal response, detailed context information is recorded. This recording includes the original byte stream of the complete test message that caused the abnormality, the specific operation type and location applied during the mutation process, the source state of the device when sending the message, the target state the device transitions to after receiving the response, and the complete content of the response message returned by the device. For the state transition path, a path encoding method is used to record the complete state sequence experienced from the start of the test to the triggering of the abnormality, represented as a state node sequence. ,in This is a status node that triggers an exception. When the device returns a clear exception response code, extract the value of the response code and its semantic meaning in the protocol specification, such as access denied, format error, or internal error. Some exceptions manifest as no device response or connection interruption; in these cases, record the timeout duration and the last bidirectional message exchange before the connection is broken.

[0054] All recorded anomaly triggering events are stored in a structured manner, with each event serving as an independent entry in the anomaly message feature set. The entry's data structure includes the field-level parsing results of the anomaly message, labeling the type, value range, and whether each field has undergone mutation operations. For fields that have undergone structural mutations, additional mutation type identifiers are recorded, such as the difference between the original and truncated lengths for truncation operations, the number of bytes padded and the padded pattern for field padding operations, and the specific constraint relationship violated for cross-field constraint breaking records. State transition path information is stored as path fingerprints, generating unique identifiers through hash operations on state sequences and transition conditions, facilitating subsequent clustering analysis of anomalies with similar paths. The response feature dimension records the response message's type code, status code, and key field values; for no-response cases, it records the timeout threshold and connection status. The complete anomaly message feature set integrates the above multi-dimensional information, providing a structured input data source for the subsequent vulnerability pattern extraction stage, ensuring accurate identification of protocol field combination features and state transition patterns that lead to abnormal device behavior.

[0055] In the step of implementing structural mutations according to the protocol semantic constraint model for seed messages assigned high mutation weights: Field truncation operations are divided into two dimensions based on the length boundary constraints of protocol fields: boundary value truncation and out-of-bounds truncation. Boundary value truncation adjusts the field length to the minimum or maximum value specified in the protocol specification, while out-of-bounds truncation sets the field length to a value that exceeds the maximum value or is lower than the minimum value. Field filling operations are divided into two dimensions according to type constraints: legal type boundary filling and illegal type filling. Legal type boundary filling overwrites the field content with extreme value data that conforms to the field type constraints, while illegal type filling overwrites the field with data format that violates the field type definition. Cross-field constraint violation operations are divided into two dimensions based on the inter-field dependency relationship: length reference violation and check integrity violation. Length reference violation modifies the value of the length indicator field in the message to a value that is inconsistent with the actual payload length, while check integrity violation modifies the check value in the message containing the check field to a value that does not match the payload calculation result. The mutation results of each dimension of the above three types of operations are labeled with the corresponding mutation type tags and incorporated into the mutation test message set guided by the coverage.

[0056] For seed messages assigned high mutation weights, structural mutation operations guided by the protocol semantic constraint model can accurately locate potential security vulnerabilities such as boundary handling defects, type validation vulnerabilities, and insufficient field correlation validation in the protocol implementation. The core of these mutation operations lies in selectively disrupting the integrity of semantic constraints while maintaining the basic protocol structure of the message as identifiable, thereby triggering abnormal processing logic of the target device under unexpected input conditions.

[0057] Field truncation operations probe a device's robustness to boundary conditions by manipulating the length attribute of protocol fields. Boundary value truncation extracts the field length constraints defined in the protocol specification; for variable-length fields, it adjusts their actual length to the minimum allowed by the specification. or maximum value This operation verifies whether the device correctly implements the memory allocation strategy and data parsing logic under boundary conditions. For example, for the client identifier field in the IoT MQTT protocol, the protocol specification requires its length to be between 1 and 23 bytes. The boundary value truncation operation will generate extremely short identifiers with a length of exactly 1 byte and extremely long identifiers with a length of up to 23 bytes. The test examines whether the device encounters buffer allocation errors or string processing anomalies when handling these two boundary cases. The out-of-bounds truncation operation breaks through the length limit of the protocol specification, for which a maximum length is defined. The field generates a length of Extremely long fields, including incremental ones Values ​​typically chosen as powers of 2, such as 256, 512, or 1024 bytes, are used to trigger potential buffer overflow vulnerabilities; for those with a defined minimum length... The field generates a length of The system detects device crashes or logical errors when the length check is insufficient, even generating zero-length fields. In the CoAP protocol's token field processing, out-of-bounds truncation can set the token length, originally limited to 0 to 8 bytes, to 16 bytes or a larger value, allowing observation of whether the device causes subsequent message parsing offset errors due to the lack of strict validation of the upper length bound.

[0058] The field population operation performs targeted valid boundary detection and invalid type injection based on the data type constraints of the protocol fields. The valid type boundary population operation is based on the field type constraint mapping table. The system records type definitions and fills extreme values ​​for different data type fields. For integer type fields, if they are defined as unsigned 8-bit integers, they are filled with 0 and 255 as type boundary values ​​respectively; if they are defined as signed 16-bit integers, they are filled with -32768 and 32767 as boundary values; for enumeration type fields, the first and last enumeration values ​​in the enumeration definition are selected for filling. This operation verifies whether the device correctly handles extreme cases of type ranges, such as filling the cluster identifier field of the Zigbee protocol with the maximum value 0xFFFF, testing whether the device misinterprets it as a reserved value or triggers a special processing procedure. Illegal type padding intentionally violates field type definitions. For fields declared as numeric, it pads them with non-numeric strings, such as filling an integer field with the ASCII character sequence "AAAA". For fields declared as UTF-8 encoded strings, it pads them with illegal byte sequences, such as an invalid UTF-8 sequence containing consecutive 0xFF bytes. For fields declared as enumeration types, it pads them with values ​​not appearing in the enumeration definition, such as padding a field that only defines enumeration values ​​from 0x01 to 0x05 with 0xAB. In the protocol-level fields of MQTT CONNECT messages, illegal type padding can replace the expected single-byte value of 0x04 with the multi-byte string "MQTT". Observe whether the device parser generates a memory access exception or a state machine error due to the type mismatch.

[0059] Cross-field constraint violation operations specifically target combinations of fields with dependencies in the protocol message to violate consistency. Length reference violation operations identify the field sequence dependency graph. There are field pairs with length indication relationships, for the length field indicating the length of the subsequent load. and its corresponding actual load field Calculate the actual length of the load. Then modify the value of the length field. The offset Positive values ​​can cause the declared length to be too large, while negative values ​​can cause the declared length to be insufficient. For example, in the CoAP protocol's Option field processing, if the actual payload length is 128 bytes, modifying the length indicator field to declare 200 bytes will cause the parser to exceed the actual payload boundary when reading subsequent data, potentially reading uninitialized memory areas or data from other messages. Conversely, if the length field is modified to declare 80 bytes, the device may fail to correctly execute subsequent protocol logic due to payload truncation. Verification integrity violation operations target messages containing checksum or message authentication code fields. These operations modify the payload portion while intentionally keeping the original value of the checksum field unchanged, or recalculate the checksum but apply a bit-flipping operation to the calculation result.

[0060] For fields protected by CRC checksum, calculate the correct CRC value. Then, fill the validation field with... XOR mask It can be selected as a single-bit flip or multi-bit flip mode. In scenarios where the function code and data fields of the Modbus TCP protocol are protected by CRC16 check, keeping the CRC field unchanged after modifying the data field content can detect whether the device strictly performs the check. Devices that do not perform the check will accept the tampered data and may trigger unexpected control actions. Even if the device correctly rejects the message with failed check, it is also valuable to observe whether there are resource leaks or incomplete state rollback issues in its error handling process.

[0061] To achieve fine-grained vulnerability pattern tracing, each mutation operation, along with the generated mutation message, attaches a metadata tag containing a mutation type classification to the message. Messages generated by field truncation operations are labeled "TRUNCATE_BOUNDARY" for boundary value truncation mutations and "TRUNCATE_OVERFLOW" for out-of-bounds truncation mutations. Messages generated by field padding operations are labeled "FILL_TYPE_BOUNDARY" for valid type boundary padding mutations and "FILL_TYPE_INVALID" for invalid type padding mutations. Messages generated by cross-field constraint violation operations are labeled "VIOLATION_LENGTH_REF" for length reference violation mutations and "VIOLATION_CHECKSUM" for checksum integrity violation mutations. This tag information is stored along with the mutation message in the overwrite-boot mutation test message set. In this context, the structured representation is a composite data object containing attributes such as the message's binary content, mutation type label, source seed message identifier, and the offset of the field position where the mutation is applied. When a mutated message triggers a device crash or protocol state transition anomaly during subsequent fuzzing, reading the mutation type label of that message can immediately pinpoint the root cause of the anomaly: a boundary handling defect, missing type validation, or insufficient field correlation validation. This accelerates the process of summarizing and extracting vulnerability patterns.

[0062] In practical IoT device testing scenarios, for the Zigbee protocol commonly used in smart home devices, the cluster command identifier field in its application layer data frames was identified as a single-byte enumeration type. The protocol specification defines a valid enumeration value range of 16 command types, from 0x00 to 0x0F. An illegal type padding operation was performed on this field, setting its value to the undefined 0xAA value, while keeping the frame control field and frame sequence number field in the frame header unchanged. The generated mutated message was labeled as "FILL_TYPE_INVALID". After sending this message to the target Zigbee coordinator device, if the device does not perform whitelist verification of the enumeration value in its command distribution logic, it may execute the default undefined command processing branch. If this branch has a null pointer dereference problem due to insufficient code coverage, it will trigger a device firmware crash. The correspondence between this abnormal behavior and the mutated type label constitutes the key input for subsequent vulnerability feature extraction. A length reference violation operation was performed on the MACPayload field in the LoRaWAN protocol. The length of this field is indicated by the lower 4 bits of the FHDR.FCtrl field in the frame header. If the actual payload length is 32 bytes, the length indicator value is modified to declare 64 bytes. It was observed that the LoRaWAN gateway device generated a segmentation fault when attempting to parse data that exceeded the actual receive buffer length. This phenomenon is associated with the "VIOLATION_LENGTH_REF" label, revealing a defect in the device's length consistency check implementation.

[0063] By systematically incorporating the mutation results of each dimension of the above three types of structural mutation operations and their corresponding type labels into the coverage-guided mutation test message set, it is ensured that the fuzzing process can fully cover semantic constraint boundary conditions, type constraint violation scenarios, and field correlation destruction scenarios while exploring the protocol state space. This maximizes the probability of discovering various security vulnerabilities in the implementation of IoT protocols and provides a fully labeled abnormal sample dataset for subsequent vulnerability pattern recognition and dynamic defense strategy generation.

[0064] The steps for dynamically adjusting the network access control policy of the target IoT device based on the vulnerability feature fingerprint database include: For each vulnerability feature fingerprint in the vulnerability feature fingerprint database, a multi-dimensional matching rule is constructed, which covers protocol field offset, field value range threshold, and field combination association constraint. Real-time feature analysis is performed on the inbound messages received by the target IoT device, and the analysis results are compared with the multi-dimensional matching rules item by item. When the comparison results meet the matching conditions, the interception rule generation instruction is triggered. Based on the interception rule generation instruction, an interception rule update message is pushed to the network access control policy module. The interception rule update message includes the target protocol field identifier, the interception action type, and the rule effective timestamp. The vulnerability exploitation risk level is determined based on the historical triggering frequency of the vulnerability feature fingerprint, the severity of associated abnormal responses, and the exposure range of the protocol state transition path. Based on the vulnerability exploitation risk level, all currently effective interception rules are dynamically prioritized and sorted. Interception rules corresponding to high risk levels are scheduled to the first position in the priority matching queue, while interception rules corresponding to low risk levels are moved to the next position in sequence, thus completing continuous dynamic defense against the target IoT device.

[0065] When dynamically adjusting network access control policies for target IoT devices based on a vulnerability fingerprint database, the first step is to construct multi-dimensional matching rules for each vulnerability fingerprint in the database. Each vulnerability fingerprint records the protocol field combination features that trigger an abnormal response during fuzzing. These features include the absolute offset of the field causing the anomaly in the packet, the abnormal range of the field's value, and the combination association pattern between multiple fields. When constructing multi-dimensional matching rules, the byte-level offset is determined for each abnormal field. This offset is counted from the beginning of the message and precisely located to the first byte of the field. For the value range of the field that triggers the exception, the numerical interval causing the exception is extracted by analyzing the historical values ​​of that field in the exception message feature set. This range represents the sensitive numerical boundary that triggers the vulnerability. When the value of a field falls within this range, the field is considered to meet the matching condition.

[0066] For vulnerability features involving multiple field combinations, construct a set of field combination association constraints. Each constraint element in this set is represented as a triple. ,in and These represent the identifiers of the two fields involved in the combination. This indicates the logical constraint relationship between two fields, including numerical equality constraints, numerical difference constraints, or logical dependency constraints. For example, when a length indicator field... The declared value and the actual load field An exception is triggered when the number of bytes is inconsistent, then the constraint relationship... It can be represented as ,in This is the permissible offset error threshold. In this way, multi-dimensional matching rules can accurately capture complex multi-field combination vulnerability patterns.

[0067] Upon receiving an inbound message from a target IoT device, real-time feature parsing is performed. The feature parsing process first involves protocol-level decomposition of the message. Based on the protocol field structure defined in the protocol state machine, the original byte sequence of each field is extracted sequentially according to its offset. For each extracted field, its byte sequence is converted into its corresponding numerical representation. And record the actual offset of this field in the message. The parsed field offsets are then compared with the field offsets defined in the multidimensional matching rules. Perform a comparison, if If the condition is met, the process proceeds to the field value range matching stage. During the field value range matching stage, the following checks are performed: Does it meet the requirements? If the condition is met, the field is considered a successful match.

[0068] For matching rules involving field combination constraints, after completing single-field matching, the set of association constraints is further examined. All constraints in the set. For each constraint element in the set. Extract the corresponding fields from the message and Substitute the actual value of into the constraint relationship. Perform a logical judgment. Only when all fields participating in the combination satisfy their respective value range constraints, and the association constraints between all fields are met, will the combination be successful. The multidimensional matching rule is considered a complete match only when all results return true. When the comparison results meet the matching conditions, an interception rule generation instruction is immediately triggered, carrying the matched vulnerability feature fingerprint identifier. And the network 5-tuple information such as the source address and destination port of the current message.

[0069] Based on the interception rules, an instruction is generated and an interception rule update message is pushed to the network access control policy module. The data structure of this update message contains several core fields: target protocol identifier. This identifier specifies the protocol fields that need to be monitored. It includes the field name, field offset, and field length; and the type of interception action. Defines the handling method for matching messages, with options including discarding them directly, discarding them after logging, or downgrading them to a low-priority processing queue; rule effective timestamp. It records the precise moment when the blocking rule took effect, using nanosecond-level time precision to support accurate control in high-speed network environments. The blocking rule update message also includes the rule's validity period. This is used to define the automatic expiration time of the rule, preventing expired rules from occupying policy matching resources for an extended period. After receiving an update message, the network access control policy module inserts the new rule into the active rule table and performs an initial sorting based on rule priority.

[0070] When determining the exploit risk level of a vulnerability fingerprint that triggers a match, multiple risk dimensions must be considered comprehensively. First, the historical trigger frequency of the vulnerability fingerprint should be statistically analyzed. This frequency is measured within a statistical unit time window. The number of times the fingerprint is matched is calculated. A higher trigger frequency indicates a greater likelihood that the vulnerability feature will be exploited in a real attack. Next, the severity of the associated abnormal responses is assessed. The severity level is categorized based on the consequences of the abnormal response, including device crashes, denial of service, data breaches, or privilege escalation. Crash-related anomalies are assigned the highest severity level. Exceptions that only cause a slight delay or return an error code are assigned a lower rating. .

[0071] Scope of exposure of protocol state transition paths This is used to measure how many state nodes can trigger the vulnerability. By analyzing the state transition paths recorded in the abnormal message feature set, the number of predecessor state nodes that can reach the triggered abnormal state is counted. The wider the exposure, the more stages of protocol interaction an attacker can launch exploits, resulting in a broader attack surface. Exploitation Risk Level The calculation formula is derived by combining the above three dimensions. ,in , , The weight coefficients for the three dimensions are respectively, satisfying... The maximum value in the denominator is used for normalization to ensure comparability across dimensions. Based on the calculated... Numerical values ​​are used to classify risk levels into three levels: high, medium, and low. When it is judged as high risk, When it is determined to be medium risk, It was determined to be low risk at that time.

[0072] The network access control policy module dynamically prioritizes all currently active blocking rules based on their vulnerability exploitation risk level. Each element in the queue corresponds to an interception rule, and the sort key of the element is the risk level corresponding to that rule. When a new blocking rule is inserted into the queue, its insertion position is determined based on its risk level, ensuring that high-risk rules are always at the front of the queue. For rules with the same risk level, the insertion position is further determined by the rule's effective timestamp. A secondary sorting process is performed, prioritizing the matching of more recently generated rules. During packet matching, inbound packets are matched sequentially according to the priority queue. Once a rule is successfully matched, the corresponding interception action is immediately executed, and subsequent low-priority rules are no longer matched.

[0073] High-risk interception rules are prioritized and placed at the top of the priority matching queue, enabling interception at the earliest stage of packet entry into the device protocol stack, effectively reducing the probability of successful vulnerability exploitation. Low-risk interception rules are shifted sequentially to avoid excessive interference with normal business traffic. To maintain the dynamism of the priority queue, the risk level of the affected rules is recalculated whenever new abnormal packet characteristics are received or the trigger frequency of existing vulnerability fingerprints changes significantly. This triggers a queue reordering operation. The reordering operation uses an incremental update strategy, adjusting only the positions of rules whose risk levels have changed, thus avoiding the performance overhead of a full sort.

[0074] By continuously monitoring inbound packets and dynamically adjusting the priority of interception rules, continuous dynamic defense against target IoT devices is achieved. When a vulnerability fingerprint is detected as not triggering a match for a period of time, or when the corresponding vulnerability has been patched through a firmware update, the priority of that rule is automatically reduced or it is removed from the active rule table, freeing up policy matching resources. This dynamic access control policy adjustment mechanism based on a vulnerability fingerprint database can quickly respond to newly discovered vulnerability threats and flexibly adjust the defense focus according to the actual attack situation, ensuring device security while avoiding unnecessary disruption to normal communication.

[0075] The steps of generating instructions to push interception rule update messages to the network access control policy module based on the interception rules include: The target protocol field identifier carried by the interception rule generation instruction is parsed to identify the set of protocol fields that have association constraints with the target protocol field in the protocol semantic constraint model, and the set of protocol fields is included in the linkage detection scope of the interception rule. Based on the aforementioned linkage detection range, a joint matching condition for associated fields is constructed, the single-field interception condition is expanded into a multi-field composite interception condition, and the multi-field composite interception condition is encapsulated into the rule body field of the interception rule update message; Perform coverage redundancy detection on the effective interception rules, mark the existing rules that have an inclusion relationship with the matching coverage of the newly generated interception rules as redundant rules, and revoke the redundant rules from the network access control policy module; Set a rule effectiveness confirmation mechanism for the interception rule update message. Before the network access control policy module returns a rule effectiveness confirmation response, place the corresponding inbound message that triggers the match in a suspension processing queue to complete the continuous dynamic defense of the target Internet of Things device.

[0076] After receiving the interception rule generation instruction, first extract the target protocol field identifier carried in the instruction , which locates the key protocol field that triggers the abnormal response. Since there are often semantic dependency relationships between fields in the Internet of Things protocol, simply intercepting the target field may not cover attack variants that bypass detection by modifying related fields. Therefore, it is necessary to perform field dependency relationship parsing based on the previously constructed protocol semantic constraint model . Specifically, extract all directed edges with as nodes from the field temporal dependency graph, and identify the set of precursor fields that directly affect the value, and the set of successor fields[[ID=z16]] affected by the value. At the same time, retrieve the type constraint mapping table of protocol fields , and identify the associated fields that share the same check domain or length indication domain with . These fields form a strong association constraint with the target field during the message parsing process. Merge the above set of precursor fields, set of successor fields, and associated fields sharing the check domain to form an extended set of protocol fields , which defines the联动检测范围 of the interception rule.

[0077] For each field within the联动检测范围, it is necessary to extract the characteristic value range of the field when an exception is triggered from the abnormal message feature set. Assume that the field The value range in the abnormal message is , and at the same time record the byte offset of the field in the message structure. When constructing the combined matching condition for associated fields, use the form of a multi-field composite logical expression. For a pair of fields with a temporal dependency relationship, if the dependency relationship is defined as The value of must be calculated from the value, then the combined matching condition is expressed as the logical predicate , where represents the calculation function defined by the dependency relationship, It should be noted that the term "联动检测范围" in the original text seems to be a specific term in the relevant context but is not a common English expression. I have left it in Chinese for now as it's not clear what the exact intended English equivalent should be without more context. You may need to adjust it according to the actual situation.This is the allowable computational bias. This condition can capture malformed messages constructed by attackers by disrupting field dependencies. For the association between the length field and the payload field, the joint matching condition is constructed as follows: ,in This is the threshold for allowed length inconsistencies. This condition is used to detect attack packets whose length declaration does not match the actual payload.

[0078] Combine the joint matching conditions of all related fields into a multi-field composite interception condition. This composite condition is expressed in disjunctive normal form, i.e. ,in Indicates the first A combination of fields, For fields The corresponding single-field matching conditions or combined matching conditions between fields, This represents the total number of field combinations that need to be covered. This multi-layered logical structure allows the interception rules to simultaneously detect abnormal values ​​in a single field and the disruption of relationships between multiple fields. To ensure that network access control devices can efficiently execute this composite condition, the logical expression is converted into a byte-level matching pattern sequence. Specifically, during the conversion process, the value range judgment condition... In message offset Set byte mask at location Compared with expected value The combination of these, when the inbound message is at the offset byte sequence at the location and The result of the bitwise AND operation falls into Matching is triggered when the range is met. For determining the relationship between fields, temporary calculation logic is embedded in the network access control policy module. This logic extracts the current values ​​of multiple fields and performs relationship verification calculations.

[0079] Combine the above multi-field interception conditions When encapsulating an intercept rule update message, a message format conforming to the network access control device interface specification must be constructed. The intercept rule update message includes a rule body field, a priority field, and an effective timestamp field. and the validity period field The rule body fields use a nested structure. First, declare the rule type as a multi-field joint matching type, and then list the number of fields participating in the joint matching. For each participating field, a field identifier is given sequentially. Byte offset Matching mask Expected value range And logical relation operators between fields. Logical relation operators are encoded using an enumeration type, including... Indicates conjunction relationship, Indicates the disjunction relation, This indicates the dependencies that require computational verification. The priority field carries the information based on the vulnerability exploitation risk level. The calculated priority values ​​ensure that high-risk rules take effect first. (Effective timestamp) Set to the current system timestamp plus the rule push delay. Reserve time for the network access control policy module to load rules. Validity period field. Based on the persistent threat assessment results of vulnerability characteristics, a longer validity period is set for high-risk vulnerabilities whose exploit code has been disclosed; and a shorter validity period is set for low-risk vulnerabilities that exist only in specific versions to avoid policy accumulation.

[0080] Before pushing updated interception rule messages to the network access control policy module, a coverage redundancy check needs to be performed on the already effective interception rules. The purpose of redundancy checking is to prevent a large number of rules with overlapping functions from causing the access control policy library to bloat and reducing message matching efficiency. The detection method involves traversing the currently effective rule set. For each existing rule in the set Extract its matching conditions and the set of protocol fields covered Determine the matching conditions of the newly generated rule. Matching conditions with existing rules The logical inclusion relationship between them. If it exists... If the matching range of the new rule completely encompasses the matching range of the existing rule, then the existing rule is considered valid. This is a redundant rule. This is because when an inbound packet meets... Time will inevitably satisfy The new rules for blocking actions It can cover the defense requirements of existing rules. Existing rule identifiers that satisfy the inclusion relationship are added to the redundant rule set. It then sends a rule revocation command to the network access control policy module. The rule revocation command carries the identifier of the redundant rule. and the revocation timestamp The policy module is required to remove the corresponding rule from the effective rule table at a specified time.

[0081] To ensure the reliability of blocking rule updates, a rule activation confirmation mechanism is implemented when pushing blocking rule update messages. This mechanism uses a request-response model, and the blocking rule update message includes a confirmation request flag. and session identifier Upon receiving an update message, the network access control policy module first parses the matching conditions in the rule body fields and loads them into the internal matching engine. Then, it performs a rule consistency check to verify whether the new rule conflicts logically with the existing rule set. If the check passes, the policy module constructs a rule activation confirmation response message, which carries the session identifier. Effective status code and the actual effective timestamp of the rule Within the time window prior to receiving a confirmation response that the rule has taken effect, inbound packets that trigger the rule will be placed in a deferred processing queue. The deferred processing queue is based on the message arrival timestamp. Maintain queue order, for each message in the queue Record the target protocol field identifier that it matches. and the rule session identifier to be confirmed .

[0082] When a rule activation confirmation response and status code are received When the indicator rule has been successfully loaded, iterate through the deferred processing queue. For messages that match the session identifier The matching judgment is re-executed based on the values ​​of its fields. If the message meets the interception conditions of the already effective rule... If so, then the interception action will be executed. The message is discarded and a security event log is generated, which records the source address of the message. Values ​​of the target protocol field Matching vulnerability feature fingerprint identifier and interception timestamp If a message does not meet the interception criteria, it will be removed from the deferred queue and allowed to proceed to the next processing step via the network access control policy module. For cases where the rule confirmation timeout occurs (i.e., after the set timeout period),... If no confirmation response with a success status code is received within the specified time, the rule push retry mechanism will be triggered. The retry mechanism maintains a retry counter. Each time a retry occurs, the counter value is incremented and the waiting time is extended, employing an exponential backoff strategy. Calculate the waiting time for the next retry. The retry counter reaches its maximum value. If no confirmation response is received, a rule push failure alarm is sent to the system management module, and the messages in the deferred processing queue are matched according to the existing rule set to avoid the failure of defense capabilities due to rule push anomalies.

[0083] During the ongoing operation of the rules after they take effect, it is necessary to evaluate their actual defensive effectiveness. Evaluation metrics include rule trigger frequency. False interception rate and defense response latency The frequency of rule triggering is statistically analyzed within a time window. The number of inbound packets that meet the interception conditions is calculated. Frequently triggered rules indicate that the corresponding vulnerability fingerprints face continuous attack attempts in the actual network environment, requiring the rules to maintain a high priority. The false interception rate is calculated by manually auditing the intercepted packet samples, representing the number of legitimate business packets that are incorrectly intercepted. Divide by the total number of intercepted packets get When the false interception rate exceeds a preset threshold In such cases, the rules for matching are finely adjusted, reducing the risk of false blocking by tightening the range of field values ​​or adding additional pre-matching conditions. This also helps prevent response delays. Defined as the time difference between the arrival of an inbound packet at the network access control policy module and the completion of the interception action, this metric reflects the impact of the computational complexity of multi-field composite matching conditions on real-time defense performance. When the response latency exceeds the communication latency requirements of IoT devices, the composite matching conditions need to be optimized. For example, the logical AND operation of multiple fields can be converted into a single comparison operation of a bitmask, or parallel matching of key fields can be implemented at the hardware level.

[0084] Through the collaborative work of the aforementioned rule push process, redundancy detection mechanism, effectiveness confirmation mechanism, and deferred processing queue, the entire process of interception rule generation and effectiveness is controllable and manageable. A second aspect of this invention provides an intelligent testing system for IoT protocol vulnerabilities based on machine learning, comprising: The protocol modeling unit is used to model the protocol interaction behavior of the target IoT device, build the protocol state machine, extract the semantic constraint relationship of the protocol fields, and form a protocol semantic constraint model. The seed generation unit is used to generate an initial seed corpus based on the protocol semantic constraint model. The initial seed corpus contains a set of test messages covering each state transition path of the protocol state machine. The mutation testing unit is used to perform weighted mutations on the seed messages in the test message set based on the protocol state coverage feedback information, dynamically adjust the mutation weights of the seed messages according to the coverage frequency of each state transition path, prioritize the application of structural mutations to the seed messages corresponding to low coverage state paths, generate a coverage-guided mutation test message set, input the coverage-guided mutation test message set into the target IoT device to perform fuzz testing, record the messages that trigger abnormal responses and the corresponding state transition paths during the test, and form an abnormal message feature set. The feature extraction unit is used to extract vulnerability patterns from the abnormal message feature set, identify the protocol field combination features associated with the abnormal response, and construct a vulnerability feature fingerprint database. The dynamic defense unit is used to dynamically adjust the network access control policy of the target IoT device based on the vulnerability feature fingerprint database, trigger real-time interception rule updates for inbound packets that match the vulnerability feature fingerprint, and dynamically sort the priority of the interception rules according to the vulnerability exploitation risk level, so as to complete the continuous dynamic defense of the target IoT device.

[0085] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0086] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0087] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0088] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for intelligent testing of vulnerabilities of Internet of Things protocols based on machine learning, characterized in that, include: Model the protocol interaction behavior of the target IoT device, construct the protocol state machine, extract the semantic constraint relationship of the protocol fields, and form a protocol semantic constraint model; Based on the protocol semantic constraint model, an initial seed corpus is generated, which contains a set of test messages covering each state transition path of the protocol state machine. Based on the protocol state coverage feedback information, weighted mutations are performed on the seed messages in the test message set. The mutation weights of the seed messages are dynamically adjusted according to the coverage frequency of each state transition path. Structural mutations are applied to the seed messages corresponding to state paths with coverage frequencies lower than a preset frequency threshold first. A coverage-guided mutation test message set is generated. The coverage-guided mutation test message set is input into the target IoT device to perform fuzz testing. The messages that trigger abnormal responses and their corresponding state transition paths are recorded during the test to form an abnormal message feature set. Vulnerability patterns are extracted from the abnormal message feature set to identify protocol field combination features associated with abnormal responses and construct a vulnerability feature fingerprint database. Based on the vulnerability feature fingerprint database, the network access control policy of the target IoT device is dynamically adjusted. Real-time interception rule updates are triggered for inbound messages that match the vulnerability feature fingerprint, and the priority of the interception rules is dynamically sorted according to the vulnerability exploitation risk level.

2. The method of claim 1, wherein, The specific steps for modeling the protocol interaction behavior of the target IoT device, constructing a protocol state machine, extracting semantic constraint relationships of protocol fields, and forming a protocol semantic constraint model include: Using the session phase division results experienced by the target IoT device during the protocol interaction process as the basis for defining state nodes, the handshake phase, authentication phase, data transmission phase and session termination phase are respectively mapped to independent state nodes of the protocol state machine. The change in the value of the control field that triggers state switching in the protocol message is used as the state transition condition extraction mechanism. The correspondence between each control field and the state node is analyzed to form a set of state transition conditions. For the field type constraint dimension of the protocol fields, the data type definition of each field is identified and a field type constraint mapping table is established. For the value range constraint dimension of protocol fields, the value distribution range of each field in legal interaction messages is statistically analyzed to determine the upper and lower bounds of each field's value. For the time dependency constraint dimension of protocol fields, the constraint relationship between the value of the preceding message field and the value of the subsequent message field in the same state transition path is extracted to establish a field time dependency graph. The field type constraint mapping table, the value range constraint boundary, and the field time dependency graph are integrated to form the protocol semantic constraint model.

3. The method according to claim 1, characterized in that, Based on the aforementioned protocol semantic constraint model, the step of generating an initial seed corpus, wherein the initial seed corpus contains a set of test messages covering each state transition path of the protocol state machine, specifically includes: Based on the triggering frequency and state coverage contribution of each state transition path in the protocol state machine, the state transition paths are prioritized and the state transition paths with a triggering frequency lower than a preset frequency threshold and a state coverage contribution higher than a preset contribution threshold are marked as high priority paths. For high-priority paths, seed messages are selected from legal messages that satisfy all constraints in the protocol semantic constraint model according to the path coverage depth, and messages with a path coverage depth greater than a preset depth threshold are preferentially included in the initial seed corpus. The test message set is constructed using a layered construction approach. In the base layer, state trigger messages covering each state node are constructed. In the extension layer, boundary coverage messages are constructed based on the field constraint boundaries of high-priority paths. In the depth layer, a multi-step interaction message sequence across state transition paths is constructed. The messages at each layer are deduplicated, and messages that trigger the same state transition result in the protocol state machine as existing seed messages are removed, while messages that trigger different state transition results are retained to form the initial seed corpus.

4. The method according to claim 1, characterized in that, The steps of performing weighted mutation on the seed packets in the test packet set based on the protocol state coverage feedback information specifically include: The number of triggers for each state transition path in each round of fuzz testing is counted, and the real-time coverage frequency of each path is calculated as the ratio of the number of triggers to the total number of test rounds, forming a coverage frequency vector. Based on the coverage frequency vector, mutation weights are assigned to various sub-messages, and structural mutations are implemented on the length boundaries, type constraints, and inter-field dependencies of the protocol fields according to the protocol semantic constraint model. The structural mutations include three types of operations: field truncation, field padding, and cross-field constraint violation. The mutated message and the original seed message are weighted and sampled according to their respective mutation weights to form a cover-guided mutation test message set. After the cover-guided mutation test message set is input into the target IoT device, the device response status is collected in real time. Messages that trigger unexpected state transitions or abnormal response codes, along with their state transition paths, are recorded together to form the abnormal message feature set.

5. The method according to claim 4, characterized in that, The steps of weighting and sampling the mutated messages and the original seed messages according to their respective mutation weights to form a set of mutation test messages guided by coverage include: Field truncation operations are divided into two dimensions based on the length boundary constraints of protocol fields: boundary value truncation and out-of-bounds truncation. Boundary value truncation adjusts the field length to the minimum or maximum value specified in the protocol specification, while out-of-bounds truncation sets the field length to a value that exceeds the maximum value or is lower than the minimum value. Field filling operations are divided into two dimensions according to type constraints: legal type boundary filling and illegal type filling. Legal type boundary filling overwrites the field content with extreme value data that conforms to the field type constraints, while illegal type filling overwrites the field with data format that violates the field type definition. Cross-field constraint violation operations are divided into two dimensions based on the inter-field dependency relationship: length reference violation and check integrity violation. Length reference violation modifies the value of the length indicator field in the message to a value that is inconsistent with the actual payload length, while check integrity violation modifies the check value in the message containing the check field to a value that does not match the payload calculation result. The mutation results of each dimension of the above three types of operations are labeled with the corresponding mutation type tags and incorporated into the mutation test message set guided by the coverage.

6. The method according to claim 1, characterized in that, The steps for dynamically adjusting the network access control policy of the target IoT device based on the vulnerability fingerprint database specifically include: For each vulnerability feature fingerprint in the vulnerability feature fingerprint database, a multi-dimensional matching rule is constructed. The multi-dimensional matching rule covers protocol field offset, field value range threshold, and field combination association constraints. Real-time feature parsing is performed on the inbound packets received by the target IoT device. The parsing results are compared with the multi-dimensional matching rule item by item. When the comparison results meet the matching conditions, an interception rule generation instruction is triggered. Based on the interception rule generation instruction, an interception rule update message is pushed to the network access control policy module. The interception rule update message includes the target protocol field identifier, the interception action type, and the rule effective timestamp. The vulnerability exploitation risk level is determined for the vulnerability feature fingerprint that triggers the matching. The vulnerability exploitation risk level is calculated based on the historical trigger frequency of the vulnerability feature fingerprint, the severity of the associated abnormal response, and the exposure range of the protocol state transition path. Based on the vulnerability exploitation risk level, all currently effective interception rules are dynamically prioritized and sorted. Interception rules corresponding to high risk levels are scheduled to the first position in the priority matching queue, while interception rules corresponding to low risk levels are moved to the next position in sequence, thus completing continuous dynamic defense against the target IoT device.

7. The method according to claim 6, characterized in that, The specific steps of generating instructions to push interception rule update messages to the network access control policy module based on the interception rules include: The target protocol field identifier carried by the interception rule generation instruction is parsed to identify the set of protocol fields that have association constraints with the target protocol field in the protocol semantic constraint model, and the set of protocol fields is included in the linkage detection scope of the interception rule. Based on the aforementioned linkage detection range, a joint matching condition for associated fields is constructed, the single-field interception condition is expanded into a multi-field composite interception condition, and the multi-field composite interception condition is encapsulated into the rule body field of the interception rule update message; Perform coverage redundancy detection on the already effective blocking rules, mark existing rules that have an inclusion relationship with the matching coverage of the newly generated blocking rules as redundant rules, and revoke the redundant rules from the network access control policy module; A rule activation confirmation mechanism is set for the interception rule update message. Before the network access control policy module returns a rule activation confirmation response, the corresponding inbound message that triggers the matching is placed in a deferred processing queue to complete the continuous dynamic defense against the target IoT device.

8. A machine learning-based intelligent testing system for IoT protocol vulnerabilities, used to implement the method as described in any one of claims 1-7, characterized in that, include: The protocol modeling unit is used to model the protocol interaction behavior of the target IoT device, build the protocol state machine, extract the semantic constraint relationship of the protocol fields, and form a protocol semantic constraint model. The seed generation unit is used to generate an initial seed corpus based on the protocol semantic constraint model. The initial seed corpus contains a set of test messages covering each state transition path of the protocol state machine. The mutation testing unit is used to perform weighted mutations on the seed messages in the test message set based on the protocol state coverage feedback information, dynamically adjust the mutation weights of the seed messages according to the coverage frequency of each state transition path, prioritize the application of structural mutations to the seed messages corresponding to low coverage state paths, generate a coverage-guided mutation test message set, input the coverage-guided mutation test message set into the target IoT device to perform fuzz testing, record the messages that trigger abnormal responses and the corresponding state transition paths during the test, and form an abnormal message feature set. The feature extraction unit is used to extract vulnerability patterns from the abnormal message feature set, identify the protocol field combination features associated with the abnormal response, and construct a vulnerability feature fingerprint database. The dynamic defense unit is used to dynamically adjust the network access control policy of the target IoT device based on the vulnerability feature fingerprint database, trigger real-time interception rule updates for inbound packets that match the vulnerability feature fingerprint, and dynamically sort the priority of the interception rules according to the vulnerability exploitation risk level, so as to complete the continuous dynamic defense of the target IoT device.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images