Interactive visualization methods, apparatuses, and devices for fuzzing bottleneck breakthroughs

Abstract

The application relates to an interactive visualization method, device and equipment for fuzzy testing bottleneck breakthrough, and belongs to the network security field. All compiled modules in a program under test are combined into a complete intermediate code to obtain a global view of the program under test; a hash algorithm is used to generate a unique label for each function; a call graph and a control flow graph are constructed; function call instruction information is obtained by scanning basic blocks of each function; the basic blocks are instrumented; the compiled and instrumented program under test is subjected to fuzzy testing, and runtime data is obtained in real time; according to the fuzzy testing runtime data and static analysis data, data-driven visualization is carried out, and the call graph, the control flow graph and real-time execution statistical information are displayed in real time; through the interactive chart, a test engineer is assisted in locating fuzzy testing bottleneck constraints. The application can help the test engineer better understand and intervene in the fuzzy testing process, and improve the code coverage rate of the fuzzy testing and the number of defect detections.

Description

Technical Field

[0001] This invention belongs to the field of network security, and specifically relates to an interactive visualization method, apparatus, and device for overcoming fuzz testing bottlenecks. Background Technology

[0002] Fuzzing is an automated testing technique that automatically or semi-automatically generates random data according to certain rules. This random data is then input into the entry point of a dynamically running program under test, while simultaneously monitoring for any anomalies to uncover security vulnerabilities. Currently, fuzzing is widely used in vulnerability discovery. However, its performance is limited by the complex constraints of large programs, causing testing to easily reach a bottleneck after a period of time, thus inhibiting the improvement of fuzzing coverage. Summary of the Invention

[0003] (a) Technical problems to be solved

[0004] The technical problem to be solved by the present invention is how to provide an interactive visualization method, apparatus and device for overcoming the bottleneck of fuzz testing, so as to solve the bottleneck problem of fuzz testing being limited by complex constraints in large programs.

[0005] (II) Technical Solution

[0006] To address the aforementioned technical problems, this invention proposes an interactive visualization method for overcoming bottlenecks in fuzz testing, comprising the following steps:

[0007] S110: Using the LLVM platform, all compiled modules of the program under test are merged into a complete intermediate code to obtain a global view of the program under test;

[0008] S120: Use a hash algorithm to generate a unique label for each function and extract a function summary containing the function name and row range;

[0009] S130: Construct a global call graph and control flow graph, obtain function call instruction information by scanning the basic blocks of each function, and collect static analysis data;

[0010] S140: Instrument the basic blocks and update the coverage statistics;

[0011] S150: Performs fuzz testing on the compiled and instrumented program under test, and obtains runtime data such as the hit count, coverage path, and number of crashes of basic function blocks in real time;

[0012] S160: Based on the fuzz test runtime data and static analysis data, perform data-driven visualization to display the call graph, control flow graph, and real-time execution statistics in real time;

[0013] S170: Assists test engineers in locating bottleneck constraints in fuzz testing through interactive diagrams and provides semantic context.

[0014] Furthermore, in S110, during the compilation phase, additional library files are called to utilize the LLVM platform to parse the dependencies between various compilation modules and obtain the internal call relationships of the program; all compilation modules are linked and loaded together to form a complete intermediate code, thus constructing a global view of the program under test.

[0015] Furthermore, in S120, by scanning the debugging metadata of the function's basic block, relevant information for each function is extracted, including the function name, parameter list, source file name, and the location information of the function's code line. The collected function information is constructed into a string, which contains enough information for each function to distinguish different functions. A specific hash algorithm is used to perform a hash operation on the constructed string to generate a fixed-length hash value. In rare cases, different inputs may produce the same hash value. To resolve hash collisions, an open addressing and linked list collision resolution strategy is adopted. Finally, the generated hash value is used as a unique label for the function, which is used to identify and reference specific functions in subsequent analysis and visualization processes.

