A vulnerability exploit code generation method, system, computer program and medium

Abstract

The application discloses a vulnerability exploitation code generation method, system, computer program and medium, comprising: obtaining vulnerability characteristic information of a vulnerability report, generating a vulnerability exploitation generation prompt word based on static path pre-judgment, and generating to-be-optimized code through a language large model; executing in an actual running environment to obtain a response result, comparing with a vulnerability expected behavior library to generate a semantic similarity score, if the score is lower than a threshold value, generating an iterative optimization prompt word according to the response result, inputting into a vulnerability exploitation iterative decision body to optimize the above-mentioned code, iteratively executing score analysis and directional optimization until the score reaches a termination condition. In addition, the system, computer program and medium thereof are also included. Through the cooperative mechanism of static path pre-judgment, dynamic execution verification and execution result semantic feedback, the application realizes automatic and intelligent generation and high-availability optimization of vulnerability exploitation code.

Description

Technical Field

[0001] This invention relates to the field of vulnerability repair, and more specifically, to a method, system, computer program, and medium for generating vulnerability exploit code. Background Technology

[0002] In the field of cybersecurity, whenever a new software vulnerability is discovered, security researchers need to quickly generate corresponding exploit code to verify the vulnerability's authenticity, assess its severity, and provide a basis for subsequent remediation efforts. However, this process has long been one of the most time-consuming and labor-intensive parts of security work. Without specialized technical expertise, security teams typically have to rely on manual methods to generate exploit code. Researchers need to carefully read vulnerability reports, understand the vulnerability's triggering conditions, attack paths, and scope of impact, and then manually write code to reproduce the vulnerability. While this method ensures the accuracy of the code, it is extremely inefficient; a complex vulnerability may require days or even weeks to write verification code. Moreover, this work demands a high level of technical skill from researchers, and not every security team possesses this capability.

[0003] With the explosive growth in the number of vulnerabilities, manual methods are no longer sufficient to meet practical needs. Some teams have begun to try using template-based methods to generate code, pre-designing code templates for common vulnerability types and then filling them in based on specific vulnerability information. This method does improve efficiency, but the problem is that vulnerabilities are incredibly diverse, each with its own unique characteristics, and simple templates struggle to accurately reflect the complex features of vulnerabilities. Often, the generated code either fails to trigger the vulnerability or deviates significantly from the actual attack scenario. Even more problematic is that evaluating the quality of the generated code remains a challenge. Existing evaluation methods often focus only on whether the code runs correctly or whether the syntax is correct, failing to verify whether the code truly reflects the essential characteristics of the vulnerability or whether the attack path is complete and connected.

[0004] More importantly, existing code generation and evaluation methods are all static analysis techniques, which cannot address the issue of exploit code failing to run in real-world environments due to factors such as missing environmental dependencies, version mismatches, and differences in authentication methods. A typical scenario is this: security researchers generate exploit code that is logically and syntactically correct, but it fails to execute in the target power information system environment due to differences in database type, middleware version inconsistencies, or authentication method mismatches. Researchers need to repeatedly manually debug, modify the code, and redeploy for testing, making the entire process extremely inefficient.

[0005] The aforementioned deficiencies are particularly pronounced in industries with high security levels and highly heterogeneous environments, such as power information systems. Power information systems are characterized by diverse operating environments (involving multiple operating systems, databases, and middleware), complex security authentication mechanisms, and extremely high requirements for system stability. This results in significant differences in the usability of exploit code across different power system environments. Traditional static code review and evaluation methods cannot perceive these differences in operating environments and struggle to predict the code's performance in real-world environments before execution.

[0006] Security teams urgently need a smarter and more efficient method and system that can combine static analysis and dynamic execution verification to automate the generation of exploit code, assess environmental adaptability, and optimize it in a targeted manner, thereby generating exploit code with high availability in different power information system environments. Summary of the Invention

[0007] This invention overcomes the technical problems of low efficiency in generating exploit code, difficulty in reflecting actual operation effects by static evaluation methods, and lack of environment adaptability verification in the prior art. It provides a method, system, computer program, and medium for generating exploit code. Through a collaborative mechanism of static path prediction, dynamic execution verification, and semantic feedback of execution results, it realizes automated and intelligent generation and high availability optimization of exploit code.

[0008] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for generating exploit code, used to generate exploit code capable of triggering a vulnerability, includes the following steps: S1. Obtain vulnerability feature information from the vulnerability report. The vulnerability report is generated based on the vulnerability code. Static path prediction is performed based on the vulnerability feature information, and static analysis results are output. The static path prediction includes: evaluating the vulnerability reachability of the code to be audited using taint propagation rules, and invoking the code audit decision body to perform logical defect reasoning when the vulnerability reachability result cannot be obtained. S2. Generate vulnerability exploitation prompts based on the vulnerability feature information and the static analysis results, and generate initial vulnerability exploitation code through the vulnerability exploitation decision body; S3. Execute the initial exploit code in an actual operating environment and capture the execution response results; S4. Perform semantic similarity reasoning between the execution response result and the preset vulnerability expected behavior library to obtain a semantic similarity score; S5. If the semantic similarity score is lower than the set threshold, then an iterative optimization prompt word is generated based on the execution response result and input into the vulnerability exploitation iterative decision-making body to correct the initial vulnerability exploitation code in a targeted manner. S6. Iterate through steps S3 to S5 until the termination condition is triggered, and output the target vulnerability exploit code.

