Code reuse attack defense method based on real-time loading of gadget quality

Abstract

The present invention relates to the field of system security software vulnerability defense, and discloses a code reuse attack defense method based on real-time loading of gadget quality, comprising the following steps: obtaining a program code segment in a preprocessing stage, and performing static analysis on the instructions of all functions in the code segment to obtain the total number of gadgets in the entire program; evaluating the danger level of the obtained gadgets; initializing the thread pool, the standby area and the execution area, and storing gadget information in the initialization stage; monitoring the parent process in the real-time loading and unloading stage, and running the executable program by the child process; loading when 0xCC is found, and unloading when the parent process monitors the total number of gadgets in the execution area or the total danger level score of gadgets in the execution area exceeds a set threshold. The method disclosed by the present invention can load and unload in a more fine-grained manner, greatly reducing the attack surface and danger level.

Description

Technical Field

[0001] The present invention relates to the field of system security software vulnerability defense, and in particular to a code reuse attack defense method based on real-time loading of gadget quality. Background Art

[0002] In today's digital age, computer system security has become one of the focuses of widespread attention. In the field of computer system security, a common attack is code reuse attack. Compared with traditional injection attacks, code reuse attacks do not require code injection, but directly use existing assembly instruction fragments (called gadgets) at the vulnerability point. By executing multiple gadget fragments, called gadget chains, the return address of the program is modified, and the control flow of the program is changed, system permissions are obtained, and the purpose of malicious attacks is achieved.

[0003] As can be seen, to implement the attack, the following conditions need to be met: (1) there is a vulnerability exploit; (2) the attacker knows the exact memory addresses of multiple exploitable code snippets; (3) multiple exploitable code snippets are in memory at the same time; (4) the control flow is changed.

[0004] Therefore, the existing defense schemes also defend by destroying the above conditions. At present, the defense mechanism of code reuse attacks has been deeply studied at home and abroad, mainly divided into the following methods: randomization, threshold monitoring, control flow integrity, and software de-expansion. After years of development, software de-expansion methods have gradually become active. It is based on the destruction condition (3) for defense. There are two types of software de-expansion. One is code-level de-expansion, which reduces the code exposure by deleting unnecessary code; the other is memory-level de-expansion, which ensures that only a part of the code is exposed in the memory. Code-level de-expansion requires source code, but some software does not provide source code. In addition, if too much code is deleted, necessary code may be deleted. If too little code is deleted, the defense effect is reduced. Therefore, memory-level de-expansion has developed. This type of method focuses on the amount of real-time memory code. By loading and unloading code into memory in real time, the amount of code in memory is low. Attackers cannot ensure that multiple exploitable code fragments are in memory at the same time, so they cannot construct gadget chains, achieving a defense effect.

[0005] However, the existing real-time loading and unloading methods are based on functions as the granularity. Different programs need to design the upper limit threshold of the number of functions in different categories. At the same time, if the number of program functions is small and the sizes of various functions are unevenly distributed, it may happen that almost the entire code segment exists in the memory, and the attack surface is not reduced. Summary of the invention

[0006] In order to solve the above technical problems, the present invention provides a code reuse attack defense method based on real-time loading of gadget quality, so as to achieve more fine-grained loading and unloading, thereby greatly reducing the attack surface and the degree of danger.

[0007] To achieve the above object, the technical solution of the present invention is as follows:

[0008] A code reuse attack defense method based on real-time loading of gadget quality includes the following steps:

[0009] Step 1, preprocessing stage:

[0010] Get the program code segment, and perform static analysis on the instructions of all functions in the code segment, define every n instructions as a gadget, and get the total number of gadgets in the entire program; evaluate the danger level of the obtained gadgets, determine the danger level score of each gadget, and store it in a file;

[0011] Step 2, initialization phase:

[0012] Thread pool initialization: create thread task types and task queues, and at the same time, create multiple threads;

[0013] Initialize the spare area and execution area: copy all program code segments to the spare area and clear the execution area. Clearing means changing all code segments in the execution area to 0xCC. At the same time, set the spare area to read-only permission, and the execution area to read and execute.

[0014] Gadget information storage: The address and size of the gadget in the file obtained in the preprocessing stage are stored in the hash table;

[0015] Step 3, real-time loading and unloading phase:

[0016] Monitoring is implemented by creating a parent-child process, where the parent process performs monitoring and the child process runs the executable program;

[0017] When the child process attempts to execute the code snippet, it finds 0xCC instead of a program instruction. At this time, the parent process captures the corresponding signal and needs to load it. The loading task is distributed to the thread pool, which allows the thread to find the corresponding size through the address and the hash table. All instructions corresponding to the gadget are found in the spare area and loaded into the execution area. The child process continues to execute after the instructions are loaded back.

[0018] When the parent process monitors that the total number of gadgets in the execution area exceeds the set threshold or the total risk score of gadgets in the execution area exceeds the set threshold, it needs to be uninstalled and the existing code fragment in the execution area is directly modified to 0xCC to make the part unexecutable.

[0019] In the above scheme, in step 1, every 5 instructions are customized as a gadget, and when the end of the function is reached, the remaining instructions are set as a gadget.

[0020] In the above scheme, in step 1, the target addresses of all call and jmp instructions are first obtained and stored in a list structure called target. Then, when obtaining the gadget, it is truncated at the call and jmp.

[0021] In the above scheme, in step 2, the degree of danger is divided into 4 levels, 1 represents the lowest degree of danger and 4 represents the most dangerous; the specific division principles are as follows:

[0022] The danger level score of instructions with pop reg form or containing popa and popal is 4;

[0023] The danger level score of the instructions including ret, call, and jmp is 3;

[0024] The danger level score for instructions involving rip, rsp, rbp, eip, esp, and ebp is 3;

[0025] The danger level score of using privileged instructions is 3;

[0026] The danger level score of the memory reference instruction is 2;

[0027] The remaining instructions have a danger level score of 1.

[0028] In the above scheme, in step 3, the child process is a multi-threaded program, and the parent process is also monitored in real time through multi-threading. The parent and child processes allow the child process to execute on a fixed piece of memory through shared memory.

[0029] In the above scheme, in step 3, in order to allow the child process to execute on a fixed piece of memory, it is necessary to first obtain the child process parameters, environment variables, and child process entry point information; the program parameters and environment variables can be obtained through the process initialization stack. In order to simulate execution, a new stack needs to be defined. The customized new stack is a user-mode stack; the child process entry point information can be directly obtained through the ELF header.

[0030] In the above scheme, in step 3, when the child process runs the executable program, the child process needs to jump to the execution area, so the current context is saved first, including various general registers, and then jumps to the child process entry point of the execution area; this part is implemented through a small piece of assembly code, which stores various general register information through the push reg method, and then jumps to the child process entry point through the jmp method, and then restores the general register information through the pop instruction.

[0031] In the above scheme, in step 3, when unloading, the LRU batch unloading strategy is adopted.

[0032] In the above scheme, in step 3, when uninstalling, the LRU algorithm is used to uninstall multiple gadgets that have not been used for the longest time.

[0033] Through the above technical solution, the code reuse attack defense method based on real-time loading of gadget quality provided by the present invention has the following beneficial effects:

[0034] 1) Load and unload at a finer granularity to ensure that the set threshold is consistent with the actual running result, and the number of codes in memory will not exceed the expected threshold;

[0035] 2) It not only focuses on reducing the attack surface, but also on the quality of gadgets. It is scalable. If a new type of attack appears, it only needs to assess the danger level of the corresponding gadget based on the characteristics of that type.

[0036] 3) Use multithreading, hash tables, and LRU optimization to make full use of the characteristics of various programs and consider program locality, avoid frequent loading and unloading, and reduce the overhead caused by fine-grainedness;

[0037] 4) Users can customize the number of gadget instructions, gadget quantity threshold, and gadget risk score threshold, allowing users to choose between ensuring security and operating efficiency according to their needs;

[0038] 5) In terms of defense effect, by testing customized ROP attacks, CVE-2016-10190, CVE-2017-13089, etc., it can effectively defend against attacks;

[0039] 6) In terms of performance, through testing with perlbench, gcc, bwaves, mcf and other programs in SPEC CPU 2017, when reasonable gadget instruction numbers, gadget quantity thresholds, and gadget risk score thresholds are set, the average overhead is only a few percent, but the attack surface and risk level are greatly reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art are briefly introduced below.

