CN120256314A

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

Info

Publication number: CN120256314A
Application number: CN202510724959.8A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Hunan Panlian Xin'an Information Technology Co ltd
Current assignee: Hunan Panlian Xin'an Information Technology Co ltd
Priority date: 2025-06-03
Filing date: 2025-06-03
Publication date: 2025-07-04
Anticipated expiration: 2045-06-03
Also published as: CN120256314B

Abstract

The invention discloses a GUI program fuzzy test method, system, computer equipment and storage medium. First, a hypercall interface of a KVM virtual machine is designed, and then a QEMU virtual machine monitor is designed to respond to the call number and corresponding function code of the KVM virtual machine hypercall interface, and a code library encapsulating the call number and the corresponding function code is written for external call, and the code library is injected into a target GUI program, a Windows proxy layer is created under a Windows system, and a fuzzy test of the target GUI program is completed through the Windows proxy layer, and a Linux proxy layer is created under a Linux system, and a fuzzy test of the target GUI program is completed through the Linux proxy layer. The method can expand the fuzzy test scope of the GUI program and speed up the fuzzy test speed of the GUI program.

Description

GUI program ambiguity test method, system, computer device and storage medium

Technical Field

The present invention relates to the field of fuzzy testing technologies, and in particular, to a GUI program fuzzy testing method, system, computer device, and storage medium.

Background

The fuzzy test is an automatic dynamic test technology and is focused on finding out vulnerabilities in various tested software, so that the safety and the robustness of the tested software are improved. The software to be tested may be 1) applications including various types of applications such as desktop applications, mobile applications, web applications, etc., 2) libraries, modules or components for reuse in software development, 3) operating systems to test operating system kernels, system calls or other system level functions, 4) implementation of protocols, network protocols, communication protocols or other protocols, 5) file format parsers, handlers or read/write operations for various file formats, 6) drivers, hardware drivers, kernel modules or other system level programs, 7) data structures to test the handler, algorithm or parsers of the data structures, 8) APIs to test the use of APIs, processing of parameter inputs, etc. By inputting randomly generated invalid or unexpected data into the tested software and dynamically monitoring whether the execution of the program triggers program abnormality, the fuzzy test can effectively trigger potential errors and loopholes of the tested software, thereby helping developers identify potential safety hazards. With the use of various program analysis techniques, such as control flow analysis, data flow analysis, symbolic execution, stain analysis, etc., a vast array of fuzzy test items has evolved.

However, with increasing complexity of software functions and structures, conventional single-task mode fuzzy tests have failed to meet the requirement of acquiring test results in real time. Therefore, researchers gradually turn to parallel fuzzy testing methods to improve the testing efficiency in unit time, and representative items in the parallel fuzzy testing methods include Oss-Fuzz of google, oneFuzz, collabFuzz, enFuzz of microsoft and the like, which generally depend on the parallel functions of the existing fuzzy testing engine (such as AFL, libFuzzer, honggfuzz) and realize the test collaboration among multiple parallel nodes through sharing seed catalogues. Although parallel fuzzy testing improves the testing efficiency on a certain program, many challenges are faced, firstly, the lack of an effective synchronization mechanism for the cooperative work among different fuzzy testing engines can lead to resource waste and reduction of the testing efficiency, secondly, the existing fuzzy testing engines are usually optimized for a specific platform (such as a specific operating system or programming language) and lack of generality and cross-platform support, and most of parallelization schemes are limited to only a few basic fuzzy testing engines, and in addition, the selection of the fuzzy testing engines often depends on simple and rough heuristic rules, so that the testing efficiency and the resource utilization rate are improved in a limited space.

Although research on improving the performance of the fuzzy test is endless, how to effectively integrate multiple fuzzy test engines to perform parallel fuzzy test is still a problem to be solved. In view of such challenges, it is important to construct an efficient parallel architecture that can accommodate parallelized adaptation of existing fuzzy test engines. By the method, the fuzzy test engines can be parallel in a cross-platform manner and support data synchronization and resource management with finer granularity, so that the overall efficiency of parallel fuzzy tests is improved.

Disclosure of Invention

In view of the above problems, the present application proposes a GUI program ambiguity test method, system, computer device, and storage medium, which support efficient ambiguity test of a GUI program using snapshot and end point correlation techniques.

