Symbol solution-based automatic vulnerability utilization and construction method

Abstract

The invention provides an automatic vulnerability utilization and construction method based on symbol solution. The method comprises the following steps: step 1, a utilization generation method based on constraint solution; specifically, code injection and utilization are analyzed, three vulnerability utilization methods of bypassing ASLR by using a springboard and bypassing NX by using return-to-libc are used, and a corresponding automatic utilization data construction process by using a constraint expression phi exp (epsilon) is constructed respectively; step 2, utilizing and generating the automatic vulnerability Exploit; checking a security mechanism of a program starting place through CheckSec; if the program starts NX protection, performing ROP utilization construction in combination with an ROP utilization means; if the program does not start NX protection, whether an ASLR mechanism is started or not is checked, if the ASLR mechanism is started, ROP utilization construction is carried out in combination with an ROP utilization means, and if the ASLR mechanism is not started, two kinds of utilization can be constructed in combination with a Shellcode utilization means and the ROP utilization means. By applying the technical scheme, the automation level, accuracy and efficiency of vulnerability utilization construction can be improved, and progress in the field of security research is promoted.

Description

Technical Field

[0001] The present invention relates to the technical field of vulnerability mining and exploit construction, and in particular to an automated vulnerability exploit construction method based on symbolic solution. Background Art

[0002] Nowadays, there are many types of vulnerabilities in modern software, such as buffer overflows, format string vulnerabilities, integer overflows, etc. Each vulnerability has its own unique triggering conditions and exploitation methods. Successfully exploiting a vulnerability usually requires meeting specific conditions, which may involve complex program states and input data. This makes it extremely complex and time-consuming to manually construct an effective exploitation strategy. Summary of the invention

[0003] In view of this, the purpose of the present invention is to provide an automated vulnerability exploit construction method based on symbolic solving, which can improve the automation level, accuracy and efficiency of vulnerability exploit construction and promote progress in the field of security research.

[0004] To achieve the above object, the present invention adopts the following technical solution: an automated vulnerability exploit construction method based on symbolic solution, comprising the following steps:

[0005] Step 1: Constraint-solving-based exploit generation method; specifically analyze three vulnerability exploit methods: code injection exploit, using a springboard to bypass ASLR, and return-to-libc to bypass NX, and construct corresponding exploit constraint expressions respectively Automating the process of utilizing data to construct;

[0006] Step 2: Generate automatic vulnerability exploits; use CheckSec to check the security mechanisms enabled by the program: if the program has NX protection enabled, then use ROP exploits to build ROP exploits; if the program does not have NX protection enabled, check whether the ASLR mechanism is enabled. If the ASLR mechanism is enabled, then use ROP exploits to build ROP exploits. If ASLR is not enabled, then use Shellcode exploits and ROP exploits to build both exploits.

[0007] In a preferred embodiment, in step 1, code injection utilizes a buffer overflow vulnerability to write the attack code shellcode into the process memory and hijack the program control flow to the memory where the shellcode is located. When the controllable memory block cannot accommodate the shellcode, first, according to the size of the controllable memory block symBuf[i], 0 ≤ i ≤ n, the shellcode is divided into n segments. Then, the shellcode segments are sequentially stored in multiple controllable memory blocks symBuf[i], and jump instructions are used to connect the attack code distributed in different memory blocks, thus completing the attack process;

[0008] The code injection with segmented layout is described using constraints Formula (1) represents the case of max(symBuf[i]) ≥ len(shellcode), 0 ≤ i ≤ n, that is, the method of constructing utilization data when there is a controllable memory block with sufficient space in the process. Here, MaxsymBuf is the memory block with the largest space among all controllable memory blocks. The specific construction method is as follows: First, the data in the memory MaxsymBuf is constrained to the shellcode, so as to write the complete shellcode into the controllable memory. Then, the value of the EIP register in the program state is constrained to the address of MaxsymBuf, and the program control flow is transferred to the memory where the shellcode is located;

[0009] Φexp(ε) = (MaxSymBuf ← shellcode) ∧ [state(ε).eip ← addr(MaxSymBuf)] (1)

[0010] Formula (1) describes the method of constructing utilization data when max(symBuf[i]) < len(shellcode), where 0 ≤ i ≤ n, and jmp_ins[i] is the jump instruction between symBuf[i] and symBuf[i + 1]. When the space of the controllable memory block in the process is insufficient, the segmented shellcode[i] and the jump instruction jmp_ins[i] used to implement the control flow transfer between the segments are sequentially written into multiple controllable memory blocks symBuf[i]. Finally, the EIP register of the program is set to point to the first controllable memory block symBuf[0] storing the shellcode to hijack the program control flow to execute the shellcode;

[0011]

[0012] In a preferred embodiment, in the step 1, the springboard is used to bypass the ASLR. By analyzing the stack operation of the function call process, it can be known that when the program executes the ret instruction to return, the return address will be popped out of the stack frame. After the ret instruction is executed, the ESP register points to the next memory unit after the return address in the stack, and the content in ESP will not be modified by the overflow data; the shellcode is written to the position after the return address in the stack memory, and then the shellcode in the memory is dynamically located with the help of the "jmpesp" instruction, which can be abstracted as the utilization constraint expression shown in formula (3): describe;

[0013] Where:

[0014] mem[state(ε).esp]——the memory on the top of the stack pointed to by register ESP; jmpesp_addr——the address of the "jmpesp" instruction in the program;

[0015] The overflow data can overwrite the stack memory after the return address, so the data in the memory mem[state(ε).esp] is constrained to shellcode, and the shellcode is written to the stack memory. Then, the value of the EIP register in the program state is constrained to the "jmpesp" instruction address to hijack the program control flow; when the program executes the ret instruction, the control flow is first hijacked to the "jmpesp" instruction, and then the jump instruction is executed to transfer to the top of the stack to execute the shellcode.

[0016] In a preferred embodiment, in step 1, return-to-libc bypasses NX and connects the existing code fragments in the memory through jump instructions to construct an attack chain that can complete a specific function, and then hijacks the control flow to the attack chain to execute and complete the exploitation process; return-to-libc calls the function in the C language dynamic link library libc by setting appropriate parameters in the stack to implement arbitrary code execution. The construction process of its attack chain can be expressed by formula (4);

[0017]

