Dynamic program analysis method oriented to WOW64 environment enhancement

Abstract

The invention discloses a dynamic program analysis method oriented to WOW64 environment enhancement, which can be used for performing efficient fine-grained analysis on a target application program running in a WOW64 environment, realizing efficient and stable analysis on 32-bit and mixed programs by fusing a built-in simulator of a 64-bit Windows operating system, and meanwhile, being compatible with analysis of 64-bit mode execution codes. According to the method, interception and dynamic instrumentation of execution of the target program are realized by using system kernel characteristics, and a dynamic analysis code generation scheme for WOW64 environment enhancement is provided, so that the influence on execution of the target program is reduced, and the method has relatively good deployability. The dynamic program instrumentation and analysis method driven by a system kernel is realized, an analysis scene in a WOW64 environment is optimized, and dynamic analysis on various types of programs can be realized. According to the method, the availability of dynamic analysis in the WOW64 environment is improved, and the performance of fine-grained analysis and the analysis and detection confrontation capability are further improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of software security analysis, and in particular relates to a dynamic program analysis method for WOW64 environment enhancement. Background Art

[0002] The Windows platform remains a primary target for vulnerability exploits and malicious code attacks, and 32-bit applications are still widely used on the Windows platform, including older versions of software, specialized software, and open source software. Well-known software like Office and Adobe all have corresponding installers. Although 64-bit Windows systems are widely used, to maintain compatibility, Windows also provides an emulation platform called WOW64, which allows 32-bit applications to run seamlessly on 64-bit platforms. In fact, when VMware Workstation Pro, a well-known virtualization software, is installed on a 64-bit Windows system, most of its components are 32-bit programs.

[0003] One of the biggest challenges facing 32-bit programs at runtime is the limited memory address space. While this can conserve resources to a certain extent, dynamic program instrumentation and fine-grained analysis also consume significant memory space, potentially impacting the normal operation of the target program. Current mainstream analysis frameworks analyze different versions of a program separately, effectively operating within a 32-bit architecture when analyzing 32-bit applications. Furthermore, if the target program itself occupies a large amount of memory during runtime, insufficient memory may occur within the analysis environment, preventing the program from running properly or being analyzed. In fact, many malware programs employ code bloat to evade automated detection by security software engines and sandboxes. Therefore, when a program with code bloat executes, the system reserves a significant amount of memory space for the program. In this case, the memory available to the analysis framework itself is severely limited, and shadow memory used to store analysis state becomes even more difficult to allocate. For example, analysis of such programs using application-layer instrumentation tools will fail. However, the target program itself can still use the memory space reserved for segments, without impacting its operation. On the other hand, the operation of some special applications, such as vulnerability exploits and runtime code modification, depends on memory allocation and space layout. The modules and code associated with the application-layer analysis framework occupying the target process space may interfere with the target program's normal memory allocation and addressing, causing deviations in its functional execution. For example, for some vulnerability exploits, when using traditional application-layer methods to load and execute the program without adding additional instrumentation code, the vulnerability exploit is difficult to trigger normally. The presence of the analysis framework may cause changes in the preset memory allocation location, making it difficult for traditional application-layer methods to perform accurate dynamic data flow analysis on these programs. Summary of the Invention

[0004] The purpose of the present invention is to address the problems existing in the above-mentioned prior art and provide a dynamic program analysis method for WOW64 environment enhancement, realize a dynamic code tracking and analysis framework based on the system kernel, can uniformly intercept and analyze target programs in the WOW64 environment, expand the execution environment for 32-bit programs, overcome problems such as insufficient memory resources and memory layout impact, improve the analysis capability of special applications, and further enhance the analysis, detection and confrontation capabilities.

[0005] The technical solution to achieve the purpose of the present invention is: a dynamic program analysis method for WOW64 environment enhancement, the method comprising the following steps:

[0006] Step 1: Configure and load the kernel driver on the target system, start the target program to be analyzed, manage and control the entire running process of the target program, and ensure that the execution of all user-mode code of the target program can be tracked and processed;

[0007] Step 2: After the current analysis begins, the memory space that the dynamic analysis process relies on is set in the target process space, including the newly generated execution code cache, the code lookup location table, the shadow memory used for dynamic taint analysis, and other spaces allocated as needed during the dynamic analysis process;

