A vulnerability cause positioning method based on intelligent debugging agent

Abstract

This invention discloses a vulnerability cause localization method based on an intelligent debugging agent. The aim is to use a debugging agent to debug programs based on crash samples, mine dynamic information during the debugging process, and provide further debugging instructions to accurately locate the vulnerability and output its cause. First, a vulnerability cause localization system based on an intelligent debugging agent is constructed. The system's debugging strategy guidance module selects breakpoint debugging, debugging information analysis, or vulnerability location confirmation strategies as debugging strategies through a round-robin mechanism. The debugging experience memory module introduces experience activity, enabling the large language model to continuously learn and evolve its knowledge, significantly improving the accuracy of locating and causing new vulnerabilities. This reduces the traditional "vulnerability discovery → manual debugging → location report" cycle of several days to minutes, effectively solving the efficiency problem between automated vulnerability discovery and manual debugging. This invention enables fully automated and accurate vulnerability cause localization.

Description

Technical Field

[0001] This invention relates to a method for locating the causes of vulnerabilities in software system security, specifically a method for locating the causes of vulnerabilities based on an intelligent debugging agent. Background Technology

[0002] The convergence of the digital economy and smart terminals has driven the widespread application of software systems in key areas such as industrial control, financial transactions, and the Internet of Things. The security of these software systems is inseparable from the stable operation of social infrastructure. Vulnerabilities are a key factor affecting software system security, and timely detection and patching of software vulnerabilities are crucial for improving software security. Large and complex software has a massive codebase, making traditional manual code auditing inefficient for vulnerability discovery. To improve the efficiency of software vulnerability discovery, researchers have conducted extensive research on automated software vulnerability discovery technologies, developing numerous automated vulnerability discovery tools that have achieved great success in recent years, with an increasing number of vulnerabilities being discovered by these tools.

[0003] Among automated vulnerability discovery tools, fuzzing is undoubtedly the most successful, considered to have discovered the most serious security vulnerabilities. However, automated vulnerability discovery techniques, represented by fuzzing, can only generate software crash samples. These samples can reveal the existence of vulnerabilities, but cannot provide information on the root causes. Vulnerability root causes contain information on the location and cause of the vulnerability, which is crucial for subsequent vulnerability remediation. In this case, crash samples must be analyzed and debugged to be transformed into the vulnerability root causes needed by software maintainers. Currently, the industry still relies on manual debugging and analysis by security experts for the massive number of crash samples discovered by automated tools and reported by security communities (such as Bugziila and CVEDetails). This manual debugging method is time-consuming and labor-intensive, resulting in excessively long software vulnerability remediation cycles, and many vulnerabilities cannot be remedied because their root causes cannot be located in time. Compared with the rapid development of automated vulnerability discovery technologies, automated root-cause analysis (RCA) has received relatively less attention. Currently, the technical approaches to automated root-cause analysis are mainly divided into two categories: non-statistical RCA and statistical RCA.

[0004] The first type of method, non-statistical RCA, employs program analysis techniques such as data flow analysis and symbolic execution, and uses customized rules to uncover the root causes of software vulnerabilities. For example, ARCUS uses symbolic execution and rule-based methods, detecting vulnerable states and ultimately locating potential vulnerabilities by testing "hypothetical" problems. However, because non-statistical RCA relies on source tracing analysis and predefined vulnerability identification rules, it suffers from low success rates, huge computational overhead, and low location accuracy in complex software execution flows (complex function call relationships, millions of instructions) and irreversible execution of some instructions (such as Xor eax, eax).

[0005] The second type of method, statistical RCA, overcomes the limitations of non-statistical RCA. Its core idea is that when executing a sample that causes a crash, it will inevitably encounter the program entity that caused the crash (e.g., statement, block, or predicate), while executing a non-crash sample will not trigger these program entities. The location of the vulnerability is inferred by analyzing the statistical correlation differences between the runtime program entities of crashed and non-crash samples. For example, AURORA (Statistical Crash Analysis for Automated Root Cause Explanation), a representative work in the field of statistical RCA, generates Boolean expressions that capture the runtime state of the program as predefined predicates and evaluates the predicate ranking based on their contribution to the crash. AURORA uses statistical techniques to generate a priority list of potential vulnerability causes based on the difference comparison results between crashed and non-crash samples generated by the fuzzing tool AFL. Racing (Racing on the Negative Force: Efficient Vulnerability Root-Cause Analysis through Reinforcement Learning on Counterexamples) builds upon AURORA by leveraging reinforcement learning to optimize fuzzy testing sample generation strategies and proposes a counterexample sampling method to accelerate the statistical analysis process. Statistical RCA heavily relies on the quality of positive and negative samples. However, fuzzing, as a sub-technique of software testing, is not specifically designed for generating positive and negative samples. Therefore, in scenarios requiring high-value positive and negative samples for causal localization, issues such as low sample generation quality and uneven sample distribution exist, limiting the effectiveness of statistical analysis-based causal localization methods. This results in statistical RCA being not only time-consuming and inefficient, but also, because statistical methods are essentially probabilistic inferences, and the inference results depend on the quality of positive and negative sample generation, statistical RCA outputs a relevance ranking of program entities. Vulnerability localization is calculated based on this relevance ranking, leading to relatively low vulnerability localization accuracy.

[0006] Currently, both non-statistical RCA and statistical RCA suffer from low vulnerability location accuracy, slow speed, and poor effectiveness, thus failing to find effective application in industrial security production. Due to these limitations, security experts in the industry still rely on manual debugging of software vulnerabilities, locating vulnerability positions, and providing cause analysis when faced with crash samples generated by vulnerability discovery tools. However, even for experienced security experts, manually debugging each software crash sample is a tedious and time-consuming task (usually taking tens of minutes or even hours), resulting in a significant consumption of software security resources in the debugging and analysis phase rather than vulnerability remediation. Therefore, the industry currently generally adopts expert debugging to solve the problem of vulnerability cause location. Furthermore, as can be seen from the concepts of non-statistical RCA and statistical RCA, existing automatic vulnerability cause location methods do not fully utilize the observation capabilities of debuggers and do not regard debugging as the core means of vulnerability cause location technology.

[0007] In summary, existing methods for locating vulnerability causes are generally incompatible with practical applications in this field. How to help security experts quickly and effectively locate vulnerabilities and thus promptly fix security risks is a hot topic being discussed by those skilled in the art. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide a vulnerability cause localization method based on an intelligent debugging agent. The debugging agent uses debugging tools to debug the program based on the crash sample, just like a human does. It mines dynamic information in the debugging process and automatically gives the next debugging instructions according to the debugging context, so as to accurately locate the vulnerability and output the cause of the vulnerability.

[0009] To address the aforementioned technical problems, this invention provides an automatic vulnerability cause localization method based on a smart debugging agent, comprising the following steps:

[0010] The first step involves constructing a vulnerability cause localization system based on an intelligent debugging agent. This system comprises a step-by-step debugging module, a debugging strategy guidance module, a debugging command output module, and a debugging experience memory module. The step-by-step debugging module includes a GDB (GNU Debugger) debugging submodule, a debugging information formatting submodule, and a debugging status analysis submodule. The debugging command output module includes a knowledge base construction submodule, a retrieval and matching submodule, and a debugging command generation submodule. The debugging experience memory module includes a long-term memory submodule and an experience feedback activation submodule. The debugging status analysis submodule, long-term memory submodule, and debugging command generation submodule all employ a large language model for intelligent reasoning. The large language model used must possess both deep code understanding and controllable structured output capabilities, be able to perform semantic induction, vector embedding, and command generation, and be able to stably return high-confidence results within milliseconds via a secure long-connection API. It should support private deployment to meet the real-time and confidentiality requirements of interactive debugging. The preferred large language model is GPT-3.5-turbo. The debugging status analysis submodule, long-term memory submodule, and debugging command generation submodule all use the same large language model.

[0011] The GDB debugging submodule is connected to the debugging information formatting submodule and the debugging instruction generation submodule. It contains GDB, receives the target binary program and test case PoC (Proof of Concept) input by the user, receives the debugging instruction sequence from the debugging instruction generation submodule, enables GDB to perform PoC injection on the target binary program according to the debugging instruction sequence, obtains the original debugging information, and sends the original debugging information to the debugging information formatting submodule.

[0012] The debug information formatting submodule is connected to the GDB debug submodule and the debug status analysis submodule. It receives raw debug information from the GDB debug submodule, formats the raw debug information to obtain a debug status quadruple, and sends the debug status quadruple to the debug status analysis submodule.

[0013] The debug status analysis submodule is connected to the debug information formatting submodule, the retrieval and matching submodule, and the long-term memory submodule. It receives debug status quadruples from the debug information formatting submodule, uses a large language model to infer and update the debug status quadruples to obtain debug status text, and sends the debug status text to the long-term memory submodule and the retrieval and matching submodule. It then sends the debug status quadruples to the retrieval and matching submodule, the debug strategy guidance module, and the debug instruction generation submodule.

[0014] The long-term memory submodule is connected to the debug status analysis submodule and the experience feedback activation submodule. It receives debug status text from the debug status analysis submodule, extracts key tags (including vulnerability type, function name, register exception, etc.) from the debug status text, and sends the experience memory quintuple to the experience feedback activation submodule.

[0015] The experience feedback activation submodule is connected to the long-term memory submodule and the knowledge base construction submodule. It receives the experience memory quintuple from the long-term memory submodule, converts the experience memory quintuple from experience temperature to experience activity, obtains the experience activity, updates the knowledge entries, and sends the knowledge entries to the knowledge base construction submodule.

