GUI (Graphical User Interface) program fuzzing test method and system, computer equipment and storage medium

Abstract

The invention discloses a GUI (Graphical User Interface) program fuzz test method and system, computer equipment and a storage medium, and the method comprises the steps: firstly designing a hyper-call interface of a KVM (Keyboard Virtual Machine), and then designing a QEMU (Query Empirical Mode Unit) monitor for responding to a call number and a corresponding function code of the hyper-call interface of the KVM; the method comprises the following steps: writing a code library in which a call number and a corresponding function code are packaged for external call, injecting the code library into a target GUI program, creating a Windows agent layer under a Windows system, finishing a fuzzy test on the target GUI program through the Windows agent layer, creating a Linux agent layer under a Linux system, and finishing a fuzzy test on the target GUI program through the Linux agent layer. According to the method, the fuzzy test range of the GUI program can be expanded, and the fuzzy test speed of the GUI program is increased.

Description

Technical Field

[0001] The present invention relates to the technical field of fuzz testing, and in particular to a GUI program fuzz testing method, system, computer device, 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 enhancing the security and robustness of the software under test. The software under test can be: 1) application programs, including various types of application programs, such as desktop application programs, mobile application programs, Web application programs, etc.; 2) libraries, libraries, modules, or components used for reuse in software development; 3) operating systems, testing the operating system kernel, system calls, or other system-level functions; 4) protocols, implementations of network protocols, communication protocols, or other protocols; 5) file formats, parsers, handlers, or read / write operations for various file formats; 6) device drivers, hardware device drivers, kernel modules, or other system-level programs; 7) data structures, testing processing programs, algorithms, or parsers for data structures; 8) APIs, testing the usage of APIs, handling of parameter inputs, etc. By inputting randomly generated invalid or unexpected data into the software under test and dynamically monitoring whether the execution of the program triggers program 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, taint analysis, etc., a large number of fuzz testing projects have emerged.

[0003] However, with the increasing complexity of software functions and structures, traditional single-task mode fuzz testing can no longer meet the demand for real-time obtaining of test results. Therefore, researchers have gradually turned to parallel fuzz testing methods to improve the test efficiency per unit time. Representative projects in parallel fuzz testing methods include Oss-Fuzz of Google, OneFuzz of Microsoft, CollabFuzz, EnFuzz, etc. These methods usually rely on the parallel functions provided by existing fuzz testing engines (such as AFL, LibFuzzer, honggfuzz), and achieve test collaboration among multiple parallel nodes by sharing the seed directory. Although parallel fuzz testing has improved the test efficiency to a certain extent, it still faces many challenges: First, the lack of an effective synchronization mechanism for the collaborative work between different fuzz testing engines will lead to resource waste and a decline in test efficiency; second, existing fuzz testing engines are usually optimized for specific platforms (such as specific operating systems or programming languages), lacking generality and cross-platform support; third, most parallelization schemes are only limited to several basic fuzz testing engines, and the selection of fuzz testing engines often relies on simple and rough heuristic rules, resulting in limited room for improvement in test efficiency and resource utilization.

[0004] Although there is an endless stream of research on improving the performance of fuzz testing, how to effectively integrate multiple fuzz testing engines for parallel fuzz testing remains an urgent problem to be solved. Facing this challenge, it is crucial to build an efficient parallel architecture that can adapt to existing fuzz testing engines for parallel adaptation. Through this method, the fuzz testing engines can be parallel across platforms and support finer-grained data synchronization and resource management, thereby improving the overall efficiency of parallel fuzz testing. Summary of the Invention

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

[0006] On the one hand, the present invention provides a fuzz testing method for GUI programs, including the following steps: S1. Design a hypercall interface for the KVM virtual machine to transfer control instructions between the virtual machine monitor layer and the virtual machine; S2. Design a QEMU virtual machine monitor to respond to the call numbers and corresponding function codes of the KVM virtual machine hypercall interface, including initializing snapshot management, writing memory addresses, submitting configuration information, reporting error events, logging, and code tracing configuration, to achieve dynamic monitoring of the virtual machine state and efficient processing of test cases; S3. Create a Windows proxy layer under the Windows system, hijack system calls by dynamically injecting a code library, and trigger the fuzz testing process using a flag file to achieve dynamic testing and monitoring of the target GUI program; S4. Create a Linux proxy layer under the Linux system, implement fuzz testing of the target GUI program by developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls, and combining with dynamically injecting a hook library.

