A method and apparatus for dynamically determining an end block

Abstract

The present application discloses a method and apparatus for dynamically determining an end block. Based on each test case among all test cases, pre-fuzz testing is performed on a binary program to be tested, and the end block is recorded in an end block list; in response to a message indicating the end of the pre-fuzz testing, based on mutated test cases obtained by mutating the test cases, fuzz testing is performed on the binary program to be tested according to a preset rule, where the preset rule is used to dynamically determine the end block and update the end block list, and module testing is performed based on the updated end block list. This method can broaden the object of Fuzzing for scenarios such as network services on IoT devices that do not run to completion, and cooperate with the discovery mechanism of the End Block to provide guidance for the mutation of test examples during the Fuzzing process, thereby improving the speed of discovering vulnerabilities in binary programs on devices such as IoT.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a method and device for dynamically determining an End Block. Background Art

[0002] Fuzzing is a method of discovering software vulnerabilities by providing unexpected inputs to a target system and monitoring abnormal results. It is widely used by major software manufacturers to mine vulnerabilities in their own products, thereby reducing the vulnerabilities in the products. Currently, Fuzzing technology is usually applied to ordinary service processes or various module components, and the end of their software operation can be used as a sign of the end of a Fuzzing, which facilitates the rapid operation of Fuzzing. However, for scenarios where processes such as network services do not exit, such as network services running on Internet of Things (IoT) devices, the Fuzzing process cannot sense whether the end of the operation has been reached, resulting in a single Fuzzing not being able to end quickly, thus slowing down the entire Fuzzing process.

[0003] Based on this, for scenarios where processes do not exit, there is an urgent need to provide a technical solution that allows Fuzzing to sense the end of the operation, so as to achieve efficient Fuzzing in these scenarios. Summary of the Invention

[0004] Embodiments of this application provide a method and device for dynamically determining an End Block, which can dynamically confirm the End Block during the Fuzzing process, so as to confirm whether the current Fuzzing process has reached the end in the program operation process, improve the feedback update speed of Fuzzing, thereby improving the efficiency of Fuzzing, and overcoming the strong dependence of Fuzzing on the feedback of the object under test.

[0005] In a first aspect, embodiments of this application provide a method for dynamically determining an end block, including:

[0006] Based on each test case in all test cases, perform pre-fuzz testing on the binary program to be tested, and record the end block in the end block list;

[0007] In response to the message indicating the end of the pre-fuzz testing, perform fuzz testing on the binary program to be tested according to a preset rule based on the mutated test cases after the test cases are mutated. The preset rule is used to dynamically determine the end block and update the end block list, and perform the module testing based on the updated end block list.

[0008] Optionally, before pre-fuzz testing the binary program to be tested for each test case in all the test cases, the method further includes:

[0009] Static analysis of the binary program to be tested using a script to obtain multiple code blocks of the binary program to be tested.

[0010] Optionally, the preset rules include:

[0011] If the program paths of the binary program to be tested when running the mutant case and the corresponding test case are the same, and the binary program to be tested enters an end block in the end block list when running the mutant case, then terminate the fuzz testing based on the mutant case;

[0012] If the program paths of the binary program to be tested when running the mutant case and the corresponding test case are different, and the binary program to be tested enters an end block in the end block list when running the mutant case, then update the coverage rate, delete the breakpoints of the current new code blocks, record the test case corresponding to the mutant case, and terminate the fuzz testing based on the mutant case;

[0013] If the program paths of the binary program to be tested when running the mutant case and the corresponding test case are different, and the binary program to be tested does not enter an end block in the end block list when running the mutant case, then record the test case corresponding to the mutant case, re-perform pre-fuzz testing on the binary program to be tested based on the test case corresponding to the mutant case, and record the obtained new end block in the end block list.

[0014] Optionally, the coverage rate is the ratio of the number of code blocks passed by the binary program to be tested during operation to the number of code blocks included in the binary program to be tested.

[0015] Optionally, the method further includes:

[0016] Determine the coverage rate based on the result of fuzz testing the binary program to be tested, and the coverage rate is used to guide the selection of test cases.

[0017] Optionally, the pre-fuzz testing of the binary program to be tested includes:

[0018] Restore all the breakpoints in the code blocks passed by the binary program to be tested during the running of each test case until the end condition is met, and record the last restored breakpoint as an end block.