[0009] Preferably, the vulnerability feature information includes vulnerability type, affected components, affected versions, vulnerability triggering conditions, pollution source, dangerous operation point, attack payload construction requirements, and target runtime environment constraints. The target runtime environment constraints include one or more of the following: database type, middleware version, authentication method, system interface type, or runtime version.

[0010] Preferably, the method of evaluating the vulnerability reachability of the code to be audited using taint propagation rules includes: defining a taint source (Source) and a dangerous operation point (Sink); applying filtering rules and constraints along the code data flow to determine the downstream position where the taint-marked data exists; marking the taint data as hard reachable when it reaches the end of the data flow, otherwise marking it as hard unreachable. Record the downstream position reached by the taint marking data and the corresponding filtering rules and constraints to generate taint propagation audit results.

[0011] Preferably, the code audit decision-making body is invoked to perform logical defect reasoning, specifically including: The abstract syntax tree, control flow graph, and cross-function call relationship graph of the code to be audited are serialized and then input into the code audit decision body; The code audit decision-making body, based on pre-trained vulnerability pattern knowledge, infers whether there are potential path breaks in the code due to logical sequence errors, missing condition judgments, improper resource release, or authentication bypass, and generates semantic audit results.

[0012] Preferably, the static analysis result is generated by fusing the taint propagation audit result with the semantic audit result output by the code audit decision body; when the taint propagation audit result conflicts with the semantic audit result, the semantic audit result is adopted as the static analysis conclusion.

[0013] Preferably, the semantic similarity reasoning in step S4 specifically includes: The error codes, stack traces, return value status, and output logs in the execution response results are vectorized to generate an execution response feature vector. The semantic similarity score is obtained by calculating the cosine similarity or Euclidean distance between the execution response feature vector and the expected trigger feature vector stored in the vulnerability expected behavior library.

[0014] Preferably, the generation strategy for the iterative optimization prompts includes: extracting abnormal keywords, missing dependency information, or environment mismatches from the execution response results, injecting them into a preset template, and generating targeted natural language repair instructions.

[0015] Preferably, the termination conditions include: the semantic similarity score reaches a set threshold, the number of iterations reaches a preset value, or the similarity improvement in two consecutive iterations is less than a preset ratio. When any one of the termination conditions is met, the iteration stops and the exploit code is output.

[0016] Preferably, the static path prediction in step S1 further includes: filtering reachable paths based on the specific operating environment constraints of the power information system to eliminate attack paths that are incompatible with the environment; the specific operating environment constraints include operating system version, database type and middleware authentication method.

[0017] A vulnerability exploitation code generation and optimization system based on dynamic and static collaboration includes: The static prediction module is used to obtain vulnerability feature information from vulnerability reports, which correspond to code to be audited. Based on the vulnerability feature information, static path prediction is performed, and static analysis results are output. The static path prediction includes: evaluating the vulnerability reachability of the code to be audited using taint propagation rules, and, if the vulnerability reachability result cannot be obtained, calling the code audit decision body to perform logical defect reasoning. The initial generation module is used to generate vulnerability exploitation generation prompts based on the vulnerability feature information and the static analysis results, and to generate initial vulnerability exploitation code through the vulnerability exploitation generation decision body. The dynamic execution module is used to execute the initial exploit code in a real-world operating environment and capture the execution response results; The semantic comparison module is used to perform semantic similarity reasoning between the execution response result and a preset vulnerability expected behavior library to obtain a semantic similarity score; The iterative optimization module is used to generate iterative optimization prompts based on the execution response results when the semantic similarity score is lower than a set threshold. These prompts are then input into the vulnerability exploitation iterative decision-making body to correct the initial vulnerability exploit code in a targeted manner. The module iterates in a loop until a termination condition is triggered, and then outputs the target vulnerability exploit code.

[0018] Preferably, the training data for the code audit decision-making body includes: cross-function vulnerability sample code, defect patch pairs containing complex control flows, and code slices annotated with logical jump relationships.

[0019] Preferably, the system also includes a RAG knowledge base retrieval module, which is used to retrieve the most similar remediation case to the current execution response result from the historical vulnerability database when the semantic similarity score is lower than a set threshold, in order to assist in constructing the iterative optimization prompt words.

[0020] Preferably, the vulnerability expected behavior library is built based on the CVE / CNNVD vulnerability database and historical vulnerability verification reports in the power industry, and stores the expected output characteristics, response delay characteristics and system state change characteristics of various vulnerabilities when they are successfully triggered.

[0021] Compared with the prior art, the beneficial effects of the present invention are: (1) A dynamic and static collaborative iterative optimization process of "static prediction → dynamic execution → semantic feedback → targeted optimization" is constructed. By executing the code in the actual running environment and evaluating the semantic similarity based on the execution response results, the technical defect that pure static analysis cannot perceive the difference in the running environment is overcome, and the high availability generation of vulnerability exploitation code is realized.

[0022] (2) A layered static analysis method combining taint propagation rules and code audit decision-making is adopted: the rule layer quickly decides the reachability of regular direct paths, and the LLM layer performs in-depth reasoning on complex logical structures such as cross-function calls and indirect jumps. The two work together to ensure the accuracy and coverage of static path prediction.

[0023] (3) Based on the execution response results, construct targeted optimization prompts and transform the specific reasons for the failure (such as missing dependencies, environment mismatch, authentication failure) into locatable and explainable repair instructions, drive the large model to make accurate corrections, and greatly improve the efficiency of iterative optimization. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating the present invention; Figure 2 This is a schematic diagram of the static path prediction layered architecture of the present invention. Detailed Implementation

[0025] The present disclosure will be further described below with reference to the accompanying drawings and embodiments.

