Code testing method and device, computing device, and storage medium

Abstract

The application discloses a code testing method and device, a computing device and a storage medium. The method is executed in the computing device, and the method comprises the following steps: pruning invalid code branches in a source code file to be tested to obtain one or more dangerous code branches; constructing a predetermined sample and a sample generation strategy based on the one or more dangerous code branches; generating an input sample based on the predetermined sample and the sample generation strategy; and performing a fuzz test on the dangerous code branches based on the input sample. According to the technical scheme of the application, the range of the code fuzz test is reduced, and the test efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of testing technology, and in particular to a code testing method, a code testing device, a computing device, and a storage medium. Background Technology

[0002] A vulnerability is a flaw in the specific implementation of hardware, software, protocols, or system security policies, allowing attackers to access or damage the system without authorization. Therefore, timely discovery and detection of vulnerabilities can protect software or systems from attacks. Two important vulnerability discovery techniques are source code auditing and fuzzing. Source code auditing analyzes and examines the source code of the target system to find incorrectly used function calls, dangerous code, and return states, thereby inferring security issues in the code. Dangerous code refers to officially defined functions that may contain vulnerabilities such as shell execution, deserialization, and buffer overflows. Examples include `exec`, `yaml.load`, and `subprocess.Popen` in Python; `gets`, `strcpy`, and `sprintf` in C; and `eval` and `include` in PHP. When the parameters passed to these functions are user-controllable, vulnerabilities can arise. Additionally, insecure coding practices, such as referencing null pointers, unreleased memory, memory freeing and re-referencing, and array out-of-bounds errors, can also lead to vulnerabilities.

[0003] Fuzzing, on the other hand, requires executing the test code and constructing various types of data to determine whether the code processes the data correctly, in order to discover security issues in the code.

[0004] The essence of fuzzing is to use input to detect whether the execution path corresponding to the current input contains potential vulnerabilities. Therefore, when it's uncertain which path might contain a vulnerability, increasing path coverage to detect more vulnerabilities is a good choice. This is also the fundamental logic of the AFL tool. AFL (American Fuzzy Lop) is an open-source fuzzing testing tool developed by Google security engineer Michal Zalewski. It can efficiently fuzz binary programs to uncover potential memory safety issues, such as buffer overflows and User-Avoidance Defenders (UAF). Besides testing binary files, AFL variants can also test the source code of scripting languages, such as python-afl.

[0005] However, during AFL testing, code instrumentation is used to record detection coverage; input mutation is used to find new execution paths, increasing detection coverage. Therefore, when dealing with complex programs with multiple path branches, a large amount of input data is needed to improve coverage, and it's difficult to achieve 100% coverage of all code branches. This results in AFL being very time-consuming and computationally resource-intensive for testing, with most resources consumed on invalid path branches.

[0006] Therefore, a code testing method is needed to solve the problems existing in the above solutions. Summary of the Invention

[0007] Therefore, the present invention provides a code testing method and a code testing apparatus to solve or at least alleviate the problems mentioned above.

[0008] According to one aspect of the present invention, a code testing method is provided, executed in a computing device, the method comprising: trimming invalid code branches in a source code file to be tested to obtain one or more dangerous code branches; constructing predetermined samples and a sample generation strategy based on the one or more dangerous code branches; generating input samples based on the predetermined samples and the sample generation strategy; and performing fuzz testing on the dangerous code branches based on the input samples.

[0009] Optionally, in the code testing method according to the present invention, the method further includes: inserting probes into the one or more dangerous code branches; performing mutation processing on the input sample; and monitoring whether the mutated input sample can cover the one or more dangerous code branches based on the probes.

[0010] Optionally, in the code testing method according to the present invention, monitoring whether the input sample can cover the one or more dangerous code branches includes: using a feedback-driven algorithm to monitor whether the input sample can cover the one or more dangerous code branches.

[0011] Optionally, in the code testing method according to the present invention, the method further includes: if the input sample cannot cover the one or more dangerous code branches, adjusting the sample generation strategy using a feedback-driven algorithm to obtain a new sample generation strategy; generating a new input sample based on the predetermined sample and the new sample generation strategy; and performing fuzz testing on the dangerous code branches based on the new input sample.