The invention provides a GUI program ambiguity test method, which comprises the following steps:

S1, designing an overshoot interface of a KVM virtual machine, and transmitting a control instruction between a virtual machine monitor layer and the virtual machine;

S2, designing a QEMU virtual machine monitor for responding to the calling number and the corresponding functional code of the KVM virtual machine overshoot interface, wherein the QEMU virtual machine monitor comprises initializing snapshot management, memory address writing, configuration information submitting, error event reporting, log recording and code tracking configuration so as to realize dynamic monitoring of the state of the virtual machine and efficient processing of test cases;

S3, creating a Windows agent layer under a Windows system, hijacking system call by dynamically injecting a code library, and triggering a fuzzy test flow by using a mark file to realize dynamic test and monitoring of a target GUI program;

S4, creating a Linux agent layer under a Linux system, and realizing fuzzy test on a target GUI program by developing a control panel program, creating eBPF program monitoring file operation, hijacking system call and combining dynamic injection hook library.

Preferably, the specific procedure of S2 is as follows:

s21, carrying out initialization confirmation on the KVM and the QEMU to obtain a fuzzy test snapshot;

s22, informing the KVM and the QEMU to restore the state of the virtual machine by using the fuzzy test snapshot;

s23, receiving a memory address designated by a virtual machine to write a test case, wherein input parameters are structure pointers containing the size and data of the test case;

S24, inquiring QEMU configuration information of a host, and submitting agent configuration information, wherein the host configuration information comprises buffer area size and coverage rate bitmap parameters, and the agent configuration information comprises overtime time and coverage rate collection mode;

S25, reporting the discovered software crash or other error events to the host computer, and causing the QEMU to stop the operation of the virtual machine;

s26, sending a pointer pointing to the C character string in the virtual machine to the QEMU, and reading and printing or recording the content by the QEMU to form log records and debugging records;

s27, configuring a code address range tracked by an INTEL PT;

S28, designating the to-be-tested target program of the host as a 32-bit code or a 64-bit code;

s29, the QEMU terminates the fuzzy test flow.

Preferably, S3 specifically includes the following:

S31, a development window selector acquires the process information of the target GUI program through a graphical interface, and injects frida scripts;

s32, packaging a code base of the hyper-invocation function for external invocation;

s33, writing frida scripts, injecting a code library, hijacking NTCREATEFILE functions, and starting a fuzzy test when the mark file is detected.

Preferably, S33 specifically includes the following:

s331, injecting a code library into a target GUI program;

S332, intercepting the call of NTCREATEFILE functions in the Windows system library and creating stub codes;

S333, judging whether a file to be opened by a NTCREATEFILE function is a mark file for starting a snapshot or not through a stub code, wherein the file to be opened by the NTCREATEFILE function comprises a file automatically generated by a program when a target GUI program runs or a mark file provided by a system and used for marking the starting snapshot;

S334, if the file to be opened by the NTCREATEFILE function is a mark file for starting the snapshot, calling an API in the code library to start the fuzzy test flow of the target GUI program.

Preferably, S4 specifically includes the following:

S41, developing a control panel program, wherein the control panel program is used for displaying information of a target GUI program and providing interaction controls;

S42, creating eBPF a program, wherein the eBPF program is used for monitoring the opening operation of the designated file and suspending the target process, and resuming operation after obtaining the stack information;

S43, starting eBPF a program through a control panel program, acquiring program related information of a file designated by a user to be opened, waiting for eBPF to finish running, and displaying the related information on a corresponding control of the control panel;

s44, selecting a stack item as a tested target by a user, and selecting an ending point of a tested function;

s45, clicking a start button of a control panel program by a user, and writing a program path, a target file and end point information into a configuration file by the control panel;

S46, developing a hook library based on frida-gum library, performing global injection by using a ld.read mechanism provided by a linux system, hijacking __ openat functions, triggering a fuzzy test when a target file is detected, and calling a RELEASE overshoot reset test at an end point.

Preferably, the eBPF procedure is created in S42, the specific procedure is as follows:

s421, creating openat a system calling program, intercepting the call of a openat kernel function in a Linux system, judging whether a file to be opened designated by the openat kernel function is a target file before operation, if so, executing S422, otherwise, executing S426;

S422, suspending the openat system calling program, and transmitting the related information of the openat system calling program back to the eBPF user layer;