[0018] Among them, system_addr is the memory address of the library function system(), exit_addr is the memory address of the library function exit(), and binsh_addr is the address of the string " / bin / sh" in the memory; the address of the library function to be called and its parameters are arranged in the memory through overflow data, the data in the memory mem[state(ε).esp] is constrained to the address of the exit() function as the return address after the system() function is called, the data in the memory mem[state(ε).esp+4] is constrained to the address of the string " / bin / sh" as the parameter when the system() function is called, and the value of the EIP register in the program state is constrained to the address of the system() function to hijack the program control flow; when the vulnerability is triggered, the program control flow is transferred to the attack chain to execute system(" / bin / sh") to return to the system shell, and the exit() function is called after exiting the shell to end the process.

[0019] In a preferred embodiment, there are two ways to construct the Shellcode injection exploit in step 2:

[0020] Method 1: Place the shellcode in a symbolic area controlled by user input;

[0021] Method 2: Write Shellcode to .BSS segment

[0022] For method 1, the conditions required to build the vulnerability exploit are: len(Shellcode)<=size(SymbolicRegion)LoadSymbolicRegion(State)=ShellcodeSymbolic(EIP)=True

[0023] %EIP = ShellcodeAddress

[0024] Among them, condition 1) indicates that the length of the injected Shellcode code should not exceed the size of the selected symbolic memory area, otherwise only part of the Shellcode code can be written into the memory and the final exploitation effect cannot be achieved; condition 2) indicates that the memory of the selected symbolic memory area should be the specific value of the injected Shellcode code; condition 3) indicates that in the current state, the return address EIP must be symbolic, otherwise the program control flow cannot be controlled; condition 4) indicates that the return address EIP needs to point to the memory address where the Shellcode is placed;

[0025] For method 2, the conditions required to build the vulnerability exploit are:

[0026] FindReadFunction(Binary)=TrueFindMemInBSS(Binary)=True

[0027] ReadShellcodeInBSS(State)=TrueSymbolic(EIP)=True

[0028] %EIP = ShellcodeAddress

[0029] Among them, condition 1.) means that it is necessary to find the read or gets function in the program, and use these functions that write to the memory to write the Shellcode code to the .BSS segment; condition 2.) means starting from the high address position of the program .BSS segment and moving towards the low address, a memory area that can accommodate the Shellcode is found; condition 3.) means that by constructing ROP, the Shellcode is written into the found .BSS memory area that can store the Shellcode using the read or get function; condition 4.) means that in the symbolic state after the Shellcode is successfully written, the return address EIP is still symbolic; condition 5.) means that the return address EIP points to the starting address of the Shellcode in the .BSS segment.

[0030] In a preferred embodiment, the ROPExploit generation in step 2 is specifically that when the binary program turns on the stack non-executable protection, it means that the injected Shellcode code cannot be executed, and the exploit cannot be successful; using the existing code fragment Gadget in the memory, the starting addresses of these Gadgets are pieced together into a GadgetChain, hijacking the control flow of the program, making the program jump between these Gadgets, executing the functions possessed by the Gadgets, and thus piecing together a complete and more complex function, which can ignore the stack non-executable protection and achieve the purpose of exploitation.

[0031] In a preferred embodiment, in the GadgetChain construction process based on the program itself in step 2, it is first necessary to find the address value of the system library function called in the binary program; the execution of the system function also requires a parameter, namely the address of the " / bin / sh" string; since the string " / bin / sh" may not exist in the binary program, the easiest way is to write " / bin / sh" by yourself and use the written address as the parameter of the system function; writing data to the memory requires calling functions such as read or gets, so it is also necessary to find the address value of calling library functions such as read or gets in the binary program.

[0032] In a preferred embodiment, the step 2 uses the method of finding the required Gadget address from the dynamic link library to construct a GadgetChain based on the dynamic link library; when the Linux ELF program is executed, the dynamic link library it uses is dynamically loaded into a certain address segment in the memory. If the system turns on ASLR, the address segment it loads is variable, otherwise it is fixed; the actual address of the function in the dynamic link library in the memory will change with the address of the dynamic link library loading, but the relative offset of the library function relative to the starting position of the dynamic link library is fixed and unchanged; if the actual address of one of the library functions in the memory is known, then the loading base address of the dynamic link library is calculated according to the offset of the library function in the dynamic link library; after knowing the loading base address of the dynamic link library, as long as the offset of any function in the dynamic link library in the library is known, The actual address of any library function in memory can be calculated; the dynamic link library is loaded into a certain location in the memory. When the actual address addr of the library function function1 is known, the base address LibBaseAddr=addr1-offset1 of the dynamic link library loading is calculated. If you want to use the library function function2, calculate the actual address addr2=LibBaseAddr+offset2 of function2 in memory; when the program is run and loaded into the memory, the actual address of the library function called in the program in the memory will be saved in the GOT table entry of the program; here, by leaking the actual address of a certain library function saved in the .GOT table entry, the above method is used to indirectly calculate the required system function address, which is used to construct system(' / bin / sh') to open the shell.

[0033] Compared with the prior art, the present invention has the following beneficial effects:

[0034] 1. Enhanced constraint solving capabilities: Improve the symbolic solver to enable it to handle more complex constraints and boundary conditions, thereby supporting more complex vulnerability exploitation conditions. Introduce new solving algorithms or optimize existing algorithms to improve solving speed and accuracy.

[0035] 2. Dynamic path optimization: Combined with dynamic analysis technology, the path exploration strategy is dynamically adjusted during the symbolic execution process to more efficiently discover and exploit vulnerabilities. This includes adjusting the symbolic execution strategy based on actual runtime feedback to reduce the exploration of invalid paths.

[0036] 3. Integrate multiple analysis techniques: Combine symbolic execution with other analysis techniques (such as static analysis and dynamic taint analysis) to comprehensively analyze program behavior and vulnerability exploitation conditions, and provide more accurate vulnerability exploitation construction.

[0037] 4. Automated exploit template generation: Develop automated tools to generate vulnerability exploit templates, automatically create a common exploit code framework based on specific vulnerability characteristics, and reduce manual intervention and development time.

[0038] 5. Integrated intelligent heuristic search: Use machine learning or heuristic algorithms to optimize the symbolic execution process, intelligently select and evaluate paths, thereby improving the efficiency and effectiveness of vulnerability exploit construction.

[0039] 6. Cross-platform support: Extending symbolic execution tools to support different operating systems and platforms enables vulnerability exploit construction to adapt to a wider range of application environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A schematic diagram of code injection using a segmented layout according to a preferred embodiment of the present invention;

[0041] Figure 2 A schematic diagram of using a springboard to bypass ASLR in a preferred embodiment of the present invention;