[0012] Optionally, in the code testing method according to the present invention, pruning invalid code branches in the source code file to be tested to obtain one or more dangerous code branches includes: auditing the source code file to be tested to identify one or more dangerous codes; tracing back dangerous code branches based on the dangerous codes, and pruning invalid code branches to obtain one or more dangerous code branches.

[0013] Optionally, in the code testing method according to the present invention, the dangerous code branch is traced back based on the dangerous code, and the invalid code branch is pruned to obtain one or more dangerous code branches, including: parsing the source code file into a syntax tree; locating the node of the dangerous code in the syntax tree according to the name of the dangerous code; tracing back the dangerous code branch based on the parent node attribute of the dangerous code node; setting the invalid code branch in the syntax tree to none to prune the invalid code branch and obtain a pruned syntax tree; restoring the pruned syntax tree to obtain a pruned code file, wherein the pruned code file contains one or more dangerous code branches.

[0014] Optionally, in the code testing method according to the present invention, parsing the source code file into a syntax tree includes: parsing the source code file into an AST syntax tree using an AST package; and adding a parent node attribute to each node in the AST syntax tree.

[0015] Optionally, in the code testing method according to the present invention, auditing the source code file to be tested includes: using an auditing tool to audit the source code file to be tested to identify one or more dangerous codes.

[0016] According to one aspect of the present invention, a code testing apparatus is provided, residing in a computing device, the apparatus comprising: a trimming module adapted to trim invalid code branches in a source code file to be tested to obtain one or more dangerous code branches; a monitoring module adapted to instrument the one or more dangerous code branches to monitor whether an input sample can cover the one or more dangerous code branches; a generation module adapted to construct a predetermined sample and a sample generation strategy based on the one or more dangerous code branches to generate an input sample; and a testing module adapted to perform fuzz testing on the dangerous code branches based on the input sample to detect whether the dangerous code branches have vulnerabilities.

[0017] According to one aspect of the present invention, a computing device is provided, comprising: at least one processor; and a memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the code testing method described above.

[0018] According to one aspect of the present invention, a readable storage medium storing program instructions is provided, which, when read and executed by a computing device, causes the computing device to perform the code testing method described above.

[0019] According to the technical solution of the present invention, a code testing method is provided. This method involves pruning invalid code branches in source code files, retaining only dangerous code branches, and performing fuzzing only on these dangerous code branches. Specifically, predetermined samples and a sample generation strategy are constructed based on the dangerous code branches to generate input samples. Fuzzing is then performed on the dangerous code branches based on these input samples to detect whether they contain vulnerabilities. Furthermore, during the fuzzing process, instrumentation is applied to the dangerous code branches to monitor whether the input samples can cover them. Thus, the present invention only performs fuzzing on dangerous code branches in the source code files, narrowing the scope of fuzzing and improving testing efficiency. Simultaneously, it reduces the number of samples during fuzzing, increasing sample effectiveness and reducing resource consumption.

[0020] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0021] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various ways in which the principles disclosed herein may be practiced, and all aspects and their equivalents are intended to fall within the scope of the claimed subject matter. The foregoing and other objectives, features, and advantages of this disclosure will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings. Throughout this disclosure, the same reference numerals generally refer to the same parts or elements.

[0022] Figure 1 A schematic diagram of a computing device 100 according to an embodiment of the present invention is shown;

[0023] Figure 2 , Figure 3 The flowcharts of a code testing method 200 according to an embodiment of the present invention are shown respectively;

[0024] Figure 4 A schematic diagram illustrating the principle of tracing back dangerous code branches based on dangerous code, according to an embodiment of the present invention, is shown.

[0025] Figure 5A flowchart illustrating the process of tracing back dangerous code branches based on dangerous code, according to an embodiment of the present invention, is shown.

[0026] Figure 6 A schematic diagram of a code testing apparatus 600 according to an embodiment of the present invention is shown. Detailed Implementation

[0027] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0028] Figure 1 A schematic diagram of a computing device 100 according to an embodiment of the present invention is shown. Figure 1 As shown, in a basic configuration, computing device 100 includes at least one processing unit 102 and system memory 104. According to one aspect, depending on the configuration and type of the computing device, the processing unit 102 may be implemented as a processor. System memory 104 includes, but is not limited to, volatile memory (e.g., random access memory), non-volatile memory (e.g., read-only memory), flash memory, or any combination of such memories. According to one aspect, system memory 104 includes an operating system 105.

