Control flow hijacking vulnerability test sample automatic generation method and system based on constraint driving

Abstract

The invention discloses a control flow hijacking vulnerability test sample automatic generation method and system based on constraint driving, and the method comprises the steps: 1, detecting a target program, obtaining vulnerability information and available points of the target program, and constructing a utilization constraint according to the available points; 2, constructing a path constraint according to the vulnerability information; and 3, solving a constraint expression according to the utilization constraint and the path constraint, if the constraint expression has a solution, outputting vulnerability utilization information to complete automatic generation of a vulnerability test sample, and if the constraint expression does not have a solution, reconstructing the utilization constraint to solve the constraint expression. According to the method, the constraint expression is solved by utilizing the constraint and the path constraint, so that the speed and the accuracy of generating the vulnerability test sample code are improved, and vulnerability analysis tests on different hardware platforms become more efficient and reliable.

Description

Technical Field

[0001] The present invention relates to the technical field of vulnerability analysis and testing, and in particular to a method and system for automatically generating control flow hijacking vulnerability test samples based on constraint-driven. Background Art

[0002] With the development of information technology, the deep integration of cyberspace and physical space has made the threat of cyber attacks more serious. Faced with the growing number of vulnerabilities and evolving malicious samples, vulnerability testing technology has become particularly important. It can not only help security experts discover and fix security vulnerabilities, but also enhance the system's defense capabilities.

[0003] The traditional manual vulnerability exploitation process includes the following key steps:

[0004] Step 1: Verify the existence of vulnerabilities. Use static and dynamic program analysis methods to detect potential vulnerabilities in the program and construct inputs that trigger the vulnerabilities for verification.

[0005] Step 2: Analyze the root cause of the vulnerability and obtain vulnerability information. Analyze the program with the vulnerability, determine the cause and root cause of the vulnerability, and obtain information about the vulnerability, including the vulnerability type and protection mechanism, and choose the exploit method based on this information;

[0006] Step 3: Determine whether the control flow can be hijacked. Use debugging tools such as IDA, ghidra, and GDB to dynamically debug and analyze the vulnerability triggering process to determine whether the program execution flow can be hijacked;

[0007] Step 4: Construct memory layout. Analyze the program state after the vulnerability is triggered, arrange the attack payload into the memory space, and point the program control flow to the memory address of the attack payload to ensure that the attack payload can be executed;

[0008] Step 5: Construct a vulnerability test sample. Construct input that can exploit the vulnerability so that the desired memory layout is obtained after the vulnerability is triggered, thereby hijacking the program's control flow to a specific attack payload to achieve the purpose of the attack.

[0009] Traditional manual exploitation methods are often time-consuming and inefficient. In contrast, automated exploitation technology can quickly conduct security tests on a wide range of targets, which not only greatly improves the security and stability of software systems, but also significantly reduces the cost and time of security testing, thereby improving the overall efficiency of software development and maintenance.

[0010] However, vulnerability testing is closely related to the CPU architecture, and different methods are required to test vulnerabilities on different architectures. Due to differences in the formation mechanism of vulnerabilities and the protection measures against them, the methods of exploitation are also diverse. This diversity makes it difficult to implement general automated exploitation tools, as they are difficult to be compatible with multiple CPU architectures at the same time and implement diverse exploitation methods. Summary of the invention

[0011] In order to at least partially solve the problem that the vulnerability automated exploitation method is difficult to be compatible with multiple CPU architectures at the same time, the present invention provides a constraint-driven control flow hijacking vulnerability test sample automatic generation method and system, which divides the process of vulnerability test sample automatic generation into two stages: prerequisite judgment and exploitation generation, constructs a constraint-driven vulnerability test sample automatic generation model, and uniformly describes the control flow hijacking method of different architecture vulnerabilities from the expression, so as to realize the generation of vulnerability test samples of different architectures. It mainly targets stack overflow vulnerabilities and formatted string vulnerabilities, and is applicable to different architectures such as x86\x86-64\MIPS32\ARM32.

[0012] In order to achieve the above object, the technical solution of the present invention is:

