GUI program fuzz testing method, system, computer device and storage medium

Abstract

The present invention discloses a GUI program fuzz testing method, system, computer device, and storage medium. The method first designs a hypercall interface for a KVM virtual machine, then designs a QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface. A code library encapsulating the call number and corresponding function code is compiled for external calls. The code library is injected into a target GUI program. A Windows proxy layer is created under a Windows system, and fuzz testing of the target GUI program is performed through the Windows proxy layer. A Linux proxy layer is created under a Linux system, and fuzz testing of the target GUI program is performed through the Linux proxy layer. This method can expand the scope of GUI program fuzz testing and accelerate the speed of GUI program fuzz testing.

Description

Technical Field

[0001] The present invention relates to the field of fuzz testing technology, and in particular to a GUI program fuzz testing method, system, computer equipment and storage medium. Background Art

[0002] Fuzz testing is an automated dynamic testing technique that focuses on discovering vulnerabilities in various software under test, thereby improving its security and robustness. The software under test can be: 1) Applications, including various types of applications such as desktop applications, mobile applications, and web applications; 2) Libraries, including libraries, modules, or components for reusable software development; 3) Operating systems, including testing of the operating system kernel, system calls, or other system-level functions; 4) Protocols, including implementations of network protocols, communication protocols, or other protocols; 5) File formats, including parsers, handlers, or read / write operations for various file formats; 6) Drivers, including hardware drivers, kernel modules, or other system-level programs; 7) Data structures, including testing of data structure handlers, algorithms, or parsers; 8) APIs, including testing of API usage and parameter input processing. By inputting randomly generated invalid or unexpected data into the software under test and dynamically monitoring whether program execution triggers exceptions, fuzz testing can effectively trigger potential errors and vulnerabilities in the software under test, helping developers identify security risks. With the use of various program analysis techniques, such as control flow analysis, data flow analysis, symbolic execution, and taint analysis, a large number of fuzz testing projects have been spawned.

[0003] However, with the increasing complexity of software functionality and structure, traditional single-task fuzz testing can no longer meet the demand for real-time test results. Consequently, researchers have gradually turned to parallel fuzzing approaches to improve testing efficiency per unit time. Representative projects include Google's Oss-Fuzz, Microsoft's OneFuzz, CollabFuzz, and EnFuzz. These approaches typically rely on the inherent parallelization capabilities of existing fuzzing engines (such as AFL, LibFuzzer, and honggfuzz), enabling testing collaboration among multiple parallel nodes through a shared seed directory. While parallel fuzzing has improved testing efficiency to some extent, it still faces numerous challenges. First, the lack of effective synchronization mechanisms between different fuzzing engines leads to resource waste and reduced testing efficiency. Second, existing fuzzing engines are typically optimized for specific platforms (such as specific operating systems or programming languages), lacking generalizability and cross-platform support. Third, most parallelization schemes are limited to a few basic fuzzing engines and often rely on crude heuristics when selecting fuzzing engines, resulting in limited room for improvement in testing efficiency and resource utilization.

[0004] Despite a surge in research on improving fuzz testing performance, effectively integrating multiple fuzz testing engines for parallel fuzz testing remains a pressing challenge. To address this challenge, building an efficient parallel architecture that can adapt existing fuzz testing engines for parallelization is crucial. This approach allows fuzz testing engines to run in parallel across platforms and supports finer-grained data synchronization and resource management, thereby improving the overall efficiency of parallel fuzz testing. Summary of the Invention

[0005] In response to the above problems, the present invention proposes a GUI program fuzz testing method, system, computer device and storage medium, which use snapshot and end point related technologies to support efficient fuzz testing of GUI programs.

[0006] On one hand, the present invention provides a GUI program fuzz testing method, comprising the following steps:

[0007] S1. Design the hypercall interface of the KVM virtual machine to transmit control instructions between the virtual machine monitor layer and the virtual machine;

[0008] S2. Design a QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging and code tracking configuration, to achieve dynamic monitoring of virtual machine status and efficient processing of test cases;

[0009] S3. Create a Windows proxy layer under the Windows system, hijack system calls by dynamically injecting code libraries, and use flag files to trigger the fuzz testing process to achieve dynamic testing and monitoring of the target GUI program;

[0010] S4. Create a Linux proxy layer under the Linux system, develop a control panel program, create an eBPF program to monitor file operations, hijack system calls and combine it with a dynamic injection hook library to implement fuzz testing of the target GUI program.

[0011] Preferably, the specific process of S2 is as follows:

[0012] S21, KVM and QEMU perform initialization confirmation and obtain fuzz testing snapshot;

