An Automatic Migration Method and System for Vulnerability Verification Code in Windows Applications

Abstract

This invention proposes an automatic migration method and system for vulnerability verification code in Windows applications, belonging to the field of vulnerability verification technology. In this method, the original version of the vulnerability verification code is executed on a cross-version Windows application, and the execution process is tracked using dynamic instrumentation technology. Based on the behavior obtained during the vulnerability verification process, a vulnerability exploitation strategy model is established to generate an exploitation strategy. The stages that trigger crashes during the vulnerability verification process are extracted, and the reasons for failure in executing vulnerability verification on the cross-version Windows application are identified through the exploitation strategy. Based on the failure reasons, the original version of the vulnerability verification code is modified, thereby automatically migrating to generate the target version of the vulnerability verification code. This invention addresses the problems of low efficiency and high technical barriers in generating vulnerability verification code when performing vulnerability verification on different versions of Windows applications.

Description

Technical Field

[0001] This invention belongs to the field of vulnerability verification technology, and in particular relates to an automatic migration method and system for vulnerability verification code for Windows applications. Background Technology

[0002] With the development of information technology, various software programs are rapidly being updated and popularized, making their security crucial. Binary software vulnerabilities pose a significant threat to network security, and Windows software, as the most common type of binary software, is widely used in people's daily lives and work. Therefore, the need for Windows software vulnerability verification is increasingly urgent. Because different operating systems and applications on the internet have their own versions, vulnerability verification code is mostly based on existing, known operating environments. This presents significant difficulties for migrating code between different versions of operating systems and applications. Furthermore, information security needs are constantly evolving, thus necessitating research into faster, more convenient, and more universal vulnerability verification technologies.

[0003] From an enterprise and organizational application perspective, security personnel perform functional upgrades and security checks on various systems and applications. In this context, migrating vulnerability verification code directly to another environment requires writing a new set of vulnerability verification code specifically for the target environment for testing. However, human factors and environmental issues can lead to verification failures during testing, consuming significant time and manpower. Furthermore, with the widespread application of new technologies such as cloud computing, big data, and the Internet of Things in today's increasingly complex and diverse network environments, traditional vulnerability verification methods rely primarily on manually writing and testing verification code. This process is cumbersome, time-consuming, and technically challenging, exhibiting limitations such as long execution time and low success rates, failing to meet practical needs. Summary of the Invention

[0004] To address the aforementioned technical issues, it is necessary to implement automatic migration of vulnerability verification code to generate vulnerability verification code suitable for new software versions, thereby improving the efficiency and success rate of vulnerability verification. This invention proposes a method and system for automatic migration of vulnerability verification code for Windows applications; aiming to solve the problems of low efficiency in generating vulnerability verification code for different versions of applications in the Windows operating system and high dependence on source code.

[0005] The first aspect of this invention proposes an automatic migration method for vulnerability verification code in Windows applications. The method includes: step S1, executing the original version of vulnerability verification code on a cross-version Windows application and tracing the execution process using dynamic instrumentation technology; step S2, establishing a vulnerability exploitation strategy model based on the behavior obtained during the vulnerability verification process to generate a vulnerability exploitation strategy; step S3, extracting the stages that trigger crashes during the vulnerability verification process and identifying the reasons for failure in executing vulnerability verification on the cross-version Windows application through the vulnerability exploitation strategy; and step S4, modifying the original version of vulnerability verification code based on the reasons for failure, thereby generating the target version of vulnerability verification code through automatic migration.

[0006] In step S3, the exploitation strategy includes: buffer overflow, EIP overwriting, jump instruction execution, and payload execution; wherein: at the buffer overflow point, pre-configured data exceeding the buffer storage length is input as a parameter of the vulnerable function and introduced into a local variable, causing the data to overflow the buffer; the data is overflowed to the EIP position in the stack frame, and the content at that position is overwritten as the address of the jump instruction to be executed next, then the program executes according to the pre-set control flow; after intercepting the EIP, if the address of the jump instruction exists and meets the program's constraints on the address of the called function, then the program successfully executes the jump instruction; after successfully executing one or more jump instructions, the program jumps to the address where the payload is stored and executes the payload.

[0007] In step S3, the reasons for the failure of performing vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, after the buffer overflow, the address of the expected jump instruction is not filled into the EIP position. The reason is that the stack memory layout has changed, the stack frame length has changed, and the length of the filling content is not equal to the stack frame length.

