Kernel fuzzy testing method and device based on unicorn simulation

Abstract

The embodiment of the invention provides a kernel fuzzy testing method and device based on unicorn simulation. The method comprises the steps that a unicorn engine is created in the harness of unicorrefuzz, all needed memory areas are mapped, and the initial value of each register is set according to the requirement of a target program; fuzz test input data generated by the AFL is transmitted to a unicorn engine; after a user specifies a target function address and a breakpoint of the fuzzy test, a unicorn engine starts a fork server of the AFL to simulate and execute the fuzzy test of a target program; and in the fuzzy testing process, loading the memory as required and processing the abnormal condition of the target program.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure relate to the technical field of fuzz testing, and in particular, to a kernel fuzz testing method based on unicorn emulation, a device, and a computer readable storage medium storing a computer program. BACKGROUND

[0002] In the field of network security, fuzzing is an important vulnerability discovery method, which provides unexpected input to the target system, monitors abnormal results to find possible program errors. Although fuzzing is widely used in security vulnerability detection of application layer software, its application in the operating system and kernel level is still relatively rare.

[0003] Kernel space code is the core part of the operating system kernel, responsible for managing system resources, executing system calls, and handling core functions. Due to the complexity and privileged level of kernel space code, there may be various vulnerabilities and security issues such as memory overflow, buffer overflow, integer overflow, etc. These vulnerabilities may cause system crashes, denial of service, privilege escalation, or information leakage, etc. Therefore, testing the kernel not only needs to cover more complex execution paths, but also needs to consider the interaction of hardware, the driver program of external devices, and other multiple levels.

[0004] Currently, there are some well-known projects that have successfully fuzzed kernel subsystems, drivers, and interfaces. For example, Trinity, DIFUZE, Syzkaller, In-Kernel AFL, etc., which exhibit different techniques and methods to achieve this goal.