[0029] According to one aspect, operating system 105 is, for example, suitable for controlling the operation of computing device 100. Furthermore, examples are practiced in conjunction with graphics libraries, other operating systems, or any other applications, and are not limited to any particular application or system. Figure 1 The basic configuration is illustrated by the components within the dashed lines. According to one aspect, the computing device 100 has additional features or functions. For example, according to one aspect, the computing device 100 includes additional data storage devices (removable and / or non-removable), such as disks, optical discs, or magnetic tapes. This additional storage... Figure 1 The image is shown by removable storage device 109 and non-removable storage device 110.

[0030] As stated above, according to one aspect, a program module 103 is stored in system memory 104. According to one aspect, program module 103 may include one or more applications. The invention does not limit the type of application; for example, applications may include: email and contact applications, word processing applications, spreadsheet applications, database applications, slideshow applications, drawing or computer-aided applications, web browser applications, etc. In an embodiment of the invention, the applications in program module 103 may include a code testing device 600, configured to execute the code testing method 200 of the invention.

[0031] According to one aspect, examples can be practiced on circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or a microprocessor. For example, it can be practiced via wherein... Figure 1 Each or many of the components shown can be implemented as an example by integrating a System-on-a-Chip (SOC) on a single integrated circuit. According to one aspect, such an SOC device may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all integrated (or “burned in”) as a single integrated circuit onto a chip substrate. When operating via the SOC, the functions described herein can be operated via dedicated logic integrated on a single integrated circuit (chip) with other components of the computing device 100. Embodiments of the invention can also be implemented using other techniques capable of performing logical operations (e.g., AND, OR, and NOT), including but not limited to mechanical, optical, fluid, and quantum technologies. Additionally, embodiments of the invention can be implemented within a general-purpose computer or in any other circuit or system.

[0032] According to one aspect, computing device 100 may also have one or more input devices 112, such as a keyboard, mouse, pen, voice input device, touch input device, etc. It may also include output devices 114, such as a display, speaker, printer, etc. The foregoing devices are examples and other devices may also be used. Computing device 100 may include one or more communication connections 116 that allow communication with other computing devices 118. Examples of suitable communication connections 116 include, but are not limited to: RF transmitter, receiver and / or transceiver circuitry; Universal Serial Bus (USB), parallel and / or serial ports.

[0033] As used herein, the term computer-readable medium includes computer storage medium. Computer storage medium can include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information (e.g., computer-readable instructions, data structures, or program module 103). System memory 104, removable storage device 109, and non-removable storage device 110 are examples of computer storage media (i.e., memory storage). Computer storage media can include random access memory (RAM), read-only memory (ROM), electrically erasable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and is accessible by computer device 100. According to one aspect, any such computer storage medium can be part of computing device 100. Computer storage media does not include carrier waves or other transmitted data signals.

[0034] According to one aspect, the communication medium is implemented by computer-readable instructions, data structures, program modules 103, or other data in a modulated data signal (e.g., a carrier wave or other transmission mechanism), and includes any information transmission medium. According to one aspect, the term "modulated data signal" describes a signal having one or more sets of characteristics or altered in a manner that encodes information in the signal. By way of example and not limitation, the communication medium includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0035] In an embodiment of the invention, a computing device 100 is configured to execute a code testing method 200 according to the invention. The computing device 100 includes one or more processors and one or more readable storage media storing program instructions that, when configured to be executed by the one or more processors, cause the computing device to execute the code testing method 200 of the embodiment of the invention.

[0036] According to one embodiment of the present invention, the code testing apparatus 600 of the computing device 100 is configured to execute the code testing method 200 according to the present invention. The code testing apparatus 600 includes a plurality of program instructions for executing the code testing method 200 of the present invention, which can instruct a processor to execute the code testing method 200 according to the present invention.

[0037] Figure 2 , Figure 3Flowcharts of a code testing method 200 according to an embodiment of the present invention are shown. Method 200 is adapted to be executed in a code testing apparatus 600 of a computing device (the aforementioned computing device 100).

[0038] like Figure 2 and Figure 3 As shown, method 200 includes steps 210 to 240.

[0039] In step 210, invalid code branches in the source code file to be tested are trimmed to obtain one or more dangerous code branches.