[0016] The knowledge base construction submodule is connected to the experience feedback activation submodule and the retrieval matching submodule. It encapsulates vulnerability root cause key-value pairs extracted from open-source security knowledge in the form of quintuples to form knowledge entries, builds the knowledge base, and regularly obtains the latest vulnerability patterns and remediation solutions from open-source security knowledge. Combined with the knowledge entries received from the experience feedback activation submodule, it expands and updates the knowledge base.

[0017] The retrieval and matching submodule is connected to the knowledge base construction submodule, the debug status analysis submodule, the debug instruction generation submodule, and the debug strategy guidance submodule. It receives debug status quadruples and debug status text from the debug status analysis submodule. Using the debug status quadruples as query vectors, it performs semantic vector similarity retrieval and Top-K recall operations on the knowledge base in the knowledge base construction submodule to obtain the knowledge paragraphs most relevant to the debug status quadruples (called recalled knowledge). The recalled knowledge is then sent to the debug instruction generation submodule.

[0018] The debugging strategy guidance module is connected to the debugging instruction generation submodule and the debugging status analysis submodule. Based on the loop number i, it generates the corresponding debugging strategy prompt word in combination with the debugging status quadruple and sends the debugging strategy prompt word to the debugging instruction generation submodule.

[0019] The debugging instruction generation submodule is connected to the retrieval and matching submodule, the debugging strategy guidance submodule, the GDB debugging submodule, and the debugging status analysis submodule. It receives recall knowledge from the retrieval and matching submodule, debug status quadruples from the debugging status analysis submodule, and debugging strategy prompts from the debugging strategy guidance submodule. It combines the debug status quadruples, recall knowledge, and debugging strategy prompts into a joint context, decodes the joint context using a large language model, and returns a JSON response. If the JSON response indicates that debugging is complete, the cause of the vulnerability is confirmed, and the cause is output to the user. If the JSON response indicates that debugging is not complete, it generates a grammatically correct and policy-constrained debugging instruction sequence, sends the debugging instruction sequence to the GDB debugging submodule, and sends the JSON response to the debugging strategy guidance module.

[0020] The debugging status analysis submodule, long-term memory submodule, and debugging instruction generation submodule all integrate a large language model. The GDB debugging submodule in the step-by-step debugging module contains GDB. These four modules work together to form an intelligent debugging agent, achieving high real-time, high confidentiality, and high success rate vulnerability cause localization.

[0021] The second step involves building a security knowledge base using the knowledge base construction submodule. The method is as follows:

[0022] The knowledge base construction submodule extracts vulnerability root cause key-value pairs (vulnerability root cause description: corresponding debugging command) from open-source security knowledge (such as RCA literature, GDB debugging manual, CVE vulnerability database, and security patch announcements). Each vulnerability root cause key-value pair is a tuple (vulnerability root cause description, corresponding debugging command), in the form of (Heap Overflow: Set hardware write breakpoint at malloc return address), where "Heap Overflow" is the vulnerability root cause description, and "Set hardware write breakpoint at malloc return address" is the debugging command corresponding to "Heap Overflow". Each vulnerability root cause description maps to 1-3 community-verified high-efficiency GDB commands. Debugging commands, or "debugging techniques," encapsulate the correspondence between vulnerability root cause descriptions and corresponding debugging commands in the form of a 5-tuple (usage, desc, id, priority, comm), forming a knowledge entry. `usage` is the knowledge tag (e.g., heap overflow, UAF (Use-After-Free)); `desc` is the knowledge (in this case, the vulnerability root cause) description; `id` is the unique identifier of the knowledge; `priority` represents the knowledge activity level, where `priority` ∈ [0,1], indicating the frequency and recent utility of the knowledge entry being successfully invoked and contributing to root cause localization in historical debugging: the closer the value is to 1, the more frequently it has been hit and the closer it is to the last use; `comm` is the corresponding GDB debugging command. The knowledge entry is placed in the security knowledge base, which initially contains N knowledge entries, where N > 500.

[0023] The third step is to set the loop iteration i to 1 in the debug instruction generation submodule.

[0024] The fourth step is for the debug instruction generation submodule to output a sequence of debug instructions to the GDB debug submodule, including three debug instructions: ① symbol-file <target>This means for the loaded binary. <target>① Load the debug symbol table so that GDB can resolve function names, variable names, and source code line numbers; ② Set disassembly-flavor intel, which means setting the disassembly output format to Intel style for easier reading and analysis; ③ Run <poc>This means starting the target binary program and putting... <poc>Passed to the process to reproduce the crash and collect the initial debug state, generating the first round of the initial debug state quadruple Q1.

[0025] The fifth step involves the GDB debugging submodule receiving the target binary program and test case PoC from the user. It then executes the instruction sequence received from the debugging instruction generation submodule, generating raw debugging information. This raw debugging information is a GDB / MI record stream (MI stands for Machine Interface), formatted in GDB's machine-oriented JSON style. The raw debugging information includes program crash signals, registers, and memory addresses. This raw debugging information is then sent to the debugging information formatting submodule.

[0026] Step 6: The debug information formatting submodule receives the raw debug information from the GDB debug submodule, formats the raw debug information, and obtains the four-tuple Q of the i-th round debug state. i Q i Sending to the debug status analysis submodule is done as follows:

[0027] Step 6.1 Use regular expressions to perform structured parsing on the original debugging information, extracting crash signals, stack frames, memory addresses, register values, and source code location information. Convert the register values ​​and memory addresses into JSON-formatted serialized program states to obtain the vulnerability type, program state, execution address or source code line number, and context assembly instructions, generating the i-th round of debugging state quadruple Q. i ;

[0028]

[0029] Among them, Desc i State represents the vulnerability type identified in the i-th round of debugging. i This is a JSON object representing the program state during the i-th round of debugging, containing register values ​​and memory addresses, Loc. i Inst is the execution address or source code line number in the i-th round of debugging. i For the context assembly instructions in the i-th round of debugging.

[0030] Step 6.2 will Q i Send to the debug status analysis submodule.

[0031] Step 7: The debug status analysis submodule receives Q from the debug information formatting submodule. i Using a large language model to analyze Q i Perform inference updates to obtain the i-th round of debug state text q. i , q i Send Q to the retrieval matching submodule and the long-term memory submodule. i The method for sending the code to the retrieval and matching submodule, the debugging strategy guidance module, and the debugging instruction generation submodule is as follows:

[0032] Step 7.1 The debug status analysis submodule analyzes the Q... i Construct a prompt word for the large language model, the content of which is "Current debugging state is {Desc i }, the debugging location is {Loc i }, the register value is {State i }, the assembly instruction is {Inst i }” ,

[0033] Step 7.2 The large language model prompts the word "Current debugging state is {Desc}". i }, the debugging location is {Loc i }, the register value is {State i }, the assembly instruction is {Inst i }” performs semantic induction and vulnerability pattern matching to generate the i-th round of debug status text q i to replace Desc i And it serves as the sole keyword for subsequent knowledge retrieval, experience memory, and root cause localization. i It is a natural language vulnerability status description, such as "Heap overflow vulnerability: write length exceeds allocated space".

[0034] Step 7.3 will q i Send Q to the retrieval and matching submodule and the long-term memory submodule. i Send to the retrieval and matching submodule, the debugging strategy guidance module, and the long-term memory submodule.

[0035] Step 8: When the debugging experience memory module is greater than 2, it activates the experience accumulation mechanism to accumulate the "successful experiences" of this round into reusable knowledge and continuously update the knowledge base. The method is as follows:

[0036] Step 8.1 If i≤2, proceed directly to step 9; if i>2, proceed to step 8.2.

[0037] Step 8.2 The long-term memory submodule receives q from the debug state analysis submodule. i The system calls a large language model to generate an experience memory quintuple (debugscrip, experi, Id, tempe, comm) and sends it to the experience feedback activation submodule. Here, debugscrip is the "snapshot script" for the i-th round of debugging, summarizing the current crash signal, trigger function, and key register values ​​in natural language for subsequent retrieval and matching; experi is an experience-level summary text explaining "why executing this round of instruction sequences can advance the root cause location of the vulnerability"; Id is a unique identifier assigned to the experience memory quintuple; tempe is the "experience temperature," ranging from {0,1}, where tempe is 1 if the vulnerability is successfully located in this round, and 0 otherwise; and comm is the GDB command that actually generates value.

[0038] Step 8.3 The Experience Feedback Activation Submodule receives the experience memory quintuple from the Long-Term Memory Submodule, reads its debug script, automatically infers the knowledge tag usage, and searches the knowledge base in the knowledge base construction module. If there is no knowledge entry containing usage in the knowledge base, the knowledge activity priority of the (i-1)th round is adjusted. i-1 Set the value to 0, and set the historical call frequency Δt of the knowledge entry containing usage to 0, then proceed to step 8.4; if there is a knowledge entry containing usage in the knowledge base, let Δt = i - i', where i' is the number of rounds the knowledge entry containing usage was last called, then proceed to step 8.4.

[0039] Step 8.4 Calculate the knowledge activity priority of the i-th round using formula (2). i :

[0040]

[0041] Where β∈[0,1] is the historical weight coefficient, which is 0.8 by default. For exponentially decaying terms, the larger Δt is (the longer the time since the last call), the better. −λ·Δt The closer the value is to 0, the faster the knowledge activity priority decreases, achieving the effect of "forgetting if not used for a long time". λ is the decay rate, which is 0.01 by default.

[0042] Step 8.5 Set priority = priority i Take the knowledge tag usage obtained in step 8.3, set desc to experience in the quintuple generated in step 8.2, set id to Id in the quintuple generated in step 8.2, combine usage, desc, id with comm and priority in the quintuple generated in step 8.2 to get a new quintuple (usage, desc, id, priority, comm), convert (usage, desc, id, priority, comm) into a knowledge item, and send the knowledge item to the knowledge base construction submodule.

