Autonomous evolution type 5G protocol fuzzy test system based on large language model
The self-evolving 5G protocol fuzz testing system based on a large language model has achieved full-process automation and intelligence in 5G protocol testing, solving the problems of low testing efficiency and difficulty in vulnerability discovery in existing technologies, improving the relevance and coverage of testing, and possessing independent optimization capabilities.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 北京明博信安信息技术有限公司
- Filing Date
- 2026-02-04
- Publication Date
- 2026-05-01
AI Technical Summary
Existing technologies are insufficient for efficient and comprehensive testing of 5G protocols, especially in terms of complexity and scale, resulting in low testing efficiency, difficulty in discovering vulnerabilities, and difficulty in systematically uncovering deep security threats.
An auto-evolving 5G protocol fuzzy testing system based on a large language model is adopted. By parsing the protocol specification through protocol extraction units, structured knowledge elements are generated. Combined with a dynamic test knowledge base and feedback internalization units, the system achieves automated, intelligent, and autonomous optimization of testing, generates targeted test cases, and performs iterative optimization.
It has achieved full automation and intelligence in 5G protocol testing, improved the targeting of testing and the efficiency of vulnerability discovery, ensured the integrity of protocol coverage and the accuracy of vulnerability detection, and has the ability to evolve autonomously to adapt to new protocols and new vulnerabilities.
Smart Images