[0026] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0027] Example 1: like Figure 1 As shown, a method for generating exploit code includes the following steps: S1. Obtain vulnerability feature information from the vulnerability report, perform static path prediction based on the vulnerability feature information, and output static analysis results; S2. Generate vulnerability exploitation generation prompts based on the vulnerability feature information and the static analysis results, and generate vulnerability exploitation code through the vulnerability exploitation generation decision body; S3. Execute the exploit code in an actual operating environment and capture the execution response results; S4. Perform semantic similarity reasoning between the execution response result and the preset vulnerability expected behavior library to obtain a semantic similarity score; S5. If the semantic similarity score is lower than the set threshold, then an iterative optimization prompt word is generated based on the execution response result and input into the vulnerability exploitation iterative decision-making body to correct the initial vulnerability exploitation code in a targeted manner. S6. Iterate through steps S3 to S5 until the termination condition is triggered, and output the target vulnerability exploit code.

[0028] It is worth noting that the decision bodies, including the vulnerability exploitation generation decision body, the vulnerability exploitation iteration decision body, and the code audit decision body, are abstractions of large models, agents, and other conceptual entities. In practical use, people can use different large model bases to implement various decision bodies, or they can configure the corresponding context to generate agent roles based on the same large model. This embodiment is not limited to this.

[0029] This application aims to provide a closed-loop method for generating and optimizing exploit code using vulnerability reports. Unlike existing technologies, this application not only performs static review on the generated code but also deploys it to a real-world runtime environment for execution. Iterative optimization is driven by real execution feedback, ensuring high availability of the final exploit code in the target environment. The exploit code is generated for vulnerability research; business logic is removed for anonymization, resulting in a better representation of the vulnerability structure and high value for vulnerability study. In related technologies, exploit code is manually generated, which struggles to handle a large number of vulnerability environments. Therefore, this embodiment provides a language model-based exploit code generation method, using iterative refinement to obtain exploit code that accurately reflects vulnerability characteristics.

[0030] First, this method obtains vulnerability reports and, based on the organization of these reports, acquires characteristic information about the vulnerabilities. Vulnerability reports can be obtained from vulnerability databases, security bulletins, vulnerability analysis reports, or manually compiled vulnerability knowledge. From the vulnerability reports, the following information is extracted: vulnerability type, affected components, affected versions, vulnerability triggering conditions, contamination sources, dangerous operation points, attack payload construction requirements, and target runtime environment constraints. Regular expressions or language models are used to extract characteristic information about the vulnerabilities from the reports. The target runtime environment constraints include one or more of the following: database type, middleware version, authentication method, system interface type, or runtime version.

[0031] like Figure 2As shown, after obtaining vulnerability feature information, static path prediction is performed. Static path prediction adopts a layered analysis architecture, completed collaboratively by the rule layer and the semantic layer: The rule layer evaluates the vulnerability reachability of the code to be audited. Define taint sources (Source) and sinks (Sinks) and evaluate the vulnerability reachability of the audited code by applying filtering rules and constraints along the code data flow. Specifically, based on the predefined Source and Sink in the vulnerability feature information, perform taint propagation simulation on the program's control flow graph and data flow graph. When encountering filtering functions (such as input validation, permission checks, type conversions, etc.) or constraints (such as length limits, format validation, whitelist filtering) during the simulation, determine whether the constraint can be bypassed. This generates taint propagation audit results. If all constraints on the path are conflict-free or can be satisfied, and the taint data can reach the end of the vulnerability code corresponding to the audited vulnerability feature information, it is marked as "hard reachable"; if there are unsatisfiable constraints (e.g., requiring a fixed input length that the attack payload cannot meet), it is marked as "hard unreachable," and the breakpoint location and corresponding constraint are recorded. The output content is the taint propagation audit result.

[0032] Semantic layer, i.e., LLM logic flawed reasoning: When the reachability of a vulnerability in the code to be audited cannot be evaluated, the code audit decision-making body is triggered to perform supplementary reasoning. Reasons for the inability to evaluate vulnerability reachability include: taint propagation at the rule layer due to indirect calls (such as calling a dangerous function through a function pointer or callback function), cross-function jumps (such as the taint source being defined in function A, the dangerous operation being executed in function D, and the taint being passed through functions B and C), or complex branches within loops (such as whether the path is reachable depends on the number of iterations of the loop and the condition judgments within the loop).

[0033] In some embodiments, LLM logic defect reasoning serves as a passive fallback operation for evaluating the vulnerability reachability of the code to be audited. In other embodiments, an active selection step is included to check whether there are reasons in the vulnerable code that prevent vulnerability reachability evaluation. If the conditions are met, the process actively proceeds to LLM logic defect reasoning. In still other embodiments, both methods are used.

[0034] The abstract syntax tree, control flow graph, and cross-function call relationship graph of the code to be audited are serialized and input into the code audit decision-making body. The model is pre-trained, having learned from a large number of vulnerability sample codes, defect patch pairs containing complex control flows, and code slices annotated with logical jump relationships, enabling it to identify logical defect patterns in the code. In other embodiments, the model is an existing open-source model, coupled with a database containing a large amount of knowledge related to vulnerability sample codes, which is injected in a contextual manner during inference. Specifically, the model infers whether there are potential path breaks in the code due to the following reasons: Logical sequence error: For example, authentication checks are performed after dangerous operations, which can lead to bypassing authentication and direct access to sensitive functions; Missing conditional checks: such as executing system commands without checking user permissions, or performing memory copying without validating input length; Improper resource release: such as file handles or database connections not being released in abnormal paths, causing subsequent operations to fail. Authentication bypass: If the session token verification logic is flawed, it allows attackers to perform high-privilege operations with low-privilege identities.

