A data-oriented vulnerability search method for binary programs

Abstract

The application provides a binary program-oriented data-oriented vulnerability searching method, and belongs to the technical field of computers, and comprises the following steps: inputting test data into a target binary program in a computer and running the target binary program; saving a memory snapshot when the target binary program runs to a vulnerability function where a memory error vulnerability is located; marking test data data of a buffer zone input into the computer in the memory snapshot as a pollution source; and executing the target binary program with a first instruction of the vulnerability function as a starting point. If any memory copy Gadget that copies data in the memory to other memory positions and any address write Gadget that writes data in the memory are found in the process of executing the target binary program, it is determined that the current memory error vulnerability is sufficient to be upgraded to a data-oriented vulnerability DOP for exploitation. The method can analyze data-oriented vulnerability availability of a binary program.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a data-oriented vulnerability retrieval method for binary programs. Background Technology

[0002] In the current field of binary security, Data-Oriented Programming (DOP) vulnerabilities have become a significant threat. DOP vulnerabilities exploit existing data fragments within a program to construct malicious behavior, independent of the program's control flow. This makes traditional defense mechanisms and detection techniques much more difficult to address DOP vulnerabilities.

[0003] While some memory errors, once discovered, typically cause program crashes, these errors can potentially be escalated into DoP (Domain-Operated Exploit) vulnerabilities and exploited if the user carefully crafts the program input. Therefore, determining whether a current memory error can be escalated into a DoP vulnerability is a crucial issue.

[0004] Existing defense mechanisms and detection tools mainly focus on traditional control flow hijacking attacks and have limited analytical capabilities for DOP vulnerabilities. Therefore, there is currently a lack of an efficient and accurate method and system to analyze whether current memory errors have the potential for DOP vulnerability exploitation. Summary of the Invention

[0005] To overcome the shortcomings of the existing technology, the present invention provides a data-oriented vulnerability retrieval method for binary programs.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A data-driven vulnerability retrieval method for binary programs includes:

[0008] Input test data into the target binary program in the computer and run the target binary program. When the target binary program runs to the vulnerable function where the memory error vulnerability is located, save a memory snapshot.

[0009] Mark the test data in the memory snapshot as a source of contamination, and execute the target binary program starting from the first instruction of the vulnerable function.

[0010] When the target binary program executes a data transfer instruction contaminated by a contamination source, if the operation of the contamination source-contaminated data transfer instruction is to write back to memory, then the instruction of the destination operand is cleared, and the instruction of the source operand is retrieved in the order it entered memory. The instruction of the source operand and the current instruction are then combined to form a Gadget.

[0011] If, during the execution of the target binary program, an arbitrary memory copy instruction (AMC Gadget) is found to copy data from memory to another memory location, and an arbitrary address write instruction (AMWGadget) is found to write data to an arbitrary memory location, then the current memory error vulnerability is deemed sufficient to be upgraded to a Data-Driven Exploitation (DOP) vulnerability.

[0012] Furthermore, it also includes:

[0013] The instruction address of the first instruction of the vulnerable function is taken as the starting point of the analysis, the instruction address of the first Gadget G1 is taken as the analysis endpoint 1, and the instruction address of the second Gadget G2 is taken as the analysis endpoint 2.

[0014] Obtain the backward slice plot between the analysis start point and analysis end point 1; based on the backward slice plot between the analysis start point and analysis end point 1, obtain the z3 expression expr1 of analysis end point 1 relative to the analysis start point;

[0015] Obtain the backward slice between the analysis start point and the analysis end point 2; based on the backward slice between the analysis start point and the analysis end point 2, obtain the z3 expression expr2 of the analysis end point 2 relative to the analysis start point;

[0016] If there is a solution if expr1 == expr2, then there is a data flow dependency between analysis endpoint 1 and analysis endpoint 2; otherwise, there is no data flow dependency between analysis endpoint 1 and analysis endpoint 2.

[0017] If there is a data flow dependency between analysis endpoint 1 and analysis endpoint 2, combine G1 and G2 into a single Gadget.

[0018] Furthermore, obtaining the backward slice diagram between the analysis start point and the analysis end point 1 includes:

[0019] Collect and analyze the binary bytecode between the analysis start point and the analysis end point 1, and convert the binary bytecode into a VEX IR instruction sequence;

[0020] The VEX IR instruction sequence is broken down into subexpressions, and a data flow graph (DFG) is constructed based on the VEX IR statement type, subexpression type, and the read temporary variables, registers, and memory.