[0019] Optionally, the method is applied to an Internet of Things (IoT) device, and a fuzz testing client is installed on the IoT device.

[0020] Optionally, the fuzz testing client communicates with the fuzz testing server based on a fuzz input / output interface.

[0021] In a second aspect, an embodiment of the present application further provides an apparatus for dynamically determining an end block, including:

[0022] A pre-test unit, configured to perform pre-fuzz testing on a binary program to be tested based on each test case in all test cases, and record the end block in an end block list;

[0023] A test unit, configured to, in response to a message indicating the end of pre-fuzz testing, perform fuzz testing on the binary program to be tested based on a mutated test case obtained by mutating a test case, according to a preset rule, where the preset rule is used to dynamically determine an end block and update the end block list, and perform the module testing based on the updated end block list.

[0024] Optionally, the apparatus further includes:

[0025] A preparation unit, configured to statically analyze the binary program to be tested using a script to obtain multiple code blocks of the binary program to be tested before performing pre-fuzz testing on the binary program to be tested based on each test case in all test cases.

[0026] Optionally, the preset rule includes:

[0027] If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are the same, and the binary program to be tested enters an end block in the end block list when running the mutated test case, then terminate the fuzz testing based on the mutated test case;

[0028] If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are different, and the binary program to be tested enters an end block in the end block list when running the mutated test case, then update the coverage rate, delete breakpoints of the current new code block, record the test case corresponding to the mutated test case, and terminate the fuzz testing based on the mutated test case;

[0029] If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are different, and the binary program to be tested does not enter an end block in the end block list when running the mutated test case, then record the test case corresponding to the mutated test case, perform pre-fuzz testing on the binary program to be tested again based on the test case corresponding to the mutated test case, and record the obtained new end block in the end block list.

[0030] Optionally, the coverage rate is the ratio of the number of code blocks passed by the binary program to be tested during operation to the number of code blocks included in the binary program to be tested.

[0031] Optionally, the apparatus further comprises:

[0032] A determination unit, configured to determine a coverage rate based on the result of fuzz testing the binary program to be tested, where the coverage rate is used to guide the selection of test cases.

[0033] Optionally, the pre-test unit is specifically configured to:

[0034] Restore all breakpoints in the code blocks passed during the running of each test case of the binary program to be tested until an end condition is met, and record the last restored breakpoint as an end block.

[0035] Optionally, the apparatus is applied to an Internet of Things (IoT) device, and a fuzz testing client is installed on the IoT device.

[0036] Optionally, the fuzz testing client communicates with the fuzz testing server based on a fuzz input / output interface.

[0037] It should be noted that for the specific implementation manner and achieved effects of the apparatus for dynamically determining an end block provided in the second aspect, reference may be made to the description of the related embodiments of the method for dynamically determining an end block shown in the first aspect.

[0038] In a third aspect, an embodiment of the present application further provides a fuzz testing system, where the system includes a fuzz testing client and a fuzz testing server, and:

[0039] The fuzz testing client is configured to execute the method provided in the first aspect above;

[0040] The fuzz testing server is configured to communicate with the fuzz testing client based on a fuzz input / output interface and provide data required for fuzz testing.

[0041] Wherein, the fuzz testing client is carried on an Internet of Things (IoT) device.

[0042] In a fourth aspect, an embodiment of the present application further provides an electronic device, where the electronic device includes a processor and a memory:

[0043] The memory is used to store a computer program;

[0044] The processor is configured to execute the method provided in the first aspect above according to the computer program.

[0045] In a fifth aspect, an embodiment of the present application further provides a computer-readable storage medium for storing a computer program for executing the method provided in the first aspect above.

[0046] Thus, the embodiments of the present application have the following beneficial effects:

[0047] The embodiment of the present application provides a method for dynamically determining an end block. The method includes: First, based on each test case among all test cases, perform pre-fuzz testing on the binary program to be tested and record the end blocks in an end block list; Then, in response to a message indicating the end of pre-fuzz testing, perform fuzz testing on the binary program to be tested based on the mutated test cases after mutating the test cases according to a preset rule for dynamically determining end blocks and updating the end block list, and perform the module testing based on the updated end block list. It can be seen that through this method, for scenarios such as network services on IoT devices that do not run to completion, the problem of strong dependence of current Fuzzing on feedback or protocols such as the end of the object to be tested is solved, broadening the objects of Fuzzing. At the same time, in cooperation with the discovery mechanism of End Block, it provides guidance for the mutation of test examples during the Fuzzing process, thereby improving the speed of discovering binary program vulnerabilities on devices such as IoT. Description of the Drawings

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments recorded in the present invention, and those of ordinary skill in the art can also obtain other drawings based on these drawings.