[0005] Among them, Syzkaller and In-Kernel AFL both use fuzzing methods based on coverage feedback, the former improves the efficiency of testing by tracking the execution path of the kernel and extracting coverage data, and the latter accelerates fuzzing through shared memory areas and kernel memory mapping. Trinity, with its simple and easy-to-use design, can find some vulnerabilities through system calls even without complex description files. TriforceAFL and kAFL use virtualization technology (QEMU and KVM) and hardware-assisted code coverage technology (such as Intel's Processor Trace), thus improving the performance and efficiency of fuzzing. TriforceAFL solves the problem of virtualization overhead through complete system emulation and state restoration, while kAFL greatly improves the speed of execution per second through hardware-level coverage tracking. However, kernel fuzzing for arbitrary architectures has not been implemented. SUMMARY

[0006] The embodiments described herein provide a unicorn simulation-based kernel fuzzing method, device and computer readable storage medium storing a computer program, which combines simulation technology and dynamic memory mapping, effectively solves the performance bottleneck commonly encountered in fuzzing, and is suitable for kernel or binary testing tasks that require efficient memory management.

[0007] According to a first aspect of the present disclosure, a unicorn simulation-based kernel fuzzing method is provided, comprising: creating a unicorn engine in the harness of unicornfuzz, mapping all required memory regions and setting the initial values of various registers according to the needs of the target program; passing the fuzzing input data generated by AFL to the unicorn engine; after the user specifies the target function address and breakpoint of the fuzzing, the unicorn engine starts the fork server of AFL, simulates the fuzzing of the target program; loading memory on demand and handling abnormal conditions of the target program during fuzzing.

[0008] In some embodiments of the present disclosure, creating a unicorn engine in the harness of unicornfuzz, mapping all required memory regions and setting the initial values of various registers according to the needs of the target program comprises: creating a unicorn engine in the harness of unicornfuzz and setting the processor architecture; mapping the memory region required by the target program to the unicorn engine, loading the binary code of the target program into the mapped memory region; setting the initial values of the registers according to the needs of the target program.

[0009] In some embodiments of the present disclosure, passing the fuzzing input data generated by AFL to the unicorn engine comprises: unicornfuzz interacts with the GDB stub using the avatar2 framework; writing the input data required for fuzzing into the simulated memory through the mem_write() function; if the input data needs to modify the content of the register, modify the content of the register through the reg_write() function.

[0010] In some embodiments of the present disclosure, after the user specifies the target function address and breakpoint of the fuzzing, the unicorn engine starts the fork server of AFL to simulate the fuzzing of the target program, which comprises: after the user specifies the address and breakpoint of the target function of the fuzzing in the probe wrapper, start the fork server of AFL and begin to execute the simulated fuzzing; when fuzzing, the unicorn engine is in an active or paused state, and a communication channel is established between the probe component and AFL; when the specified breakpoint is triggered, the execution is paused and waits for a dynamic memory mapping request.

[0011] In some embodiments of the present disclosure, the loading memory on demand and handling abnormal situations of the target program during the fuzzing process comprises: when the unicorn requests to access an unmapped memory region, the probe component is notified through the UC_HOOK_MEM_UNMAPPED application programming interface; the probe component checks whether the requested memory region is valid, if the requested memory is valid, the request is processed and mapped into the unicorn engine, if the memory is successfully mapped, the emulation continues, and the memory region is cached to the disk; if the requested memory is invalid, the request is rejected, and a SIGSEGV signal is triggered, and the crash information is reported to the AFL.

[0012] In some embodiments of the present disclosure, if the requested memory is invalid, the request is rejected, and a SIGSEGV signal is triggered, and the crash information is reported to the AFL, which comprises: when the target program crashes due to invalid memory access, the captured crash information is reported to the AFL, the crash information including the memory location of the crash, stack information and related input data; if the requested memory cannot be mapped, the probe component creates a rejection file in the input directory; for the failed memory request, the probe component creates an empty file in the input directory, marking that the memory region cannot be mapped continuously, and waiting for subsequent checking.

[0013] In some embodiments of the present disclosure, the loading memory on demand and handling abnormal situations of the target program during the fuzzing process further comprises: when the emulated target program references the unmapped memory region again, the probe component checks whether the memory region has been requested in the previous run; if the memory region has been requested and successfully mapped in the previous run, the cached data is continued to be used, and if the memory region has been rejected, the processing of the memory region is stopped.

[0014] In some embodiments of the present disclosure, the probe component checks whether the memory region has been requested in the previous run comprises: periodically polling the output directory of the probe wrapper, waiting for the dump result of the memory region; if the output directory of the probe wrapper contains the dumped memory data, the data is continued to be used; if the output directory of the probe wrapper contains a rejection file, indicating that the memory region cannot be dumped or processed, the current operation is stopped, and the memory region is marked as rejected.

[0015] According to a second aspect of the present disclosure, a kernel fuzzing device based on unicorn emulation is provided. The device comprises at least one processor; and at least one memory storing a computer program. When the computer program is executed by the at least one processor, the device is caused to:.

[0016] In some embodiments of the present disclosure, the computer program, when executed by the at least one processor, causes the apparatus to perform the steps of the unicorn emulation based kernel fuzzing method according to the first aspect of the present disclosure.

[0017] In some embodiments of the present disclosure, the computer program, when executed by the at least one processor, causes the apparatus to perform the steps of the unicorn emulation based kernel fuzzing method according to the first aspect of the present disclosure.

[0018] According to a third aspect of the present disclosure, a computer readable storage medium storing a computer program is provided, wherein the computer program, when executed by a processor, implements the steps of the unicorn emulation based kernel fuzzing method according to the first aspect of the present disclosure.

[0019] The unicorn emulation based kernel fuzzing method and apparatus according to embodiments of the present disclosure effectively reduce unnecessary memory overhead by loading memory only when needed through a dynamic memory mapping mechanism, ensuring the efficiency of fuzz testing. At the same time, through interaction with a virtual machine, breakpoints can be set at specific addresses of the target function and accurately located to specific addresses of the target function, enabling high-precision vulnerability detection. Unicorefuzz does not need to interact with real hardware, but only relies on virtual machines and simulation technology, which can support fuzz testing of arbitrary architecture and binary level code, and can perform efficient and accurate fuzz testing in complex target environments. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings of the embodiments will be briefly described below. It should be noted that the drawings described below only relate to some embodiments of the present disclosure, rather than limiting the present disclosure, wherein:

[0021] Figure 1 FIG. 5 shows an internal workflow schematic diagram of the Unicorefuzz fork service according to embodiments of the present disclosure;

[0022] Figure 2 FIG. 6 shows an exemplary flowchart of the unicorn emulation based kernel fuzzing method according to embodiments of the present disclosure;

[0023] Figure 3 FIG. 7 is a fuzz testing execution flow schematic diagram according to embodiments of the present disclosure;

[0024] Figure 4 FIG. 8 is a schematic block diagram of the unicorn emulation based kernel fuzzing apparatus according to embodiments of the present disclosure.

[0025] It should be noted that the elements in the drawings are schematic and not drawn to scale. DETAILED DESCRIPTION

[0026] In order to make the purposes, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments of the present disclosure. Based on the described embodiments of the present disclosure, all other embodiments obtained by a person of ordinary skill in the art without creative effort belong to the scope of protection of the present disclosure.

[0027] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this present subject matter belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the specification and relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. Additionally, terms such as "first" and "second" are used merely to distinguish one component (or portion of a component) from another.

[0028] Unicorefuzz is a kernel fuzzing tool based on unicornAFL and AFL++, which can perform fuzzing tests on most targets, especially kernel components, through simulation. Among them, unicornAFL is an AFL fork based on the unicorn emulator, which allows Fuzzing testing without actually executing the program. Unicorn is a QEMU-based CPU emulator that allows developers to simulate various CPU architectures without actual hardware, which can dynamically translate any supported binary instruction set into the host instruction set. Specifically, given a binary CPU platform, the workflow of unicorn is: 1. Translate the basic code blocks of the target platform instruction set into the host platform instruction set. 2. Cache the translated code blocks. 3. Save the mapping of the source program counter to the target program counter in the address lookup table. 4. Execute the translated code blocks. 5. Repeat the above operations for the next discovered code block. The translated code blocks are similar to basic blocks, and by taking advantage of this correspondence between them and the fact that control is returned to the emulator after the execution of each code block, the program counter can be used as coverage feedback for each new block, thus enabling dynamic detection similar to compile-time detection.

[0029] AFL++ is an enhanced version of AFL. AFL provides a QEMU mode that guides the generation of test cases by monitoring program execution paths and coverage. AFL's QEMU mode uses a modified QEMU emulator to emulate the test program. This QEMU reports the covered branches to AFL after executing each basic block. To increase speed, a fork service resets the state to a fully loaded initial state during fuzz testing. After forking the child process, the parent process also translates the block and caches the results, so that the next fork does not require expensive translation. Control returns to QEMU after each block, and QEMU passes coverage information to AFL via shared memory by calling the afl_maybe_log function.

[0030] Unicorefuzz is built on AFL-unicorn, a framework that combines AFL and Unicorn, applying AFL's intelligent testing strategies to the UnicornEngine simulated environment. This enables deep exploration and vulnerability discovery in previously inaccessible binary code blocks. In AFL-unicorn, the emulator appends code to the end of each basic block, sends coverage information to AFL, and starts a fork of AFL after the emulator is set up. To speed things up, the parent process caches basic blocks. AFL itself only needs to launch an external program and generate input.

[0031] Figure 1 FIG. 1 shows a schematic diagram of the internal workflow of the Unicorefuzz fork service according to an embodiment of the present disclosure. Figure 1 As shown, the Prabe wrapper is used to interact with the fuzz testing framework and external target programs. It relies on the Avatar2 framework. Avatar2 can provide more feedback to the fuzz tester by simulating and executing the target code, thereby helping to find program vulnerabilities. Through Avatar2, Unicorefuzz can connect to external target programs such as binary analysis tools, any GDB session, PANDA and QEMU virtual machines, smart devices, etc. This allows Unicorefuzz to support multiple environments, thereby improving its compatibility on different platforms. Avatar2 can dump the memory and registers of the process and use this information for subsequent analysis, fuzz testing, and vulnerability discovery.

[0032] First, the AFL starts an external target program and initializes the unicorn engine to load the initial kernel memory, the kernel part of the external program is simulated by the unicorn engine. After the external program loads the kernel memory, it forks child processes, each child process independently executes and is responsible for executing a part of the fuzz test, simulates the execution of the target binary program, simulates the use of memory during the execution of the program, and feeds back the memory and state information encountered during the execution to the parent process. Each child process will continue to run until an exit condition such as exception or crash occurs.

[0033] If a child process encounters a new memory region or translates a new code block during execution, it will feed back to the parent process through a pipe. The pipe is a very efficient inter-process communication (IPC) mechanism, which allows the child process to pass its memory access requirements and state information to the parent process. The parent process then performs the necessary memory mapping, translation or other processing based on the feedback data.

[0034] The parent process is responsible for handling memory translation requests from child processes, loading unmapped memory regions into the simulation environment, translating existing memory into corresponding machine code, and saving the translated memory blocks to disk. In this way, these memory blocks can be directly used in subsequent tests without the need for retranslation. The parent process also manages and saves the running state of the child processes to ensure that each child process can run independently and each has its own memory mapping. If a child process needs to access an unmapped memory region, the parent process will trigger the memory mapping mechanism and load the new memory region into the simulation environment for the child process to use. If a child process accesses an invalid memory region during fuzz testing, such as out-of-bound access or illegal memory access, the process will receive a SIGSEGV signal (segmentation fault), which will cause the child process to crash. When a crash occurs, the parent process will receive a crash signal and feed back the crash information to AFL. AFL records the crash information and continues to run the fuzz test. The crash information includes the type of memory access error and the specific operation that caused the crash, so that the developer can further analyze it.

[0035] Unicorefuzz performs fuzz testing through simulation and emulation technology, and does not directly interact with hardware, but tests the target binary code through a simulation environment. The framework focuses on simulating the parser, which is usually responsible for handling untrusted input buffers, which allows it to fuzz complex parts such as kernel components.

[0036] To further illustrate the embodiments of the present disclosure, Figure 2 An exemplary flowchart of a unicorn-emulated kernel fuzzing method according to an embodiment of the present disclosure is shown. In Figure 2At block S202 , a unicorn engine is created in the unicorefuzz harness, all required memory areas are mapped, and the initial values ​​of various registers are set according to the needs of the target program.

[0037] Harness is an adaptation layer that connects the target program to a fuzz testing engine (such as AFL++). It converts the input data generated by the fuzz testing engine into a format understandable to the target program, calls the target program's API at appropriate times to perform fuzz testing, and collects feedback during execution, such as code coverage and crash information, to guide the fuzz testing engine in generating new test cases.

[0038] During the fuzzing preparation phase, the Unicorefuzz harness creates a Unicorn engine object, which is responsible for mapping the required memory regions. It selects the appropriate processor architecture type, maps multiple memory regions based on the target program's requirements, ensures the correct starting address and size for each region, and then loads the target program's binary code into the mapped memory regions. The Unicorn engine sets the initial values ​​of various registers based on the target program's requirements, and AFL generates the input data required for fuzzing.

[0039] Then, in block S204 , the fuzz testing input data generated by AFL is passed to the unicorn engine.

[0040] According to one embodiment of the present disclosure, Unicorefuzz utilizes the avatar2 framework to interact with the GDB stub (debugger) so that the target program can be debugged and controlled. AFL requires one or more initial input files (seeds), which will serve as the basis for mutation. AFL can generate mutated input data in the following ways: randomly changing the bytes of the input data (for example, replacing bytes, inserting bytes, deleting bytes, etc.); changing certain bits of the input to perform fine-grained mutations; inserting random bytes into the input data; trimming the input data to generate mutated data of different lengths, etc. The fuzz test input data generated by AFL can be passed to the Unicorn engine through the mem_write() function. If the target program modifies registers through parameters or memory data, the reg_write() function can be used to modify it. These functions ensure that the fuzzy input generated by AFL can be correctly passed to the target program to test its performance under different inputs.

[0041] Next, in block S206 , after the user specifies the target function address and breakpoints for the fuzz test, the unicorn engine starts the AFL fork server to simulate the fuzz test of the target program.

[0042] According to one embodiment of the present disclosure, the user needs to set a breakpoint in the harness of the code and the memory region where the AFL input data should be stored, and wait for the breakpoint to trigger. These inputs and breakpoints trigger corresponding operations in the emulator (such as a virtual machine) to ensure that the data can be accurately delivered. After the user specifies the address of the target function of the fuzz test and the breakpoint in the probe wrapper, the fork server of the AFL is started, and the simulation of the fuzz test is started. The fork server is an important component in the AFL, which is responsible for the creation of child processes, enabling the AFL to run multiple child processes and perform fuzz testing on them. This allows the AFL to perform testing in a parallel manner, thereby speeding up the vulnerability discovery process. During the fuzz test, the unicorn engine is in an active or paused state, and a communication channel is established between the probe component and the AFL, through which the loading of memory is managed.

[0043] When the specified breakpoint is triggered, the execution is paused and a request for dynamic memory mapping is awaited. The goal of dynamic memory mapping is to avoid performing fuzz testing by dumping the entire memory of the target program, as this would result in unnecessary memory overhead.

[0044] In Figure 2 At block S208, the memory is loaded on demand and the exception conditions of the target program are handled during the fuzz test.

[0045] During the execution of the fuzz test, access to unmapped memory regions may occur. When the unicorn accesses an unmapped memory region, it sends a memory request to the probe component through the UC_HOOK_MEM_UNMAPPED API interface. The probe component checks whether the memory page is valid, and if the memory is valid, it processes the request and maps it into the unicorn engine. If the memory is successfully mapped, the emulation continues, and the memory region is cached to disk; if the requested memory is invalid, the request is denied, and a SIGSEGV signal (segmentation violation) is triggered, reporting the crash information to the AFL. The AFL receives the crash information and performs subsequent vulnerability analysis and repair. Each memory access is strictly checked and processed, ensuring the stability of the fuzz test and providing detailed crash reports for analysis in the event of memory access problems.

[0046] In one embodiment of the present disclosure, during simulation, when the target program crashes due to invalid memory access, the captured crash information is reported to AFL. The crash information includes the memory location of the crash, stack information, and related input data. If the requested memory cannot be mapped, the probe component creates a rejection file in the input directory. The rejection file is used to mark the memory area as inaccessible and provide a record for subsequent testing. For failed memory requests, the probe component creates an empty file in the input directory, marking the memory area as unavailable for further mapping, and waits for subsequent inspection.

[0047] When the simulated target program references an unmapped memory region again, the probe component checks whether the memory region has been requested in the previous run. If the memory region has been requested and successfully mapped in the previous run, the cached data will continue to be used. If the memory region has been rejected, the processing of the memory region will be stopped.

[0048] Specifically, the probe wrapper's output directory can be periodically polled, awaiting the dump results for the memory region. If the probe wrapper's output directory contains dumped memory data, this data can be used without re-requesting the mapping, thereby improving testing efficiency. If the probe wrapper's output directory contains a rejection file, indicating that the memory region cannot be dumped or processed, the current operation is terminated and the memory region is marked as rejected.

[0049] By dynamically mapping and loading memory on demand, Unicorefuzz avoids frequent interaction with the virtual machine during fuzz testing, effectively reducing memory overhead and avoiding unnecessary resource waste during fuzz testing. Combined with virtual machine breakpoint control and efficient memory management of the probe component, Unicorefuzz provides an efficient and flexible way to test for potential vulnerabilities in the kernel and applications.

[0050] Figure 3 1 is a schematic diagram of the fuzzy test execution process according to an embodiment of the present disclosure. Figure 3As shown in Figure 1, in fuzz testing, seeds are used as initial input files, providing AFL with preliminary test input. A major advantage of AFL fuzz testing is its ability to automatically detect crashes. Combined with the Unicorn emulator, it can effectively capture abnormal behavior of the target program and generate feedback reports. The spawns mechanism in AFL is used to create new processes and execute the target program. After each fork, a new child process is generated to execute different fuzz inputs. When starting fuzzing, you must first ensure that the Unicorn engine can correctly load the target kernel module or kernel image. You can use uc.mem_map() to map kernel space and ensure it is compatible with the target platform. When using AFL with Unicorn for fuzz testing, AFL mutates the seeds and executes the target program simulation until a crash or abnormal behavior is detected.

[0051] In the Unicorn engine, breakpoints are set to trigger breakpoint handlers to capture the program's state at specific locations. When AFL detects a program crash, it records a feedback report. This report includes a CrashID: a unique identifier used to distinguish between crashes; a seed file: the input data that caused the crash; and a backtrace log: the stack trace at the time of the crash, which helps analyze the cause of the crash.

[0052] Figure 4 : is a schematic block diagram of a kernel fuzzy test device based on unicorn simulation according to an embodiment of the present disclosure. Figure 4 As shown, the apparatus 400 may include a processor 410 and a memory 420 storing a computer program. When the computer program is executed by the processor 410, the apparatus 400 may perform the following operations: Figure 2 The steps of method 200 are shown. In one example, apparatus 400 can be a computer device or a cloud computing node. Apparatus 400 can create a Unicorn engine in the UnicoreFuzz harness, map all required memory areas, and set the initial values ​​of various registers according to the requirements of the target program; pass the fuzz test input data generated by AFL to the Unicorn engine; after the user specifies the target function address and breakpoints for the fuzz test, the Unicorn engine starts the AFL fork server to simulate the fuzz test of the target program; and, during the fuzz test, load memory on demand and handle exceptions in the target program.

[0053] In some embodiments of the present disclosure, the device 400 can create a unicorn engine in the harness of unicorefuzz and set the processor architecture; map the memory area required by the target program to the unicorn engine, load the binary code of the target program into the mapped memory area; and set the initial value of the register according to the needs of the target program.

[0054] In some embodiments of the present disclosure, the device 400 writes the input data that needs to be fuzz tested into the simulated memory through the mem_write() function; if the input data needs to modify the content of the register, the content of the register is modified through the reg_write() function.

[0055] In some embodiments of the present disclosure, the device 400 can start the AFL fork server and begin to perform simulated fuzz testing after the user specifies the address and breakpoint of the target function of the fuzz test in the probe wrapper; when performing fuzz testing, the unicorn engine is in an active or paused state, and a communication channel is established between the probe component and AFL; when the specified breakpoint is triggered, the execution is suspended and waits for a dynamic mapping memory request.

[0056] In some embodiments of the present disclosure, the device 400 can notify the probe component through the UC_HOOK_MEM_UNMAPPED application program interface when Unicorn accesses an unmapped memory area; the probe component checks whether the requested memory area is valid. If the requested memory is valid, the request is processed and mapped to the Unicorn engine. If the memory is successfully mapped, the simulation continues and the memory area is cached to the disk; if the requested memory is invalid, the request is rejected, and a SIGSEGV signal is triggered to report the crash information to AFL.

[0057] In some embodiments of the present disclosure, the device 400 can report the captured crash information to AFL when the target program crashes due to invalid memory access. The crash information includes the memory location of the crash, stack information, and related input data. If the requested memory cannot be mapped, the probe component creates a rejection file in the input directory. For failed memory requests, the probe component creates an empty file in the input directory, marks that the memory area cannot be mapped further, and waits for subsequent inspection.

[0058] In some embodiments of the present disclosure, the device 400 can, when the target program references an unmapped memory area again, have the probe component check whether the memory area has been requested in a previous run; if the memory area has been requested and successfully mapped in a previous run, continue to use the cached data; if the memory area has been rejected, stop processing the memory area.

[0059] In some embodiments of the present disclosure, the device 400 can periodically poll the output directory of the detection wrapper and wait for the dump result of the memory area; if the output directory of the detection wrapper contains dumped memory data, continue to use these data; if the output directory of the detection wrapper contains a rejection file, it means that the memory area cannot be dumped or processed, stop the current operation, and mark the memory area as rejected for processing.

[0060] In an embodiment of the present disclosure, the processor 410 may be, for example, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a processor based on a multi-core processor architecture, etc. The memory 420 may be any type of memory implemented using data storage technology, including but not limited to random access memory, read-only memory, semiconductor-based memory, flash memory, disk storage, etc.

[0061] Furthermore, in an embodiment of the present disclosure, the apparatus 400 may also include an input device 430, such as a keyboard, a mouse, etc. In addition, the apparatus 400 may also include an output device 440, such as a display, etc.

[0062] In other embodiments of the present disclosure, a computer-readable storage medium storing a computer program is further provided, wherein the computer program can achieve the following when executed by a processor: Figure 2 The steps of the kernel fuzz testing method based on Unicorn simulation are shown.

[0063] In summary, according to the kernel fuzz testing method and device based on unicorn simulation of the embodiments of the present disclosure, memory is loaded only when needed through a dynamic memory mapping mechanism, which effectively reduces unnecessary memory overhead and ensures the efficiency of fuzz testing. At the same time, through interaction with the virtual machine, breakpoints can be set at specific addresses of the target function and accurately located to the specific address of the target function, enabling high-precision vulnerability detection. Unicorefuzz does not need to interact with real hardware, but only relies on virtual machines and simulation technology. It can support fuzz testing of arbitrary architectures and binary-level codes, and can perform efficient and accurate fuzz testing in complex target environments.

[0064] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the apparatus and method according to multiple embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of a module, program segment or instruction includes one or more executable instructions for realizing the specified logical function. In some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart, can be implemented by a dedicated hardware-based system that performs the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0065] Unless the context clearly indicates otherwise, as used herein and in the appended claims, the singular includes the plural, and vice versa. Thus, when referring to the singular, the plural of the corresponding term is generally included. Similarly, the words "include" and "comprising" are to be interpreted as inclusive rather than exclusive. Likewise, the terms "include" and "or" should be interpreted as inclusive unless such interpretation is expressly prohibited herein. Where the term "example" is used herein, particularly when it follows a group of terms, "example" is merely exemplary and illustrative and should not be considered exclusive or comprehensive.