[0021] Extract the backward slice plot between the analysis start point and analysis end point 1 from the DFG.

[0022] Furthermore, it also includes:

[0023] Perform a layer-order traversal of the backward slice graph between the analysis start point and the analysis end point 1. For each VEX IR node in the backward slice graph, split the VEX IR node into a subexpression.

[0024] Convert the subexpression to a z3 expression;

[0025] The expression range of the corresponding register and memory at the analysis endpoint 1 is solved using the Optimize class of the z3 expression. The corrupted memory is then determined based on the expression range of the corresponding register and memory at the analysis endpoint 1.

[0026] For the contaminated memory, execute the target binary program starting from the found Gadget G1, until the second Gadget G12 is found;

[0027] If the source address of G12 is covered by the pollution of G1, then G12 is regarded as a new arbitrary memory read AMR Gadget; if the destination address of G12 is covered by the pollution of G1, then G12 is regarded as a new arbitrary address write AMW Gadget; if the source address of G12 is covered by the pollution of G1 and the destination address of G12 can be polluted, then G2 is regarded as an arbitrary memory copy AMC Gadget.

[0028] Continue executing the target binary program starting from G12 until no new Gadget can be found or the currently explored Gadget makes the program DOP available.

[0029] Furthermore, Gadget G1 is either an AMW Gadget that writes to any address or an AMC Gadget that copies memory to any memory.

[0030] Furthermore, it also includes: path exploration during the execution of the target binary program, including:

[0031] During path exploration, all branches whose decision conditions are contaminated are defined as symbolic branches, and the basic block containing the symbolic branch is defined as a symbolic node; the symbolic node is:

[0032] mov register1, [address1]

[0033] cmp[address2], register1

[0034] jxx code segment address

[0035] If the cmp instruction in the jump node of a symbolic branch is corrupted, the current branch is defined as a controllable branch;

[0036] During the execution of the target binary program, one path is executed at a time, and all controllable branches traversed in this run and the jump result of this run are recorded;

[0037] After a single path exploration is completed, a generational search is performed on the controllable branches. During the generational search:

[0038] Upon reaching a symbolic branch, record the jump direction of this execution, retrieve the path to that symbolic branch, reverse the jump direction at the end of the path, and generate a new path for the next execution.

[0039] When executing a newly generated path, symbolic execution techniques are used to collect the constraints of the newly generated path and verify the solvability of the path constraints, solving for the symbolic input leading to the path; the path is then executed and new paths are explored.

[0040] Furthermore, it also includes: using the Dispatcher search algorithm to determine whether the current program execution is in a loop structure, in order to control the number of loop iterations and alleviate path explosion; the Dispatcher search algorithm is:

[0041] Use the LoopFinder tool to find loop structures in the target binary program and record the entry and exit edges of all loops;

[0042] A stack is used to store the current loop structure of the simulation execution. During the execution, the instructions to be executed in the simulation are continuously obtained, and the address of the current instruction is checked to see if it is located at the entry edge or exit edge of the loop.

[0043] If it is located at the entry edge of a loop, check if the current top element of the stack is the same as the loop. If not, push the loop onto the stack; otherwise, it indicates that the second round of the same loop has been entered.

[0044] If the current loop is outside the loop, pop the loop from the top of the stack and check if the stack is empty. If it is empty, it means that the current simulation is not in any loop.

[0045] The data-oriented vulnerability retrieval method for binary programs provided by this invention has the following beneficial effects:

[0046] This invention provides a method for analyzing the exploitability of Data-Driven Exploitation (DOP) vulnerabilities in current memory errors. By identifying gadgets involved in the memory error, it determines whether the current memory error can be exploited as a DOP vulnerability. If, during the execution of the target binary program, arbitrary memory copying gadgets (copying data from memory to other memory locations) and write gadgets (writing data to arbitrary addresses in memory) are found, then the current memory error is determined to be exploitable as a Data-Driven Exploitation (DOP) vulnerability. The analysis results can help vulnerability hunters and security experts analyze the risk of software system vulnerabilities being exploited by DOP vulnerabilities. Attached Figure Description

[0047] To more clearly illustrate the embodiments and design schemes of the present invention, the accompanying drawings required for this embodiment will be briefly described below. The drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a schematic diagram of the present invention;

[0049] Figure 2 This is a flowchart of the present invention;

[0050] Figure 3 This is the Dispatcher dispatcher of the present invention. Detailed Implementation