[0049] Figure 1 A structural schematic diagram of an applicable scenario provided by an embodiment of the present application;

[0050] Figure 2 A flowchart of a method for dynamically determining an End Block provided by an embodiment of the present application;

[0051] Figure 3a A schematic diagram after preprocessing the test cases provided by an embodiment of the present application;

[0052] Figure 3b A schematic diagram after one Per Fuzz provided by an embodiment of the present application;

[0053] Figure 3c A schematic diagram of a case after Fuzzing provided by an embodiment of the present application;

[0054] Figure 4 Schematic structural diagram of an apparatus for dynamically determining an End Block provided by an embodiment of the present application;

[0055] Figure 5 Schematic structural diagram of a fuzz testing system provided by an embodiment of the present application;

[0056] Figure 6 Schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0057] To make the above objects, features, and advantages of the present application more obvious and understandable, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings and specific implementation manners. It can be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. In addition, it should be noted that for the sake of description, only parts related to the present application are shown in the accompanying drawings, not all structures.

[0058] For scenarios where processes such as network services do not exit, such as network services running on Internet of Things (IoT) devices, the Fuzzing process cannot perceive whether the end of the operation has been reached, resulting in a single Fuzzing not being able to end quickly, thus slowing down the entire Fuzzing process. Taking IoT devices as an example, with the boost of cutting-edge technologies such as Artificial Intelligence (AI), cloud computing, and 5th Generation Mobile Communication Technology (5G), IoT has developed rapidly in recent years. There are endless IoT applications in various forms and terminals with huge differences. The embedded systems carrying IoT applications are highly fragmented, resulting in a lack of unified security application standards and bringing various security problems. Therefore, Fuzzing technology is usually required to discover vulnerabilities in the service corresponding programs on IoT devices. Different from other devices, IoT devices usually carry network services. Therefore, Fuzzing for IoT devices can basically be regarded as a kind of Fuzzing for network services.

[0059] After the inventor's research, there are many network service fuzzing solutions for IoT devices. For example, fuzzing frameworks such as BooFuzz or Fuzzowski for protocols encapsulate various common service requests. Another example is the template-based fuzzing framework like dharma. The core points of these fuzzing solutions for network services on IoT devices are as follows: The current IoT devices use a certain common state-based service (such as the http service commonly). Therefore, the fuzzing process can perform template mutation based on the protocol, and then, according to the existing prior knowledge, feedback the current mutation logic through the returned status code and the returned information. Among them, there is a problem with state-based fuzzing mutation: Protocol-based fuzzing usually strongly depends on the protocol process. However, some of the protocols on IoT devices are not standard communication protocols and may not always respond with a status, which leads to this type of state-based fuzzing degenerating into mindless fuzzing with random mutation because no response is obtained, resulting in a decrease in the overall fuzzing efficiency. As a solution, by introducing fuzzing based on binary coverage feedback, the strong dependence on the feedback information of the object under test in this protocol-based fuzzing can be reduced, and instead, it depends on the instrumentation feedback process provided by fuzzing for the program. There are many common instrumentation methods currently, such as modifying based on source code or using DBI means to dynamically modify the executing program and other instrumentation methods. However, due to its size constraints, IoT devices are usually deployed on different architectures, which brings great problems to this fuzzing based on binary coverage feedback. As an example, the gdb debugger can be used to instrument the target process. By setting breakpoints in the specified code block (Block) and modifying the logic of the gdb debugger itself, the main behavior when the program runs to the breakpoint can be modified, thus achieving coverage feedback on the program running process. This solution utilizes a mature gdb solution and can be well compatible with the IoT platform; moreover, for the defects existing in the state-dependent fuzzing mentioned above, the fuzzing based on the gdb debugger proposes a concept of End Block, that is, a module is specified, and when the program runs to this module, the current fuzzing is regarded as ended. Through the concept of End Block, the end of fuzzing can be effectively located, so as to quickly feedback the fuzzing results and mutate the test cases.