[0013] S22, notify KVM and QEMU to restore the virtual machine state using the fuzz test snapshot;

[0014] S23. Receive a memory address specified by the virtual machine to write a test case, where the input parameter is a structure pointer containing the test case size and data;

[0015] S24. Query the host QEMU configuration information and submit the agent configuration information, wherein the host configuration information includes the buffer size and coverage bitmap parameters, and the agent configuration information includes the timeout period and coverage collection method;

[0016] S25, reporting the discovered software crash or other error event to the host, causing QEMU to stop the virtual machine;

[0017] S26. Send the pointer to the C string in the virtual machine to QEMU, and QEMU reads and prints or records the content to form a log record and a debug record;

[0018] S27. Configure the code address range for Intel PT tracing.

[0019] S28, specifying that the target program to be tested on the host is 32-bit code or 64-bit code;

[0020] S29. QEMU terminates the fuzz testing process.

[0021] Preferably, S3 specifically includes the following:

[0022] S31. Develop a window picker to obtain the target GUI program's process information through the graphical interface and inject the frida script;

[0023] S32, a code library that encapsulates the hypercall function for external calls;

[0024] S33. Write a frida script to inject into the code library and hijack the NtCreateFile function to start fuzz testing when a flag file is detected.

[0025] Preferably, S33 specifically includes the following:

[0026] S331, injecting the code library into the target GUI program;

[0027] S332. Intercept the call to the NtCreateFile function in the Windows system library and create a stub code;

[0028] S333. Determine, through the stub code, whether the file to be opened by the NtCreateFile function is a flag file for starting a snapshot. The file to be opened by the NtCreateFile function includes a file automatically generated by the target GUI program when the program is running, or a flag file provided by the system for identifying a startup snapshot.

[0029] S334. If the file to be opened by the NtCreateFile function is a flag file for starting a snapshot, the API in the code library is called to start the fuzz testing process of the target GUI program.

[0030] Preferably, S4 specifically includes the following:

[0031] S41. Develop a control panel program, the control panel program being used to display information of the target GUI program and provide interactive controls;

[0032] S42. Create an eBPF program. The eBPF program is used to monitor the opening operation of a specified file and suspend the target process, and resume operation after obtaining stack information.

[0033] S43. Start the eBPF program through the control panel program, obtain program-related information for opening the user-specified file, wait for the eBPF program to finish running, and display the relevant information on the corresponding control of the control panel;

[0034] S44, the user selects a stack entry as the target to be tested and selects the end point of the function to be tested;

[0035] S45. The user clicks the start button of the control panel program, and the control panel writes the program path, target file, and end point information into the configuration file;

[0036] S46. Develop a hook library based on the frida-gum library, use the ld.reload mechanism provided by the Linux system for global injection, hijack the __openat function and trigger the fuzz test when the target file is detected, and call the RELEASE hypercall reset test at the end point.

[0037] Preferably, in S42, an eBPF program is created, and the specific process is as follows:

[0038] S421. Create an openat system call program to intercept the call of the openat kernel function in the Linux system. Before running, determine whether the file to be opened specified by the openat kernel function is the target file. If it is, execute S422; otherwise, execute S426;

[0039] S422: Pause the openat system call program and return the relevant information of the openat system call program to the eBPF user layer.

[0040] S423. The eBPF user layer uses the lldb debugger to obtain the stack information of the suspended calling program.

[0041] S424: Resume the target GUI program until the target process ends, and then uninstall the eBPF program running in the Linux system from the kernel.

[0042] S425, write the program path and the obtained stack information into a file, and terminate the operation;

[0043] S426. The operating system continues to execute normally without any interruption or other special operations.

[0044] Preferably, S46 specifically includes the following:

[0045] S461, loading the dynamic library where the end point in the configuration file is located;

[0046] S462, hook __openat function, run the stub code created in S332 before the __openat function runs;

[0047] S463, judging through the stub code whether the file to be opened by the __openat function is the file specified by the user in the configuration file;

[0048] S464: If the file to be opened by the __opena function is a file specified by the user in the configuration file, call the API in the code library to start the fuzz testing process;

[0049] S465, the hook library obtains the dynamic library loading address and calculates the actual memory address of the program end point based on the dynamic library loading address and the code offset;

[0050] S466. Install hook code at the actual memory address of the program end point to directly call the RELEASE super call in the code library, end this test, and start the next test.

[0051] GUI program fuzz testing system, including hypercall interface design module, virtual machine monitor design module, Windows proxy layer creation module and Linux proxy layer creation module;

[0052] Hypercall interface design module, which designs the hypercall interface of the KVM virtual machine, used to transmit control instructions between the virtual machine monitor layer and the virtual machine;

