A large model assisted peach framework communication protocol vulnerability automatic mining method

Abstract

The application discloses a large model assisted Peach framework communication protocol vulnerability automatic mining method, and particularly relates to the technical field of communication protocol automatic test, and is used for solving the problem that the existing large language model assisted generated Peach test model may be inconsistent with the actual field relationship and state semantics of the protocol, and it is difficult to accurately distinguish the model, the test environment and the responsibility source of the to-be-tested implementation when the test is abnormal. By constructing a protocol semantic closure containing field boundaries, dependency relationships, state transition slots and witness operations, the large language model is constrained to generate a Peach data model and a state model, and the candidate model is aligned and checked in combination with a sample message and a state path, so that a continuous closed loop is formed for model generation, test execution, responsibility determination and repair regression, thereby improving the consistency of the generated model and the actual semantics of the protocol, and providing a reliable semantic basis for the protocol robustness test result.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology for communication protocols, specifically a method for automated vulnerability discovery of communication protocols using a large model-assisted Peach framework. Background Technology

[0002] Communication protocol security testing is typically applied to the research, development, verification, and defect investigation of communication equipment, software protocol stacks, and protocol simulation instances. After obtaining authorization from the device under test (DUT) and establishing an isolated test environment, testers establish message data structures and communication interaction flows based on protocol documentation, interface definitions, sample interaction messages, and runtime status records. Then, they generate and execute test messages using protocol testing frameworks such as Peach, collecting the DUT's responses (normal responses, rejection responses, timeout responses, connection changes, and communication state changes) to test the protocol's ability to handle abnormal inputs and unexpected state transitions.

[0003] The Peach testing framework typically uses a data model to describe message fields, field types, and the length, quantity, offset, or validation relationships between fields, and a state model to describe the request sending, response receiving, and communication state transition processes. For communication protocols with many fields, complex dependencies, or multi-stage interactive states, the construction of the test model needs to combine protocol documentation, sample messages, and state records. With the application of large language models in text parsing and configuration content generation, they can be used to assist in identifying protocol fields and generating Peach data and state models, thereby providing support for the construction of test models for complex protocols.

[0004] However, the generated large language model has a certain degree of uncertainty. Even if the generated Peach test model passes the basic syntax check and is loaded normally by the test framework, its field boundaries, field types, the scope of the length field, the coverage of the validation fields, the conditions for enabling condition fields, the request-response correspondence, or the state transition conditions may still be inconsistent with the actual message structure and communication state of the protocol under test. Since the basic format check mainly examines the syntax, element references, and loading conditions of the model file, it is usually difficult to confirm whether the field dependencies and state actions in the model conform to the true semantics reflected in the protocol documentation and sample interactions.

[0005] In the above situations, the test framework may generate and send test messages under conditions that do not conform to the actual field relationships or state prerequisites of the protocol. When the object under test (DUT) exhibits a rejection response, timeout response, connection interruption, or state deviation, the anomaly may be caused by improper handling of test input by the DUT implementation, errors in field relationships or state configurations in the test model, or changes in the test link or the underlying connection state of the DUT. If defects are confirmed solely based on device responses, crash information, or execution logs, it is difficult to determine the starting point of the anomaly in test model generation, message sending, test environment, device response, or state transition, easily leading to confusion between test model errors and DUT implementation anomalies.

[0006] Furthermore, regression testing after defect fixing typically requires reusing the original test model, test inputs, and prior communication states. If the original anomaly lacks a stable correspondence with specific model versions, state paths, and execution evidence, the test conditions before and after the fix may change, making it difficult to determine whether the anomaly's disappearance was caused by protocol implementation fixes or by changes in the test model, execution environment, or communication state. Therefore, it is necessary to address the issue that while the Peach test model generated by the large language model is formally executable, the semantic correctness of the protocol and the source of anomaly responsibility are difficult to confirm, in order to improve the verifiability of regression results for communication protocol security defect detection and fixation. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides an automated vulnerability discovery method for communication protocols using a large model-assisted Peach framework, thereby resolving the problems mentioned in the background section.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for automated vulnerability discovery of communication protocols in the Peach framework assisted by a large model, comprising: S1. Based on the protocol documentation, sample messages, and status records, form a protocol semantic closure containing field boundaries, dependencies, state transition slots, and witness operations; S2. Input the protocol semantic closure into the large language model to generate the Peach data model and state model, and establish the mapping between model elements and closures and witness operations. S3. Call the candidate test model and witness operation respectively to process the same instance message and state path, align field relationships and state actions, form semantic constraint records and freeze the test model; S4. Based on semantic constraint records, determine the target deviation from the boundary, the linkage update set, and the protection witness set, and generate the comparison action and test action for the same state slot; S5. Perform comparison and test actions to align rendered messages, sent messages, environmental status, device response, and communication status, and determine the first inconsistency level. S6. Based on the first level of inconsistency and the results of the control action, form the results of model responsibility, environmental responsibility or the responsibility to be tested, solidify the test evidence version and perform remedial regression.

[0009] Furthermore, the processing of protocol data, sample messages, and status records includes: Sample messages are grouped according to message direction, interaction sequence, and communication session. Field definitions and status descriptions in the protocol documentation are associated with the corresponding sample messages and status records to form protocol interaction records with source location.

[0010] Furthermore, based on protocol interaction records, field boundaries and dependencies are formed, including: The start and end positions of each field are determined based on the field order, fixed identifiers, and sample values. The pointing relationships, scope of application, and update order between the length field, validation field, condition field, and associated field segments are established.

[0011] Furthermore, state transition slots are formed based on protocol interaction records, including: Record the preceding communication status, allowed request actions, allowed response actions, response waiting range, and subsequent communication status according to a single request-response process, and configure the status records used to confirm the preceding and subsequent communication statuses as corresponding witness operations.

[0012] Furthermore, generating the Peach data model and state model includes: Field boundaries and dependencies are mapped to Peach data elements and element relationships. State transition slots are mapped to Peach states, sending actions, receiving actions, and state transitions, while preserving the correspondence between each model element and the protocol semantic closure.

[0013] Furthermore, the verification of candidate test models includes: Examine the syntax, element references, and loading results of the Peach model. Parse and reconstruct the same instance message and rehearse the same state path using candidate test models and witness operations respectively. Perform consistency alignment on field boundaries, dependency values, request-response order, and state acceptance results.

[0014] Furthermore, when performing control and test actions, Peach rendering messages, actual sent messages, device responses, connection status, communication status before and after execution, and environmental status are collected in a unified time sequence, and the collected results are associated with the corresponding test model, state transition slot, and action type to form anomaly evidence records.

[0015] Furthermore, the consequences that result in liability include: When a rendered message does not meet the semantic constraints, a model responsibility result is generated. When the sent message and the rendered message are inconsistent, or when the environmental state changes, an environmental responsibility result is formed. When the control action is normally accepted and the abnormality of the test action first appears in the device response or communication status, the result of the responsibility for the implementation of the test is formed.

