A kernel fuzzing method and apparatus based on unicorn simulation

Abstract

The embodiments of this disclosure provide a kernel fuzzing method and apparatus based on unicorn simulation. The method includes: creating a unicorn engine in the harness of unicorefuzz, mapping all required memory regions and setting the initial values ​​of each register 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 breakpoints for the fuzzing, the unicorn engine starts the AFL fork server to simulate the execution of the fuzzing of the target program; and loading memory as needed and handling abnormal situations of the target program during the fuzzing process.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of fuzzing technology, specifically to a kernel fuzzing method, apparatus, and computer-readable storage medium storing a computer program based on unicorn simulation. Background Technology

[0002] In the field of cybersecurity, fuzzing is an important vulnerability discovery method. It involves providing unexpected input to a target system and monitoring anomalous results to uncover potential program errors. Although fuzzing is widely used for security vulnerability detection in application-layer software, its application at the operating system and kernel levels remains relatively limited.

[0003] The kernel space code is the core of the operating system kernel, responsible for managing system resources, executing system calls, and handling core functions. Due to the complexity and privilege levels of the kernel space code, various vulnerabilities and security issues may exist, such as memory overflows, buffer overflows, and integer overflows. These vulnerabilities can lead to security risks such as system crashes, denial-of-service attacks, privilege escalation, or information leaks. Therefore, kernel testing needs to cover not only more complex execution paths but also multiple levels, including hardware interactions and external device drivers.

[0004] Several well-known projects have successfully fuzzed kernel subsystems, drivers, and interfaces. For example, Trinity, DIFUZE, Syzkaller, and In-Kernel AFL demonstrate different techniques and methods for achieving this goal.

[0005] Syzkaller and In-Kernel AFL both utilize coverage-based fuzzing methods. Syzkaller improves testing efficiency by tracing the kernel's execution path and extracting coverage data, while In-Kernel AFL accelerates fuzzing through shared memory regions and kernel memory mapping. Trinity, with its user-friendly design, allows for the discovery of vulnerabilities through system calls even without complex description files. TriforceAFL and kAFL utilize virtualization technologies (QEMU and KVM) and hardware-assisted code coverage techniques (such as Intel's Processor Trace) to improve fuzzing performance and efficiency. TriforceAFL addresses virtualization overhead through complete system emulation and state recovery, while kAFL significantly increases execution speed per second through hardware-level coverage tracing. However, kernel fuzzing for arbitrary architectures has not yet been implemented. Summary of the Invention

[0006] The embodiments described herein provide a kernel fuzzing method, apparatus, and computer-readable storage medium storing a computer program based on unicorn simulation. Combining simulation technology and dynamic memory mapping, it effectively solves common performance bottlenecks in fuzzing and is suitable for kernel or binary testing tasks that require efficient memory management.

[0007] According to a first aspect of this disclosure, a kernel fuzzing method based on unicorn simulation is provided, comprising: creating a unicorn engine in the harness of unicorefuzz, mapping all required memory regions and setting the initial values ​​of each register according to the needs of the target program; passing fuzzing input data generated by AFL to the unicorn engine; after the user specifies the target function address and breakpoints for the fuzzing, the unicorn engine starts the AFL fork server to simulate the execution of the fuzzing of the target program; and loading memory as needed and handling exceptions in the target program during the fuzzing process.

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

[0009] In some embodiments of this disclosure, passing the fuzzing input data generated by AFL to the unicorn engine includes: Unicorefuzz interacting with the GDB stub using the avatar2 framework; writing the input data to be fuzzed into simulated memory using the mem_write() function; and modifying the register contents using the reg_write() function if the input data requires modification of the register contents.

[0010] In some embodiments of this disclosure, after the user specifies the address of the target function and breakpoints for the fuzz test, the unicorn engine starts the AFL fork server to simulate the fuzz test of the target program. This includes: after the user specifies the address of the target function and breakpoints for the fuzz test in the probe wrapper, starting the AFL fork server and beginning to execute the simulated fuzz test; during the fuzz test, the unicorn engine is in an active or paused state and establishes a communication channel between the probe component and AFL; when the specified breakpoints are triggered, execution is paused and the system waits for a dynamically mapped memory request.