[0053] The virtual machine monitor design module designs the QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging and code tracking configuration, to achieve dynamic monitoring of virtual machine status and efficient processing of test cases;

[0054] Windows proxy layer creation module, which creates a Windows proxy layer under the Windows system, hijacks system calls by dynamically injecting code libraries, and uses flag files to trigger the fuzz testing process to achieve dynamic testing and monitoring of the target GUI program;

[0055] The Linux proxy layer creation module creates a Linux proxy layer under the Linux system. By developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls and combining it with a dynamic injection hook library, it implements fuzz testing of the target GUI program.

[0056] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein the processor implements the steps of the above-mentioned GUI program fuzzy testing method when executing the computer program.

[0057] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned GUI program fuzzy testing method are implemented.

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

[0059] 1) Expanding the scope of fuzz testing: Traditional gray-box fuzz testing tools can only test programs that automatically exit after completing their function, such as common Linux commands like cat and ls. GUI programs generally do not automatically exit, making these tools inappropriate. This invention, by finding the end point of the GUI program under test and actively terminating the process when it reaches that point, allows the fuzz testing tool to continue running.

[0060] 2) Accelerated fuzz testing: Traditional gray-box fuzz testing tools perform a test by starting a new process. GUI programs normally take some time to start (drawing the UI is time-consuming, and most programs create multiple threads to avoid blocking). The technical solution of the present invention takes a snapshot before the tested function runs and restores the snapshot after the tested function runs, thus avoiding the ineffective time occupied by program process creation. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 This is a flow chart of a GUI program fuzz testing method according to one embodiment of the present invention;

[0062] Figure 2 This is a general architecture diagram of a GUI program fuzz testing method according to one embodiment of the present invention;

[0063] Figure 3 This is a timing diagram of user operations for initiating GUI program fuzz testing through a Windows system in one embodiment of the present invention;

[0064] Figure 4 This is a timing diagram of user operations for starting a GUI program fuzz test through a Linux system in one embodiment of the present invention;

[0065] Figure 5 It is a schematic block diagram of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0066] In order to enable those skilled in the art to better understand the technical solution of the present invention, the present invention is further described in detail below with reference to the accompanying drawings.

[0067] In one embodiment, see Figure 1 and Figure 2 A GUI (Graphical User Interface) program fuzz testing method includes the following steps:

[0068] S1. Design the hypercall interface of KVM (Kernel-based Virtual Machine) to transfer control instructions between the virtual machine monitor layer and the virtual machine.

[0069] Specifically, a hypercall interface is designed for fuzz testing. The main function of the hypercall interface is to assist in fuzz testing in KVM / QEMU and libsnap libraries.

[0070] S2. Design QEMU (Quick EMUlator, an open source virtual machine monitor and emulator) to respond to the call number and corresponding function code of the KVM hypercall interface, and encapsulate the call number and corresponding function code into a function code identifier, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging and code tracking configuration, to achieve dynamic monitoring of virtual machine status and efficient processing of test cases.

[0071] Host QEMU is a software package that includes a virtual machine monitor and emulator. The host QEMU manages the emulator's operations through the virtual machine monitor, providing virtualization capabilities. The emulator simulates hardware devices, enabling virtual machines to run different operating systems. The QEMU designed in S2 responds to the call number and corresponding function code of the KVM hypercall interface, specifically the call number and function code used to trigger the fast snapshot recovery mechanism. These call numbers and function codes are encapsulated into a function code identifier. External programs can call the function code identifier through the hypercall interface to instruct QEMU to perform a fast virtual machine image recovery operation.

[0072] In one embodiment, the specific process of S2 is as follows:

[0073] S21, KVM and QEMU perform initialization confirmation and obtain fuzz testing snapshot;

[0074] S22, notify KVM and QEMU to restore the virtual machine state using the fuzz test snapshot;

[0075] S23. Receive a memory address specified by the virtual machine to write a test case, where the input parameter is a structure pointer containing the test case size and data;

[0076] S24. Query the host QEMU configuration information and submit the agent configuration information, wherein the host configuration information includes the buffer size and coverage bitmap parameters, and the agent configuration information includes the timeout period and coverage collection method;

[0077] S25, reporting the discovered software crash or other error event to the host, causing QEMU to stop the virtual machine;

[0078] S26. Send the pointer to the C string in the virtual machine to QEMU, and QEMU reads and prints or records the content to form a log record and a debug record;

[0079] S27. Configure the code address range for Intel PT tracing.

[0080] S28, specifying that the target program to be tested on the host is 32-bit code or 64-bit code;