[0008] Step 3: During the target program's execution, the kernel driver continuously intercepts and tracks its code execution, and dynamically generates actual execution code based on target program access exceptions and fast system call instructions;

[0009] Step 4: rewrite the special instructions that appear during the execution of step 3 so that the semantics of the original program remain unchanged when executed in 64-bit mode;

[0010] Step 5: Based on step 4, the system call process is optimized and the jump and return instructions of the system call in the WOW64 environment are rewritten to further improve the code generation and execution efficiency;

[0011] Step 6: Quickly link the dynamically generated code. When generating the code, the direct jump and indirect jump in the original code are processed separately, and the system call instruction is used to modify and link the code block in the kernel.

[0012] Step 7: Build efficient analysis code at the instruction level and propose a runtime data recording and extraction algorithm based on basic blocks to further build efficient dynamic fine-grained analysis code for the target program.

[0013] Step 8: Based on the dynamic analysis target, in the generated analysis code, the system call instruction and access exception are used to make the program execution enter the kernel, complete the specific analysis and inspection tasks and output the analysis results.

[0014] Compared with the prior art, the present invention has the following significant advantages:

[0015] 1) The present invention implements a dynamic program analysis method for WOW64 environment enhancement based on the kernel driver, solving the problem that traditional application layer methods cannot analyze special applications in the WOW64 environment;

[0016] 2) The present invention integrates the underlying system infrastructure, effectively improving analysis performance and detection and countermeasure capabilities, and reducing the impact of virtual machine detection commonly used by malicious code;

[0017] 3) This invention focuses on optimizing dynamic fine-grained analysis of 32-bit programs, improving analysis performance through method design itself, and has certain versatility;

[0018] 4) The method proposed in the present invention can be directly implemented in an existing system environment, and can take into account both deployment flexibility and analysis concealment. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a framework diagram of the dynamic program analysis method enhanced for the WOW64 environment according to the present invention.

[0020] Figure 2 A flow chart of dynamic code generation and execution constructed in one embodiment.

[0021] Figure 3 The flowchart of system call analysis and processing in the WOW64 environment constructed in one embodiment.

[0022] Figure 4 FIG2 is a diagram showing the experimental results of dynamic analysis of vulnerability exploitation verification code in one embodiment. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0024] In one embodiment, combined Figure 1 , provides a dynamic program analysis method enhanced for WOW64 environment, including the following steps:

[0025] Step 1: Configure and load the kernel driver on the target system, start the target program to be analyzed, manage and control the entire running process of the target program, and ensure that the execution of all user-mode code of the target program can be tracked and processed. This step specifically includes:

[0026] Step 1.1: When the target program is started, the kernel driver allocates a mapping table for page and code status tracking for each target process, saves the original permission status of the memory page, and marks and updates it during the tracking process;

[0027] Step 1.2: traverse the target process space, obtain all pre-allocated memory pages in the process space, and use the underlying functions provided by the system kernel to set memory access permissions, such as the MiSetProtectionOnSection function;

[0028] Step 1.3: Distinguish between 32-bit and 64-bit programs, monitor the memory page allocation operations of the target process, adjust the access rights of the process space memory pages for allocation and deallocation operations, and intercept code instruction fetch operations. For 32-bit programs, the user space tracked only includes the lower 4GB addresses;

[0029] In step 1.4, the kernel driver is used to capture the user callback and user mode exception distribution process in the WOW64 environment, intercepting all user mode code execution of the target program. The user processing functions in the 32-bit NTDLL module are filtered, such as the KiUserCallbackDispatcherHandler function, ignoring the execution of code not relevant to the analysis, and ensuring the normal execution of the original program after processing.

[0030] Step 2: Allocate the memory space that the dynamic analysis process relies on in the target process space, including the newly generated execution code cache, code lookup location table, shadow memory for dynamic taint analysis, and other space allocated as needed during the dynamic analysis process. The specific steps include:

[0031] Step 2.1: Using the kernel driver, when analyzing 32-bit programs, expand the code execution environment to the entire 64-bit address space and allocate reserved memory space in the high address space;

[0032] Step 2.2: Allocate generated code cache space to store the dynamically generated target code and the data structures required for code instrumentation. The cache used to store generated code can be set to 2GB in size. This allows direct jump instructions to be used when linking between generated code blocks, that is, the offset address of the jump target is directly specified in the code, which speeds up execution. The remaining space is used to store other analysis-related data.