s423, eBPF the user layer uses lldb debugger to obtain the stack information of the calling program which has been suspended to run;

s424, restoring the operation of the target GUI program until the target process is finished, and unloading eBPF programs operated in the Linux system from the kernel;

s425, writing the program path and the acquired stack information into a file, and ending the operation;

S426, the operating system continues to execute normally without any interrupt or other special operation.

Preferably, S46 specifically includes the following:

s461, loading a dynamic library where an ending point in the configuration file is located;

S462, a hook __ openat function, and running the stub code created in S332 before __ openat function runs;

S463, judging __ openat whether the file to be opened by the stub code is a file designated by a user in the configuration file;

s464, if the file to be opened by the __ opena function is a file designated by a user in the configuration file, calling an API in a code library to start a fuzzy test flow;

s465, acquiring a dynamic library loading address by a hook library, and calculating an actual memory address of a program end point according to the dynamic library loading address and a code offset;

s466, a hook code is installed at the actual memory address of the program end point and is used for directly calling the RELEASE hypercall in the code library, ending the test and starting the next test.

The GUI program fuzzy test system comprises a hypercalling interface design module, a virtual machine monitor design module, a Windows agent layer creation module and a Linux agent layer creation module;

The hypercalling interface design module is used for designing a hypercalling interface of the KVM virtual machine and transmitting control instructions between the virtual machine monitor layer and the virtual machine;

The virtual machine monitor design module is used for responding to the calling number and the corresponding functional code of the KVM virtual machine overshoot interface, and comprises the steps of initializing snapshot management, memory address writing, configuration information submission, error event reporting, log recording and code tracking configuration so as to realize dynamic monitoring of the state of the virtual machine and efficient processing of test cases;

The Windows agent layer creation module creates a Windows agent layer under a Windows system, hives system call by dynamically injecting a code library, and triggers a fuzzy test flow by using a mark file to realize dynamic test and monitoring of a target GUI program;

and the Linux agent layer creation module creates a Linux agent layer under a Linux system, and realizes fuzzy test on a target GUI program by developing a control panel program, creating eBPF program monitoring file operation, hijacking system call and combining dynamic injection hook library.

The invention also provides a computer device which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, wherein the processor realizes the steps of the GUI program ambiguity test method when executing the computer program.

The present invention also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the above-described GUI program ambiguity test method.

Compared with the prior art, the invention has the beneficial effects that:

1) The range of fuzzy test is expanded, that is, the conventional dust box fuzzy test tool can only test programs which automatically exit after the function is finished, for example, common commands cat, ls and the like of a Linux system, and GUI programs cannot automatically exit, so that the conventional dust box fuzzy test tool is not applicable. According to the invention, the end point of the GUI program to be tested is searched, and the process is actively ended when the GUI program to be tested runs to the end point, so that the fuzzy test tool can continuously work.

2) The speed of the fuzzy test is accelerated, the traditional gray box fuzzy test tool performs one test by starting a new process, and the GUI program normally needs a certain time to start (the UI is drawn in a time consuming way, and most programs can create a plurality of threads in order to avoid blockage).

Drawings

FIG. 1 is a flow chart of a GUI program ambiguity test method according to one embodiment of the present invention;

FIG. 2 is a general architecture diagram of a GUI program ambiguity test method according to one embodiment of the present invention;

FIG. 3 is a timing diagram of a user operation to initiate a GUI program fuzziness test via a Windows system in accordance with one embodiment of the present invention;

FIG. 4 is a timing diagram of a user operation to initiate a GUI program fuzziness test via a Linux system in accordance with an embodiment of the present invention;

fig. 5 is a schematic block diagram of a computer device in an embodiment of the present invention.

Detailed Description

In order to make the technical scheme of the present invention better understood by those skilled in the art, the present invention will be further described in detail with reference to the accompanying drawings.

In one embodiment, referring to fig. 1 and 2, a GUI (GRAPHICAL USER INTERFACE ) program ambiguity test method includes the steps of:

S1, designing a KVM (Kernel-based Virtual Machine) overshoot interface for transmitting control instructions between a virtual machine monitor layer and a virtual machine.

Specifically, the hypercalling interface for fuzzy test is designed, and the main function of the hypercalling interface is to assist in fuzzy test in KVM/QEMU and libsnap libraries.