[0081] S29. QEMU terminates the fuzz testing process.

[0082] Specifically, the function code identifiers include the following:

[0083] 1) Handshake: used for KVM and QEMU to confirm each other;

[0084] 2) ACQUIRE: used to obtain fuzz testing snapshots;

[0085] 3) RELEASE: used to notify KVM and QEMU to restore the virtual machine state using the previously obtained snapshot;

[0086] 4) GET_PAYLOAD: The code running in the virtual machine instructs QEMU by providing the memory space address

[0087] The location where the test case is written. You need to allocate a large enough memory space, the size must be an integer multiple of the page size, and ensure that the page is in resident memory.

[0088] Some of the GET_PAYLOAD function codes are as follows:

[0089] Input parameters:

[0090] typedef struct {

[0091] int32_t size; / / Store the actual size of the test case

[0092] uint8_t data[]; / / A flexible array used to store test case content, where the actual data content is stored

[0093] payload_buffer_t

[0094] payload_buffer (structure pointer): used to store the actual size and content of the test case;

[0095] 5) GET_HOST_CONFIG: used to query the host QEMU configuration, such as obtaining the size of the test case buffer.

[0096] Some function codes of GET_HOST_CONFIG are as follows:

[0097] Input parameters:

[0098] typedef struct {

[0099] uint32_t host_magic; / / host flag

[0100] uint32_t host_version; / / host version

[0101] uint32_t bitmap_size; / / Bitmap size used to store coverage information

[0102] uint32_t ijon_bitmap_size; / / ijon bitmap size

[0103] uint32_t payload_buffer_size; / / Memory size for storing test cases

[0104] uint32_t worker_id; / / fuzz testing client worker id

[0105] } host_config_t;

[0106] host_config (structure pointer): obtain the host configuration information;

[0107] 6) SET_AGENT_CONFIG: Used to submit agent configuration information, including the timeout for a single test case run and the coverage collection method.

[0108] An agent usually refers to a program or software that can perform specific tasks and collect information on behalf of users or other programs, or perform certain operations in the system. This agent program can perform tasks autonomously in a computer system and coordinate communication and interaction between different systems or programs.

[0109] Some function codes of SET_AGENT_CONFIG are as follows:

[0110] Input parameters:

[0111] typedef struct {

[0112] uint32_t agent_magic; / / Tell the host agent flag

[0113] uint32_t agent_version; / / Tell the host the agent version

[0114] uint8_t agent_timeout_detection; / / Tell the host the timeout for a single run of the test case

[0115] uint8_t agent_tracing; / / Tell the host not to use Intel pt technology for coverage collection, but to be provided by the agent

[0116] } agent_config_t;

[0117] agent_config (struct pointer): pointer to the memory where agent_config data is stored

[0118] 7) PANIC: Used to report software crashes or other error events to the host, causing QEMU to stop the virtual machine and reload the snapshot.

[0119] 8) hprintf: Sends a pointer to a C string to QEMU so that QEMU can read it and print or log the contents, typically used for logging and debugging.

[0120] Some of the hprintf function codes are as follows:

[0121] Input parameters:

[0122] str_ptr (pointer): points to the memory address of the string you want to print to the console.

[0123] 9) RANGE_SUBMIT: Used to configure the address range of INTEL PT tracking. Tracking data outside the address range will not be counted in the code coverage.

[0124] Some of the RANGE_SUBMIT function codes are as follows:

[0125] Input parameters:

[0126] typedef struct {

[0127] uint64_t start_addr; / / The starting address of the code to collect code coverage

[0128] uint64_t end_addr; / / code end address to collect code coverage

[0129] } range_t;

[0130] range (structure pointer): points to the memory address of the structure that stores the address range.

[0131] 10) USER_SUBMIT_MODE: Used to tell the host whether the target is 32-bit code or 64-bit code.

[0132] Input parameters:

[0133] mode (enumeration): can be MODE_64, MODE_32.

[0134] 11) habort: Tells QEMU to terminate the fuzzing process when an unresolvable error occurs.

[0135] S3. Create a Windows proxy layer under the Windows system, hijack system calls by dynamically injecting code libraries, and use flag files to trigger the fuzz testing process to achieve dynamic testing and monitoring of the target GUI program.

[0136] Specifically, abnormal, illegal or random input data is injected into the target GUI program through the Windows proxy layer to detect the target GUI program's ability to process these inputs, thereby discovering potential vulnerabilities.

[0137] Furthermore, S3 specifically includes the following:

[0138] S31. Develop a window picker to obtain the process information of the target GUI program through the graphical interface and inject the frida script.