[0008] In step S3, the reasons for the failure to perform vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, after executing EIP overwrite, the instructions at the EIP location are not executed successfully. The reason is that the GS mitigation mechanism is deployed. When the program returns from the function, it checks the Security Cookie value in the stack frame. In the case of stack overflow, the Security Cookie value is changed.

[0009] In step S3, the reasons for the failure to perform vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, the reasons include: after performing EIP overwrite, the instructions at the EIP location were not successfully executed. The reasons also include: the deployment of the safeSEH mitigation mechanism, the program checks the address of the called function, and the address of the jump instruction is disabled.

[0010] In step S3, the reasons for the failure to perform vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, the reasons include: during the execution of the jump instruction, the control flow of the program cannot be intercepted to the attack payload execution stage because the address of the jump instruction has changed.

[0011] In step S4, the original version of the vulnerability verification code is modified, specifically including: for cases where the stack memory layout changes, the length of the padding content is modified by string matching.

[0012] In step S4, the vulnerability verification code of the original version is modified, specifically including: for cases where a mitigation mechanism is deployed, a flag scanning method is used to bypass the mitigation mechanism.

[0013] In step S4, the original version of the vulnerability verification code is modified, specifically including: for cases where the address of the jump instruction changes, the instruction address is modified using a memory operation alignment method.

[0014] A second aspect of this invention proposes an automatic migration system for vulnerability verification code in Windows applications. The system includes a processing unit configured to: execute the original version of vulnerability verification code on a cross-version Windows application, and track the execution process using dynamic instrumentation technology; establish a vulnerability exploitation strategy model based on the tracked behavior during the vulnerability verification process to generate an exploitation strategy; extract the stages that trigger crashes during the vulnerability verification process, and identify the reasons for failure in executing vulnerability verification on the cross-version Windows application through the exploitation strategy; modify the original version of vulnerability verification code based on the failure reasons, thereby generating the target version of vulnerability verification code through automatic migration.

[0015] In summary, this invention proposes a dynamic adjustment method to automatically migrate Windows application stack overflow vulnerability verification code. Specifically, this invention achieves the following technical effects: (1) Using this invention, vulnerability verification code suitable for a new environment can be generated based on the input application and vulnerability verification code; (2) Using this invention, cross-version difference analysis can be automatically performed for different versions of Windows applications; (3) Using this invention, the reasons for migration failures of vulnerability verification code for different versions of Windows applications can be analyzed and automatically adjusted. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating an automatic migration method for vulnerability verification code in Windows applications according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] This invention proposes an automatic migration method and system for vulnerability verification code for Windows applications; aiming to solve the problems of low efficiency in generating vulnerability verification code for different versions of applications in the Windows operating system and high dependence on source code.

[0020] The first aspect of this invention proposes an automatic migration method for vulnerability verification code in Windows applications, the method comprising (e.g.) Figure 1 (As shown): Step S1: Execute the original version of the vulnerability verification code on the cross-version Windows application and use dynamic instrumentation technology to trace the execution process; Step S2: Build a vulnerability exploitation strategy model based on the behavior obtained during the vulnerability verification process to generate a vulnerability exploitation strategy; Step S3: Extract the stage that triggers the crash during the vulnerability verification process and identify the reasons for the failure of the vulnerability verification on the cross-version Windows application through the vulnerability exploitation strategy; Step S4: Modify the original version of the vulnerability verification code based on the reasons for the failure, thereby generating the target version of the vulnerability verification code through automatic migration.

[0021] In some embodiments, the original vulnerability verification code is first run on two different versions of software. Then, dynamic instrumentation technology is used to trace the entire process of program execution. A model is built based on the behavior during the vulnerability verification process to generate a vulnerability exploitation strategy. After that, the stage of program crash is analyzed and the reasons for cross-version vulnerability verification failure are identified by comparing with the vulnerability exploitation strategy. Finally, these failure reasons are classified and processed to modify the key parameters in the vulnerability verification code to generate the target version of vulnerability verification code: for cases where the address of the key instruction changes, the address of the key instruction is modified by using memory operation alignment; for cases where the stack memory layout changes, the padding length is modified by using string matching; and for cases where the mitigation mechanism is deployed, the mitigation mechanism is bypassed by using flag scanning.