[0011] In some embodiments of this disclosure, loading memory on demand and handling exceptions in the target program during fuzzing includes: when unicorn requests access to an unmapped memory region, it notifies the probe component via 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, it processes the request and maps it into the unicorn engine; if the memory is successfully mapped, it continues to execute the simulation and caches the memory region to disk; if the requested memory is invalid, it rejects the request and triggers the SIGSEGV signal, reporting the crash information to AFL.

[0012] In some embodiments of this disclosure, if the requested memory is invalid, the request is rejected and a SIGSEGV signal is triggered to report the crash information to the AFL. This includes: when the target program crashes due to invalid memory access, the captured crash information is reported to the AFL, 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 failed memory requests, the probe component creates an empty file in the input directory, marking that the memory region cannot be mapped further, and waits for subsequent checks.

[0013] In some embodiments of this disclosure, loading memory on demand and handling exceptions of the target program during fuzzing further includes: when the simulated target program references an unmapped memory region again, the probe component checks whether the memory region has been requested in a previous run; if the memory region has been requested and successfully mapped in a previous run, the cached data continues to be used; if the memory region has been rejected, processing of the memory region is stopped.

[0014] In some embodiments of this disclosure, the probe component checks whether the memory region has been requested in previous runs, including: periodically polling the output directory of the probe wrapper and waiting for the dump results of the memory region; if the output directory of the probe wrapper contains dumped memory data, then continue to use the data; if the output directory of the probe wrapper contains a rejection file, indicating that the memory region cannot be dumped or processed, stop the current operation, and mark the memory region as rejected.

[0015] According to a second aspect of this disclosure, a kernel fuzzing apparatus based on unicorn simulation is provided. The apparatus includes 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 apparatus:

[0016] In some embodiments of this disclosure, the computer program, when executed by at least one processor, causes the device to operate as follows:

[0017] In some embodiments of this disclosure, the computer program, when executed by at least one processor, causes the device to operate as follows:

[0018] According to a third aspect of this 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 kernel fuzzing method based on unicorn simulation according to a first aspect of this disclosure.

[0019] The kernel fuzzing method and apparatus based on unicorn simulation according to embodiments of this disclosure, through a dynamic memory mapping mechanism, loads memory only when needed, effectively reducing unnecessary memory overhead and ensuring the high efficiency of fuzzing. Simultaneously, through interaction with the virtual machine, breakpoints can be set at specific addresses of the target function and precisely located, enabling high-precision vulnerability detection. Unicorefuzz does not require interaction with real hardware, relying only on virtual machines and simulation technology, and can support fuzzing of arbitrary architectures and binary-level code, enabling efficient and accurate fuzzing in complex target environments. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly described below. It should be understood that the drawings described below only relate to some embodiments of this disclosure and are not intended to limit this disclosure, wherein:

[0021] Figure 1 A schematic diagram illustrating the internal workflow of the Unicorefuzz fork service according to an embodiment of this disclosure is shown.

[0022] Figure 2 An exemplary flowchart of a kernel fuzzing method based on unicorn simulation according to an embodiment of the present disclosure is shown;

[0023] Figure 3 This is a schematic diagram of the fuzzing test execution process according to an embodiment of the present disclosure;

[0024] Figure 4 This is a schematic block diagram of a kernel fuzzing testing apparatus based on unicorn simulation according to an embodiment of the present disclosure.

[0025] It should be noted that the elements in the attached diagram are schematic and not drawn to scale. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are also within the scope of protection of this disclosure.

[0027] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject matter pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having meanings consistent with their meanings in the context of the specification and in the relevant art, and shall not be interpreted in an idealized or overly formal form unless otherwise explicitly defined herein. Furthermore, terms such as “first” and “second” are used only to distinguish one component (or part of a component) from another component (or another part of a component).

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