[0040] It should be noted that, according to an embodiment of the present invention, the one or more dangerous code branches obtained in step 210 are the target code branches for which fuzzing testing is required. In other words, the present invention performs fuzzing guided by dangerous code branches.

[0041] Subsequently, one or more dangerous code branches can be instrumented; that is, probes can be inserted into one or more dangerous code branches to monitor whether the input sample can cover one or more dangerous code branches. Here, the input sample is generated in the following steps.

[0042] It should be noted that code instrumentation involves inserting probes into the program under test to obtain information about the program's control flow and data flow, thereby obtaining information such as code coverage, program execution path, variable references and definitions.

[0043] Here, by instrumenting one or more dangerous code branches, probes can be used to record the coverage of the code being tested. Based on the coverage of the test code, it can be determined whether the test code covers one or more dangerous code branches.

[0044] Specifically, in embodiments of the present invention, fuzz testing of dangerous code branches can be performed based on input samples. Correspondingly, by instrumenting one or more dangerous code branches and inserting probes into one or more dangerous code branches, the input samples can be monitored and verified to cover one or more dangerous code branches.

[0045] In an embodiment of the present invention, input samples can be generated through steps 220 to 230.

[0046] Specifically, in step 220, a predetermined sample and a sample generation strategy are constructed based on one or more dangerous code branches.

[0047] In step 230, input samples are generated based on predetermined samples and a sample generation strategy.

[0048] In step 240, the dangerous code branch is fuzzed based on the input sample (as input) to detect whether the dangerous code branch has a vulnerability.

[0049] Specifically, by executing the trimmed code file (i.e., executing one or more dangerous code branches), the system detects whether each dangerous code branch handles the input sample data abnormally (whether it triggers a program crash). If a dangerous code branch handles the input sample abnormally, it will trigger a program crash, thus identifying the dangerous code branch as vulnerable. Here, during the fuzzing process of dangerous code branches, if a dangerous code branch handles the input sample abnormally and triggers a program crash, the abnormal dangerous code branch that triggered the crash can be recorded; that is, the vulnerable dangerous code branch is recorded.

[0050] In one implementation, a fuzzer can be used to generate input samples based on predefined samples and a sample generation strategy, and then fuzz tests can be performed on dangerous code branches based on the input samples.

[0051] It should be noted that, according to the embodiments of the present invention, fuzzing only needs to be performed on one or more valid dangerous code branches in the source code file, which helps to reduce the number of invalid samples in the fuzzing process, improve testing efficiency, and reduce resource consumption.

[0052] According to one embodiment of the present invention, before fuzzing dangerous code branches based on input samples, the input samples can be pre-mutated to ensure that the input samples are valid and conform to the input format. Subsequently, probes inserted into one or more dangerous code branches can be used to monitor and verify whether the mutated input samples can cover one or more dangerous code branches. Furthermore, fuzzing is performed on the dangerous code branches based on the mutated input samples, and during the fuzzing process, abnormal dangerous code branches that trigger program crashes are recorded.

[0053] In one embodiment, during fuzzing of dangerous code branches, a feedback-driven algorithm can be used to monitor whether the input sample (the mutated input sample) covers one or more dangerous code branches.

[0054] In addition, if it is determined that the input sample (the mutated input sample) cannot cover one or more dangerous code branches, a feedback-driven algorithm can be used to modify and adjust the sample generation strategy to obtain a new sample generation strategy.

[0055] Subsequently, the fuzz tester can generate new input samples based on predefined samples and new sample generation strategies, and perform fuzz testing on dangerous code branches based on the new input samples to detect whether dangerous code branches have vulnerabilities.

[0056] Specifically, after generating new input samples, these samples can be mutated. Then, fuzz testing can be performed on the dangerous code branches based on the mutated new input samples. Subsequently, based on the instrumentation of one or more dangerous code branches, probes can be used to monitor and verify whether the mutated new input samples can cover one or more dangerous code branches. Furthermore, fuzz testing is performed on the dangerous code branches based on the mutated new input samples.

[0057] In one embodiment, in step 210, automated auditing (analysis and detection) of the source code file to be tested can be performed to match and identify one or more dangerous codes and their locations within the source code file, thereby determining one or more dangerous codes in the source code file. Here, in one implementation, the entry function of the source code file to be tested is `main`, and an auditing tool can be used to audit the source code file to be tested to identify one or more dangerous codes. The auditing tool can be implemented as, for example, `bandit`, but the present invention is not limited thereto.