[0016] Furthermore, defect identification and remediation regression analysis includes: The test actions that lead to the achievement of the responsibility for the test are repeatedly executed, and the defect confirmation result is formed based on the repeated occurrence of the same anomaly and the first inconsistency level; After the protocol is repaired, the test evidence version is called to restore the same state migration slot and the control and test actions are re-executed to form the repair regression results.

[0017] Compared with the prior art, the present invention has the following beneficial effects: 1. By unifying protocol data, sample messages, and state records into a protocol semantic closure that includes field boundaries, dependencies, state transition slots, and witness operations, and using this protocol semantic closure to constrain the large language model to generate the Peach data model and state model, and then using candidate test models and witness operations to align and verify the same sample messages and state paths, the model generation, semantic verification, test action construction, test execution, responsibility determination, and remediation regression are formed in a continuous processing chain according to a predetermined order. This reduces the possibility that the generated model can be loaded and executed but cannot accurately express the protocol field relationships and state semantics, and provides a processing basis corresponding to the protocol semantics for the protocol robustness test results.

[0018] 2. By determining the target deviation boundary, linkage update set, and protection witness set based on semantic constraint records, and generating control actions and test actions that only differ from the target object under the same state slot, the changes in fields, updates of dependent fields, initial states, and non-target semantics are kept under control. This reduces the interference caused by unsynchronized length associations, incorrect verification relationships, different state starting points, or changes in other non-target variables on the test results, and establishes a clearer correspondence between abnormal responses and controlled test conditions.

[0019] 3. By sequentially aligning model parameters, rendered messages, sent messages, environmental status, device response, and communication status, the first inconsistency level is determined. Combined with the comparison action results, model responsibility, environmental responsibility, or responsibility of the implementation under test is formed. At the same time, the protocol semantic closure version, frozen test model version, execution record, and responsibility results are solidified into interrelated test evidence versions. This enables the differentiation of the source of abnormal results and supports regression verification after model correction, environment recovery, or repair of the implementation under test, thereby improving the traceability and verifiability of the testing process and its conclusions. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the test environment structure for the authorization isolation protocol; Figure 2 A schematic diagram illustrating the overall process of using large language models to assist in Peach protocol testing. Figure 3 A schematic diagram illustrating the semantic closure of the protocol data, field relationships, and status records; Figure 4 A schematic diagram illustrating the generation and element mapping of the Peach test model for protocol semantic closure constraints. Figure 5 This is a schematic diagram illustrating the semantic verification of the candidate test model and the witness operation in a dual-path manner. Figure 6 A schematic diagram is generated for target deviation from the boundary, linkage update, and actions of slots in the same state; Figure 7 This is a schematic diagram illustrating the execution of tests and layer alignment for slots in the same state; Figure 8 This is a schematic diagram of the first inconsistency level responsibility determination and repair regression loop. Detailed Implementation

[0021] 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.

[0022] Example: Combined with Appendix Figures 1-8 This embodiment provides an automated vulnerability discovery method for communication protocols using the Peach framework with a large model, including: In this embodiment, the method operates in a protocol testing environment isolated from the production network. This testing environment can consist of a physical device under test (DUT), a protocol emulation device, or an authorized implementation of the DUT, and must include at least a protocol data storage terminal, a large language model processing terminal, a test model building terminal, a test execution terminal, and a test evidence storage terminal. Each terminal establishes a communication connection through an independent test network, which is physically or logically isolated from the production network. The test execution terminal sends test messages to the corresponding DUT, protocol emulation interface, or local loopback interface based on pre-configured test object identifiers, communication addresses, and interface information, and synchronously records message rendering, message sending, environment status, device response, and communication status. Protocol data, sample messages, test models, test actions, and execution evidence are stored separately according to test items and associated using project identifiers, protocol version identifiers, model version identifiers, execution batch identifiers, and evidence version identifiers to ensure that the data source, model generation process, test execution process, and result evidence during the protocol testing process are mutually corresponding and traceable.

[0023] S1. Based on the protocol documentation, sample messages, and status records, form a protocol semantic closure containing field boundaries, dependencies, state transition slots, and witness operations. The specific implementation is as follows: The implementation entity for this step is the protocol semantic processing module, which can run on a local server, test workstation, or containerized computing node in an isolated test environment. Its inputs include protocol documentation, sample messages, and status records. Protocol documentation originates from the formal technical documentation of the protocol under test, the applicant's internal interface specifications, authorized device communication specifications, or pre-defined field definition tables for the test project. Minimum required content includes message direction, message type, field order, field length representation, field dependencies, and allowed protocol states. Sample messages originate from legitimate communication records collected by the applicant during normal business processes, simulation processes, or device self-test processes. They must include at least one correctly parsed request sample and corresponding records of normal response, rejection response, timeout response, or status deviation response. Status records originate from test device logs, simulation protocol stack logs, or status operation records generated by testers according to normal business sequences. They must include at least the status name, entry condition, triggering operation, execution result, and subsequent status.

[0024] The protocol semantic processing module first generates a source identifier and a content digest for each piece of input data. The source identifier includes at least the data type, data version, acquisition method, and the test project to which it belongs. The content digest is used to determine whether the same data has changed in subsequent steps. For sample messages containing sensitive business data, the business data fields are first anonymized, retaining only the structural relationship between the message type field, length field, sequence field, business data field, and verification field. Real user identifiers, account identifiers, keys, authentication credentials, or production control parameters are not retained.

[0025] The protocol semantic processing module establishes a set of field slots according to the field arrangement order in the message. Each field slot records at least the field slot identifier, field name, field category, start boundary formation rule, end boundary formation rule, length source, value type, preceding dependent fields, subsequent associated fields, and exception handling method. Field categories can be abstractly set as message type fields, length fields, sequence fields, business data fields, and validation fields. Field boundaries are not required to be represented solely by fixed byte positions; they can also be dynamically determined by the length of preceding fields, message type, or state conditions. For example, when the end boundary of a business data field is given by the length field, the length field is set as the boundary dependent field of the business data field; when the calculation scope of the validation field covers the message type field, length field, sequence field, and business data field, these fields are set as the content dependent fields of the validation field.

[0026] After forming the field slot set, the protocol semantic organization module establishes a field dependency set. Each field dependency includes at least a dependency identifier, source field slot, target field slot, dependency type, dependency direction, and dependency conditions. Dependency types include length dependency, order dependency, value dependency, validation dependency, and state dependency. For example, when a change in the value of the length field requires a linked adjustment of the business data field boundary, the length dependency from the length field to the business data field is recorded; when the message type field determines the structure of subsequent business data fields, the value dependency from the message type field to the business data field is recorded; when the validation field is recalculated based on the preceding field, the validation dependency from the preceding field to the validation field is recorded. For dependencies not explicitly stated in the protocol documentation but stably observable from multiple sample messages, they are only marked as pending confirmation dependencies and are not directly used as mandatory constraints after freezing.

[0027] The protocol semantic processing module establishes a set of state transition slots based on state records. Each state transition slot includes at least a slot identifier, current state, preceding states allowed to enter this state, allowed operations to be performed in this state, message type required for the operation, expected response category, target state upon success, and hold or rollback state upon failure. State names use unified names within the test project and do not directly rely on non-unified text in device logs. For example, multiple similar expressions in the device logs indicating established connection, prepared session, and executable service can be uniformly mapped to a single test state slot, but the mapping relationship between the original log expressions and the unified state slot should be preserved.