[0029] AFL++ is an enhanced version of AFL. AFL provides a QEMU mode that guides test case generation by monitoring program execution paths and coverage. AFL's QEMU mode uses a modified QEMU emulation program that reports the covered branches to AFL after each basic block execution. To improve speed, during fuzzing, a fork service resets the state to the initial state of a fully loaded process. After forking the child process, the parent process also translates the block and caches the results, so that the costly translation is not needed for subsequent forks. Control is returned to QEMU after each block, and QEMU passes coverage information to AFL via shared memory by calling the `afl_maybe_log` function.

[0030] To perform feedback-driven fuzzing of kernel space code, Unicorefuzz is built on top of AFL-unicorn. AFL-unicorn combines AFL and unicorn, applying AFL's intelligent testing strategies to the unicornEngine-simulated environment, enabling deep exploration and vulnerability discovery of previously inaccessible binary code blocks. In AFL-unicorn, the emulator adds code to the end of each basic block, sends coverage information to AFL, and starts AFL's fork service after the emulator setup is complete. To speed up the process, the parent process caches the basic blocks. AFL itself only needs to start the external program and generate input.

[0031] Figure 1 A schematic diagram illustrating the internal workflow of the Unicorefuzz fork service according to an embodiment of this disclosure is shown. Figure 1 As shown, the Prabe wrapper is used to enable the fuzzing framework to interact with external target programs. It relies on the Avatar2 framework, which provides more feedback to the fuzzer by simulating and executing the target's code, thus helping to find vulnerabilities. Through Avatar2, Unicorefuzz can connect to external target programs such as binary analysis tools, any GDB session, PANDA and QEMU virtual machines, and smart devices. This allows Unicorefuzz to support multiple environments, improving its compatibility across different platforms. Avatar2 can dump the process's memory and registers, using this information for subsequent analysis, fuzzing, and vulnerability discovery.

[0032] First, AFL starts the external target program and initializes the unicorn engine to load the initial kernel memory. The kernel portion of this external program is simulated using the unicorn engine. After loading the kernel memory, the external program forks child processes. Each child process executes independently, responsible for executing its part of the fuzzing process. It simulates the execution of the target binary program, mimics the program's memory usage during execution, and reports the memory and status information encountered during execution back to the parent process. Each child process continues to run until an exception, crash, or other exit condition occurs.

[0033] If a child process encounters a new memory region or translates a new code block during execution, it will report back to the parent process via a pipe. Pipes are a highly efficient inter-process communication (IPC) mechanism that allows child processes to pass their memory access requests and status information to the parent process. The parent process then performs necessary memory mapping, translation, or other processing based on the feedback data.

[0034] The parent process handles 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. This allows these memory blocks to be used directly in subsequent tests without retranslation. The parent process also manages and saves the runtime state of child processes, ensuring each child process can run independently and has its own required memory mappings. If a child process needs to access an unmapped memory region, the parent process triggers the memory mapping mechanism, loading the new memory region into the simulation environment for the child process to use. If a child process accesses an invalid memory region during fuzzing, such as an out-of-bounds access or illegal memory access, the process receives a SIGSEGV signal (segmentation fault), causing the child process to crash. When a crash occurs, the parent process receives the crash signal and feeds back the crash information to AFL. AFL records the crash information and continues running the fuzzing. The crash information includes the type of memory access error and the specific operation that caused the crash, allowing developers to further analyze the data.

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

[0036] To further illustrate the embodiments of this disclosure, Figure 2 An exemplary flowchart of a kernel fuzzing method based on unicorn simulation according to embodiments of the present disclosure is shown. Figure 2At box S202, create the unicorn engine in the unicorefuzz harness, map all the required memory regions, and set the initial values ​​of each register according to the needs of the target program.

[0037] Harness is an adaptation layer used to connect the target program with a fuzzing engine (such as AFL++). Its role is to convert the input data generated by the fuzzing engine into a format that the target program can understand, and to call the target program's interface at appropriate times to perform fuzzing. It is also responsible for collecting feedback information during the execution process, such as code coverage and crash information, to guide the fuzzing engine in generating new test cases.