[0016] Furthermore, in S130, a global call graph and control flow graph are constructed by traversing the complete intermediate code to represent the program structure, including the call relationships between functions and the control flow between basic blocks within a function; the program control flow graph is analyzed using an open-source static analysis tool, and function call instruction information is obtained by scanning the basic blocks of each function.

[0017] Furthermore, in S140, a counter is created for each basic block based on the function's unique label to represent the number of times each basic block is executed; instrumentation code is added at the entry point, branch jump point, and return point of each basic block to detect program crashes and update the corresponding counters; the instrumentation code needs to ensure that it can update the shared memory area used by fuzzing; optimization measures are adopted to reduce the impact of instrumentation on program performance, including limiting the granularity of the counter, using atomic operations or locking mechanisms to prevent race conditions in a multi-threaded environment, and keeping the counter in a cache to speed up access; after the instrumentation is completed, the modified intermediate code is passed to the backend compiler to generate an executable file containing the instrumentation code.

[0018] Furthermore, in S150, a fuzzing tool is used to perform fuzzing tests on the compiled and instrumented program under test; to collect and share runtime data in real time, a shared memory area is initialized when the program starts to store the data collected during runtime; during the dynamic execution of the program, based on the instrumented code, execution information is recorded to update the local counter, i.e., the basic block hit count; by recording events of jumping from one basic block to another, the program execution path is traced and the program coverage path is recorded; the counter and path information updated by the instrumented code are periodically synchronized to the shared memory, and the shared memory data is continuously updated and accessed when the program continues to run and process multiple input samples; based on the instrumented code, crash events are recorded and the number of crashes is recorded, and the crash information is synchronized to the shared memory in real time to ensure that critical information is not lost due to abnormal program termination.

[0019] Furthermore, in S160, the visualization component periodically reads data from shared memory, formats the collected data into a format suitable for network transmission, and updates the displayed statistics and charts; it displays the function call graph in the form of a force-directed graph; it displays the control flow graph using a tree layout based on the Reingold-Tilford algorithm; it hides the basic function blocks not covered in the fuzz test; and it displays the hierarchical structure of the basic blocks using the RT tree layout algorithm.

[0020] Furthermore, in S170, the test engineer uses a visual interface to monitor real-time data of the fuzzing test, including code coverage, basic block hit counts, and crash information; by analyzing real-time data, they identify areas where test coverage is growing slowly or has stopped increasing; through the visualized call graph and control flow graph, they locate functions and basic blocks with low hit counts or that have not been executed; they view the source code corresponding to these functions and basic blocks to understand their semantics and execution context, and comprehend the code logic and execution constraints of bottleneck areas; they identify complex constraints that hinder the exploration path of test inputs, and manually construct or update test inputs based on the identified complex constraints to enable them to trigger insufficiently explored code paths; they adjust the input generation strategy or modify the program's configuration options to better guide the fuzzing process; they apply the constructed target inputs or updated test drivers to the fuzzing test; they restart the fuzzing test, monitor changes in test coverage and crash information, and verify the effectiveness of the intervention measures; during the fuzzing process, they continuously use the visual interface to monitor the test status, and repeatedly adjust the test strategy based on the test results until satisfactory test coverage is achieved and sufficient potential problems are found.

[0021] The present invention also provides an interactive visualization device for overcoming bottlenecks in fuzz testing, the device comprising:

[0022] The encryption module is used to generate a unique label for each function using a hash algorithm, and extract a function digest containing the function name and line range to obtain a unique identifier for the function;

[0023] The compilation module is used to merge all the compilation modules in the program under test into a complete intermediate code, obtain a global view of the program under test, and then construct the call graph and control flow graph.

[0024] The instrumentation module is used to add instrumentation code at the entry or exit of each basic block, to update the number of times each basic block is executed, and to detect program crashes.

[0025] The initialization module is used to perform fuzz testing on the program under test and initialize shared memory.