[0028] Subsequently, the protocol semantic processing module extracts witness operations from protocol documentation and status records. A witness operation is a normal operation that verifies the validity of field relationships or state transitions without altering the implementation under test or performing unauthorized operations. Each witness operation includes at least a witness operation identifier, applicable state slot, input message template, prerequisite state conditions, execution method, expected response category, expected target state, and witness object. The witness object can be a field boundary, a field dependency, or a state transition slot. For example, executing a normal request in a specified state with a valid sample message and confirming that the device returns a normal response and the state enters the target state can be considered a witness operation for that state transition slot; re-rendering a sample message without changing the business meaning and confirming that the length field and validation field are updated consistently with the business data fields can be considered a witness operation for a field dependency.

[0029] The protocol semantic organization module writes the field slot set, field dependency set, state transition slot set, witness operation set, and source mapping of input data into the protocol semantic closure. The protocol semantic closure includes at least a closure identifier, closure version, protocol version, data summary set, field slot set, field dependency set, state transition slot set, witness operation set, and pending items set. The pending items set is used to store inconsistencies between data, insufficient sample quantity, missing state records, or uncertain dependencies.

[0030] When different protocol documents conflict on the same field boundary, the protocol semantic processing module does not directly select any result. Instead, it generates a conflict record based on the document version, sample message, and state record. The conflict record must include at least the conflicting object, different candidate interpretations, the source of each interpretation, and whether an executable witness operation exists. Before the conflict is resolved, the corresponding field slot must not be included in the freeze constraints of subsequent test models. When a sample message cannot be parsed, the parsing failure location, the boundary rules used, and the reason for the failure are written to the exception record; field dependencies are not directly generated from that sample message. When a state record lacks a preceding or subsequent state, the corresponding state transition slot is marked as an incomplete slot, which can only be used for model generation candidates and not directly for test action execution.

[0031] This step outputs a protocol semantic closure. The protocol semantic closure is passed to step S2 via its closure identifier and version. The large language model caller only invokes the field slots, dependencies, state transition slots, and witness operations that have undergone integrity verification. This organizes the semantic content scattered across protocol documents, sample messages, and state logs into a unified data structure with field boundaries, dependency directions, state conditions, and verification criteria, reducing field omissions, state mismatches, and fictitious relationships that occur when directly generating test models based solely on natural language documents.

[0032] S2. Input the protocol semantic closure into the large language model to generate the Peach data model and state model, and establish a mapping between model elements and closures and witness operations. The specific implementation is as follows: The main entity responsible for this step is the test model generation module, which runs on both the large language model caller and the test model builder within an isolated testing environment. The large language model can be a model deployed on a local server or a dedicated model service approved by the applicant and with data anonymized. The input data is the protocol semantic closure formed in step S1, and its minimum required content includes a set of field slots, a set of field dependencies, a set of state transition slots, a set of witness operations, the protocol version, and the closure version.

[0033] Before invoking the large language model, the test model generation module converts the protocol semantic closure into a structured model generation request. The model generation request is divided into at least three areas: a data model generation area, a state model generation area, and a mapping generation area. The data model generation area contains the field order, field categories, field boundary rules, field dependencies, and allowed abstract value ranges. The state model generation area contains state transition slots, allowed operations in each state, input message types, expected response categories, and target states. The mapping generation area requires the large language model to return the corresponding field slot identifier, dependency identifier, state transition slot identifier, or witness operation identifier for each generated model element.

[0034] The test model generation module imposes constraints on the content of the input large language model. First, the large language model is only allowed to use field names, state names, and operation names already existing in the protocol semantic closure; it is not allowed to add real accounts, authentication information, remote control objects, or unauthorized operations. Second, it only uses abstract field types and test placeholder values ​​for the message content, and does not generate attack payloads that can be directly applied to third-party systems. Third, the large language model is required to output the Peach data model, Peach state model, and model element mapping table according to a preset structure; it does not accept unparseable free text as the final model. Fourth, for unresolved issues, conflicting fields, and incomplete state slots in the protocol semantic closure, the large language model is required to mark them as objects awaiting confirmation; it is not allowed to automatically select one of them for interpretation and write it into the frozen model.

[0035] The Peach data model describes the data structure of test messages and includes at least a data model identifier, model version, field element list, field arrangement relationship, field boundary relationship, field dependency relationship, and rendering entry point. Each field element includes at least a model element identifier, corresponding field slot identifier, field category, data representation method, length source, default sample value, and dependency update rule. The message type field is used to select the corresponding data model branch, the length field records the boundary length of related business data fields, the sequence field maintains the consistency of message order within the same test process, business data fields use anonymized placeholder content, and the validation field is updated according to the validation dependencies explicitly recorded in the protocol semantic closure.

[0036] The Peach state model describes the states and actions during test execution, and includes at least a state model identifier, a set of state nodes, a set of actions, a set of state transitions, and rules for handling exception responses. Each state node corresponds to at least one state transition slot, and each action records at least the action identifier, the current state, the data model invoked, the sending or receiving direction, the expected response category, the success target state, and the failure handling method. Normal responses, rejection responses, timeout responses, and state deviation responses are mapped to their corresponding state handling branches, but it is not assumed in the state model that the device under test necessarily has a defect.

[0037] After generating the Peach data model and state model, the test model generation module establishes a model element mapping table. The model element mapping table includes at least a mapping identifier, a model element identifier, a model element type, a closure object identifier, a witness operation identifier, and the mapping basis. Model element types include field elements, field relationships, state nodes, state actions, and state transitions. The closure object identifier points to a field slot, field dependency, or state transition slot, and the witness operation identifier points to the witness operation that can verify the model element. One model element can correspond to multiple closure objects, and one closure object can correspond to multiple model elements, but each mapping should retain a clear mapping direction and version information.

[0038] The test model generation module performs syntax and semantic checks on the output of the large language model. Syntax checks determine whether the data model, state model, and mapping table meet the preset structure, and whether there are duplicate identifiers, missing references, or unresolved elements. Semantic checks determine whether the field order conforms to the protocol's semantic closure, whether length dependencies and validation dependencies are preserved, whether state actions are allowed in their corresponding state transition slots, and whether each key model element has at least one closure mapping or witness operation mapping.

[0039] When the large language model output lacks model element mappings, the output is not used directly. Instead, the corresponding part is regenerated carrying the identifier of the missing closure object. If the mapping is still missing after regeneration, the corresponding model element is deleted or marked as an unconfirmed element. When the large language model generates fields, states, or operations that do not exist in the protocol semantic closure, the object is written into the out-of-bounds generation record and removed from the candidate test models. If the message types referenced by the data model and the state model are inconsistent, the references are re-established based on the field slots and state transition slots in the closure. If automatic recovery is not possible, the candidate model is stopped and proceeds to step S3.