[0066] Further aspects and scope of adaptability become apparent from the description provided herein. It should be understood that various aspects of the present application can be implemented individually or in combination with one or more other aspects. It should also be understood that the description and specific embodiments herein are intended to be illustrative only and are not intended to limit the scope of the present application.

[0067] Several embodiments of the present disclosure have been described in detail above, but it is obvious that those skilled in the art can make various modifications and variations to the embodiments of the present disclosure without departing from the spirit and scope of the present disclosure. The scope of protection of the present disclosure is defined by the appended claims.

Claims

1. A kernel fuzz testing method based on unicorn simulation, characterized in that: The method comprises: Create the Unicorn engine in the UnicoreFuzz harness, map all required memory areas and set the initial values ​​of each register according to the needs of the target program; Pass the fuzzing input data generated by AFL to the unicorn engine; After the user specifies the target function address and breakpoint for the fuzz test, the Unicorn engine starts the AFL forkserver to simulate the fuzz test of the target program; and Load memory on demand during fuzz testing and handle exceptions of the target program.

2. The kernel fuzz testing method based on unicorn simulation according to claim 1 is characterized in that The steps involved in creating the Unicorn engine in the UnicoreFuzz harness, mapping all required memory regions, and setting the initial values ​​of various registers as needed by the target program include: Create a unicorn engine in the unicorefuzz harness and set the processor architecture; Mapping the memory area required by the target program to the Unicorn engine, and loading the binary code of the target program into the mapped memory area; and Set the initial value of the register according to the needs of the target program.