[0043] Step 9: The knowledge base construction submodule updates the security knowledge base periodically (T). The method is as follows:

[0044] Step 9.1 The knowledge base construction submodule receives knowledge entries from the experience feedback activation submodule;

[0045] Step 9.2 The knowledge base construction submodule determines whether the period T has been reached, which is generally 24 hours. If not, proceed to step 10; if the period T has been reached, proceed to step 9.3.

[0046] Step 9.3 The knowledge base construction submodule obtains the latest vulnerability patterns and remediation solutions from the CVE vulnerability database, security patch announcements, etc., and performs attribute normalization processing on the knowledge entries received from the experience feedback activation submodule. That is, the latest vulnerability patterns and remediation solutions are cleaned and formatted according to the format of the knowledge entries: first, the vulnerability type is identified as usage using regular expressions, and the CVE number is taken as the id prefix. Then, key functions or variables are extracted from the code of the remediation solution as comm candidates. Next, the root cause and remediation points are summarized using the same large language model to generate desc. When there is no GDB command in the latest vulnerability patterns and remediation solutions obtained from the CVE vulnerability database, security patch announcements, etc., a GDB command is automatically added as comm. The priority is uniformly written as 0.5, thus obtaining a regular quintuple. The attribute-normalized knowledge entries are added to the security knowledge base, and then proceed to step 9.1.

[0047] Step 10: The retrieval and matching submodule receives the Q from the debug state analysis submodule. i and q i , with Q i To retrieve the query vector, semantic vector similarity retrieval and Top-K recall operations are performed on the knowledge base in the knowledge base construction submodule to obtain the result with respect to Desc. i The most relevant recall knowledge is sent to the debug instruction generation submodule, using the following method:

[0048] Step 10.1 The matching submodule receives the i-th round debug state quadruple Q from the debug state analysis submodule. i With debug status text q i .

[0049] Step 10.2 Retrieve the matching submodule based on Q i Desc in i The vulnerability type shown is retrieved from the knowledge base, and results are filtered out from the knowledge base that match Desc. i Knowledge entries with completely identical vulnerability types are used to obtain a subset K of knowledge entries.

[0050] , serving as a candidate space for subsequent similarity calculations Is with Desc i The j-th knowledge entry of the same vulnerability type shown. express Vulnerability type, Q i .Desc i Q represents i Desc in i The vulnerability types shown are 1≤j≤J, where J is the number of knowledge entries in K.

[0051] Step 10.3 Calculate q sequentially i The weighted similarity with all knowledge entries in K is used to obtain J weighted similarities, where q i and The weighted similarity sim(q) i , k j Calculate according to formula (3):

[0052] Where emb(q) i ) represents q i The text embedding vector, emb(k) j .desc i ) is the j-th knowledge entry k in K. j desc i The text embedding vector, where α is the weight coefficient balancing semantic similarity and knowledge activity, α∈[0,1], with a default value of 0.7, k j .priority is k j Knowledge activity within.

[0053] Step 10.4 Sort the J weighted similarities obtained in Step 10.3 in descending order, and arrange the J knowledge items in K in descending order of weighted similarity to obtain a subset KK of sorted knowledge items. Take the top TT (TT ∈ [5, 10] and be an integer; if there are less than 5 items, take all) highest matching knowledge items from KK, encapsulate these TT highest matching knowledge items and their corresponding weighted similarities into recall knowledge, and send the recall knowledge to the debugging instruction generation submodule.

[0054] Step 11: The debugging strategy guidance module receives the debugging status quadruple Qᵢ from the debugging status analysis submodule. Based on i, it selects one of three debugging strategies—breakpoint debugging, debugging information analysis, or vulnerability location confirmation—as the debugging strategy using a round-robin mechanism. Each round activates one of these three strategies sequentially, and the debugging strategy prompt is sent to the debugging instruction generation submodule, ensuring that the debugging process alternates between "breadth-depth-verification." The method is as follows:

[0055] Step 11.1 Receive the debug state quadruple Qᵢ from the debug state analysis submodule, and let variable kk = i mod 3;

[0056] Step 11.2 If kk=1, proceed to step 11.3; if kk=2, proceed to step 11.4; if kk=0, proceed to step 11.5.

[0057] Step 11.3 Employ breakpoint debugging strategy for Q i Loc in i Analysis yields the crash call chain C. (i.e., the sequence of function calls when the program crashes, f) m Let M be the m-th crashing function when the program crashes, where M is the total number of crashing functions in the crash call chain C. The debugging strategy guidance module finds the entry address of the function in C that has not yet been set with a breakpoint, generates a debugging strategy prompt for the conditional breakpoint command, and tells the large language model in the debugging instruction generation submodule which function entry point should be set as the next breakpoint; the debugging strategy prompt is sent to the debugging instruction generation submodule to constrain the large language model sampling space. Proceed to step 12.

[0058] Step 11.4 Employ debugging information analysis strategies to analyze the register and memory state changes ΔState when the i-th breakpoint is triggered. , This is a snapshot of the registers and memory read in the i-th round. Debug the register and memory snapshot read in the (i-1)th round (ΔState reflects the change in variables / registers) (for example, when i=2, i.e. when the debugging information analysis strategy is used for the first time, debug the register and memory state when the breakpoint is hit in the first round), obtain the debugging strategy prompt word for generating the next debugging instruction for observation or comparison, send the debugging strategy prompt word to the debugging instruction generation submodule, and go to step 12;

[0059] Step 11.5 Receive the JSON response from the instruction generation submodule (at this point, kk=0, indicating that i is at least 3, and a JSON response has already been generated in subsequent step 12.2). Use the vulnerability location and confirmation strategy to check the same suspicious instruction address V that has appeared in two consecutive rounds. a (V) a (Directly taken from the "va" field in the JSON response output of the submodule generated by the previous round of debugging instructions) and V a The five assembly contexts are combined to form the policy prompt word for the reproduction-verification command. The policy prompt word is then sent to the debug instruction generation submodule. Proceed to step 12.

[0060] Step 12: The debug instruction generation submodule receives debug policy prompts from the debug policy guidance module, TT recall knowledge from the retrieval and matching submodule, and quadruplets Q1, ..., Q from the debug status analysis submodule. i The debugging strategy prompts, recall knowledge, and quadruples are serialized using a JSON-Schema-enforced template and fed into the large language model. The large language model decodes the code under the dual constraints of strategy and knowledge, outputting a JSON response that conforms to the pattern. This JSON response is then sent to the debugging strategy guidance module, where `i` is incremented by 1. If the JSON response indicates that the vulnerability cause has been located or `i > max_step`, then `max_step` is incremented. p is If the maximum threshold number of steps is reached, proceed to step thirteen; if the cause of the vulnerability is not successfully located and i ≤ max_step, proceed to step five. The method is:

[0061] Step 12.1 The debug instruction generation submodule receives debug strategy prompts from the debug strategy guidance module, TT recall knowledge from the retrieval and matching submodule, and the quadruple Q from the debug status analysis submodule. i Q i Place them into a set of four tuples Q, Q = {Q1, ..., Q2}. i } ;

[0062] Step 12.2 involves processing the debugging strategy prompts, recall knowledge, and quadruple Q received in step 12.1. i The template is enforced using JSON-Schema (i.e., a three-part prompt: "role-context-constraint"); context: {Qi, recall knowledge, ...} Debugging strategy prompts}; constraint: "Should return JSON {status:(completed|continue),SourceLoc?,Desc?,next_cmds:[]}") After serialization, it is sent to the large language model. The large language model performs one-time inference, outputs a JSON response, and sends the JSON response to the debugging strategy guidance module. If the JSON response returns the field "status" as "completed" and there are non-empty "SourceLoc" and "Desc" fields, it is determined that the cause of the vulnerability has been located. Here, SourceLoc represents the line number of the source code where the vulnerability is located, and Desc is a natural language vulnerability cause summary generated by the large language model for the target binary program, which is different from the desc in the knowledge entry in the knowledge base. Proceed to step 12.3; If the JSON response returns the field "status" as "completed" and there are any empty "SourceLoc" and "Desc" fields, it means that the vulnerability location is incomplete. Proceed to step 12.4; If the JSON response returns the field "status" as "continue", then proceed to step 12.4;

[0063] Step 12.3 Encapsulate "SourceLoc" and "Desc" in the JSON response into a tuple (SourceLoc,Desc) as the vulnerability cause output, then proceed to step thirteen;

[0064] Step 12.4 Parse the atomic GDB debugging instruction sequence in the "next_cmds" field of the JSON response. Let i = i + 1. If i ≤ max_step, then max_step... p = 15~20, then the atomic-level GDB debugging instruction sequence is sent to the GDB debugging submodule, and proceed to step 5: if i>max_step, it means the loop count has been reached, and the current best guess (i.e., Q) is forcibly output. max_step The most suspicious instruction address and its corresponding natural language description) are reported as the root cause of the vulnerability. This ensures convergence within a finite step size and avoids infinite debugging. Proceed to step thirteen.

[0065] Step thirteen, the end.

[0066] The following technical effects can be achieved by using this invention:

[0067] 1. The first step of this invention is to construct a vulnerability cause localization system based on a smart debugging agent that integrates dynamic debugging, intelligent reasoning and experience memory. This system can achieve fully automatic and accurate localization of vulnerability causes. The step-by-step debugging module and the debugging command output module form a millisecond-level closed-loop interaction. The large language model directly performs semantic understanding and controllable structured command generation on the debugging state quadruple. This completely skips the path explosion and SMT solution overhead of traditional symbolic execution (such as the Racing system) in deep call chains and with a scale of millions of instructions, thereby eliminating the computational bottleneck.