[0033] Step 2.3 allocates shadow memory space for dynamic taint analysis to store the analysis status of the target program's memory. For 32-bit programs, a pre-allocation scheme is used, and the memory size is consistent with the 32-bit process space address range. This allows for faster reading and writing of the analysis status through offsets during analysis. For 32-bit space, a direct mapping method is used, while for 64-bit programs, an on-demand allocation scheme is used, that is, memory is allocated immediately based on memory usage during the execution of the target program.

[0034] Step 2.4 allocates and builds a code lookup and location table, which establishes a mapping between the original code and the generated code. This facilitates rapid location of the dynamically generated executable code from the original code. Physical memory is allocated only when the program accesses the allocated memory address. Pre-allocating a large amount of virtual address space does not overuse physical memory resources. For 64-bit addresses, a two-level or three-level index lookup access method is used to conserve virtual address space.

[0035] Step 3: intercept and track the target program during its execution and dynamically generate the actual execution code. In one embodiment, Figure 2 , the main steps of code generation include:

[0036] Step 3.1: Take over the target code execution process through the target program's page access exception. When the original code is about to be executed, it will trigger a non-executable exception. The kernel driver captures the address and disassembles and rewrites it to generate a new actual execution code. This method can intercept unknown code, such as kernel callbacks and injected code.

[0037] Step 3.2: When rewriting the code, the program basic block is used as the unit, that is, the block starting from the current exception address is parsed until the jump instruction, and a code management structure is added in front of the newly generated code to describe the basic information of the code;

[0038] Step 3.3: After the current basic block is constructed, the address of the generated code is used as the return address, and the target thread returns to user mode to continue execution. For 32-bit programs, before the thread returns to user mode, the L flag of the CS segment is determined and modified to make the processor run in 64-bit mode, expanding the memory addressing range of the program during execution.

[0039] Step 3.4: Use fast system calls to intercept code execution and rewrite the code to improve code generation speed, hook the system call dispatch function in the kernel, and filter it through context features;

[0040] Step 3.5: For the generated code, at the control transfer instruction, use the system call instruction to make the code execution enter the kernel and rewrite the instruction at the jump target address, so as to handle the situation where the execution process is controllable through the system call instruction;

[0041] Step 3.6, for the indirect jump instruction, when searching and obtaining the generated target code, the program will enter kernel mode due to an access exception and generate the target code in the same way. In the generated code, the target address is used as the index to search the generated code address of the target through the code lookup positioning table. The kernel driver continues to track the target program, captures the exception event, generates new code and updates the code mapping table.

[0042] Step 4: Rewrite the special instructions that appear during the execution of step 3 so that the semantics of the original program remain unchanged when executed in 64-bit mode. The specific steps include:

[0043] Step 4.1: Rewrite special instructions. When converting 32-bit code to 64-bit code, most instructions can keep the same encoding or be implemented by simply adding the instruction prefix 0x67.

[0044] Step 4.2: Some instructions do not support 32-bit execution in 64-bit mode. Appropriate conversion is performed on these instructions to maintain the correctness of program semantics, including enter / leave, push / pop, etc. For example, convert push eax to "lea esp, [esp-4]; mov dwordptr [esp], eax";

[0045] In step 4.3, perform separate conversions for the encoding methods of the inc and dec instructions that are only supported in 32-bit mode.

[0046] Step 5, further, based on step 4, the system call process is optimized, and the syscall instruction is directly reused when generating code. After the execution returns from the kernel, the framework will intercept its execution and perform subsequent instrumentation. In one embodiment, combined with Figure 3 When the 32-bit target code executes a system call, it intercepts and rewrites the final indirect jump instruction in the wow64cpu component. It then uses this indirect jump to continue execution in the wow64cpu module, including jumps to the ntdll and win32u modules. Furthermore, when the system call completes and returns to 32-bit mode, it hooks the return code and redirects execution to the generated code corresponding to the original code, further improving code generation and execution efficiency.