[0007] Preferably, the specific process of S2 is as follows: S21. KVM and QEMU perform initialization confirmation to obtain a fuzz testing snapshot; S22. Notify KVM and QEMU to restore the virtual machine state using the fuzz testing snapshot; S23. Receive the memory address specified by the virtual machine to write the test case, and the input parameter is a pointer to a structure containing the test case size and data; S24. Query the host QEMU configuration information and submit the agent configuration information, where the host configuration information includes buffer size and coverage bitmap parameters, and the agent configuration information includes timeout time and coverage collection method; S25. Report the detected software crashes or other error events to the host, causing QEMU to stop the virtual machine; S26. Send the pointer to the C string inside the virtual machine to QEMU, and QEMU reads, prints, or records the content to form log records and debugging records; S27. Configure the code address range for INTEL PT tracing; S28. Specify whether the target program to be tested on the host is 32-bit code or 64-bit code; S29. QEMU terminates the fuzz testing process.

[0008] Preferably, S3 specifically includes the following: S31. Develop a window picker to obtain the process information of the target GUI program through the graphical interface and inject the frida script; S32. Package the code library with hypercall functions for external calls; S33. Write a frida script, inject the code library, and hijack the NtCreateFile function to start fuzz testing when the flag file is detected.

[0009] Preferably, S33 specifically includes the following: S331. Inject the code library into the target GUI program; S332. Intercept the call to the NtCreateFile function in the Windows system library and create stub code; S333. Determine whether the file to be opened by the NtCreateFile function is the flag file for starting the snapshot through the stub code; among them, the file to be opened by the NtCreateFile function includes the files automatically generated by the program during the operation of the target GUI program, or the flag file provided by the system to identify the startup snapshot; S334. If the file to be opened by the NtCreateFile function is the flag file for starting the snapshot, call the API in the code library to start the fuzz testing process of the target GUI program.

[0010] Preferably, S4 specifically includes the following: S41. Develop a control panel program, which is used to display the information of the target GUI program and provide interactive controls; S42. Create an eBPF program, which is used to monitor the open operation of the specified file, pause the target process, obtain the stack information, and then resume running; S43. Start the eBPF program through the control panel program, obtain the program-related information of the file opened by the user, wait for the eBPF program to finish running, and display the relevant information on the corresponding controls of the control panel; S44. The user selects a stack entry as the target to be measured and selects the end point of the function to be measured; 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, perform global injection by the ld.reload mechanism provided by the linux system, hijack the __openat function and trigger fuzz testing when the target file is detected, and call the RELEASE hypercall to reset the test at the end point.

[0011] Preferably, in S42, an eBPF program is created, and 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 so, execute S422; otherwise, execute S426; S422. Pause the operation of the openat system call program and transfer the relevant information of the openat system call program back to the eBPF user layer; S423. The eBPF user layer uses the lldb debugger to obtain the stack information of the suspended call program; 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; S425. Write the program path and the obtained stack information into a file and end the operation; S426. The operating system continues to execute normally without any interruption or other special operations.

[0012] Preferably, S46 specifically includes the following: S461. Load the dynamic library where the end point is located in the configuration file; S462. Hook the __openat function and run the stub code created in S332 before the __openat function runs; S463. Determine whether the file to be opened by the __openat function is the file specified by the user in the configuration file through the stub code; S464. If the file to be opened by the __opena function is the 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 according to the dynamic library loading address and the code offset; S466. Install the 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.

[0013] A GUI program fuzz testing system, including a hypercall interface design module, a virtual machine monitor design module, a Windows proxy layer creation module, and a 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; Virtual machine monitor design module, design QEMU virtual machine monitor to respond to the call number and corresponding function code of KVM virtual machine hypercall interface, including initialization snapshot management, memory address writing, configuration information submission, error event reporting, logging and code tracking configuration, so as to realize 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, fuzz testing of the target GUI program is achieved.

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