[0068] 2. The debugging strategy guidance module selects breakpoint debugging strategy, debugging information analysis strategy, or vulnerability location confirmation strategy as the debugging strategy through a round-robin mechanism, ensuring that the debugging process focuses on key tasks at different stages and avoids ineffective exploration; the debugging experience memory module introduces experience activity and weighted similarity, enabling the large language model to have continuous learning and knowledge evolution capabilities, which significantly improves the accuracy of locating new vulnerabilities and their causes.

[0069] 3. This invention only requires a single crash test case to work, without the need for high-quality non-crash samples, and is not limited to specific vulnerability types; the large language model outputs source code line numbers and natural language interpretation at once, eliminating the need for manual reproduction, manual backtracking and report writing, compressing the traditional "vulnerability discovery → manual debugging → location report" cycle of several days to minutes, effectively solving the efficiency problem between automated vulnerability discovery and manual debugging. Attached Figure Description

[0070] Figure 1 This is the overall flowchart of the present invention.

[0071] Figure 2 This is the logical structure diagram of the vulnerability cause localization system based on the intelligent debugging agent constructed in the first step of this invention. Detailed Implementation

[0072] The present invention will now be described with reference to the accompanying drawings.

[0073] like Figure 1 As shown, the automatic vulnerability cause localization method based on intelligent debugging agent of the present invention includes the following steps:

[0074] The first step is to build a vulnerability cause localization system based on intelligent debugging agents. This system, for example... Figure 2 As shown, the system comprises a step-by-step debugging module, a debugging strategy guidance module, a debugging instruction output module, and a debugging experience memory module. The step-by-step debugging module includes a GDB debugging submodule, a debugging information formatting submodule, and a debugging status analysis submodule. The debugging instruction output module includes a knowledge base construction submodule, a retrieval and matching submodule, and a debugging instruction generation submodule. The debugging experience memory module includes a long-term memory submodule and an experience feedback activation submodule. The debugging status analysis submodule, long-term memory submodule, and debugging instruction generation submodule all employ a large language model for intelligent reasoning. In this embodiment, the large language model used is GPT-3.5-turbo. The debugging status analysis submodule, long-term memory submodule, and debugging instruction generation submodule all use the same large language model.

[0075] The GDB debugging submodule is connected to the debugging information formatting submodule and the debugging instruction generation submodule. It contains GDB, receives the target binary program and test case PoC input by the user, receives the debugging instruction sequence from the debugging instruction generation submodule, enables GDB to perform PoC injection on the target binary program according to the debugging instruction sequence, obtains the original debugging information, and sends the original debugging information to the debugging information formatting submodule.

[0076] The debug information formatting submodule is connected to the GDB debug submodule and the debug status analysis submodule. It receives raw debug information from the GDB debug submodule, formats the raw debug information to obtain a debug status quadruple, and sends the debug status quadruple to the debug status analysis submodule.

[0077] The debug status analysis submodule is connected to the debug information formatting submodule, the retrieval and matching submodule, and the long-term memory submodule. It receives debug status quadruples from the debug information formatting submodule, uses a large language model to infer and update the debug status quadruples to obtain debug status text, and sends the debug status text to the long-term memory submodule and the retrieval and matching submodule. It then sends the debug status quadruples to the retrieval and matching submodule, the debug strategy guidance module, and the debug instruction generation submodule.

[0078] The long-term memory submodule is connected to the debug status analysis submodule and the experience feedback activation submodule. It receives debug status text from the debug status analysis submodule, extracts key tags (including vulnerability type, function name, register exception, etc.) from the debug status text, and sends the experience memory quintuple to the experience feedback activation submodule.

[0079] The experience feedback activation submodule is connected to the long-term memory submodule and the knowledge base construction submodule. It receives the experience memory quintuple from the long-term memory submodule, converts the experience memory quintuple from experience temperature to experience activity, obtains the experience activity, updates the knowledge entries, and sends the knowledge entries to the knowledge base construction submodule.

[0080] The knowledge base construction submodule is connected to the experience feedback activation submodule and the retrieval matching submodule. It encapsulates vulnerability root cause key-value pairs extracted from open-source security knowledge in the form of quintuples to form knowledge entries, builds the knowledge base, and regularly obtains the latest vulnerability patterns and remediation solutions from open-source security knowledge. Combined with the knowledge entries received from the experience feedback activation submodule, it expands and updates the knowledge base.

[0081] The retrieval and matching submodule is connected to the knowledge base construction submodule, the debug status analysis submodule, the debug instruction generation submodule, and the debug strategy guidance submodule. It receives debug status quadruples and debug status text from the debug status analysis submodule. Using the debug status quadruples as query vectors, it performs semantic vector similarity retrieval and Top-K recall operations on the knowledge base in the knowledge base construction submodule to obtain the knowledge paragraphs most relevant to the debug status quadruples (called recalled knowledge). The recalled knowledge is then sent to the debug instruction generation submodule.

[0082] The debugging strategy guidance module is connected to the debugging instruction generation submodule and the debugging status analysis submodule. Based on the loop number i, it generates the corresponding debugging strategy prompt word in combination with the debugging status quadruple and sends the debugging strategy prompt word to the debugging instruction generation submodule.

[0083] The debugging instruction generation submodule is connected to the retrieval and matching submodule, the debugging strategy guidance submodule, the GDB debugging submodule, and the debugging status analysis submodule. It receives recall knowledge from the retrieval and matching submodule, debug status quadruples from the debugging status analysis submodule, and debug strategy prompts from the debugging strategy guidance submodule. It combines the debug status quadruples, recall knowledge, and debug strategy prompts into a joint context, decodes the joint context using a large language model, and the large language model returns a JSON field. If the JSON field indicates that debugging is complete, the cause of the vulnerability is confirmed, and the cause of the vulnerability is output to the user. If the JSON field indicates that debugging is not complete, a debugging instruction sequence that conforms to the syntax and is constrained by the policy is generated, and the debugging instruction sequence is sent to the GDB debugging submodule.

[0084] The debugging status analysis submodule, long-term memory submodule, and debugging instruction generation submodule all integrate a large language model. The GDB debugging submodule in the step-by-step debugging module contains GDB. These four modules work together to form an intelligent debugging agent, achieving high real-time, high confidentiality, and high success rate vulnerability cause localization.

[0085] The second step involves building a security knowledge base using the knowledge base construction submodule. The method is as follows:

[0086] The knowledge base construction submodule extracts vulnerability root cause key-value pairs (vulnerability root cause description: corresponding debugging command) from open-source security knowledge (such as RCA-related literature, GDB debugging manuals, CVE vulnerability databases, and security patch announcements). Each vulnerability root cause key-value pair is a tuple (vulnerability root cause description, vulnerability corresponding debugging command). Each vulnerability root cause description maps to 1-3 community-verified, high-efficiency GDB commands. Debugging commands, or "debugging techniques," encapsulate the correspondence between vulnerability root cause descriptions and corresponding debugging commands in the form of a 5-tuple (usage, desc, id, priority, comm), forming a knowledge entry. `usage` is the knowledge tag, `desc` is the knowledge description, `id` is the unique identifier of the knowledge, and `priority` represents the knowledge activity level. `priority` ∈ [0,1] indicates the frequency and recent utility of the knowledge entry being successfully invoked and contributing to root cause localization in historical debugging: the closer the value is to 1, the more frequently it has been hit and the closer it is to the last use. `comm` is the corresponding GDB debugging command. The knowledge entries are placed in the security knowledge base, which initially contains N knowledge entries, where N > 500.

[0087] The third step is to set the loop iteration i to 1 in the debug instruction generation submodule.

[0088] The fourth step is for the debug instruction generation submodule to output a sequence of debug instructions to the GDB debug submodule, including three debug instructions: ① symbol-file <target>This means for the loaded binary. <target>① Load the debug symbol table so that GDB can resolve function names, variable names, and source code line numbers; ② Set disassembly-flavor intel, which means setting the disassembly output format to Intel style for easier reading and analysis; ③ Run <poc>This means starting the target binary program and putting... <poc>Passed to the process to reproduce the crash and collect the initial debug state, generating the first round of the initial debug state quadruple Q1.

[0089] The fifth step involves the GDB debugging submodule receiving the target binary program and test case PoC from the user. It then executes the instruction sequence received from the debugging instruction generation submodule, generating raw debugging information. This raw debugging information is a GDB / MI record stream (MI stands for Machine Interface), formatted in GDB's machine-oriented JSON style. The raw debugging information includes program crash signals, registers, and memory addresses. This raw debugging information is then sent to the debugging information formatting submodule.

[0090] Step 6: The debug information formatting submodule receives the raw debug information from the GDB debug submodule, formats the raw debug information, and obtains the four-tuple Q of the i-th round debug state. i Q i Sending to the debug status analysis submodule is done as follows:

[0091] Step 6.1 Use regular expressions to perform structured parsing on the original debugging information, extracting crash signals, stack frames, memory addresses, register values, and source code location information. Convert the register values ​​and memory addresses into JSON-formatted serialized program states to obtain the vulnerability type, program state, execution address or source code line number, and context assembly instructions, generating the i-th round of debugging state quadruple Q. i ;

[0092]

[0093] Among them, Desc i State represents the vulnerability type identified in the i-th round of debugging. i This is a JSON object representing the program state during the i-th round of debugging, containing register values ​​and memory addresses, Loc. i Inst is the execution address or source code line number in the i-th round of debugging. i For the context assembly instructions in the i-th round of debugging.

[0094] Step 6.2 will Q i Send to the debug status analysis submodule.