[0047] Step 6: Quickly link the dynamically generated code. When generating code, for direct and conditional jumps in the original code, the jump targets are directly obtained from the source code, and the related code is directly linked together in the generated code. The jump instruction rewrite structure is similar to the original instruction, but when the target code is not parsed and generated, it defaults to jumping to a special stub block containing the syscall instruction. For example, if the jump condition is not met, the kernel driver will continue execution and enter the kernel to generate the target code for the corresponding block. It will also dynamically modify the previous jump instruction so that subsequent execution will directly jump to the newly generated code, thus completing the linking of the generated code.

[0048] Step 7: Construct efficient analysis code at the instruction level to further implement efficient dynamic fine-grained analysis of the target program. Construct analysis code based on the basic block level of the program, and place the analysis code corresponding to each basic block before the jump instruction of its generated code. If you want to check the analysis status before a certain instruction, merge and insert the analysis code before it. When generating target code for the basic block, insert the relevant runtime recording code before the memory access instruction, and add the corresponding acquisition instruction to the analysis code. When parsing the basic block, no deep analysis process is introduced, but code generation is completed in a single round of linear scanning, and a runtime data recording and extraction algorithm based on the basic block is implemented. The main steps of the algorithm include:

[0049] Step 7.1, according to the starting address of the target basic block, obtain all the instruction information included in the basic block and initialize the structure array R to track the changes in register values ​​during code execution, as shown in formula (1):

[0050]

[0051] Among them, i represents the register index, which belongs to the register set REG_SET. The number of registers is related to the processor architecture. The structure member index represents the corresponding buffer index position. set indicates whether the register value has been recorded. offset represents the offset between the recorded value and the actual value. It is mainly used for Stack type operations.

[0052] Step 7.2: Initialize the instruction information set S, which includes the runtime register value to be loaded and the offset of the buffer where it is located, as shown in formula (2):

[0053]

[0054] Where j represents the instruction index, and the instruction belongs to the instruction set INS_SET contained in the basic block;

[0055] Step 7.3, traverse each instruction in the basic block and determine whether the register values ​​involved in the instruction need to be recorded. If they need to be recorded, update the set S, as shown in formula (3):

[0056]

[0057] Among them, reg represents the register index involved, ins represents the instruction index involved, and slot is the offset value of the buffer corresponding to the saved data;

[0058] Step 7.4: Based on step 7.3, determine whether the R[reg].set flag has been set. If not, update the flag, as shown in formula (4):

[0059]

[0060] Among them, k represents the buffer index currently used;

[0061] Step 7.5: Determine whether the register value involved will change after the instruction is executed. If so, reset the R[reg].set flag.

[0062] Step 7.6, determine whether the instruction is the target instruction to be analyzed. If not, reset the R[reg].set flag;

[0063] Step 7.7: For stack operation instructions, adjust the corresponding offset value, as shown in formula (5):

[0064]

[0065] Among them, OperandSize indicates the size of the operands involved in the current instruction, PUSH indicates the set of instructions involving push operations, POP indicates the set of instructions involving pop operations, and esp indicates the stack pointer register;

[0066] Step 7.8, obtain the instruction information set S involving register saving and loading, and add the corresponding value acquisition code to the generated code according to the content of the set, so that the runtime information can be obtained during analysis.

[0067] Step 8: Based on the dynamic analysis target, in the generated analysis code, the system call instruction and access exception are used to make the program execution enter the kernel, complete the specific analysis and inspection tasks and output the analysis results.

[0068] The method of the present invention solves the problem of efficient and fine-grained analysis of applications in the WOW64 environment, enabling enhanced dynamic analysis of 32-bit and hybrid applications. It also addresses issues such as insufficient resources, code bloat, and execution mode switching that exist in the analysis of 32-bit applications in the WOW64 environment. Compared to other methods, the analysis method of the present invention can address the problems faced by dynamic analysis in the WOW64 environment, reduce analysis overhead, and balance deployment flexibility with analysis confidentiality. Figure 4 The present invention performs dynamic analysis of memory detection effects on CVE vulnerability verification codes, which can achieve more in-depth analysis of complex codes such as vulnerability exploits.

[0069] In summary, the dynamic program analysis method for WOW64 environment enhancement proposed in the present invention fully utilizes system kernel technology to achieve unified execution interception and code analysis for 32-bit and 64-bit codes, further improving the flexibility of analysis and having better analysis, detection and confrontation capabilities. This method expands the execution environment of 32-bit programs under WOW64, can make full use of the 64-bit process space, realizes more efficient dynamic code generation and analysis code execution process, and improves the adaptability of dynamic analysis in the WOW64 environment.