[0058] Furthermore, by tracing back the dangerous code branches based on the dangerous code and pruning the invalid code branches, one or more dangerous code branches can be obtained.

[0059] like Figure 3 As shown, the source code file originally contained 3 code branches. By pruning 2 invalid code branches (branch 1 and branch 3), only one dangerous code branch (branch 2) remains. In this way, only one dangerous code branch needs to be fuzzed.

[0060] Figure 4 A schematic diagram illustrating the principle of backtracking dangerous code branches based on a dangerous code according to an embodiment of the present invention is shown. Figure 4 As shown, after identifying dangerous code by auditing the source code file, a step-by-step backtracking can be performed based on the syntax tree of the source code file. The backtracking is divided into two aspects: one is to backtrack the call chain of objects such as functions and classes; the other is to backtrack the passing of parameters, including direct assignment, property assignment, string concatenation, function processing, string truncation and other operations.

[0061] Figure 5 A schematic diagram of a process for backtracking dangerous code branches based on dangerous codes according to an embodiment of the present invention is shown.

[0062] like Figure 5 As shown, the following methods can be used to backtrack dangerous code branches and prune invalid code branches:

[0063] First, the source code file can be parsed into a syntax tree. In one implementation, an AST package can be used to parse the source code file into an AST syntax tree and add parent node attributes to each node in the AST syntax tree.

[0064] Then, based on the name of each dangerous code, the node of the dangerous code is located in the syntax tree.

[0065] Next, the dangerous code branch is traced back layer by layer based on the parent node attributes of the dangerous code node. Here, the result of locating the dangerous code node in the syntax tree can be a list of nodes containing one or more dangerous code nodes.

[0066] Next, the syntax tree is rewritten. This is achieved by setting invalid code branches in the syntax tree to none, thus pruning invalid code branches and obtaining a pruned syntax tree.

[0067] Finally, the trimmed syntax tree is restored to obtain the trimmed code file. This trimmed code file contains one or more dangerous code branches, thus resulting in one or more dangerous code branches. It can be understood that in the trimmed code file, only dangerous code branches and dangerous functions are retained; invalid code branches have been trimmed.

[0068] For example, in one application instance, taking the dangerous code in Phthon as an example, the Phthon source code file to be tested contains dangerous code branches main and open, and includes an invalid code branch func1.

[0069] The following are the results of auditing source code files using the Bandit auditing tool and identifying dangerous code:

[0070]

[0071]

[0072] As can be seen, the dangerous code identified in the source code file is subprocess.Popen, which belongs to the function open(), and the potential vulnerability is a shell execution vulnerability.

[0073] Furthermore, backtracking down dangerous code branches based on dangerous code can be achieved through the following methods:

[0074] The source code file is parsed into an AST syntax tree using the AST package, inheriting from the native ast.NodeTransformer class, and a parent node property is added to each node in the AST syntax tree. Partial code is shown below:

[0075]

[0076] Then, based on the name of the dangerous code, the node containing the dangerous code is located in the syntax tree. The location result can be a list containing .ast nodes.

[0077] Next, based on the parent node attributes of each dangerous code node, the dangerous code branches are traced back layer by layer until the main or interface function is reached.

[0078] Next, the syntax tree is rewritten. Invalid code branch nodes are set to none to prune invalid code branches, resulting in a pruned syntax tree. Partial code is shown below: class NodeWrapper(ast.NodeTransformer):

[0079] #Keep dangerous branches found during backtracking, and prune invalid branches, setting them to None; parent_list contains dangerous code branches.

[0080]

[0081] Finally, you can use `astunparse.Unparser` to restore the clipped syntax tree to the clipped code file. See the code below for details:

[0082]

[0083] As can be seen, in the trimmed code file, the invalid code branch `func1` was removed, while dangerous functions and dangerous code branches were retained. Compared to the source code file, the trimmed code has significantly fewer branches, thus narrowing the scope for fuzz testing.

[0084] Based on the code audit results, it can be seen that the sample code may contain a shell execution vulnerability. Therefore, the initial parameters set before fuzzing are also for the shell execution vulnerability. For the convenience of exception capture (usually exception capture is program crash capture, time exception capture, command execution result capture), the initial parameters can be set to (name='sleep',url='1',sig=0).