[0051] To enable those skilled in the art to better understand and implement the technical solutions of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are only used to more clearly illustrate the technical solutions of the present invention and should not be construed as limiting the scope of protection of the present invention.

[0052] Example:

[0053] This invention provides a data-driven vulnerability retrieval method for binary programs, specifically as follows: Figure 1 As shown, the process includes: inputting test data into the target binary program and running the target binary program; when the target binary program reaches the vulnerable function and triggers a memory error, saving a memory snapshot and obtaining the data in the current registers and memory; marking the test data in the input buffer of the memory snapshot as the pollution source, and starting the pollution propagation from the first instruction of the vulnerable function; during the pollution propagation process, when a polluted arithmetic instruction is executed, it is directly stored in the instruction cache; when an unpolluted data transfer instruction is executed, all instructions in the instruction cache containing the destination operand of the current instruction are cleared; after a polluted data transfer instruction is executed, the behavior of the current instruction is checked; if the current instruction's operation is to write back to memory, the instructions in the cache containing the destination operand of the current instruction are cleared, and the instructions containing the source operand of the current instruction are retrieved according to the order they entered the cache, forming a Gadget together with the current instruction; if the current instruction's behavior is to access memory and write the content to a register, the instructions in the cache containing that register are cleared, and the current instruction is written to the cache; if an arbitrary memory copy Gadget and an arbitrary address write Gadget are found in the program, the current memory error is determined to be escalated to a DOP vulnerability for exploitation.

[0054] The following are the specific implementation details and principles of this invention:

[0055] S1. Gadget functional modeling; S2. Gadget search; S3. Gadget capability assessment; S4. Incomplete Gadget stitching; S5. Gadget activation; S6. Program carrier DOP usability assessment.

[0056] 1) First, the functionality of Gadgets needs to be modeled and categorized. This invention is used to analyze the possibility that known memory errors could lead to the carrier program being able to exploit DOP vulnerabilities.

[0057] This invention argues that the existence of a Gadget for computational functions does not determine the existence of a DOP vulnerability; a complete data flow vulnerability semantic requires the presence of powerful memory manipulation code snippets.

[0058] This invention targets the binary code fragments required for DOP vulnerability exploitation, and combines taint analysis results to classify the different taint levels of various parts of the instruction.

[0059] This invention defines Gadgets with the following functionalities: Arbitrary Memory Copy (AMC), which allows copying the contents of one memory region to another; Arbitrary Memory Read (AMR), which allows copying the contents of one memory region to another; and Arbitrary Memory Write (AMW), which allows writing data to any address in memory. Furthermore, it defines instruction sequence Gadgets and library function Gadgets according to their existing forms, as follows:

[0060] An instruction sequence Gadget is defined as a sequence of instructions that reads data from a memory address into a register, performs operations on the register, and finally writes it back to memory. Its formal code representation is shown in code snippet 1. Here, `Operational_inst` represents the arithmetic instruction in the assembly code. This instruction is optional; removing it still results in a complete instruction sequence Gadget in code snippet 1.

[0061] mov register 1, [address 1]

[0062] Operational_inst register 1, constant 1

[0063] mov[address2], register1

[0064] Library function Gadget: Defined as a library function implementation with memory assignment capabilities. The formal representation of the library function Gadget based on memcpy is shown in code snippet 2.

[0065] mov rdi, address1

[0066] mov rsi, address2

[0067] mov rdx, register1

[0068] call memcpy

[0069] 2) The Gadget search algorithm defined in S2 needs to be analyzed on a memory snapshot of a program.

[0070] Before the analysis begins, the Proof of Content (PoC) is used as program input and executed until the function where the crash occurs, and a snapshot of the program's memory is saved. The program memory snapshot is loaded, and data in the user input buffer is marked as a source of contamination. The first instruction of the vulnerable function is set as the starting point for simulated execution.

[0071] The simulation process includes taint propagation analysis, data flow analysis, gadget identification, and dispatcher identification.

[0072] 3) Mark external input as contaminated data, implement taint propagation during execution, continuously receive contaminated instructions and cache them, and perform instruction correlation analysis when encountering memory write-back operations to search for instructions in the cache that can form a Gadget with it.

[0073] The following are the implementation details of the Gadget search algorithm:

[0074] External input is marked as contaminated data. During execution, taint propagation is implemented. Contaminated instructions are continuously received and cached. When an operation to store content back into memory is encountered, instruction correlation analysis is performed to search the cache for instructions that can form gadgets with it.