[0026] The statistics update module is used to obtain and update runtime data of function basic blocks in real time, including: hit count, coverage path and number of crashes;

[0027] The visualization module is used to perform data-driven visualization based on fuzzing runtime data and static analysis results. It displays call graphs, control flow graphs, and real-time execution statistics in real time. Interactive charts assist test engineers in locating fuzzing bottlenecks and constraints, and provide semantic context.

[0028] The present invention also provides an electronic device, comprising: at least one processor and a memory; the memory storing instructions executable by the at least one processor, wherein the instructions, when executed by the at least one processor, implement the method described herein.

[0029] (III) Beneficial Effects

[0030] This invention proposes an interactive visualization method, apparatus, and device for overcoming fuzzing bottlenecks. The invention merges all compiled modules of the program under test into a single complete intermediate code to obtain a global view of the program. It then uses a hash algorithm to generate unique labels for each function, extracts function summaries containing function names and line ranges, and constructs call graphs and control flow graphs to obtain function call instruction information. By instrumenting basic blocks, the compiled and instrumented program under test is fuzz-tested. Real-time runtime data such as function basic block hit counts, coverage paths, and crash counts are obtained. Based on fuzzing runtime data and static analysis data, the call graph, control flow graph, and real-time execution statistics are displayed. Interactive charts assist test engineers in locating fuzzing bottleneck constraints and provide semantic context to help test engineers better understand and intervene in the fuzzing process, thereby improving fuzzing code coverage and defect detection rates. Attached Figure Description

[0031] Figure 1This is a flowchart of an interactive visualization method for overcoming bottlenecks in fuzz testing disclosed herein.

[0032] Figure 2 This is a block diagram of the interactive visualization device disclosed herein for overcoming bottlenecks in fuzz testing.

[0033] Figure 3 A block diagram of an exemplary electronic device capable of implementing embodiments of the present disclosure. Detailed Implementation

[0034] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0035] According to a first aspect of this disclosure, an interactive visualization method for overcoming fuzzing bottlenecks is provided. The method includes:

[0036] Using the LLVM platform, all compiled modules of the program under test are merged into a complete intermediate code, thus obtaining a global view of the program under test;

[0037] A unique label is generated for each function using a hash algorithm, and a function summary containing the function name and line range is extracted.

[0038] Construct a call graph and a control flow graph, and obtain function call instruction information by scanning the basic blocks of each function;

[0039] Instrument the basic blocks and update the coverage statistics;

[0040] The compiled and instrumented program is subjected to fuzz testing to obtain runtime data such as the hit count, coverage path, and number of crashes of basic function blocks in real time.

[0041] Based on the fuzz test runtime data and static analysis data, data-driven visualization is performed to display the call graph, control flow graph, and real-time execution statistics in real time.

[0042] Interactive charts assist test engineers in identifying bottleneck constraints in fuzz testing and provide semantic context.

[0043] Furthermore, during the compilation phase, additional library files are called, and the LLVM platform is used to resolve the dependencies between various compilation modules and obtain the internal call relationships of the program. All compilation modules are linked and loaded together to form a complete intermediate code, thus constructing a global view of the program under test.

[0044] Furthermore, by scanning the debugging metadata of the basic function blocks, relevant information for each function is extracted, including the function name, parameter list, source file name, and function code line location information. The collected function information is constructed into a string containing enough information for each function to distinguish different functions. A specific hash algorithm is used to perform a hash operation on the constructed string to generate a fixed-length hash value. In rare cases, different inputs may produce the same hash value. To resolve hash collisions, collision resolution strategies such as open addressing and linked lists are used. The generated hash value is used as a unique label for the function, which is used to identify and reference specific functions in subsequent analysis and visualization processes.

[0045] Furthermore, by traversing the complete intermediate code, a global call graph and control flow graph are constructed to represent the program structure, including the call relationships between functions and the control flow between basic blocks within a function; function call instruction information is obtained by scanning the basic blocks of each function.