[0041] Figure 1 A flowchart of a code reuse attack defense method based on real-time loading of gadget quality disclosed in an embodiment of the present invention;

[0042] Figure 2 It is the memory image when the program is running. DETAILED DESCRIPTION

[0043] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0044] The present invention provides a code reuse attack defense method based on real-time loading of gadget quality, which realizes loading and unloading with finer granularity, pays attention to the quantity and quality of code fragments, reduces the attack surface and the degree of danger in a controllable manner, and uses thread pool and LRU batch unloading strategy for optimization, reduces the overhead caused by fine granularity, thereby ensuring the security of the program without excessive overhead.

[0045] This method is implemented on the Linux operating system, and the implementation environment is Ubuntu 20.04.05. Figure 1 This is the framework diagram of this method. This method is divided into three stages, namely the preprocessing stage, the initialization stage, and the real-time loading and unloading stage. The following will explain each stage of this scheme in detail.

[0046] Step 1, preprocessing stage:

[0047] Get the program code segment, and perform static analysis on the instructions of all functions in the code segment, customize every n instructions as a gadget, and get the total number of gadgets in the entire program; evaluate the danger level of the obtained gadgets, determine the danger level score of each gadget, and store it in a file.

[0048] (1) Obtaining gadget information

[0049] In the process of obtaining gadget information, the executable file of the program is first statically analyzed. In this embodiment, the IDA (Interactive Disassembler) tool is used for analysis, and the Python script is used to obtain the required instructions. IDA is a powerful reverse engineering tool, mainly used for software analysis, especially for binary code analysis. It can convert machine language code into easier-to-understand assembly language code, and provide an interactive environment for users to explore the internal structure and logic of the program in depth. Through IDA, all assembly instructions of the executable file can be obtained, and the .text segment, that is, the code segment content, can be obtained using the functions provided by IDAPython.

[0050] Here, we set n instructions as a gadget, n can be defined by the user, and 5 is selected by default.

[0051] Although every n instructions is a gadget, function boundaries still need to be considered, because program execution is performed by function, and it may jump from function A to function B. Therefore, even if there are not n instructions, if the end of the function is reached, it must be set as a gadget. For example, function A has 98 instructions, and there are no instructions involving function jumps. Here n is 5, so every 5 instructions in the front are a gadget, but the last gadget contains only 3 instructions because the function boundary has been reached.

[0052] In addition, due to the finer granularity, it is necessary to consider whether the jump target of instructions such as call and jmp is the beginning of the gadget, otherwise the corresponding gadget cannot be found during subsequent loading. In this step, the target addresses of all calls and jmps will be obtained first and stored in a list structure called target. Then, when obtaining the gadget, it will be truncated at the call and jmp. For example, if n is set to 5, after function B processes many 5 instructions, the first two of the new 5 instructions encountered are ordinary instructions, and the third is a jmp instruction. At this time, the gadget is only these 3 instructions, because the next instructions will not be executed later, but the instructions at the target address after jmp. During the processing, it is found that the starting address is in the list structure, and it is necessary to set it as the starting address. For example, function C sets n to 5. Among the 5 instructions processed, the address of the 5th is in the list, then the first 4 are a gadget, and the 5th and subsequent instructions are a gadget.

[0053] IDAPython provides many functions, such as get_func to get function size and address information, print_insn_mnem to get assembly instruction mnemonics (such as mov, jmp, etc.), next_head to get the starting address of the next instruction, etc. These functions can easily get instruction information, and then set a gadget for every n instructions and store them in the gadget list.

[0054] (2) Evaluating gadget quality

[0055] The second part requires the evaluation of the obtained gadgets. Here, the danger level is divided into 4 levels, 1 for the lowest danger level and 4 for the most dangerous. According to the principles, the following principles are proposed by comprehensively considering various attack characteristics, availability, whether the system structure is changed, and whether privileged instructions are called:

[0056] The danger level score of instructions with pop reg form or containing popa and popal is 4;

[0057] The danger level score of the instructions including ret, call, and jmp is 3;

[0058] The danger level score for instructions involving rip, rsp, rbp, eip, esp, and ebp is 3;

[0059] The danger level score of using privileged instructions is 3;

[0060] The danger level score of the memory reference instruction is 2;

[0061] The remaining instructions have a danger level score of 1.

[0062] Let’s look at each principle one by one.