[0060] Currently, the above-mentioned End Block is usually used for programs that require manual triggering of program termination, such as a graphical user interface (GUI). It usually analyzes the current program in combination with static analysis before the program runs, and uses the method of pre-fuzz testing (PreFuzz) to determine the Block existing at the time of timeout as the End Block, and then extracts the current address as a marker. In IoT devices, usually a service will not exit before an abnormal state occurs, and different states may have different End Blocks. Therefore, the method of obtaining the End Block through a single PreFuzz analysis cannot well determine whether the current Fuzzing has really reached the end of the program.

[0061] Based on this, the embodiments of the present application propose a technical solution for dynamically determining the End Block for scenarios without a clear end flag, such as network services on IoT devices, to solve the problems mentioned above. It can be understood that the embodiments of the present application can dynamically and reasonably confirm the position of the End Block through the mechanism of PreFuzz and dynamic adjustment of the End Block, improving the running efficiency of Fuzzing.

[0062] The method for dynamically determining the end block provided by the embodiments of the present application may include, for example: First, based on each test case in all test cases, perform pre-fuzz testing on the binary program to be tested, and record the end block in the end block list; then, in response to the message indicating the end of the pre-fuzz testing, based on the mutated test cases after mutating the test cases, perform fuzz testing on the binary program to be tested according to a preset rule, where the preset rule is used to dynamically determine the end block and update the end block list, and perform the module testing based on the updated end block list.

[0063] It can be seen that through this method, for scenarios such as network services on IoT devices that do not run to completion, it solves the problem of the strong dependence of current Fuzzing on feedback or protocols such as the end of the object to be tested, broadens the object of Fuzzing, and at the same time, in cooperation with the discovery mechanism of the End Block, provides guidance for the mutation of test examples in the Fuzzing process, thereby improving the speed of discovering binary program vulnerabilities on devices such as IoT.

[0064] To make the solution provided by the embodiments of the present application clearer, some terms mentioned in the embodiments of the present application are explained below.

[0065] Instrumentation: A means of controlling the execution of a binary program by modifying the code of the binary program, thereby changing the program's execution flow and ultimately achieving control over the binary program.

[0066] Interrupt Instruction (int3): A debugging technique of a debugger. By modifying the target address to a special int3 instruction code, when the program runs to the int3 instruction, the program will be interrupted. At this time, the programmer can observe the current state of the program or further modify the logic.

[0067] Code Block (Block): During the execution of a program, a set of instructions that are generally executed continuously is called an instruction set. A Block is a special instruction set. The first instruction of a Block is the end point of a certain jump instruction or the target block of some instructions, and the last instruction of a Block is an instruction that jumps to another Block.

[0068] End Block: The last Block reached in the current Fuzzing input data.

[0069] Program Path: A path composed of different Blocks. Generally, a program path represents a new execution logic.

[0070] Dynamic Fuzzing: A testing technique that discovers bugs by sending various test data to a specific target, causing the program to crash or have a logical error. Currently, Fuzzing is often used for vulnerability mining.

[0071] Code Coverage Feedback: The test data of traditional Fuzzing usually comes from the understanding of the target process. Therefore, the discovered vulnerabilities are often limited by the observer's perspective, and blind mutation will waste a lot of time. Current Fuzzing (such as AFL) will confirm whether the current mutation is reasonable by detecting whether new execution paths are found in the code flow of the incoming data. This feedback mechanism is called coverage feedback.

[0072] PreFuzz: Pre-fuzzing test. Usually before Fuzzing, the current test case (also called test data) will be run once to confirm that the test case is a valid test case. Sometimes some necessary data for other Fuzzing processes will be processed at this stage, such as generating the End Block.

[0073] Target Binary: The binary program to be tested.

[0074] Fuzz Engine: The fuzz testing server (or the program on the fuzz testing server) is used to read test cases and mutate the test cases.

[0075] Fuzz Sensor: The fuzz testing client (or the program on the fuzz testing client) is used to capture the coverage of the Target Binary. For example, it can be a client improved from the gdb debugger.

[0076] Fuzz IO: The fuzz testing input / output interface is used for communication between the Fuzz Engine and the Fuzz Sensor.

[0077] Seed: The test case. Since the test case is used as the starting point for mutation during the fuzzing process, it is also called the seed.

[0078] Mutation: The seed mutation stage. By mutating the seed, the input is changed to a certain extent, so that the test data can enter different blocks, increasing the probability of discovering vulnerabilities.

