Interactive visualization method, device and equipment for fuzz test bottleneck breakthrough

Abstract

The invention relates to an interactive visualization method, device and equipment for fuzzy test bottleneck breakthrough, and belongs to the field of network security. According to the method, all compiling modules in a tested program are combined into a complete intermediate code, and a global view of the tested program is obtained; generating a unique label for each function by using a hash algorithm; constructing a call graph and a control flow graph, and obtaining function call instruction information by scanning a basic block of each function; carrying out pile insertion on the basic blocks; performing a fuzzy test on the tested program after compiling and instrumentation, and obtaining runtime data in real time; according to the fuzzy test runtime data and the static analysis data, data-driven visualization is carried out, and a call graph, a control flow graph and real-time execution statistical information are displayed in real time; a test engineer is assisted through an interactive chart, and fuzzy test bottleneck constraints are positioned. According to the method, a test engineer can be helped to better understand and intervene the fuzzy test process, and the fuzzy test code coverage rate and the defect detection number are improved.

Description

Technical Field

[0001] The present invention belongs to the field of network security, and in particular relates to an interactive visualization method, device and equipment for breaking through the bottleneck of fuzzy testing. Background Art

[0002] Fuzz testing is an automated testing technology that automatically or semi-automatically generates random data according to certain rules, and then inputs the generated random data into the entry of the dynamically running program under test, while monitoring whether the program under test has any abnormalities, so as to discover security defects. Currently, fuzz testing technology has been widely used in the field of vulnerability mining. Its performance is limited by the complex constraints in large programs, making it easy for the test to reach a bottleneck after a period of time, thereby inhibiting the improvement of fuzz testing coverage. Summary of the invention

[0003] 1. Technical issues to be resolved

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

[0005] (II) Technical solution

[0006] In order to solve the above technical problems, the present invention proposes an interactive visualization method for breaking through the bottleneck of fuzz testing, which comprises the following steps:

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

[0008] S120: Generate a unique label for each function using a hash algorithm, and extract a function summary including a function name and a line 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: inserting the basic block and updating the coverage statistics;

[0011] S150: Perform fuzz testing on the compiled and instrumented program under test, and obtain runtime data such as hit counts, coverage paths, and crash numbers of function basic blocks in real time;

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

[0013] S170: Assist test engineers with locating fuzz testing bottleneck constraints through interactive diagrams and provide semantic context.

[0014] Furthermore, in S110, during the compilation phase, by calling additional library files and utilizing the LLVM platform, the dependencies between the compilation modules are parsed to obtain the calling relationships within the program; all compilation modules are linked and loaded together to merge into a complete intermediate code to construct a global view of the program under test.

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

[0016] Furthermore, in S130, by traversing the complete intermediate code, a global call graph and control flow graph are constructed to represent the structure of the program, including the calling relationship between functions and the control flow between basic blocks within the 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.

[0017] Furthermore, in the S140, a counter is created for each basic block according to the unique function label to indicate the number of times each basic block is executed; stub code is added at the entry, branch jump, and return of each basic block to detect program crashes and update the corresponding counters at the same time; the stub code needs to ensure that the shared memory area used by the fuzz test can be updated; optimization measures are adopted to reduce the impact of stub on program performance, including limiting the granularity of the counter, using atomic operations or lock mechanisms to prevent race conditions in a multi-threaded environment, and keeping the counter in the cache to speed up access; after completing the stub, the modified intermediate code is passed to the back-end compiler to generate an executable file containing the stub code.

[0018] Furthermore, in the S150, a fuzz testing tool is used to perform fuzz testing 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 data collected during runtime; during the dynamic execution of the program, based on the instrumentation code, the execution information is recorded to update the local counter, that is, the basic block hit count; by recording events of jumping from one basic block to another, the program execution path is tracked and the program coverage path is recorded; the counter and path information updated by the instrumentation 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 instrumentation 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 key information is not lost due to abnormal termination of the program.

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