[0063] The first one focuses on instructions of the form of pop reg. This type of instruction can directly pop the contents on the stack into the corresponding register to modify the contents. This type of instruction is easy to use, so it is judged as a high-risk instruction. The popa and popal instructions are instructions that may be used in Tiny-CRA. They will put 8 data on the stack into the general registers of di, si, bp, sp, bx, dx, cx, ax and edi, esi, ebp, esp, ebx, edx, ecx, and eax at one time, thereby quickly changing the contents of the registers, so they are also judged as high-risk instructions.

[0064] The second one, including ret, call, jmp family instructions, has a danger level of 3, because the three types of attacks, ROP, COP, and JOP, will use these instructions to change the return address or jump address, thereby changing the control flow, but the ease of use is lower than that of the first type of instructions. There are many cases in the jmp series, including jmp, jz, jnz, je, jne, ja, jb, jg, jl, jp, jnp, jo, jno, js, and jns. These instructions have some differences, but they all jump, so they all need to be taken into account.

[0065] The third item, the hazard level of rip, rsp, rbp, eip, esp, and ebp instructions is 3, including instructions containing these registers and leave instructions. Rip stores the return address, rsp is the top address of the system stack when the function is called, and rbp is the bottom address of the stack. These registers affect the control flow, so the hazard level is 3.

[0066] Article 4. The danger level of using privileged instructions is 3, including syscall, int 0x80, cli, sti, lgdt, lidt, etc. These instructions have higher permissions. For example, syscall will make a system call and enter the kernel layer, so more attention should be paid. However, this type of instruction is not as easy to use as the first type, so the danger level is assessed as 3.

[0067] Article 5. The danger level of instructions with memory references is 2. Instructions with memory references can change memory, but such instructions are difficult to use, so the danger level is 2, and the characteristics are [].

[0068] Excluding the above instructions, the remaining instructions evaluate to 1, i.e. not dangerous.

[0069] Combining the above rules and the fact that each n instructions obtained above is a gadget, the danger level of each gadget can be evaluated, and information such as the gadget starting address, size, danger level, total number of gadgets, and total score of gadget danger levels can be saved and accessed to a file.

[0070] Since the above operation is a static analysis of the executable file, it is not related to the program running. If the binary does not change, it can be used permanently after analysis once. Therefore, the time of the above operation will not affect the subsequent program execution.

[0071] Step 2, initialization phase:

[0072] Thread pool initialization: create thread task types and task queues, and at the same time, create multiple threads.

[0073] Initialization of the spare area and execution area: The spare area is the memory for storing program code segments, while the execution area is where subsequent programs are executed. Before monitoring, first copy all program code segments to the spare area and clear the execution area. Clearing means changing all code segments in the execution area to 0xCC; at the same time, set the spare area to read-only permission, and the execution area to be readable and executable; changing all execution areas to 0xCC is to enable subsequent programs to trigger interrupts when they attempt to execute, and the monitoring program captures the interrupt, thereby achieving loading and unloading.

[0074] Gadget information storage: The address and size of the gadget in the file obtained in the preprocessing stage are stored in the hash table.

[0075] Step 3, real-time loading and unloading phase:

[0076] At this stage, the expected effect is as follows: if the program has x parts, such as A, B, C, etc., first put all x parts into the spare area, and the execution area is empty. When it is expected to execute A, load the A part code from the spare area to the execution area to ensure that only the A part is visible to the attacker. When B is executed later, the A part is unloaded to ensure that only the B part is visible to the attacker.

[0077] Although the spare area has all the code segments of the program, the program cannot be executed in the spare area, and the attacker may not know the existence of the spare area, thus ensuring security.

[0078] Therefore, a program is needed that can load the code from the backup area to the execution area, and can also monitor the total number of gadgets and the total danger value in the memory, so as to start unloading the executed code when the threshold is reached. The above program is the monitoring program, and the above operation is real-time loading and unloading. To achieve real-time loading and unloading, it is necessary to use the information of the gadget address, size, and danger value obtained in the first step to find the corresponding gadget to load or unload, and calculate the total number of gadgets and the total danger value.

[0079] At this stage, the following two functions need to be implemented: (1) the monitoring process loads code from the backup area to the execution area in real time; (2) the monitoring process unloads after detecting that the memory reaches the threshold.