[0079] To facilitate the understanding of the specific implementation of the method for dynamically determining the End Block provided by the embodiments of the present application, the following will be described in conjunction with the accompanying drawings.

[0080] It should be noted that the main body implementing the method for dynamically determining the End Block can be the device for dynamically determining the End Block provided by the embodiments of the present application. This device can be carried on an electronic device or a functional module of an electronic device. The electronic device in the embodiments of the present application can be any device capable of implementing the method for dynamically determining the End Block in the embodiments of the present application. For example, it can be an IoT device.

[0081] Before introducing the embodiments of the present application, first, taking the device for dynamically determining the End Block carried on an IoT device as an example, an exemplary introduction to the applicable scenario is given, as Figure 1 shown.

[0082] See Figure 1, this scenario may include: Fuzz Engine 200 and IoT device 100. Among them, IoT device 100 may include Fuzz Sensor 110, and Fuzz Sensor 110 may include: Target Binary 111, instrumentation module Stub 112, tracing module Trace 113, and vulnerability detection module Santinizer 114. Fuzz Engine 200 may include seed mutation module Seed Mutation 210, seed queue module Seed Queue 220, and coverage detector Coveragechecker 230. Communication can be carried out between Fuzz Engine 200 and Fuzz Sensor 110 of IoT device 100 through fuzz input / output interface Fuzz IO 300.

[0083] It should be noted that Figure 1 the functions of each module and the steps executed in the embodiments of this application can be referred to the introduction in the following Figure 2 illustrated embodiments.

[0084] Figure 2 This is a schematic flowchart of a method for dynamically determining the End Block provided by the embodiments of this application. This method can be applied to IoT device 100 as shown in Figure 1 . A fuzz testing client 110 is installed on the IoT device 100. The fuzz testing client 110 communicates with the fuzz testing server 200 based on the fuzz input / output interface 300.

[0085] As shown in Figure 2 , this method may include the following S201 - S202:

[0086] S201, based on each test case in all test cases, perform pre-fuzz testing on the binary program to be tested, and record the end blocks in the end block list.

[0087] As an example, before S201, the embodiments of this application may also include preprocessing work. The preprocessing work may include, for example: using a script to statically analyze the binary program to be tested to obtain multiple code blocks of the binary program to be tested. It can also be understood as: setting breakpoints for the entire binary program to be tested. For example, referring to Figure 3a , this preprocessing work may be: before pre-fuzz testing, Fuzz Engine 200 sends the selected test cases to Fuzz Sensor 110, and Stub 112 in Fuzz Sensor 110 sets breakpoints for the binary program to be tested, obtaining 9 Blocks as shown in Figure 3a .

[0088] It should be noted that in the pre-fuzzing test stage, a relatively long timeout (such as 10 seconds) can be set.

[0089] For S201, first, the Fuzz Engine 200 can traverse all files and load all Seeds. At this time, the Seeds can be considered as some request data packets for normal operation; then, before Mutation of all Seeds, PreFuzz is performed. At this time, data communication is carried out through Fuzz IO, and the data is sent to the Target Binary 111, and the information of the test data (the size of the test data, index (such as serial number or name), etc.) is sent to the Fuzz Sensor 110; then, the Target Binary 110 runs normally and processes the data normally. The Fuzz Sensor 110 removes some breakpoints according to the EndBlock processing idea; finally, after Pre Fuzz ends, the Fuzz Sensor 110 records the current End Block, and notifies the Fuzz Engine 200 through the Fuzz IO 300 that the current Pre Fuzz has ended.

[0090] In Pre Fuzz, the processing idea of the Fuzz Sensor 110 for the End Block can be considered to include: not adopting any strategy, using the direct recovery strategy for all encountered breakpoints, and restoring all breakpoints in the code blocks passed during the running of each test case of the binary program to be tested until the end condition is met, and recording the last restored breakpoint as an end block. It can also be understood as: when a run is completed or ends due to timeout (greater than the preset timeout, such as greater than 10 seconds), the last eliminated Block can be recorded and added to the EndBlock list as the End Block. The result after one run can be seen Figure 3b As shown, the program path includes Block 1, Block 5, Block 8, and Block 9, and Block 9 is recorded as the End Block of this run. After repeating this process multiple times and inputting all current test cases once, an End Block list will be obtained. For example, the End Block list can be recorded as [END1, END2,....ENDn].