[0020] Furthermore, in S170, the test engineer uses a visual interface to monitor the real-time data of the fuzz test, including code coverage, basic block hit counts, and crash information; identifies parts where the test coverage grows slowly or stops increasing by analyzing real-time data; locates functions and basic blocks with low hit counts or that are not executed through visually displayed call graphs and control flow graphs; views the source code corresponding to these functions and basic blocks, understands their semantics and execution contexts, and understands the code logic and execution constraints in the bottleneck area; identifies complex constraints that hinder the test input exploration path, and manually constructs or updates the test input based on the identified complex constraints so that it can trigger code paths that have not been fully explored; better guides the fuzz testing process by adjusting the input generation strategy or modifying the program's configuration options; applies the constructed target input or updated test driver to the fuzz test; restarts the fuzz test, monitors changes in test coverage and crash information, and verifies the effectiveness of intervention measures; continuously uses the visual interface to monitor the test status during the fuzz testing process, and repeatedly adjusts the test strategy based on the test results until satisfactory test coverage is achieved and enough potential problems are discovered.

[0021] The present invention also provides an interactive visualization device for breaking through the bottleneck of fuzzy testing, the device comprising:

[0022] An encryption module, used to generate a unique label for each function using a hash algorithm, and extract a function summary including a function name and a row range to obtain a unique identifier of 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 build a call graph and a 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] Initialization module, used to perform fuzz testing on the program under test and initialize shared memory;

[0026] Statistics update module, used to obtain and update the runtime data of function basic blocks in real time, including: hit counts, coverage paths and crash numbers;

[0027] The visualization module is used to perform data-driven visualization based on the fuzz test runtime data and static analysis results, and to display the call graph, control flow graph, and real-time execution statistics in real time. It assists test engineers through interactive charts to locate fuzz test bottleneck constraints and provide semantic context.

[0028] The present invention also provides an electronic device, comprising: at least one processor and a memory; the memory stores instructions that can be executed by the at least one processor, and the instructions implement the described method when executed by the at least one processor.

[0029] (III) Beneficial effects

[0030] The present invention proposes an interactive visualization method, device and equipment for breaking through the bottleneck of fuzz testing. The present invention obtains a global view of the program under test by merging all compiled modules in the program under test into a complete intermediate code, generates a unique label for each function by using a hash algorithm, extracts a function summary including the function name and line range, and then constructs a call graph and a control flow graph to obtain function call instruction information, and performs fuzz testing on the compiled and instrumented program under test by inserting basic blocks, obtains runtime data such as hit counts, coverage paths and crash numbers of function basic blocks in real time, and displays call graphs, control flow graphs and real-time execution statistics in real time based on fuzz test runtime data and static analysis data, assists test engineers with locating fuzz test bottleneck constraints through interactive charts, and provides semantic context to assist test engineers in better understanding and intervening in the fuzz test process, thereby improving fuzz test code coverage and the number of defect detections. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1A flowchart of an interactive visualization method for breaking through a fuzz testing bottleneck disclosed in the present invention;

[0032] Figure 2 A block diagram of an interactive visualization device for breaking through a fuzzy testing bottleneck disclosed in the present invention;

[0033] Figure 3 FIG. 1 is a block diagram of an exemplary electronic device capable of implementing an embodiment of the present disclosure. DETAILED DESCRIPTION

[0034] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0035] According to a first aspect of the present disclosure, an interactive visualization method for breaking through a fuzz testing bottleneck is provided. The method comprises:

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

[0037] A hash algorithm is used to generate a unique label for each function, and a function summary containing the function name and line range is extracted;

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

[0039] Instrument basic blocks and update coverage statistics;

[0040] Perform fuzz testing on the compiled and instrumented program to obtain runtime data such as hit counts of function basic blocks, coverage paths, and crash numbers in real time;

[0041] Perform data-driven visualization based on the fuzz test runtime data and static analysis data to display call graphs, control flow graphs, and real-time execution statistics in real time;

[0042] Assist test engineers with interactive diagrams to locate fuzz testing bottleneck constraints and provide semantic context.

[0043] Furthermore, during the compilation phase, by calling additional library files and utilizing the LLVM platform, the dependencies between the various compilation modules are parsed to obtain the calling relationships within the program; all compilation modules are linked and loaded together to merge into a complete intermediate code to build a global view of the program under test.