[0095] Step 7: The debug status analysis submodule receives Q from the debug information formatting submodule. i Using a large language model to analyze Q i Perform inference updates to obtain the i-th round of debug state text q. i , q i Send Q to the retrieval matching submodule and the long-term memory submodule. i The method for sending the code to the retrieval and matching submodule, the debugging strategy guidance module, and the debugging instruction generation submodule is as follows:

[0096] Step 7.1 The debug status analysis submodule analyzes the Q... i Construct a prompt word for the large language model, the content of which is "Current debugging state is {Desc i }, the debugging location is {Loc i }, the register value is {State i }, the assembly instruction is {Inst i }” ,

[0097] Step 7.2 The large language model prompts the word "Current debugging state is {Desc}". i }, the debugging location is {Loc i }, the register value is {State i }, the assembly instruction is {Inst i }” performs semantic induction and vulnerability pattern matching to generate the i-th round of debug status text q i to replace Desc i And it serves as the sole keyword for subsequent knowledge retrieval, experience memory, and root cause localization. i It is a natural language vulnerability status description, such as "Heap overflow vulnerability: write length exceeds allocated space".

[0098] Step 7.3 will q i Send Q to the retrieval and matching submodule and the long-term memory submodule. i Send to the retrieval and matching submodule, the debugging strategy guidance module, and the long-term memory submodule.

[0099] Step 8: When the debugging experience memory module is greater than 2, it activates the experience accumulation mechanism to accumulate the "successful experiences" of this round into reusable knowledge and continuously update the knowledge base. The method is as follows:

[0100] Step 8.1 If i≤2, proceed directly to step 9; if i>2, proceed to step 8.2.

[0101] Step 8.2 The long-term memory submodule receives q from the debug state analysis submodule. i The system calls a large language model to generate an experience memory quintuple (debugscrip, experi, Id, tempe, comm) and sends it to the experience feedback activation submodule. Here, debugscrip is the "snapshot script" for the i-th round of debugging, summarizing the current crash signal, trigger function, and key register values ​​in natural language for subsequent retrieval and matching; experi is an experience-level summary text explaining "why executing this round of instruction sequences can advance the root cause location of the vulnerability"; Id is a unique identifier assigned to the experience memory quintuple; tempe is the "experience temperature," ranging from {0,1}, where tempe is 1 if the vulnerability is successfully located in this round, and 0 otherwise; and comm is the GDB command that actually generates value.

[0102] Step 8.3 The Experience Feedback Activation Submodule receives the experience memory quintuple from the Long-Term Memory Submodule, reads its debug script, automatically infers the knowledge tag usage, and searches the knowledge base in the knowledge base construction module. If there is no knowledge entry containing usage in the knowledge base, the knowledge activity priority of the (i-1)th round is adjusted. i-1 Set the value to 0, and set the historical call frequency Δt of the knowledge entry containing usage to 0, then proceed to step 8.4; if there is a knowledge entry containing usage in the knowledge base, let Δt = i - i', where i' is the number of rounds the knowledge entry containing usage was last called, then proceed to step 8.4.

[0103] Step 8.4 Calculate the knowledge activity priority of the i-th round using formula (2). i :

[0104]

[0105] Where β∈[0,1] is the historical weight coefficient, which is 0.8 by default. The term is an exponential decay term. The larger Δt is (the longer it has been since the last call), the closer it is to 0, which causes the knowledge activity priority to drop rapidly, achieving the effect of "forgetting if not used for a long time". λ is the decay rate, which is 0.01 by default.

[0106] Step 8.5 Set priority = priority i Take the knowledge tag usage obtained in step 8.3, set desc to experience in the quintuple generated in step 8.2, set id to Id in the quintuple generated in step 8.2, combine usage, desc, id with comm and priority in the quintuple generated in step 8.2 to get a new quintuple (usage, desc, id, priority, comm), convert (usage, desc, id, priority, comm) into a knowledge item, and send the knowledge item to the knowledge base construction submodule.

[0107] Step 9: The knowledge base construction submodule updates the security knowledge base periodically (T). The method is as follows:

[0108] Step 9.1 The knowledge base construction submodule receives knowledge entries from the experience feedback activation submodule;

[0109] Step 9.2 The knowledge base construction submodule determines whether the period T has been reached, which is generally 24 hours. If not, proceed to step 10; if the period T has been reached, proceed to step 9.3.

[0110] Step 9.3 The knowledge base construction submodule obtains the latest vulnerability patterns and remediation solutions from the CVE vulnerability database, security patch announcements, etc., and performs attribute normalization processing on the knowledge entries received from the experience feedback activation submodule. That is, the latest vulnerability patterns and remediation solutions are cleaned and formatted according to the format of the knowledge entries: first, the vulnerability type is identified and used as usage using regular expressions, and the CVE number is taken as the id prefix. Then, key functions or variables are extracted from the code of the remediation solution as comm candidates. Next, the root cause and remediation points are summarized using the same large language model to generate desc. When there is no GDB command in the latest vulnerability patterns and remediation solutions obtained from the CVE vulnerability database, security patch announcements, etc., a GDB command is automatically added as comm. The priority is uniformly written as 0.5, thus obtaining a regular quintuple. The attribute-normalized knowledge entries are added to the security knowledge base, and then proceed to step 9.1.

[0111] Step 10: The retrieval and matching submodule receives the Q from the debug state analysis submodule. i and q i , with Q i To retrieve the query vector, semantic vector similarity retrieval and Top-K recall operations are performed on the knowledge base in the knowledge base construction submodule to obtain the result with respect to Desc. i The most relevant recall knowledge is sent to the debug instruction generation submodule, using the following method:

[0112] Step 10.1 The matching submodule receives the i-th round debug state quadruple Q from the debug state analysis submodule. i With debug status text q i .

[0113] Step 10.2 Retrieve the matching submodule based on Q i Desc in i The vulnerability type shown is retrieved from the knowledge base, and results are filtered out from the knowledge base that match Desc. i Knowledge entries with completely identical vulnerability types are used to obtain a subset K of knowledge entries. , serving as a candidate space for subsequent similarity calculations Is with Desc i The j-th knowledge entry of the same vulnerability type shown. express Vulnerability type, Q i .Desc i Q represents i Desc in i The vulnerability types shown are 1≤j≤J, where J is the number of knowledge entries in K.

[0114] Step 10.3 Calculate q sequentially i The weighted similarity with all knowledge entries in K is used to obtain J weighted similarities, where q i and The weighted similarity sim(q) i , k j Calculate according to formula (3):

[0115] Where emb(q) i ) represents q i The text embedding vector, emb(k) j .desc i ) is the j-th knowledge entry k in K. j desc i The text embedding vector, where α is the weight coefficient balancing semantic similarity and knowledge activity, α∈[0,1], with a default value of 0.7, k j .priority is k j Knowledge activity within.

[0116] Step 10.4 Sort the J weighted similarities obtained in Step 10.3 in descending order, and arrange the J knowledge items in K in descending order of weighted similarity to obtain a subset KK of sorted knowledge items. Take the top TT (TT ∈ [5, 10] and be an integer; if there are less than 5 items, take all) highest matching knowledge items from KK, encapsulate these TT highest matching knowledge items and their corresponding weighted similarities into recall knowledge, and send the recall knowledge to the debugging instruction generation submodule.

[0117] Step 11: The debugging strategy guidance module receives the debugging status quadruple Qᵢ from the debugging status analysis submodule. Based on i, it selects one of three debugging strategies—breakpoint debugging, debugging information analysis, or vulnerability location confirmation—as the debugging strategy using a round-robin mechanism. Each round activates one of these three strategies sequentially, and the debugging strategy prompt is sent to the debugging instruction generation submodule, ensuring that the debugging process alternates between "breadth-depth-verification." The method is as follows:

[0118] Step 11.1 Receive the debug state quadruple Qᵢ from the debug state analysis submodule, and let variable kk = i mod 3;

[0119] Step 11.2 If kk=1, proceed to step 11.3; if kk=2, proceed to step 11.4; if kk=0, proceed to step 11.5.

[0120] Step 11.3 Employ breakpoint debugging strategy for Q i Loc in i Analysis yields the crash call chain C. (i.e., the sequence of function calls when the program crashes, f) m Let M be the m-th crashing function when the program crashes, where M is the total number of crashing functions in the crash call chain C. The debugging strategy guidance module finds the entry address of the function in C that has not yet been set with a breakpoint, and generates a debugging strategy prompt word for the conditional breakpoint command to tell the large language model in the debugging instruction generation submodule which function entry point should be set as the next breakpoint; the debugging strategy prompt word is sent to the debugging instruction generation submodule to constrain the large language model sampling space. Proceed to step 12.

[0121] Step 11.4 Employ debugging information analysis strategies to analyze the register and memory state changes ΔState when the i-th breakpoint is triggered. , This is a snapshot of the registers and memory read in the i-th round. Debug the register and memory snapshot read in the (i-1)th round (ΔState reflects the change in variables / registers) (for example, when i=2, i.e. when the debugging information analysis strategy is used for the first time, debug the register and memory state when the breakpoint is hit in the first round), obtain the debugging strategy prompt word for generating the next debugging instruction for observation or comparison, send the debugging strategy prompt word to the debugging instruction generation submodule, and go to step 12;

[0122] Step 11.5 Receive the JSON response from the debug instruction generation submodule, and use the vulnerability location and confirmation strategy to check the same suspicious instruction address V that has appeared in two consecutive rounds. a , and V a The five assembly contexts are combined to form the policy prompt word for the reproduction-verification command. The policy prompt word is then sent to the debug instruction generation submodule. Proceed to step 12.