[0013] The oil dripping aspect of the present invention proposes a method for automatically generating control flow hijacking vulnerability test samples based on constraint driving, including:

[0014] Step 1: Detect the target program to obtain vulnerability information and exploitable points of the target program, and build exploit constraints based on the exploitable points to facilitate the exploitation of the constrained program after it is executed to the exploitable points;

[0015] Step 2: Construct path constraints based on vulnerability information to facilitate the execution of the program to the exploitable point of the vulnerability;

[0016] Step 3: Solve the constraint expression according to the exploit constraint and path constraint. If the constraint expression has a solution, output the vulnerability exploitation information and complete the automatic generation of vulnerability test samples. If the constraint expression has no solution, rebuild the exploit constraint to solve the constraint expression to determine whether the vulnerability test sample is successfully generated.

[0017] Furthermore, the utilization constraint is expressed by the following formula:

[0018] C exp =C pc ∩C payload

[0019] Among them, C exp To utilize the constraint, C pc For control flow hijacking constraints, C payload It is the attack load constraint.

[0020] Furthermore, the control flow hijacking constraint is expressed by the following formula:

[0021] C pc =(any_addr←PC)

[0022] Among them, any_addr is an arbitrary address and PC is the program counter.

[0023] Furthermore, the attack payload constraints include code injection constraints and code reuse constraints, which are used to constrain whether the attack payload can be constructed in the memory space of the program;

[0024] The code injection class constraints include code injection class constraints for stack overflow vulnerabilities and code injection class constraints for formatted string vulnerabilities; the code reuse class constraints include return-oriented programming constraints, code reuse class constraints for stack overflow vulnerabilities and code reuse class constraints for formatted string vulnerabilities.

[0025] Furthermore, the code injection class constraint of the stack overflow vulnerability is expressed by the following formula:

[0026] C payload =(sym_buf←shellcode,shellcode_addr←PC)

[0027] Among them, sym_buf is the symbol memory, shellcode is the filling data, and shellcode_addr is the filling data address.

[0028] The code injection class constraint of the format string vulnerability is expressed as follows:

[0029] C payload =(sym_buf←shellcode,shellcode_addr←Indirect_PC)

[0030] Among them, Indirect_PC is the indirect control program counter.

[0031] Furthermore, the code reuse class constraint of the stack overflow vulnerability is expressed by the following formula:

[0032] C payload =(libc_func _ addr←PC,stack|regs←parameters)

[0033] Among them, libc_func _ addr is the address of the dynamic library function, tack|regs is the stack or register, and parameters is the dynamic library function parameters;

[0034] The code reuse class constraint of the format string vulnerability is expressed as follows:

[0035] C payload =(got←system_addr,stack|regs←parameters)

[0036] Among them, got is the global offset table, and system_addr is the address of the target library function;

[0037] The return-oriented programming constraint is expressed as follows:

[0038] C payload =(ROP_addr←PC,sym_buf←ROP)

[0039] Among them, ROP_addr is the return oriented programming address, and ROP is return oriented programming.

[0040] Furthermore, the constraint expression is expressed by the following formula:

[0041] C cons =C vul ∩C exp

[0042] Among them, C cons is the constraint expression, C vul is the path constraint, C exp To use constraints.

[0043] The second aspect of the present invention proposes a constraint-driven control flow hijacking vulnerability test sample automatic generation system, comprising:

[0044] The exploit constraint module is used to detect the target program, obtain vulnerability information and exploitable points of the target program, and construct exploit constraints based on the exploitable points to facilitate the exploitation of the constrained program after it is executed to the exploitable points;

[0045] The path constraint module is used to construct path constraints based on vulnerability information, so that the program can be executed to the exploitable point of the vulnerability;

[0046] The calculation module is used to solve the constraint expression according to the exploit constraint and the path constraint. If the constraint expression has a solution, the vulnerability exploitation information is output to complete the automatic generation of vulnerability test samples. If the constraint expression has no solution, the constraint expression is solved by reconstructing the exploit constraint to determine whether the vulnerability test sample is successfully generated.