[0040] This step outputs candidate test models. A candidate test model includes at least a candidate model identifier, a protocol semantic closure version, a Peach data model, a Peach state model, a model element mapping table, generated verification results, and a set of unconfirmed elements. The candidate test model, along with its corresponding witness operation, is passed to step S3 via the candidate model identifier. This ensures that the output of the large language model is no longer an independent script or model file lacking source constraints, but rather a candidate test model that is item-by-item associated with the protocol semantic closure and witness operation, and can be subsequently verified and traced.

[0041] S3. Call the candidate test model and witness operation respectively to process the same instance message and state path, align field relationships and state actions, form semantic constraint records, and freeze the test model. The specific implementation is as follows: The main entity responsible for this step is the model semantic verification module, which runs on both the test model building end and the test execution end. Input data includes the candidate test model formed in step S2, the witness operation in step S1, sample messages, and the state paths corresponding to the sample messages. The minimum required content includes the candidate model identifier, Peach data model, Peach state model, model element mapping table, at least one complete sample message, the starting state corresponding to the sample message, the execution action, and the expected target state.

[0042] The model semantic verification module establishes two independent processing paths for the same sample message. The first processing path is the candidate test model processing path. The Peach data model parses the sample message, extracting the message type, length, sequence, business data, and verification fields. Then, it executes the corresponding state actions according to the Peach state model and obtains the candidate model processing result. The second processing path is the witness operation processing path. The witness operation processes the same sample message and state path according to the field relationships and state conditions recorded in the protocol semantic closure, obtaining the witness processing result.

[0043] The candidate model processing results should include at least field parsing results, field boundary results, field dependency calculation results, message re-rendering results, action invocation order, state transition results, and response classification. The witness processing results should include at least the field boundaries confirmed by the witness operation, inter-field dependencies, allowed actions, initial state, target state, and expected response classification. Both processing paths should use the same instance message digest, the same state path identifier, and the same execution batch identifier to avoid misalignment due to different inputs.

[0044] The model semantic verification module first aligns field relationships. Field relationship alignment includes at least field quantity alignment, field order alignment, field boundary alignment, length dependency alignment, and validation dependency alignment. For fixed-length fields, it compares whether the start and end positions parsed by the candidate model are consistent with the witness operation; for dynamic-length fields, it compares whether the candidate model correctly determines the boundaries of the business data field based on the length field or the preceding field; for validation fields, it compares whether the candidate model updates according to the dependency scope in the protocol semantic closure when re-rendering the message. The specific content of the business data field is not a necessary condition for semantic consistency, but its length, position, and dependency relationship should be consistent.

[0045] Subsequently, the model semantic verification module aligns state actions. State action alignment includes at least the initial state, action name, action invocation order, data model invoked, expected response classification, successful target state, and exception handling state. If a candidate state model invokes an action not permitted by the protocol semantic closure in a certain state, it is recorded as a state action out of bounds; if a candidate state model omits necessary preceding states and directly enters a subsequent state, it is recorded as a missing state transition; if a candidate state model misjudges a rejection response as a normal response, or incorrectly enters the successful target state after a timeout response, it is recorded as inconsistent response handling.

[0046] The model semantic verification module writes each alignment result to a semantic constraint record. The semantic constraint record includes at least a constraint record identifier, candidate model identifier, closure version, sample message summary, state path identifier, field constraint set, state constraint set, witness operation reference, alignment conclusion, and pending difference set. The field constraint set records the confirmed field order, boundary rules, dependencies, and update methods; the state constraint set records the confirmed state preconditions, action order, response classification, and transition results; and the pending difference set stores differences that cannot be determined through existing samples and witness operations.

[0047] For discrepancies that can be directly corrected through field mapping or state mapping, the model semantic verification module performs limited corrections on the candidate test models. For example, if a candidate data model omits the length dependency from the length field to the business data field, the corresponding dependency is added based on the model element mapping table; if a candidate state model enters an erroneous target state after rejecting a response, it is adjusted to either a hold state or a rollback state based on the state transition slot. Each correction records the content before modification, the content after modification, the basis for modification, and the corresponding witness operation. Empirical corrections without closure-based basis are not allowed.

[0048] When a candidate test model fails to correctly parse normal sample messages, fails to complete a normal state path, or has unavoidable critical differences with the witness operation, the candidate test model is not frozen and returns to step S2 for regeneration. Critical differences include incorrect message type field identification, dynamic boundary calculation errors, missing necessary field dependencies, incorrect state action order, and incorrect target state. Non-critical differences that do not affect the current test objective can be retained in the pending differences set, but must not be used as mutable objects for subsequent test actions.

[0049] Candidate test models that meet the freezing conditions are written into the frozen test model. The frozen test model includes at least a frozen model identifier, a basic candidate model identifier, a protocol semantic closure version, a Peach data model version, a Peach state model version, a semantic constraint record identifier, a set of allowed change elements, a set of prohibited change elements, and a freezing time. After freezing, the model file itself is no longer directly modified in step S4, and the test actions generated in step S4 can only call the allowed change elements through a predefined variable parameter interface.

[0050] This step outputs semantic constraint records and a frozen test model. The semantic constraint records are used in step S4 to determine the target deviation boundary, the linkage update set, and the protection witness set. The frozen test model is used to generate and execute control actions and test actions. Thus, the large language model's generated results are verified through a dual-path approach using normal examples and witness operations, preventing the direct use of syntactically executable models with errors in field relationships or state logic for testing the device under test.

[0051] S4. Based on semantic constraint records, determine the target deviation from the boundary, the linkage update set, and the protection witness set, and generate the comparison action and test action for the slot with the same state. The specific implementation is as follows: The main entity responsible for this step is the test action generation module, which runs on the test model building end. Input data includes the semantic constraint records generated in step S3, the frozen test model, and the field slots or state transition slots to be tested. Minimum required content includes confirmed field boundaries, field dependencies, state constraints, the set of elements allowed to be changed, the set of elements prohibited from being changed, and the corresponding witness operations.

[0052] The test action generation module first determines the target deviation boundary. The target deviation boundary refers to a controlled deviation position set to verify the ability of the implementation under test to handle field anomalies, dependency inconsistencies, or state action inconsistencies, without changing the scope of the test object or introducing unauthorized operations. The target deviation boundary includes at least the target object identifier, target object type, baseline value or baseline relationship, allowed deviation method, deviation limit, and applicable state slot. The target object type can be a field value, field boundary, field dependency relationship, or state action condition.

[0053] For target objects of the field value type, only select baseline and boundary values ​​within the abstract value range allowed by protocol semantic closure and semantic constraint records, and do not fill in real accounts, authentication credentials, or production control instructions. For target objects of the field boundary type, in an isolated environment, verify whether the implementation under test returns a rejection response, timeout response, or state deviation response when the length field and business data field lengths are inconsistent, but the test content remains placeholder data without business harm. For target objects of the field dependency type, verify whether the length field or validation field is updated in accordance with the dependency relationship after a controlled change in the business data field. For target objects of the state action type, only allow verification of action preconditions within authorized test state slots, and do not perform unauthorized access, identity bypass, or production device control.