[0015] 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.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1) Expanding the scope of fuzz testing: Traditional gray-box fuzz testing tools can generally only test programs that automatically exit after running their functions, such as common Linux system commands cat, ls, etc., while GUI programs generally do not automatically exit, so traditional gray-box fuzz testing tools are not applicable. The present invention finds the end point of the GUI program to be tested and actively ends the process when the GUI program to be tested runs to the end point, so that the fuzz testing tool can continue to work.

[0017] 2) Accelerated the speed of fuzz testing: Traditional grey-box fuzz testing tools conduct a single test by starting a new process. However, GUI programs usually take a certain amount of time to start under normal circumstances (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 function under test runs and restores the snapshot after the function under test runs, avoiding the ineffective time occupied by the creation of program processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a flowchart of a method for fuzz testing a GUI program according to an embodiment of the present invention; Figure 2 is an overall architecture diagram of a method for fuzz testing a GUI program according to an embodiment of the present invention; Figure 3 is a timing diagram of user operations for starting fuzz testing of a GUI program through the Windows system according to an embodiment of the present invention; Figure 4 is a timing diagram of user operations for starting fuzz testing of a GUI program through the Linux system according to an embodiment of the present invention; Figure 5 is a schematic block diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

[0020] In one embodiment, referring to Figure 1 and Figure 2 , a method for fuzz testing a GUI (Graphical User Interface) program includes the following steps: S1. Design a hypercall interface for KVM (Kernel-based Virtual Machine) to transfer control instructions between the virtual machine monitor layer and the virtual machine.

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

[0022] S2. Design QEMU (Quick EMUlator, an open-source virtual machine monitor and simulator) to respond to the call numbers and corresponding function codes of the KVM hypercall interface, encapsulate the call numbers and corresponding function codes into function code identifiers, including initializing snapshot management, writing memory addresses, submitting configuration information, reporting error events, logging, and code tracing configuration, so as to achieve dynamic monitoring of the virtual machine state and efficient processing of test cases.

[0023] Host QEMU is a software entity that includes functions such as a virtual machine monitor and a simulator. Host QEMU manages the operation of the simulator through the virtual machine monitor, provides virtualization functions, and simulates hardware devices through the simulator, enabling the virtual machine to run different operating systems. The QEMU designed in S2 is used to respond to the call numbers and corresponding function codes of the KVM hypercall interface, specifically the call numbers and function codes used to trigger the quick snapshot recovery mechanism, encapsulate the call numbers and function codes into function code identifiers, and external programs can call the function code identifiers through the hypercall interface to instruct QEMU to perform a quick virtual machine image recovery operation.

[0024] In one embodiment, the specific process of S2 is as follows: S21. KVM and QEMU perform initialization confirmation to obtain the fuzzing snapshot. S22. Notify KVM and QEMU to restore the virtual machine state using the fuzzing snapshot. S23. Receive the memory address specified by the virtual machine to write the test case, and the input parameter is a pointer to a structure containing the test case size and data. S24. Query the host QEMU configuration information and submit the agent configuration information. Among them, the host configuration information includes the buffer size and coverage bitmap parameters, and the agent configuration information includes the timeout time and the coverage collection method. S25. Report the discovered software crashes or other error events to the host, causing QEMU to stop the virtual machine. S26. Send the pointer to the C string inside 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. Specify the target program to be tested on the host as 32-bit code or 64-bit code. S29. QEMU terminates the fuzzing process.

[0025] Specifically, the function code identifiers include the following: 1) Handshake: Used for mutual confirmation between KVM and QEMU. 2) ACQUIRE: Used to obtain a fuzzing snapshot; 3) RELEASE: Used to notify KVM and QEMU to restore the virtual machine state using the previously obtained snapshot; 4) GET_PAYLOAD: The code running inside the virtual machine indicates to QEMU the location to write the test case by providing the memory space address. Sufficiently large memory space needs to be allocated, and the size must be an integer multiple of the page size, and ensure that the page is in the resident memory.