[0047] The third aspect of the present invention proposes an electronic device, comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements a constraint-driven control flow hijacking vulnerability test sample automatic generation method as described in the first aspect above.

[0048] The fourth aspect of the present invention proposes a computer-readable storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the storage medium is located is controlled to execute a constraint-driven control flow hijacking vulnerability test sample automatic generation method as described in the first aspect above.

[0049] Beneficial effects of the present invention:

[0050] (1) The present invention unifies the control flow hijacking method of describing different architecture vulnerabilities from the expression, so that it can effectively exploit vulnerabilities under multiple CPU architectures. This method not only reduces the reliance on manual analysis, but also significantly reduces the risk of errors and omissions in the analysis process. At the same time, it greatly improves the speed and accuracy of vulnerability test sample code generation, making vulnerability analysis testing on different hardware platforms more efficient and reliable.

[0051] (2) The present invention automatically generates control flow hijacking vulnerability test samples by constructing a method of utilizing constraints and path constraints, which has good scalability. By constructing new vulnerability exploitation constraints, different vulnerability exploitation methods can be continuously expanded and adapted. This flexibility enables the system to cope with emerging vulnerability exploitation technologies and ever-changing network security threats, thereby improving the ability to automatically generate vulnerability test samples. Whether facing newly discovered vulnerability types or program vulnerabilities of different architectures, the method of the present invention can provide effective support and provide a powerful tool for vulnerability analysis and repair. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 A flowchart of a method for automatically generating control flow hijacking vulnerability test samples based on constraint-driven control flow hijacking vulnerability test samples provided by an embodiment of the present invention.

[0053] Figure 2 The present invention provides a second flowchart of a method for automatically generating control flow hijacking vulnerability test samples based on constraint-driven control flow hijacking vulnerability testing.

[0054] Figure 3 An architectural diagram of a method for automatically generating control flow hijacking vulnerability test samples based on constraint-driven control flow hijacking vulnerability test samples provided by an embodiment of the present invention.

[0055] Figure 4An architectural diagram of a constraint-driven control flow hijacking vulnerability test sample automatic generation system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0056] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution in the embodiment of the present invention will be clearly described below in conjunction with the drawings in the embodiment of the present invention. Obviously, the described embodiment is a part of the embodiment of the present invention, not all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0057] Example 1

[0058] like Figure 1 As shown, a method for automatically generating control flow hijacking vulnerability test samples based on constraint-driven control flow hijacking vulnerability test samples includes:

[0059] S101: Detect the target program, obtain vulnerability information and exploitable points of the target program, and construct exploit constraints based on the exploitable points.

[0060] Specifically, the present invention detects the target program through a symbolic execution vulnerability detection method based on vulnerability orientation, obtains exploitable points, and constructs exploit constraints, which include control flow hijacking constraints and attack payload constraints. The vulnerability can be exploited to perform subsequent operations at the exploitable point. The present invention proposes three standards for successfully exploiting the vulnerability, including generating proof of concept (POC), hijacking control flow, and generating exploits (Exploit). For stack overflow vulnerabilities and formatted string vulnerabilities, the exploitability can be made clear, that is, the program state can be hijacked by the control flow when the vulnerability is detected. If the control flow hijacking constraint can be solved, and the attack payload constraint cannot be constructed, the exploitability of the vulnerability is hijacking the control flow. If both constraints can be solved, they can be successfully exploited.

[0061] S102: Construct path constraints according to vulnerability information.

[0062] Specifically, path constraints refer to a series of conditions or constraints that must be met in software testing and vulnerability detection in order to achieve specific test goals or trigger specific vulnerabilities. These constraints ensure that the program can be executed in a predetermined manner, thereby triggering the vulnerability and possibly further exploiting it. During the symbolic execution process, each possible execution path is tracked. When the program encounters a conditional judgment, the symbolic execution engine determines the execution path of the program based on the result of the judgment (true or false). Path constraints are designed to ensure that program execution can reach and trigger the vulnerability point, thereby verifying its exploitability. For vulnerabilities such as stack overflow and formatted string, the construction of path constraints is based on the program state information obtained during the vulnerability detection phase.