[0085] During fuzzing of dangerous code branches, based on the feedback-driven algorithm of honggfuzz, the values ​​of three parameters are continuously adjusted to achieve the maximum dangerous code branch coverage. `url` and `sig` are randomly generated from initial values. When the value of `sig` is greater than 2, the target dangerous code is entered, triggering a new branch. At this point, `sig` is recorded, and subsequent samples are mutated based on this to achieve the maximum dangerous code branch coverage. For example, if `sig = 2.5` when a new branch is triggered, the next `sig` will mutate to `sig ± 0.01`. By making minimal changes to the samples, dangerous code branch coverage is achieved while ensuring that two input samples are different. When the `url` value exceeds the threshold for time anomaly detection, it is captured as an abnormal state and recorded as the fuzzing result, for example (`name = 'sleep', url = '20', sig = 4.2`).

[0086] Compared with traditional fuzz testing methods, the improved method does not need to consider all random data such as name=*, url=*, and sig<=2 during the testing process, which increases the effectiveness of the samples and improves the detection efficiency.

[0087] Figure 6 A schematic diagram of a code testing apparatus 600 according to an embodiment of the present invention is shown. The code testing apparatus 600 resides in a computing device (e.g., the aforementioned computing device 100). The code testing apparatus 600 is adapted to perform the code testing method 200 of the present invention.

[0088] like Figure 6 As shown, the code testing device 600 includes a trimming module 610, a building module 620, a generation module 630, and a testing module 640 connected in sequence.

[0089] The trimming module 610 is adapted to trim invalid code branches in the source code file to be tested, obtaining one or more dangerous code branches. The building module 620 is adapted to build a predetermined sample and a sample generation strategy based on one or more dangerous code branches. The generation module 630 is adapted to generate input samples based on the predetermined sample and the sample generation strategy. The testing module 640 is adapted to perform fuzz testing on the dangerous code branches based on the input samples to detect whether the dangerous code branches have vulnerabilities.

[0090] It should be noted that the trimming module 610 is used to execute the aforementioned step 210, the building module 620 is used to execute the aforementioned step 220, the generating module 630 is used to execute the aforementioned step 230, and the testing module 640 is used to execute the aforementioned step 240. Here, the specific execution logic of the trimming module 610, the building module 620, the generating module 630, and the testing module 640 are described in the preceding method 200 for steps 210 to 240, and will not be repeated here.

[0091] According to the code testing method of the present invention, invalid code branches in the source code file are pruned, retaining only dangerous code branches. Fuzzing is then performed only on these dangerous code branches. Specifically, predetermined samples and a sample generation strategy are constructed based on the dangerous code branches to generate input samples. Fuzzing is then performed on the dangerous code branches based on these input samples to detect whether they contain vulnerabilities. Furthermore, during the fuzzing process, instrumentation is applied to the dangerous code branches to monitor whether the input samples cover them. Thus, the present invention only performs fuzzing on dangerous code branches in the source code file, narrowing the scope of fuzzing and improving testing efficiency. Simultaneously, it reduces the number of samples during fuzzing, increasing sample effectiveness and reducing resource consumption.

[0092] The various techniques described herein can be implemented in combination with hardware or software, or a combination thereof. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embedded in a tangible medium, such as a removable hard disk, USB flash drive, floppy disk, CD-ROM, or any other machine-readable storage medium, wherein when the program is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for practicing the present invention.

[0093] When the program code is executed on a programmable computer, the mobile terminal generally includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. The memory is configured to store program code; the processor is configured to execute the code testing method of the present invention according to instructions in the program code stored in the memory.

[0094] By way of example, and not limitation, readable media include readable storage media and communication media. Readable storage media stores information such as computer-readable instructions, data structures, program module 103, or other data. Communication media generally embodies computer-readable instructions, data structures, program module 103, or other data in the form of modulated data signals such as a carrier wave or other transmission mechanism, and includes any information transmission medium. Any combination of the above is also included within the scope of readable media.

[0095] In the specification provided herein, the algorithms and displays are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used with the examples of this invention. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0096] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0097] Similarly, it should be understood that, in order to streamline this disclosure and aid in understanding one or more aspects of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this method of disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0098] Those skilled in the art will understand that modules, units, or components of the devices disclosed in the examples herein can be arranged in the devices described in this embodiment, or alternatively, can be located in one or more devices different from the devices in this example. The modules in the foregoing examples can be combined into a single module or, in addition, can be divided into multiple sub-modules.