[0042] Figure 3 This is a schematic diagram of the disassembly result of a program calling the strcpy function in a preferred embodiment of the present invention;

[0043] Figure 4 A schematic diagram of return-to-libc bypassing NX in a preferred embodiment of the present invention;

[0044] Figure 5 Construct an overall block diagram for Exploit in the preferred embodiment of the present invention;

[0045] Figure 6 A schematic diagram of injecting Shellcode into a symbolic area according to a preferred embodiment of the present invention;

[0046] Figure 7 This is a schematic diagram of injecting Shellcode into the .BSS segment according to a preferred embodiment of the present invention;

[0047] Figure 8 A schematic diagram of GadgetChain in a preferred embodiment of the present invention;

[0048] Fig. 9 A schematic diagram of the basic structure of GadgetChain based on the program itself in a preferred embodiment of the present invention;

[0049] Fig.10 A schematic diagram of the relative positions of the symbolized area and the current ESP in a preferred embodiment of the present invention;

[0050] Fig.11 A schematic diagram of the Chain structure of the read function of the preferred embodiment of the present invention;

[0051] Fig.12 A schematic diagram of loading a dynamic link library into a memory according to a preferred embodiment of the present invention;

[0052] Fig.13 A schematic diagram of a leaked .GOT table entry in a preferred embodiment of the present invention;

[0053] Fig.14 A schematic diagram of constructing a System call according to a preferred embodiment of the present invention;

[0054] Fig.15 A schematic diagram of symbolic recovery from a crash state according to a preferred embodiment of the present invention;

[0055] Fig.16 A schematic diagram of a branch successor path selection process according to a preferred embodiment of the present invention;

[0056] Fig.17 A schematic diagram of stack overflow overwriting return address analysis in a preferred embodiment of the present invention;

[0057] Fig.18 A schematic diagram of memory read and write vulnerability analysis according to a preferred embodiment of the present invention;

[0058] Fig.19 This is a schematic diagram of the Shellcode injection and utilization process of a preferred embodiment of the present invention;

[0059] Fig. 20 A schematic diagram of a code reuse process based on a program itself according to a preferred embodiment of the present invention;

[0060] Fig.21 The figure is a schematic diagram of a code reuse process based on a dynamic link library according to a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0061] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0062] It should be noted that the following detailed descriptions are illustrative and are intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used in the present invention have the same meanings as those commonly understood by those skilled in the art to which the present application belongs.

[0063] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application; as used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or their combinations.

[0064] An automated vulnerability exploit construction method based on symbolic solution, reference Figure 1-21 , combines symbolic execution with other analysis techniques (such as static analysis and dynamic taint analysis) to comprehensively analyze program behavior and vulnerability exploitation conditions, provide more accurate vulnerability exploitation construction, develop automated tools to generate vulnerability exploitation templates, and automatically create a general exploitation code framework based on specific vulnerability characteristics, reducing manual intervention and development time.

[0065] 1. Utilization Generation Method Based on Constraint Solving

[0066] Through analysis, we find the expression that satisfies the vulnerability constraint. After the state, it is necessary to further determine whether the state satisfies the constraint expression In order to try to construct an attack chain to hijack the program control flow. If the program state can satisfy the above two constraint expressions at the same time, the vulnerability exploit data can be quickly solved. This section specifically analyzes three vulnerability exploit methods: code injection exploit, using a springboard to bypass ASLR, and return-to-libc to bypass NX, and constructs the corresponding exploit constraint expressions respectively. Automate the process of constructing data.

[0067] 1) Code injection exploitation of segmented layout

[0068] Code injection exploits a buffer overflow vulnerability to write attack code shellcode into the process memory and hijack the program control flow to the memory where the shellcode is located, ultimately achieving the attack effect of executing arbitrary code. Shellcode originally refers to a section of attack code injected into the process to obtain the system shell when exploiting a vulnerability. In a broad sense, any code injected into a process for the purpose of attack can be called shellcode, and its function can be to steal data, delete files, format the hard disk, and other offensive behaviors.

[0069] The premise of code injection is to write the attack code into the target process, so there should be a controllable memory block in the process that is large enough to accommodate the shellcode. If the size of the controllable memory block is not large enough, the exploit will not be successful. Figure 1 As shown, in order to improve the applicability of the vulnerability automatic exploitation system, the present invention improves the layout of shellcode in the memory. When the controllable memory block cannot accommodate the shellcode, the shellcode is first divided into n segments according to the size of the controllable memory block symBuf[i] (0≤i≤n), and then the shellcode segments are stored in multiple controllable memory blocks symBuf[i] in sequence, and the jump instructions are used to connect the attack codes distributed in different memory blocks, thereby completing the attack process.

[0070] Code injection with segmented layout exploits constraints This is described as follows. Formula (1) represents the case where max(symBuf[i]) ≥ len(shellcode) (0 ≤ i ≤ n), that is, the method of constructing exploitation data when there is a controllable memory block with sufficient space in the process. Here, MaxsymBuf is the memory block with the largest space among all controllable memory blocks. The specific construction method is as follows: First, constrain the data in the memory MaxsymBuf to the shellcode, so as to write the complete shellcode into the controllable memory. Then, constrain the value of the EIP register in the program state to the address of MaxsymBuf, and transfer the program control flow to the memory where the shellcode is located.

[0071] Φexp(ε) = (MaxSymBuf ← shellcode) ∧ [state(ε).eip ← addr(MaxSymBuf)] (1)

[0072] Formula (1) describes the method of constructing exploitation data when max(symBuf[i]) < len(shellcode), where 0 ≤ i ≤ n, and jmp_ins[i] is the jump instruction between symBuf[i] and symBuf[i + 1]. When the space of the controllable memory block in the process is not enough, write the segmented shellcode[i] and the jump instruction jmp_ins[i] used to implement the control flow transfer between segments into multiple controllable memory blocks symBuf[i] in turn. Finally, make the EIP register of the program point to the first controllable memory block symBuf[0] storing the shellcode to hijack the program control flow to execute the shellcode.

[0073]

[0074] 2) Bypass using trampoline instructions

[0075] To defend against common vulnerability exploitation methods, various vulnerability mitigation mechanisms have been implemented at the levels of modern operating systems and compilers. Although these mechanisms can achieve certain protection effects, there are still corresponding bypass methods. When the address space layout randomization (ASLR) vulnerability mitigation mechanism is enabled in the system, the memory addresses of the stack, shared libraries, and mmap mapping areas in the process space will change every time the program is loaded. Since the distribution of data in the process space cannot be predicted, the exploitation methods introduced in the previous section will no longer apply.