[0070] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only illustrative of the principles of the present invention. Without departing from the spirit and scope of the present invention, any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A dynamic program analysis method for WOW64 environment enhancement, characterized in that: The following steps are involved: Step 1: Configure and load the kernel driver on the target system, start the target program to be analyzed, manage and control the entire running process of the target program, and ensure that the execution of all user-mode code of the target program can be tracked and processed; Step 2: After the current analysis begins, the memory space that the dynamic analysis process relies on is set in the target process space, including the newly generated execution code cache, the code lookup location table, the shadow memory used for dynamic taint analysis, and other spaces allocated as needed during the dynamic analysis process; Step 3: During the target program's execution, the kernel driver continuously intercepts and tracks its code execution, and dynamically generates actual execution code based on target program access exceptions and fast system call instructions; Step 4: rewrite the special instructions that appear during the execution of the target program in step 3 so that the semantics of the original program remain unchanged when executed in 64-bit mode; Step 5: Based on step 4, the system call process is optimized and the jump and return instructions of the system call in the WOW64 environment are rewritten to further improve the code generation and execution efficiency; Step 6: Quickly link the dynamically generated code. When generating the code, the direct jump and indirect jump in the original code are processed separately, and the system call instruction is used to implement the modification and linking of the code block in the kernel. Step 7: Build efficient analysis code at the instruction level and propose a runtime data recording and extraction algorithm based on basic blocks to further build efficient dynamic fine-grained analysis code for the target program. Step 8: Based on the dynamic analysis target, in the generated analysis code, the system call instruction and access exception are used to make the program execution enter the kernel, complete the specific analysis and inspection tasks and output the analysis results.

2. The WOW64 environment-enhanced dynamic program analysis method according to claim 1, characterized in that: In step 1, the kernel driver is loaded to manage and control the entire running process of the target program, including: Step 1.1: The kernel driver allocates a mapping table for page and code status tracking for each target process, saves the original permission status of the memory page, and marks and updates it during the tracking process; Step 1.2: traverse the target process space, obtain all pre-allocated memory pages in the process space, and use the underlying functions provided by the system kernel to set memory access permissions; Step 1.3: Monitor the memory page allocation operations of the corresponding processes of 32-bit programs and 64-bit programs respectively, adjust the access rights of the process space memory pages for allocation and recycling operations, and intercept the code instruction fetch operation; In step 1.4, the kernel driver is used to capture the user callback and user mode exception distribution process in the WOW64 environment, intercepting all user mode code execution of the target program.

3. The WOW64 environment-enhanced dynamic program analysis method according to claim 1, characterized in that: In step 2, the memory space that the dynamic analysis process relies on is allocated in the target process space, specifically including: Step 2.1: Use the kernel driver to expand the code execution environment of the 32-bit program to the entire 64-bit address space and allocate reserved memory space in the high address space; Step 2.2: Allocate generated code cache space to store the dynamically generated target code and the data structures required for code instrumentation. The remaining space is used to store other analysis-related data. Step 2.3: Allocate shadow memory space for dynamic taint analysis to store the analysis status of the target program's memory. For 32-bit programs, a pre-allocation scheme is used, and the memory size is consistent with the 32-bit process space address range. For 64-bit programs, real-time allocation is performed based on the memory usage during the execution of the target program. Step 2.4, allocate and build a code lookup location table to establish a mapping relationship between the original code and the generated code. For 32-bit space, direct mapping is used, and for 64-bit space, two-level or three-level index lookup access is used to save virtual address space.

4. The WOW64 environment-enhanced dynamic program analysis method according to claim 1, characterized in that: In step 3, the target program execution process is intercepted and tracked, and the actual execution code is dynamically generated, including: Step 3.1: Take over the target code execution process through the target program's page access exception. When the original code is about to be executed, it will trigger a non-executable exception. The kernel driver captures the exception address and disassembles and rewrites it to generate new actual execution code. Step 3.2: When rewriting the code, the program basic block is used as the unit, that is, the block starting from the current exception address is parsed until the jump instruction, and a code management structure is added in front of the newly generated code to describe the basic information of the code; Step 3.3: After the current basic block is built, the address of the generated code is used as the return address, and the target thread returns to user mode to continue execution, and the processor runs in 64-bit mode. Step 3.4: Use fast system calls to intercept code execution and rewrite the code to improve code generation speed, hook the system call dispatch function in the kernel, and filter it through context features; Step 3.5: For the generated code, at the control transfer instruction, use the system call instruction to make the code execution enter the kernel and rewrite the instruction at the jump target address; Step 3.6, for the indirect jump instruction, when searching and obtaining the generated target code, the program will enter kernel mode due to an access exception and generate the target code in the same way. In the generated code, the target address is used as the index to search the generated code address of the target through the code lookup positioning table. The kernel driver continues to track the target program, captures the exception event, generates new code and updates the code mapping table.