S2, designing QEMU (Quick EMUlator, open source virtual machine monitor and simulator) for responding to the calling number and corresponding function code of KVM super calling interface, packaging the calling number and corresponding function code into function code identifier, including initializing snapshot management, memory address writing, configuration information submitting, error event reporting, log recording and code tracking configuration, to realize dynamic monitoring of virtual machine state and efficient processing of test case.

The host QEMU is a software entity comprising functions of a virtual machine monitor, a simulator and the like, manages the running of the simulator through the virtual machine monitor, provides a virtualization function, simulates hardware equipment through the simulator, and enables the virtual machine to run different operating systems. The QEMU designed in S2 is configured to respond to the calling number and the corresponding function code of the KVM overshoot interface, specifically, the calling number and the function code for triggering the fast snapshot restoration mechanism, package the calling number and the function code into a function code identifier, and the external program may invoke the function code identifier through the overshoot interface to instruct the QEMU to execute the fast virtual machine image restoration operation.

In one embodiment, the specific procedure of S2 is as follows:

s27, configuring a code address range tracked by an INTEL PT;

s29, the QEMU terminates the fuzzy test flow.

Specifically, the function code identifier includes the following:

1) Handshaking, for KVM and QEMU to acknowledge each other;

2) Acquisition, used for taking the fuzzy test snapshot;

3) RELEASE is used for informing KVM and QEMU to restore virtual machine state by using the snapshot acquired previously;

4) Get_payoad code running within the virtual machine indicates QEMU by providing a memory space address

The location of the test case is written. It is necessary to allocate a sufficiently large memory space, the size must be an integer multiple of the page size, and ensure that the page is in resident memory.

The get_payoad part of the function code is as follows:

Inputting parameters:

typedef struct {

Int32_tsize;// actual size of storage test case

Uint 8_tdata [ ]// Flexible array for storing test case contents, storage location of actual data contents

} payload_buffer_t

The payload_buffer (structure body pointer) is used for storing the actual size of the test case and the content of the test case;

5) Get_host_config for querying the HOST QEMU configuration, e.g., obtaining the size of the test case buffer.

The get_host_config part of the function code is as follows:

Inputting parameters:

typedef struct {

uint32_t host_magic;// host flag

Uint32_t host_version;// host version

Uint32_t bitmap_size;// bitmap size for storing coverage information

Uint32_ t ijon _bitmap_size;// ijon bitmap size

Uint32_t payload_buffer_size;// memory space size for storing test cases

Uint32_t worker_id;// fuzzy test client work id

} host_config_t;

Host_config (structure pointer) to obtain configuration information of the host;

6) Set_agent_config, configuration information for submitting the AGENT, including timeout time and coverage rate collection mode of single run of test cases.

An agent is generally referred to as a program or software that performs a specific task on behalf of a user or other program and gathers information, or performs some operation in a system, and that autonomously performs tasks in a computer system, enabling coordination of communications and interactions between different systems or programs.

The set_agent_config part function code is as follows:

Inputting parameters:

typedef struct {

uint32_t agent_magic;// tell host agent flag

Uint32_t agent_version;// tell host agent version

Uint8_t agent_timeout_detection;// test case single run timeout time telling host set

Uint8_t agent_tracking;// tells the host not to use intelpt technology for coverage collection, but rather is provided by the agent

} agent_config_t;

Agent_config (structure pointer) a memory pointer to store agent_conf_t data

7) PANIC A software crash or other error event to report to the host that causes the QEMU to stop the virtual machine and reload the snapshot.

8) Hprintf a pointer to the C string is sent to the QEMU for the QEMU to read and print or record the content, typically for logging and debugging.

Part hprintf of the function code is as follows:

Inputting parameters:

str_ptr (pointer) to the memory address of the character string to be printed to the console.

9) Range_submit: address RANGE for configuring INTEL PT trace, trace data outside the address RANGE will not account for code coverage.

The range_submit part function code is as follows:

Inputting parameters:

typedef struct {

uint64_t start_addr;// code start address where code coverage is to be collected

Uint64_t end_addr;// code end address where code coverage is to be collected

} range_t;

Range, which points to the fabric memory address of the memory address range.

10 User_submit_mode for telling the host whether the target is a 32-bit code or a 64-bit code.

Inputting parameters:

MODE (enumeration) may take the values mode_64, mode_32.