[0035] The code audit decision-making body outputs semantic audit results, including whether logical defects exist, defect types, defect locations, and potential impacts.

[0036] Ultimately, the taint propagation audit results from the rule layer and the inference results from the semantic layer are fused to generate the static analysis result. In some embodiments, both inference audit methods are used simultaneously. When the two conflict (e.g., the rule layer cannot determine whether a path is reachable due to indirect calls, while the semantic layer inferences that the path has a logical break), the semantic audit result is adopted first as the static analysis conclusion to preserve the LLM's ability to identify complex logical defects.

[0037] In some embodiments, static path prediction further includes filtering reachable paths based on the specific operating environment constraints of the power information system (including operating system version, database type, and middleware authentication method) to eliminate attack paths incompatible with the environment. For example, if the target power system uses an Oracle database but the generated attack payload uses MySQL-specific syntax, the path is marked as incompatible with the environment and eliminated to prevent the subsequent generation of code that cannot run in that environment.

[0038] Next, step S2 is executed: exploit generation prompts are generated based on vulnerability feature information and static analysis results. These prompts are constructed according to a preset template. Vulnerability feature information extracted from the vulnerability report and static analysis results (including hard reachable paths, hard unreachable paths and breakpoint locations, and semantic audit pass / fail results) are injected into the template to generate structured exploit generation prompts. The prompts include constraints built based on vulnerability feature information, which, through static analysis results, prevent the decision-making body from continuing to generate in that direction. Subsequently, the exploit generation prompts drive the exploit generation decision-making body to generate initial exploit code. The exploit generation decision-making body uses a general code generation language model as its model base. Specifically, it can be a self-trained model or connected to a third-party language model service via API. This application does not restrict the selection of this language model, and its structure and training method are irrelevant to the protection subject of this application; therefore, they will not be elaborated upon here. The initial exploit code, during generation, avoids paths marked as hard unreachable in the static analysis stage and code patterns with logical defects, thereby improving the effectiveness of the initial code.

[0039] Step S3 is the key step that distinguishes this application from existing static code review schemes: deploying the generated initial exploit code to a real-world runtime environment and capturing the execution response results. The real-world runtime environment is built based on the target runtime environment constraints in the vulnerability feature information, including the matching database type, middleware version, authentication method, system interface type, and runtime version. The execution response results include, but are not limited to: program return value, standard output stream, standard error stream, exception stack trace, network response status code, response content, execution time, and system state change logs.

[0040] In step S4, the execution response result is compared with a pre-defined vulnerability expectation behavior library for semantic similarity reasoning. The vulnerability expectation behavior library is built based on the CVE / CNNVD vulnerability database and historical vulnerability verification reports from the power industry, storing the expected output characteristics, response delay characteristics, and system state change characteristics of various vulnerabilities when successfully triggered. For example, for SQL injection vulnerabilities, expected behaviors might include: returning an error message containing the database table structure, increased response delay (indicating successful time-based blind injection), or returning unexpected data records.

[0041] The specific process of semantic similarity reasoning includes: First, the error codes, stack traces, return value status, and output logs in the execution response result are vectorized and encoded to generate execution response feature vectors. Encoding can use pre-trained text embedding models (such as BERT, CodeBERT, etc.) to map the textual execution response to a high-dimensional semantic space. Simultaneously, expected trigger feature vectors corresponding to the vulnerability type are extracted from a vulnerability expected behavior library. Then, the cosine similarity or Euclidean distance between the two vectors is calculated, and the obtained value, after normalization, becomes the semantic similarity score. The score range is from 0 to 1; the closer the value is to 1, the better the execution response matches the expected vulnerability behavior, meaning the more the vulnerability exploit code's execution effect matches expectations.

[0042] In step S5, if the semantic similarity score is lower than a set threshold (in some embodiments, the threshold is set to 0.75, 0.8, or 0.85), then iterative optimization prompts are generated based on the execution response results. The generation strategy for iterative optimization prompts includes: extracting abnormal keywords, missing dependency information, or environment mismatches from the execution response results, injecting them into a preset template, and generating targeted natural language repair instructions.

[0043] The specific iterative optimization prompt generation process is as follows: First, the execution response result is parsed to identify the failure reason type. If the response contains keywords such as "ModuleNotFoundError" or "No such file or directory," it is determined to be a "missing dependency," and the missing dependency name is injected into the template. If the response contains keywords such as "version," "incompatible," or "requires," it is determined to be an "environment mismatch," and the mismatched environment items (such as database version, Python version, etc.) are injected into the template. If the response contains keywords such as "Access Denied," "Permission denied," or "Authenticationfailed," it is determined to be an "authentication failure," and the authentication method difference information is injected into the template.

[0044] For example, if the execution response displays "ModuleNotFoundError: No module named 'MySQLdb'", the generated iterative optimization prompt will be: "The current code depends on the MySQLdb module, but this module is not installed in the target environment. Please modify the code to use a database driver already installed in the target environment (such as pymysql or sqlite3) to regenerate the connection code." As another example, if the execution response displays "OperationalError: (1045, 'Access denied foruser')", the generated iterative optimization prompt will be: "The target environment uses certificate authentication instead of password authentication. Please modify the authentication logic in the code to adapt to certificate authentication." The above approach transforms the previously vague "execution failure" problem into targeted feedback information that is localizable, interpretable, and iteratively correctable, thereby providing a clear basis for the targeted correction of large models.