[0046] Furthermore, based on the function's unique label, a counter is created for each basic block to represent the number of times each basic block is executed. Instrumentation code is added at the entry point, branch jump point, and return point of each basic block to detect program crashes, such as access violations and segmentation faults, and to update the corresponding counters. Fuzzing typically uses shared memory to track code coverage, so it is necessary to ensure that the instrumentation code can update these shared memory regions. Optimization measures are adopted to reduce the impact of instrumentation on program performance, including limiting the granularity of the counter, using atomic operations or locking mechanisms to prevent race conditions in multi-threaded environments, and keeping the counter in a cache to speed up access. After instrumentation is completed, the modified LLVMIR is passed to the backend compiler to generate an executable file containing the instrumentation code.

[0047] Furthermore, fuzzing tools such as AFL are used to perform fuzz testing on the compiled and instrumented program under test. To collect and share runtime data in real time, a shared memory area is initialized at program startup to store the data collected during runtime. During the dynamic execution of the program, execution information is recorded and local counters, i.e., basic block hit counts, are updated based on the instrumented code. The program execution path is traced and the program coverage path is recorded by recording events that jump from one basic block to another. The counters and path information updated by the instrumented code are periodically synchronized to the shared memory, and the shared memory data is continuously updated and accessed as the program continues to run and process multiple input samples. Based on the instrumented code, crash events are recorded, and the number of crashes is recorded. The crash information is synchronized to the shared memory in real time to ensure that critical information is not lost due to abnormal program termination. The efficiency of data reading and writing is improved by optimizing memory access patterns, such as prefetching and caching strategies.

[0048] Furthermore, the visualization component periodically reads data from shared memory, formats the collected data into a format suitable for network transmission, and updates the displayed statistics and charts; it displays the function call graph in the form of a force-directed graph; it displays the control flow graph using a tree layout based on the Reingold-Tilford algorithm; it hides the basic function blocks not covered in the fuzz test; and it displays the hierarchical structure of the basic blocks using the RT tree layout algorithm.

[0049] Furthermore, test engineers use a visual interface to monitor real-time fuzzing data, including code coverage, basic block hit counts, and crash information. By analyzing real-time data, they identify areas where test coverage growth is slow or has stalled, often due to bottlenecks caused by complex constraints or insufficiently explored code regions. Visualized call graphs and control flow graphs pinpoint functions and basic blocks with low hit counts or that are not executed. They examine the source code corresponding to these functions and basic blocks to understand their semantics and execution context, comprehending the code logic and execution constraints of bottleneck areas. They identify complex constraints that hinder test input exploration paths, such as array sorting and virtual function calls. Based on the identified constraints, they manually construct or update test inputs to trigger insufficiently explored code paths. They adjust input generation strategies or modify program configuration options to better guide the fuzzing process. They apply the constructed target inputs or updated test drivers to the fuzzing. They restart the fuzzing, monitoring changes in test coverage and crash information to verify the effectiveness of interventions. Throughout the fuzzing process, they continuously monitor the test status using a visual interface, repeatedly adjusting test strategies based on test results until satisfactory test coverage is achieved and sufficient potential issues are identified.

[0050] The present invention also provides an interactive visualization device for overcoming fuzz testing bottlenecks, the device comprising:

[0051] The encryption module is used to generate a unique label for each function using a hash algorithm, and extract a function digest containing the function name and line range to obtain a unique identifier for the function;

[0052] The compilation module is used to merge all the compilation modules in the program under test into a complete intermediate code, obtain a global view of the program under test, and then construct the call graph and control flow graph.

[0053] The instrumentation module is used to add instrumentation code at the entry or exit of each basic block, to update the number of times each basic block is executed, and to detect program crashes, such as access violations, segmentation faults, etc.

[0054] The initialization module is used to perform fuzz testing on the program under test and initialize shared memory.