[0099] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0100] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0101] Furthermore, some of the embodiments described herein are methods or combinations of method elements that can be implemented by a processor of a computer system or by other means of performing the functions. Therefore, a processor having the necessary instructions for implementing the methods or method elements forms means for implementing the methods or method elements. Furthermore, the elements described herein in the apparatus embodiments are examples of means for implementing the functions performed by elements for the purposes of carrying out the invention.

[0102] As used herein, unless otherwise specified, the use of ordinal numbers such as “first,” “second,” “third,” etc., to describe ordinary objects merely indicates different instances of similar objects and is not intended to imply that the objects being described must have a given order in time, space, ordering, or any other manner.

[0103] Although the invention has been described with respect to a limited number of embodiments, those skilled in the art will understand from the foregoing description that other embodiments are conceivable within the scope of the invention described herein. Furthermore, it should be noted that the language used in this specification has been chosen primarily for readability and edibility purposes, and not for the purpose of interpreting or limiting the subject matter of the invention. Therefore, many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the appended claims. The disclosure of the invention is illustrative rather than restrictive, and the scope of the invention is defined by the appended claims.

Claims

1. A code testing method, executed in a computing device, the method comprising: The invalid code branches in the source code file to be tested are trimmed to obtain one or more dangerous code branches; Based on the one or more dangerous code branches, construct predetermined samples and sample generation strategies; Based on the predetermined sample and sample generation strategy, an input sample is generated, and the input sample is subjected to mutation processing. By inserting probes into the one or more dangerous code branches, it is possible to monitor whether the mutated input sample can cover the one or more dangerous code branches; If the mutated input sample can cover the one or more dangerous code branches, then fuzz testing is performed on the dangerous code branches based on the mutated input sample, including: detecting whether the dangerous code branch processes the input sample data abnormally, so as to determine whether the dangerous code branch has a vulnerability; If the mutated input sample cannot cover the one or more dangerous code branches, the sample generation strategy is adjusted using a feedback-driven algorithm to obtain a new sample generation strategy. Based on the predetermined sample and the new sample generation strategy, a new input sample is generated, and the new input sample is mutated so that the dangerous code branch can be fuzz tested based on the mutated new input sample.

2. The method as described in claim 1, wherein, Monitoring whether the mutated input sample can cover one or more dangerous code branches includes: Using a feedback-driven algorithm, monitor whether the mutated input sample can cover one or more dangerous code branches.

3. The method as described in claim 1, wherein, Invalid code branches in the source code file to be tested are pruned to obtain one or more dangerous code branches, including: Audit the source code files to be tested to identify one or more dangerous pieces of code; Based on the dangerous code, trace back the dangerous code branch and prune the invalid code branch to obtain one or more dangerous code branches.

4. The method of claim 3, wherein, Based on the aforementioned dangerous code, trace back the dangerous code branches and prune invalid code branches to obtain one or more dangerous code branches, including: The source code file is parsed into a syntax tree; Based on the name of the dangerous code, locate the node of the dangerous code in the syntax tree; Backtrack the dangerous code branch based on the parent node attribute of the node with the dangerous code; Set the invalid code branches in the syntax tree to none in order to prune the invalid code branches and obtain the pruned syntax tree; The trimmed syntax tree is restored to obtain a trimmed code file, which contains one or more dangerous code branches.

5. The method of claim 4, wherein, Parsing the source code file into a syntax tree includes: The source code file was parsed into an AST syntax tree using the AST package; Add a parent node attribute to each node in the AST syntax tree.

6. A code testing apparatus residing in a computing device, adapted to perform the method as described in any one of claims 1-5, the apparatus comprising: The trimming module is suitable for trimming invalid code branches in the source code file to be tested, resulting in one or more dangerous code branches; The building module is adapted to build a predetermined sample and a sample generation strategy based on the one or more dangerous code branches; The generation module is adapted to generate input samples based on the predetermined samples and the sample generation strategy; The testing module is adapted to perform fuzz testing on dangerous code branches based on the input samples.

7. A computing device, comprising: At least one processor; as well as A memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, the program instructions including instructions for performing the method as described in any one of claims 1-5.

8. A readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the method as described in any one of claims 1-5.

Images