[0076] By analyzing the stack operation of the function call process, we know that when the program returns by executing the ret instruction, the return address will be popped out of the stack frame. After the ret instruction is executed, the ESP register points to the memory unit after the return address in the stack, and the content in ESP will not be modified by the overflow data. Therefore, the shellcode is written to the position after the return address in the stack memory, and then the shellcode in the memory is dynamically located with the help of the "jmpesp" instruction. This exploit method can be abstracted as the exploit constraint expression shown in formula (3): describe.

[0077]

[0078] Where:

[0079] mem[state(ε).esp]——The memory on the top of the stack pointed to by register ESP;

[0080] jmpesp_addr – The address of the “jmpesp” instruction in the program.

[0081] The overflow data can overwrite the stack memory after the return address, so the data in the memory mem[state(ε).esp] is constrained to shellcode, the shellcode is written to the stack memory, and then the value of the EIP register in the program state is constrained to the "jmpesp" instruction address to hijack the program control flow. The control flow transfer process during the vulnerability exploitation process is as follows: Figure 2 As shown in the figure, when the program executes the ret instruction, the control flow is first hijacked to the "jmpesp" instruction, and then the jump instruction is executed to transfer to the top of the stack to execute the shellcode.

[0082] The "jmpesp" instruction used to dynamically locate the shellcode in this method is called a springboard instruction. Table 1 lists the commonly used springboard instructions and their corresponding machine codes.

[0083] Table 1:

[0084] Springboard Instructions Machine code jmp eax / call eax FF E0 / FFD0 jmp ecx / call ecx FF E1 / FFD1 jmp edx / call edx FF E2 / FFD2 jmp ebx / call ebx FF E3 / FFD3 jmp esp / call esp FF E4 / FFD4 jmp ebp / call ebp FF E5 / FFD5 jmp esi / call esi FF E6 / FFD6 jmp edi / calledi FF E7 / FFD7

[0085] For example, "jmp / calleax" is usually applicable to situations where the program calls the strcpy function, such as Figure 3When calling the strcpy(char*dest,char*src) function, the instructions at 0x08048504 and 0x08048507 push the parameter dest into the stack through register EAX. When executing to 0x08048524, register EAX still points to the destination buffer dest. Therefore, the shellcode is written into the source buffer src. After the strcpy function is executed, register EAX will point to the memory where the shellcode is located. By using the buffer overflow vulnerability to hijack the control flow to the springboard instruction, the shellcode can be successfully jumped to execute.

[0086] 3) return-to-libc to bypass NX

[0087] The core idea of ​​code injection attack is to exploit the vulnerability to write the attack code into the target process space, and then hijack the control flow to the attack code in the memory for continued execution. If the program deploys the memory non-executable vulnerability mitigation mechanism NX during the compilation phase, the non-code segment memory area in the process space will be set to non-executable, and the CPU's attempt to fetch instructions from these memories will trigger a memory access violation exception, so the code injection attack will no longer work.

[0088] In order to bypass NX, an attack chain that can complete a specific function can be constructed by connecting existing code fragments in memory through jump instructions, and then hijacking the control flow to the attack chain to execute and complete the exploitation process. This type of exploitation is called code reuse.

[0089] Return-to-libc is a code reuse technique. This exploitation method implements arbitrary code execution by setting appropriate parameters in the stack to call functions in the C language dynamic link library libc. The construction process of its attack chain can be expressed by formula (4).

[0090]

[0091] Among them, system_addr is the memory address of the library function system(), exit_addr is the memory address of the library function exit(), and binsh_addr is the address of the string " / bin / sh" in the memory. The address of the library function to be called and its parameters are obtained by overflowing the data. Figure 4 The data in the memory mem[state(ε).esp] is constrained to the address of the exit() function as the return address after the system() function is called, the data in the memory mem[state(ε).esp+4] is constrained to the address of the string " / bin / sh" as the parameter when the system() function is called, and the value of the EIP register in the program state is constrained to the address of the system() function to hijack the program control flow. Figure 4 As shown in the figure, when the vulnerability is triggered, the program control flow is transferred to the attack chain and the execution of system (" / bin / sh") can return to the system shell. After exiting the shell, the exit() function is called to end the process.

[0092] 2. Automated Exploit Generation

[0093] When automatically constructing vulnerability exploits, it is necessary to combine the security protection mechanism enabled by the program with appropriate means of exploitation to construct exploit conditions, such as Figure 5 As shown. Check the security mechanism enabled by the program through CheckSec: if the program has NX protection enabled, then combine the ROP exploit to construct the ROP exploit; if the program does not have NX protection enabled, check whether the ASLR mechanism is enabled. If the ASLR mechanism is enabled, then combine the ROP exploit to construct the ROP exploit. If ASLR is not enabled, then combine the Shellcode exploit and the ROP exploit to construct the two exploits respectively. The following is a detailed description of the construction process of each vulnerability exploit.

[0094] 1) ShellcodeExploit Generation

[0095] When the binary program does not have a security mechanism enabled, the most basic vulnerability exploit is Shellcode injection. The so-called Shellcode is actually a piece of code (or a piece of filler data) that is sent to the binary program to achieve a specific purpose. Here, in order to verify whether the vulnerability exploit is successful, the purpose achieved by the present invention using the Shellcode code is to open a shell to verify whether the control authority is obtained. One of the necessary conditions for the success of Shellcode injection is that the memory area where the Shellcode code is placed must be a section of memory that can be executed, and the position where the code is placed is fixed and unchanged, and will not change position with each program startup. Therefore, only under the premise that the binary program does not have stack non-executable protection and ASLR protection means enabled, Shellcode injection utilization has the possibility of success. In addition, in the Linux 32-bit system, there is a special situation: when the Linux 32-bit ELF program is loaded into the memory, the image of the program is not affected by the system ASLR protection, and the system defaults to the .BSS segment (a memory area in the ELF file used to store uninitialized global variables and static variables in the program) is executable. If the Shellcode code can be placed in the .BSS segment of the program, the effect of utilization can also be achieved.

[0096] Combined with the above conditions, there are two ways to construct Shellcode injection exploits:

[0097] Method 1: Place the shellcode in a symbolic area controlled by user input;

[0098] Method 2: Write Shellcode to .BSS segment