[0055] The statistics update module is used to obtain and update runtime data such as the hit count, coverage path, and number of crashes of the basic function blocks in real time.

[0056] The visualization module is used to perform data-driven visualization based on fuzzing runtime data and static analysis results. It displays call graphs, control flow graphs, and real-time execution statistics in real time. Interactive charts assist test engineers in locating fuzzing bottlenecks and constraints, and provide semantic context.

[0057] The present invention also provides an electronic device. The electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the method described above.

[0058] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0059] Example 1:

[0060] To address the bottleneck problem of fuzzing in existing technologies being limited by complex constraints in large programs, this disclosure proposes the following technical solution: by combining static analysis data of the program under test and runtime data of fuzzing, a visual interface is used to interactively display the fuzzing process, assisting test engineers in locating testing bottlenecks, thereby improving fuzzing code coverage and the number of defects detected. Detailed embodiments are described below.

[0061] Figure 1 A flowchart of an interactive visualization method 100 for overcoming fuzz testing bottlenecks according to an embodiment of the present disclosure is shown.

[0062] S110: Using the LLVM platform, all compiled modules of the program under test are merged into a complete intermediate code, thus obtaining a global view of the program under test.

[0063] In order to improve compilation efficiency, modern compilation systems usually divide the compilation phase into compilation modules and compile each module in parallel. However, this method cannot directly obtain the internal calling relationships of the program and makes it difficult to construct a global overview of the target program under test.

[0064] In this embodiment, during the compilation phase, additional library files are called, and linking tools in the LLVM platform (such as the LLVM linker, LLD) are used to link multiple modules into a single, larger module. This step involves resolving the dependencies between the modules and merging them into a single program representation.

[0065] S120: Use a hash algorithm to generate a unique label for each function and extract a function summary containing the function name and row range.

[0066] The hash algorithm can be MD5 (MD5 Message-Digest Algorithm), SHA (Secure Hash Algorithm), or MAC (Message Authentication Code).

[0067] In this embodiment, based on the unique identifier characteristic of hash algorithms, the MD5 algorithm is used to encrypt the basic information of each function from a security perspective.

[0068] Specifically, firstly, relevant information for each function is extracted from the source code or LLVM intermediate code IR, including: function name, parameter list, source file name, and starting line number; the collected function information is constructed into a string, which should contain enough information to distinguish different functions; the constructed string is hashed using a selected hash algorithm to generate a fixed-length hash value; in rare cases, different inputs may produce the same hash collision, and to handle this situation, collision resolution strategies such as open addressing and linked lists are adopted; finally, the generated hash value is used as a unique label for the function, which can be used to identify and reference specific functions in subsequent analysis and visualization processes.

[0069] S130: Construct a global call graph and control flow graph, obtain function call instruction information by scanning the basic blocks of each function, and collect static analysis data.

[0070] Specifically, by traversing the complete intermediate code generated by LLVM, a global call graph and control flow graph are constructed. The open-source static analysis tool "Angr" is used to analyze the program control flow graph, and function call instruction information is obtained by scanning the basic blocks of each function.

[0071] S140: Instrument the basic blocks and update the coverage statistics.

[0072] Instrumentation refers to inserting probes into specific locations in a program while ensuring the integrity of the original program logic. These probes collect information from the code, including the function itself, function parameter values, and return values, thereby gathering dynamic context information during program execution.

[0073] In some embodiments, probes are typically used to collect code coverage, branch coverage, and function call coverage during program execution. Collecting code coverage is equivalent to collecting function block coverage, which can be achieved by instrumenting the program code at function entry points, branch jump points, and function return points. Branch coverage can also be obtained simultaneously. Function call coverage can generally be obtained by inserting probes at function entry points, and by combining all function call path information, information on uncalled paths can be obtained.

[0074] Considering the information required by the visualization module, specific probes are inserted at function entry points, branch jump points, and function return points for instrumentation.