[0045] Then, iterative optimization prompts (in some embodiments, also including the exploit code of the current round and vulnerability feature information of the target vulnerability) are input into the exploit generation decision body, driving it to perform targeted corrections to the current code. The language model generates the corrected exploit code based on the specific failure reasons reflected in the execution response results. In some embodiments, the exploit iteration decision body and the exploit generation decision body are the same.

[0046] In step S6, steps S3 to S5 are executed iteratively, that is, after each correction, the code is re-executed in the actual running environment, the response results are captured, and the semantic similarity score is calculated until the termination condition is triggered.

[0047] Termination conditions include one or more of the following: (1) Scoring meets the standard: When the semantic similarity score reaches the set threshold (e.g., 0.85), it means that the exploit code has successfully triggered the expected vulnerability behavior in the target environment. At this time, the current code is output as the target vulnerability exploit code.

[0048] (2) Reach the maximum number of iterations: Set the maximum number of iterations (e.g., 5 times), count the number of iterations from step S3 to S5, and stop updating the code to be optimized when the maximum number of iterations is reached, and output the exploit code version with the highest semantic similarity score in the historical iterations.

[0049] (3) Effect Saturation: Set up a historical iteration effect database to record the semantic similarity score of each iteration and the score optimization range between adjacent rounds. When the score improvement of the current iteration is lower than the preset ratio (e.g., 20%) of the historical average optimization range, it is determined that it has entered the saturation zone. Continuing to iterate can no longer significantly improve the code quality, triggering early termination and outputting the code version with the highest current score.

[0050] In some embodiments, a RAG knowledge base retrieval module is also provided. When the semantic similarity score is lower than a set threshold, the module retrieves the most similar remediation case from the historical vulnerability database that matches the current execution response result, thus assisting in the construction of iterative optimization prompts. Specifically, the current execution response result is used as the query vector to retrieve the most similar historical remediation case from the RAG knowledge base. The remediation solutions in the case (such as "replace the database driver from MySQLdb to pymysql") are incorporated as reference information into the iterative optimization prompts to enhance the accuracy of large model remediation.

[0051] Example 2: Based on this, a vulnerability exploit code generation system is also disclosed, including: The static prediction module is used to obtain vulnerability feature information from vulnerability reports, perform static path prediction based on the vulnerability feature information, and output static analysis results. The static path prediction includes: using taint propagation rules to determine the reachability of the first type of path along the data flow, and calling the code audit decision body to perform logical defect reasoning on code segments with complex logical structures and / or cross-function calls. The initial generation module is used to generate vulnerability exploitation generation prompts based on the vulnerability feature information and the static analysis results, and to generate initial vulnerability exploitation code through the vulnerability exploitation generation decision body. The dynamic execution module is used to execute the initial exploit code in a real-world operating environment and capture the execution response results; The semantic comparison module is used to perform semantic similarity reasoning between the execution response result and a preset vulnerability expected behavior library to obtain a semantic similarity score; The iterative optimization module is used to generate iterative optimization prompts based on the execution response results when the semantic similarity score is lower than a set threshold. These prompts are then input into the vulnerability exploitation iterative decision-making body to correct the initial vulnerability exploit code in a targeted manner. The module iterates in a loop until a termination condition is triggered, and then outputs the target vulnerability exploit code.

[0052] In some embodiments, the training data for the code audit decision body includes: cross-function vulnerability sample code, defect patch pairs containing complex control flows, and code slices annotated with logical jump relationships.

[0053] First, this system acquires vulnerability reports and, based on the organization of these reports, obtains characteristic information about the vulnerabilities. Vulnerability reports can be acquired from vulnerability databases, security bulletins, vulnerability analysis reports, or manually compiled vulnerability knowledge. From the vulnerability reports, the system extracts the vulnerability type, affected components, affected versions, vulnerability triggering conditions, contamination sources, dangerous operation points, attack payload construction requirements, and target runtime environment constraints. The system uses regular expressions or language models to extract characteristic information about the vulnerabilities from the reports. The target runtime environment constraints include one or more of the following: database type, middleware version, authentication method, system interface type, or runtime version.

[0054] like Figure 2 As shown, after obtaining vulnerability feature information, static path prediction is performed. Static path prediction adopts a layered analysis architecture, completed collaboratively by the rule layer and the semantic layer: The rule layer evaluates the vulnerability reachability of the code to be audited. Define taint sources (Source) and sinks (Sinks) and evaluate the vulnerability reachability of the audited code by applying filtering rules and constraints along the code data flow. Specifically, based on the predefined Source and Sink in the vulnerability feature information, perform taint propagation simulation on the program's control flow graph and data flow graph. When encountering filtering functions (such as input validation, permission checks, type conversions, etc.) or constraints (such as length limits, format validation, whitelist filtering) during the simulation, determine whether the constraint can be bypassed. This generates taint propagation audit results. If all constraints on the path are conflict-free or can be satisfied, and the taint data can reach the end of the vulnerability code corresponding to the audited vulnerability feature information, it is marked as "hard reachable"; if there are unsatisfiable constraints (e.g., requiring a fixed input length that the attack payload cannot meet), it is marked as "hard unreachable," and the breakpoint location and corresponding constraint are recorded. The output content is the taint propagation audit result.

[0055] Semantic layer, i.e., LLM logic flawed reasoning: When the reachability of a vulnerability in the code to be audited cannot be evaluated, the code audit decision-making body is triggered to perform supplementary reasoning. Reasons for the inability to evaluate vulnerability reachability include: taint propagation at the rule layer due to indirect calls (such as calling a dangerous function through a function pointer or callback function), cross-function jumps (such as the taint source being defined in function A, the dangerous operation being executed in function D, and the taint being passed through functions B and C), or complex branches within loops (such as whether the path is reachable depends on the number of iterations of the loop and the condition judgments within the loop).