[0063] The process of building path constraints involves replacing the input of the program with symbolic variables and then tracing the execution path of the program in symbolic execution. When a conditional statement is encountered, the corresponding constraint conditions are recorded and accumulated as path constraints.

[0064] When using the vulnerability-oriented symbolic execution vulnerability detection method, the potential vulnerability locations in the program can be accurately identified. By simulating program execution and generating detailed path constraints (here, existing technologies are used to generate path constraints, specifically refer to Automatic Exploit Generation), anomalies in program behavior can be found, which often indicate the existence of exploitable vulnerabilities. Symbolic execution technology explores all possible program execution paths and generates corresponding constraints for each path. Once these constraints are met, it means that the corresponding execution path is reachable, thereby verifying the existence of the vulnerability and its potential for exploitation.

[0065] S103: Solve the constraint expression according to the exploit constraint and the path constraint. If the constraint expression has a solution, output the vulnerability exploitation information to complete the automatic generation of vulnerability test samples. If the constraint expression has no solution, reconstruct the exploit constraint to solve the constraint expression.

[0066] Specifically, the constraint expression is expressed as follows:

[0067] C cons =C vul ∩C exp

[0068] Among them, C cons is the constraint expression, C vul is the path constraint, C exp To use constraints.

[0069] If the expression can be solved, the vulnerability exploitation information is output, and the vulnerability test sample is automatically generated. If there is no solution, different control flow hijacking and attack payloads are rebuilt to build new exploitation constraints and try to solve it again.

[0070] like Figure 2 As shown, the present invention detects the target program. When a vulnerability is detected, the exploit constraint is first constructed according to the characteristics of the target program and the vulnerability, including the control flow hijack constraint and the attack load constraint. Then the path constraint is constructed, and the constraint expression is constructed and solved by combining the exploit constraint and the path constraint. If the constraint is solvable or the exploit constraint is constructed, the vulnerability exploit information is output; otherwise, the exploit constraint is reconstructed and solved again.

[0071] Example 2

[0072] Based on the above embodiments, Figure 3 As shown, the embodiment of the present invention provides a construction process using constraints, which specifically includes:

[0073] Different methods are used to construct exploit constraints for different vulnerability types (stack overflow vulnerabilities and format string vulnerabilities). The exploit constraints are used to constrain the program to exploit the vulnerability after the program is executed to the exploitable point. The exploit constraints are expressed as follows:

[0074] C exp =C pc ∩C payload

[0075] Among them, C exp To utilize the constraint, C pc For control flow hijacking constraints, C payload It is the attack load constraint.

[0076] The control flow hijacking constraint is used to constrain the control flow of the program to point to the location of the constructed attack payload, and the attack payload constraint is used to constrain whether the attack payload can be constructed in the memory space of the program.

[0077] For control flow hijacking constraints, when facing a stack overflow vulnerability, the control flow hijacking constraints are expressed as follows:

[0078] C pc =(any_addr←PC)

[0079] Among them, any_addr is an arbitrary address and PC is the program counter.

[0080] When facing a format string vulnerability, an attacker can use a carefully constructed format string input to obtain sensitive information in the program or execute malicious code. By exploiting this type of vulnerability to achieve the function of arbitrary address writing, the attacker can indirectly control the program counter to point to the address of the attack payload. The attacker can use the following formula strategy to achieve the goal of arbitrary address writing:

[0081] payload=address+padding+%offset$n

[0082] Among them, payload is the effective load, address is the target address, padding is the padding byte, %offset is the number of characters from the beginning of the string to the position to be formatted, and $n is to use the nth parameter to replace %offset.

[0083] The above formula is used to implant and execute the attack code in the program's memory space.

[0084] The attack payload constraints are constructed in different ways according to the different ways of vulnerability exploitation, and are divided into two types: code injection and code reuse. Code injection refers to the use of vulnerabilities to inject attack payloads into the program, so that when it is executed, the attack payload injected by the attacker will be executed to achieve malicious functions. Code reuse refers to the use of existing code blocks (such as library functions, operating system calls, etc.) to combine attack payloads, bypass the security protection mechanism of the program, and achieve the malicious purpose of the attacker.