[0075] In this embodiment, the dynamic instrumentation tool can be the "Intel Pintool" instrumentation tool.

[0076] S150: Performs fuzz testing on the compiled and instrumented program under test, and obtains runtime data such as the hit count, coverage path, and number of crashes of basic function blocks in real time.

[0077] Specifically, a fuzzing tool is used to perform fuzzing tests on the compiled and instrumented program. Based on the instrumented code, the basic block hit count and program coverage path are updated, and the counters and path information updated by the instrumented code are periodically synchronized to shared memory. In addition, crash events are recorded and synchronized to shared memory in real time.

[0078] The shared memory uses a hash table to store bitmaps, which store the execution paths covered by the test. This is typically a 64KB byte array. Each byte in the bitmap represents the number of times an edge (jumping from one block to another) is executed. The hash index of an edge is the XOR of the addresses of two blocks modulo 64KB. By running the instrumented binary program, once the fuzzing begins, the probe collects all data, including basic block hit counts, covered paths, and crash counts, and updates the stored information.

[0079] In this embodiment, in addition to the bitmap hash table, the shared memory also includes a global counter to store the hit count of basic blocks. To avoid counter saturation, the original counter is reset to zero after each read. Furthermore, to reduce overhead, the counter is stored in a cache with a size limited to 16 bits.

[0080] From the perspective of comprehensive visualization and real-time performance, initializing shared memory consists of two parts: first, allocating and initializing a 64K-length bitmap hash table; second, setting and zeroing a 16-bit counter stored in the cache.

[0081] S160: Based on the fuzz test runtime data and static analysis data, perform data-driven visualization to display the call graph, control flow graph, and real-time execution statistics in real time;

[0082] Visualization technology integrates graphics, data analysis, and human-computer interaction. Using a visual interactive interface as a channel, it incorporates human experience, cognition, and perception into the professional data and program analysis process, enabling effective logical analysis and positioning decisions.

[0083] In this embodiment, based on the collected static analysis data and the data collected during fuzzing, a web page is built using HTML5 in the form of a web front-end interface, a front-end framework is built using Bootstrap, and the D3 tool is used to intuitively visualize the data.

[0084] S170: Assists test engineers in locating bottleneck constraints in fuzz testing through interactive diagrams and provides semantic context.

[0085] In this embodiment, test engineers can interact with and use the visualization interface by following these steps: First, test engineers view the current fuzzing process through the web interface. Based on the charts and data provided by the visualization, they can determine whether the current fuzzing has entered a bottleneck period, such as when path coverage tends to stabilize or when the time since discovering the last new path is relatively long. Then, test engineers navigate to potential intervention points through the call graph and control flow graph displayed in the visualization, load the corresponding code snippets, and the web frontend can provide semantic context for test engineers to better understand the reasons for the bottleneck. Finally, test engineers intervene in the fuzzing process by constructing specific target seeds or updating the test driver to break through the test bottleneck and achieve higher path coverage.

[0086] Example 2:

[0087] The above is an introduction to the method embodiments. The following describes the solution described in this disclosure further through device embodiments.

[0088] Figure 2 A block diagram of an interactive fuzz testing visualization apparatus 200 according to an embodiment of the present disclosure is shown. Figure 2 As shown, the device 200 includes:

[0089] The encryption module 210 is used to generate a unique label for each function using a hash algorithm and extract a function digest containing the function name and line range to obtain a unique identifier for the function;

[0090] Compiler module 220 is used to merge all the compiler modules in the program under test into a complete intermediate code, obtain a global view of the program under test, and then construct the call graph and control flow graph;

[0091] Instrumentation module 230 is used to add instrumentation code at the entry or exit of each basic block to update the number of times each basic block is executed and to detect program crashes, such as access violations, segmentation faults, etc.

[0092] Initialization module 240 is used to perform fuzz testing on the program under test and initialize shared memory;