5. The WOW64 environment-enhanced dynamic program analysis method according to claim 4, characterized in that: In step 4, the special instructions that appear during the running of the target program in step 3 need to be rewritten, including: Step 4.1: Rewrite special instructions. When converting 32-bit code to 64-bit code, most instructions can keep the same encoding or be implemented by simply adding the instruction prefix 0x67. Step 4.2: Some instructions do not support 32-bit execution in 64-bit mode. These instructions are converted appropriately to maintain the correctness of program semantics. In step 4.3, perform separate conversions for the encoding methods of the inc and dec instructions that are only supported in 32-bit mode.

6. The WOW64 environment-enhanced dynamic program analysis method according to claim 5, characterized in that: In step 5, the system call instruction is optimized, including: (1) When generating code, the syscall instruction is directly reused. After the execution returns from the kernel, the framework will intercept its execution and perform subsequent instrumentation; (2) After the system call is executed and returns to 32-bit mode, the return code is hooked and the execution is redirected to the generated code corresponding to the original code, further improving the efficiency of code generation and execution.

7. The WOW64 environment-enhanced dynamic program analysis method according to claim 1, characterized in that: In step 6, the dynamically generated code is quickly linked, including: (1) When generating code, for direct jumps and conditional jumps in the original code, the jump targets are directly obtained from the code; (2) The jump instruction rewrite structure is similar to the original instruction, but when the target code is not parsed and generated, it jumps to a special stub block containing the syscall instruction by default; (3) The kernel driver will continue to execute and enter the kernel and generate the target code of the corresponding block, and dynamically modify the previous jump instruction so that its subsequent execution can directly jump to the newly generated code.

8. The WOW64 environment-enhanced dynamic program analysis method according to claim 1, characterized in that: In step 7, a runtime data recording and extraction algorithm based on basic blocks is proposed. The specific process includes: Step 7.1, according to the starting address of the target basic block, obtain all the instruction information included in the basic block and initialize the structure array R to track the changes in register values ​​during code execution, as shown in formula (1): Among them, i represents the register index, which belongs to the register set REG_SET. The number of registers is related to the processor architecture. The structure member index represents the corresponding buffer index position. set indicates whether the register value has been recorded. offset represents the offset between the recorded value and the actual value. It is for Stack type operations. Step 7.2: Initialize the instruction information set S, which includes the runtime register value to be loaded and the offset of the buffer where it is located, as shown in formula (2): Where j represents the instruction index, and the instruction belongs to the instruction set INS_SET contained in the basic block; Step 7.3, traverse each instruction in the basic block and determine whether the register values ​​involved in the instruction need to be recorded. If they need to be recorded, update the set S, as shown in formula (3): Among them, reg represents the register index involved, ins represents the instruction index involved, and slot is the offset value of the buffer corresponding to the saved data; Step 7.4: Based on step 7.3, determine whether the R[reg].set flag has been set. If not, update the flag, as shown in formula (4): Among them, k represents the buffer index currently used; Step 7.5: Determine whether the register value involved will change after the instruction is executed. If so, reset the R[reg].set flag. Step 7.6, determine whether the instruction is the target instruction to be analyzed. If not, reset the R[reg].set flag; Step 7.7: For stack operation instructions, adjust the corresponding offset value, as shown in formula (5): Among them, OperandSize indicates the size of the operands involved in the current instruction, PUSH indicates the set of instructions involving push operations, POP indicates the set of instructions involving pop operations, and esp indicates the stack pointer register; Step 7.8, obtain the instruction information set S involving register saving and loading, and add the corresponding value acquisition code to the generated code according to the content of the set, so that the runtime information can be obtained during analysis.

Images