[0085] Since constraint solving takes a lot of time and is prone to solving failures, we design prerequisites for attack payload construction. When selecting a vulnerability exploit method, we analyze the capabilities of the current vulnerability, select an exploit method that meets the prerequisites for attack payload construction, and then build and solve control flow hijacking constraints and attack payload constraints. Otherwise, we only build control flow hijacking constraints, which can achieve control flow hijacking but cannot generate an Exploit.

[0086] For code injection exploits, the typical way to exploit stack overflow vulnerabilities is to return malicious code (return-to-shellcode). The attacker will write a malicious code (shellcode) and put it in the buffer. Then, the attacker will overflow the buffer by inputting too much data, overwriting the program's return address with the address of the malicious shellcode in the buffer. In this way, when the program is executed and attempts to return, it will jump to the code of the malicious shellcode to execute, thereby achieving the attacker's malicious purpose. The prerequisites that need to be met for building a code injection attack payload include:

[0087] Symbol memory (sys_buf) has readable, writable, and executable properties.

[0088] The length of sys_buf is not less than the length of shellcode.

[0089] The program does not have NX (No Execute) security enabled.

[0090] After the prerequisites are met, the code injection class exploit constraint for the stack overflow vulnerability includes the following steps:

[0091] 1. Use the symbolic memory block search algorithm to find the symbolic memory address (sym_buf) where the shellcode can be stored.

[0092] 2. Write the shellcode into sym_buf and fill the extra part of sym_buf with NOP (no operation instruction).

[0093] 3. Constrain the data of the program counter (PC) to the address of the shellcode, so that the program control flow is transferred to the memory where the shellcode is located.

[0094] The construction process is expressed as follows:

[0095] C payload =(sym_buf←shellcode,shellcode_addr←PC)

[0096] Among them, sym_buf is the symbol memory, shellcode is the filling data, and shellcode_addr is the filling data address.

[0097] For format string vulnerabilities, attackers inject shellcode into the memory space and use arbitrary address write operations to hijack the control flow, thereby pointing the program control flow to the address of the shellcode. The code injection attack of the format string vulnerability is described using the following formula:

[0098] C payload =(sym_buf←shellcode,shellcode_addr←Indirect_PC)

[0099] Among them, Indirect_PC is the indirect control program counter.

[0100] First, a constraint is constructed to write the complete shellcode into the controllable memory sym_buf. Then, the program control flow is transferred to the memory where the shellcode is located by indirectly controlling the PC and constraining the data in the PC to be the address of the shellcode.

[0101] After enabling NX protection, the shellcode stored in the stack buffer will be treated as data and cannot be executed, which will make the code injection type of exploitation fail. In order to bypass this protection, a technique that can bypass NX is required.

[0102] For stack overflow vulnerabilities, there are two techniques, return to C standard library attack (return_to_libc) and return-oriented programming (ROP), to bypass NX protection measures. The return-to-libc attack transfers the control flow to the existing standard library function (such as system()) in the program by overwriting the return address of the program, and injects appropriate parameters (such as / bin / sh) on the stack to simulate the function call. Attacks using the return-to-libc technique must meet two key restrictions: first, the program counter must point to the valid address of the target library function, and second, the correct dynamic library function parameters must be constructed on the stack.

[0103] Depending on the program structure and architecture, attacks using the return-to-libc technique need to meet certain prerequisites, including the presence of exploitable dynamic library functions in the program (such as system(), execl(), execve(), etc.), and the possible need to disable ASLR (Address Space Layout Randomization) protection.

[0104] For the return-to-libc method of stack overflow vulnerability, the data of program counter PC is constrained to the address of dynamic library function, and the corresponding dynamic library function parameters are constructed in the stack or register. The code reuse class constraint of stack overflow vulnerability is expressed as follows:

[0105] C payload =(libc_func _ addr←PC,stack|regs←parameters)