[0038] During the fuzzing preparation phase, Unicorefuzz's harness creates a unicorn engine object, which is responsible for mapping the required memory regions. By selecting an appropriate processor architecture type and mapping multiple memory regions according to the target program's needs, ensuring the correct starting address and size for each region, the target program's binary code is loaded into the mapped memory regions. The Unicorn engine sets the initial values ​​of various registers according to the target program's requirements, and AFL generates the input data needed for fuzzing.

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

[0040] According to one embodiment of this disclosure, Unicorefuzz utilizes the avatar2 framework to interact with the GDB stub (debugger) to enable debugging and control of the target program. AFL requires one or more initial input files (seeds), which serve as the basis for mutations. AFL can generate mutated input data by: randomly altering bytes of the input data (e.g., replacing, inserting, deleting bytes, etc.); changing certain bits of the input for fine-grained mutation; inserting random bytes into the input data; and pruning the input data to generate mutated data of different lengths. The fuzzing input data generated by AFL can be passed to the Unicore engine using the mem_write() function. If the target program modifies registers via parameters or memory data, it can be modified using the reg_write() function. These functions ensure that the fuzzed input generated by AFL is correctly passed to the target program to test its performance under different inputs.

[0041] Next, in box S206, 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 execution of the fuzz test on the target program.

[0042] According to one embodiment of this disclosure, the user needs to set breakpoints and the memory area where AFL input data should be stored in the code's harness, and wait for the breakpoints to be triggered. These inputs and breakpoints trigger corresponding operations in the simulator (such as a virtual machine) to ensure that the data can be accurately transmitted. After the user specifies the address of the target function and breakpoints for fuzzing in the probe wrapper, the AFL fork server is started to begin executing simulated fuzzing. The fork server is an important component in AFL, responsible for managing the creation of child processes, enabling AFL to run multiple child processes and perform fuzzing on them. This allows AFL to execute tests in parallel, thereby accelerating the vulnerability discovery process. During fuzzing, the unicorn engine is either active or paused, and a communication channel is established between the probe component and AFL to manage memory loading.

[0043] Execution is paused when a specified breakpoint is triggered, and the program waits for a dynamically mapped memory request. The goal of dynamic memory mapping is to avoid fuzzing by dumping the entire memory of the target program, as this would incur unnecessary memory overhead.

[0044] exist Figure 2 At box S208, memory is loaded on demand and exceptions in the target program are handled during fuzzing.

[0045] During fuzzing, access to unmapped memory regions may occur. When unicorn accesses an unmapped memory region, it sends a memory request to the probe component via the UC_HOOK_MEM_UNMAPPED API interface. The probe component checks if the memory page is valid. If the memory is valid, it processes the request and maps it into the unicorn engine. If the memory is successfully mapped, the simulation continues, and the memory region is cached to disk. If the requested memory is invalid, the request is rejected, a SIGSEGV (segmentation fault) signal is triggered, and a crash report is sent to AFL. AFL receives the crash report and performs subsequent vulnerability analysis and remediation. Each memory access undergoes rigorous checking and processing, ensuring the stability of the fuzzing and providing detailed crash reports for analysis when memory access issues occur.

[0046] In one embodiment of this disclosure, during simulation, when the target program crashes due to invalid memory access, the captured crash information is reported to AFL. This 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 to mark the memory region as inaccessible and to provide a record for subsequent tests. For failed memory requests, the probe component creates an empty file in the input directory to mark the memory region as unmappable and awaits further 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 a previous run. If the memory region was requested and successfully mapped in a previous run, the cached data continues to be used; otherwise, processing of the memory region is stopped.

[0048] Specifically, the output directory of the probe wrapper can be periodically polled, waiting for the dump results of the memory region. If the output directory of the probe wrapper contains dumped memory data, this data can continue to be used without re-requesting mapping, thus improving test efficiency. If the output directory of the probe wrapper contains a rejection file, it indicates that the memory region cannot be dumped or processed, the current operation is stopped, and the memory region is marked as rejected.

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