[0044] Furthermore, by scanning the debugging metadata of the function basic blocks, relevant information of each function is extracted, including the function name, parameter list, source file name and location information of the function code line, etc.; the collected function information is constructed into a string, which contains enough information about each function to distinguish different functions; a specific hash algorithm is used to perform a hash operation on the constructed string to generate a hash value of a fixed length; in rare cases, different inputs may produce the same hash value. In order to resolve hash conflicts, conflict resolution strategies such as open addressing and linked list method are adopted; the generated hash value is used as the unique label of 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 structure of the program, including the calling relationship between functions and the control flow between basic blocks within the function; function call instruction information is obtained by scanning the basic blocks of each function.

[0046] Furthermore, according to the unique label of the function, a counter is created for each basic block to indicate the number of times each basic block is executed; stub code is added at the entry, branch jump, and return of each basic block to detect program crashes, such as access violations, segmentation errors, etc., and the corresponding counters are updated at the same time; fuzz testing usually uses shared memory to track code coverage, and it is necessary to ensure that the stub code can update these shared memory areas; optimization measures are taken to reduce the impact of stubs on program performance, including limiting the granularity of counters, using atomic operations or lock mechanisms to prevent race conditions in multi-threaded environments, and keeping counters in cache to speed up access; after completing the stub, the modified LLVMIR is passed to the backend compiler to generate an executable file containing the stub code.

[0047] Furthermore, fuzz testing tools such as AFL are used to perform fuzz testing on the compiled and instrumented program. 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 the instrumented code, the execution information is recorded to update the local counter, that is, the basic block hit count. By recording events that jump from one basic block to another, the program execution path is tracked 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. The crash information is synchronized to the shared memory in real time to ensure that key 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 in the shared memory, formats the collected data into a format suitable for network transmission, and updates the displayed statistics and charts; displays the function call graph in the form of a force-directed graph; displays the control flow graph using a tree layout based on the Reingold-Tilford algorithm; hides the basic blocks of functions that are not covered in the fuzz test; and displays the hierarchy of basic blocks using an RT tree layout algorithm.

[0049] Furthermore, the test engineer uses a visual interface to monitor the real-time data of the fuzz test, including code coverage, basic block hit counts, and crash information; by analyzing the real-time data, identify the parts where the test coverage grows slowly or stops increasing, which are usually bottlenecks caused by complex constraints or insufficiently explored code areas; locate functions and basic blocks with low hit counts or that are not executed through visually displayed call graphs and control flow graphs; view the source code corresponding to these functions and basic blocks, understand their semantics and execution context, and understand the code logic and execution constraints in the bottleneck area; identify complex constraints that hinder the test input exploration path, such as array sorting, virtual function calls, etc.; based on the identified constraints, manually construct or update the test input so that it can trigger the insufficiently explored code path; adjust the input generation strategy or modify the program configuration options to better guide the fuzz test process; apply the constructed target input or updated test driver to the fuzz test; restart the fuzz test, monitor the changes in test coverage and crash information, and verify the effectiveness of the intervention measures; continuously use the visual interface to monitor the test status during the fuzz test process, and repeatedly adjust the test strategy based on the test results until a satisfactory test coverage is achieved and enough potential problems are discovered.

[0050] The present invention also provides an interactive visualization device for breaking through the bottleneck of fuzzy testing, the device comprising:

[0051] An encryption module, used to generate a unique label for each function using a hash algorithm, and extract a function summary including a function name and a row range to obtain a unique identifier of 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 build a call graph and a 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 detect program crashes, such as access violations and segmentation errors;

[0054] Initialization module, used to perform fuzz testing on the program under test and initialize shared memory;

[0055] Statistics update module, used to obtain and update runtime data such as hit counts, coverage paths, and crash counts of function basic blocks in real time;

[0056] The visualization module is used to perform data-driven visualization based on the fuzz test runtime data and static analysis results, and to display the call graph, control flow graph, and real-time execution statistics in real time. It assists test engineers through interactive charts to locate fuzz test bottleneck constraints and provide semantic context.

[0057] The present invention also provides an electronic device, which includes a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the above method when executing the program.

[0058] The present invention also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the method described above is implemented.

[0059] Embodiment 1:

[0060] In view of the bottleneck problem of fuzz testing in the prior art being restricted by complex constraints in large programs, the embodiments of the present disclosure propose the following technical solutions: by combining the static analysis data of the tested program and the fuzz test runtime data, a visual interface interactive display of the fuzz test process is implemented to assist test engineers in locating test bottlenecks, thereby improving the fuzz test code coverage and the number of defect detections. The following is a detailed description using a detailed embodiment.

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

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