[0091] S202. In response to the message indicating the end of the pre-fuzzing test, based on the mutated test cases after mutating the test cases, perform fuzz testing on the binary program to be tested according to a preset rule. The preset rule is used to dynamically determine the end block and update the end block list, and perform the module testing based on the updated end block list.

[0092] Among them, after S201, when the Fuzz Engine 200 learns that the Pre Fuzz has ended, the Seed Mutation 210 can start mutating, and send the mutation results (also known as mutated test cases or mutated data) to the Target Binary 111, and at the same time notify the Fuzz Sensor 110 to enter the formal fuzzing. The message indicating the end of the pre-fuzzing test can refer to the message that the Fuzz Engine 200 notifies the Fuzz Sensor 110 to enter the formal fuzzing. The end of the pre-fuzzing test can mean that all test cases have been pre-tested.

[0093] After receiving the message from the Fuzz Engine 200 indicating the end of the pre-fuzzing test, the Fuzz Sensor 110 modifies the End Block processing logic, records the running results of the Target Binary 111, and registers the newly discovered End Block. When the Target Binary 111 runs to the End Block, the Fuzz Sensor 110 sends the current running results to the Fuzz Engine 200. The Fuzz Engine 200 obtains the code coverage through the returned information (such as whether the mutation is effective, mutation energy, etc.), and guides the Seed selection based on the code coverage. If a crash is found, process the crash information. After completing all the processing, repeat the above steps to continue the fuzz testing provided in the embodiments of the present application.

[0094] Among them, the processing logic of the modified End Block, that is, the preset rule in S202, it can be understood that in S202, the current breakpoint is not directly eliminated, but the breakpoint is restored according to a certain strategy (i.e., the preset rule). As an example, the preset rule may include: Case 1: The program paths of the mutant test case and the corresponding test case when the binary program under test runs are the same, and the binary program under test enters the end block in the end block list when running the mutant test case. Then, terminate the fuzz testing based on the mutant test case. Case 2: The program paths of the mutant test case and the corresponding test case when the binary program under test runs are different, and the binary program under test enters the end block in the end block list when running the mutant test case. Then, update the code coverage, delete the breakpoint of the current new code block, record the test case corresponding to the mutant test case, and terminate the fuzz testing based on the mutant test case. Case 3: The program paths of the mutant test case and the corresponding test case when the binary program under test runs are different, and the binary program under test does not enter the end block in the end block list when running the mutant test case. Then, record the test case corresponding to the mutant test case, re-perform pre-fuzz testing on the binary program under test based on the test case corresponding to the mutant test case, and record the obtained new end block in the end block list.

[0095] Specifically, when no new branch is triggered and directly enter the marked End Block, it is regarded as the completion of a Fuzzing, and the current Fuzzing process is directly terminated. When a new branch is triggered and enter the marked End Block, update the current code coverage information, delete the breakpoint of the current new Block, and record the current test case, and terminate the current Fuzzing process. When a new branch is triggered and does not enter the marked EndBlock, it will enter the state as shown in Figure 3c Since the current Block was not added to the End Block before, it may cause the need to wait for timeout to terminate the current Fuzzing process. At this time, the test case needs to be recorded, re-execute Pre Fuzz, find the latest New End Block, and add the New End Block to the End Block list. It should be noted that since the probability of the mutant test case triggering a new branch is small, the processing logics of Case 2 and Case 3 are triggered with a very small probability and usually do not have a great impact on Performance.

[0096] In some implementation manners, after S202, it may further include: determining the code coverage based on the result of fuzz testing on the binary program under test, where the code coverage is used to guide the selection of test cases.

[0097] It can be understood that in the embodiments of the present application, the coverage rate may refer to the ratio of the number of code blocks passed by the binary program to be tested during operation to the number of code blocks included in the binary program to be tested. For example, Figure 3b in, the coverage rate may be (4 / 9). In Figure 3b Based on Case 2, the updated coverage rate may be (4 + 1) / 9 = (5 / 9).

[0098] It can be seen that through the method provided by the embodiments of the present application, for scenarios such as network services on IoT devices that do not end, the problem of strong dependence of current Fuzzing on feedback or protocols such as the end of the object to be tested is solved, the object of Fuzzing is broadened, and at the same time, combined with the discovery mechanism of the End Block, it provides guidance for the mutation of test cases during the Fuzzing process, thereby improving the speed of discovering binary program vulnerabilities on IoT and other devices.