[0026] The partial functional code of GET_PAYLOAD is as follows: Input parameters: typedef struct { int32_t size; / / Stores the actual size of the test case uint8_t data[]; / / Flexible array used to store the test case content, the actual storage location of the data content } payload_buffer_t payload_buffer (pointer to the structure): Used to store the actual size of the test case and the test case content; 5) GET_HOST_CONFIG: Used to query the host QEMU configuration, such as obtaining the size of the test case buffer.

[0027] The partial functional code of GET_HOST_CONFIG is as follows: Input parameters: typedef struct { uint32_t host_magic; / / Host flag uint32_t host_version; / / Host version uint32_t bitmap_size; / / Size of the bitmap used to store coverage information uint32_t ijon_bitmap_size; / / Size of the ijon bitmap uint32_t payload_buffer_size; / / Size of the memory space used to store the test case uint32_t worker_id; / / Fuzzing client worker id } host_config_t; host_config (pointer to the structure): Obtains the configuration information of the host; 6) SET_AGENT_CONFIG: Used to submit the configuration information of the agent, including the timeout for a single run of the test case and the coverage collection method.

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

[0029] The partial function code of SET_AGENT_CONFIG is as follows: Input parameters: typedef struct { uint32_t agent_magic; / / Tells the host the agent flag uint32_t agent_version; / / Tells the host the agent version uint8_t agent_timeout_detection; / / Tells the host the timeout for a single run of the set test case uint8_t agent_tracing; / / Tells the host not to use the Intel PT technology for coverage collection, but to be provided by the agent } agent_config_t; agent_config (pointer to a structure): A pointer to the memory storing the agent_confi_t data 7) PANIC: Used to report software crashes or other error events found to the host, causing QEMU to stop the virtual machine and reload the snapshot.

[0030] 8) hprintf: Sends a pointer to a C string to QEMU so that QEMU can read and print or record the content, usually used for logging and debugging.

[0031] The partial function code of hprintf is as follows: Input parameters: str_ptr (pointer): The memory address of the string to be printed to the console.

[0032] 9) RANGE_SUBMIT: Used to configure the address range for INTEL PT tracing. Tracing data outside the address range will not be included in the code coverage.

[0033] The partial function code of RANGE_SUBMIT is as follows: Input parameters: typedef struct { uint64_t start_addr; / / Starting address of the code for which code coverage is to be collected uint64_t end_addr; / / Ending address of the code for which code coverage is to be collected } range_t; range (pointer to the structure): Memory address of the structure that stores the address range.

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

[0035] Input parameters: mode (enumeration): Can take values MODE_64, MODE_32.

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

[0037] S3. Create a Windows proxy layer under the Windows system, hijack system calls by dynamically injecting a code library, and trigger the fuzzing process using a flag file to achieve dynamic testing and monitoring of the target GUI program.

[0038] Specifically, inject abnormal, illegal, or random input data into the target GUI program through the Windows proxy layer to detect the target GUI program's processing ability for these inputs, thereby discovering potential vulnerabilities.

[0039] Furthermore, S3 specifically includes the following: S31. Develop a window picker to obtain the process information of the target GUI program through the graphical interface and inject the frida script.

[0040] Specifically, write a window picker with a button. Its function is to be able to obtain the process information of the target GUI program to be tested, such as the window name, process ID, etc. of the target GUI program, by dragging the window picker. Start the frida (a tool for tracing and hijacking functions) process by clicking the button of the window picker, and inject the JavaScript script at the default location into the frida process specified by the window picker. JavaScript is a lightweight scripting language commonly used in web development and dynamic web interactions.

[0041] S32. Package a code library that encapsulates the hypercall function for external calls.

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

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

[0044] Specifically, the Frida injection script is a JavaScript script used to execute in the Frida process. Write a Frida injection script that interacts with the window picker, can interact with the buttons in the window picker, and execute the required functions.

[0045] Furthermore, S33 specifically includes the following: S331. Inject the code library libsnap into the target GUI program; S332. Intercept the call to the Windows system library NtCreateFile function and create stub code; S333. Use the stub code to determine whether the file to be opened by the NtCreateFile function is the flag file for starting the snapshot; among them, the files to be opened by the NtCreateFile function include files automatically generated by the program when the target GUI program runs, or the flag files provided by the system for identifying the start of the snapshot; S334. If the file to be opened by the NtCreateFile function is the flag file for starting the snapshot, call the API (Application Programming Interface) in the code library libsnap to start the fuzz testing process of the target GUI program.