[0093] The statistics update module 250 is used to obtain and update runtime data such as the hit count, coverage path, and number of crashes of the basic function blocks in real time.

[0094] The visualization module 260 is used to perform data-driven visualization based on fuzzing runtime data and static analysis results. It displays call graphs, control flow graphs, and real-time execution statistics in real time. Through interactive charts, it assists test engineers in locating fuzzing bottlenecks and constraints and provides semantic context.

[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the described module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0096] Example 3:

[0097] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0098] Figure 3 A block diagram of an exemplary electronic device 300 capable of implementing embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0099] Electronic device 300 includes a computing unit 301, which can perform various appropriate actions and processes according to a computer program stored in ROM 302 or a computer program loaded into RAM 303 from storage unit 308. RAM 303 can also store various programs and data required for the operation of electronic device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via bus 304. I / O interface 305 is also connected to bus 304.

[0100] Multiple components in electronic device 300 are connected to I / O interface 305, including: input unit 306, such as keyboard, mouse, etc.; output unit 307, such as various types of displays, speakers, etc.; storage unit 308, such as disk, optical disk, etc.; and communication unit 309, such as network card, modem, wireless transceiver, etc. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0101] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above, such as method 100. For example, in some embodiments, method 100 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 308.

[0102] In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 300 via ROM 302 and / or communication unit 309. When the computer program is loaded into RAM 303 and executed by computing unit 301, one or more steps of method 100 described above may be performed. Alternatively, in other embodiments, computing unit 301 may be configured to perform method 100 by any other suitable means (e.g., by means of firmware).

[0103] This invention merges all compiled modules of the program under test into a complete intermediate code to obtain a global view of the program under test. It then uses a hash algorithm to generate a unique label for each function, extracts function summaries containing function names and line ranges, and constructs call graphs and control flow graphs to obtain function call instruction information. By instrumenting basic blocks, it performs fuzz testing on the compiled and instrumented program under test, obtaining runtime data such as function basic block hit counts, coverage paths, and crash counts in real time. Based on fuzz test runtime data and static analysis data, it displays call graphs, control flow graphs, and real-time execution statistics. Interactive charts assist test engineers in locating fuzz testing bottlenecks and constraints, and provide semantic context to help test engineers better understand and intervene in the fuzz testing process, thereby improving fuzz test code coverage and defect detection rates.

[0104] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An interactive visualization method for overcoming bottlenecks in fuzz testing, characterized in that, The method includes the following steps: S110: Using the LLVM platform, all compiled modules of the program under test are merged into a complete intermediate code to obtain a global view of the program under test; S120: Use a hash algorithm to generate a unique label for each function and extract a function summary containing the function name and row range; S130: Construct a global call graph and control flow graph, obtain function call instruction information by scanning the basic blocks of each function, and collect static analysis data; S140: Instrument the basic blocks and update the coverage statistics; S150: Perform fuzz testing on the compiled and instrumented program under test, and obtain runtime data such as the hit count, coverage path, and number of crashes of basic function blocks in real time; S160: Based on the fuzz test runtime data and static analysis data, perform data-driven visualization to display the call graph, control flow graph, and real-time execution statistics in real time; S170: Assists test engineers in locating bottleneck constraints in fuzz testing through interactive diagrams and provides semantic context; in, In step S120, by scanning the debugging metadata of the basic function blocks, relevant information for each function is extracted, including the function name, parameter list, source file name, and the location information of the function's code line. The collected function information is constructed into a string containing information that distinguishes each function from others. A specific hash algorithm is used to perform a hash operation on the constructed string to generate a fixed-length hash value. When different inputs produce the same hash value, an open addressing and linked list collision resolution strategy is adopted to resolve hash collisions. Finally, the generated hash value is used as a unique label for the function, which is used to identify and reference specific functions in subsequent analysis and visualization processes. In step S170, test engineers use a visual interface to monitor real-time data from fuzzing, including code coverage, basic block hit counts, and crash information. By analyzing real-time data, they identify areas where test coverage is growing slowly or has stopped increasing. Through visualized call graphs and control flow graphs, they locate functions and basic blocks with low hit counts or that have not been executed. They review the source code corresponding to these functions and basic blocks to understand their semantics and execution context, and comprehend the code logic and execution constraints of bottleneck areas. They identify complex constraints that hinder the exploration of test input paths, and manually construct or update test inputs based on these constraints to trigger insufficiently explored code paths. They adjust input generation strategies or modify program configuration options to better guide the fuzzing process. They apply the constructed target inputs or updated test drivers to the fuzzing. They restart the fuzzing, monitor changes in test coverage and crash information, and verify the effectiveness of intervention measures. Throughout the fuzzing process, they continuously use the visual interface to monitor the test status and repeatedly adjust the test strategy based on the test results until satisfactory test coverage is achieved and potential problems are discovered.