[0075] During algorithm execution, all data transfer instructions and corrupted arithmetic instructions are analyzed. Upon receiving a corrupted arithmetic instruction, it is directly stored in the instruction cache. Upon receiving an uncorrupted data transfer instruction, all instructions in the cache containing the destination operand of the current instruction are cleared. Upon receiving a corrupted data transfer instruction, the behavior of the current instruction is checked. If the current instruction's operation is to write back to memory, the instructions in the cache containing the destination operand of the current instruction are cleared, and the instructions containing the source operand of the current instruction are retrieved in the order they entered memory, forming a gadget together with the current instruction. If the current instruction's behavior is to access memory and write its contents to a register, the instructions in the cache containing that register are cleared, and the current instruction is written to the cache.

[0076] To explore all possible Gadgets, a path exploration strategy needs to be implemented during the simulation. During path exploration, all branches whose decision conditions can be contaminated are defined as symbolic branches, and the basic blocks containing these symbolic branches are defined as symbolic nodes.

[0077] The formal assembly code representation of symbolic nodes in basic blocks is shown in code snippet 3:

[0078] mov register1, [address1]

[0079] cmp[address2], register1

[0080] jxx code segment address

[0081] If the `cmp` instruction in a jump node is contaminated, it indicates that the current branch is a controllable branch. During the simulation, one path is executed at a time, and all controllable branches traversed and the jump results are recorded. After a single execution exploration, a vanilla generational search algorithm is implemented based on the controllable branches. Upon reaching a symbolic branch, the jump direction is recorded, the path leading to that symbolic branch is retrieved, and the jump direction at the end of the path is reversed to generate a new path for the next execution. When executing the newly generated path, symbolic execution techniques are used to collect the path constraints and verify their solvability, solving for the symbolic input leading to the path. The path is then executed, and a new path exploration process begins.

[0082] 3.1) This invention designs a Gadget data flow analysis based on VEX IR to solve the data flow expression of the Gadget contaminated variable searched in step S2.

[0083] The overall approach to Gadget data flow analysis based on VEX IR is as follows: Utilizing data flow analysis techniques and the z3 solver, the precise range of relevant registers and memory for the Gadget is obtained, or the existence of data flow dependencies between two Gadgets is determined. Specific steps include: collecting binary bytecode from the analysis start point to the analysis end point and converting it into an intermediate language VEX IR instruction sequence; then, splitting the VEX IR statement into sub-expressions; and constructing edges of a data flow graph (DFG) based on statement types, sub-expression types, and the read temporary variables, registers, and memory. Next, extracting backward slices containing the analysis end point from the DFG; and finally, obtaining expressions, solving for their ranges, and determining data flow dependencies based on the backward slices.

[0084] The statement types include: Ist_WrTmp, Ist_Store, and Ist_Put. The subexpression types include: Iex_Binop, Iex_RdTmp, Iex_Unop, Iex_Get, Iex_Load, and Iex_Const.

[0085] 4) Expression acquisition and range determination process: The first step is to perform a layer-order traversal of the slice graph. For each VEX IR node, the VEX IR node is first split into sub-expressions. Then, according to the VEX IR node type, sub-expression type and operand type, different conversion strategies are adopted to convert them into z3 expressions. The second step is to use the z3 Optimize class and combine it with the state of the analysis starting point to solve for the expression range of the corresponding registers and memory at the analysis ending point.

[0086] The VEX IR node type and subexpression type correspond to the statement type and subexpression type mentioned in claim 5, respectively.

[0087] Operand types include Iop_Add, Iop_Sub, Iop_Mul, Iop_Div, Iop_Or, Iop_And, Iop_Xor, Iop_Shl, Iop_Shr, and Iop_Sar. Below are the conversion strategies for three different VEX IR statement types:

[0088] (1) IR statement type: Ist_WrTmp. Taking the subexpression type as Iex_Binop, the operand type as Iop_Add, and the VEX IR as t2 = Add64(t1, value) as an example, the conversion process is as follows:

[0089] rvalue1 = z3_exprs["t1"]

[0090] rvalue2=z3.BitVecVal(value,64)

[0091] z3_exprs[t2]=rvalue1+rvalue2

[0092] (2) IR statement type: Ist_Store. Taking VEX IR as STle(t2) = t1 as an example, the conversion process is as follows:

[0093] var_name = "Store_t2"

[0094] rvalue = z3_exprs["t1"]

[0095] z3_expr[var_name]=rvalue