[0050] Figure 3 This is a schematic diagram of the fuzzing test execution process according to an embodiment of the present disclosure. (Refer to...) Figure 3As shown, in fuzzing, seeds are files used as initial inputs, providing AFL with preliminary test inputs. A major advantage of AFL fuzzing is its ability to automatically detect crash points. Combined with the Unicorn simulator, 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. It generates a new child process after each fork to execute different fuzzing inputs. When starting fuzzing, it is first necessary to ensure that the Unicorn engine can correctly load the target kernel module or kernel image. The kernel space can be mapped using `uc.mem_map()`, ensuring compatibility with the target platform. When using AFL with Unicorn for fuzzing, AFL mutates seeds and executes simulations of the target program until a crash or abnormal behavior is detected.

[0051] In the unicorn engine, breakpoints are set to trigger breakpoint handlers, capturing the program's state at specific points. When AFL detects a program crash, it logs a feedback report. This report includes: CrashID (a unique identifier used to distinguish different crashes); seed file (the input data that caused the crash); and backtrack log (stack information at the time of the crash, aiding in crash analysis).

[0052] Figure 4 This is a schematic block diagram of a kernel fuzzing apparatus based on unicorn simulation according to embodiments of the present disclosure. Figure 4 As shown, the device 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 device 400 is made capable of performing actions such as... Figure 2 The steps of method 200 are shown. In one example, device 400 can be a computer device or a cloud computing node. Device 400 can create a unicorn engine in the unicorefuzz harness, map all required memory regions 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 breakpoints for the fuzzing, the unicorn engine starts the AFL fork server to simulate the execution of the fuzzing of the target program; and, during the fuzzing process, load memory as needed and handle exceptions in the target program.

[0053] In some embodiments of this disclosure, the apparatus 400 can create a unicorn engine and set the processor architecture in the harness of unicorefuzz; map the memory region required by the target program to the unicorn engine; load the binary code of the target program into the mapped memory region; and set the initial values ​​of the registers according to the needs of the target program.

[0054] In some embodiments of this disclosure, the apparatus 400 writes the input data to be fuzzed into simulated memory using the mem_write() function; if the input data requires modification of the register contents, the register contents are modified using the reg_write() function.

[0055] In some embodiments of this disclosure, the apparatus 400 can start the AFL fork server and begin executing a simulated fuzz test after the user specifies the address of the target function and breakpoints for the fuzz test in the probe wrapper. During the fuzz test, the unicorn engine is either active or paused and a communication channel is established between the probe component and AFL. When a specified breakpoint is triggered, execution is paused and the system waits for a dynamically mapped memory request.

[0056] In some embodiments of this disclosure, when unicorn accesses an unmapped memory region, the device 400 can notify the probe component via 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 simulation continues and the memory region is cached to 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 this disclosure, when the target program crashes due to invalid memory access, the device 400 can report the captured crash information 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. For failed memory requests, the probe component creates an empty file in the input directory, marks the memory region as unmappable, and waits for subsequent checks.

[0058] In some embodiments of this disclosure, when the intended target program references an unmapped memory region again, the probe component checks whether the memory region has been requested in a previous run; if the memory region has been requested and successfully mapped in a previous run, the cached data continues to be used; if the memory region has been rejected, processing of the memory region is stopped.

[0059] In some embodiments of this disclosure, the device 400 may periodically poll the output directory of the probe wrapper and wait for the dump results of the memory region; if the output directory of the probe wrapper contains dumped memory data, then the data is used; if the output directory of the probe wrapper contains a rejection file, it indicates that the memory region cannot be dumped or processed, the current operation is stopped, and the memory region is marked as rejected.

[0060] In embodiments of this disclosure, 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. Memory 420 may be any type of memory implemented using data storage technologies, including but not limited to random access memory, read-only memory, semiconductor-based memory, flash memory, disk storage, etc.