[0139] Specifically, a window picker with a button is written. Its function is to obtain the process information of the target GUI program to be tested, such as the target GUI program's window name and process ID, by dragging the window picker. By clicking the window picker button, the frida process (a tool for tracking and hijacking functions) is launched. The JavaScript script in the default location is injected into the frida process specified by the window picker. JavaScript is a lightweight scripting language commonly used in web development and dynamic web page interaction.

[0140] S32. A code library that encapsulates the hypercall function for external calls.

[0141] Specifically, write a code library (assuming the code library name is libsnap) that encapsulates the function number in step S2 for external calling.

[0142] S33. Write a frida script to inject into the code library and hijack the NtCreateFile function to start fuzz testing when a flag file is detected.

[0143] Specifically, the frida injection script is a JavaScript script that is executed in the frida process. The frida injection script that interacts with the window picker can interact with the buttons in the window picker to perform the required functions.

[0144] Furthermore, S33 specifically includes the following:

[0145] S331, inject the code library libsnap into the target GUI program;

[0146] S332. Intercept the call to the Windows system library NtCreateFile function and create a stub code.

[0147] S333. Determine, through the stub code, whether the file to be opened by the NtCreateFile function is a flag file for starting a snapshot. The file to be opened by the NtCreateFile function includes a file automatically generated by the target GUI program when the program is running, or a flag file provided by the system for identifying a startup snapshot.

[0148] S334: If the file to be opened by the NtCreateFile function is a flag file for starting a snapshot, the API (Application Programming Interface) in the code library libsnap is called to start the fuzz testing process of the target GUI program.

[0149] It should be noted that if the file to be opened by the NtCreateFile function is not the flag file for starting the snapshot, the fuzz testing process of the target GUI program will not be started.

[0150] like Figure 3 As shown, the fuzz testing process begins with the user launching the program under test through a target selector, typically running it in debug mode or attaching it to an existing process. The user then selects a specific target to monitor (such as the system call NtCreateFile) and obtains runtime information about the program (such as its memory layout). Through code injection techniques (such as DLL injection or debugger modification), a custom hook is implanted into the target process to intercept key operations. After installing the NtCreateFile hook, the program is triggered to open a flag file to verify the interception effect. Finally, the core fuzz testing phase begins: mutated files are automatically generated as input and dynamically passed to the target program for execution. Anomalies such as crashes and memory errors are monitored in real time, and test cases that trigger vulnerabilities are recorded. The entire process combines dynamic injection with automated testing to uncover potential vulnerabilities in software such as file parsers.

[0151] S4. Create a Linux proxy layer under the Linux system, develop a control panel program, create an eBPF program to monitor file operations, hijack system calls and combine it with a dynamic injection hook library to implement fuzz testing of the target GUI program.

[0152] Abnormal, illegal or random input data is injected into the target GUI program through the Linux proxy layer to detect the target GUI program's ability to process these inputs, thereby discovering potential vulnerabilities.

[0153] Furthermore, S4 specifically includes the following:

[0154] S41. Develop a control panel program, which is used to display information of the target GUI program and provide interactive controls.

[0155] Specifically, the control panel program can display information of the target GUI program to be tested, such as the program file name, process number, etc. The control panel program includes a start file monitoring button, a start fuzz testing button, and a drop-down list for displaying stack information.

[0156] S42. Create an eBPF program. The eBPF program is used to monitor the opening operation of the specified file and suspend the target process, and resume the operation after obtaining the stack information.

[0157] Furthermore, in S42, an eBPF program is created. The specific process is as follows:

[0158] S421. Create an openat system call program to intercept the call of the openat kernel function in the Linux system. Before running, determine whether the file to be opened specified by the openat kernel function is the target file. If it is, execute S422; otherwise, execute S426;

[0159] S422: Pause the openat system call program and transmit relevant information about the openat system call program back to the eBPF user layer. The eBPF user layer specifically refers to the userspace component of Extended BPF (eBPF), which is used to process and analyze eBPF programs running in the Linux kernel. eBPF is a technology in the Linux kernel that allows users to run small programs in the Linux kernel to extend kernel functionality or analyze system behavior.

[0160] S423. The eBPF user layer uses the lldb debugger to obtain the stack information of the suspended target program. The Linux proxy layer is used for kernel behavior. The proxy layer can help user space programs communicate and work together with kernel space.

[0161] S424. Resume the operation of the target GUI program until the target process ends, and unload the eBPF program running in the Linux system from the kernel. The eBPF (Extended Berkeley Packet Filter) program is a small program running in the Linux kernel, used to extend kernel functions, monitor system behavior, and perform network packet filtering.