11 Habort telling the QEMU to terminate the fuzzy test flow when an unresolved error occurs.

And S3, creating a Windows agent layer under the Windows system, hijacking the system call by dynamically injecting a code library, and triggering a fuzzy test flow by using a mark file to realize dynamic test and monitoring of the target GUI program.

Specifically, abnormal, illegal or random input data is injected into the target GUI program through the Windows agent layer to detect the processing capability of the target GUI program on the inputs, thereby discovering potential vulnerabilities.

Further, S3 specifically includes the following:

S31, a development window selector acquires the process information of the target GUI program through a graphical interface, and injects frida scripts.

Specifically, a window picker with a button is written, and the function of the window picker is to be capable of acquiring process information of a target GUI program to be tested, such as a window name, a process number, and the like of the target GUI program, by dragging the window picker. Starting frida (tool for tracking and hijacking functions) process by clicking button of window selector, injecting JavaScript script at default position into frida process appointed by window selector, javaScript is a lightweight script language commonly used for webpage development and dynamic webpage interaction.

S32, packaging a code base of the hyper call function for external call.

Specifically, a code base (assumed to be code base name libsnap) encapsulating the function number in step S2 is written for external call.

Specifically, frida injection script is JavaScript script for execution in the frida process, writing frida injection script that interacts with the window picker, able to interact with buttons in the window picker, performing the required functions.

Further, S33 specifically includes the following:

s331, injecting a code library libsnap into a target GUI program;

s332, intercepting the call of the Windows system library NTCREATEFILE function and creating stub codes;

S334, if the file to be opened by the NTCREATEFILE function is a mark file for starting the snapshot, calling an API (Application Programming Interface ) in the code library libsnap to start the fuzzy test flow of the target GUI program.

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 fuzzy test flow of the target GUI program is not started.

As shown in FIG. 3, the fuzzy test procedure begins with a user launching a program under test through a target selector, typically running in debug mode or attached to an existing process. The user then selects a particular object to be monitored (e.g., system call NTCREATEFILE) and obtains the runtime information (e.g., memory layout) of the program. The custom hooks are implanted into the target process through code injection technology (such as DLL injection or debugger modification), and key operations are intercepted. After the NTCREATEFILE hooks are installed, the trigger opens the flag file to verify the intercept effect. And finally entering a fuzzy test core stage, namely automatically generating a variation file as input, dynamically transmitting the variation file to a target program for execution, monitoring abnormality such as crash, memory error and the like in real time, and recording test cases triggering loopholes. The whole process combines dynamic injection and automatic testing and is used for mining potential vulnerabilities of software such as a file parser and the like.

The Linux agent layer is used for injecting abnormal, illegal or random input data into the target GUI program to detect the processing capability of the target GUI program on the inputs, thereby finding potential loopholes.

Further, S4 specifically includes the following:

s41, developing a control panel program, wherein the control panel program is used for displaying information of the target GUI program and providing interaction controls.

Specifically, the control panel program can display information of the target GUI program to be tested, such as a program file name, a process number, and the like. The control panel program includes a start file monitor button, a start fuzziness test button, and a drop down list for displaying stack information.

S42, creating eBPF a program, wherein the eBPF program is used for monitoring the opening operation of the designated file and suspending the target process, and resuming operation after acquiring the stack information.

Further, a eBPF procedure is created in S42, and the specific procedure is as follows:

S422, suspending the openat system calling program, and transmitting the related information of the openat system calling program back to the eBPF user layer, wherein the eBPF user layer specifically refers to a user space component of an Extended BPF (eBPF) and is used for processing and analyzing eBPF programs running in a Linux kernel. eBPF is a technique in the Linux kernel that allows users to run small programs in the Linux kernel to extend kernel functionality or analyze system behavior.

S423 and eBPF the user layer uses lldb debugger to obtain the stack information of the object program which has been suspended, the Linux proxy layer is used for kernel behavior, and the proxy layer can help the user space program to communicate and work cooperatively with the kernel space.

S424, resuming the operation of the target GUI program until the target process is finished, unloading eBPF programs operated in the Linux system from the kernel, wherein eBPF (Extended Berkeley PACKET FILTER) is a small program operated in the Linux kernel and is used for expanding kernel functions, monitoring system behaviors, executing network data packet filtering and other tasks.