3. The kernel fuzz testing method based on unicorn simulation according to claim 1 is characterized in that Passing the fuzz test input data generated by AFL to the unicorn engine includes: Unicorefuzz uses the avatar2 framework to interact with the GDB stub; Write the input data to be fuzzed into the simulated memory via the mem_write() function; and If the input data needs to modify the contents of the register, the reg_write() function is used to modify the contents of the register.

4. The kernel fuzz testing method based on unicorn simulation according to claim 1 is characterized in that After the user specifies the target function address and breakpoint for the fuzz test, the Unicorn engine starts the AFL fork server to simulate the fuzz test of the target program, including: After the user specifies the address and breakpoint of the target function of the fuzz test in the detection wrapper, the AFL fork server is started to perform the simulated fuzz test; While fuzzing, the Unicorn engine is active or paused, and a communication channel is established between the probe component and AFL; and Pauses execution when the specified breakpoint is hit, and waits for a dynamic memory mapping request.

5. The kernel fuzz testing method based on unicorn simulation according to claim 4 is characterized in that, The on-demand loading of memory and handling of abnormal situations of the target program during the fuzz testing process include: When unicorn requests access to an unmapped memory area, the probe component is notified via the UC_HOOK_MEM_UNMAPPED application program interface; The probe component checks whether the requested memory area is valid. If the requested memory is valid, it processes the request and maps it to the Unicorn engine. If the memory is successfully mapped, the simulation continues and caches the memory area to disk. If the requested memory is invalid, the request is denied and a SIGSEGV signal is triggered, reporting the crash information to AFL.