[0162] S425: Write the program path and the obtained stack information into a file, and terminate the operation.

[0163] S426. The operating system continues to execute normally without any interruption or other special operations.

[0164] Specifically, the openat system call is intercepted. Before the openat kernel function runs, it is determined whether the file to be opened specified by its parameters is the target file. If so, the program that calls the openat system call will be suspended, and the relevant information of the program will be passed back to the eBPF user layer. The eBPF user layer will use the lldb debugger to obtain the stack information of the target program that has been suspended. After obtaining it, the target program will be resumed until the target process ends. The eBPF program is unloaded from the kernel, and then the program path and the obtained stack information are written to the file, and finally the operation ends. If not, that is, when the target file of the openat system call is not the target file to be opened, the system should continue to execute normally without any interruption or other special operations.

[0165] S43. Start the eBPF program through the control panel program, obtain information about the program that opens the user-specified file, wait for the eBPF program to complete, and display the relevant information on the corresponding control panel. The eBPF program will continue to run to wait for possible subsequent tasks or events, and continue to monitor or process relevant data when needed. If the eBPF program is no longer needed, it needs to be manually stopped or terminated to free up resources and ensure normal operation of the system.

[0166] S44: The user selects a stack entry as a target to be tested and selects an end point of the function to be tested.

[0167] Specifically, assuming that when the program runs to the current code position, the functional code to be tested has been completed, the user clicks the drop-down list and selects a suitable stack entry in the drop-down list as the target to be tested, the end point of the function to be tested.

[0168] S45. The user clicks the start button of the control panel program, and the control panel writes the program path, target file, and endpoint information into the configuration file. The written related information includes: the executable program file name, the file specified by the user on the control panel, the dynamic library path where the program endpoint is located, and the offset of the program endpoint relative to the dynamic library's starting memory address.

[0169] S46. Develop a hook library based on the frida-gum library (assuming the hook library is named libgadget). Use the ld.reload mechanism provided by the Linux system for global injection. Hijack the __openat function and trigger fuzz testing when the target file is detected. Call the RELEASE hypercall to reset the test at the end point.

[0170] S46 specifically includes the following:

[0171] S461, loading the dynamic library where the end point in the configuration file is located;

[0172] S462, hook __openat function, run the stub code created in S332 before the __openat function runs;

[0173] S463, judging through the stub code whether the file to be opened by the __openat function is the file specified by the user in the configuration file;

[0174] S464: If the file to be opened by the __opena function is a file specified by the user in the configuration file, call the API in the code library to start the fuzz testing process;

[0175] S465, the hook library obtains the dynamic library loading address and calculates the actual memory address of the program end point based on the dynamic library loading address and the code offset;

[0176] S466. Install hook code at the actual memory address of the program end point to directly call the RELEASE super call in the code library, end this test, and start the next test.

[0177] Specifically, if Figure 4 As shown, after the user starts the target program through the control panel, he selects the file to be tested and manually opens the program to initialize the test environment. Subsequently, when the target program is running, a specific stack entry (such as a function call chain node) is selected as the test termination mark to define the monitoring scope. The user triggers the program to open the same file again, confirms the operation path, and starts the fuzz testing process: the system automatically generates a mutated file to replace the original input, dynamically executes and monitors program behavior (such as memory leaks, crashes, etc.), and records the stack status and input samples when the exception is triggered. This process combines manually preset key nodes with automated mutations to focus on the stability testing of specific code paths, and is suitable for verifying the robustness of file parsing logic.

[0178] In one embodiment, a GUI program fuzz testing system is also provided, comprising a hypercall interface design module, a virtual machine monitor design module, a Windows proxy layer creation module, and a Linux proxy layer creation module;

[0179] Hypercall interface design module, which designs the hypercall interface of the KVM virtual machine, used to transmit control instructions between the virtual machine monitor layer and the virtual machine;

[0180] The virtual machine monitor design module designs the QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging and code tracking configuration, to achieve dynamic monitoring of virtual machine status and efficient processing of test cases;

[0181] Windows proxy layer creation module, which creates a Windows proxy layer under the Windows system, hijacks system calls by dynamically injecting code libraries, and uses flag files to trigger the fuzz testing process to achieve dynamic testing and monitoring of the target GUI program;

[0182] The Linux proxy layer creation module creates a Linux proxy layer under the Linux system. By developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls and combining it with a dynamic injection hook library, it implements fuzz testing of the target GUI program.