[0106] Among them, libc_func _ addr is the address of the dynamic library function, tack|regs is the stack or register, and parameters is the dynamic library function parameters.

[0107] In the return-to-libc mode, for the formatted string vulnerability, the GOT table entry can be modified to point to the library function address, effectively bypassing the NX protection. The exploit constraints of this type of attack include: first, constructing the GOT table entry to point to the address of the target library function; second, ensuring that the parameters required for the library function execution are correct. The specific exploit constraint construction needs to be adjusted according to different system architectures and vulnerability situations. When constructing the exploit constraint, the fmtstr technique in pwntools can be used to accurately modify the GOT table entry and adjust its address to the address of the target library function. During the exploitation process, the limitations of other vulnerability protection measures such as ASLR and Canary also need to be considered. The code reuse class constraint of the formatted string vulnerability is expressed as follows:

[0108] C payload =(got←system_addr,stack|regs←parameters)

[0109] Among them, got is the global offset table and system_addr is the address of the target library function.

[0110] Angrop is needed when constructing attack payload constraints through ROP. Angrop is a vulnerability exploitation tool based on symbolic execution, which is specifically used to automatically generate ROP chains. It can automatically generate valid ROP chains through symbolic execution of programs, thus playing an important role in the vulnerability exploitation process. When the target program has a complete ROP chain and sufficient stack space, constraints can be constructed byte by byte for the symbolic variables corresponding to the length of the ROP chain, such as "symbolicByte_index=ROPChainByte_index", to achieve effective utilization. By solving these constraints, a complete exploitation input can be obtained. Return-oriented programming constraints are expressed as follows:

[0111] C payload =(ROP_addr←PC,sym_buf←ROP)

[0112] Among them, ROP_addr is the return oriented programming address, and ROP is return oriented programming.

[0113] Return-oriented programming constraints are applicable to various vulnerability types such as stack overflow vulnerabilities and format string vulnerabilities.

[0114] Example 3

[0115] Corresponding to the above method, such as Figure 4 As shown, a constraint-driven control flow hijacking vulnerability test sample automatic generation system includes:

[0116] The utilization constraint module is used to detect vulnerable programs, obtain vulnerability information and exploitable points of vulnerable programs, and construct utilization constraints based on the exploitable points.

[0117] The path constraint module is used to build path constraints based on vulnerability information.

[0118] The calculation module is used to solve the constraint expression according to the exploit constraint and the path constraint. If the constraint expression has a solution, the vulnerability test sample is successfully generated. If the constraint expression has no solution, the constraint expression is solved by reconstructing the exploit constraint.

[0119] Example 4

[0120] Corresponding to the above method, an embodiment of the present invention provides an electronic device, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements a constraint-driven control flow hijacking vulnerability test sample automatic generation method as described in the above embodiment.

[0121] Preferably, an embodiment of the present invention provides a computer-readable storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the storage medium is located is controlled to execute a constraint-driven control flow hijacking vulnerability test sample automatic generation method as described in the above embodiment.

[0122] In summary, the present invention can effectively exploit vulnerabilities under multiple CPU architectures by uniformly describing the control flow hijacking method of different architecture vulnerabilities from the expression. This method not only reduces the reliance on manual analysis, but also significantly reduces the risk of errors and omissions in the analysis process. At the same time, it greatly improves the speed and accuracy of vulnerability test sample code generation, making vulnerability analysis tests on different hardware platforms more efficient and reliable. The present invention automatically generates control flow hijacking vulnerability test samples by constructing a method of utilizing constraints and path constraints, which has good scalability. By constructing new vulnerability exploitation constraints, different vulnerability exploitation methods can be continuously expanded and adapted. This flexibility enables the system to cope with emerging vulnerability exploitation technologies and ever-changing network security threats, thereby enhancing the ability to automatically generate vulnerability test samples. Whether facing newly discovered vulnerability types or program vulnerabilities of different architectures, the method of the present invention can provide effective support and provide a powerful tool for vulnerability analysis and repair.