[0022] In step S3, the exploitation strategy includes: buffer overflow, EIP overwriting, jump instruction execution, and payload execution; wherein: at the buffer overflow point, pre-configured data exceeding the buffer storage length is input as a parameter of the vulnerable function and introduced into a local variable, causing the data to overflow the buffer; the data is overflowed to the EIP position in the stack frame, and the content at that position is overwritten as the address of the jump instruction to be executed next, then the program executes according to the pre-set control flow; after intercepting the EIP, if the address of the jump instruction exists and meets the program's constraints on the address of the called function, then the program successfully executes the jump instruction; after successfully executing one or more jump instructions, the program jumps to the address where the payload is stored and executes the payload.

[0023] In step S3, the reasons for the failure of performing vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, after the buffer overflow, the address of the expected jump instruction is not filled into the EIP position. The reason is that the stack memory layout has changed, the stack frame length has changed, and the length of the filling content is not equal to the stack frame length.

[0024] In step S3, the reasons for the failure to perform vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, after executing EIP overwrite, the instructions at the EIP location are not executed successfully. The reason is that the GS mitigation mechanism is deployed. When the program returns from the function, it checks the Security Cookie value in the stack frame. In the case of stack overflow, the Security Cookie value is changed.

[0025] In step S3, the reasons for the failure to perform vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, the reasons include: after performing EIP overwrite, the instructions at the EIP location were not successfully executed. The reasons also include: the deployment of the safeSEH mitigation mechanism, the program checks the address of the called function, and the address of the jump instruction is disabled.

[0026] In step S3, the reasons for the failure to perform vulnerability verification on cross-version Windows applications are identified through the vulnerability exploitation strategy. Specifically, the reasons include: during the execution of the jump instruction, the control flow of the program cannot be intercepted to the attack payload execution stage because the address of the jump instruction has changed.

[0027] In some embodiments, a model is established consisting of buffer overflow - overwriting EIP - executing jump instructions - executing attack payload, which is referred to as a vulnerability exploitation strategy. This model divides the general process of stack overflow vulnerability verification into key steps, dividing the verification process of stack overflow vulnerability into four key steps: buffer overflow, overwriting EIP, executing jump instructions, and executing attack payload.

[0028] To exploit a stack overflow vulnerability, the attacker first needs to input pre-designed data exceeding the buffer's storage length as a parameter into a local variable of the vulnerable function at the buffer overflow point, causing the data to overflow the buffer. To successfully hijack the program's control flow, the attacker needs to pre-design the overflow data so that when it overflows to the EIP address in the stack frame, the content there exactly overwrites the address of the next jump instruction (such as jmp esp, call esi, pop pop ret, etc.) that the program needs to execute, allowing the program to follow the attacker's pre-defined control flow. After hijacking the EIP, if the address of the jump instruction exists and meets the program's constraints on the called function address, the program will successfully execute this jump instruction. Finally, after successfully executing one or more jump instructions, the program will eventually jump to the address where the attack payload is stored and execute the attack payload.

[0029] The above is a complete stack overflow vulnerability verification process. To facilitate the analysis of behavior during the vulnerability verification process, the vulnerability exploitation strategy model will use dynamic instrumentation technology to track four key nodes in the vulnerability verification process and determine whether each step is executed successfully. If the program crashes at a certain node in the model, the model will conduct in-depth analysis of the behavior of that node and output detailed information about the program crash (such as register values, stack call status, etc.) to facilitate subsequent analysis of the cause of the program crash and identification of the reasons for cross-version vulnerability verification failure.

[0030] Based on the vulnerability exploitation strategy model established above, the reason for vulnerability verification failure can be determined according to the stage of program crash. Knowing the reason for vulnerability verification failure, the differences between the new and old versions of the software are obvious: Because the stack frame length has changed in the new version, the length of the padding content in the original vulnerability verification code is not equal to the stack frame length, resulting in the expected jump instruction address not being filled into the EIP; because the new version of the Windows operating system or software has enabled the safeSEH mitigation mechanism, the program checks the Security Cookie value in the stack frame when the function returns. If the Security Cookie value has changed, the function will not return normally, and the instructions in the EIP will not be executed; because the new version of the Windows operating system or software has enabled the safeSEH mitigation mechanism, the program checks the address of the called function. The address of the jump instruction is not among them and is therefore disabled, so the jump instruction cannot be executed; because the address of this jump instruction has changed in the new version of the software, the instruction stored at the jump instruction address in the original vulnerability verification code is another instruction. Even if it is successfully executed, it cannot hijack the program control flow to the vulnerability exploit payload.