[0061] Furthermore, in embodiments of this disclosure, device 400 may also include input device 430, such as a keyboard, mouse, etc. Additionally, device 400 may also include output device 440, such as a display, etc.

[0062] In other embodiments of this disclosure, a computer-readable storage medium storing a computer program is also provided, wherein the computer program, when executed by a processor, is capable of performing the following functions: Figure 2 The steps of the kernel fuzzing method based on unicorn simulation are shown.

[0063] In summary, the kernel fuzzing method and apparatus based on unicorn simulation according to the embodiments of this disclosure, through a dynamic memory mapping mechanism, loads memory only when needed, effectively reducing unnecessary memory overhead and ensuring the high efficiency of fuzzing. Simultaneously, through interaction with the virtual machine, breakpoints can be set at specific addresses of the target function and the specific address of the target function can be precisely located, enabling high-precision vulnerability detection. Unicorefuzz does not require interaction with real hardware, relying only on virtual machines and simulation technology, and can support fuzzing of arbitrary architectures and binary-level code, enabling efficient and accurate fuzzing in complex target environments.

[0064] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatuses and methods according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0065] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

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

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

Claims

1. A kernel fuzzing method based on unicorn emulation, characterized in that, The method comprises: 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, wherein: 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, and 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; passing the fuzz test input data generated by AFL to the unicorn engine, wherein: unicornfuzz interacts with the GDB stub using the avatar2 framework; writing the input data required for fuzz testing 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; after the user specifies the target function address and breakpoint of the fuzz test, the unicorn engine starts the forkserver of AFL to simulate the fuzz test of the target program, wherein: after the user specifies the address of the target function and the breakpoint of the fuzz test in the probe wrapper, start the fork server of AFL and begin to execute the simulated fuzz test; 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 AFL; pause the execution when the specified breakpoint is triggered, and wait for the request for dynamically mapping memory; and loading memory on demand and handling abnormal situations of the target program during the fuzz test.

2. The unicorn emulation based kernel fuzz testing method of claim 1, wherein, The loading memory on demand and handling abnormal situations of the target program during the fuzz test comprises: when the unicorn requests to access an unmapped memory region, the UC_HOOK_MEM_UNMAPPED application programming interface is used to notify the probe component; the probe component checks whether the requested memory region is valid, and if the requested memory is valid, processes the request and maps it to the unicorn engine, and if the memory is successfully mapped, continues to execute the simulation and caches the memory region to the disk; if the requested memory is invalid, reject the request and trigger the SIGSEGV signal, and report the crash information to AFL.

3. The unicorn emulation based kernel fuzz testing method of claim 2, wherein, The rejection of the request if the requested memory is invalid, triggering the SIGSEGV signal, and reporting the crash information to AFL comprises: when the target program crashes due to invalid memory access, the captured crash information is reported to AFL, and the crash information includes the crashed memory location, stack information and related input data; if the requested memory cannot be mapped, the probe component creates a rejection file in the input directory; and for the failed memory request, the probe component creates an empty file in the input directory to mark that the memory region cannot be continuously mapped, and waits for subsequent checks.

4. The unicorn emulation based kernel fuzz testing method of claim 2, wherein, The loading memory on demand and handling exception of target program during 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 previous runs; If the memory region has been requested and successfully mapped in previous runs, continue using the cached data, if the memory region has been rejected, stop processing the memory region.

5. The unicorn emulation based kernel fuzz testing method of claim 4, wherein, The probe component checking whether the memory region has been requested in previous runs 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 dumped memory data, continue using the data; If the output directory of the probe wrapper contains a rejection file, indicating that the memory region cannot be dumped or processed, stop the current operation, and mark the memory region as rejected.

6. A kernel fuzzing device based on unicorn emulation, characterized in that, The apparatus comprises: at least one processor; and at least one memory having computer program stored therein; wherein 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 of any one of claims 1 to 5.

7. A computer readable storage medium storing a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the unicorn emulation based kernel fuzzing method of any one of claims 1 to 5.

Images