[0080] Here, monitoring is implemented by creating a parent-child process. The parent process performs monitoring and the child process runs the executable program. Considering that the child process is a multi-threaded program, the parent process is also monitored in real time through multi-threading. The parent-child process allows the child process to execute on a fixed piece of memory through shared memory.

[0081] Therefore, in order for the child process to be able to execute on a fixed piece of memory, it is necessary to first obtain the child process parameters, environment variables and other information, as well as the child process entry point information. The program parameters and environment variables can be obtained through the process initialization stack, but this stack is a system-provided stack. Therefore, in order to simulate execution, a new stack needs to be defined here. The customized new stack is a user-mode stack. The child process entry point information can be obtained directly through the ELF header. ELF (Executable and Linkable Format) is a universal standard file format for executable files in the Linux operating system. ELF consists of two parts: header and body. The header stores the child process entry point information.

[0082] Next, the child process needs to jump to the shared memory area, so first save the current context, mainly various general registers, and then jump to the process entry point in the shared memory area. This part is implemented through a small piece of assembly code, which stores various register information through the push reg method, and then jumps to the entry point through the jmp method. The register information can be restored later through the pop instruction.

[0083] The next step is to monitor program execution. When the child process attempts to execute the code snippet, it finds 0xCC instead of the program instruction. At this time, the parent process captures the corresponding signal and needs to load it. The loading task is distributed to the thread pool, allowing the thread to find the corresponding size through the address, find the hash table, find all the instructions of the corresponding gadget in the spare area, load them into the execution area, and then use the PTRACE_CONT type of ptrace to allow the child process to continue executing after the instructions are loaded back; after the subsequent child process executes a part of the instructions, it will encounter the new 0xCC, so the monitoring process can load the instructions as described above.

[0084] The above is the loading part, which needs to be unloaded after reaching the threshold. Unloading is to directly modify the existing code fragment in the execution area to 0xCC, making the part unexecutable. Unloading needs to consider two issues: when to unload and how to unload.

[0085] When to uninstall is mainly considered from two dimensions. One is the total number of gadgets in memory, and the other is the total danger level of gadgets in memory. As long as one of the thresholds is triggered, uninstallation will be performed. In the previous preprocessing stage, the total number of gadgets and the total gadget danger level score of the program have been known, so we can define the expected threshold by ourselves. For example, the expected total number of gadgets is 1 / 16 of the original program, and the total gadget danger level score is 1 / 8 of the total score.

[0086] As for how to unload, the LRU batch unloading strategy is adopted here. Batch unloading can avoid the problem of frequent unloading. If only one instruction fragment is unloaded, the memory will soon reach the threshold again due to subsequent loading, and it needs to be unloaded again. Frequent loading and unloading will increase performance overhead, so batch unloading is used here. At the same time, this solution uses the LRU algorithm.

[0087] The LRU (Least Recently Used) algorithm is a page replacement algorithm for the operating system. In the operating system, LRU will replace the pages that have not been used for the longest time. Here we refer to this algorithm and uninstall multiple gadgets that have not been used for the longest time.

[0088] This method is implemented through a doubly linked list and sets the total number of nodes. When a gadget is accessed, it is placed in the head node, and when it is uninstalled, it is uninstalled from the tail node. Therefore, the head node is the frequently accessed code fragment. The algorithm also uses the principle of locality, that is, once an instruction in the program is executed, it may be executed again soon. Therefore, this method also has a certain cache effect.

[0089] In the real-time loading and unloading phase, the parent process monitors the child process, monitors whether the total number of gadgets in memory and the total gadget danger score have reached the threshold, and uses the LRU batch unloading strategy. The memory layout is as follows: Figure 2 As shown, the standby area contains all the codes, the execution area only contains the loaded codes, and the rest is empty. By monitoring in the above manner until the program is executed, the security of the program is ensured.

[0090] In summary, the present invention proposes a more fine-grained real-time loading and unloading strategy, which uses custom gadgets, evaluates the danger level of gadgets, initializes thread pools, execution areas, and spare areas, loads and unloads in real time, and monitors the total number of gadgets and the total danger level, so that multiple gadgets that may be exploited in the memory cannot exist in the memory at the same time, so that attackers cannot form a gadget chain, thereby ensuring the security of the program. At the same time, multi-threading and LRU batch unloading methods are used for optimization, reducing the overhead caused by fine-grainedness.