[0031] In step S4, the original version of the vulnerability verification code is modified, specifically including: for cases where the stack memory layout changes, the length of the padding content is modified by string matching.

[0032] In step S4, the vulnerability verification code of the original version is modified, specifically including: for cases where a mitigation mechanism is deployed, a flag scanning method is used to bypass the mitigation mechanism.

[0033] In step S4, the original version of the vulnerability verification code is modified, specifically including: for cases where the address of the jump instruction changes, the instruction address is modified using a memory operation alignment method.

[0034] In some embodiments, after determining the reason for the failure of cross-version vulnerability verification of the target software, it is also necessary to adaptively adjust the vulnerability verification code of the reference version to generate vulnerability verification code suitable for the target version of the software. The vulnerability verification code adaptive adjustment techniques are introduced in three parts according to the three reasons for the failure of cross-version vulnerability verification: modification of critical instruction addresses based on memory operation alignment, modification of padding length based on string matching, and bypassing mitigation mechanisms based on flag scanning.

[0035] To address the issue of vulnerability verification failures caused by cross-version software iterations, this invention employs a systematic vulnerability verification code adaptive adjustment technique, along with dynamic execution analysis and semantic matching mechanisms, to achieve automated migration of the reference version's vulnerability verification code (EXP) to the target version. This technology employs a collaborative optimization strategy based on three common failure causes: changes in critical instruction addresses, changes in stack memory layout, and deployment of security mitigation mechanisms. First, dynamic instrumentation is used to record the execution traces of the original EXP on both the reference and target versions, generating memory operation sequences 1 and 2. Then, execution differences are located through step-by-step comparison. For instruction address changes, the target version searches for alternative instructions with the same semantics as the differing instructions in sequence 1 and replaces their addresses. For stack layout changes, a string matching algorithm locates the original padding length in the EXP and replaces it with the target version's offset. For newly added security mechanisms, unprotected dynamic link libraries are identified by scanning system PE file flags, and usable instruction addresses are extracted to replace the original exception handling functions.

[0036] To address the instruction address offset issue, a dynamic execution trace comparison and functional equivalence matching strategy is adopted. By extracting key memory operation semantic features during the execution process of the reference version, an equivalent instruction mapping relationship in the target version is constructed, forming an instruction address update mechanism based on semantic consistency. This mechanism ensures the consistency of execution semantics across versions by iteratively aligning the memory operation sequences in the execution path, effectively fixing the instruction location failure problem caused by code refactoring.

[0037] To address the issue of stack memory layout changes, a pattern recognition-based offset adaptive algorithm was designed. By generating deterministic test templates and analyzing crash characteristics, an offset mapping relationship between versions is constructed. String matching techniques are then used to locate and replace key parameters in the exploit code. This algorithm achieves robust adaptation to stack frame structure changes by abstracting memory layout features, thus resolving the control flow hijacking failure caused by buffer overflow offset invalidation.

[0038] To address the challenges of deploying security mechanisms, a defense bypass method based on system component feature scanning is proposed. By parsing the metadata features of binary files (such as PE file header flags), unprotected system components are identified, and an exploitable instruction library is constructed to achieve semantic bypass of newly added security mechanisms. This method abstracts the detection logic of the defense mechanism and reconstructs the execution path while preserving the semantics of vulnerability exploitation, ensuring the effectiveness of vulnerability verification in enhanced defense environments.

[0039] A second aspect of this invention proposes an automatic migration system for vulnerability verification code in Windows applications. The system includes a processing unit configured to: execute the original version of vulnerability verification code on a cross-version Windows application, and track the execution process using dynamic instrumentation technology; establish a vulnerability exploitation strategy model based on the tracked behavior during the vulnerability verification process to generate an exploitation strategy; extract the stages that trigger crashes during the vulnerability verification process, and identify the reasons for failure in executing vulnerability verification on the cross-version Windows application through the exploitation strategy; modify the original version of vulnerability verification code based on the failure reasons, thereby generating the target version of vulnerability verification code through automatic migration.