[0123] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A constraint-driven control flow hijacking vulnerability test sample automatic generation method, characterized in that: include: Step 1: Detect the target program, obtain vulnerability information and exploitable points of the target program, and build exploit constraints based on the exploitable points; Step 2: Construct path constraints based on vulnerability information; Step 3: Solve the constraint expression according to the exploit constraint and path constraint. If the constraint expression has a solution, output the vulnerability exploitation information and complete the automatic generation of vulnerability test samples. If the constraint expression has no solution, rebuild the exploit constraint to solve the constraint expression.

2. According to claim 1, a constraint-driven control flow hijacking vulnerability test sample automatic generation method is characterized in that: The utilization constraint is expressed as follows: C exp =C pc ∩C payload Among them, C exp To utilize the constraint, C pc For control flow hijacking constraints, C payload It is the attack load constraint.

3. According to claim 2, a constraint-driven control flow hijacking vulnerability test sample automatic generation method is characterized in that: The control flow hijacking constraint is expressed as follows: C pc =(any_addr←PC) Among them, any_addr is an arbitrary address and PC is the program counter.

4. According to claim 2, a constraint-driven control flow hijacking vulnerability test sample automatic generation method is characterized in that: The attack payload constraints include code injection constraints and code reuse constraints; The code injection class constraints include code injection class constraints for stack overflow vulnerabilities and code injection class constraints for formatted string vulnerabilities; the code reuse class constraints include return-oriented programming constraints, code reuse class constraints for stack overflow vulnerabilities and code reuse class constraints for formatted string vulnerabilities.

5. According to claim 4, a constraint-driven control flow hijacking vulnerability test sample automatic generation method is characterized in that: The code injection class constraint of the stack overflow vulnerability is expressed as follows: C payload =(sym_buf←shellcode,shellcode_addr←PC) Among them, sym_buf is the symbol memory, shellcode is the filling data, and shellcode_addr is the filling data address. The code injection class constraint of the format string vulnerability is expressed as follows: C payload =(sym_buf←shellcode,shellcode_addr←Indirect_PC) Among them, Indirect_PC is the indirect control program counter.

6. According to claim 4, a constraint-driven control flow hijacking vulnerability test sample automatic generation method is characterized in that: The code reuse class constraint of the stack overflow vulnerability is expressed as follows: C payload =(libc_func _ addr←PC,stack|regs←parameters) Among them, libc_func _ addr is the address of the dynamic library function, tack|regs is the stack or register, and parameters is the dynamic library function parameters; The code reuse class constraint of the format string vulnerability is expressed as follows: C payload =(got←system_addr,stack|regs←parameters) Among them, got is the global offset table, and system_addr is the address of the target library function; The return-oriented programming constraint is expressed as follows: C payload =(ROP_addr←PC,sym_buf←ROP) Among them, ROP_addr is the return oriented programming address, and ROP is return oriented programming.

7. The method for automatically generating control flow hijacking vulnerability test samples based on constraint-driven control flow hijacking vulnerability test samples according to claim 1, characterized in that: The constraint expression is expressed as follows: C cons =C vul ∩C exp Among them, C cons is the constraint expression, C vul is the path constraint, C exp To use constraints.

8. A constraint-driven control flow hijacking vulnerability test sample automatic generation system, characterized in that: include: The utilization constraint module is used to detect the target program, obtain vulnerability information and the exploitable points of the target program, and build the utilization constraint according to the exploitable points; Path constraint module, used to build path constraints based on vulnerability information; The calculation module is used to solve the constraint expression according to the exploit constraint and the path constraint. If the constraint expression has a solution, the vulnerability exploitation information is output to complete the automatic generation of vulnerability test samples. If the constraint expression has no solution, the exploit constraint is reconstructed to solve the constraint expression.

9. An electronic device, characterized in that: It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements a constraint-driven control flow hijacking vulnerability test sample automatic generation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The storage medium includes a stored computer program, wherein when the computer program is running, the device where the storage medium is located is controlled to execute a constraint-driven control flow hijacking vulnerability test sample automatic generation method as described in any one of claims 1 to 7.

Images