[0046] 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.

[0047] Such as Figure 3As shown, the fuzz testing process starts when the user launches the program under test through a target selector, usually running in debug mode or attaching to an existing process. Subsequently, the user selects specific targets to monitor (such as the system call NtCreateFile) and obtains runtime information of the program (such as memory layout). Custom hooks are implanted into the target process through code injection techniques (such as DLL injection or debugger modification) to intercept critical operations. After installing the NtCreateFile hook, the program is triggered to open a flag file to verify the interception effect. Finally, it enters the core stage of fuzz testing: automatically generating mutated files as inputs, dynamically passing them to the target program for execution, real-time monitoring of exceptions such as crashes and memory errors, and recording the test cases that trigger vulnerabilities. The entire process combines dynamic injection and automated testing to discover potential vulnerabilities in software such as file parsers.

[0048] S4. Create 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 with a dynamically injected hook library, fuzz testing of the target GUI program is achieved.

[0049] Inject abnormal, illegal, or random input data into the target GUI program through the Linux proxy layer to detect the processing ability of the target GUI program for these inputs, thereby discovering potential vulnerabilities.

[0050] Furthermore, S4 specifically includes the following: S41. Develop a control panel program, which is used to display information of the target GUI program and provide interactive controls.

[0051] Specifically, the control panel program can display information of the target GUI program to be tested, such as the program file name, process ID, etc. The control panel program contains a start file monitoring button, a start fuzz testing button, and a dropdown list for displaying stack information.

[0052] S42. Create an eBPF program, which is used to monitor the open operation of a specified file, pause the target process, obtain stack information, and then resume running.

[0053] Furthermore, the process of creating the eBPF program in S42 is as follows: S421. Create an openat system call program to intercept calls to 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 so, execute S422; otherwise, execute S426; S422. Pause the operation of the openat system call program and send the relevant information of the openat system call program back to the eBPF user layer. The eBPF user layer specifically refers to the user space 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 functions or analyze system behavior.

[0054] S423. The eBPF user layer uses the lldb debugger to obtain the stack information of the target program that has been paused. The Linux proxy layer is used for kernel behavior, and the proxy layer can help user space programs communicate and cooperate with the kernel space.

[0055] 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, which is used to extend kernel functions, monitor system behavior, and perform tasks such as network packet filtering.

[0056] S425. Write the program path and the obtained stack information into a file and end the operation.

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

[0058] Specifically, intercept the openat system call. Before the openat kernel function runs, determine whether the file to be opened specified by its parameters is the target file. If so, pause the operation of the program that calls the openat system call and send the relevant information of the program back to the eBPF user layer. The eBPF user layer will use the lldb debugger to obtain the stack information of the paused target program. After obtaining it, resume the operation of the target program until the target process ends, unload the eBPF program from the kernel, then write the program path and the obtained stack information into a file, and finally end the operation. If not, that is, when the target file of the openat system call is not the file to be opened, the system should continue to execute normally without any interruptions or other special operations.

[0059] S43. Start the eBPF program through the control panel program, obtain the 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 controls of the control panel. The eBPF program will keep running 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 required to run, it needs to be manually stopped or terminated to release resources and ensure the normal operation of the system.

[0060] S44. The user selects a stack entry as the target to be measured and selects the end point of the function to be measured.

[0061] Specifically, assume that when the program runs to the current code position, the function code to be tested has already run to completion. At this time, the user clicks on the drop-down list and selects an appropriate stack entry in the drop-down list as the target to be measured and the end point of the function to be measured.

[0062] 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. The relevant information written includes: the executable program file name, the file specified by the user on the control panel, the dynamic library path where the program end point is located, and the offset of the program end point relative to the starting memory address of the dynamic library.

[0063] S46. Develop a hook library based on the frida-gum library (assuming the name of the hook library is libgadget), perform global injection through the ld.reload mechanism provided by the linux system, hijack the __openat function and trigger fuzz testing when the target file is detected, and call the RELEASE hypercall to reset the test at the end point.