[0054] After determining that the target deviates from the boundary, the test action generation module determines the linked update set based on the field dependency set. The linked update set includes at least the target object, directly dependent objects, indirectly dependent objects, update order, update rules, and objects not updated. For example, when the length of a business data field changes, the length field and the validation field belong to the linked update set; when the sequence field is only used to record message order and does not depend on the business data field, it is not included in the corresponding linked update set. The linked update set distinguishes between "tests that only change the target object to form structural inconsistencies" and "tests that change the target object and synchronously update dependent objects to form consistency comparisons," avoiding misjudging message errors caused by the model itself not updating dependent fields as anomalies in the tested implementation.

[0055] The test action generation module also determines the protection witness set based on semantic constraint records. The protection witness set ensures that the target test action does not violate confirmed semantics unrelated to the current target. Each protection witness includes at least the witness object, witness operation identifier, protection condition, verification timing, and failure handling method. Message type fields unrelated to the target deviation boundary, status start point, necessary preceding actions, and normal exit actions are typically included in the protection witness set. If any witness condition in the protection witness set is not met, the current test action must not proceed to the execution phase.

[0056] Under the same state transition slot, the test action generation module generates a set of control actions and test actions. Control actions and test actions share the same starting state, message type, business operation purpose, execution environment, and target device, differing only in the object corresponding to the target deviation boundary. Control actions use the baseline field relationships and baseline state actions in the frozen test model; test actions change the target object according to the target deviation boundary and select whether to update the linked update set based on the test type.

[0057] Each control action includes at least an action identifier, a frozen model identifier, a state slot identifier, a data model identifier, a set of baseline parameters, a set of linked updates, a set of protection witnesses, and an expected response category. Each test action includes at least a test action identifier, a corresponding control action identifier, a target deviation boundary, deviation parameters, a linked update strategy, a set of protection witnesses, a stop condition, and an allowed response category. The allowed response category uses only normal responses, rejection responses, timeout responses, and state deviation responses to record the defensive processing results of the implementation under test, without presupposing that any particular response necessarily constitutes a vulnerability.

[0058] The test action generation module performs static verification after the action is generated. Static verification includes state slot consistency verification, target object uniqueness verification, linkage update integrity verification, protection witness executability verification, and address authorization verification. Execution is not allowed if the comparison action and the test action do not belong to the same state slot; if a single test action changes multiple independent target objects whose responsibility cannot be distinguished, it should be split into multiple test batches; if a protection witness lacks a corresponding witness operation, the process should return to step S3 to supplement semantic constraints; if the address to be tested is not in the authorization list, the current execution should be terminated.

[0059] When the target deviates from the boundary and the test state may not be able to recover normally, the test action generation module adds a recovery action to the test action. The recovery action only includes resetting the simulation session, restoring the local snapshot, re-entering the legal start state, or restarting the authorized test device, and does not include bypassing authentication or forcibly modifying the state of third-party devices.

[0060] This step outputs control action records and test action records. Control and test actions are passed to step S5 via a shared status slot identifier, action group identifier, and execution batch identifier. Target deviation from the boundary, linkage update set, and protection witness set simultaneously serve as the basis for step S5 to determine the source of message differences and the effectiveness of execution. This enables the formation of control tests with a single controlled variable under the same state conditions, reducing interference from asynchronous field dependencies, different state starting points, or inconsistent test environments on result judgment.

[0061] S5. Perform comparison and test actions to align rendered messages, sent messages, environmental status, device response, and communication status, and determine the first inconsistency level. The specific implementation is as follows: The main entity responsible for this step is the test execution and alignment module, which runs on the test execution end. Input data includes the control actions, test actions, frozen test models, protection witness sets, and authorized test environment configurations generated in step S4. Minimum required information includes action group identifiers, status slot identifiers, target device or simulation implementation identifiers, authorized addresses, rendering entry points, execution order, stop conditions, and recovery actions.

[0062] The test execution and alignment module establishes an execution context before execution. The execution context includes at least the execution batch identifier, action group identifier, test environment version, implementation version under test, frozen model version, protocol semantic closure version, time base, state snapshot identifier, and network interface identifier. Comparison actions and test actions use the same execution context or two equivalent execution contexts formed by copying from the same base snapshot to ensure comparability of environmental conditions.

[0063] The test execution and alignment module first performs the pre-witness operation in the protection witness set to confirm that the implementation under test is in the target state slot, that normal sample messages can receive the expected response, and that the test network, simulation interface, and evidence collection functions are normal. If the pre-witness operation fails, the comparison action and test action are not executed; instead, the failure is attributed to an environment preparation anomaly or a model preparation anomaly.

[0064] After the pre-witness passes, the test execution and alignment module performs a comparison action. The frozen test model generates a rendered message based on the baseline parameters in the comparison action. The rendered message records at least the field element values, field boundaries, field dependency calculation results, a complete message summary, and the model rendering log. The rendered message is converted into a sent message via the test sending interface. The sent message records at least the actual sent byte summary, sending interface, sending time, target address, and sending result. The test execution and alignment module synchronously records the environment state before sending, the environment state after sending, the device response, and the communication status.

[0065] Subsequently, after restoring to the same state slot or re-establishing the state from the same base snapshot, the test execution and alignment module performs test actions and records the corresponding rendering messages, sent messages, environmental status, device response, and communication status in the same manner. The records of the comparison actions and test actions are associated through action group identifiers and relative time positions.

[0066] The environment status includes at least the running status of the implementation under test, the test interface status, the session status, the resource usage status, and the recovery action execution status. Device responses include at least the response category, response message digest, response time, response message type, and the device status after the response. Communication status includes at least the connection establishment status, transmission completion status, reception completion status, timeout status, and connection termination status. All device responses are only categorized as normal responses, rejection responses, timeout responses, and status deviation responses; no speculation is made regarding reasons for which there is no direct evidence within the device.

[0067] The test execution and alignment module aligns the execution records of the comparison actions and test actions according to a preset hierarchical order. The hierarchy includes, in turn, the model parameter layer, the message rendering layer, the message sending layer, the environment state layer, the device response layer, and the communication state layer.

[0068] The model parameter layer is used to verify whether the differences between the control action and the test action exist only in the target deviation boundary and its specified linked update object. If the protected witness object or non-target parameters change, inconsistencies will occur in the model parameter layer.

[0069] The message rendering layer is used to confirm whether the frozen test model generates the expected message according to the action parameters. The test execution and alignment module compares the rendering results of field boundaries, field arrangement, length field, sequence field, business data field, and validation field to determine whether the actual rendering difference is consistent with the target deviation boundary and the linked update set.

[0070] The message sending layer is used to compare whether the rendered message and the actual sent message are consistent. If the rendered message is correct, but the sending interface is truncated, appended, has a different encoding, or fails to complete the transmission, the first inconsistency may occur at the message sending layer.

[0071] The environment state layer is used to verify whether the implementation version under test, initial state, network interface, session state, and basic resource state remain comparable when performing comparison and test actions. If the device has deviated from the target state slot before the test action is executed, or if the test interface malfunctions, the first inconsistency may occur at the environment state layer.

