Method for exploiting vulnerabilities in program execution processes based on hardware virtualization

Abstract

The application discloses a program execution process vulnerability mining method based on hardware virtualization, which interferes with, varies and monitors the intermediate state data of runtime without interrupting the normal program execution process, so that the test process is not limited to the program entry point or the final output result, but can be deep into the function call chain, the intermediate variable assignment, the state machine transition and the memory structure change and other key positions, so that more granular and targeted testing is realized. The application can significantly improve the coverage range and vulnerability mining capability of the test, and is especially suitable for analyzing highly complex and state-dependent modern software systems.

Description

Technical Field

[0001] This invention belongs to the field of testing technology, specifically relating to a method for discovering vulnerabilities in the program execution process based on hardware virtualization. Background Technology

[0002] Software vulnerabilities are one of the main threats to system security, and current software vulnerability discovery is primarily based on fuzzing methods. Fuzzing is a key method for discovering vulnerabilities in the field of software security. Its core idea is to input a large amount of constructed, random, or semi-random data into a program in order to trigger abnormal behavior (such as crashes, memory leaks, or logical errors), thereby discovering potential security vulnerabilities.

[0003] Current fuzzing methods primarily target the initial input of a program, including files and network packets. This section uses file-based input fuzzing as an example to illustrate its basic principles. This method involves fuzzing programs that take files as input (such as image parsers, audio / video decoders, and PDF readers). The input to these programs is often a structured file format. By mutating or generating files in a specific format, automated testing is performed on programs that rely on file parsing, thereby discovering vulnerabilities in the parsing process.

[0004] The basic principle is that the program processes data by reading files, therefore the fuzz testing process is as follows: 1. Prepare a set of legal torrent files (such as legal PNG, PDF, MP4, etc.).

[0005] 2. Mutate the file to generate a new test sample.

[0006] 3. Have the program read these mutated files and monitor their behavior (crashes, hangs, unauthorized access, etc.).

[0007] 4. Record which inputs triggered new code paths or caused exceptions, as the basis for subsequent mutations.

[0008] 5. Return to step 2 to generate further samples and test whether any anomalies have occurred in the data.

[0009] The core implementation of AFL (American Fuzzy Lop) revolves around one goal: to leverage coverage feedback to guide the fuzzing process, thereby efficiently discovering vulnerabilities in a program. Its success lies in its high-performance, low-cost instrumentation method and efficient input mutation strategy.

[0010] Figure 1 This is the schematic diagram of AFL.

[0011] As shown in Table 1, the AFL workflow can be divided into the following core modules: Table 1

[0012] Instrumentation (code coverage tracing): It uses a global shared memory area to record "path hashes" and track edge coverage, recording not only which blocks were executed, but also from which block to which block.

[0013] Mutation Engine: AFL's mutation engine continuously mutates samples, attempting to trigger new code paths.

[0014] Coverage Feedback and Queue Management Each time AFL runs a sample, it records the hash of the execution path and determines whether the path is new (whether it brings new edge coverage). If it is a new path, the sample is added to the seed queue. This allows for priority exploration of "unknown paths" and improves fuzzing efficiency.

[0015] Existing fuzzing techniques typically use external input interfaces of a program (such as command-line arguments, environment variables, file input, or network data) as input points, triggering different execution paths by mutating these external inputs. However, this approach has significant limitations: input data can only be injected from the program's entry point, lacking direct control over the program's internal execution state, and making it difficult to delve into the program's intermediate logic and critical functions for detailed testing.

[0016] Specifically, because data cannot be directly injected into the function entry point or specific memory state of the intermediate process, it is impossible to precisely construct specific conditions to trigger abnormal behavior of deeply nested paths, boundary handling logic, or internal state machines. This not only limits the improvement of coverage but also reduces the possibility of discovering deep logic vulnerabilities (such as memory overflow, state inconsistency, or privilege circumvention). Therefore, existing technologies have limited fuzzing effectiveness, low efficiency, and a high risk of omissions when dealing with complex software, deep function call chains, or programs with strong state dependencies. Summary of the Invention