[0099] For method 1, the conditions required to build the vulnerability exploit are: len(Shellcode)<=size(SymbolicRegion)LoadSymbolicRegion(State)=ShellcodeSymbolic(EIP)=True

[0100] %EIP = ShellcodeAddress

[0101] Among them, condition 1) indicates that the length of the injected Shellcode code should not exceed the size of the selected symbolic memory area, otherwise only part of the Shellcode code can be written into the memory and the final exploitation effect cannot be achieved; condition 2) indicates that the memory of the selected symbolic memory area should be the specific value of the injected Shellcode code; condition 3) indicates that in the current state, the return address EIP must be symbolic, otherwise the program control flow cannot be controlled; condition 4) indicates that the return address EIP needs to point to the memory address where the Shellcode is placed. Shellcode injection exploitation construction method 1 is as follows Figure 6 shown.

[0102] For method 2, the conditions required to build the exploit become slightly more complicated:

[0103] FindReadFunction(Binary)=TrueFindMemInBSS(Binary)=True

[0104] ReadShellcodeInBSS(State)=TrueSymbolic(EIP)=True

[0105] %EIP = ShellcodeAddress

[0106] Condition 1) indicates that it is necessary to find the read or gets function in the program, and use these functions that write to the memory to write the Shellcode code to the .BSS segment; Condition 2) indicates that a memory area that can hold Shellcode is found from the high address position of the program's .BSS segment to the low address direction; Condition 3) indicates that by constructing ROP, the Shellcode is written into the found .BSS memory area that can store Shellcode using the read or get function; Condition 4) indicates that in the symbolic state after the Shellcode is successfully written, the return address EIP is still symbolic; Condition 5) indicates that the return address EIP points to the starting address of the Shellcode in the .BSS segment. Construction method 2 of Shellcode injection utilization is as follows Figure 7 shown.

[0107] 2)ROPExploit Generation

[0108] When the binary program has the stack non-executable protection turned on, it means that the injected Shellcode code cannot be executed, and the exploit cannot be successful. At this time, you can use the existing code fragments in the memory, which are called Gadgets here, to piece together the starting addresses of these Gadgets into a GadgetChain, hijack the control flow of the program, make the program jump between these Gadgets, execute the functions of the Gadgets, and thus piece together a complete and more complex function, which can ignore the stack non-executable protection and achieve the purpose of exploitation. The whole process is as follows: Figure 8 shown.

[0109] According to the source of Gadget, it can be divided into Gadget based on the program itself and Gadget based on dynamic link library. There are two types of Gadget based on the program itself. One is some code fragments used to perform specific operations in the binary program, such as the instruction fragment POPRDI;RET used to pop the stack, and the other is the library function called by the binary program itself, such as system(), read() function, etc. When the system turns on ASLR, the address of this Gadget is the real address in the memory, so it can be directly assembled into GadgetChain for use. Gadget based on dynamic link library refers to finding the required Gadget from the dynamic link library. Since the code content in the dynamic link library is rich, a large number of GadgetChains can be constructed according to the desired purpose of utilization. The purpose of the vulnerability exploitation of the present invention is to open a new Shell, so the function of the constructed GadgetChain is to be able to execute system (π / bin / sh"). The following describes the construction of code reuse using the library function called by the program itself and the construction of executing the system (" / bin / sh") vulnerability exploit using the library function in the dynamic link library according to the different sources of Gadget.

[0110] 3) Code reuse based on the program itself

[0111] In the process of constructing GadgetChain based on the program itself, you first need to find the address value of the system library function called in the binary program. The execution of the system function also requires a parameter, which is the address of the " / bin / sh" string. Since a string like " / bin / sh" may not exist in a binary program, the easiest way is to write " / bin / sh" by yourself and use the written address as a parameter of the system function. Writing data to the memory requires calling functions such as read or gets, so you also need to find the address value of calling library functions such as read or gets in the binary program. Taking the read function as an example, the function prototype of the read function is ssize_tread(intfd,void*buf,size_tcount), which requires three parameters, namely the file descriptor fd, the memory address buf to be written, and the length of the data to be written count. The basic vulnerability exploit Chain constructed is as follows Fig. 9 shown.

[0112] The construction conditions of the GadgetChain based on the program itself are as follows:

[0113] FindSystemFunction(Binary)=TrueFindReadFunction(Binary)=True

[0114] Chain1:read(0,read_to,dataLength)-->ReadState

[0115] Chain2:system(read_to)-->BaseonReadState-->SystemStateSymbolic(SystemState(EIP))=True

[0116] %EIP=AddressChain2

[0117] Among them, conditions (1) and (2) indicate that the system function and the read function can be found in the binary program; condition (3) indicates that the read function is used to construct a GadgetChain to write the " / bin / sh" string into the symbolic memory area pointed to by read_to. The first parameter 0 indicates that the input data is obtained from the standard input, and the constructed GadgetChain is placed in the symbolic memory, and relevant constraints are added to obtain a new symbolic state ReadState; condition (4) indicates that on the basis of the new symbolic state ReadState, a GadgetChain of system (" / bin / sh") is constructed, and a symbolic memory area where the Chain can be placed is found, and corresponding constraints are added to obtain a new symbolic state SystemState; condition (5) indicates that the EIP of the new symbolic state SystemState must be symbolic, so that the control flow of the program can be controlled; condition (6) indicates that the EIP of SystemState points to the address where the constructed systemChain is placed.

[0118] When placing the constructed GadgetChain in the symbolic memory, it is necessary to select the existing symbolic memory area. Only the symbolic areas that meet the conditions can be used to place the Chain. Fig.10The following are several cases, that is, the symbolized area controlled by the user input is located above the current ESP or the symbolized area is located below the current ESP. When the symbolized area is above the current ESP, after the instruction at the return address is executed, the stack frame is popped out of the stack, and the Chain placed in the symbolized memory area will not be executed. Therefore, the symbolized memory area that meets this situation cannot be used to place the Chain and should be discarded. When the symbolized memory area is below the current ESP, after the instruction at the return address is executed, the program will take the data at the current ESP as an instruction to execute, and will not execute the GadgetChain placed in the symbolized memory area. Therefore, it is necessary to adjust the position pointed to by ESP here. Because ESP points to the top position of the current stack memory, as long as the data at the top of the stack is popped out of the stack, ESP will naturally point to the next stack memory position, so you can consider using an instruction fragment that can change the data distribution on the stack to adjust the position of ESP.