[0096] (3) IR statement type: Ist_Put. Taking VEX IR as PUT(rsi) = t1 as an example, the conversion process is as follows:

[0097] reg_name = rename_reg("rsi")

[0098] rvalue = z3_exprs["t1"]

[0099] z3_exprs[reg_name] = rvalue

[0100] Notes: ① z3_exprs is a dictionary storing expressions for various temporary variables and registers. ② z3.BitVecVal(value, size) creates a z3-bit vector of size size and value value. ③ The rename_reg function is used to rename registers, ensuring the uniqueness of register names.

[0101] 5) Determining data flow dependencies:

[0102] The specific steps for determining data flow dependencies are as follows: Analyze the backward slice between the starting point and the ending point 1, obtain the z3 expression expr1 of the ending point 1 relative to the starting point; analyze the backward slice between the starting point and the ending point 2, obtain the z3 expression expr2 of the ending point 2 relative to the starting point; if expr1 == expr2 has a solution, then it proves that there is a data flow dependency between the ending point 1 and the ending point 2; otherwise, there is no data flow dependency.

[0103] This invention focuses on three key parameters of memory operation gadgets during execution: source address, source data, and destination address. Based on the different levels of contamination of these three parameters, usable memory operation gadgets can be divided into the following three categories:

[0104] Arbitrary Address Write (AMW): The source and destination addresses of a Gadget can be controlled, but the source address cannot. In binary programs, this manifests as the ability to read data from a fixed user data buffer and write it to an arbitrary range of addresses.

[0105] Arbitrary Memory Read (AMR): The source address of the Gadget can be controlled, but the destination address is uncontrollable. That is, it has the ability to read data from any memory address and write it to a fixed memory buffer.

[0106] Arbitrary Memory Copy (AMC): Both the source and destination addresses of the gadget can be controlled. That is, it has the ability to read data from any memory address (except for the user input buffer) and write it to any region of memory.

[0107] Operations (OPE): All operands in a Gadget can be controlled to perform operations on the controlled data.

[0108] Furthermore, the capabilities of a Gadget are not limited to its instruction sequence itself, but also depend on its relationship within the context. This invention defines a Dispatcher search algorithm that uses the angr framework to load a binary program (or dynamic link library), constructs the program's CFG graph, and uses the LoopFinder() method to find any loop structures within it.

[0109] The Dispatcher is defined as follows:

[0110] Distributor: A loop structure whose loop body contains at least two Gadgets whose paths do not overlap. A schematic diagram of the distributor is shown below. Figure 3 :

[0111] Enhancer: Defined as a loop structure that controls only a single Gadget. It contains a counter that increments each time the loop is entered, and this counter directly participates in the Gadget's key variables. Its binary instruction formal description is shown in code snippet 3:

[0112] cmp index register, immediate value 1

[0113] ja exit address

[0114] inc index register

[0115] Move register 1, [base register 1 + index register]

[0116] mov[base register 2 + index register], register 1

[0117] jmp cmp command address

[0118] During the simulation execution, a dispatcher search is performed, recording the control relationship between the found gadgets and the dispatcher. First, a CFG (Cybernetic Scripting Group) of the binary program is constructed, and loop structures are found within the CFG. During the simulation execution, instructions are continuously received, and it is checked whether the current instruction is within a loop and its position within the loop is determined, thereby obtaining the control relationship between the loop and the code segment. The specific algorithm is shown in the figure below:

[0119]

[0120] In the process of evaluating Gadget capabilities, firstly, using the data flow analysis method described in claim 5, a backward slice graph of the data flow from the start of the vulnerable function to the current Gadget is constructed. This allows for the construction of data flow expressions for the corrupted operands in the Gadget, and the value range is calculated according to the method described in claim 6. The value range of the corrupted operands in the Gadget is defined as the Gadget capability. If the current Gadget is controlled by an enhancer, its capability will be enhanced according to the enhancer's maximum loop count.

[0121] 6) Stitching strategy for incomplete Gadgets:

[0122] Taking arbitrary AMR arbitrary memory read and AMW arbitrary address write gadgets as examples, when the destination address of the AMR gadget and the source address of the AMW gadget coincide, memory data can be transferred. Originally, AMR and AMW could only read from and write to fixed addresses, respectively. By calling them in the order of AMR gadget and AMW gadget, they can form an arbitrary memory copy gadget. Similarly, when there are two AMC gadgets, we calculate the range of the target address of AMC1 and the range of the source address of AMC2, construct the data flow between them, and calculate the program input that enables AMC1 and AMC2 to establish a data flow connection. After completing the above work, the gadget activation algorithm is executed. When the search algorithm finds a new gadget G1, G1 must be an AMW gadget or an AMC gadget. Then, gadget capabilities are constructed and the corresponding memory is marked. Subsequently, simulated execution is performed from G1 onwards, and taint propagation is implemented, recording all tainted instructions and searching for a new gadget G2. The activation process defined here is as follows: The key variables (source address, destination address, and data pointed to by the source address) of G2 are rewritten by executing the code sequence of G1 in the program. Then, G2's capabilities are evaluated, the data flow dependencies during execution from G1 to G2 are calculated, and the data flow expressions and value ranges of the polluted variables in G2 are solved. If G2 is an AMW Gadget or an AMC Gadget, then a polluted variable in G2 is used as a memory write address. Polluted memory is further marked according to the value range of this variable. The analysis process defined in claim 3 continues, starting from G2, until the current program is considered DOP complete or no new AMC Gadgets or AMWGadgets are found during the activation process.

[0123] 7) DOP Usability Assessment

[0124] This invention expands the scope of an impact of a known program memory error. If the program contains arbitrary memory copying and arbitrary address write gadgets that can be activated by the memory error and have strong pollution capabilities, then the current memory error is determined to be an exploitable DoP vulnerability.

[0125] The following is a table further defining the availability of the carrier program DOP according to this invention:

[0126] AMCGadget AMWGadget AMRGadget OPEGadget Availability 0 0 x x Low 0 1 0 0 medium 0 1 0 1 higher 0 1 1 0 higher 0 1 1 1 higher 1 0 0 0 medium 1 0 0 1 medium 1 0 1 0 higher 1 0 1 1 higher 1 1 x 0 higher 1 1 x 1 high

[0127] The following are specific embodiments of the present invention:

[0128] (1) Obtain a program memory snapshot;

[0129] (2) Mark polluted memory and use Triton to simulate execution;

[0130] (3) Gadget search;

[0131] (4) Gadget ability assessment;

[0132] (5) Gadget activation;

[0133] (6) Availability assessment of the program carrier DOP.

[0134] First, use GDB to run the target binary program and save a snapshot of the program before the memory error trigger point, and obtain the current data in each register and memory.

[0135] Triton simulation execution includes the following process:

[0136] Static simulation execution. Inputs from the POC are labeled as tainted data and symbolic data, and taint propagation analysis is performed during execution.

[0137] Path exploration. During the execution of (1), all symbolic branches are recorded, and a generational search method is used to explore the path. When a symbolic branch is encountered, the path to the current branch and the jump direction of this execution are recorded. When n new symbolic branches are explored, N new paths are generated. The paths are stored using a dictionary type (dict), and each element represents a key-value pair of the address of the jxx instruction and whether the jump was successful. Its formal description is as follows:

[0138] {jxx addr1:True,jxx addr2:False}

[0139] The collected N paths are inverted by negating the last key-value pairs to generate new paths. Unreachable paths are eliminated using constraint solving. Meanwhile, to mitigate the path explosion problem, this invention limits the number of times a loop in the program is executed to 5. The `angr` function is used to identify the loop's location and record the number of times the same loop is entered. If the same loop is entered too many times, a jump signal is sent to the simulation execution module, and the current execution is terminated.

[0140] Gadget capability assessment. During the analysis, a data flow graph is constructed for each searched memory operation gadget, and a backward slice graph of the gadget is extracted from it. The data flow expression of the contaminated operands in the gadget is constructed, and the corresponding value range is obtained using the z3 solver, which serves as the capability of this gadget.

[0141] Gadget activation. This invention defines the activation process as including a source Gadget G1 and a destination Gadget G2. It should be noted that Arbitrary Memory Read (AMR) Gadgets have weak capabilities and are generally not selected as G1. Arbitrary Address Write (AMW) and Arbitrary Memory Copy (AMC) Gadgets both have the ability to cover key variables. After the Gadget search module in (3) discovers G1, it uses the VEX IR-based Gadgets data flow analysis algorithm code to obtain the expression range of the contaminated operands in G1, thus forming the capability of G1.