[0017] To overcome the shortcomings of existing technologies, this invention provides a method for vulnerability discovery during program execution based on hardware virtualization. This method, without interrupting the normal program execution flow, interferes with, mutates, and monitors intermediate state data during runtime. This allows the testing process to extend beyond the program entry point or final output, delving into key locations such as function call chains, intermediate variable assignments, state machine transitions, and memory structure changes, enabling more granular and targeted testing. This invention significantly improves the coverage and vulnerability discovery capabilities of testing, and is particularly suitable for analyzing highly complex, state-dependent modern software systems.

[0018] The technical solution adopted by this invention to solve its technical problem is as follows: Step 1: Extract the function call relationships of the target binary program; Step 2: Run the process-level virtual machine and name it BaseLine; Step 3: Load the target binary program using the BaseLine virtual machine, set the entry point of the target function to be monitored, and pause the execution of the virtual machine; Step 4: Based on the suspended Baseline virtual machine, a new virtual machine is created using the Linux system's fork call. This virtual machine is named Target, and fuzz data is generated. At this point, the Target virtual machine is in the same state as the Baseline virtual machine, both being suspended. Step 5: Based on the fuzz data, modify the part of the binary program memory of the target function in the Target virtual machine that is related to the function to be monitored; Step 6: Resume the Target virtual machine running and monitor whether the target binary program has crashed. If so, proceed to Step 7; otherwise, wait for the Target virtual machine to finish executing and exit, then return to Step 4. Step 7: Output the crash information and return to step 4.

[0019] Preferably, the process-level virtual machine is the QEMU usermode virtual machine.

[0020] Preferably, in step 1, IDA Pro, Ghidra, or Radare2 tools are used to extract function call relationships.

[0021] Preferably, the new virtual machine forked in step 4 is used to isolate the execution of fuzzing input.

[0022] Preferably, in step 5, the part of the memory of the target binary program in the virtual machine related to the function to be monitored is modified by overwriting memory or files.

[0023] Preferably, the virtual machine in steps 1 to 7 is replaced with a system-level debugger.

[0024] Preferably, the system-level debugger is GDB or WinDbg.

[0025] An electronic device includes: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the electronic device performs the above-described method for detecting vulnerabilities in the program execution process.

[0026] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned method for discovering vulnerabilities in the program execution process.

[0027] A chip includes a processor for retrieving and running a computer program from a memory, causing a device equipped with the chip to execute the aforementioned program execution process vulnerability discovery method.

[0028] A computer program product includes a computer storage medium storing a computer program, the computer program including instructions executable by at least one processor, wherein when the instructions are executed by the at least one processor, the above-described method for detecting vulnerabilities in the program execution process is implemented.

[0029] The beneficial effects of this invention are as follows: This invention provides a fuzz testing method for the intermediate process and internal data state of user-mode program execution, aiming to break through the limitations of traditional fuzz testing which is limited to the program input and output level, and expand the test coverage to the intermediate state, internal variables and key logic paths of the program during runtime.

[0030] The core idea of ​​this method is to construct an execution monitoring mechanism with intermediate state awareness capabilities to observe, intervene at specific points, and perform targeted mutation operations on intermediate variables, data structures, and control states of user-mode programs during execution in real time. Instrumentation is performed without interrupting the overall program execution flow, enabling fuzz testing to extend beyond the initial input to all stages of program execution, particularly key internal points such as critical function entry points, state transition nodes, loop conditions, and buffer write locations.

[0031] Specifically, this method includes, but is not limited to, the following innovative aspects: Intermediate state data location and extraction: Through static analysis and dynamic instrumentation techniques, key intermediate variables, internal data structures and state control points involved in program execution are automatically identified; Runtime interference and mutation mechanism: Without interrupting the main program logic, perform targeted mutation or perturbation on intermediate data to simulate abnormal or boundary scenarios; Crash and Abnormal Behavior Capture Mechanism: Enhances the ability to detect program crashes, logical errors, or security vulnerabilities caused by intermediate state interference, improving the depth and breadth of vulnerability discovery.

[0032] This invention achieves high-granularity test control over the intermediate processes of program execution without affecting the normal operation logic, thereby enabling deeper and more refined fuzzing testing. Compared with traditional fuzzing methods based on external input, this invention can significantly improve the test coverage and vulnerability discovery capabilities, and is especially suitable for analyzing highly complex modern software systems with strong state dependencies. Attached Figure Description

[0033] Figure 1 This is the schematic diagram of AFL; Figure 2 This is a flowchart of the method of the present invention; Figure 3 This is a flowchart of the testing method for binutils according to an embodiment of the present invention. Detailed Implementation