[0064] S46 specifically includes the following: S461. Load the dynamic library where the end point is located in the configuration file; S462. Hook the __openat function and run the stub code created in S332 before the __openat function runs; S463. Use the stub code to determine 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 the 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 hypercall in the code library, end this test, and start the next test.

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

[0066] In one embodiment, a GUI program fuzz testing system is also provided, including a hypercall interface design module, a virtual machine monitor design module, a Windows proxy layer creation module, and a Linux proxy layer creation module; The hypercall interface design module designs the hypercall interface of the KVM virtual machine for transmitting 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 numbers and corresponding function codes of the KVM virtual machine hypercall interface, including initializing snapshot management, writing memory addresses, submitting configuration information, reporting error events, logging, and code tracing configuration to achieve dynamic monitoring of the virtual machine state and efficient processing of test cases; The Windows proxy layer creation module creates a Windows proxy layer under the Windows system, hijacks system calls by dynamically injecting a code library, and triggers the fuzz testing process using a flag file 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, realizes fuzz testing of the target GUI program by developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls, and combining with dynamically injecting a hook library.

[0067] For the specific limitations of the GUI program fuzz testing system, reference can be made to the limitations of the GUI program fuzz testing method in the above text, which will not be elaborated here. Each module in the above GUI program fuzz testing system can be implemented in whole or in part by software, hardware, and their combinations. The above modules can be embedded in the processor of the computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so as to facilitate the processor to call and execute the operations corresponding to each of the above modules.

[0068] In one embodiment, a computer device includes a memory, a processor, and a computer program stored on 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 a mobile phone, a tablet, a mobile computer, or any other computer device capable of implementing the detection of an experimental instrument.

[0069] In one embodiment, a computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned GUI program fuzz testing method are implemented.

[0070] Specifically, refer to Figure 5 , Figure 5 which is a schematic block diagram of a computer device in an embodiment of the present invention.

[0071] The computer device 3 can be a smart phone, a tablet computer, a notebook computer, a desktop computer, etc. that execute programs. The computer device 3 in this embodiment at least includes, 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, such as the program corresponding to the above-mentioned GUI program fuzz testing method. Those skilled in the art can understand that the schematic diagram is only an example of the computer device 3 and does not constitute a limitation on the computer device 3.

[0072] The memory 31 includes at least one type of readable storage medium, and the readable storage medium includes a flash memory, a mobile hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a magnetic memory, a 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, and 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 memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), etc. equipped on the computer device 3. Further, the memory 31 can also include both an internal storage unit of the computer device 3 and an external storage device. The memory 31 can not only be used to store application software and various types of data installed in the computer device 3, such as the program code corresponding to the above-mentioned GUI program fuzzy testing method, but also can be used to temporarily store data that has been output or is to be output.

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

[0074] 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 elaborated here.

[0075] 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 the 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 the program process creation is avoided, thereby speeding up the fuzz testing.

[0076] The above has introduced in detail a GUI program fuzz testing method, system, computer device, and storage medium provided by the present invention. Specific examples are used in this article to elaborate on the principle and implementation manner 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 noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

Claims

1. A method for fuzz testing a GUI program, characterized in that, The method includes the following steps: S1. Design a hypercall interface for the KVM virtual machine to transfer control instructions between the virtual machine monitor layer and the virtual machine; S2. Design a QEMU virtual machine monitor to respond to the call numbers and corresponding function codes of the KVM virtual machine hypercall interface, including initializing snapshot management, writing memory addresses, submitting configuration information, reporting error events, logging, and code tracing configuration, to achieve dynamic monitoring of the virtual machine state and efficient processing of test cases; S3. Create a Windows proxy layer under the Windows system, hijack system calls by dynamically injecting a code library, and trigger the fuzz testing process using a flag file to achieve dynamic testing and monitoring of the target GUI program; S4. Create a Linux proxy layer under the Linux system, implement fuzz testing of the target GUI program by developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls, and combining with dynamically injecting a hook library.