[0056] In some embodiments, LLM logic defect reasoning serves as a passive fallback operation for evaluating the vulnerability reachability of the code to be audited. In other embodiments, an active selection step is included to check whether there are reasons in the vulnerable code that prevent vulnerability reachability evaluation. If the conditions are met, the process actively proceeds to LLM logic defect reasoning. In still other embodiments, both methods are used.

[0057] The abstract syntax tree, control flow graph, and cross-function call relationship graph of the code to be audited are serialized and input into the code audit decision-making body. The model is pre-trained, having learned from a large number of vulnerability sample codes, defect patch pairs containing complex control flows, and code slices annotated with logical jump relationships, enabling it to identify logical defect patterns in the code. In other embodiments, the model is an existing open-source model, coupled with a database containing a large amount of knowledge related to vulnerability sample codes, which is injected in a contextual manner during inference. Specifically, the model infers whether there are potential path breaks in the code due to the following reasons: Logical sequence error: For example, authentication checks are performed after dangerous operations, which can lead to bypassing authentication and direct access to sensitive functions; Missing conditional checks: such as executing system commands without checking user permissions, or performing memory copying without validating input length; Improper resource release: such as file handles or database connections not being released in abnormal paths, causing subsequent operations to fail. Authentication bypass: If the session token verification logic is flawed, it allows attackers to perform high-privilege operations with low-privilege identities.

[0058] The code audit decision-making body outputs semantic audit results, including whether logical defects exist, defect types, defect locations, and potential impacts.

[0059] Ultimately, the taint propagation audit results from the rule layer and the inference results from the semantic layer are fused to generate the static analysis result. In some embodiments, both inference audit methods are used simultaneously. When the two conflict (e.g., the rule layer cannot determine whether a path is reachable due to indirect calls, while the semantic layer inferences that the path has a logical break), the semantic audit result is adopted first as the static analysis conclusion to preserve the LLM's ability to identify complex logical defects.

[0060] In some embodiments, static path prediction further includes filtering reachable paths based on the specific operating environment constraints of the power information system (including operating system version, database type, and middleware authentication method) to eliminate attack paths incompatible with the environment. For example, if the target power system uses an Oracle database but the generated attack payload uses MySQL-specific syntax, the path is marked as incompatible with the environment and eliminated to prevent the subsequent generation of code that cannot run in that environment.

[0061] Next, step S2 is executed: exploit generation prompts are generated based on vulnerability feature information and static analysis results. These prompts are constructed according to a preset template. Vulnerability feature information extracted from the vulnerability report and static analysis results (including hard reachable paths, hard unreachable paths and breakpoint locations, and semantic audit pass / fail results) are injected into the template to generate structured exploit generation prompts. The prompts include constraints built based on vulnerability feature information, which, through static analysis results, prevent the large model from continuing to generate in that direction. Subsequently, the exploit generation prompts drive the exploit generation decision-making body to generate initial exploit code. The exploit generation decision-making body generates a large language model based on general code; specifically, it can be a self-trained model or connected to a third-party language model service via API. This application does not restrict the selection of this language model, and the structure and training method of the language model are irrelevant to the protection subject of this application; therefore, they will not be elaborated here. The initial exploit code, during generation, avoids paths marked as hard unreachable in the static analysis stage and code patterns with logical defects, thereby improving the effectiveness of the initial code.

[0062] Step S3 is the key step that distinguishes this application from existing static code review schemes: deploying the generated initial exploit code to a real-world runtime environment and capturing the execution response results. The real-world runtime environment is built based on the target runtime environment constraints in the vulnerability feature information, including the matching database type, middleware version, authentication method, system interface type, and runtime version. The execution response results include, but are not limited to: program return value, standard output stream, standard error stream, exception stack trace, network response status code, response content, execution time, and system state change logs.

[0063] In step S4, the execution response result is compared with a pre-defined vulnerability expectation behavior library for semantic similarity reasoning. The vulnerability expectation behavior library is built based on the CVE / CNNVD vulnerability database and historical vulnerability verification reports from the power industry, storing the expected output characteristics, response delay characteristics, and system state change characteristics of various vulnerabilities when successfully triggered. For example, for SQL injection vulnerabilities, expected behaviors might include: returning an error message containing the database table structure, increased response delay (indicating successful time-based blind injection), or returning unexpected data records.

[0064] The specific process of semantic similarity reasoning includes: First, the error codes, stack traces, return value status, and output logs in the execution response result are vectorized and encoded to generate execution response feature vectors. Encoding can use pre-trained text embedding models (such as BERT, CodeBERT, etc.) to map the textual execution response to a high-dimensional semantic space. Simultaneously, expected trigger feature vectors corresponding to the vulnerability type are extracted from a vulnerability expected behavior library. Then, the cosine similarity or Euclidean distance between the two vectors is calculated, and the obtained value, after normalization, becomes the semantic similarity score. The score range is from 0 to 1; the closer the value is to 1, the better the execution response matches the expected vulnerability behavior, meaning the more the vulnerability exploit code's execution effect matches expectations.

[0065] In step S5, if the semantic similarity score is lower than a set threshold (in some embodiments, the threshold is set to 0.75, 0.8, or 0.85), then iterative optimization prompts are generated based on the execution response results. The generation strategy for iterative optimization prompts includes: extracting abnormal keywords, missing dependency information, or environment mismatches from the execution response results, injecting them into a preset template, and generating targeted natural language repair instructions.