[0034] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0035] This invention aims to address the problem that existing fuzz testing techniques primarily focus on the program input or output layer, making it difficult to effectively cover the intermediate states and related data during program execution. Existing fuzzing methods generally rely on variations in external program inputs (such as command-line arguments, file inputs, network data, etc.) and evaluate test effectiveness based on the overall program execution results (such as crash information, abnormal behavior, or code coverage). While this approach is suitable for covering shallow logic and simple paths, its coverage and vulnerability discovery capabilities are significantly insufficient when facing programs with complex control flows, deeply nested call relationships, or internal state dependencies.

[0036] Specifically, traditional fuzzing testing methods struggle to effectively reach dynamically generated intermediate data structures, state transitions, or critical intermediate variables within the program's execution path. These intermediate states often play a decisive role in the program's deep-seated logic, directly impacting security and correctness. However, because they cannot be directly controlled by external input, existing methods struggle to precisely construct triggering conditions, resulting in limited test coverage and the potential omission of deep-seated logical flaws, security vulnerabilities, or boundary errors.

[0037] To address this, this invention proposes a fuzzy testing method for the intermediate processes and internal data states of program execution. This method, without interrupting the normal execution flow of the program, interferes with, mutates, and monitors the intermediate state data during runtime. This allows the testing process to extend beyond the program entry point or final output, delving into key locations such as function call chains, intermediate variable assignments, state machine transitions, and changes in memory structure, thus achieving more granular and targeted testing.

[0038] Compared with traditional methods, the present invention has the following significant advantages: 1. Covering deeper execution paths: It can guide the program to trigger deep logic branches that are usually difficult to reach; 2. Enhance vulnerability discovery capabilities: Enable the uncovering of security vulnerabilities and boundary condition errors that are difficult to cover using traditional methods; 3. Strong compatibility and non-intrusiveness: It can be embedded and executed without modifying the source code or interrupting the main logic flow of the program.

[0039] In summary, this invention, while ensuring the normal operation of the program, achieves efficient fuzz testing of the intermediate process of the program, significantly improving the depth, breadth and efficiency of testing, and providing stronger technical support for software security verification and high-quality assurance.

[0040] The overall process of this invention is as follows: Figure 2 As shown.

[0041] The specific process of this invention is as follows: Step 1: Analyze the binary program (target binary program) to be exploited and extract its function call relationships.

[0042] Step 2: Run the virtual machine and name it BaseLine.

[0043] Step 3: Have BaseLine load the target binary program using a virtual machine, set the function entry point to be monitored, and pause the virtual machine.

[0044] Step 4: Using the Baseline virtual machine, a new virtual machine named Target is created through the Linux fork call, generating fuzz data, and then proceeding to Step 5.

[0045] Step 5: Based on the fuzz data, modify the part of the memory of the target binary program in the Target virtual machine that is related to the function to be monitored.

[0046] Step 6: Restore the Target virtual machine to operation and monitor whether the target binary program has crashed. If so, proceed to Step 7; otherwise, wait for the target program in the Target virtual machine to exit normally, then exit the Target virtual machine and return to Step 4.

[0047] Step 7: Output the crash information and return to step 4.

[0048] This operation mode is interrupted and exits the fuzz test loop by the user pressing Ctrl+C. Without the user's Ctrl+C command, it continuously loops copying the virtual machine, generating fuzz data, and monitoring for crashes.

[0049] Example: We will use the binary analysis tool binutils to analyze specific instances.

[0050] (1) The flowchart of the embodiment is as follows Figure 3 As shown.

[0051] (2) The detailed implementation process of the technical solution in the embodiment is as follows: Step 1: Analyze the target program (binutils); Static analysis of target tools (such as objdump) in binutils: Use tools such as IDA Pro, Ghidra, and Radare2 to extract function call graphs to represent the call relationships between functions. Identify the key input processing functions (e.g., bfd_check_format, bfd_openr, bfd_get_section_by_name, etc.). Select the target function as the entry point for fuzzing (e.g., file loading or parsing logic); The goal is to identify functions that are susceptible to abnormal input as the starting point for fuzzing.