Figure CN121967284A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of large language models, and more specifically to an auto-evolving 5G protocol fuzz testing system based on large language models. Background Technology
[0002] As the core of 5G networks, the security, stability, and reliability of the 5G protocol stack directly affect the secure operation of the entire communication system. However, the complexity and scale of 5G protocols pose significant challenges to protocol implementation and testing.
[0003] First, 5G protocol specification documents (such as the 3GPP series of specifications) are enormous, typically containing millions of words of text descriptions, state machine definitions, and interaction flow descriptions, covering multiple technical domains such as NAS, RRC, and PDCP. This complexity leads to inefficient manual analysis and testing, and makes it easy to miss potential vulnerabilities.
[0004] Secondly, traditional 5G protocol testing methods mainly rely on manual test case design based on specifications or fuzz testing techniques based on random mutations. The former heavily depends on expert experience and is difficult to cover all boundary cases and abnormal scenarios; the latter lacks specificity, and the generated test cases often fail to accurately trigger deep vulnerabilities in the protocol implementation, resulting in low testing efficiency and a high false negative rate.
[0005] Third, the 5G protocol contains a large number of potential design flaws, such as ambiguous parameter boundary definitions, unclear abnormal processes, and conflicting state transition conditions. These flaws are difficult to identify effectively under traditional testing methods and may cause serious security problems under certain conditions.
[0006] In summary, the core dilemma of existing technologies lies in the fact that, faced with ultra-large-scale and highly complex 5G protocols, traditional testing paradigms lack a method that can continuously accumulate testing knowledge and dynamically optimize testing strategies using that knowledge. This results in repetitive and inefficient testing processes, difficulty in breaking through coverage bottlenecks, and an inability to systematically uncover deep-seated security threats. Summary of the Invention
[0007] To address the challenges of protocol document parsing, weak test case targeting, poor multi-protocol compatibility, and incomplete test coverage in 5G protocol testing, this invention proposes an auto-evolving 5G protocol fuzz testing system based on a large language model. This system achieves full-process automation and intelligence in protocol fuzz testing, significantly improving test targeting, protocol coverage, and vulnerability discovery efficiency.
[0008] Technical solution:
[0009] An auto-evolving 5G protocol fuzz testing system based on a large language model includes:
[0010] The protocol extraction unit is used to parse the target protocol specification document and extract structured protocol knowledge elements, including message format, state machine logic (constructed based on protocol interaction logic) and parameter constraints.
[0011] The vulnerability analysis unit parses the protocol knowledge elements and generates a list of potential vulnerability descriptions associated with the protocol logic.
[0012] A dynamic test knowledge base is used to store the protocol knowledge elements, the list of potential vulnerability descriptions, and test knowledge summarized from historical test results;
[0013] The test strategy generation unit generates targeted fuzzy testing strategies and corresponding test cases based on the current protocol knowledge elements and potential vulnerability description list in the dynamic test knowledge base.
[0014] The test execution unit is used to execute the test cases and capture the test results;
[0015] The feedback internalization unit analyzes the test results, extracts causal patterns to generate new test knowledge, and updates it to the dynamic test knowledge base;
[0016] Specifically, based on the update status of the dynamic test knowledge base, test targets and resources are dynamically scheduled to achieve autonomous optimization and evolution of the test process.
[0017] Furthermore, in the protocol extraction unit, the method for extracting structured protocol knowledge elements is as follows:
[0018] First, the target protocol specification document is sliced according to logical chapters or functional modules to generate protocol document slices. Then, through preliminary parsing of the slice content, basic elements such as protocol message format, field definition, and syntax constraints are extracted. Finally, based on these basic elements, the protocol interaction logic is inferred, and a state machine model that maps the complete behavior of the protocol is constructed.
[0019] Furthermore, the vulnerability analysis unit, based on the aforementioned protocol knowledge elements and state machine logic, automatically generates a list of potential vulnerability descriptions associated with the protocol logic through vulnerability analysis. Each vulnerability description includes the vulnerability type, triggering scenario, scope of impact, and associated protocol context information. It also receives test cases from the test strategy generation unit and maps each test case to the corresponding vulnerability entry in the list of potential vulnerability descriptions.
[0020] Furthermore, the dynamic test knowledge base is organized and stored using a graph structure; nodes represent protocol messages, states, parameter constraint entities, and vulnerability description entities; edges represent the derivation, dependency, triggering, or exclusion relationships between entities; and a graph query language is used to achieve efficient retrieval and associative reasoning of relevant knowledge during the testing process.
[0021] Furthermore, the dynamic test knowledge base also includes: after the test execution unit completes the test case execution, the vulnerability description list and test case set are dynamically optimized based on the causal rules extracted by the feedback internalization unit.
[0022] Furthermore, dynamic optimization includes: if a test case successfully triggers a system exception, its association weight with the corresponding vulnerability description is strengthened, and the vulnerability is marked as verified; if none of the test cases corresponding to a vulnerability description trigger an exception, the triggering conditions are modified or its priority is reduced based on the execution results; and the vulnerability description list is deredundant and merged based on the coverage and effectiveness of the test cases.
[0023] Furthermore, the test strategy generation unit employs an iterative processing mechanism to sequentially select individual target vulnerability descriptions from the potential vulnerability description list. In each iteration, the target protocol knowledge elements, state machine logic, and the currently selected individual target vulnerability description are fused and analyzed to deduce the feasible path and triggering conditions of the vulnerability in the protocol context. Based on the results of the fusion analysis, a set of test cases for the specific vulnerability is synthesized. This set of test cases includes targeted attack vectors designed to trigger the vulnerability by constructing malformed messages, injecting abnormal processes, or violating state rules. The set of test cases includes a crash test case set and a non-crash test case set.
[0024] Furthermore, the fusion analysis includes: (Association Mapping) semantically associating the currently selected single target vulnerability description with the message format definition and parameter constraint rules in the target protocol knowledge elements to determine the specific location of the vulnerability in the protocol syntax structure; (Conflict Detection) placing the mapped vulnerability point in the protocol state transition path defined by the state machine logic, analyzing the state machine conflict paths or undefined states that may be caused by inserting abnormal inputs or violating constraints under the normal state sequence; (Triggerable Path Derivation) based on the results of the association mapping and conflict detection, deriving the input condition sequence and state transition sequence that need to be satisfied to trigger the vulnerability; (Attack Vector Synthesis) synthesizing specific test instructions, malformed message data, or abnormal interaction processes according to the derived triggerable path to construct the targeted attack vector.
[0025] Furthermore, the feedback internalization unit, based on the protocol knowledge elements associated with the target vulnerability, compares and analyzes the crash test case set and the non-crash test case set to identify significant differences between them in input parameter values, protocol interaction sequences, and system state transitions. From these significant differences, it summarizes the key necessary or sufficient conditions that lead to the successful triggering of the system anomaly as vulnerability triggering rules. Simultaneously, based on the constraint rules in the protocol knowledge elements, it locates the input or logical restrictions that prevent the vulnerability from being triggered from the non-crash test case set as vulnerability avoidance rules. The vulnerability triggering rules and the vulnerability avoidance rules are structurally integrated to generate new test knowledge that is strongly associated with the target vulnerability and protocol context and can guide the optimization of test strategies. The new test knowledge is updated to the dynamic test knowledge base to optimize the generation of subsequent test strategies for the same or similar vulnerabilities.
[0026] Furthermore, the autonomous optimization and evolution are achieved through a closed loop: new test knowledge generated by the feedback and evolution steps is updated to the dynamic test knowledge base; the updated knowledge base directly affects the generation and execution steps of the next round of test strategies; through continuous iteration, the system's vulnerability detection accuracy, protocol coverage, and testing efficiency are continuously improved.
[0027] The beneficial effects of this invention are:
[0028] (1) The present invention realizes full automation and intelligence of the testing process, significantly reducing the reliance on human experts: through the collaborative work of modules such as protocol extraction unit and test strategy generation unit, the system can automatically complete the entire process from parsing massive protocol documents, generating targeted test cases to analyzing test results, overcoming the shortcomings of traditional methods that are inefficient and prone to missing deep vulnerabilities.
[0029] (2) This invention improves the targeting of testing and the accuracy of vulnerability discovery: the system does not generate random or blind test cases, but generates targeted test cases with clear attack vectors based on protocol knowledge elements and vulnerability descriptions in a dynamic test knowledge base. In particular, by extracting causal rules from test results and updating the knowledge base through feedback internalization units, the system can "learn from experience" like a security expert, continuously optimize subsequent testing strategies, and thus effectively trigger deep and hidden protocol vulnerabilities.
[0030] (3) This invention has the ability to evolve autonomously, and the testing efficiency is continuously improved: The system constructs a closed loop of testing, analysis, learning and optimization. The dynamic test knowledge base serves as the memory center of the system and is continuously enriched with the increase of test rounds, making the generation of test strategies more and more accurate, realizing the continuous growth of test coverage and vulnerability detection accuracy, and possessing the long-term adaptability to cope with new protocols and new vulnerabilities.
[0031] (4) The present invention achieves full-range, complete test coverage of complex protocols: by parseting the protocol document in a structured manner and using an iterative mining and slicing rotation mechanism, the system can systematically traverse all logical chapters and technical domains of the protocol, ensuring the integrity of test coverage and effectively avoiding blind spots that may exist in traditional testing.
[0032] (5) The present invention has good versatility and scalability: the system architecture is not limited to a specific 5G protocol. Its approach of parsing documents based on a large language model and driving testing based on a knowledge base can be adapted to fuzz testing of other complex communication protocols or interface specifications, and has broad application prospects. Attached Figure Description
[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below.
[0034] Figure 1 This is a schematic diagram of system modules according to an embodiment of the present invention;
[0035] Figure 2 This is an example diagram of the prompt word P1 content according to an embodiment of the present invention;
[0036] Figure 3 This is an example diagram of the prompt word P2 content according to an embodiment of the present invention;
[0037] Figure 4 This is an example diagram of the prompt word P3 content according to an embodiment of the present invention;
[0038] Figure 5 This is an example diagram of the prompt word P4 content according to an embodiment of the present invention;
[0039] Figure 6 This is an example diagram of the prompt word P5 content according to an embodiment of the present invention. Detailed Implementation
[0040] To make the objectives, technical solutions, and advantages of this invention clearer, the following detailed description, in conjunction with the accompanying drawings and embodiments, further illustrates the invention. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of the invention. Figure 1 As shown, this invention discloses an auto-evolving 5G protocol fuzz testing system based on a large language model, mainly composed of six modules, including: a protocol extraction unit, a vulnerability analysis unit, a dynamic test knowledge base, a test strategy generation unit, a test execution unit, and a feedback internalization unit. Specifically,
[0041] The protocol extraction unit is used to parse the target protocol specification document and extract structured protocol knowledge elements, including message formats, state machine logic (built based on protocol interaction logic), and parameter constraints. Specifically, firstly, the 5G protocol specification document (such as the 3GPP series specifications) undergoes structured preprocessing, being split according to logical chapters, technical domains (such as NAS, RRC, PDCP, etc.), or functional modules to form structured protocol document slices. Then, primary parsing is performed to extract basic elements such as protocol message formats, field definitions, and syntactic constraints. Finally, advanced modeling is performed, inferring protocol interaction logic based on these basic elements and constructing a state machine model that maps the complete behavior of the protocol.
[0042] In this embodiment, the protocol document slices and the preset extraction task instructions are constructed as the first prompt word P1. Based on the prompt word P1, a large model (such as LLM) is driven to perform deep parsing on the structured protocol text slices, which are then transformed into structured data containing core elements such as message format, field definition, and parameter constraints.
[0043] Prompt word P1, for example Figure 2 As shown, its specific structure is as follows: First, through a professional role setting ("You are a well-trained protocol analyst, specifically responsible for the analysis of 5G protocol specifications"), the large language model is positioned as a 5G protocol analysis expert. The core task description instruction requires the model to carefully read the protocol fragments input by the user and analyze core specification information, including protocol format specifications. The input part uses the placeholder form {5G protocol fragment} to clearly indicate that the object to be processed is a slice of protocol text processed by the upstream module. The output format is strictly limited to a JSON structure, which must contain the key-value pair "Protocol coreinformation" to force the model to output structured and standardized results, ensuring that its output can be seamlessly parsed and directly used by downstream modules (such as vulnerability mining modules). It should be noted that the prompts shown in the figure are a simplified and refined presentation of the complete prompts used in actual deployment based on the need for commercial confidentiality protection.
[0044] By performing structured preprocessing on 5G protocol specification documents (such as the 3GPP series of specifications), and precisely dividing them according to logical chapters, technical domains (such as NAS, RRC, PDCP, etc.), and functional modules, a structured dataset that can be efficiently called by subsequent modules is generated, including core elements such as chapter indexes, semantic fragments, and key parameter tables. This division process essentially constitutes a key preprocessing step for achieving protocol complexity reduction and improved testing accuracy: given that the 3GPP series of specifications is a massive heterogeneous document collection containing multimodal information such as text descriptions, diagrams, and state machine definitions, its million-word volume significantly exceeds the threshold of the large model context window, and the semantic coupling across technical domains can easily lead to feature dilution during model inference. By dividing according to technical domain boundaries (such as the layering of the PDCP / RLC protocol stack) and functional module granularity (such as the RRC connection establishment sub-process), unstructured documents can be decomposed into semantically cohesive fragment units, which not only adapts to the upper limit of large model token processing but also effectively improves parsing accuracy by reducing cross-domain semantic interference.
[0045] In this embodiment, the parsed protocol document and the state machine construction task instructions are jointly constructed into a second prompt word P2. Based on prompt word P2, the large language model is driven to complete information extraction, logical association, and structured modeling, realizing the fully automated construction of a unified state machine model from scattered slice information. This model strictly follows the protocol specification definition, accurately maps the state transition logic of normal business processes, exception handling branches, and boundary scenarios, ensuring the integrity of state nodes, the accuracy of dependencies, and the consistency of jump rules. This provides high-fidelity and reusable logical support for subsequent 5G protocol fuzz testing, effectively improving the targeting of test case generation and the efficiency of vulnerability discovery.
[0046] Prompt word P2, for example Figure 3As shown, its specific structure is as follows: First, by defining its role (As a 5G protocol and formal logic expert), the large language model is positioned as an expert possessing both communication protocol knowledge and formal modeling capabilities. The core task instruction requires the model to integrate and logically complete the core information from multiple input protocol slices, and systematically extract four categories of key rules: state dependency rules, triggering rules, state transition rules, and constraint rules. These four categories of rules together constitute a complete skeleton describing the dynamic behavior of the protocol. Finally, the instruction strictly specifies that a structured rule set should be output in JSON format, and requires each rule to include a unique ID, type, description, and application scenario, thereby ensuring that the output results are not only human-readable but also machine-readable data that can be directly parsed and utilized by downstream systems or modules. It should be noted that the prompts shown in the figure are a simplified and refined presentation of the complete prompts used in actual deployment, based on the need for commercial confidentiality protection.
[0047] The vulnerability analysis unit parses the protocol knowledge elements and generates a list of potential vulnerability descriptions associated with the protocol logic. Specifically, based on the protocol knowledge elements and state machine logic, it automatically generates a list of potential vulnerability descriptions associated with the protocol logic through vulnerability analysis. Each vulnerability description includes the vulnerability type, triggering scenario, scope of impact, and associated protocol context information. It also receives test cases from the test strategy generation unit and maps each test case to the corresponding vulnerability entry in the list of potential vulnerability descriptions.
[0048] In this embodiment, structured core protocol information (protocol knowledge elements) and the protocol state machine logic of the state machine model are jointly constructed as the third prompt word P3. Based on prompt word P3, the large model is driven, and based on the protocol specification's inherent logical consistency verification mechanism, potential protocol design flaws and implementation risks are identified. These include, but are not limited to, ambiguous parameter boundary definitions, missing abnormal scenario handling procedures, and conflicting state transition conditions. This achieves a joint security review of the protocol's static specifications and dynamic behavioral logic, thereby identifying deep-seated design flaws hidden in complex state dependencies and interaction processes. The extracted core information and identified vulnerabilities will be output in a structured manner, providing accurate protocol features and vulnerability descriptions as input for subsequent test case generation. The generated potential vulnerabilities may be more than one, potentially encompassing multiple vulnerabilities.
[0049] Prompt word P3, such as Figure 4As shown, its specific structure is as follows: First, through role setting (As a well-trained security analyst, specializing in detecting vulnerabilities in 5G protocol specifications), the large language model is positioned as a security analyst specializing in 5G protocol vulnerability discovery. The core task instruction requires the model to carefully read and comprehensively analyze two types of key information input by the user: core protocol information and state machine logic, and identify "all possible vulnerabilities" from them. This positioning elevates its work beyond simple syntax checking to an assessment of the overall logical consistency and security robustness of the protocol. Finally, the prompt word, through strict output format constraints (Outputformat: {"Potential vulnerability": yyy}), forces the model to output the analysis results in a structured and standardized form (such as JSON) to ensure that the generated list of potential vulnerability descriptions can be directly parsed and utilized by the downstream test case generation module.
[0050] A dynamic test knowledge base is used to store the protocol knowledge elements, the list of potential vulnerability descriptions, and test knowledge summarized from historical test results.
[0051] It's important to note that the dynamic test knowledge base is not merely a static data storage container; it also possesses intelligent test case management capabilities. When the number of valid test cases generated for a specific target vulnerability description reaches a preset threshold, the system standardizes and stores these test cases along with their complete context information, forming reusable test assets. The specific storage and management method is as follows: the knowledge base employs a structured storage strategy. When the number of valid test cases generated for a target vulnerability description within a specific protocol text slice reaches a preset number, the standardized storage process is automatically triggered. The stored content comprehensively covers the protocol text slice identifier, target vulnerability description information, and the corresponding set of valid test cases. The protocol text slice identifier is associated with the original protocol specification's document number, technical domain classification, and logical chapter index, ensuring the traceability of each test asset. Simultaneously, the knowledge base establishes a multi-dimensional indexing mechanism, supporting rapid retrieval and semantic matching based on vulnerability type and protocol chapter, providing a data foundation for the intelligent reuse of test cases.
[0052] The test strategy generation unit generates targeted fuzzy testing strategies and corresponding test cases based on the current protocol knowledge elements and a list of potential vulnerability descriptions in the dynamic test knowledge base. Based on the target protocol knowledge elements, state machine logic, and the list of potential vulnerability descriptions in the dynamic test knowledge base, an iterative processing mechanism is used to sequentially select individual target vulnerability descriptions from the list of potential vulnerability descriptions. In each iteration, the target protocol knowledge elements, state machine logic, and the currently selected individual target vulnerability description are fused and analyzed to infer the feasible path and triggering conditions of the vulnerability in the protocol context. Based on the results of the fusion analysis, a set of test cases for the specific vulnerability is automatically synthesized. This set of test cases contains targeted attack vectors designed to trigger the vulnerability by constructing malformed messages, injecting abnormal processes, or violating state rules.
[0053] In this embodiment, structured core protocol information (protocol knowledge elements), state machine logic of the state machine model, and descriptions of individual potential vulnerabilities are collectively constructed as a fourth prompt word P4. Based on prompt word P4, a large language model is driven, and targeted reasoning is performed to generate a set of fuzzy test cases with scenario-specific relevance. These test cases specifically include, but are not limited to, constructing malformed protocol messages and injecting abnormal interaction processes. By establishing correlation constraints between core protocol information, potential vulnerability descriptions, and test generation logic within the prompt word, it is ensured that the generated test case set can accurately generate test cases targeting specific vulnerabilities.
[0054] Prompt word P4, for example Figure 5As shown, its specific structure is as follows: First, by setting the role (As a specially trained security analyst), the large language model is positioned as a specially trained security analyst. The core task instructions include two levels: one is to require the model to perform in-depth analysis of the implementation path and triggering conditions of the input vulnerability; the other is to require the model to accurately identify the exploitable security attributes in the protocol. This ensures that the generated test cases are not only based on the vulnerability description, but also rooted in a systematic understanding of the weaknesses of the protocol itself. The prompt words clearly list the key input fields: {Technical Conclusion} (representing the improved description obtained after analysis based on the generated test cases) for receiving optimization feedback, {Protocol core information} (representing the extracted core protocol information) containing static protocol knowledge, {Protocol state transition rules} defining dynamic behavior, and {Potentialvulnerability[i]} (representing the i-th vulnerability description) to be attacked this time. Crash Cases represents the set of test cases that cause the system to crash, {Non-Crash Cases} represents the set of test cases that do not cause the system to crash, and {NUM} represents the maximum number of words in the final summary output. Its output is strictly limited to a JSON object containing 10 structured test cases, ensuring the standardization and parsability of the results.
[0055] The test execution unit is used to execute the test cases and capture the test results. In this embodiment, the generated fuzzy test cases are injected into the 5G protocol simulation environment according to the preset protocol interface specifications. A multi-dimensional monitoring module deployed in the simulation environment collects the simulation environment's operational status data in real time. Based on preset anomaly judgment rules, the monitoring data is analyzed in real time to distinguish and capture test cases corresponding to two types of test results: one is crash test cases that trigger simulation environment anomalies, and the other is non-crash test cases that do not trigger environment anomalies. These two types of test cases will be used for comparative analysis later, further feeding back into the optimization prompt word P4.
[0056] The feedback internalization unit analyzes the test results, extracts causal patterns to generate new test knowledge, and updates it to the dynamic test knowledge base.
[0057] In this embodiment, to achieve in-depth result analysis of two types of test cases generated for the same vulnerability (i.e., crash test cases that trigger simulation environment anomalies and non-crash test cases that do not trigger simulation environment anomalies), a dedicated prompt word P5 is constructed. This prompt word must have clear task orientation and logical constraints to guide the large language model to perform the following analysis operations based on the core features of the two types of test cases and simulation environment monitoring data:
[0058] ① Accurately identify the essential differences between the two types of test cases in terms of parameter value range, protocol interaction process design, and other dimensions.
[0059] ② Combining the core constraints of the 5G protocol specification (such as parameter boundary rules), deduce the key conditions for crash-type test cases to successfully trigger vulnerabilities (such as parameter out-of-bounds thresholds and malformed protocol field formats).
[0060] ③ Locate the core reason why non-crash test cases failed to trigger vulnerabilities (such as parameter configuration not touching the boundary of protocol defects).
[0061] ④ The above-mentioned differences, successful triggering conditions, and reasons for failure are summarized in a structured manner to form analytical conclusions with technical guidance.
[0062] The analysis conclusion is embedded in the "Technical Conclusion" field of the prompt word P4 in a standardized module form. This enhances P4's understanding of vulnerability triggering logic and test case construction rules, providing precise guidance for the generation of test cases for similar or related vulnerabilities and improving the quality of generated test cases.
[0063] The structured protocol core information (protocol knowledge elements) from upstream modules, the state machine logic of the state machine model, descriptions of individual potential vulnerabilities, and the sets of crash and non-crash test cases from the test execution phase are collectively constructed into the fifth prompt word, P5. Based on the P5-driven large language model, automated and standardized comparative analysis of different test results under the same vulnerability assumption can be achieved, accurately extracting the key conditions leading to successful vulnerability triggering and the core reasons for test failure.
[0064] P5 prompt words such as Figure 6As shown, its specific structure is as follows: First, through a highly professional role setting (As a professional 5G protocol security analyst), the large language model is positioned as a professional 5G protocol security analyst. The core task instructions explicitly require the model to perform vulnerability trigger analysis on both crash and non-crash use cases based on the core protocol specifications and potential vulnerabilities. Its input information module systematically provides all the context required for analysis, including protocol knowledge, target vulnerabilities, and positive and negative test evidence. To ensure the depth and logic of the analysis, the prompts specify four standardized analysis steps: difference identification, trigger condition derivation, failure cause identification, and structured summary. Finally, the output is strictly constrained to be a JSON format containing only the "Technical Conclusion" field. Here, TechnicalConclusion represents the improved description obtained after analysis based on the generated test cases; Protocol coreinformation represents the extracted core protocol information; "Potential vulnerability[i]" represents the description of the i-th vulnerability; Crash Cases represents the set of test cases that caused the system to crash; Non-Crash Cases represents the set of test cases that did not cause the system to crash; and NUM represents the maximum word limit for the final summary output. Technically guiding analytical conclusions are embedded in the "Technical Conclusion" field of the prompt word P4 in a standardized module format, enhancing P4's understanding of vulnerability triggering logic and test case construction rules. This provides precise guidance for subsequent test case generation for similar or related vulnerabilities, improving the quality of generated test cases. The forced model compresses and refines the complex analysis process into a highly structured, conclusive text, used for iterative optimization of the core knowledge of the test case generation logic (P4).
[0065] Specifically, based on the updated status of the dynamic test knowledge base, test targets and resources are dynamically scheduled using feedback internalization units to achieve autonomous optimization and evolution of the testing process. In this embodiment, autonomous optimization and evolution are implemented through a closed loop: new test knowledge generated by the feedback and evolution steps is updated to the dynamic test knowledge base; the updated knowledge base directly affects the generation and execution of the next round of test strategies; through continuous iteration, the system's vulnerability detection accuracy, protocol coverage, and testing efficiency are continuously improved.
[0066] For a given protocol slice, the system enters a testing loop. The test strategy generation unit retrieves a list of potential vulnerability descriptions corresponding to that slice from the dynamic test knowledge base, and iterates through the list to generate and execute test cases for each vulnerability, achieving deep coverage of the slice and enabling iterative vulnerability discovery.
[0067] The workflow of the self-evolving 5G protocol fuzz testing system based on a large language model disclosed in this application is as follows:
[0068] First, the original protocol documents are preprocessed. By identifying logical chapters, technical domain boundaries, and functional module division points, the massive amount of documents is segmented into multiple semantically complete protocol document slices, and standardized codes and traceability mappings are established for each slice. Based on this, the system enters the deep knowledge extraction stage, performing multi-level parsing on each slice: from basic syntactic elements (message format, field definition) to semantic constraints (parameter value range, dependency relationships), and finally constructing a complete protocol state machine model through logical reasoning, forming a structured protocol knowledge element library.
[0069] After completing knowledge modeling, the system initiates a test target decision-making mechanism. By analyzing abnormal paths and boundary conditions in the protocol state machine, it automatically generates potential vulnerability hypotheses and prioritizes vulnerabilities based on historical test data, forming a target vulnerability list for the current testing cycle. Subsequently, the system enters the targeted test case generation phase. For each target vulnerability, the system analyzes its triggering conditions in the state machine, generating targeted test cases that include normal sequence mutations, abnormal input construction, and state transition interference, ensuring that they conform to the protocol syntax specifications.
[0070] During the test execution phase, the system injects the verified test cases into the simulation environment according to the protocol interface specifications. Simultaneously, it deploys multi-dimensional monitoring probes to capture the protocol stack processing, resource usage, and anomaly signals in real time. After testing, the system enters a crucial in-depth analysis phase. By comparing the differences in input parameters and execution paths between crashed and non-crash test cases, it extracts the key combinations of conditions that trigger vulnerabilities and establishes a causal relationship model.
[0071] Based on the analysis results, the system dynamically updates its testing knowledge base, integrates newly discovered vulnerability triggering patterns, and adjusts testing strategies to optimize subsequent testing efficiency. Finally, the system evaluates the effectiveness of this round of testing and intelligently decides on the next cycle's goals based on metrics such as vulnerability discovery rate and coverage improvement: whether to continue exploring current vulnerability variants or switch to new vulnerabilities or new protocol slices, thus forming a complete closed loop of testing, analysis, learning, and optimization. This process enables the system to achieve continuous evolution of testing performance in a completely autonomous manner, ultimately achieving in-depth systematic testing of complex protocols.
[0072] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A self-evolving 5G protocol fuzz testing system based on a large language model, characterized in that, include: The protocol extraction unit is used to parse the target protocol specification document and extract structured protocol knowledge elements, including message format, state machine logic and parameter constraints. The vulnerability analysis unit parses the protocol knowledge elements and generates a list of potential vulnerability descriptions associated with the protocol logic. A dynamic test knowledge base is used to store the protocol knowledge elements, the list of potential vulnerability descriptions, and test knowledge summarized from historical test results; The test strategy generation unit generates targeted fuzzy testing strategies and corresponding test cases based on the current protocol knowledge elements and potential vulnerability description list in the dynamic test knowledge base. The test execution unit is used to execute the test cases and capture the test results; The feedback internalization unit analyzes the test results, extracts causal patterns to generate new test knowledge, and updates it to the dynamic test knowledge base; Specifically, based on the update status of the dynamic test knowledge base, test targets and resources are dynamically scheduled to achieve autonomous optimization and evolution of the test process.
2. The system according to claim 1, characterized in that, The protocol extraction unit extracts structured protocol knowledge elements in the following way: First, the target protocol specification document is sliced according to logical chapters or functional modules to generate protocol document slices. Then, through preliminary parsing of the slice content, basic elements such as protocol message format, field definition, and syntax constraints are extracted. Finally, based on these basic elements, the protocol interaction logic is inferred, and a state machine model that maps the complete behavior of the protocol is constructed.
3. The system according to claim 1, characterized in that, The vulnerability analysis unit, based on the protocol knowledge elements and state machine logic, automatically generates a list of potential vulnerability descriptions associated with the protocol logic through vulnerability analysis. Each vulnerability description includes the vulnerability type, triggering scenario, scope of impact, and associated protocol context information. It also receives test cases from the test strategy generation unit and maps each test case to the corresponding vulnerability entry in the list of potential vulnerability descriptions.
4. The system according to claim 1, characterized in that, The dynamic test knowledge base is organized and stored using a graph structure; Among them, nodes are used to represent protocol messages, status, parameter constraint entities, and vulnerability description entities; Edges are used to represent derivative, dependency, triggering, or exclusionary relationships between entities; The graph query language enables efficient retrieval and associative reasoning of relevant knowledge during the testing process.
5. The system according to claim 1, characterized in that, The dynamic test knowledge base also includes: after the test execution unit completes the test case execution, the vulnerability description list and test case set are dynamically optimized based on the causal rules extracted by the feedback internalization unit.
6. The system according to claim 5, characterized in that, The dynamic optimization includes: if a test case successfully triggers a system exception, its association weight with the corresponding vulnerability description is strengthened, and the vulnerability is marked as verified; if none of the test cases corresponding to a vulnerability description trigger an exception, the triggering conditions are modified or its priority is reduced based on the execution results; and the vulnerability description list is deredundant and merged based on the coverage and effectiveness of the test cases.
7. The system according to any one of claims 1-6, characterized in that, The test strategy generation unit adopts an iterative processing mechanism to sequentially select a single target vulnerability description from the potential vulnerability description list. In each iteration, the target protocol knowledge elements, state machine logic and the currently selected single target vulnerability description are fused and analyzed to deduce the feasible path and triggering conditions of the vulnerability in the protocol context. Based on the results of the fusion analysis, a set of test cases for the specific vulnerability is synthesized; the set of test cases includes a set of crash test cases and a set of non-crash test cases.
8. The system according to claim 7, characterized in that, The fusion analysis includes: semantically mapping the currently selected single target vulnerability description with the message format definition and parameter constraint rules in the target protocol knowledge elements to determine the specific location of the vulnerability in the protocol syntax structure; placing the mapped vulnerability point in the protocol state transition path defined by the state machine logic, and analyzing the state machine conflict paths or undefined states that may be caused by inserting abnormal inputs or violating constraints in the normal state sequence; based on the results of the association mapping and conflict detection, deriving the input condition sequence and state transition sequence required to trigger the vulnerability; and synthesizing specific test instructions, malformed message data, or abnormal interaction processes according to the derived triggerable path to construct the targeted attack vector.
9. The system according to claim 7, characterized in that, The feedback internalization unit, based on the protocol knowledge elements associated with the target vulnerability, compares and analyzes the crash test case set and the non-crash test case set to identify significant differences in input parameter values, protocol interaction sequences, and system state transitions. From these significant differences, it summarizes the key necessary or sufficient conditions that lead to the successful triggering of the system anomaly, as the vulnerability triggering rule. Simultaneously, based on the constraint rules in the protocol knowledge elements, it locates the input or logical restrictions that prevent the vulnerability from being triggered from the non-crash test case set, as the vulnerability avoidance rule. The vulnerability triggering rule and the vulnerability avoidance rule are structurally integrated to generate new test knowledge that is strongly associated with the target vulnerability and protocol context and can guide the optimization of test strategies. The new test knowledge is updated to the dynamic test knowledge base to optimize the generation of subsequent test strategies for the same or similar vulnerabilities.
10. The system according to claim 1, characterized in that, The autonomous optimization evolution is specifically achieved through a closed loop: New test knowledge generated by feedback and evolution steps is updated to the dynamic test knowledge base; The updated knowledge base directly impacts the generation and execution steps of the next round of testing strategies; Through continuous iteration, the test knowledge in the dynamic test knowledge base is constantly enriched, thereby driving the test strategy to become more targeted.
Citation Information
Cited By
A model vulnerability detection system and method for aerospace field
CN122286788A