S425, writing the program path and the acquired stack information into the file, and ending the operation.

Specifically, intercept openat the system call, before openat kernel function runs, judge whether the file to be opened specified by its parameter is the target file, if yes, suspend the program calling openat system call and transmit the relevant information of the program back to eBPF user layer, eBPF user layer will use lldb debugger to obtain the target program stack information that has suspended running, resume the running of the target program after obtaining until the target process ends, eBPF program uninstalls from kernel, then write the program path and obtained stack information into the file, and finally end running, if not, namely when the target file called openat system is not the target file to be opened, the system should continue normal execution, and will not perform any interruption or other special operations.

S43, starting eBPF the program through the control panel program, acquiring program related information of the file designated by the user, waiting for eBPF to finish running, and displaying the related information on a corresponding control of the control panel. eBPF the program will continue to run waiting for possible subsequent tasks or events and continue to monitor or process relevant data as needed, if eBPF program operation is no longer needed, it will need to be manually stopped or terminated to free up resources and ensure proper operation of the system.

S44, the user selects a stack item as a tested target and selects an ending point of a tested function.

Specifically, when the program runs to the current code position, the function code to be tested is already run, and the user clicks the drop-down list to select a proper stack item in the drop-down list as a tested target and an end point of the tested function.

S45, clicking a start button of the control panel program by a user, and writing the program path, the target file and the end point information into the configuration file by the control panel. The written related information comprises executable program file names, files appointed by a user on a control panel, dynamic library paths where program end points are located, and offset of the program end points relative to initial memory addresses of the dynamic library.

S46, developing a hook library based on frida-gum library (assuming that the name of the hook library is libgadget), performing global injection by using a ld.reload mechanism provided by a linux system, hijacking a __ openat function, triggering a fuzzy test when a target file is detected, and calling a RELEASE overshoot reset test at an end point.

S46 specifically includes the following:

Specifically, as shown in fig. 4, after the user starts the target program through the control panel, the file to be tested is selected and the program is opened manually to initialize the test environment. Then, a specific stack entry (e.g., function call chain node) is selected as a test termination flag at the target program runtime to define the monitoring scope. And after confirming the operation path, the system automatically generates a variant file to replace the original input, dynamically executes and monitors program behaviors (such as memory leakage, breakdown and the like), and records the stack state and input samples when the abnormal triggering occurs. The process is suitable for verifying the robustness of file analysis logic by combining manual preset key nodes with automatic variation and focusing on the stability test of a specific code path.

In one embodiment, a GUI program ambiguity test system is provided, including an overshoot interface design module, a virtual machine monitor design module, a Windows agent layer creation module, and a Linux agent layer creation module;

For specific limitations of the GUI program ambiguity test system, reference may be made to the above description of the GUI program ambiguity test method, and no further description is given here. The various modules in the GUI program ambiguity test system described above may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, a computer device includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor, where the processor executes the computer program to implement the steps of a GUI program ambiguity test method described above, and the computer device may be any computer device capable of implementing detection of an experimental apparatus, such as a mobile phone, a tablet, and a mobile computer.

In one embodiment, a computer readable storage medium has stored thereon a computer program which, when executed by a processor, performs the steps of a GUI program ambiguity test method as described above.

In particular, referring to FIG. 5, FIG. 5 is a schematic block diagram of a computer device in an embodiment of the invention.

The computer device 3 may be a smart phone, tablet, notebook, desktop computer, etc. that executes a program. The computer device 3 of the present 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, which are communicably connected to each other via a system bus, such as a program corresponding to one of the above-described GUI program blur test methods. Those skilled in the art will appreciate that the schematic illustration is merely an example of the computer device 3 and does not constitute a limitation of the computer device 3.

The memory 31 includes at least one type of readable storage medium including flash memory, a removable hard disk, a multimedia card, a card memory (e.g., SD or DX memory, etc.), a magnetic memory, a magnetic disk, an optical disk, etc. The memory 31 may be an internal storage unit of the electronic device 1, such as a mobile hard disk of the computer device 3, or the memory 31 may 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 (SD) card, a flash memory card (FLASH CARD) or the like, which are provided on the computer device 3. Further, the memory 31 may also include both an internal storage unit and an external storage device of the computer device 3. The memory 31 may be used not only for storing application software installed in the computer device 3 and various types of data, such as program codes corresponding to one of the above-described GUI program ambiguity test methods, but also for temporarily storing data that has been output or is to be output.