2. The interactive visualization method for overcoming bottlenecks in fuzz testing as described in claim 1, characterized in that, In S110, during the compilation phase, additional library files are called to utilize the LLVM platform to resolve the dependencies between various compilation modules and obtain the internal call relationships of the program; all compilation modules are linked and loaded together to form a complete intermediate code, thus constructing a global view of the program under test.

3. The interactive visualization method for overcoming bottlenecks in fuzz testing as described in claim 1, characterized in that, In step S130, a global call graph and control flow graph are constructed by traversing the complete intermediate code to represent the program structure, including the call relationships between functions and the control flow between basic blocks within a function. An open-source static analysis tool is used to analyze the program control flow graph, and function call instruction information is obtained by scanning the basic blocks of each function.

4. The interactive visualization method for overcoming bottlenecks in fuzz testing as described in any one of claims 1-3, characterized in that, In step S140, a counter is created for each basic block based on the function's unique label to represent the number of times each basic block is executed. Instrumentation code is added at the entry point, branch jump point, and return point of each basic block to detect program crashes and update the corresponding counters. The instrumentation code needs to ensure that it can update the shared memory area used by fuzzing. Optimization measures are adopted to reduce the impact of instrumentation on program performance, including limiting the granularity of the counter, using atomic operations or locking mechanisms to prevent race conditions in a multi-threaded environment, and keeping the counter in a cache to speed up access. After instrumentation is completed, the modified intermediate code is passed to the backend compiler to generate an executable file containing the instrumentation code.

5. The interactive visualization method for overcoming bottlenecks in fuzz testing as described in claim 4, characterized in that, In S150, a fuzzing tool is used to perform fuzzing tests on the compiled and instrumented program under test; in order to collect and share runtime data in real time, a shared memory area is initialized when the program starts to store the data collected at runtime. During the dynamic execution of the program, based on instrumented code, execution information is recorded and local counters are updated, i.e., basic block hit counts; by recording events that jump from one basic block to another, the program execution path is traced and the program coverage path is recorded; the counters and path information updated by the instrumented code are periodically synchronized to shared memory, and the shared memory data is continuously updated and accessed as the program continues to run and process multiple input samples; based on the instrumented code, crash events are recorded and the number of crashes is recorded, and crash information is synchronized to shared memory in real time to ensure that critical information is not lost due to abnormal program termination.

6. The interactive visualization method for overcoming bottlenecks in fuzz testing as described in claim 5, characterized in that, In S160, the visualization component periodically reads data from shared memory, formats the collected data into a format suitable for network transmission, and updates the displayed statistics and charts; it displays the function call graph in the form of a force-directed graph; it displays the control flow graph using a tree layout based on the Reingold-Tilford algorithm; it hides the basic function blocks not covered in the fuzz test; and it displays the hierarchical structure of the basic blocks using the RT tree layout algorithm.

7. An electronic device, characterized in that, include: At least one processor and memory; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, implement the method described in any one of claims 1-6.

Images