[0072] The device response layer is used to compare the response classification, response message summary, response time, and post-response status of the control action results and the test action results. When the device returns a normal response to the control action but returns a rejection response, timeout response, or status deviation response to the test action, only the response difference is recorded, and it is not directly identified as a defect in the implementation under test. It is still necessary to combine the responsibility judgment of the aforementioned layers and step S6.

[0073] The communication state layer is used to determine whether states such as connection establishment, transmission completion, reception completion, timeout, and connection termination are consistent with the device response. For example, if the device does not return a response but the communication connection remains normal, it is recorded as a timeout response; if the sending interface fails to complete the transmission, resulting in no response being received, it is not directly attributed to the implementation under test.

[0074] The test execution and alignment module starts from the model parameter layer and sequentially searches for the first discrepancy that cannot be explained by the target deviation from the boundary, the linked update set, or the expected response classification, identifying it as the first inconsistency level. The record of the first inconsistency level includes at least the level identifier, corresponding action, control value, test value, discrepancy content, consistency conclusion of the preceding level, and related evidence identifier.

[0075] During execution, if the device under test experiences resource anomalies, continuous communication interruptions, or an unrecoverable state, the test execution and alignment module immediately stops subsequent actions, saves current evidence, and performs recovery actions. If a stable result cannot be obtained after the same test action reaches a preset number of retries, it is marked as an unstable result and does not directly establish responsibility for the implementation under test. When the comparison action itself cannot obtain a normal or expected response, this group of tests lacks a comparative basis. Step S6 prioritizes determining model responsibility or environmental responsibility, and does not determine responsibility for the implementation under test based on the individual results of the test actions.

[0076] This step outputs the execution alignment record and the first inconsistency level. The execution alignment record includes at least the execution context, comparison action evidence, test action evidence, alignment results for each level, protection witness results, anomaly handling record, and the first inconsistency level. The above output is passed to step S6 via the execution batch identifier for responsibility classification, evidence consolidation, and remediation regression. This allows the location of the first discrepancy in the continuous chain of model generation, message rendering, actual transmission, test environment, and device response to be identified, avoiding direct attribution of responsibility to the implementation under test based solely on the final abnormal response.

[0077] S6. Based on the first level of inconsistency and the results of the control actions, determine the model responsibility, environmental responsibility, or responsibility for the achievement to be tested, solidify the test evidence version, and perform remedial regression. The specific implementation is as follows: The responsibility determination and regression verification module is the main implementer of this step, running on both the test execution end and the test evidence storage end. Input data includes the execution alignment record generated in step S5, the first inconsistency level, the comparison action result, the test action result, the protection witness result, the frozen test model, and the protocol semantic closure version. Minimum required content includes the consistency conclusions of each preceding level, evidence of the first inconsistency level, the validity of the comparison action, the deviation of the test action target from the boundary, and the implementation version to be tested.

[0078] The responsibility determination and regression verification module first determines whether a valid comparison basis has been established for the comparison action. A comparison action is considered valid when it can be executed within the target state slot, the rendered message and the sent message are consistent, the protection witness passes, and the device returns a normal response or the expected response allowed by the protocol. When an anomaly occurs in the model parameter layer, message rendering layer, or message sending layer, the responsibility determination for the implementation under test is not initiated; instead, model responsibility or environmental responsibility is determined based on the first inconsistency level. When a comparison action fails due to test interface anomalies, session state anomalies, the device failing to enter the target state, or insufficient basic resources, environmental responsibility is prioritized.

[0079] Model responsibility refers to situations where the first level of inconsistency is located at the model parameter layer or message rendering layer, and the difference originates from the frozen test model, action parameters, field mapping, field dependencies, or state action definitions. The model responsibility result should at least include the responsible object identifier, the responsible model element, the corresponding closure object, a description of the difference, the affected action, and a suggested fix location. For example, if the target deviates from the business data field, and the test model fails to update the length field according to the linked update set, resulting in the actual test message not performing the intended test action, then the responsibility is attributed to model responsibility. Similarly, if a candidate state model calls an action in an incorrect state, causing the test preconditions to be invalid, this is also attributed to model responsibility.

[0080] Environmental responsibility refers to situations where the frozen test model and message rendering results meet expectations, but the first inconsistency level is located at the message sending layer or the environment state layer, or both the control action and the test action are affected by the same test environment anomaly. Environmental responsibility results must include at least the anomalous interface, the anomalous environment state, the time of occurrence, the affected batches, the recovery action, and retry recommendations. For example, environmental responsibility results are generated when the test sending interface truncates messages, the test network is interrupted, the simulation device does not load the correct version, the device under test is not in the target state slot, or the state snapshot recovery fails.

[0081] The responsibility of the implementation under test refers to the implementation where the control action is effective, the model parameter layer, message rendering layer, message sending layer, and environment state layer all conform to semantic constraints, and the test action only shows the expected difference in the target deviation boundary and the specified linked update object, while the implementation under test produces a response or state result inconsistent with the protocol semantic closure or state constraints. The result of the responsibility of the implementation under test includes at least the implementation version under test, target state slot, target deviation boundary, control action result, test action result, first inconsistent response level, affected state, and evidence reference. The responsibility of the implementation under test is only used to identify protocol robustness, anomaly handling consistency, or state transition consistency issues; it does not generate attack exploitation steps or deduce unauthorized access methods.

[0082] When the first level of inconsistency cannot be stably reproduced, the results of the control actions are unstable, the witnessing portion of the protection fails, or the existing evidence is insufficient to rule out model responsibility and environmental responsibility, the responsibility determination and regression verification module does not force the formation of responsibility for the test implementation. Instead, it generates a record to be reviewed. The record to be reviewed includes at least the evidence gap, the witnessing operations that need to be supplemented, the suggested retry conditions, and the reason for not attributing responsibility at this time. The record to be reviewed re-enters this step for judgment after supplementing the evidence.

[0083] Once the responsibility outcome is determined, the responsibility determination and regression verification module solidifies the test evidence version. The test evidence version includes at least the evidence version identifier, protocol semantic closure version, frozen test model version, implementation version under test, test environment version, action group identifier, comparison action record, test action record, rendered message digest, sent message digest, environment status record, device response record, communication status record, first inconsistency level, responsibility outcome, and formation time. Evidence content is stored incrementally; subsequent entries must not overwrite the original record. When supplementary explanations are needed, a version chain is formed by referencing the original evidence version through a new evidence version.

[0084] For model responsibility, the repair targets are the Peach data model, Peach state model, model element mapping, or test action parameters. After the model repair is completed, the original frozen test model is not directly replaced. Instead, the process returns to step S2 or step S3 to generate a new candidate test model and re-performs the witness operation for alignment, forming a new frozen model version.

[0085] For environmental responsibility, the remediation targets are the test sending interface, simulation environment, state snapshot, network connection, or test device configuration. After the environment remediation is completed, retain the original frozen test model and original action group, update the test environment version, and re-execute step S5 to determine whether the first inconsistency level has disappeared.