[0091] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A code reuse attack defense method based on real-time loading of gadget quality, characterized in that: The steps include: Step 1, preprocessing stage: Get the program code segment, and perform static analysis on the instructions of all functions in the code segment, define every n instructions as a gadget, and get the total number of gadgets in the entire program; evaluate the danger level of the obtained gadgets, determine the danger level score of each gadget, and store it in a file; Step 2, initialization phase: Thread pool initialization: create thread task types and task queues, and at the same time, create multiple threads; Initialize the spare area and execution area: copy all program code segments to the spare area and clear the execution area. Clearing means changing all code segments in the execution area to 0xCC. At the same time, set the spare area to read-only permission, and the execution area to read and execute. Gadget information storage: The address and size of the gadget in the file obtained in the preprocessing stage are stored in the hash table; Step 3, real-time loading and unloading phase: Monitoring is implemented by creating a parent-child process, where the parent process performs monitoring and the child process runs the executable program; When the child process attempts to execute the code snippet, it finds 0xCC instead of a program instruction. At this time, the parent process captures the corresponding signal and needs to load it. The loading task is distributed to the thread pool, which allows the thread to find the corresponding size through the address and the hash table. All instructions corresponding to the gadget are found in the spare area and loaded into the execution area. The child process continues to execute after the instructions are loaded back. When the parent process monitors that the total number of gadgets in the execution area exceeds the set threshold or the total risk score of gadgets in the execution area exceeds the set threshold, it needs to be uninstalled and the existing code snippet in the execution area is directly modified to 0xCC.

2. A code reuse attack defense method based on real-time loading of gadget quality according to claim 1, characterized in that: In step 1, every 5 instructions are defined as a gadget. When the end of the function is reached, the remaining instructions are set as a gadget.

3. A code reuse attack defense method based on real-time loading of gadget quality according to claim 1, characterized in that: In step 1, the target addresses of all call and jmp instructions are first obtained and stored in a list structure called target. Then, when obtaining the gadget, it is truncated at the call and jmp.

4. The code reuse attack defense method based on real-time loading of gadget quality according to claim 1 is characterized in that: In step 2, the degree of danger is divided into 4 levels, 1 represents the lowest degree of danger and 4 represents the most dangerous. The specific division principles are as follows: The danger level score of instructions with pop reg form or containing popa and popal is 4; The danger level score of the instructions including ret, call, and jmp is 3; The danger level score for instructions involving rip, rsp, rbp, eip, esp, and ebp is 3; The danger level score of using privileged instructions is 3; The danger level score of the memory reference instruction is 2; The remaining instructions have a danger level score of 1.

5. The code reuse attack defense method based on real-time loading of gadget quality according to claim 1 is characterized in that: In step 3, the child process is a multi-threaded program, and the parent process is also monitored in real time through multi-threading. The parent and child processes allow the child process to execute on a fixed piece of memory through shared memory.

6. A code reuse attack defense method based on real-time loading of gadget quality according to claim 5, characterized in that: In step 3, in order to allow the child process to execute on a fixed piece of memory, it is necessary to first obtain the child process parameters, environment variables, and child process entry point information; the program parameters and environment variables can be obtained through the process initialization stack. In order to simulate execution, a new stack needs to be defined. The customized new stack is a user-mode stack; the child process entry point information can be directly obtained through the ELFheader.

7. A code reuse attack defense method based on real-time loading of gadget quality according to claim 1, characterized in that: In step 3, when the child process runs the executable program, the child process needs to jump to the execution area, so the current context, including various general registers, is saved first, and then jumps to the child process entry point of the execution area; specifically, it is implemented through a small piece of assembly code, which stores various general register information through the push reg method, and then jumps to the child process entry point through the jmp method, and then restores the general register information through the pop instruction.

8. The code reuse attack defense method based on real-time loading of gadget quality according to claim 1 is characterized in that: In step 3, when unloading, the LRU batch unloading strategy is adopted.

9. The code reuse attack defense method based on real-time loading of gadget quality according to claim 1 is characterized in that: In step 3, when uninstalling, the LRU algorithm is used to uninstall multiple gadgets that have not been used for the longest time.

Images