[0142] Finally, the corresponding memory is marked according to the taint capability of G1, and then the taint propagation analysis continues from G1. If the source address or destination address of G2 is affected by the taint, it indicates that G2 can be activated. If the source address of G2 is covered by the taint of G1, G2 is considered a new AMR Gadget. Similarly, if the destination address of G2 can be tainted, G2 is considered a new AMW Gadget. If both are possible, then G2 constitutes an AMC Gadget. The activation process is iterative, continuing from G2 as the starting point, until no new Gadget can be found or the currently explored Gadget can enable the program to have DOP availability.

[0143] The Gadget activation method of this invention can expand the impact of memory errors in a program and further propagate the data flow, thereby discovering more Gadgets. This method analyzes the semantics of Gadget instruction sequences, uses data flow techniques to solve for the memory impact range of these sequences, and simulates the impact on memory after fully utilizing the current Gadget. Compared to previous methods, this method can find more and more usable Gadgets and provide the path that triggers these Gadgets.

[0144] Incomplete Gadget Stitching. A program may contain two gadgets with a fixed control flow order and interdependent data flows. For example, G1 and G2 may share variables, and both G1 and G2 may be on a valid control flow path. One possible code representation is as follows:

[0145] G1: memcpy(arg2,arg1)

[0146] G2: memcpy(arg3,arg2)

[0147] During the analysis, the data flow analysis module is used to check for data flow dependencies between G1 and G2, thereby identifying parameter arg2. arg1 and arg3 are contaminated by external data. Sequential execution of G1 and G2 enables arbitrary memory copy operations. Its gadget capability is determined by the range of arg1 and arg3 obtained from the data flow expression.

[0148] Gadget stitching strategy:

[0149] This invention designs a Gadget stitching algorithm that utilizes data flow analysis technology to functionally combine found Gadgets in order to discover more powerful code exploitation methods. Previous methods could only find Gadgets composed of consecutive instruction sequences, and then relied on manual combination of Gadgets. The method designed in this invention can automatically classify Gadgets and stitch them together functionally according to Gadget types, thereby achieving more powerful code functionality and broadening the ways Gadgets can be used.

[0150] Availability assessment of the program carrier DOP.

[0151] During the execution of (3) and (4), the capabilities of the discovered Gadgets are calculated. For example, if a known out-of-bounds write-to-memory error exists, and the parameters of memcpy(arg1,arg2,size) can be modified to completely overwrite arg1 and arg2 with the contents of the user input buffer, and the written arg1 and arg2 are unrestricted, then the current memcpy is considered a fully capable AMC Gadget. Similarly, if arg2 points to the user input buffer, and arg1 can be overwritten by an out-of-bounds write-to-memory error, and arg1 is unrestricted, then the current memcpy is considered a fully capable AMW Gadget.

[0152] Furthermore, if an AMW or AMC Gadget with memory-impacting capabilities is found in a program, and at least one OPE Gadget with data processing capabilities exists, then the current memory error has a high probability of being upgraded to a DOP vulnerability.

[0153] The above-described embodiments are merely preferred embodiments of the present invention, and the scope of protection of the present invention is not limited thereto. Any simple changes or equivalent substitutions of the technical solutions that can be obviously obtained by those skilled in the art within the scope of the technology disclosed in the present invention shall fall within the scope of protection of the present invention.

Claims

1. A data-driven vulnerability retrieval method for binary programs, characterized in that, include: Input test data into the target binary program in the computer and run the target binary program. When the target binary program runs to the vulnerable function where the memory error vulnerability is located, save a memory snapshot. Mark the test data in the memory snapshot as a source of contamination, and execute the target binary program starting from the first instruction of the vulnerable function. When the target binary program executes a data transfer instruction contaminated by a contamination source, if the operation of the contamination source-contaminated data transfer instruction is to write back to memory, then the instruction of the destination operand is cleared, and the instruction of the source operand is retrieved in the order it entered memory. The instruction of the source operand and the current instruction are then combined to form a Gadget. If, during the execution of the target binary program, an arbitrary memory copy instruction (AMC Gadget) is found to copy data from memory to other memory locations, and an arbitrary address write instruction (AMWGadget) is found to write data to any memory location, then the current memory error vulnerability is deemed sufficient to be upgraded to a data-driven vulnerability (DOP) for exploitation. The instruction address of the first instruction of the vulnerable function is taken as the starting point of the analysis, the instruction address of the first Gadget G1 is taken as the analysis endpoint 1, and the instruction address of the second Gadget G2 is taken as the analysis endpoint 2. Obtain the backward slice plot between the analysis start point and analysis end point 1; based on the backward slice plot between the analysis start point and analysis end point 1, obtain the z3 expression expr1 of analysis end point 1 relative to the analysis start point; Obtain the backward slice between the analysis start point and analysis end point 2; The z3 expression expr2 of analysis endpoint 2 relative to the analysis start point is obtained from the backward slice between analysis start point 2 and analysis endpoint 2. If there is a solution if expr1 == expr2, then there is a data flow dependency between analysis endpoint 1 and analysis endpoint 2; otherwise, there is no data flow dependency between analysis endpoint 1 and analysis endpoint 2. If there is a data flow dependency between analysis endpoint 1 and analysis endpoint 2, combine G1 and G2 into a single Gadget.