[0086] For the implementation under test, authorized equipment R&D or maintenance personnel shall repair the implementation of the protocol under test based on the responsibility results. The repair content is not automatically written into the production equipment by this method, but is performed after the new implementation version under test is deployed to the isolation environment. The repair regression includes at least the original control action regression, the original test action regression, and the protection witness regression. The original control action regression is used to confirm that the repair has not disrupted the normal communication process; the original test action regression is used to confirm that the corresponding rejection response, timeout response, state deviation response, or abnormal state handling has met expectations; the protection witness regression is used to confirm that field relationships and state transitions unrelated to this repair still hold.

[0087] The regression results should include at least the regression batch identifier, the pre-remediation version of the liability evidence, the post-remediation version of the implementation to be tested, the frozen model version used, the control action results, the test action results, the protection witness results, and the regression conclusion. If the original test action achieves the expected results after remediation, and both the control action and the protection witness pass, the liability results will be updated to "Regression Verification Completed," but the original liability results will not be deleted. If the original issue still exists, a new version of the test evidence will be generated, and the liability for implementation to be tested will continue to be retained. If the first inconsistency level shifts to the model or environment level during the regression process, the system will be reclassified according to the new implementation evidence, and the original liability conclusion will not be used.

[0088] Through the above steps, a protocol semantic closure is formed based on protocol data, sample messages, and state records. This semantic closure constrains the large language model to generate the Peach data model and state model. Then, the candidate test model is semantically verified through witness operations and normal samples, which reduces the probability of inconsistencies between the content generated by the large language model and the actual protocol structure. By generating comparison actions and test actions under the same state slot through target deviation boundary, linkage update set, and protection witness set, the test variables can be kept controllable. By sequentially aligning the rendered message, sent message, environment state, device response, and communication state, the first inconsistency level can be located. Finally, the responsibility of the model, environment, and the implementation under test is distinguished based on the comparison actions and the first inconsistency level, and the remediation regression is supported by versioned evidence, thereby improving the reproducibility, interpretability, and accuracy of responsibility location of the protocol robustness test results.

[0089] In the operational scenario shown in this embodiment, taking the robustness test of the communication protocol of a certain type of data acquisition terminal as an example, the object under test is the protocol simulation implementation and the corresponding physical test terminal deployed in an isolated test network. The test network is isolated from the production network, and the test execution terminal only connects to the pre-registered test address. The communication protocol adopts a binary message structure. A service request message includes a message type field, a length field, a sequence field, a service data field, and a verification field in sequence. Among them, the message type field is used to determine the interpretation method of the service data field, the length field is used to indicate the actual length of the service data field, the sequence field is used to identify the message order within the same session, and the verification field is formed based on the message type field, length field, sequence field, and service data field. The protocol operation state is divided into connection establishment state, session preparation state, service processing state, and service completion state according to the execution order. Only after the connection establishment state completes the normal initialization operation can the terminal under test enter the session preparation state and receive service requests. Before testing, the field description document of the protocol, three sets of normal request messages and corresponding response messages after anonymization, terminal operation logs and status change records are written to the protocol data storage terminal. For this test, a project identifier "Protocol Test Project One", a protocol version identifier "Protocol Version One", and an implementation version identifier "Implementation Version One" are created.

[0090] The protocol semantic organization module first reads the field description document, sample messages, and status records, and establishes five field slots according to the actual arrangement order in the messages. The message type field and sequence field use fixed boundaries, the end boundary of the business data field is dynamically determined based on the length field, and the validation field is located after the business data field. The module further establishes field dependencies, recording the value dependency of the message type field on the business data field structure, the length dependency of the length field on the business data field boundary, and the validation dependency of the message type field, length field, sequence field, and business data field on the validation field. Simultaneously, it establishes state transition slots based on the terminal operation logs, from the connection establishment state to the session preparation state, from the session preparation state to the business processing state, and from the business processing state to the business completion state. A valid request that can obtain a normal response in the session preparation state and enter the business completion state is set as a business processing witness operation, and a normal request that, after re-rendering, allows the length field and validation field to be updated synchronously with the business data field is set as a field dependency witness operation. The field slots, field dependencies, state transition slots, witness operations, and the source relationships of each input data are jointly written into the protocol semantic closure, forming closure version "closure version one".

[0091] The test model generation module converts closure version one into a structured model generation request and inputs it into the large language model deployed on the local server. The large language model generates a Peach data model based on field slots and a Peach state model based on state transition slots, returning the corresponding closure object identifier and witness operation identifier for each field element, field relationship, state node, and state action. The generated Peach data model includes message type elements, length elements, sequence elements, business data elements, and validation elements. The generated Peach state model includes connection establishment state nodes, session preparation state nodes, business processing state nodes, and business completion state nodes. When validating the generated results, the test model generation module found that one candidate model correctly established the boundary relationship between the length field and the business data field, but did not include the length field in the calculation dependency of the validation field. Because this model element is inconsistent with the validation dependency in the protocol semantic closure, the test model generation module regenerates this part of the model based on the closure object identifier and writes the original generation result and the corrected result into the generation validation record. After correction, the candidate test model "Candidate Model One" is formed.

[0092] The model semantic verification module calls candidate model one and the business processing witness operation to process the same normal sample message and the same state path, respectively. Candidate model one parses the message type field, length field, sequence field, business data field, and verification field, and executes the connection initialization action and business request action in sequence according to the Peach state model; the witness operation processes the same message according to the field relationship and state conditions in the protocol semantic closure. The verification module compares the two processing paths item by item, confirming that the number of fields, field order, dynamic boundaries, length dependency, verification dependency, action call order, starting state, and target state are all consistent, and the normal sample message re-rendered by the candidate model is the same as the input sample in terms of structural relationship. This forms a semantic constraint record "Constraint Record One", setting the message type field, sequence field, and state preconditions as elements that cannot be changed, setting the parameters in the length field, business data field, and verification field that are related to this round of testing as elements that can be changed, and freezing candidate model one as "Frozen Model One".

[0093] This test selects the boundary consistency between the length field and the business data field as the target test object. Based on constraint record one, the test action generation module establishes the baseline relationship as "the business data length represented by the length field must be consistent with the actual length of the business data field," and defines any controlled inconsistency between the two as the target deviation boundary. To ensure the uniqueness of the anomaly source, the message type field, sequence field, initial state, business operation purpose, and target terminal remain unchanged. The test action generation module generates a set of control actions and test actions located in the same session preparation state slot: the control action generates a normal request message with complete field relationships according to Freeze Model One; the test action, without changing the message type and business operation purpose, causes the length represented by the length field to deviate from the actual length of the business data field by a predetermined boundary, and regenerates the verification field according to the verification dependency, thereby avoiding the introduction of a second independent variable due to the verification field not being updated. The business processing witness operation, message type identification relationship, initial state, and normal state recovery operation together constitute the protection witness set. After the actions are generated, the system performs static verification on the state slot, the uniqueness of the target object, the integrity of the linkage update, the executability of the protection witness, and the authorized status of the test address. After the verification passes, the action group "Action Group One" is formed.

