Fuzz testing optimization method and device based on input-context correspondence

Abstract

Embodiments of the present disclosure provide a method and device for optimizing fuzz testing based on input-context correspondence, which comprises: performing fuzz testing on a target program based on kAFL, hooking all comparison instructions and recording parameters in the comparison instructions; mutating the parameters in the comparison instructions to generate different mutated values; whenever a comparison operation is encountered in the execution of the target program, identifying the part related to the magic number, replacing the original input value with the mutated value to generate a new test case; identifying all check detection instructions and recording check information, modifying the check detection instructions to always be true to generate a preliminary queue; and verifying and repairing the inputs in the preliminary queue, and deciding whether to put them into the real queue according to whether the repaired inputs successfully trigger new coverage or expose new vulnerabilities.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of fuzz testing technology, and more specifically, to a fuzz testing optimization method, apparatus, and computer-readable storage medium storing a computer program based on the correspondence between input and context. Background Technology

[0002] Fuzzing has become a key component in testing the quality of software systems. In recent years, more intelligent feedback-driven fuzzing tools, such as AFL, have made significant progress in both academic research and industry. Two common problems in fuzzing are the magic number and validation checks. Example code is shown below:

[0003] if(u64(input)==u64("MAGICHDR"))

[0004] bug(1);

[0005] if(u64(input)==sum(input+2,len-2))