[0052] Step 2: Start the virtual machine; Start the BaseLine virtual machine and run it in a monitorable, snapshot-recoverable mode; Step 3: Start the target program and set monitoring points; Set interrupts or breakpoints at the entry points of functions such as bfd_check_format() and bfd_open(); Step 4: Fork the Target virtual machine from the Baseline virtual machine and generate fuzz data; Use a custom fuzzing tool to generate binary input; The Target virtual machine is used to isolate the execution of fuzzing input, ensuring that the current input is only relevant to the currently running instance; Data is generated by the data generator and then injected.

[0053] Step 5: Memory modification and input injection; The fuzz data is passed to the Target virtual machine via shared memory, NFS, virtio, or QEMU file mapping mechanism; Modify the data structures processed by the target function within the Target virtual machine by overwriting memory or files; Step 6: Execution and crash monitoring; Restore the Target virtual machine to operation; Monitor whether the target program crashes (Segfault, Abort, ASAN reports, etc.); If no crash occurs, wait for the program in the Target virtual machine to exit, then exit the Target virtual machine and return to step 4 to continue fuzzing; If a crash is detected, proceed to step 7.

[0054] Step 7: Record the crash information and return to the fuzz loop; Save crash input, runtime logs, and program state (such as stack, registers, and call stack). Use tools (such as gdb, ASAN, valgrind) to collect detailed crash traces; Return to step 4 to continue the fuzzing process.

[0055] Alternative technical solutions that may exist for this invention are as follows: 1. The user-mode virtual machine (such as QEMU User Mode) used in this invention is replaced with a system-level debugger (such as GDB, WinDbg, etc.) as the execution monitoring and control tool. By utilizing the breakpoint setting, memory access, register reading, and single-step execution capabilities provided by the debugger, accurate observation and feedback collection of the running status of the program under test can be achieved without relying on virtualization technology, thereby supporting debugger-based fuzzing methods.

[0056] 2. Replace the user-space virtual machine (e.g., QEMU User Mode) used in this invention with other user-space virtualization execution environments with similar functions, such as Unicorn, Renode, or other lightweight virtual machines that support user-space program execution. These alternatives can also be used to isolate execution input samples and collect runtime information to achieve the path coverage, state monitoring, and anomaly detection functions required for fuzzing, while providing greater portability and flexibility across different platforms and architectures.

Claims

1. A method for vulnerability discovery in program execution based on hardware virtualization, characterized in that, Includes the following steps: Step 1: Extract the function call relationships of the target binary program; Step 2: Run the process-level virtual machine and name it BaseLine; Step 3: Load the target binary program using the BaseLine virtual machine, set the entry point of the target function to be monitored, and pause the execution of the virtual machine; Step 4: Based on the suspended Baseline virtual machine, a new virtual machine is created using the Linux system's fork call. This virtual machine is named Target, and fuzz data is generated. At this point, the Target virtual machine is in the same state as the Baseline virtual machine, both being suspended. Step 5: Based on the fuzz data, modify the part of the binary program memory of the target function in the Target virtual machine that is related to the function to be monitored; Step 6: Restore the Target virtual machine to operation and monitor whether the target binary program has crashed. If so, proceed to Step 7. Otherwise, wait for the Target virtual machine to finish executing and exit, then return to step 4; Step 7: Output the crash information and return to step 4.

2. The method for discovering vulnerabilities in the program execution process based on hardware virtualization according to claim 1, characterized in that, The process-level virtual machine is the QEMU usermode virtual machine.

3. The method for vulnerability discovery in program execution based on hardware virtualization according to claim 1, characterized in that, In step 1, IDA Pro, Ghidra, and Radare2 tools are used to extract function call relationships.

4. The method for vulnerability discovery in program execution based on hardware virtualization according to claim 1, characterized in that, The new virtual machine forked in step 4 is used to isolate the execution of fuzzing input.

5. The method for vulnerability discovery in program execution based on hardware virtualization according to claim 1, characterized in that, In step 5, the part of the memory of the target binary program in the virtual machine that is related to the function to be monitored is modified by overwriting memory or files.

6. The method for vulnerability discovery in program execution based on hardware virtualization according to claim 1, characterized in that, The virtual machine in steps 1 to 7 is replaced with a system-level debugger.

7. The method for vulnerability discovery in program execution based on hardware virtualization according to claim 1, characterized in that, The system-level debugger is GDB or WinDbg.

8. An electronic device, characterized in that, include: Processor and memory; The memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

10. A chip, characterized in that, include: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1 to 7.

Images