[0063] Among them, in order to improve compilation efficiency, modern compilation systems usually divide compilation modules during the compilation stage and compile each module in parallel. This method cannot directly obtain the calling relationship within the program, and it is difficult to build a global overview of the target program to be tested.

[0064] In this embodiment, during the compilation phase, multiple modules are linked into a single larger module by calling additional library files and utilizing the linking tool (such as LLVM linker, LLD) in the LLVM platform. This step involves parsing the dependencies of each module and merging them into a single program representation.

[0065] S120: Generate a unique label for each function using a hash algorithm, and extract a function summary including a function name and a line range.

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

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

[0068] Specifically, first extract the relevant information of each function from the source code or LLVM's intermediate code IR, including: function name, parameter list, source file name and starting line number, etc.; construct the collected function information into a string, which should contain enough information to distinguish different functions; use the selected hash algorithm to perform hash operation on the constructed string to generate a hash value of fixed length; in rare cases, different inputs may produce the same hash conflict. In order to deal with this situation, conflict resolution strategies such as open addressing and linked list method are adopted; finally, the generated hash value is used as the unique label of the function, which can be used to identify and reference specific functions in subsequent analysis and visualization.

[0069] S130: Build 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 the function call instruction information is obtained by scanning the basic blocks of each function.

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

[0072] Among them, the instrumentation technology refers to inserting probes into specific locations of the program on the basis of ensuring the logical integrity of the original program. The probes collect information in the code, including the function itself, function parameter values, return values, etc., thereby collecting dynamic context information when the program is running.

[0073] In some embodiments, it is generally desired to collect code coverage, branch coverage and function call coverage during program runtime through probes. If code coverage is to be collected, it can be equivalent to function block coverage. The execution process of the program code can be obtained by inserting stubs at the function entry, branch jump and function return. Branch coverage can also be obtained synchronously. Function call coverage can generally be obtained by inserting a probe at the function entry. At the same time, combined with all the call path information of the function, the uncalled path information can be obtained.

[0074] Considering the information required by the visualization module, we choose to insert specific probes at the function entry, branch jump, and function return for instrumentation processing.

[0075] In this embodiment, the dynamic instrumentation tool may be an “Intel Pintool” instrumentation tool.

[0076] S150: Perform fuzz testing on the compiled and instrumented program under test, and obtain runtime data such as hit counts, coverage paths, and crash numbers of function basic blocks in real time.

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

[0078] The shared memory has a hash table that stores the bitmap, which saves the execution path covered by the test. It is usually a 64K byte array. Each byte in the bitmap represents the number of times an edge (jumping from one program block to another) is executed. The hash index of the edge is the XOR of the addresses of the two program blocks modulo 64K. By running the binary program under test generated by the instrumented compilation, when the fuzz test starts, the probe will collect all the data, including the hit count of the basic block, the coverage path and the number of crashes, and update and store the information.

[0079] In this embodiment, in addition to the bitmap hash table, the shared memory also includes a global counter for storing the hit count of the basic block. To avoid counter saturation, the original counter will be reset to zero after each read. At the same time, in order to reduce overhead, the counter is stored in the cache and the size is limited to 16 bits.

[0080] From the perspective of comprehensive visualization and real-time performance, initializing shared memory includes two parts: one is to allocate and initialize a 64K bitmap hash table; the other is to set and reset a 16-bit counter stored in the cache.

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

[0082] Among them, visualization technology integrates graphics, data analysis and human-computer interaction technology, uses the visual interactive interface as a channel, integrates people's experience cognition and perception ability into the professional data and program analysis process, and completes effective logical analysis and positioning decisions.

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

[0084] S170: Assist test engineers with locating fuzz testing bottleneck constraints through interactive diagrams and provide semantic context.