The processor 32 may be a central processing unit (Central Processing Unit, CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 32 executes the operating system of the computer device 3 and various types of applications installed. In this embodiment, the processor 32 executes the computer program 33 stored in the memory 31 to implement a GUI program ambiguity test method according to the present invention.

The computer device and the computer readable storage medium both include the GUI program ambiguity test method, so that the ambiguity test method has the advantages of the ambiguity test method, and are not described herein.

According to the method, the system, the computer equipment and the storage medium for fuzzy test of the GUI program, firstly, the overshoot interface of the KVM virtual machine is designed, then, the QEMU virtual machine monitor is designed for responding to the calling number and the corresponding functional code of the overshoot interface of the KVM virtual machine, a Windows agent layer is created under a Windows system, the fuzzy test of the target GUI program is completed through the Windows agent layer, a Linux agent layer is created under the Linux system, and the fuzzy test of the target GUI program is completed through the Linux agent layer. According to the method, on one hand, the end point of the tested target is searched, and when the target program runs to the end point, the process is actively ended to enable the fuzzy test tool to work continuously, so that the range of fuzzy test is expanded, on the other hand, the snapshot is shot before the function is run, and after the function is run, the snapshot is restored to avoid invalid time occupied by program process creation, so that the speed of fuzzy test is accelerated.

The GUI program ambiguity test method, system, computer device and storage medium provided by the present invention are described in detail above. The principles and embodiments of the present invention have been described herein with reference to specific examples, the description of which is intended only to facilitate an understanding of the core concepts of the invention. It should be noted that it will be apparent to those skilled in the art that various modifications and adaptations of the invention can be made without departing from the principles of the invention and these modifications and adaptations are intended to be within the scope of the invention as defined in the following claims.

Claims

1. A GUI program fuzzy testing method, characterized in that the method comprises 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 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, so as to realize dynamic monitoring of virtual machine status and efficient processing of test cases;

S3. Create a Windows proxy layer under the Windows system, hijack the system call by dynamically injecting the code library, and use the flag file 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 the specific process of S2 is as follows:

S21, KVM and QEMU perform initialization confirmation and obtain fuzz test snapshot;

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

S23, receiving 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, querying the host QEMU configuration information, and submitting 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 time and coverage collection method;

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

S26, sending the pointer to the C string in the virtual machine to QEMU, QEMU reads and prints or records the content to form a log record and a debugging record;

S27, configure the code address range traced by INTEL PT;

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

S29. QEMU terminates the fuzz testing process.

3. The GUI program fuzz testing method according to claim 2, wherein S3 specifically comprises 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, a code library encapsulating the supercall function for external calls;

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

4. The GUI program fuzzy testing method according to claim 3, wherein S33 specifically comprises the following:

S331, injecting the code library into the target GUI program;

S332, intercept the call of NtCreateFile function in Windows system library and create stub code;

S333, judging through the stub code whether the file to be opened by the NtCreateFile function is a flag file for starting the snapshot; wherein the file to be opened by the NtCreateFile function includes a file automatically generated by the program when the target GUI program is running, or a flag file provided by the system for identifying the starting 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.

5. The GUI program fuzz testing method according to claim 4, wherein S4 specifically comprises the following:

S41, developing a control panel program, the control panel program is used to display information of the target GUI program and provide interactive controls;

S42, creating 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;

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 a target to be tested and selects an 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.

6. The GUI program fuzz testing method according to claim 5, characterized in that the eBPF program is created in S42, and the specific process is as follows:

S421, create an openat system call program, intercept the call of the openat kernel function in the Linux system, and determine whether the file to be opened specified by the openat kernel function is the target file before running. If yes, execute S422, otherwise execute S426;

S422, suspend the operation of the openat system call program, and transmit 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 calling program that has been suspended;

S424, resuming the operation of the target GUI program until the target process ends, and uninstalling the eBPF program running in the Linux system from the kernel;

S425, write the program path and the acquired stack information into a file, and terminate 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 comprises 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 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.

8. A GUI program fuzz testing system, characterized by 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;

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.

9. A computer device, comprising 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 GUI program fuzzy testing method described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the GUI program fuzzy testing method according to any one of claims 1 to 7.