[0123] Step 12: The debug instruction generation submodule receives debug policy prompts from the debug policy guidance module, TT recall knowledge from the retrieval and matching submodule, and quadruplets Q1, ..., Q from the debug status analysis submodule. i The debugging strategy prompts, recall knowledge, and quadruples are serialized using a JSON-Schema-enforced template and fed into the large language model. The large language model decodes the code under the dual constraints of strategy and knowledge, outputting a JSON response that conforms to the pattern. This JSON response is then sent to the debugging strategy guidance module, where `i` is incremented by 1. If the JSON response indicates that the vulnerability cause has been located or `i > max_step`, then `max_step` is incremented. p is If the maximum threshold number of steps is reached, proceed to step thirteen; if the cause of the vulnerability is not successfully located and i ≤ max_step, proceed to step five. The method is:

[0124] Step 12.1 The debug instruction generation submodule receives debug strategy prompts from the debug strategy guidance module, TT recall knowledge from the retrieval and matching submodule, and the quadruple Q from the debug status analysis submodule. i Q i Place them into a set of four tuples Q, Q = {Q1, ..., Q2}. i } ;

[0125] Step 12.2 involves processing the debugging strategy prompts, recall knowledge, and quadruple Q received in step 12.1. i The template is enforced using JSON-Schema (i.e., a three-part prompt: "role-context-constraint"); context: {Qi, recall knowledge, ...} Debugging strategy prompts}; constraint: "Should return JSON {status:(completed|continue),SourceLoc?,Desc?,next_cmds:[]}") After serialization, it is sent to the large language model. The large language model performs one-time inference, outputs a JSON response, and sends the JSON response to the debugging strategy guidance module. If the JSON response returns the field "status" as "completed" and there are non-empty "SourceLoc" and "Desc" fields, it is determined that the cause of the vulnerability has been located. Here, SourceLoc represents the line number of the source code where the vulnerability is located, and Desc is a natural language vulnerability cause summary generated by the large language model for the target binary program, which is different from the desc in the knowledge entry in the knowledge base. Proceed to step 12.3; If the JSON response returns the field "status" as "completed" and there are any empty "SourceLoc" and "Desc" fields, it means that the vulnerability location is incomplete. Proceed to step 12.4; If the JSON response returns the field "status" as "continue", then proceed to step 12.4;

[0126] Step 12.3 Encapsulate "SourceLoc" and "Desc" in the JSON response into a tuple (SourceLoc,Desc) as the vulnerability cause output, then proceed to step thirteen;

[0127] Step 12.4 Parse the atomic GDB debugging instruction sequence in the "next_cmds" field of the JSON response. Let i = i + 1. If i ≤ max_step, then max_step... p = 15~20, then the atomic-level GDB debugging instruction sequence is sent to the GDB debugging submodule, and proceed to step 5: If i>max_step, it means that the number of loop rounds has been reached, and the current best guess (i.e., the most suspicious instruction address of Qmax_step and its corresponding natural language description) is forcibly output, and it is used as the root cause report of the vulnerability to ensure that convergence is completed within a finite step size and to avoid infinite debugging, and proceed to step thirteen.

[0128] Step thirteen, the end.

[0129] To verify the effectiveness of this invention in vulnerability cause localization, a performance comparison experiment was conducted on a computer running Ubuntu 22.04 and equipped with an AMD 24-core 3.6GHz CPU, comparing the performance of this invention with the current best-performing technology described in the background. The Ubuntu 22.04 operating system kernel version was 5.8.0, the software environment was LLVM 10.0.0 + Python 3.8, and the hardware environment consisted of 64GB DDR4 memory and a 500GB NVMe SSD. The vulnerability cause localization system based on intelligent debugging agents is primarily coded in Python.

[0130] The experiment used 50 vulnerabilities (including 42 CVE vulnerabilities and 8 officially disclosed vulnerabilities) from 29 target binary programs for evaluation. These vulnerabilities covered six common vulnerability types: integer overflow, heap buffer overflow, stack buffer overflow, use after free, double free, and null pointer dereference. The source code of the target binary programs ranged from 796 to 2,270,065 lines of code, and the complexity of each vulnerability varied. For each test vulnerability, the present invention was used for localization, and the results are shown in Table 1. As shown in Table 1, the present invention can more accurately identify the specific location of the vulnerability's cause. The effective localization success rate of the present invention reached 90%, while the effectiveness of the Racing method was only 64%. In terms of localization output, Racing returns a list containing 100 possible cause locations and their rankings. The value listed in Racing in the table indicates the position of the actual cause location of the vulnerability within that ranking. The present invention directly outputs the exact cause location. In the table, the value "1" indicates that the actual location was successfully located, without ranking; "N" indicates that the cause of the vulnerability was not successfully located. Taking the msg00042 vulnerability (serial number 1) as an example, the actual location of the vulnerability's cause is ranked 16th in the Racing method ranking, but 1st in this invention, meaning that this invention successfully located the actual location of the vulnerability. In the CVE-2023-34823 vulnerability (serial number 2), the Racing method failed to locate the vulnerability's cause, while this invention successfully located it. All vulnerability cause locations in Table 1 have been manually reproduced and confirmed.

[0131] Table 1. Comparison of vulnerability cause localization capabilities between the present invention and the Racing method

[0132] Serial Number Vulnerability ID Racing Positioning This invention ID Vulnerability ID Racing Positioning This invention 1 msg00042 16 1 26 CVE-2021-40656 N 1 2 CVE-2023-34823 N 1 27 CVE-2021-45340 N 1 3 CVE-2017-11403 N 1 28 CVE-2019-20056 N 1 4 CVE-2019-14267 N 1 29 CVE-2024-31003 24 1 5 CVE-2019-14934 N 1 30 CVE-2016-5321 33 1 6 CVE-2019-17451 4 1 31 CVE-2020-19497 2 1 7 CVE-2019-9074 2 1 32 issue-667 N 1 8 CVE-2021-46324 2 1 33 CVE-2023-31981 57 1 9 CVE-2021-46325 24 1 34 CVE-2024-35426 48 1 10 CVE-2022-25465 51 1 35 CVE-2021-46507 N 1 11 CVE-2024-25200 10 1 36 CVE-2021-20205 3 1 12 CVE-2018-13785 1 1 37 CVE-2023-34318 18 1 13 CVE-2021-30485 1 1 38 CVE-2016-5636 9 1 14 CVE-2021-46509 79 1 39 2020 / q1 / 65 6 1 15 CVE-2021-46513 91 1 40 CVE-2022-29379 7 N 16 CVE-2021-46518 N 1 41 CVE-2019-20633 27 N 17 CVE-2021-46519 8 1 42 CVE-2022-45703 76 1 18 CVE-2021-46520 3 1 43 issue-6067 N 1 19 CVE-2021-46521 49 1 44 CVE-2022-0240 1 1 20 CVE-2021-46523 37 1 45 CVE-2021-4188 8 1 21 CVE-2021-46524 12 1 46 CVE-2024-24186 N 1 22 CVE-2021-46526 3 1 47 issue-905 1 N 23 CVE-2021-46527 15 1 48 issue-6065 91 1 24 CVE-2017-12858 6 N 49 5.4.0-11 39 N 25 bug #5.0-2 1 1 50 CVE-2023-34432 16 1

[0133] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.< / poc> < / poc> < / target> < / target> < / poc> < / poc> < / target> < / target>

Claims

1. A method for locating the root cause of vulnerabilities based on intelligent debugging agents, characterized in that... Includes the following steps: The first step is to construct a vulnerability cause localization system based on intelligent debugging agents. This system consists of a step-by-step debugging module, a debugging strategy guidance module, a debugging command output module, and a debugging experience memory module. The step-by-step debugging module includes a GDB debugging submodule, a debugging information formatting submodule, and a debugging status analysis submodule. The debugging command output module includes a knowledge base construction submodule, a retrieval and matching submodule, and a debugging command generation submodule. The debugging experience memory module includes a long-term memory submodule and an experience feedback activation submodule. The debug status analysis submodule, long-term memory submodule, and debug instruction generation submodule all integrate a large language model, and the GDB debug submodule contains GDB. These four modules work together to form an intelligent debugging agent; GDB refers to GNU Debugger. The second step is to build a security knowledge base using the knowledge base construction submodule. This involves extracting vulnerability root cause key-value pairs (vulnerability root cause description: vulnerability corresponding debugging command) from open-source security knowledge, and encapsulating the correspondence between vulnerability root cause description and vulnerability corresponding debugging command in the form of a 5-tuple to form a knowledge entry. Add the knowledge entries to the security knowledge base; The third step is to set the loop iteration i to 1 in the debug instruction generation submodule. The fourth step involves the debug instruction generation submodule outputting a sequence of debug instructions to the GDB debug submodule: the first instruction's function is to generate a new debug instruction sequence for the loaded binary. <target>The first instruction loads the debug symbol table; the second instruction sets the disassembly output format to Intel style; the third instruction starts the target binary program and... <poc> The process is passed to reproduce the crash and collect the initial debug state, generating the first round of debug state quadruple Q1;< / poc> < / target> The fifth step is for the GDB debugging submodule to receive the target binary program and test case PoC input by the user, execute the instruction sequence received from the debugging instruction generation submodule in sequence, generate raw debugging information, and send the raw debugging information to the debugging information formatting submodule. Step 6: The debug information formatting submodule receives the raw debug information from the GDB debug submodule, formats the raw debug information, and obtains the four-tuple Q of the i-th round debug state. i Q i Send to the debug status analysis submodule. ； Among them, Desc i State represents the vulnerability type identified in the i-th round of debugging. i This is a JSON object representing the program state during the i-th round of debugging, containing register values ​​and memory addresses, Loc. i Inst is the execution address or source code line number in the i-th round of debugging. i These are the context assembly instructions in the i-th round of debugging; Step 7: The debug status analysis submodule receives Q from the debug information formatting submodule. i Using a large language model to analyze Q i Perform inference updates to obtain the i-th round of debug state text q. i , q i Send Q to the retrieval matching submodule and the long-term memory submodule. i Send to the retrieval and matching submodule, the debugging strategy guidance module, and the debugging instruction generation submodule; Step 8: When the debugging experience memory module is greater than 2, it starts the experience accumulation mechanism to accumulate the "successful experience" of this round into reusable knowledge and continuously update the knowledge base. Step 9: The knowledge base construction submodule updates the security knowledge base periodically (T). Step 10: The retrieval and matching submodule receives the Q from the debug state analysis submodule. i and q i , with Q i To retrieve the query vector, semantic vector similarity retrieval and Top-K recall operations are performed on the knowledge base in the knowledge base construction submodule to obtain the result with respect to Desc. i The most relevant recall knowledge is sent to the debug instruction generation submodule. In the eleventh step, the debugging strategy guidance module receives the debugging status quadruple Qᵢ from the debugging status analysis submodule. Based on i, it selects the breakpoint debugging strategy, debugging information analysis strategy, or vulnerability location confirmation strategy as the debugging strategy using a round-robin mechanism. In each round of the loop, the three types of strategies are activated in turn, and the debugging strategy prompt is sent to the debugging instruction generation submodule to ensure that the debugging process is carried out alternately in the order of "breadth-depth-verification". Step 12: The debugging instruction generation submodule receives debugging strategy prompts from the debugging strategy guidance module, TT recall knowledge from the retrieval and matching submodule, and the quadruple Q1, ..., Qi from the debugging status analysis submodule. It serializes the input data using a JSON-Schema-enforced template and sends it to the large language model. The large language model decodes the data under the dual constraints of strategy and knowledge, outputting a JSON response that conforms to the pattern. This JSON response is then sent to the debugging strategy guidance module, and i is incremented by 1. If the JSON response indicates that the vulnerability cause has been located or i > max_step, max_step is incremented. p is If the maximum threshold number of steps is reached, proceed to step thirteen; if the cause of the vulnerability is not successfully located and i ≤ max_step, proceed to step five. Step thirteen, the end.

2. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... In the vulnerability cause localization system based on intelligent debugging agent built in the first step, the GDB debugging submodule is connected to the debugging information formatting submodule and the debugging instruction generation submodule. It receives the target binary program and test case PoC input by the user, receives the debugging instruction sequence from the debugging instruction generation submodule, enables GDB to perform PoC injection on the target binary program according to the debugging instruction sequence, obtains the original debugging information, and sends the original debugging information to the debugging information formatting submodule. The debug information formatting submodule is connected to the GDB debug submodule and the debug status analysis submodule. It receives raw debug information from the GDB debug submodule, formats the raw debug information to obtain a debug status quadruple, and sends the debug status quadruple to the debug status analysis submodule. The debug status analysis submodule is connected to the debug information formatting submodule, the retrieval and matching submodule, and the long-term memory submodule. It receives debug status quadruples from the debug information formatting submodule, uses a large language model to infer and update the debug status quadruples to obtain debug status text, and sends the debug status text to the long-term memory submodule and the retrieval and matching submodule. It then sends the debug status quadruples to the retrieval and matching submodule, the debug strategy guidance module, and the debug instruction generation submodule. The long-term memory submodule is connected to the debug status analysis submodule and the experience feedback activation submodule. It receives debug status text from the debug status analysis submodule, extracts key tags from the debug status text, and sends the experience memory quintuple to the experience feedback activation submodule. The key tags include vulnerability type, function name, and register exception. The experience feedback activation submodule is connected to the long-term memory submodule and the knowledge base construction submodule. It receives the experience memory quintuple from the long-term memory submodule, converts the experience memory quintuple from experience temperature to experience activity, obtains the experience activity, updates the knowledge entries, and sends the knowledge entries to the knowledge base construction submodule. The knowledge base construction submodule is connected to the experience feedback activation submodule and the retrieval and matching submodule. It encapsulates the vulnerability root cause key-value pairs extracted from open source security knowledge in the form of quintuples to form knowledge entries, builds the knowledge base, and regularly obtains the latest vulnerability patterns and remediation solutions from open source security knowledge. Combined with the knowledge entries received from the experience feedback activation submodule, the knowledge base is expanded and updated. The retrieval and matching submodule is connected to the knowledge base construction submodule, the debug status analysis submodule, the debug instruction generation submodule, and the debug strategy guidance module. It receives debug status quadruplets and debug status text from the debug status analysis submodule. Using the debug status quadruplets as query vectors, it performs semantic vector similarity retrieval and Top-K recall operations on the knowledge base in the knowledge base construction submodule to obtain the knowledge paragraphs most relevant to the debug status quadruplets, i.e., the recalled knowledge. The recalled knowledge is then sent to the debug instruction generation submodule. The debugging strategy guidance module is connected to the debugging instruction generation submodule and the debugging status analysis submodule. Based on the loop number i, it generates the corresponding debugging strategy prompt word in combination with the debugging status quadruple and sends the debugging strategy prompt word to the debugging instruction generation submodule. The debugging instruction generation submodule is connected to the retrieval and matching submodule, the debugging strategy guidance submodule, the GDB debugging submodule, and the debugging status analysis submodule. It receives recall knowledge from the retrieval and matching submodule, debug status quadruples from the debugging status analysis submodule, and debug strategy prompts from the debugging strategy guidance submodule. It combines the debug status quadruples, recall knowledge, and debug strategy prompts into a joint context, decodes the joint context using a large language model, and returns a JSON response. If the JSON response indicates that debugging is complete, the cause of the vulnerability is confirmed, and the cause of the vulnerability is output to the user. If the JSON response indicates that debugging is not yet complete, generate a grammatically correct and policy-constrained sequence of debugging instructions, send the sequence of instructions to the GDB debugging submodule, and send the JSON response to the debugging policy guidance module. The large language model combines deep code understanding with controllable structured output capabilities, enabling semantic induction, vector embedding, and command generation. It can also stably return high-confidence results within milliseconds via a secure long-connection API, and supports private deployment to meet the real-time and confidentiality requirements of interactive debugging.

3. The vulnerability cause localization method based on intelligent debugging agent as described in claim 2, characterized in that... The debug status analysis submodule, long-term memory submodule, and debug instruction generation submodule all use the same large language model, which is GPT-3.5-turbo.

4. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The second step involves open-source security knowledge including RCA-related literature, GDB debugging manuals, CVE vulnerability databases, and security patch announcements. The vulnerability root cause key-value pairs are binary tuples (vulnerability root cause description, corresponding debugging command). Each vulnerability root cause description maps to 1-3 community-verified, efficient GDB debugging commands, i.e., "debugging techniques." The quintuple is (usage, desc, id, priority, comm), where usage is the knowledge tag, desc is the knowledge description (vulnerability root cause description), id is the unique identifier of the knowledge, priority is the knowledge activity level (priority∈[0,1]), indicating the frequency and recent utility of the knowledge entry being successfully invoked and contributing to root cause localization in historical debugging, and comm is the corresponding GDB debugging command. The initial security knowledge base contains N knowledge entries, where N>500.

5. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The first debugging command in the fourth step is symbol-file. <target>This means for the loaded binary. <target> Load the debug symbol table so that GDB can resolve function names, variable names, and source code line numbers;< / target> < / target> The second debug command is `setdisassembly-flavor intel`; the third debug command is `run`. <poc> 。< / poc> 6. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The raw debugging information mentioned in step 5 is a GDB / MI record stream. MI is an abbreviation for Machine Interface. The format of the raw debugging information is GDB's machine-oriented JSON style. The original debugging information includes the program's crash signals, registers, and memory addresses.

7. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The sixth step, the debugging information formatting submodule, formats the original debugging information to obtain the quaternion Q for the i-th round of debugging state. i The method is: Step 6.1 Use regular expressions to perform structured parsing on the original debugging information, extracting crash signals, stack frames, memory addresses, register values, and source code location information. Convert the register values ​​and memory addresses into JSON-formatted serialized program states to obtain the vulnerability type, program state, execution address or source code line number, and context assembly instructions, generating the i-th round of debugging state quadruple Q. i ; Step 6.2 will Q i Send to the debug status analysis submodule.

8. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The debugging status analysis submodule described in step seven uses a large language model to analyze Q. i The method for performing inference updates is: Step 7.1 The debug status analysis submodule analyzes the Q... i Construct a prompt word for the large language model, the content of which is "Current debugging state is {Desc i }, the debugging location is {Loc i }, the register value is {State i }, the assembly instruction is {Inst i }” , Step 7.2 The large language model prompts the word "Current debugging state is {Desc}". i }, the debugging location is {Loc i }, the register value is {State i }, the assembly instruction is {Inst i }” performs semantic induction and vulnerability pattern matching to generate the i-th round of debug status text q i to replace Desc i And it serves as the sole keyword for subsequent knowledge retrieval, experience memory, and root cause localization. i It is a natural language vulnerability status description; Step 7.3 will q i Send Q to the retrieval and matching submodule and the long-term memory submodule. i Send to the retrieval and matching submodule, the debugging strategy guidance module, and the long-term memory submodule.

9. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The debugging experience memory module described in step eight activates the experience accumulation mechanism when the debugging round i is greater than 2. This mechanism is responsible for accumulating the "successful experiences" of this round into reusable knowledge and continuously updating the knowledge base. The method is as follows: Step 8.1 If i≤2, proceed directly to step 9; if i>2, proceed to step 8.