[0099] Correspondingly, the embodiments of the present application further provide a device 400 for dynamically determining the end block, as shown in Figure 4 The device 400 includes:

[0100] A pre-test unit 401, configured to perform pre-fuzz testing on the binary program to be tested based on each test case in all test cases, and record the end block in the end block list;

[0101] A test unit 402, configured to, in response to a message indicating the end of the pre-fuzz testing, perform fuzz testing on the binary program to be tested based on the mutated test cases after the test cases are mutated, according to a preset rule, where the preset rule is used to dynamically determine the end block and update the end block list, and perform the module testing based on the updated end block list.

[0102] As an example, the device 400 further includes:

[0103] A preparation unit, configured to statically analyze the binary program to be tested using a script before performing pre-fuzz testing on the binary program to be tested based on each test case in all test cases, to obtain multiple code blocks of the binary program to be tested.

[0104] As an example, the preset rule includes:

[0105] The program paths of the binary program to be tested when running the mutated test case and the corresponding test case are the same, and the binary program to be tested enters the end block in the end block list when running the mutated test case, then, terminate the fuzz testing based on the mutated test case;

[0106] If the program paths of the binary program to be tested when running the mutant case and the corresponding test case are different, and the binary program to be tested enters an end block in the end block list when running the mutant case, then update the code coverage, delete the breakpoints of the current new code block, record the test case corresponding to the mutant case, and terminate the fuzz testing based on the mutant case.

[0107] If the program paths of the binary program to be tested when running the mutant case and the corresponding test case are different, and the binary program to be tested does not enter an end block in the end block list when running the mutant case, then record the test case corresponding to the mutant case, re - perform pre - fuzz testing on the binary program to be tested based on the test case corresponding to the mutant case, and record the obtained new end block in the end block list.

[0108] As an example, the code coverage is the ratio of the number of code blocks passed by the binary program to be tested during operation to the number of code blocks included in the binary program to be tested.

[0109] As an example, the apparatus 400 further includes:

[0110] A determination unit, configured to determine the code coverage based on the result of fuzz testing on the binary program to be tested, where the code coverage is used to guide the selection of test cases.

[0111] As an example, the pre - testing unit is specifically configured to:

[0112] Restore all breakpoints in the code blocks passed during the process of running each test case of the binary program to be tested until the end condition is met, and record the last restored breakpoint as an end block.

[0113] As an example, the apparatus is applied to an Internet of Things (IoT) device, and a fuzz testing client is installed on the IoT device.

[0114] Wherein, the fuzz testing client communicates with the fuzz testing server based on a fuzz input - output interface.

[0115] In addition, an embodiment of the present application further provides a fuzz testing system 500, as Figure 5 shown, the system 500 includes a fuzz testing client 501 and a fuzz testing server 502, where:

[0116] The fuzz testing client 501 is configured to execute the above - mentioned Figure 2 method;

[0117] The fuzz testing server 502 is used to communicate with the fuzz testing client 501 based on the fuzz input / output interface 503 and provide the data required for fuzz testing.

[0118] Among them, the fuzz testing client 501 is carried on the Internet of Things (IoT) device 1.

[0119] In addition, an embodiment of the present application also provides an electronic device 600, as Figure 6 shown, the electronic device 600 includes a processor 601 and a memory 602:

[0120] The memory 602 is used to store computer programs;

[0121] The processor 601 is used to execute the method provided by the embodiment of the present application according to the computer program.

[0122] In addition, an embodiment of the present application also provides a computer-readable storage medium, which is used to store a computer program, and the computer program is used to execute the method provided by the embodiment of the present application.

[0123] Through the description of the above embodiments, those skilled in the art can clearly understand that all or part of the steps in the above embodiment methods can be implemented by means of software plus a general hardware platform. Based on such an understanding, the technical solution of the present application can be embodied in the form of a software product, and the computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions for causing a computer device (which can be a personal computer, a server, or a network communication device such as a router) to execute the methods described in each embodiment or some parts of the embodiments of the present application.

[0124] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between each embodiment can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, for system embodiments and device embodiments, since they are basically similar to method embodiments, they are described relatively simply, and the relevant parts can refer to the partial description of the method embodiments. The device and system embodiments described above are only illustrative. The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement without creative work.