[0183] For the specific definition of the GUI program fuzz testing system, please refer to the definition of the GUI program fuzz testing method above, which will not be repeated here. The various modules in the above-mentioned GUI program fuzz testing system can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0184] In one embodiment, a computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the above-mentioned GUI program fuzz testing method are implemented. The computer device can be any computer device such as a mobile phone, a tablet, or a mobile computer that can implement an experimental equipment detection.

[0185] In one embodiment, a computer-readable storage medium stores a computer program, which implements the steps of the above-mentioned GUI program fuzz testing method when executed by a processor.

[0186] Specifically, see Figure 5 , Figure 5 The figure is a schematic block diagram of a computer device according to an embodiment of the present invention.

[0187] The computer device 3 can be a smartphone, tablet computer, laptop computer, desktop computer, or the like that executes a program. The computer device 3 of this embodiment includes at least, but is not limited to, a memory 31, a processor 32, and a computer program 33 stored in the memory 31 and executable on the processor 32, all communicatively connected via a system bus. For example, a program corresponding to the aforementioned GUI program fuzz testing method can be used. Those skilled in the art will appreciate that the schematic diagram is merely an example of the computer device 3 and does not constitute a limitation on the computer device 3.

[0188] The memory 31 includes at least one type of readable storage medium, including flash memory, a mobile hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory), a magnetic memory, a magnetic disk, an optical disk, etc. The memory 31 can be an internal storage unit of the electronic device 1, such as a mobile hard disk of the computer device 3. The memory 31 can also be an external storage device of the computer device 3, such as a plug-in mobile hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the computer device 3. Furthermore, the memory 31 can include both an internal storage unit of the computer device 3 and an external storage device. The memory 31 can be used not only to store application software installed on the computer device 3 and various types of data, such as the program code corresponding to the aforementioned GUI program fuzz testing method, but can also be used to temporarily store data that has been output or is about to be output.

[0189] The processor 32 can be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 32 executes the operating system of the computer device 3 and various installed application programs. In this embodiment, the processor 32 executes the computer program 33 stored in the memory 31 to implement a GUI program fuzz testing method disclosed in an embodiment of the present invention.

[0190] Since the aforementioned computer device and computer-readable storage medium both include the aforementioned GUI program fuzz testing method, they also have the beneficial effects of the fuzz testing method, which will not be repeated here.

[0191] The above-mentioned GUI program fuzz testing method, system, computer device and storage medium first designs the hypercall interface of the KVM virtual machine, then designs the QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, creates a Windows proxy layer under the Windows system, and completes the fuzz testing of the target GUI program through the Windows proxy layer, and creates a Linux proxy layer under the Linux system, and completes the fuzz testing of the target GUI program through the Linux proxy layer. On the one hand, this method allows the fuzz testing tool to continue working by finding the end point of the target under test and actively ending the process when the target program runs to the end point, thereby expanding the scope of fuzz testing. On the other hand, by taking a snapshot before the function under test is run and restoring the snapshot after the function under test is run, the invalid time occupied by program process creation is avoided, thereby speeding up the fuzz testing.

[0192] The above is a detailed introduction to the GUI program fuzz testing method, system, computer device and storage medium provided by the present invention. This article uses specific examples to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the core idea of the present invention. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified. These improvements and modifications also fall within the scope of protection of the claims of the present invention.

Claims

1. A GUI program fuzz testing method, characterized in that: The method comprises the following steps: S1. Design the hypercall interface of the KVM virtual machine to transmit control instructions between the virtual machine monitor layer and the virtual machine; S2. Design a QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging, and code tracking configuration to achieve dynamic monitoring of virtual machine status and efficient processing of test cases. The specific process of S2 is as follows: S21, KVM and QEMU perform initialization confirmation and obtain fuzz testing snapshot; S22, notify KVM and QEMU to restore the virtual machine state using the fuzz test snapshot; S23. Receive a memory address specified by the virtual machine to write a test case, where the input parameter is a structure pointer containing the test case size and data; S24. Query the host QEMU configuration information and submit the agent configuration information, wherein the host configuration information includes the buffer size and coverage bitmap parameters, and the agent configuration information includes the timeout period and coverage collection method; S25, reporting the discovered software crash or other error event to the host, causing QEMU to stop the virtual machine; S26. Send the pointer to the C string in the virtual machine to QEMU, and QEMU reads and prints or records the content to form a log record and a debug record; S27. Configure the code address range for Intel PT tracing. S28, specifying that the target program to be tested on the host is 32-bit code or 64-bit code; S29, QEMU terminates the fuzz testing process; S3. Create a Windows proxy layer under the Windows system, hijack system calls by dynamically injecting code libraries, and use flag files to trigger the fuzz testing process to achieve dynamic testing and monitoring of the target GUI program; S4. Create a Linux proxy layer under the Linux system, develop a control panel program, create an eBPF program to monitor file operations, hijack system calls and combine it with a dynamic injection hook library to implement fuzz testing of the target GUI program.