[0066] The specific iterative optimization prompt generation process is as follows: First, the execution response result is parsed to identify the failure reason type. If the response contains keywords such as "ModuleNotFoundError" or "No such file or directory," it is determined to be a "missing dependency," and the missing dependency name is injected into the template. If the response contains keywords such as "version," "incompatible," or "requires," it is determined to be an "environment mismatch," and the mismatched environment items (such as database version, Python version, etc.) are injected into the template. If the response contains keywords such as "Access Denied," "Permission denied," or "Authenticationfailed," it is determined to be an "authentication failure," and the authentication method difference information is injected into the template.

[0067] For example, if the execution response displays "ModuleNotFoundError: No module named 'MySQLdb'", the generated iterative optimization prompt will be: "The current code depends on the MySQLdb module, but this module is not installed in the target environment. Please modify the code to use a database driver already installed in the target environment (such as pymysql or sqlite3) to regenerate the connection code." As another example, if the execution response displays "OperationalError: (1045, 'Access denied foruser')", the generated iterative optimization prompt will be: "The target environment uses certificate authentication instead of password authentication. Please modify the authentication logic in the code to adapt to certificate authentication." The above approach transforms the previously vague "execution failure" problem into targeted feedback information that is localizable, interpretable, and iteratively correctable, thereby providing a clear basis for the targeted correction of large models.

[0068] Then, iterative optimization prompts (which in some embodiments also include the exploit code for the current round and vulnerability feature information of the target vulnerability) are input into the exploit generation decision-making body, driving it to make targeted corrections to the current code. The language model generates corrected exploit code based on the specific failure reasons reflected in the execution response results.

[0069] In step S6, steps S3 to S5 are executed iteratively, that is, after each correction, the code is re-executed in the actual running environment, the response results are captured, and the semantic similarity score is calculated until the termination condition is triggered.

[0070] Termination conditions include one or more of the following: (1) Scoring meets the standard: When the semantic similarity score reaches the set threshold (e.g., 0.85), it means that the exploit code has successfully triggered the expected vulnerability behavior in the target environment. At this time, the current code is output as the target vulnerability exploit code.

[0071] (2) Reach the maximum number of iterations: Set the maximum number of iterations (e.g., 5 times), count the number of iterations from step S3 to S5, and stop updating the code to be optimized when the maximum number of iterations is reached, and output the exploit code version with the highest semantic similarity score in the historical iterations.

[0072] (3) Effect Saturation: Set up a historical iteration effect database to record the semantic similarity score of each iteration and the score optimization range between adjacent rounds. When the score improvement of the current iteration is lower than the preset ratio (e.g., 20%) of the historical average optimization range, it is determined that it has entered the saturation zone. Continuing to iterate can no longer significantly improve the code quality, triggering early termination and outputting the code version with the highest current score.

[0073] In some embodiments, a RAG knowledge base retrieval module is also provided. When the semantic similarity score is lower than a set threshold, the module retrieves the most similar remediation case from the historical vulnerability database that matches the current execution response result, thus assisting in the construction of iterative optimization prompts. Specifically, the current execution response result is used as the query vector to retrieve the most similar historical remediation case from the RAG knowledge base. The remediation solutions in the case (such as "replace the database driver from MySQLdb to pymysql") are incorporated as reference information into the iterative optimization prompts to enhance the accuracy of large model remediation.

[0074] In some embodiments, the vulnerability expected behavior library is built based on the CVE / CNNVD vulnerability database and historical vulnerability verification reports in the power industry, and stores the expected output characteristics, response delay characteristics and system state change characteristics of various vulnerabilities when they are successfully triggered.

[0075] Example 3: This invention also provides an electronic device, which may be a computer device, a microcontroller device, a smart mobile device, etc. The electronic device in this embodiment may include a processor, a memory, a transceiver component, etc. The memory, processor, and transceiver component are connected via a bus; the memory can be used to store executable programs, and an exemplary executable program may include instructions; the processor is used to execute the instructions stored in the memory. The memory can also be used to store data, which can be accessed and / or modified when instructions are executed.

[0076] The processor may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, and it is suitable for implementing one or more instructions. Specifically, it is suitable for loading and executing one or more instructions in the storage medium to implement the corresponding method flow or corresponding function, so as to implement the steps of a vulnerability exploit code generation method in the above embodiments.

[0077] Example 4: Based on the same inventive concept, this invention also provides a readable storage medium, specifically an electronic device readable storage medium (Memory). This readable storage medium is a memory device within an electronic device used to store programs and data. It is understood that the storage medium here can include both built-in storage media within the electronic device and extended storage media supported by the electronic device. The storage medium provides storage space, which stores the terminal's operating system. Furthermore, this storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more executable programs (including program code). It should be noted that the storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device. Loading and executing one or more instructions stored in the storage medium by the processor can implement the steps of a vulnerability exploit code generation method in the above embodiments.

[0078] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0079] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0080] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0081] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0082] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Other variations and modifications may be made without departing from the technical solutions described in the claims.

Claims