2. The data-oriented vulnerability retrieval method for binary programs according to claim 1, characterized in that, The process of obtaining the backward slice image between the analysis start point and analysis end point 1 includes: Collect and analyze the binary bytecode between the analysis start point and the analysis end point 1, and convert the binary bytecode into a VEX IR instruction sequence; The VEX IR instruction sequence is broken down into subexpressions, and a data flow graph (DFG) is constructed based on the VEX IR statement type, subexpression type, and the read temporary variables, registers, and memory. Extract the backward slice plot between the analysis start point and analysis end point 1 from the DFG.

3. The data-oriented vulnerability retrieval method for binary programs according to claim 2, characterized in that, Also includes: Perform a layer-order traversal of the backward slice graph between the analysis start point and the analysis end point 1. For each VEX IR node in the backward slice graph, split the VEX IR node into a subexpression. Convert the subexpression to a z3 expression; The expression range of the corresponding register and memory at the analysis endpoint 1 is solved using the Optimize class of the z3 expression. The corrupted memory is then determined based on the expression range of the corresponding register and memory at the analysis endpoint 1. For the contaminated memory, execute the target binary program starting from the found Gadget G1, until the second Gadget G12 is found; If the source address of G12 is overwritten by the pollution of G1, then G12 is treated as a new arbitrary memory read AMR Gadget; if the destination address of G12 is overwritten by the pollution of G1, then G12 is treated as a new arbitrary address write AMW Gadget. If the source address of G12 is covered by the pollution of G1 and the destination address of G12 can be polluted, then G2 is considered an arbitrary memory copy AMC Gadget. Continue executing the target binary program starting from G12 until no new Gadget can be found or the currently explored Gadget makes the program DOP available.

4. The data-oriented vulnerability retrieval method for binary programs according to claim 3, characterized in that, The Gadget G1 is either an AMW Gadget that writes to any address or an AMC Gadget that copies memory to any location.

5. The data-oriented vulnerability retrieval method for binary programs according to claim 1, characterized in that, Also includes: Path exploration is performed during the execution of the target binary program, including: During path exploration, all branches whose decision conditions are contaminated are defined as symbolic branches, and the basic block containing the symbolic branch is defined as a symbolic node; the symbolic node is: mov register1, [address1] cmp [address 2], register 1 jxx code segment address If the cmp instruction in the jump node of a symbolic branch is corrupted, the current branch is defined as a controllable branch; During the execution of the target binary program, one path is executed at a time, and all controllable branches traversed in this run and the jump result of this run are recorded; After a single path exploration is completed, a generational search is performed on the controllable branches. During the generational search: Upon reaching a symbolic branch, record the jump direction of this execution, retrieve the path to that symbolic branch, reverse the jump direction at the end of the path, and generate a new path for the next execution. When executing a newly generated path, symbolic execution techniques are used to collect the constraints of the newly generated path and verify the solvability of the path constraints, solving for the symbolic input leading to the path; the path is then executed and new paths are explored.

6. The data-oriented vulnerability retrieval method for binary programs according to claim 1, characterized in that, Also includes: The Dispatcher search algorithm is used to determine whether the current program execution is in a loop structure, in order to control the number of loop iterations and mitigate path explosion. The Dispatcher search algorithm is as follows: Use the LoopFinder tool to find loop structures in the target binary program and record the entry and exit edges of all loops; A stack is used to store the current loop structure of the simulation execution. During the execution, the instructions to be executed in the simulation are continuously obtained, and the address of the current instruction is checked to see if it is located at the entry edge or exit edge of the loop. If it is located at the entry edge of a loop, check if the current top element of the stack is the same as the loop. If not, push the loop onto the stack; otherwise, it indicates that the second round of the same loop has been entered. If the current loop is outside the loop, pop the loop from the top of the stack and check if the stack is empty. If it is empty, it means that the current simulation is not in any loop.

Images