2. Step 8.2 The long-term memory submodule receives q from the debug state analysis submodule. i The system calls a large language model to generate an experience memory quintuple (debugscrip, experi, Id, tempe, comm) and sends it to the experience feedback activation submodule. Here, debugscrip is the "snapshot script" for the i-th round of debugging, summarizing the current crash signal, trigger function, and key register values ​​in natural language for subsequent retrieval and matching; experi is an experience-level summary text explaining "why executing this round of instruction sequences can advance the root cause location of the vulnerability"; Id is a unique identifier assigned to the experience memory quintuple; tempe is the "experience temperature," ranging from {0,1}, where tempe is 1 if the vulnerability is successfully located in this round, and 0 otherwise; and comm is the GDB command that actually generates value. Step 8.3 The Experience Feedback Activation Submodule receives the experience memory quintuple from the Long-Term Memory Submodule, reads its debug script, automatically infers the knowledge tag usage, and searches the knowledge base in the knowledge base construction module. If there is no knowledge entry containing usage in the knowledge base, the knowledge activity priority of the (i-1)th round is adjusted. i-1 Set the value to 0, and set the historical call frequency Δt of the knowledge entry containing usage to 0, then proceed to step 8.4; if there is a knowledge entry containing usage in the knowledge base, let Δt = i - i', where i' is the number of rounds the knowledge entry containing usage was last called, then proceed to step 8.4; Step 8.4 Calculate the knowledge activity priority of the i-th round using formula (2). i : ； Where β∈[0,1] is the historical weight coefficient, which is 0.8 by default. This is the exponential decay term, where λ is the decay rate, which is 0.01 by default. Step 8.5 Set priority = priority i Take the knowledge tag usage obtained in step 8.3, set desc to experience in the quintuple generated in step 8.2, set id to Id in the quintuple generated in step 8.2, combine usage, desc, id with comm and priority in the quintuple generated in step 8.2 to get a new quintuple (usage, desc, id, priority, comm), convert (usage, desc, id, priority, comm) into a knowledge item, and send the knowledge item to the knowledge base construction submodule.

10. A vulnerability cause localization method based on an intelligent debugging agent as described in claim 1, characterized in that... The method for updating the security knowledge base by the knowledge base construction submodule in step nine on a periodic T is as follows: Step 9.1 The knowledge base construction submodule receives knowledge entries from the experience feedback activation submodule; Step 9.2 The knowledge base construction submodule determines whether the period T has been reached, where T is 24 hours. If not, proceed to step 10; if the period T has been reached, proceed to step 9.

3. Step 9.3 The knowledge base construction submodule obtains the latest vulnerability patterns and remediation solutions from the CVE vulnerability database and security patch announcements. It performs attribute normalization processing on the knowledge entries received from the experience feedback activation submodule. That is, the latest vulnerability patterns and remediation solutions are cleaned and formatted according to the format of the knowledge entries: first, the vulnerability type is identified as usage using regular expressions, and the CVE number is taken as the id prefix. Then, key functions or variables are extracted from the code of the remediation solution as comm candidates. Finally, the root cause and remediation points are summarized using the same large language model to generate desc. If the latest vulnerability patterns and remediation solutions obtained from the CVE vulnerability database and security patch announcements do not contain a GDB command, then an automatic GDB command is added as comm; the priority is uniformly written as 0.5, thus obtaining a regular quintuple. The knowledge entries after attribute normalization are added to the security knowledge base, and then proceed to step 9.

1.

11. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The retrieval and matching submodule described in step ten uses Q i To retrieve the query vector, semantic vector similarity retrieval and Top-K recall operations are performed on the knowledge base in the knowledge base construction submodule to obtain the result with respect to Desc. i The most relevant method for recall knowledge is: Step 10.1 The matching submodule receives the i-th round debug state quadruple Q from the debug state analysis submodule. i With debug status text q i ; step 10.2 The retrieval and matching submodule is based on Q i Desc in i The vulnerability type shown is retrieved from the knowledge base, and results are filtered out from the knowledge base that match Desc. i Knowledge entries with completely identical vulnerability types are used to obtain a subset K of knowledge entries. , serving as a candidate space for subsequent similarity calculations Is with Desc i The j-th knowledge entry of the same vulnerability type shown. express Vulnerability type, Q i .Desc i Q represents i Desc in i The vulnerability types shown are 1≤j≤J, where J is the number of knowledge entries in K; Step 10.3 Calculate q sequentially i The weighted similarity with all knowledge entries in K is used to obtain J weighted similarities, where q i and The weighted similarity sim(q) i , k j Calculate according to formula (3): ; Where emb(q) i ) represents q i The text embedding vector, emb(k) j .desc i ) is the j-th knowledge entry in K. desc i The text embedding vector, where α is the weight coefficient balancing semantic similarity and knowledge activity, α∈[0,1], k j .priority is k j Knowledge activity level; Step 10.4 Sort the J weighted similarities obtained in Step 10.3 in descending order, and arrange the J knowledge items in K according to the order of the weighted similarities after descending order to obtain a subset KK of sorted knowledge items. Take the top TT highest matching knowledge items from KK, encapsulate these TT highest matching knowledge items and their corresponding weighted similarities together as recall knowledge, and send the recall knowledge to the debugging instruction generation submodule; TT ∈ [5, 10] and is an integer, if there are less than 5 items, take all of them.

12. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The debugging strategy guidance module described in step eleven selects a breakpoint debugging strategy, a debugging information analysis strategy, or a vulnerability location confirmation strategy as the debugging strategy based on a round-robin mechanism. The method for activating the three strategies in each round of the loop is as follows: Step 11.1 Receive the debug state quadruple Qᵢ from the debug state analysis submodule, and let variable kk = i mod 3; Step 11.2 If kk=1, proceed to step 11.3; if kk=2, proceed to step 11.4; if kk=0, proceed to step 11.

5. Step 11.3 Employ breakpoint debugging strategy for Q i Loc in i Analysis yields the crash call chain, i.e., the sequence of function calls C at the time of program crash. f m Let M be the m-th crash function when the program crashes, where M is the total number of crash functions in the crash call chain C; The debugging strategy guidance module finds the entry address of a function in C that has not yet set a breakpoint, generates a debugging strategy prompt for the conditional breakpoint command, and tells the large language model in the debugging instruction generation submodule which function entry point should be set as the next step to set a breakpoint. Send the debugging strategy prompt to the debugging instruction generation submodule, then proceed to step 12; Step 11.4 Employ a debugging information analysis strategy to debug the register and memory state changes ΔState when the i-th breakpoint is triggered, obtaining debugging strategy prompts to generate next-step debugging instructions for observation or comparison. Send these prompts to the debugging instruction generation submodule. , This is a snapshot of the registers and memory read in the i-th round. This is a snapshot of the registers and memory read in the (i-1)th round. Reflecting the changes in variables / registers, proceed to step 12; Step 11.5 Receives a JSON response from the debug instruction generation submodule, and uses a vulnerability location and confirmation strategy to investigate the same suspicious instruction address V that has appeared in two consecutive rounds. a and V a The five assembly context messages are combined to form the policy prompt word for the reproduction-verification command. This policy prompt word is then sent to the debug command generation submodule. a Take the "va" field from the JSON response output by the previous debugging command generation submodule, and proceed to step 12.

13. The vulnerability cause localization method based on intelligent debugging agent as described in claim 1, characterized in that... The specific method for the twelfth step is as follows: Step 12.1 The debug instruction generation submodule receives debug strategy prompts from the debug strategy guidance module, TT recall knowledge from the retrieval and matching submodule, and the quadruple Q from the debug status analysis submodule. i Q i Place them into a set of four tuples Q, Q = {Q1, ..., Q2}. i } ; Step 12.2 uses a JSON-Schema-enforced template to include the input data, namely debug strategy prompts, recall knowledge, and the four-tuple Q. i After serialization, the data is fed into the large language model. The large language model performs a one-time inference, outputs a JSON response, and sends the JSON response to the debugging strategy guidance module. If the JSON response returns the "status" field as "completed" and also contains non-empty "SourceLoc" and "Desc" fields, the vulnerability cause is determined to have been located. Here, SourceLoc represents the line number of the source code where the vulnerability is located, and Desc is a natural language summary of the vulnerability cause generated by the large language model for the target binary program. Proceed to step 12.

3. If the JSON response returns the "status" field as "completed" and contains either an empty "SourceLoc" or "Desc" field, the vulnerability location is incomplete. Proceed to step 12.

4. If the JSON response returns the "status" field as "continue", proceed to step 12.

4. Step 12.3 Encapsulate "SourceLoc" and "Desc" in the JSON response into a tuple (SourceLoc,Desc) as the vulnerability cause output, then proceed to step thirteen; Step 12.4 Parse the atomic GDB debugging instruction sequence in the "next_cmds" field of the JSON response. Let i = i + 1. If i ≤ max_step, then max_step... p = 15~20, then the atomic-level GDB debugging instruction sequence is sent to the GDB debugging submodule, and proceed to step 5: If i>max_step, it means that the number of loop rounds has been reached. Force output the address of the most suspicious instruction and its corresponding natural language description at the current best guess, i.e., at max_step, and use it as the root cause report of the vulnerability to ensure that convergence is completed within a finite step size and to avoid infinite debugging, and proceed to step thirteen.

14. The vulnerability cause localization method based on intelligent debugging agent as described in claim 13, characterized in that... Step 12.2 mandates a JSON-Schema template with a three-part prompt: role: "You are an RCA expert"; context: {Qi, knowledge recall, debugging strategy prompt}. constraint: "Should return JSON{status:(completed|continue),SourceLoc?,Desc?,next_cmds:[]}".

Images