[0119] After finding a suitable instruction fragment to make the program control flow jump to the symbolic memory area, the Chain consisting of the address of the read function and the corresponding parameters is placed at the jump location, such as Fig.11 As shown, add corresponding constraints to the above process:

[0120] (1)%EIP=address(Stack_pivotGadget)

[0121] (2)Jump_to_addrisinSymbolicRegion

[0122] (3)Size(SimbolicRegionforChain)>=Size(Chain)

[0123] (4)LoadSymbolicMemory(Jumptoaddr)=Chain

[0124] Among them, condition (1) indicates that the EIP register points to the Gadget address; condition (2) indicates that the address Jump_to_addr jumped to by using Gadget is located in the symbolic memory segment; condition (3) indicates that the size of the symbolic memory segment is large enough to place the constructed Chain content; condition (4) indicates that the symbolic memory content after the jump address Jump_to_addr is the constructed Chain.

[0125] After constructing the Chain of the read function, add the corresponding constraints to get a new state ReadState. Based on the ReadState state, continue the second Chain construction to execute the system call. The Chain construction process of the system function is similar to that of the read function, so it will not be repeated. The system function address, read function address, and Gadget address used here can all be found in the program, and their addresses are all actual addresses in the memory, so they can bypass the system's ASLR protection.

[0126] 4) Code reuse based on dynamic link library

[0127] It is not common to call the system function in binary programs. Most programs do not call the system function. In this case, you can find the required Gadget address from the dynamic link library and construct a GadgetChain based on the dynamic link library.

[0128] When a Linux ELF program is executed, the dynamic link library it uses is dynamically loaded into a certain address segment in the memory. If the system has ASLR turned on, the address segment it is loaded at will change, otherwise it will remain fixed. The actual address of the function in the dynamic link library in the memory will change as the address at which the dynamic link library is loaded, but the relative offset of the library function relative to the starting position of the dynamic link library remains fixed. If you know the actual address of one of the library functions in the memory, you can calculate the loading base address of the dynamic link library based on the offset of the library function in the dynamic link library. After knowing the loading base address of the dynamic link library, you can calculate the actual address of any library function in the memory as long as you know the offset of any function in the dynamic link library in the library. For example Fig.12 As shown, the dynamic link library is loaded into a certain location in the memory. When the actual address addr of the library function function1 is known, the base address LibBaseAddr=addr1-offset1 of the dynamic link library loading can be calculated. If you want to use the library function function2, you can calculate the actual address addr2=LibBaseAddr+offset2 of function2 in the memory.

[0129] When the program is run and loaded into memory, the actual address of the library function called in the program in memory will be saved in the GOT table entry of the program. Here, by leaking the actual address of a certain library function saved in the .GOT table entry, the required system function address is indirectly calculated using the above method, which is used to construct system(' / bin / sh') to open the shell. Therefore, this method needs to construct Chain twice, once to leak the actual address of the function in the .GOT table entry of the program, and once to construct the system(' / bin / sh') call.

[0130] To leak data, you need to use a function that outputs information. Here, we take the write function as an example. The prototype of the write function is ssize_twrite(intfd,constvoid*buf,size_tcount), which requires three parameters, namely the file descriptor fd, the memory address buf of the output data, and the output data length count. The layout of the constructed Chain in the stack is as follows: Fig.13 shown.

[0131] The Chain construction conditions of the leaked .GOT entry are as follows:

[0132] (1)FindWriteFunction(Binary)=True

[0133] (2)Symbolic(EIP)=True

[0134] (3)LoadSymbolicMemory(EIP)=address(write)+0xdeadbeef+0x1+function@got+0x4

[0135] Condition (1) indicates that the write function is called in the program; condition (2) indicates that the current EIP must be symbolic data; condition (3) indicates that the symbolic memory data starting from EIP is a chain consisting of the write address + 0xdeadbeef + 0x1 + the .GOT table entry of a function in the program + 0x4.

[0136] After the first Chain construction, the actual address of the leaked library function in memory can be obtained from the standard output. The actual address of the system function in memory can be indirectly calculated using the result combined with the offset of the library function in the dynamic link library, and the second Chain construction can be performed. To call system(' / bin / sh'), you also need to know the address of the ' / bin / sh' string. Here, you can also use the leaked function address and the offset of the ' / bin / sh' string in the dynamic link library to calculate the actual address of the ' / bin / sh' string in memory. The layout of the constructed Chain in the stack is as follows: Fig.14 shown.

[0137] The construction conditions for Chainsystem to call Chain are as follows:

[0138] (1)Symbolic(EIP)=True

[0139] (2)

[0140] Condition (1) indicates that the EIP representing the current state must be symbolic data; condition (2) indicates that the symbolic memory data starting from EIP is the calculated address of the system function + 'deadbeef' + the calculated address of the ' / bin / sh' string.

[0141] The leaked function addresses and calculated function addresses here are their actual addresses in memory. Even if the system has ASLR protection enabled, these addresses are the actual addresses in memory when the program is executed for the first time. They are real and valid, so they can bypass the system's ASLR protection.

[0142] 3. Automated Vulnerability Exploitation Verification Module Implementation

[0143] The vulnerability exploitation module integrates the above methods to realize the automatic exploitation of vulnerabilities. The key processes include: symbolic recovery of crash state, vulnerability analysis, selection of multiple exploitation methods, and construction and solution of exploitation constraints.

[0144] 1) Symbolic recovery of crash state

[0145] The symbolic recovery process of the crash state is as follows Fig.15As shown. It accepts crash input crash_input, crash path information list crash_trace[] and binary program binary as input, and finally returns the symbolic crash state crash_state. First, use the symbolic execution tool to perform initial symbolization on the binary program, symbolize the program input as ' / dev / stdin', and build pre-constraints for the accepted crash input crash_input to obtain the initial symbolic state init_state. Using the initial symbolic state init_state, perform symbolic exploration to make the symbolic state reach the first basic block address in the crash path information list, that is, the location of the program entry point. The state at this time is recorded as trace_state, and the formal symbolic path execution begins. When a basic block is executed forward in the symbolic state, the address of the subsequent basic block is compared with the address in the crash path information. Combined with the difference between the basic blocks of the virtualized execution record and the basic blocks of the symbolic execution record, it is determined whether the symbolic execution path matches the crash path, until the crash state crash_state is finally obtained.

[0146] During the symbolic execution process, after each basic block is executed forward, the subsequent basic block may have branches, that is, multiple paths appear. At this time, the next basic block address of the current basic block executed in the crash path information or the pre-constraint conditions added in the symbolic state can be used to select the path. The whole process is as follows: Fig.16 shown.