[0085] In this embodiment, the test engineer can follow the following steps to interact with and use the visualization interface: first, the test engineer views the current fuzz test process through the Web interface, and determines whether the current fuzz test has entered a bottleneck period based on the charts and data provided by the visualization, such as whether the path coverage tends to be stable or the time since the last new path was discovered is long; then, the test engineer navigates to potential intervention points through the visualized call graph and control flow graph, and loads the corresponding code snippets. At the same time, the Web front end can provide the test engineer with semantic context to better understand the cause of the bottleneck; finally, the test engineer intervenes in the fuzz test process by constructing specific target seeds or updating the test driver to break through the test bottleneck and achieve higher path coverage.

[0086] Embodiment 2:

[0087] The above is an introduction to the method embodiment. The following is a further explanation of the scheme disclosed in the present invention through an apparatus embodiment.

[0088] Figure 2 FIG. 2 shows a block diagram of an interactive fuzzy test visualization device 200 according to an embodiment of the present disclosure. 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 summary including a function name and a row range to obtain a function unique identifier;

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

[0091] The 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 errors, etc.;

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

[0093] A statistics update module 250 is used to obtain and update runtime data such as hit counts, coverage paths, and crash counts of function basic blocks in real time;

[0094] The visualization module 260 is used to perform data-driven visualization based on the fuzz test runtime data and static analysis results, and to display the call graph, control flow graph and real-time execution statistics in real time. It assists test engineers through interactive charts to locate fuzz test bottleneck constraints and provide semantic context.

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

[0096] Embodiment 3:

[0097] According to an embodiment of the present disclosure, the present 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 an embodiment 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 processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

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

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

[0101] The computing unit 301 may be a variety of general and / or special 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 dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 301 performs the various methods and processes described above, such as method 100. For example, in some embodiments, the method 100 may be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as a 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 the ROM 302 and / or the communication unit 309. When the computer program is loaded into the RAM 303 and executed by the computing unit 301, one or more steps of the method 100 described above may be performed. Alternatively, in other embodiments, the computing unit 301 may be configured to execute the method 100 in any other appropriate manner (e.g., by means of firmware).

[0103] The present invention combines all compiled modules in the tested program into a complete intermediate code to obtain a global view of the tested program, generates a unique label for each function using a hash algorithm, extracts a function summary including the function name and line range, and then constructs a call graph and a control flow graph to obtain function call instruction information. The compiled and instrumented tested program is fuzz tested by inserting basic blocks, and runtime data such as hit counts, coverage paths, and crash numbers of function basic blocks are obtained in real time. Based on the fuzz test runtime data and static analysis data, the call graph, control flow graph, and real-time execution statistics are displayed in real time. The test engineer is assisted by interactive charts to locate the bottleneck constraints of the fuzz test and provide semantic context to assist the test engineer to better understand and intervene in the fuzz test process, thereby improving the fuzz test code coverage and the number of defects detected.

[0104] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the technical principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. An interactive visualization method for breaking through the bottleneck of fuzz testing, characterized in that: The method comprises the following steps: S110: using the LLVM platform, merging all compiled modules in the program under test into a complete intermediate code to obtain a global view of the program under test; S120: Generate a unique label for each function using a hash algorithm, and extract a function summary including a function name and a line 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: inserting the basic block and updating the coverage statistics; S150: Perform fuzz testing on the compiled and instrumented program under test, and obtain runtime data such as hit counts, coverage paths, and crash numbers of function basic blocks in real time; S160: Perform data-driven visualization according to the fuzz test runtime data and static analysis data, and display the call graph, control flow graph and real-time execution statistics in real time; S170: Assist test engineers with locating fuzz testing bottleneck constraints through interactive diagrams and provide semantic context.

2. The interactive visualization method for breaking through the bottleneck of fuzz testing according to claim 1, characterized in that: In S110, during the compilation phase, by calling additional library files and utilizing the LLVM platform, the dependencies between the various compilation modules are parsed to obtain the calling relationships within the program; all compilation modules are linked and loaded together to merge into a complete intermediate code to construct a global view of the program under test.

3. The interactive visualization method for breaking through the bottleneck of fuzz testing according to claim 1, characterized in that: In the S120, by scanning the debugging metadata of the function basic block, relevant information of each function is extracted, including the function name, parameter list, source file name and location information of the function code line; the collected function information is constructed into a string, which contains enough information of each function to distinguish different functions; a specific hash algorithm is used to perform a hash operation on the constructed string to generate a hash value of a fixed length; In rare cases, different inputs may produce the same hash value. To resolve hash conflicts, an open addressing and linked list conflict resolution strategy is adopted. Finally, the generated hash value is used as the unique label of the function, which is used to identify and reference specific functions in subsequent analysis and visualization processes.