[0006] if(u64(input+4)==sum(input+2,1en-2)

[0007] if(input

[11] =='R'&&input

[12] =='Q')

[0008] bug(1);

[0009] The code above indicates that the first error will only be detected if the first 8 bytes of the input contain a specific magic number header. To trigger the second error, the input must contain the string "RQ" and two correct checksums. The probability of randomly creating an input that meets these conditions is negligible. Therefore, feedback-driven fuzzing struggles to generate new coverage, and the fuzzing process stagnates.

[0010] The main drawbacks of existing fuzzing techniques for the magic number problem are: 1. Lack of diversity in generating invalid and valid combinations: Magic byte arrays are typically used to construct valid input data. However, if the fuzzer relies too heavily on magic byte arrays, the input data may be limited to valid formats, failing to effectively explore the boundary behavior of the program when handling invalid inputs. This could lead to the omission of potential errors and vulnerabilities. 2. Reduced randomness in fuzzing: The core of fuzzing is generating highly random data to explore unknown program behavior. The use of magic byte arrays increases the structured nature of the generated data, thus limiting randomness and flexibility. 3. Excessive assumptions about application protocols and logic: The effectiveness of using magic byte arrays depends on certain prior assumptions about the target program, such as knowing which file format the target program parses. If the program's input format changes, the magic byte array may become invalid, reducing the applicability of fuzzing. 4. Insufficient coverage of complex paths: Magic byte arrays may limit the fuzzer's coverage to paths that handle normal inputs, but fail to trigger complex boundary conditions or exception handling paths. Therefore, hidden logical vulnerabilities or memory safety issues may be missed.

[0011] Another common challenge faced by fuzzing tools is how to efficiently handle validation scenarios.

[0012] if(u64(input)==sum(input+8,len-8))

[0013] if(u64(input+8)==sum(input+8,1en-16)

[0014] if(input

[16] =='R'&&input

[17] =='Q')

[0015] bug(2);

[0016] The main problem with the example code above is the presence of validation instructions. These validations hinder the effectiveness of fuzzing tools because they need to bypass or modify these validation conditions to trigger more paths or expose potential vulnerabilities. Existing methods, such as FLAYER, TAINTSCOPE, and T-FUZZ, rely on the same idea: first remove hard-coded validations, then fix them. TAINTSCOPE and T-FUZZ automatically detect critical validations and, once abnormal behavior is detected, use symbolic execution to fix them.

[0017] The main drawbacks of fuzzing in testing and verification include: 1. Difficulty in reaching deep logic: Fuzzing generates data randomly or with slight mutations by default. However, if the program under test performs strict validation on the input data at the front end, most randomly generated test inputs will fail the validation. This limits the code coverage of the program under test, triggering only shallow logic code and failing to test deeper paths. 2. Reduced fuzzing efficiency: Fuzzing output depends on feedback, and validation failures cause a large number of generated inputs to be discarded. This leads to a large number of invalid test iterations, wasting computational resources. 3. Inability to discover vulnerabilities before and after validation: If the fuzzer gets stuck in the validation phase, it can only detect logic related to input validation and will not further test more complex functional logic after validation, thus missing subsequent vulnerabilities. 4. Complex validation mechanisms increase parsing burden: In multi-nested validation logic, especially involving dynamic keys or encryption algorithms, fuzzing struggles to generate valid inputs.

[0018] To overcome these obstacles, advanced program analysis techniques, such as taint tracing and symbolic execution, are commonly employed; tools like ANGORA and T-FUZZ fall into this category. These methods typically require a fairly precise description of the environment, such as the behavior of library calls or the underlying operating system, and the platform instruction set needs to have exact semantics. Therefore, these methods are difficult to use on targets that use complex instruction set extensions or uncommon libraries and operating systems. Summary of the Invention

[0019] The embodiments described herein provide a fuzzing optimization method, apparatus, and computer-readable storage medium storing a computer program based on the correspondence between input and context. This method can bypass the performance bottleneck caused by magic number and checksum detection in traditional fuzzing and can still maintain high coverage and testing performance in complex program structures.

[0020] According to a first aspect of this disclosure, a fuzzing optimization method based on the correspondence between input and context is provided, comprising: performing fuzzing on a target program based on kAFL, hooking all comparison instructions and recording the parameters in the comparison instructions; mutating the parameters in the comparison instructions to generate different mutated values; whenever a comparison operation is encountered during the execution of the target program, identifying the part related to the magic number, replacing the original input value with the mutated value, and generating a new test case; identifying all verification and detection instructions and recording verification information, modifying the verification and detection instructions to always be true, and generating a preparatory queue; verifying and repairing the inputs in the preparatory queue, and deciding whether to include the repaired inputs in the real queue based on whether the repaired inputs successfully trigger new coverage or expose new vulnerabilities.

[0021] In some embodiments of this disclosure, fuzzing a target program based on kAFL includes: generating multiple inputs and passing them to the target program; collecting coverage information fed back after the target program is executed, the coverage information being trace data generated by IntelPT; mutating the inputs based on the collected coverage information; and inserting breakpoints in the target program and checking memory and register contents during execution using virtual machines provided by KVM-PT and QEMU-PT.

[0022] In some embodiments of this disclosure, hooking all comparison instructions and recording the parameters in the comparison instructions includes: using Intel PT hardware tracing to hook common comparison operations, compiler-generated optimization instructions, and function call instructions in the program; recording the parameters involved in the comparison operation, the parameters passed during the function call, and the parameters obtained by calculating the offset of the jump table.

[0023] In some embodiments of this disclosure, mutating the parameters in the comparison instruction to generate different mutated values ​​includes: performing addition or subtraction operations on the parameters involved in the comparison operation extracted from the seed pool, and applying various encoding strategies to generate different mutated values. The encoding strategies include inversion, zero extension or byte order conversion, C string conversion, ASCII conversion, and Memory(n).

[0024] In some embodiments of this disclosure, mutating the parameters in the comparison instruction to generate different mutated values ​​further includes: when it is detected that the called function contains at least two pointer-type parameters, extracting the first 128 bytes of the data pointed to by each pointer for input to subsequent mutation processing; for comparisons of the first n bytes of a specified length, randomly mutating the first n bytes, adjusting the byte order, simulating different input situations, generating special cases through mutation, and checking whether abnormal behavior is triggered; for comparisons from the starting position to the null character, simulating different inputs by changing the first few bytes of the string, and inserting a null character if there is no null character in the input data so that the test can cover the case where the null character is the terminator; when the test involves comparisons of strings and byte arrays, providing test input by dynamically generating, filtering, and utilizing a specific dictionary containing consecutive non-zero bytes and non-0xff bytes.

[0025] In some embodiments of this disclosure, whenever a comparison operation is encountered during the execution of the target program, identifying the part related to the magic number, replacing the original input value with the mutated value, and generating a new test case includes: adding a predetermined number of random bytes to the input data to change the pattern of the input data; initially labeling the input data to identify similar patterns in the input data; and when comparing two or more versions of the input, only mutating the input and replacing the original input value with the mutated value when a similar pattern is found at the same offset, thereby generating a new test case.

[0026] In some embodiments of this disclosure, identifying all verification detection instructions and recording verification information, modifying verification detection instructions to always be true, and generating a preparatory queue includes: extracting all comparison operations from the program using Intel PT hardware tracing, generating a list of comparison operations, extracting variation patterns in the input by comparing different versions of the input value; if similar variation patterns appear in multiple input versions, these patterns are identified as verification-related instructions; if both parameters of the comparison operation are variables or pointers rather than hard-coded constants, the comparison operation is determined to be a verification-related instruction; checking whether the pattern depends on multiple bytes of the input and changes in different versions, if it changes, it is identified as a verification-related instruction; modifying the identified verification detection instructions to always be true, causing the input to bypass these verification logics and enter a deeper path of the program, generating a preparatory queue.

[0027] In some embodiments of this disclosure, verifying and repairing inputs in the preparatory queue, and deciding whether to add the repaired input to the real queue based on whether the repaired input successfully triggers a new overwrite or exposes a new vulnerability, includes: modifying specific fields in the input according to the pattern in the modification instruction to make them conform to the expected format of the target program, restoring information in the program context, and making the input logically match the target program; executing the repaired input on the unmodified real target program, and if the repaired input can trigger a new overwrite, adding the input to the real queue, otherwise discarding the input from the preparatory queue.

[0028] According to a second aspect of this disclosure, a fuzzing optimization apparatus based on the correspondence between input and context 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 causes the following: fuzzing of the target program based on kAFL, hooking all comparison instructions and recording the parameters in the comparison instructions; mutating the parameters in the comparison instructions to generate different mutated values; whenever a comparison operation is encountered during the execution of the target program, identifying the part related to the magic number, replacing the original input value with the mutated value, and generating new test cases; identifying all verification and detection instructions and recording verification information, modifying the verification and detection instructions to always be true, and generating a preparatory queue; verifying and repairing the inputs in the preparatory queue, and deciding whether to include the repaired input in the real queue based on whether the repaired input successfully triggers a new overlay or exposes a new vulnerability.

[0029] 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 fuzzing optimization method based on the input-context correspondence according to the first aspect of this disclosure.

[0030] The fuzzing method and apparatus based on the correspondence between input and context, according to embodiments of this disclosure, perform fuzzing on a target program using the kAFL framework. By leveraging hardware tracing technology to hook and compare instructions and record parameters, it can identify the relationship between input data and program state, helping fuzzing tools more effectively select the paths and mutation points to be tested, avoiding blind trial and error, thereby improving efficiency. By establishing a connection between input and program state, it can more specifically generate inputs that can trigger specific program behaviors, reducing the inefficiency caused by random mutations. It can bypass the performance bottlenecks caused by magic numbers and checksum detection in traditional fuzzing, and maintain high coverage and testing effectiveness even in complex program structures. Attached Figure Description

[0031] 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:

[0032] Figure 1 An exemplary flowchart of a fuzz testing optimization method based on input-context correspondence according to an embodiment of the present disclosure is shown;

[0033] Figure 2 This is a schematic diagram illustrating the solution to the magic number problem in the feedback-driven fuzzy testing method according to an embodiment of this disclosure;

[0034] Figure 3 This is a schematic diagram illustrating a solution to the verification problem in a feedback-driven fuzz testing method according to an embodiment of the present disclosure;

[0035] Figure 4 This is a schematic block diagram of a fuzzy testing optimization apparatus based on the correspondence between input and context, according to an embodiment of the present disclosure.

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

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

[0038] 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).

[0039] Programs typically make different decisions based on input data, such as conditional statements, variable assignments, function calls, and logical branch selections. These decisions all affect the program's execution path and state evolution. Therefore, understanding and analyzing the relationship between input data and program state is crucial. In many cases, some input data directly corresponds to memory or registers during program execution. By observing the input-context correspondence between input data and program state, and extracting the offset relationship between input data and processing logic during program execution, we can specifically infer key locations in the program logic and select more promising input data, rather than relying on completely random input. This helps achieve high code coverage more quickly, thereby increasing the chances of discovering potential vulnerabilities.

[0040] The embodiments disclosed herein aim to solve the problems of magic number and verification detection, improve the efficiency and effectiveness of fuzz testing, and by deeply exploring the mapping relationship between input data and program state, fuzz testing is not limited to randomly generated data, but performs targeted testing based on program logic and state evolution, thereby improving coverage and vulnerability discovery capabilities.

[0041] To further explain the embodiments of this disclosure in detail, Figure 1 An exemplary flowchart is shown for an fuzz testing optimization method based on the correspondence between input and context according to an embodiment of the present disclosure.

[0042] exist Figure 1 At box S102, fuzz testing is performed on the target program based on kAFL, hooking all comparison instructions and recording the parameters in the comparison instructions.

[0043] During fuzz testing, a separate trace run is performed for each new input to perform hooking and analysis. The purpose is to analyze all comparison instructions in the program that are related to the input, extract the parameters in these comparison instructions, and capture key operations that may affect the program's behavior.

[0044] According to one embodiment of this disclosure, fuzzing a target program based on kAFL specifically includes: generating multiple inputs and passing the inputs to the target program; collecting coverage information fed back after the target program is executed, the coverage information being derived from trace data generated by Intel PT; mutating the inputs based on the collected coverage information; and inserting breakpoints in the target program and inspecting memory and register contents during execution using virtual machines provided by KVM-PT and QEMU-PT.

[0045] KAFL obtains program execution coverage information through hardware-accelerated tracing provided by Intel Processor Trace (Intel PT) without instrumenting the target program. Its core architecture is built on top of KVM-PT and QEMU-PT, enabling it to isolate and execute any x86 operating system and achieve efficient execution of target code through KVM virtualization technology. Intel PT allows the system to accurately trace the code's execution path, generating tracing data. QEMU-PT can trace every instruction during program execution and correctly identify instructions that need to be hooked or modified. This makes kAFL more reliable and efficient for kernel fuzzing. During program execution, the program's state can be checked at various breakpoints. Furthermore, kAFL has the ability to patch instructions in memory. This means it can modify the target program's behavior according to testing needs, such as inserting breakpoints or modifying program paths, further facilitating fuzzing.

[0046] Intel PT hardware tracing is used to hook into common comparison operations, compiler-generated optimization instructions, and function call instructions in a program. Common comparison operations involve comparing input data with predefined values, such as ==, ! =, >, <, etc. These values ​​can be hard-coded or calculated from the input data.

[0047] In addition to common comparison operations, comparison instructions also include some compiler-generated optimization instructions used to replace ordinary comparison instructions or switch-case structures. Furthermore, in programs, operations such as string comparison and hash calculations are implemented through function calls. Therefore, besides comparison instructions, it's necessary to hook all call instructions, especially those functions that implement string comparison or other input data processing. For example, assuming the input string is "TestSeedInput", the comparison instructions will examine the first 8 bytes of the input, interpret them as an unsigned 64-bit integer, and compare them with the unsigned 64-bit integer of the string "MAGICHDR". Since integers are typically encoded in little-endian format (i.e., the least significant byte is at the beginning of memory), this means that the ASCII strings used for comparison are represented as "deeStesT" and "RDHCIGAM". For example:

[0048] Input data: "TestSeed" (assuming it is represented in little-endian encoding) is stored in memory as 0x640x650x730x740x530x650x650x64, which is "deeStesT" (little-endian representation).

[0049] Expected value: The ASCII value of "MAGICHDR" is 0x4D 0x410x470x490x430x480x440x52. After converting the string to little-endian format, it becomes 0x520x440x480x430x490x470x410x4D, which is "RDHCIGAM".

[0050] It can record parameters involved in comparison operations, parameters passed during function calls, and parameters obtained by calculating the offset of the jump table. These parameters often affect the program execution path. Based on the extracted parameters, custom mutations (pattern --> replacement) can be created to generate new input data.

[0051] Then, in box S104, the parameters in the comparison instruction are mutated to generate different mutated values.

[0052] When performing comparison operations in the program, since the testing tool cannot directly distinguish comparison operators (such as "less than" and "equal to"), it is necessary to perform a slight variation on the comparison value, that is, to perform addition or subtraction operations on the original input value.

[0053] According to one embodiment of this disclosure, the parameters involved in the comparison operation extracted from the seed pool are subjected to addition or subtraction operations, and various encoding strategies are applied to generate different mutated values. The encoding strategies include inversion, zero extension or byte order conversion, C string conversion, ASCII conversion, and Memory(n).

[0054] For example, adding or subtracting 1 from a hard-coded string like "RDHCIGAM" yields variant values ​​such as "RDHCIGAL" and "RDHCIGAN". This tiny variation, without altering the data structure, can trigger potential overflow errors or "off-by-one" vulnerabilities through minor offsets. In such vulnerabilities, a program may inadvertently ignore boundary conditions, leading to memory overflows, data overflows, or program crashes.

[0055] Besides basic addition, subtraction, and mutation, input data undergoes different encoding and decoding processes. These encoding formats often influence how the input is processed during program execution. Therefore, to improve coverage of different encodings and mutation candidates in fuzz testing, multiple encoding strategies are applied to the input data.

[0056] Encoding strategies include reversal, zero extension or byte order conversion, C string conversion, ASCII conversion, and Memory(n). Zero extension interprets the value as a little-endian integer by adding zero bytes to the left of the value or extending the sign bit (the most significant bit) into the newly added byte. For example, assuming the input value is 0x123, with zero extension, the extended value might be 0x00000123. With sign extension, it might become 0xFF000123. This encoding is useful for handling integers with different numbers of bits, especially when there is no change in size.

[0057] Endianness conversion converts little-endian to big-endian, helping to catch problems caused by mismatched storage order. C string conversion interprets the input value as a C language string, removing the first zero byte; this encoding method is very useful when processing strings. Memory(n) treats the input like the parameters of the memcmp function, considering only the first n bytes for comparison; n typically ranges from {4, 5, ..., 32}. This encoding method is suitable for scenarios involving operations on memory regions. ASCII conversion converts integer values ​​to their corresponding ASCII characters, which is very effective when processing character and text data.

[0058] These different encoding methods change the representation of input data, thus providing more test variants. For example, the input data "RDHCIGAM" may become different encoded variants such as "MAGICHDR", "LAGICHDR", and "NAGICHDR" after little-endian encoding. Reversing the original string yields MAGICHRD or AGICHRD. Treating it as a C string and removing the first 0 byte might result in DHCIGAM or HCIGAM. These encoding schemes can create a large number of variant inputs, thereby improving fuzz test coverage.

[0059] In addition to handling common integer comparisons, embodiments of this disclosure also consider the case of string or byte array comparisons via function calls. Because these functions typically involve complex memory access and matching logic, traditional fuzzing methods struggle to generate suitable input. To address this issue, all functions involving string or byte array comparisons can be hooked, and their pointer-type parameters and the data they point to can be mutated. When a called function is detected to contain at least two pointer-type parameters, the first 128 bytes of data pointed to by each pointer are extracted for subsequent mutation processing. If the data volume is less than 128 bytes, the system acquires all available data; if the data volume is greater than 128 bytes, the system only extracts the first 128 bytes. These bytes will serve as input for subsequent mutation processing.

[0060] Common string comparison functions (such as strcmp and memcmp) handle byte sequences of different lengths and null-terminated strings, respectively. Therefore, each type of comparison requires a different strategy. For comparing the first n bytes of a specified length (similar to memcmp), the first n bytes are randomly mutated to adjust the byte order, simulating different input conditions. Special cases are generated through mutation, such as all zeros or all FF extreme values, to check if any abnormal behavior is triggered.

[0061] For comparisons from the start position to the null character (similar to the strcmp family of functions), different inputs are simulated by changing the first few bytes of the string. If the input data does not contain a null character, a null character is inserted to cover the case where the null character is the terminator. The string length can be increased or decreased to test whether it affects the comparison result.

[0062] To improve the efficiency and coverage of fuzz testing, the tester not only needs to handle the two comparison scenarios mentioned above, but also needs to perform more detailed modeling based on memory access patterns. Through multi-dimensional analysis, starting from multiple levels such as memory layout, byte order, alignment, and string termination markers, more complex test inputs are generated.

[0063] By detecting memory access patterns, fuzzers can analyze which parts of memory content need to be mutated. For example, certain memory regions may contain critical strings or tags that are essential to the program's behavior. Testers can also check for byte alignment and byte order issues, especially when running on different architectures, as these issues can lead to different comparison results. By simulating real-world input data, testers can generate test cases that better reflect real-world scenarios, thus discovering potential vulnerabilities more efficiently.

[0064] According to one embodiment of this disclosure, when testing involves comparing strings and byte arrays, test input is provided by dynamically generating, filtering, and utilizing specific dictionaries containing consecutive non-zero bytes and non-0xff bytes. By matching the contents of these dictionaries with the input data, the fuzzer can help discover potential magic numbers in the program. These dictionaries are used only at the current stage of the input and do not introduce strings irrelevant to the test objective. This approach is similar to extracting the output of a strings tool in a fuzzing tool and optimizing it to contain only strings relevant to the current input stage, thereby further improving the targeting of the test.

[0065] Subsequently, in box S106, whenever a comparison operation is encountered during the execution of the target program, the part related to the magic number is identified, the original input value is replaced with the mutated value, and a new test case is generated.

[0066] In complex input scenarios, such as large file system images, there may be a large number of redundant mutation locations. For example, consider a minimal valid ext4 file system image, which is 64KB in size and consists mostly of zero bytes. In this case, if a program compares a zero byte with a constant, the mutation space can be enormous. For such a large input, there may be more than 40,000 potential mutation locations, making it very difficult to handle mutations of this scale.

[0067] According to one embodiment of this disclosure, a certain number of random bytes can be added to the input data to change the pattern of the input data. This makes some patterns no longer predictable or repetitive. For example, suppose a part of the input data is originally a long sequence of zero bytes, which may be subject to the same mutation at multiple positions. After adding random bytes, the originally repetitive parts may no longer be available, reducing the repetitiveness of mutations. As the number of random bytes in the input increases, the fuzzing engine will consider more different mutation paths, thereby avoiding performing similar mutation operations multiple times on the same input part.

[0068] The input data is then initially labeled to identify similar patterns. Specifically, different byte segments in the input are labeled with different types, such as regular data, parts generated from random bytes, and potentially variable parts, with each byte segment representing a specific pattern. These labels help the test engine more clearly understand which parts might affect the program's execution path.

[0069] When comparing two or more versions of input, the input is mutated only when a similar pattern is found at the same offset. The original input value is replaced with the mutated value, generating a new test case. For example, if a mutated pattern at a certain position has already been tried in a previous version and the test path has not changed, the system will not mutate that position again. This avoids repeated mutation operations on the same pattern, thus reducing redundant computation and testing. For instance, suppose a string "QYISLKFYDBYYSYWSIBSXEAXOKHNRUCYU" is labeled into several segments, some of which, such as "QYISLKFY", are identified as mutable patterns. In this case, the mutation operation... <qyislkfy-->MAGICHDR> will only work at the first matching position in the string, and will not attempt to replace all possible positions throughout the string.

[0070] By focusing only on the offset positions of labeled, similar patterns, the originally huge mutation space (e.g., tens of thousands or even more potential mutation positions) will be greatly compressed, and only a few mutation positions that truly have the potential to trigger different execution paths will be processed.

[0071] Figure 2 This is a schematic diagram illustrating a solution to the magic number problem in a feedback-driven fuzzy testing method according to an embodiment of this disclosure. (Refer to...) Figure 2 As shown, the values ​​in the program state typically correspond directly to a portion of the input. Whenever a new path is encountered, an instruction with comparison functionality is hooked and a trace run is performed. The instruction's parameters are recorded, directly providing information about the magic number. The parameters in the comparison instruction are mutated to generate different mutated values. Whenever a comparison operation is encountered during the target program's execution, the part related to the magic number is identified. The mutation <pattern --> replacement> pattern is used to identify the input part that needs to be replaced by the mutation. Only this part is replaced, generating new test cases.

[0072] exist Figure 1 At box S108, all verification and detection commands are identified and verification information is recorded. The verification and detection commands are modified to always be true, and a preparatory queue is generated.

[0073] Another common challenge faced by fuzzing tools is efficiently handling validation scenarios. This disclosure, based on the idea of ​​a strong correspondence between input and context, explores how to effectively repair input and bypass validation logic, ensuring that in feedback fuzzing, the input can cover more program paths while guaranteeing the effectiveness of the test.

[0074] According to one embodiment of this disclosure, Intel PT hardware tracing can be used to extract all comparison operations from a program, generating a list of comparison operations. By comparing different versions of input values, mutation patterns in the input can be extracted. These operations typically compare two data values ​​to determine whether they are equal, greater than, or less than each other. In this step, every comparison instruction in the program is recorded. If a part of the program consistently depends on certain input bytes after multiple input mutations, then these bytes constitute the "pattern" part of the comparison operation.

[0075] To identify instructions related to validation, the following heuristic can be used: if similar variation patterns appear in multiple input versions, these patterns are identified as validation-related instructions. If the "left side" of a variation pattern (i.e., a fixed portion of the input data) can be found in all inputs, then that portion is likely a validation-related instruction.

[0076] If both arguments of a comparison operation are variables or pointers rather than hard-coded constants, the operation is considered a checksum-related instruction. Therefore, a checksum operation is more likely to occur when neither argument is an immediate value. The pattern is checked to see if it depends on multiple bytes of input and changes across different versions; if it does, it is identified as a checksum-related instruction. As input variations occur, changes in certain values ​​within the program can affect the execution result of checksum instructions. The values ​​of checksum-related patterns typically depend on multiple input bytes and change across different labeled versions. For example, if a pattern is a single field of input, and the replacement value is a hash value calculated based on the input portion, it is identified as a checksum-related instruction.

[0077] The above process may carry the risk of false positives. For example, some instructions marked as verification checks may actually be other logical operations in the program (such as boundary checks). If these instructions are incorrectly identified and removed, it may trigger false positives or even cause the program to crash. Therefore, careful filtering is required in subsequent verification stages to avoid the impact of false positives.

[0078] After identifying instructions related to validation checks, these instructions are modified to always be true, causing input to bypass these validation logics and enter deeper paths in the program, generating a preparatory queue. For example, the `==` operator in comparison operations can be changed to `!=`, ensuring the condition is always true. Inputs obtained during fuzzing, while potentially triggering new paths in the modified program, may not function correctly in the unmodified target program. For instance, some boundary checks or security checks might be accidentally removed, leading to logical malfunctions or even crashes. Modified instructions might cause code that shouldn't be triggered to execute, resulting in logical errors or crashes.

[0079] These potential issues can be identified and addressed during the subsequent verification phase. Specifically, all modified comparison instructions are fixed before the fuzzing tool attempts to store the input into the test queue. If the fix fails, the modifications are rolled back, and the associated input is discarded.

[0080] Finally in Figure 1 At box S110, the input in the preparatory queue is verified and repaired. Whether to add the repaired input to the real queue depends on whether the repaired input successfully triggers a new overwrite or exposes a new vulnerability.

[0081] Specifically, based on the pattern in the modification instructions, specific fields in the input are modified to conform to the expected format of the target program, restoring the information in the program context to ensure the input matches the logic of the target program. Then, the modified input is executed on the unmodified real target program. If the modified input triggers a new overwrite, it is added to the real queue; otherwise, it is discarded from the prepared queue. After the verification process is complete, the initial test queue is cleared, ready for the next round of testing.

[0082] Figure 3 This is a schematic diagram illustrating a solution to the verification problem in a feedback-driven fuzzy testing method according to an embodiment of this disclosure. (Refer to...) Figure 3 As shown, firstly, the verification instruction is identified and modified to always be true, the verification information is recorded, and a preparatory queue is generated. Once the modified instruction executes a new path during fuzzing, it enters verification mode. In verification mode, the modified input is repaired. If the repaired input can trigger a new overlay, the input is added to the true queue; otherwise, the input is discarded from the preparatory queue.

[0083] By modifying validation instructions, the input space of fuzzing can be effectively expanded, exploring paths that the program may not have explored before. However, the validation phase is particularly important in this process because it ensures that modifications do not negatively impact the program and that all inputs entering the test queue are fully validated. This approach combines the flexibility of modification with the reliability of the validation mechanism, guaranteeing efficient fuzzing and enabling a deeper and more comprehensive testing of the program's behavioral paths.

[0084] Figure 4 This is a schematic block diagram of a fuzzy testing optimization apparatus based on the correspondence between input and context, 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 1 The steps of the method are shown. In one example, device 400 may be a computer device or a cloud computing node. Device 400 may perform fuzz testing on the target program based on kAFL, hooking all comparison instructions and recording the parameters in the comparison instructions; mutating the parameters in the comparison instructions to generate different mutated values; whenever a comparison operation is encountered during the execution of the target program, identifying the part related to the magic number, replacing the original input value with the mutated value, and generating a new test case; identifying all verification and detection instructions and recording verification information, modifying the verification and detection instructions to always be true, and generating a preparatory queue; and verifying and repairing the inputs in the preparatory queue, deciding whether to include them in the real queue based on whether the repaired input successfully triggers a new overlay or exposes a new vulnerability.

[0085] In some embodiments of this disclosure, the apparatus 400 can generate multiple inputs and pass them to a target program; collect coverage information fed back after the target program is executed, the coverage information being trace data generated by Intel PT; mutate the inputs based on the collected coverage information; and, using virtual machines provided by KVM-PT and QEMU-PT, insert breakpoints in the target program and inspect memory and register contents during execution.

[0086] In some embodiments of this disclosure, device 400 may utilize Intel PT hardware tracing to hook common comparison operations, compiler-generated optimization instructions, and function call instructions in a program; record parameters involved in comparison operations, parameters passed during function calls, and parameters obtained by calculating the offset of the jump table.

[0087] In some embodiments of this disclosure, the apparatus 400 can perform addition or subtraction operations on the parameters involved in the comparison operation extracted from the seed pool, and apply a variety of encoding strategies to generate different mutated values. The encoding strategies include inversion, zero extension or byte order conversion, C string conversion, ASCII conversion, and Memory(n).

[0088] In some embodiments of this disclosure, the apparatus 400 may, when detecting that the called function contains at least two pointer-type parameters, extract the first 128 bytes of data pointed to by each pointer for subsequent mutation processing input; for comparison of the first n bytes of a specified length, randomly mutate the first n bytes, adjust the byte order, simulate different input situations, generate special cases through mutation, and check whether abnormal behavior is triggered; for comparison from the starting position to the null character, simulate different inputs by changing the first few bytes of the string, and if there is no null character in the input data, insert a null character so that the test can cover the case where the null character is the terminator; when the test involves comparison of strings and byte arrays, provide test input by dynamically generating, filtering, and utilizing a specific dictionary containing consecutive non-zero bytes and non-0xff bytes.

[0089] In some embodiments of this disclosure, the device 400 may add a predetermined number of random bytes to the input data to change the pattern of the input data; perform initial annotation on the input data to identify similar patterns in the input data; and when comparing two or more versions of the input, only when a similar pattern is found at the same offset will the input be mutated, replacing the original input value with the mutated value to generate a new test case.

[0090] In some embodiments of this disclosure, device 400 can utilize Intel PT hardware tracing to extract all comparison operations from the program, generate a list of comparison operations, extract variation patterns in the input by comparing different versions of the input value; if similar variation patterns appear in multiple input versions, these patterns are identified as verification-related instructions; if both parameters of the comparison operation are variables or pointers rather than hard-coded constants, the comparison operation is determined to be a verification-related instruction; check whether the pattern depends on multiple bytes of the input and changes in different versions, if it changes, it is identified as a verification-related instruction; modify the identified verification detection instructions to always be true, causing the input to bypass these verification logics and enter a deeper path of the program, generating a preparatory queue.

[0091] In some embodiments of this disclosure, the device 400 can modify specific fields in the input according to the pattern in the modification instruction to make them conform to the expected format of the target program, restore the information in the program context, and make the input logically match the target program; execute the repaired input on the unmodified real target program; if the repaired input can trigger a new overwrite, add the input to the real queue; otherwise, discard the input from the preparatory queue.

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

[0093] Furthermore, in embodiments of this disclosure, device 400 may also include input device 430 and output device 440.

[0094] 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 1 The steps of the fuzzing optimization method based on the correspondence between input and context are shown.

[0095] In summary, the fuzzing method and apparatus based on the correspondence between input and context according to embodiments of this disclosure perform fuzzing on the target program using the kAFL framework. By utilizing hardware tracing technology to hook and compare instructions and record parameters, it can identify the relationship between input data and program state, helping fuzzing tools to more effectively select the paths and mutation points to be tested, avoiding blind trial and error, thereby improving efficiency. By establishing a connection between input and program state, it is possible to generate inputs that can trigger specific program behaviors more specifically, reducing the inefficiency caused by random mutations. It can bypass the performance bottlenecks caused by magic number and checksum detection in traditional fuzzing, and can still maintain high coverage and testing effectiveness in complex program structures.

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

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

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

[0099] 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 fuzzy testing optimization method based on the correspondence between input and context, characterized in that, The method includes: Fuzz testing of the target program is performed based on kAFL, hooking all comparison instructions and recording the parameters in the comparison instructions; The parameters in the comparison instruction are mutated to generate different mutated values; Whenever a comparison operation is encountered during the execution of the target program, the part related to the magic number is identified, the original input value is replaced with the mutated value, and a new test case is generated. This includes: adding a predetermined number of random bytes to the input data to change the pattern of the input data; performing initial labeling on the input data to identify similar patterns in the input data; and when comparing two or more versions of the input, only when a similar pattern is found at the same offset, the input is mutated, the original input value is replaced with the mutated value, and a new test case is generated. Identify all verification and detection commands and record verification information; modify the verification and detection commands to always be true; and generate a preparatory queue. The inputs in the preparatory queue are verified and repaired. Whether to add the repaired input to the real queue depends on whether the repaired input successfully triggers a new overwrite or exposes a new vulnerability. This includes: modifying specific fields in the input according to the pattern in the modification instruction to make them conform to the expected format of the target program, restoring the information in the program context, and making the input logically match the target program; executing the repaired input on the unmodified real target program. If the repaired input can trigger a new overwrite, the input is added to the real queue; otherwise, the input is discarded from the preparatory queue.

2. The fuzzy testing optimization method based on the correspondence between input and context as described in claim 1, characterized in that, The kAFL-based fuzz testing of the target program includes: Generate multiple inputs and pass them to the target program; Collect coverage information fed back after the target program is executed, the coverage information comes from trace data generated by Intel PT; Based on the collected coverage information, the input is mutated; and Using the virtual machines provided by KVM-PT and QEMU-PT, breakpoints are inserted in the target program and memory and register contents are inspected during execution.

3. The fuzzy testing optimization method based on the correspondence between input and context as described in claim 2, characterized in that, The hook includes all comparison commands and records the parameters in the comparison commands, including: Intel PT hardware tracing is used to hook common comparison operations, compiler-generated optimization instructions, and function call instructions in a program; and Record the parameters involved in the comparison operation, the parameters passed during the function call, and the parameters obtained by calculating the offset of the jump table.

4. The fuzzy testing optimization method based on the correspondence between input and context as described in claim 1, characterized in that, The step of mutating the parameters in the comparison instruction to generate different mutated values ​​includes: The parameters extracted from the seed pool for comparison are subjected to addition or subtraction operations, and various encoding strategies are applied to generate different mutation values. The encoding strategies include inversion, zero extension or byte order conversion, C string conversion, ASCII conversion, and Memory(n), where n represents the number of bytes.

5. The fuzzy testing optimization method based on the correspondence between input and context as described in claim 4, characterized in that, The step of mutating the parameters in the comparison instruction to generate different mutated values ​​further includes: When it is detected that the called function contains at least two pointer-type parameters, the first 128 bytes of data pointed to by each pointer are extracted for use as input for subsequent mutation processing; For the comparison of the first n bytes of a specified length, the first n bytes are randomly mutated to adjust the order of the bytes, simulate different input conditions, generate special cases through mutation, and check whether abnormal behavior is triggered. For comparisons from the start position to the null character, different inputs are simulated by changing the first few bytes of the string. If the input data does not contain a null character, a null character is inserted so that the test can cover the case where the null character is used as a terminator; and When the test involves comparing strings and byte arrays, test input is provided by dynamically generating, filtering, and utilizing a specific dictionary containing consecutive non-zero bytes and non-0xff bytes.

6. The fuzzy testing optimization method based on the correspondence between input and context as described in claim 1, characterized in that, The process of identifying all verification and detection commands and recording verification information, modifying the verification and detection commands to always be true, and generating a preparatory queue includes: Intel PT hardware tracing is used to extract all comparison operations from the program, generating a list of comparison operations. By comparing different versions of the input values, the mutation patterns in the input are extracted. If similar variation patterns appear in multiple input versions, these patterns are identified as verification-related instructions; If both parameters of a comparison operation are variables or pointers rather than hard-coded constants, then the comparison operation is determined to be a verification-related instruction. Check if the pattern depends on multiple bytes of input and changes in different versions; if it does change, it is identified as a verification-related instruction; and The identified verification and detection instructions are modified to always be true, causing the input to bypass these verification logics and enter a deeper path in the program, thus generating a preparatory queue.

7. A fuzzy testing optimization device based on the correspondence between input and context, characterized in that, The device 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 device performs the steps of the fuzzy testing optimization method based on the input-context correspondence as described in any one of claims 1 to 6.

8. A computer-readable storage medium storing a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the fuzzy testing optimization method based on the correspondence between input and context as described in any one of claims 1 to 6.

Images