1. A method for generating exploit code, used to generate exploit code capable of triggering a vulnerability, characterized in that, Includes the following steps: S1. Obtain vulnerability feature information from the vulnerability report, where the vulnerability report corresponds to the code to be audited. Based on the vulnerability feature information, perform static path prediction and output static analysis results. The static path prediction includes: evaluating the vulnerability reachability of the code to be audited using taint propagation rules, and invoking the code audit decision body to perform logical defect reasoning when the vulnerability reachability result cannot be obtained; S2. Generate vulnerability exploitation prompts based on the vulnerability feature information and the static analysis results, and generate initial vulnerability exploitation code through the vulnerability exploitation decision body; S3. Execute the initial exploit code in an actual operating environment and capture the execution response results; S4. Perform semantic similarity reasoning between the execution response result and the preset vulnerability expected behavior library to obtain a semantic similarity score; S5. If the semantic similarity score is lower than the set threshold, then an iterative optimization prompt word is generated based on the execution response result and input into the vulnerability exploitation iterative decision-making body to correct the initial vulnerability exploitation code in a targeted manner. S6. Iterate through steps S3 to S5 until the termination condition is triggered, and output the target vulnerability exploit code.

2. The vulnerability exploit code generation method according to claim 1, characterized in that the vulnerability feature information includes vulnerability type, affected components, affected versions, vulnerability triggering conditions, pollution source, dangerous operation point, attack payload construction requirements and target runtime environment constraints, and the target runtime environment constraints include one or more of the following: database type, middleware version, authentication method, system interface type, and runtime version.

3. The vulnerability exploitation code generation method according to claim 1, characterized in that, The evaluation of vulnerability reachability of the code to be audited using taint propagation rules includes: Define the source of contamination and the sink of hazardous operation points; Filtering rules and constraints are applied along the code data flow to determine the downstream position where tainted data exists; when tainted data reaches the end of the data flow, it is marked as hard reachable, otherwise it is marked as hard unreachable. Record the downstream position reached by the taint marking data and the corresponding filtering rules and constraints to generate taint propagation audit results.

4. The vulnerability exploitation code generation method according to claim 3, characterized in that, The process of invoking the code audit decision-making body to perform logical defect reasoning specifically includes: The abstract syntax tree, control flow graph, and cross-function call relationship graph of the code to be audited are serialized and then input into the code audit decision body; The code audit decision-making body, based on pre-trained vulnerability pattern knowledge, infers whether there are potential path breaks in the code due to logical sequence errors, missing condition judgments, improper resource release, or authentication bypass, and generates semantic audit results.

5. The vulnerability exploitation code generation method according to claim 4, characterized in that, The static analysis result is generated by fusing the taint propagation audit result with the semantic audit result output by the code audit decision body; when the taint propagation audit result conflicts with the semantic audit result, the semantic audit result is adopted as the static analysis conclusion.

6. The method for generating exploit code according to claim 1, characterized in that, The semantic similarity reasoning in step S4 specifically includes: The error codes, stack traces, return value status, and output logs in the execution response results are vectorized to generate an execution response feature vector. The semantic similarity score is obtained by calculating the cosine similarity or Euclidean distance between the execution response feature vector and the expected trigger feature vector stored in the vulnerability expected behavior library.

7. The method for generating exploit code according to claim 1, characterized in that, The generation strategy for the iterative optimization prompts includes: extracting abnormal keywords, missing dependency information, or environment mismatches from the execution response results, injecting them into a preset template, and generating targeted natural language repair instructions.

8. The method for generating exploit code according to claim 1, characterized in that, The termination conditions include: the semantic similarity score reaches a set threshold, the number of iterations reaches a preset value, or the similarity improvement in two consecutive iterations is less than a preset ratio. When any one of the termination conditions is met, the iteration stops and the exploit code is output.

9. The method for generating exploit code according to claim 1, characterized in that, The static path prediction in step S1 also includes: filtering reachable paths based on the specific operating environment constraints of the power information system to eliminate attack paths that are incompatible with the environment; the specific operating environment constraints include operating system version, database type and middleware authentication method.

10. A vulnerability exploit code generation system, characterized in that it includes: The static prediction module is used to obtain vulnerability feature information from vulnerability reports, which correspond to code to be audited. Based on the vulnerability feature information, static path prediction is performed, and static analysis results are output. The static path prediction includes: evaluating the vulnerability reachability of the code to be audited using taint propagation rules, and invoking the code audit decision body to perform logical defect reasoning when the vulnerability reachability result cannot be obtained; The initial generation module is used to generate vulnerability exploitation generation prompts based on the vulnerability feature information and the static analysis results, and to generate initial vulnerability exploitation code through the vulnerability exploitation generation decision body. The dynamic execution module is used to execute the initial exploit code in a real-world operating environment and capture the execution response results; The semantic comparison module is used to perform semantic similarity reasoning between the execution response result and a preset vulnerability expected behavior library to obtain a semantic similarity score; The iterative optimization module is used to generate iterative optimization prompts based on the execution response results when the semantic similarity score is lower than a set threshold. These prompts are then input into the vulnerability exploitation iterative decision-making body to correct the initial vulnerability exploit code in a targeted manner. The module iterates in a loop until a termination condition is triggered, and then outputs the target vulnerability exploit code.

11. The vulnerability exploitation code generation system according to claim 10, characterized in that, The training data for the code audit decision-making body includes: cross-function vulnerability sample code, defect patch pairs containing complex control flows, and code slices labeled with logical jump relationships.

12. The vulnerability exploitation code generation system according to claim 10, characterized in that, It also includes a RAG knowledge base retrieval module, which is used to retrieve the most similar remediation case to the current execution response result from the historical vulnerability database when the semantic similarity score is lower than a set threshold, to assist in constructing the iterative optimization prompt words.

13. The vulnerability exploitation code generation system according to claim 10, characterized in that, The vulnerability expected behavior library is built based on the CVE / CNNVD vulnerability database and historical vulnerability verification reports in the power industry. It stores the expected output characteristics, response delay characteristics, and system state change characteristics of various vulnerabilities when they are successfully triggered.

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

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 9.

Images