[0040] In summary, the goal of the automatic migration method for vulnerability verification code for Windows applications proposed in this invention is to automatically generate vulnerability verification code suitable for the new version of the software based on the existing vulnerability verification code, under the premise that the same stack overflow vulnerability exists in the original version of the Windows application and the target version of the Windows application.

[0041] Regarding the automated analysis technology for cross-version vulnerability verification failures, the following approach is first used: a vulnerability exploitation strategy model is constructed, consisting of buffer overflow, EIP overwriting, execution of jump instruction, and execution of attack payload. Then, dynamic instrumentation is employed to capture cross-version execution differences. Finally, the root causes of verification failures are abstracted into three core contradictions: instruction address offset, stack memory layout changes, and security mechanism deployment. Specifically, instruction address offset manifests as the failure of control flow hijacking points due to cross-version function address space remapping; stack memory layout changes reflect inaccurate buffer filling parameters caused by stack frame structure adjustments; and security mechanism deployment manifests as enhanced security mechanisms blocking the execution of traditional vulnerability exploitation primitives.

[0042] Regarding the adaptive adjustment technology for vulnerability verification code, the process first employs a dynamic alignment algorithm to search for semantically equivalent instruction sequences in the target version that are also present in the reference version. This establishes a cross-version instruction function mapping relationship, resolving the instruction address mutation issue. Then, based on input template mutation and crash offset analysis, adaptive adjustments to the stack layout parameters are made to achieve version adaptation of the padding length. Finally, by scanning system component security attributes, unprotected binary modules are identified, and the instruction pool required for bypassing the security mechanism is constructed, achieving semantic-level bypass of the security mechanism. This process integrates dynamic taint analysis and fuzz testing, iteratively optimizing input parameters to gradually approximate the vulnerability triggering trajectory of the reference version's execution path.

[0043] Regarding binary dynamic analysis technology, this innovative approach transforms the cross-version migration problem into a multi-layered mapping problem involving execution semantics, memory layout, and defense strategies. By constructing an abstract model of vulnerability exploitation strategies, specific version differences are mapped to calculable adjustment parameters. This solution does not rely on source code; it can verify code migration solely through binary dynamic analysis. Its core advantage lies in shielding the implementation details differences brought about by version iterations through semantic abstraction, and using dynamic execution feature matching to achieve adaptive refactoring of vulnerability exploitation logic, providing an automated solution for cross-version vulnerability verification of closed-source software.

[0044] This invention proposes a dynamic adjustment method for automatically migrating Windows application stack overflow vulnerability verification code. Specifically, this invention achieves the following technical effects: (1) Using this invention, vulnerability verification code suitable for a new environment can be generated based on the input application and vulnerability verification code; (2) Using this invention, cross-version difference analysis can be automatically performed for different versions of Windows applications; (3) Using this invention, the reasons for migration failures of vulnerability verification code for different versions of Windows applications can be analyzed and automatically adjusted.

[0045] Please note that the technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. The above embodiments only illustrate several implementation methods of this application, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the invention patent. It should be pointed out that for those skilled in the art, several modifications and improvements can be made without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A vulnerability verification code automatic migration method for a Windows application, characterized by, The method comprises: Step S1, executing the vulnerability verification code of the original version on the cross-version Windows application, tracking the execution process by using dynamic instrumentation technology; Step S2, establishing a vulnerability exploitation strategy model based on the behaviors in the vulnerability verification process obtained through tracking, to generate a vulnerability exploitation strategy; Step S3, extracting the stage of triggering a crash in the vulnerability verification process, and identifying the failure reason for executing the vulnerability verification on the cross-version Windows application through the vulnerability exploitation strategy; Step S4, modifying the vulnerability verification code of the original version based on the failure reason, thereby generating the vulnerability verification code of the target version through automatic migration; In step S4, the vulnerability verification code of the original version is modified, specifically including: For the case of stack memory layout change, a deterministic test template is generated and the crash characteristics are analyzed to build the offset mapping relationship between versions, and the key parameters in the vulnerability exploitation code are located and replaced by using string matching technology; For the case of deploying mitigation mechanisms, the metadata characteristics of the binary file are parsed, the unprotected system components are identified, the exploitable instruction library is constructed, and the semantic bypass of the new security mechanism is realized; For the case of address change of the trampoline instruction, a dynamic execution trace comparison and function equivalent matching strategy is adopted, the key memory operation semantic characteristics in the execution process of the reference version are extracted, the equivalent instruction mapping relationship in the target version is constructed, and an instruction address updating mechanism based on semantic consistency is formed.