[0125] The above are only the preferred embodiments of the present application and are not intended to limit the protection scope of the present application. It should be noted that for those of ordinary skill in the art, several improvements and refinements can be made without departing from the present application, and these improvements and refinements should also be regarded as within the protection scope of the present application.

Claims

1. A method for dynamically determining an end block, characterized in that, including: Based on each test case among all test cases, perform pre-fuzz testing on the binary program to be tested, and record the end blocks into an end block list; In response to the message indicating the end of pre-fuzz testing, based on the mutated test cases after mutating the test cases, perform fuzz testing on the binary program to be tested according to a preset rule, where the preset rule is used to dynamically determine end blocks and update the end block list, and perform the module testing based on the updated end block list; Performing pre-fuzz testing on the binary program to be tested includes: Restore all breakpoints in the code blocks passed through during the running of each test case of the binary program to be tested until the end condition is met, and record the last restored breakpoint as an end block; The preset rule includes: If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are the same, and the binary program to be tested enters an end block in the end block list when running the mutated test case, then terminate the fuzz testing based on the mutated test case; If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are different, and the binary program to be tested enters an end block in the end block list when running the mutated test case, then update the code coverage, delete the breakpoints of the current new code block, record the test case corresponding to the mutated test case, and terminate the fuzz testing based on the mutated test case; If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are different, and the binary program to be tested does not enter an end block in the end block list when running the mutated test case, then record the test case corresponding to the mutated test case, perform pre-fuzz testing on the binary program to be tested again based on the test case corresponding to the mutated test case, and record the obtained new end blocks into the end block list.

2. The method according to claim 1, wherein Before performing pre-fuzz testing on the binary program to be tested based on each test case among all test cases, the method further includes: Use a script to statically analyze the binary program to be tested to obtain multiple code blocks of the binary program to be tested.

3. The method according to claim 1, characterized in that, The code coverage is the ratio of the number of code blocks passed through during the running of the binary program to be tested to the number of code blocks included in the binary program to be tested.

4. The method according to claim 3, characterized in that, The method further includes: Determine the code coverage based on the result of performing fuzz testing on the binary program to be tested, where the code coverage is used to guide the selection of test cases.

5. The method according to any one of claims 1 to 4, characterized in that, The method is applied to an Internet of Things (IoT) device, and a fuzz testing client is installed on the IoT device.

6. The method according to claim 5, wherein The fuzz testing client communicates with a fuzz testing server based on a fuzz input / output interface.

7. A device for dynamically determining an end block, characterized in that, including: A pre-test unit for performing pre-fuzz testing on the binary program to be tested based on each test case among all test cases, and recording the end blocks into an end block list; A test unit, which is configured to perform fuzz testing on the binary program to be tested according to a preset rule based on a mutated test case after mutating a test case in response to a message indicating the end of pre-fuzz testing. The preset rule is used to dynamically determine an end block and update a list of end blocks, and perform the module testing based on the updated list of end blocks; The pre-test unit is specifically configured to: Restore all breakpoints in the code blocks passed during the running of each test case of the binary program to be tested until an end condition is met, and record the last restored breakpoint as an end block; The preset rule includes: If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are the same, and the binary program to be tested enters an end block in the list of end blocks when running the mutated test case, then terminate the fuzz testing based on the mutated test case; If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are different, and the binary program to be tested enters an end block in the list of end blocks when running the mutated test case, then update the code coverage, delete the breakpoints of the current new code block, record the test case corresponding to the mutated test case, and terminate the fuzz testing based on the mutated test case; If the program paths of the binary program to be tested when running the mutated test case and the corresponding test case are different, and the binary program to be tested does not enter an end block in the list of end blocks when running the mutated test case, then record the test case corresponding to the mutated test case, re-perform pre-fuzz testing on the binary program to be tested based on the test case corresponding to the mutated test case, and record the obtained new end block in the list of end blocks.

8. A fuzz testing system, characterized in that, The system includes a fuzz testing client and a fuzz testing server, where: The fuzz testing client is configured to execute the method according to any one of claims 1-6 above; The fuzz testing server is configured to communicate with the fuzz testing client based on a fuzz input / output interface and provide data required for fuzz testing.

9. The system according to claim 8, wherein The fuzz testing client is carried on an Internet of Things (IoT) device.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory: The memory is used to store a computer program; The processor is configured to execute the method according to any one of claims 1-6 based on the computer program.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, and the computer program is used to execute the method according to any one of claims 1-6.

Images