4. The interactive visualization method for breaking through the bottleneck of fuzz testing according to claim 1, characterized in that: In S130, by traversing the complete intermediate code, a global call graph and control flow graph are constructed to represent the structure of the program, including the calling relationship between functions and the control flow between basic blocks within the 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.

5. The interactive visualization method for breaking through the fuzzy testing bottleneck according to any one of claims 1 to 4, characterized in that: In the S140, a counter is created for each basic block according to the unique function label to indicate the number of times each basic block is executed; stub code is added at the entry, branch jump, and return of each basic block to detect program crashes and update the corresponding counters at the same time; the stub code needs to ensure that the shared memory area used by the fuzz test can be updated; optimization measures are adopted to reduce the impact of stub on program performance, including limiting the granularity of the counter, using atomic operations or lock mechanisms to prevent race conditions in a multi-threaded environment, and keeping the counter in the cache to speed up access; after completing the stub, the modified intermediate code is passed to the back-end compiler to generate an executable file containing the stub code.

6. The interactive visualization method for breaking through the bottleneck of fuzz testing according to claim 5, characterized in that: In the S150, a fuzz test tool is used to perform fuzz testing 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 is started to store the data collected during runtime; During the dynamic execution of the program, based on the instrumentation code, the execution information is recorded to update the local counter, that is, the basic block hit count; by recording the event of jumping from one basic block to another, the program execution path is tracked and the program coverage path is recorded; the counter and path information updated by the instrumentation code are regularly 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 instrumentation 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 key information is not lost due to abnormal program termination.

7. The interactive visualization method for breaking through the bottleneck of fuzz testing according to claim 6, characterized in that: In the S160, the visualization component periodically reads the data in the shared memory, formats the collected data into a format suitable for network transmission, updates the displayed statistical information and charts; displays the function call graph in the form of a force-directed graph; displays the control flow graph using a tree layout based on the Reingold-Tilford algorithm; hides the function basic blocks that are not covered in the fuzz test; and displays the hierarchical structure of the basic blocks using an RT tree layout algorithm.

8. The interactive visualization method for breaking through the bottleneck of fuzz testing according to claim 7, characterized in that: In the S170, the test engineer uses a visual interface to monitor the real-time data of the fuzz test, including code coverage, basic block hit counts, and crash information; identifies the part where the test coverage grows slowly or stops increasing by analyzing the real-time data; locates the functions and basic blocks with low hit counts or that are not executed through the visually displayed call graph and control flow graph; views the source code corresponding to these functions and basic blocks, understands their semantics and execution context, and understands the code logic and execution constraints of the bottleneck area; identifies the complex constraints that hinder the test input exploration path, and manually constructs or updates the test input based on the identified complex constraints so that it can trigger the code path that is not fully explored; adjusts the input generation strategy or modifies the configuration options of the program to better guide the fuzz test process; Apply the constructed target input or updated test driver to the fuzz test; restart the fuzz test, monitor the changes in test coverage and crash information, and verify the effectiveness of the intervention measures; During the fuzz testing process, the visual interface is continuously used to monitor the test status, and the test strategy is repeatedly adjusted according to the test results until satisfactory test coverage is achieved and enough potential problems are discovered.

9. An interactive visualization device for breaking through the bottleneck of fuzz testing, characterized in that: The device includes: An encryption module, used to generate a unique label for each function using a hash algorithm, and extract a function summary including a function name and a row range to obtain a unique identifier of the function; 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 build a call graph and a control flow graph; 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; Initialization module, used to perform fuzz testing on the program under test and initialize shared memory; Statistics update module, used to obtain and update the runtime data of function basic blocks in real time, including: hit counts, coverage paths and crash numbers; The visualization module is used to perform data-driven visualization based on the fuzz test runtime data and static analysis results, and to display the call graph, control flow graph, and real-time execution statistics in real time. It assists test engineers through interactive charts to locate fuzz test bottleneck constraints and provide semantic context.

10. 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, and when the instructions are executed by the at least one processor, the method of any one of claims 1 to 8 is implemented.

Images