[0147] After obtaining the symbolic crash state, the symbolic information in the symbolic state needs to be filtered. Users affect program execution through program input, thereby triggering vulnerabilities in the program. Therefore, the symbolic memory area affected by the standard input stdin is filtered out, that is, the symbolic data in the memory contains the symbolic identifier of 'stdin'. The filtered single symbolic memory addresses are sorted and merged into some continuous symbolic memory fragments to prepare for the subsequent vulnerability exploitation condition construction.

[0148] 2) Vulnerability Analysis

[0149] Check the register information in the symbolic crash state crash_state and the related symbolic information in the memory read and write records, and analyze the potential vulnerabilities in the crash state. Check the symbolic status of the register EIP in the symbolic crash state crash_state. If the register EIP is symbolic, and the number of bits of the symbolic data is the same as the number of bits of the program architecture, it means that the EIP register can be completely controlled by the user input. It can be determined that this is a stack overflow vulnerability that overwrites the return address. Check the related symbolic information in the historical read and write operations of the symbolic crash state crash_state. If the object of the read and write operation is the memory mem, and the address of the operated memory mem object is symbolic, then it means that there is a vulnerability that can read and write related data to any memory address; when the operation type is a write operation, if the written data is also symbolic, then it means that there is a vulnerability that can write arbitrary data to any address. The specific process is as follows. Fig.17 and Fig.18 As shown, Fig.17 Analysis process for stack overflow overwriting return address, Fig.18 Memory read and write vulnerability analysis process

[0150] 3) Shellcode injection and exploitation

[0151] Shellcode injection and utilization process Fig.19 As shown in the figure. The whole process accepts the crash state crash_state, the filtered symbolic memory segments and the injected Shellcode as input, and outputs the vulnerability exploit file exploit. The symbolic memory segments whose size exceeds the Shellcode code length are selected from the filtered symbolic memory segments to place the Shellcode, and then the corresponding constraints are added. If the added constraints can be solved in crash_state, the vulnerability exploit file exploit is generated.

[0152] 4) Code reuse based on the program itself

[0153] When exploiting the reuse of the program's own code fragment, because the system function is needed to open the shell, the address of the system function needs to be found in the program. The address of the parameter ' / bin / sh' string is required to call the system function. Since such a string may not exist in the program, the read function or gets function is directly used to write the ' / bin / sh' string into the .BSS segment of the program. The reason for writing ' / bin / sh' into the .BSS segment is that the .BSS segment of the ELF program in the Linux 32-bit system is a default readable and writable memory segment, and the .BSS segment is located in the address space where the program is loaded and will not be affected by the system ASLR mechanism. The entire exploitation process requires two GadgetChains, one for writing ' / bin / sh' into the .BSS segment of the program, and the other for constructing the system call. First, it is necessary to construct a GadgetChain that writes the ' / bin / sh' string. If the constructed constraints can be solved, the constructed constraints are added to the crash state crash_state to obtain a new state in which the ' / bin / sh' string already exists and the address of the string is known. Based on the new state, the GadgetChain called by system is constructed. If the constructed constraint conditions can be solved, the constructed constraint conditions are added to the current state, and finally the vulnerability exploit file is solved. The whole process is as follows: Fig. 20 shown.

[0154] 5) Code reuse based on dynamic link library

[0155] When the system function does not exist in the program, the vulnerability is constructed using the system function in the libc loaded into the memory. In order to obtain the address of the system function in the libc loaded into the memory, it is necessary to leak the function address in the .GOT table in the program, use its relative offset in libc to calculate the loading base address of libc in the memory, and then use the relative offset of the system function in libc to calculate the actual address of the system function in the memory. Here, the Chain needs to be constructed twice, once for leaking the function address in the .GOT table of the program, and once for calling the system function. The code reuse process based on the dynamic link library is as follows: Fig.21 shown.

Claims

1. An automated vulnerability exploit construction method based on symbolic solution, characterized in that: It includes the following steps: Step 1: Generation method using constraint solving; Specifically analyze the three vulnerability exploitation methods of code injection, using springboard to bypass ASLR, and return-to-libc to bypass NX, and construct corresponding exploit constraint expressions respectively Automating the data construction process; Step 2: Automated vulnerability exploit generation; Check the security mechanisms enabled by the CheckSec program: If the NX protection is enabled for the program, then combine the ROP exploitation means to construct the ROP exploitation; If the NX protection is not enabled for the program, then check whether the ASLR mechanism is enabled. If the ASLR mechanism is enabled, then combine the ROP exploitation means to construct the ROP exploitation. If the ASLR is not enabled, then the Shellcode exploitation means and the ROP exploitation means can be combined to construct the two exploitations respectively.

2. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: In the said Step 1, the code injection exploitation writes the attack code shellcode into the process memory through the buffer overflow vulnerability and hijacks the program control flow to the memory where the shellcode is located. When the controllable memory block cannot accommodate the shellcode, first divide the shellcode into n segments according to the size of the controllable memory block symBuf[i], 0 ≤ i ≤ n. Then, store the shellcode segments in multiple controllable memory blocks symBuf[i] in sequence, and use jump instructions to connect the attack codes distributed in different memory blocks, thus completing the attack process; Code injection exploit constraints for segment layout Describe; Formula (1) represents the case of max(symBuf[i])≥len(shellcode), 0≤i≤n, that is, the use of data construction method when there is a controllable memory block with sufficient space in the process, where MaxsymBuf is the largest memory block in all controllable memory blocks; The specific construction method is: first constrain the data in the memory MaxsymBuf to be shellcode, so that the complete shellcode is written into the controllable memory, and then constrain the value of the EIP register in the program state to be the address of MaxsymBuf, and transfer the program control flow to the memory where the shellcode is located; Φexp(ε) = (MaxSymBuf ← shellcode) ∧ [state(ε).eip ← addr(MaxSymBuf)](1) Formula (1) describes the exploitation data construction method when max(symBuf[i]) < len(shellcode), where 0 ≤ i ≤ n, and jmp_ins[i] is the jump instruction between symBuf[i] and symBuf[i + 1]; When the space of the controllable memory block in the process is insufficient, write the segmented shellcode[i] and the jump instruction jmp_ins[i] for realizing the control flow transfer between the segments into multiple controllable memory blocks symBuf[i] in sequence. Finally, make the EIP register of the program point to the first controllable memory block symBuf[0] storing the shellcode to hijack the program control flow to execute the shellcode; 3. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: In the step 1, the stack operation of the function call process in the use of the springboard to bypass ASLR is analyzed. It can be seen that when the program executes the ret instruction to return, the return address will be popped out of the stack frame. After the ret instruction is executed, the ESP register points to the memory unit after the return address in the stack, and the content in ESP will not be modified by the overflow data; the shellcode is written to the position after the return address in the stack memory, and then the shellcode in the memory is dynamically located with the help of the "jmpesp" instruction, which can be abstracted as the exploit constraint expression shown in formula (3): describe; In the formula: mem[state(ε).esp] - the stack top memory pointed to by the register ESP; jmpesp_addr - the address of the "jmpesp" instruction in the program; The stack memory after the return address can be overwritten by the overflow data. Therefore, constrain the data in the memory mem[state(ε).esp] to be the shellcode, write the shellcode into the stack memory, and then constrain the value of the EIP register in the program state to be the address of the "jmpesp" instruction to hijack the program control flow; When the program executes the ret instruction, the control flow is first hijacked to the "jmpesp" instruction, and then the jump instruction is executed to transfer to the stack top to execute the shellcode.

4. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: In step 1, return-to-libc bypasses NX and connects the existing code fragments in the memory through jump instructions to construct an attack chain that can complete a specific function, and then hijacks the control flow to the attack chain to execute and complete the exploitation process; return-to-libc calls the function in the C language dynamic link library libc by setting appropriate parameters in the stack to implement arbitrary code execution. The construction process of its attack chain can be expressed by formula (4); Among them, system_addr is the memory address of the library function system(), exit_addr is the memory address of the library function exit(), and binsh_addr is the address of the string " / bin / sh" in the memory; the address of the library function to be called and its parameters are arranged in the memory through overflow data, the data in the memory mem[state(ε).esp] is constrained to the address of the exit() function as the return address after the system() function is called, the data in the memory mem[state(ε).esp+4] is constrained to the address of the string " / bin / sh" as the parameter when the system() function is called, and the value of the EIP register in the program state is constrained to the address of the system() function to hijack the program control flow; when the vulnerability is triggered, the program control flow is transferred to the attack chain to execute system(" / bin / sh") to return to the system shell, and the exit() function is called after exiting the shell to end the process.

5. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: There are two ways to construct the Shellcode injection exploit in step 2: Method 1: Place the shellcode in a symbolic area controlled by user input; Method 2: Write Shellcode to .BSS segment For method 1, the conditions required to build the vulnerability exploit are: len(Shellcode)<=size(SymbolicRegion)LoadSymbolicRegion(State)=ShellcodeSymbolic(EIP)=True %EIP = ShellcodeAddress Among them, condition 1) indicates that the length of the injected Shellcode code should not exceed the size of the selected symbolic memory area, otherwise only part of the Shellcode code can be written into the memory and the final exploitation effect cannot be achieved; condition 2) indicates that the memory of the selected symbolic memory area should be the specific value of the injected Shellcode code; condition 3) indicates that in the current state, the return address EIP must be symbolic, otherwise the program control flow cannot be controlled; condition 4) indicates that the return address EIP needs to point to the memory address where the Shellcode is placed; For method 2, the conditions required to build the vulnerability exploit are: FindReadFunction(Binary)=TrueFindMemInBSS(Binary)=True ReadShellcodeInBSS(State)=TrueSymbolic(EIP)=True %EIP = ShellcodeAddress Among them, condition 1.) means that it is necessary to find the read or gets function in the program, and use these functions that write to the memory to write the Shellcode code to the .BSS segment; condition 2.) means starting from the high address position of the program .BSS segment and moving towards the low address, a memory area that can accommodate the Shellcode is found; condition 3.) means that by constructing ROP, the Shellcode is written into the found .BSS memory area that can store the Shellcode using the read or get function; condition 4.) means that in the symbolic state after the Shellcode is successfully written, the return address EIP is still symbolic; condition 5.) means that the return address EIP points to the starting address of the Shellcode in the .BSS segment.

6. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: In step 2, ROPExploit is generated specifically as follows: when the binary program turns on the stack non-executable protection, it means that the injected Shellcode code cannot be executed, and the exploit cannot be successful; using the existing code fragments Gadget in the memory, the starting addresses of these Gadgets are pieced together into a GadgetChain, hijacking the control flow of the program, making the program jump between these Gadgets, executing the functions possessed by the Gadgets, and thus piecing together a complete and more complex function, which can ignore the stack non-executable protection and achieve the purpose of exploitation.

7. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: In the process of constructing GadgetChain based on the program itself in step 2, it is first necessary to find the address value of the system library function called in the binary program; the execution of the system function also requires a parameter, that is, the address of the " / bin / sh" string; since the string " / bin / sh" may not exist in the binary program, the easiest way is to write " / bin / sh" by yourself and use the written address as the parameter of the system function; writing data to the memory requires calling functions such as read or gets, so it is also necessary to find the address value of calling library functions such as read or gets in the binary program.

8. The method for constructing an automated vulnerability exploit based on symbolic solution according to claim 1, characterized in that: In the step 2, the required Gadget address is found from the dynamic link library, and a GadgetChain based on the dynamic link library is constructed; when the Linux ELF program is executed, the dynamic link library used by it is dynamically loaded into a certain address segment in the memory. If the system turns on ASLR, the address segment it loads is variable, otherwise it is fixed; the actual address of the function in the dynamic link library in the memory will change with the address of the dynamic link library loading, but the relative offset of the library function relative to the starting position of the dynamic link library is fixed and unchanged; if the actual address of one of the library functions in the memory is known, then the loading base address of the dynamic link library is calculated according to the offset of the library function in the dynamic link library; after knowing the loading base address of the dynamic link library, as long as the offset of any function in the dynamic link library in the library is known, it can be calculated To the actual address of any library function in memory; the dynamic link library is loaded into a certain position in the memory, and when the actual address addr of the library function function1 is known, the base address LibBaseAddr=addr1-offset1 of the dynamic link library loading is calculated. If you want to use the library function function2, calculate the actual address addr2=LibBaseAddr+offset2 of function2 in memory; when the program is run and loaded into the memory, the actual address of the library function called in the program in the memory will be saved in the GOT table entry of the program; here, by leaking the actual address of a library function saved in the .GOT table entry, the required system function address is indirectly calculated using the above method, which is used to construct system(' / bin / sh') to open the shell.

Images