6. The kernel fuzz testing method based on unicorn simulation according to claim 5 is characterized in that: If the requested memory is invalid, the request is rejected and a SIGSEGV signal is triggered, reporting the crash information to AFL, including: When the target program crashes due to invalid memory access, the captured crash information is reported to AFL. The crash information includes the crash memory location, stack information, and related input data. If the requested memory cannot be mapped, the probe component creates a reject file in the input directory; and For failed memory requests, the probe component creates an empty file in the input directory, marking the memory area as unmappable and waiting for subsequent inspection.

7. The kernel fuzz testing method based on unicorn simulation according to claim 5 is characterized in that: The on-demand loading of memory and handling of abnormal situations of the target program during the fuzz testing process also includes: When the simulated target program references the unmapped memory area again, the probe component checks whether the memory area has been requested in a previous run; If the memory region has been requested and successfully mapped in a previous run, continue to use the cached data; if the memory region has been rejected, stop processing the memory region.

8. The kernel fuzz testing method based on unicorn simulation according to claim 7 is characterized in that: The probe component checks whether the memory area has been requested in the previous operation, including: Regularly poll the output directory of the wrapper and wait for the dump results of the memory area; If the probe wrapper's output directory contains dumped memory data, continue to use that data; If the output directory of the probe wrapper contains a rejection file, it means that the memory area cannot be dumped or processed. Stop the current operation and mark the memory area as rejected for processing.

9. A kernel fuzz testing device based on unicorn simulation, characterized in that: The device comprises: at least one processor; and at least one memory storing a computer program; Wherein, when the computer program is executed by the at least one processor, the device performs the steps of the kernel fuzz testing method based on unicorn simulation according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the computer program implements the steps of the kernel fuzz testing method based on unicorn simulation according to any one of claims 1 to 8.

Images