[0094] The test execution and alignment module executes the comparison action and test action respectively from the same basic state snapshot. Before execution, the pre-witness operation confirms that the terminal under test is in the session preparation state, the test network connection is normal, and normal sample messages can obtain normal responses. When executing the comparison action, model one is frozen to generate a baseline rendering message. The test sending interface sends the rendering message completely to the terminal under test. The terminal returns a normal response and enters the service completion state from the session preparation state. The system records the model parameters, field boundaries, rendering message digest, sending message digest, environmental state before and after sending, device response, and communication state of the comparison action. Subsequently, the test execution end restores the basic state snapshot, causing the terminal under test to re-enter the same session preparation state and execute the test action. In the rendering message corresponding to the test action, only the length field has a predetermined deviation from the actual length of the service data field. The verification field has been re-formed according to the changed message content. The actual sent message is consistent with the rendering message, and there are no abnormalities in the test network and the initial state of the terminal.

[0095] After receiving the message corresponding to the test action, the terminal under test did not return a preset rejection response, nor did it remain in the session preparation state. Instead, it returned a normal response and entered the service completion state. The test execution and alignment module compared the model parameter layer, message rendering layer, message sending layer, environment state layer, device response layer, and communication state layer in sequence. The differences in the model parameter layer were consistent with the target deviation boundary; the message rendering layer confirmed that the field changes conformed to the test action definition; the message sending layer confirmed that the actual sent content had not been truncated, appended, or encoded; the environment state layer confirmed that both the control action and the test action started from the same state snapshot, and the test interface, terminal version, and network state remained consistent. Therefore, there were no unexplained anomalies in the aforementioned layers. The device response layer was the first to show a difference that could not be explained by the target deviation boundary and the expected defensive response rules. That is, both the control action and the test action received normal responses, and the terminal entered the service completion state after the test action was executed. Therefore, the device response layer was identified as the first inconsistency layer.

[0096] The responsibility determination and regression verification module further verifies whether the control action constitutes a valid basis for comparison. Since the control action was rendered correctly, sent completely, passed protection witness, and received a normal response, the control action is determined to be valid. Meanwhile, the test action conforms to semantic constraints at the model parameter layer, message rendering layer, message sending layer, and environment state layer, thus excluding model responsibility and environment responsibility. The test action only changes at the preset target deviation boundary, but the implementation under test did not handle message rejection or state preservation according to the length boundary relationship in the protocol semantic closure. Therefore, a responsibility result for the implementation under test is formed, which is recorded as a length boundary anomaly handling consistency problem. The responsibility result records the implementation under test version, target state slot, target deviation boundary, control action result, test action result, first inconsistency level, and all related evidence, but does not generate any exploitation steps for external systems.

[0097] The test evidence storage terminal solidifies "Evidence Version 1" into "Closed Version 1," including Closure Version 1, Frozen Model 1, Implementation Version 1 Under Test, Action Group 1, Rendered Message Digest, Sent Message Digest, Environment Status Record, Device Response Record, Communication Status Record, First Inconsistency Level, and Responsibility Result, and saves it using an incremental-only method. Subsequently, the length boundary check logic of the protocol implementation under test is repaired, forming "Implementation Version 2," which is then redeployed to the same isolated test environment. During regression verification, Frozen Model 1, the original control action, the original test action, and the original protection witness set are continuously invoked. Regression results show that the control action still receives a normal response and completes normal state transition, indicating that the repair did not affect the legitimate communication process; the test action receives a rejection response, and the terminal remains in the session preparation state, not entering the business completion state; other field relationships and state transitions in the protection witness set also remain valid. Based on this, the responsibility determination and regression verification module forms "Evidence Version 2," establishes a reference relationship between it and Evidence Version 1, and updates the original responsibility result of the implementation under test to "Repair Completed Regression Verification." Thus, without relying on the final anomaly for direct attribution, a complete closed loop is achieved, from protocol semantic formation, model generation and verification, controlled test action construction, execution level alignment, responsibility classification, to remediation and regression.

[0098] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for automated vulnerability discovery in communication protocols using a large model-assisted Peach framework, characterized in that, include: S1. Based on the protocol documentation, sample messages, and status records, form a protocol semantic closure containing field boundaries, dependencies, state transition slots, and witness operations; S2. Input the protocol semantic closure into the large language model to generate the Peach data model and state model, and establish the mapping between model elements and closures and witness operations. S3. Call the candidate test model and witness operation respectively to process the same instance message and state path, align field relationships and state actions, form semantic constraint records and freeze the test model; S4. Based on semantic constraint records, determine the target deviation from the boundary, the linkage update set, and the protection witness set, and generate the comparison action and test action for the same state slot; S5. Perform comparison and test actions to align rendered messages, sent messages, environmental status, device response, and communication status, and determine the first inconsistency level. S6. Based on the first level of inconsistency and the results of the control action, form the results of model responsibility, environmental responsibility or the responsibility to be tested, solidify the test evidence version and perform remedial regression.

2. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 1, characterized in that, The processing of protocol data, sample messages, and status logs includes: Sample messages are grouped according to message direction, interaction sequence, and communication session. Field definitions and status descriptions in the protocol documentation are associated with the corresponding sample messages and status records to form protocol interaction records with source location.

3. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 2, characterized in that, Field boundaries and dependencies are formed based on protocol interaction records, including: The start and end positions of each field are determined based on the field order, fixed identifiers, and sample values. The pointing relationships, scope of application, and update order between the length field, validation field, condition field, and associated field segments are established.

4. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 2, characterized in that, State transition slots are formed based on protocol interaction records, including: Record the preceding communication status, allowed request actions, allowed response actions, response waiting range, and subsequent communication status according to a single request-response process, and configure the status records used to confirm the preceding and subsequent communication statuses as corresponding witness operations.

5. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 2, characterized in that, The generation of the Peach data model and state model includes: Field boundaries and dependencies are mapped to Peach data elements and element relationships. State transition slots are mapped to Peach states, sending actions, receiving actions, and state transitions, while preserving the correspondence between each model element and the protocol semantic closure.

6. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 5, characterized in that, The verification of candidate test models includes: Examine the syntax, element references, and loading results of the Peach model. Parse and reconstruct the same instance message and rehearse the same state path using candidate test models and witness operations respectively. Perform consistency alignment on field boundaries, dependency values, request-response order, and state acceptance results.

7. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 6, characterized in that, When performing control and test actions, collect Peach rendering messages, actual sent messages, device responses, connection status, communication status before and after execution, and environmental status according to a unified time sequence, and associate the collected results with the corresponding test model, state transition slot, and action type to form anomaly evidence records.

8. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 7, characterized in that, The consequences that result in liability include: When a rendered message does not meet the semantic constraints, a model responsibility result is generated. When the sent message and the rendered message are inconsistent, or when the environmental state changes, an environmental responsibility result is formed. When the control action is normally accepted and the abnormality of the test action first appears in the device response or communication status, the result of the responsibility for the implementation of the test is formed.

9. The method for automated vulnerability discovery of communication protocols in a large model-assisted Peach framework according to claim 8, characterized in that, Defect identification and remediation regression includes: The test actions that lead to the achievement of the responsibility for the test are repeatedly executed, and the defect confirmation result is formed based on the repeated occurrence of the same anomaly and the first inconsistency level; After the protocol is repaired, the test evidence version is called to restore the same state migration slot and the control and test actions are re-executed to form the repair regression results.

Images