2. The method of claim 1, wherein the Windows application-oriented vulnerability verification code automatic migration method is characterized in that, In step S3, the vulnerability exploitation strategy includes: buffer overflow, EIP overwrite, trampoline instruction execution and attack payload execution; wherein: At the buffer overflow point, a pre-configured data exceeding the buffer storage length is input as a parameter of the vulnerability function, which is introduced into the local variable, so that the data overflows the buffer; The data is overflowed to the EIP position in the stack frame, and the content at the position is overwritten as the address of the trampoline instruction for the next step of program execution, and then the program executes according to the pre-set control flow; After intercepting the EIP, if the address of the trampoline instruction exists and meets the constraints of the program on the calling function address, the program successfully executes the trampoline instruction; After the program successfully executes one or more jump instructions, it jumps to the address where the attack payload is stored and executes the attack payload.

3. The method of claim 2, wherein the Windows application-oriented vulnerability verification code automatic migration method is characterized in that, In step S3, the failure reason for executing the vulnerability verification on the cross-version Windows application is identified through the vulnerability exploitation strategy, specifically including: After the buffer overflow, the expected address of the trampoline instruction is not filled in the EIP position, and the reason is that the stack memory layout changes, the stack frame length changes, and the filling content length is not equal to the stack frame length.

4. The method of claim 3, wherein the Windows application-oriented vulnerability verification code automatic migration method is characterized in that, In step S3, the failure reason for executing the vulnerability verification on the cross-version Windows application is identified through the vulnerability exploitation strategy, specifically including: After the EIP overwrite, the instruction at the EIP position is not successfully executed, and the reason is that the GS mitigation mechanism is deployed, and the program checks the Security Cookie value in the stack frame when returning from a function, and the Security Cookie value is changed in the case of stack overflow.

5. The method of claim 4, wherein the Windows application-oriented vulnerability verification code automatic migration method is characterized in that, In step S3, the failure reason of performing vulnerability verification on the cross-version Windows application is identified through the vulnerability exploitation strategy, specifically including: After performing the EIP override, the instruction at the EIP location is not successfully executed, and the reason is that the safeSEH mitigation mechanism is deployed, and the program checks the address of the called function, and the address of the trampoline instruction is disabled.

6. The method of claim 5, wherein the Windows application-oriented vulnerability verification code automatic migration method is characterized in that, In step S3, the failure reason of performing vulnerability verification on the cross-version Windows application is identified through the vulnerability exploitation strategy, specifically including: During the execution of the trampoline instruction, the control flow of the program cannot be intercepted to the attack payload execution phase, and the reason is that the address of the trampoline instruction changes.

7. A system for automatic migration of vulnerability verification code for Windows application, characterized in that, The system comprises a processing unit configured to perform: Execute the vulnerability verification code of the original version on the cross-version Windows application, track the execution process using dynamic instrumentation technology; Based on the behaviors in the vulnerability verification process obtained by tracking, a vulnerability exploitation strategy model is established to generate a vulnerability exploitation strategy; Extract the stage that triggers the crash in the vulnerability verification process, and identify the failure reason of performing vulnerability verification on the cross-version Windows application through the vulnerability exploitation strategy; Based on the failure reason, modify the vulnerability verification code of the original version, thereby generating the vulnerability verification code of the target version through automatic migration; Wherein, the modification of the vulnerability verification code of the original version specifically includes: For the case of stack memory layout change, by generating a deterministic test template and analyzing the crash characteristics, a mapping relationship between versions is constructed, and a string matching technology is used to locate and replace the key parameters in the vulnerability exploitation code; For the case of deploying mitigation mechanisms, by analyzing the metadata characteristics of the binary file, identifying unprotected system components, and constructing a library of exploitable instructions, semantic bypass of the newly added security mechanisms is achieved; For the case of address change of the trampoline instruction, a dynamic execution trace comparison and function equivalence matching strategy is adopted, key memory operation semantic features in the execution process of the reference version are extracted, a mapping relationship of equivalent instructions in the target version is constructed, and an instruction address updating mechanism based on semantic consistency is formed.

Images