2. The GUI program fuzz testing method according to claim 1, characterized in that, The specific process of S2 is as follows: S21. KVM and QEMU are initialized and confirmed to obtain a fuzz testing snapshot; S22. Notify KVM and QEMU to restore the virtual machine state using the fuzz testing snapshot; S23. Receive the memory address specified by the virtual machine to write test cases, and the input parameter is a pointer to a structure containing the test case size and data; S24. Query the host QEMU configuration information and submit agent configuration information, where the host configuration information includes buffer size and coverage bitmap parameters, and the agent configuration information includes timeout time and coverage collection method; S25. Report software crashes or other error events found to the host, causing QEMU to stop the virtual machine; S26. Send a pointer to a 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. Specify the target program to be tested on the host as 32-bit code or 64-bit code; S29. QEMU terminates the fuzz testing process.

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

4. The GUI program fuzz testing method according to claim 3, characterized in that S33 specifically includes the following: S331. Inject the code library into the target GUI program; S332. Intercept calls to the NtCreateFile function in the Windows system library and create stub code; S333. Determine whether the file to be opened by the NtCreateFile function is the flag file for starting the snapshot through the stub code; among them, the file to be opened by the NtCreateFile function includes files automatically generated by the program when the target GUI program runs, or flag files provided by the system for identifying the starting snapshot. S334. If the file to be opened by the NtCreateFile function is the flag file for starting the snapshot, call the API in the code library to start the fuzz testing process of the target GUI program.

5. The GUI program fuzz testing method according to claim 4, wherein S4 specifically includes the following: S41. Develop a control panel program, which is used to display the information of the target GUI program and provide interactive controls; S42. Create an eBPF program, which is used to monitor the open operation of a specified file, pause the target process, obtain stack information and then resume running; S43. Start the eBPF program through the control panel program, obtain the program-related information of the file opened by the user, wait for the eBPF program to finish running, and display the relevant information on the corresponding controls 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, perform global injection through the ld.reload mechanism provided by the linux system, hijack the __openat function, trigger fuzz testing when the target file is detected, and call the RELEASE hypercall to reset the test at the end point.

6. The GUI program fuzz testing method according to claim 5, characterized in that When creating the eBPF program in S42, 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, judge whether the file to be opened specified by the openat kernel function is the target file. If so, execute S422, otherwise execute S426; S422. Pause the operation of the openat system call program and transfer the relevant information of the openat system call program back to the eBPF user layer; S423. The eBPF user layer uses the lldb debugger to obtain the stack information of the paused call program; 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; S425. Write the program path and the obtained stack information into a file and end the operation; S426. The operating system continues to execute normally without any interruption or other special operations.

7. The GUI program fuzz testing method according to claim 6, wherein S46 specifically includes the following: S461. Load the dynamic library where the end point is located in the configuration file; S462. Hook the __openat function and run the stub code created in S332 before the __openat function runs; S463. Judge whether the file to be opened by the __openat function is the file specified by the user in the configuration file through the stub code; S464. If the file to be opened by the __opena function is the 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 according to the dynamic library loading address and the code offset. Install hook code at the actual memory address of the program end point to directly call the RELEASE hypercall in the code library, end the current test, and start the next test.

8. A GUI program fuzz testing system, characterized in that It includes a hypercall interface design module, a virtual machine monitor design module, a Windows proxy layer creation module, and a Linux proxy layer creation module; The hypercall interface design module designs the hypercall interface of the KVM virtual machine for transmitting 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 numbers and corresponding function codes of the KVM virtual machine hypercall interface, including initializing snapshot management, writing memory addresses, submitting configuration information, reporting error events, logging, and code tracing configuration to achieve dynamic monitoring of the virtual machine state and efficient processing of test cases; The Windows proxy layer creation module creates a Windows proxy layer under the Windows system, hijacks system calls by dynamically injecting the code library, and triggers the fuzz testing process using a flag file 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, realizes fuzz testing of the target GUI program by developing a control panel program, creating an eBPF program to monitor file operations, hijacking system calls, and combining dynamic injection of the hook library.

9. A computer device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the GUI program fuzz testing method described in any one of claims 1 to 7.

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

Images