2. The GUI program fuzz testing method according to claim 1, wherein: S3 specifically includes the following: S31. Develop a window picker to obtain the target GUI program's process information through the graphical interface and inject the frida script; S32, a code library that encapsulates the hypercall function for external calls; S33. Write a frida script to inject into the code library and hijack the NtCreateFile function to start fuzz testing when a flag file is detected.

3. The GUI program fuzz testing method according to claim 2, wherein: S33 specifically includes the following: S331, injecting the code library into the target GUI program; S332. Intercept the call to the NtCreateFile function in the Windows system library and create a stub code; S333. Determine, through the stub code, whether the file to be opened by the NtCreateFile function is a flag file for starting a snapshot. The file to be opened by the NtCreateFile function includes a file automatically generated by the target GUI program when the program is running, or a flag file provided by the system for identifying a startup snapshot. S334. If the file to be opened by the NtCreateFile function is a flag file for starting a snapshot, the API in the code library is called to start the fuzz testing process of the target GUI program.

4. The GUI program fuzz testing method according to claim 3, wherein: S4 specifically includes the following: S41. Develop a control panel program, the control panel program being used to display information of the target GUI program and provide interactive controls; S42. Create an eBPF program. The eBPF program is used to monitor the opening operation of a specified file and suspend the target process, and resume operation after obtaining stack information. S43. Start the eBPF program through the control panel program, obtain program-related information for opening the user-specified file, wait for the eBPF program to finish running, and display the relevant information on the corresponding control of the control panel; S44, the user selects a stack entry as the target to be tested and selects the end point of the function to be tested; S45. The user clicks the start button of the control panel program, and the control panel writes the program path, target file, and end point information into the configuration file; S46. Develop a hook library based on the frida-gum library, use the ld.reload mechanism provided by the Linux system for global injection, hijack the __openat function and trigger the fuzz test when the target file is detected, and call the RELEASE hypercall reset test at the end point.

5. The GUI program fuzz testing method according to claim 4, wherein: In S42, an eBPF program is created. The specific process is as follows: S421. Create an openat system call program to intercept the call of the openat kernel function in the Linux system. Before running, determine whether the file to be opened specified by the openat kernel function is the target file. If it is, execute S422; otherwise, execute S426; S422: Pause the openat system call program and return the relevant information of the openat system call program to the eBPF user layer. S423. The eBPF user layer uses the lldb debugger to obtain the stack information of the suspended calling program. S424: Resume the target GUI program until the target process ends, and then uninstall the eBPF program running in the Linux system from the kernel. S425, write the program path and the obtained stack information into a file, and terminate the operation; S426. The operating system continues to execute normally without any interruption or other special operations.

6. The GUI program fuzz testing method according to claim 5, wherein: S46 specifically includes the following: S461, loading the dynamic library where the end point in the configuration file is located; S462, hook __openat function, run the stub code created in S332 before the __openat function runs; S463, judging through the stub code whether the file to be opened by the __openat function is the file specified by the user in the configuration file; S464: If the file to be opened by the __opena function is a file specified by the user in the configuration file, call the API in the code library to start the fuzz testing process; S465, the hook library obtains the dynamic library loading address and calculates the actual memory address of the program end point based on the dynamic library loading address and the code offset; S466. Install hook code at the actual memory address of the program end point to directly call the RELEASE super call in the code library, end this test, and start the next test.

7. A GUI program fuzz testing system that executes the GUI program fuzz testing method according to any one of claims 1 to 6, characterized in that: Including hypercall interface design module, virtual machine monitor design module, Windows proxy layer creation module and Linux proxy layer creation module; Hypercall interface design module, which designs the hypercall interface of the KVM virtual machine, used to transmit control instructions between the virtual machine monitor layer and the virtual machine; The virtual machine monitor design module designs the QEMU virtual machine monitor to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging and code tracking configuration, to achieve dynamic monitoring of virtual machine status and efficient processing of test cases; Windows proxy layer creation module, which creates a Windows proxy layer under the Windows system, hijacks system calls by dynamically injecting code libraries, and uses flag files to trigger the fuzz testing process to achieve dynamic testing and monitoring of the target GUI program; The Linux proxy layer creation module creates a Linux proxy layer under the Linux system. By developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls and combining it with a dynamic injection hook library, it implements fuzz testing of the target GUI program.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the GUI program fuzz testing method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the GUI program fuzz testing method according to any one of claims 1 to 6 are implemented.

Images