Method and apparatus for reproducing input data that triggers software vulnerability, and device and medium

Abstract

Provided in the present application are a method and apparatus for reproducing input data that triggers a software vulnerability, and a device and a medium. The method comprises: identifying a plurality of old-version functions and a plurality of new-version functions respectively comprised in an old-version binary program and a new-version binary program, which respectively correspond to target software before and after vulnerability patching, and an old-version static function call relationship and a new-version static function call relationship, which respectively correspond to the old-version binary program and new-version binary program; acquiring an old-version real function call sequence and a new-version real function call sequence, which respectively correspond to the old-version binary program and the new-version binary program during running; matching the plurality of old-version functions with the plurality of new-version functions to obtain a plurality of matching function pairs; determining candidate patch functions from among the plurality of matching function pairs; and according to the candidate patch functions and a second preset test case pool, performing fuzz testing on the old-version binary program and the new-version binary program, so as to determine target input data that can trigger a vulnerability of the old-version binary program. The method in the present application can efficiently reproduce target input data that can trigger a vulnerability of an old-version binary program.

Description

Method, device, equipment and medium for reproducing input data that triggers software vulnerabilities

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on June 28, 2023, with application number 202310781248.5 and application name “Method, device, equipment and medium for reproducing input data that triggers software vulnerabilities”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to network security technology, and more specifically, to a method, apparatus, device, and medium for reproducing input data that triggers software vulnerabilities. Background Art

[0003] Software vulnerabilities are a serious threat to the computer industry, impacting end users, industry entities, and even national security. Therefore, discovering and promptly patching software vulnerabilities and proactively protecting against attack signatures are crucial. In addition to undiscovered vulnerabilities in software, vulnerabilities for which vendors have already released patches can also pose security threats. This is because attackers can analyze and locate vulnerabilities by comparing pre- and post-patched software, while users may not apply patches immediately after release.

[0004] Currently, to protect user software from threats, attack detection systems can be deployed within the network systems that host the software. These systems can identify attack traffic by detecting signature attack byte sequences within network traffic, allowing attacks to be intercepted in advance. Effectively detecting attack traffic requires obtaining input data that triggers the vulnerabilities targeted by the patches. For software patched via incremental updates, the patches released by the software vendor can be directly analyzed to reproduce input data that triggers the patched vulnerabilities. However, for software patched via full updates, it is currently impossible to effectively reproduce input data that triggers the patched vulnerabilities.

[0005] Summary of the Invention

[0006] The present application provides a method, apparatus, device and medium for reproducing input data that triggers software vulnerabilities, which is used to solve the problem in the prior art that software that fixes vulnerabilities through full updates cannot efficiently reproduce the input data that can trigger the repaired vulnerabilities.

[0007] In a first aspect, the present application discloses a method for reproducing input data that triggers a software vulnerability, comprising:

[0008] Obtaining a plurality of old version functions and old version static function call relationships included in an old version binary program of the target software before the vulnerability is patched, and obtaining a plurality of new version functions and new version static function call relationships included in a new version binary program of the target software after the vulnerability is patched;

[0009] Obtaining an old version of a real function call sequence of the old version of the binary program during the process of running a first test case, and obtaining a new version of a real function call sequence of the new version of the binary program during the process of running a first test case; the first test case belongs to a first preset test case pool;

[0010] Determine the currently restored function call relationship of the old version based on the old version static function call relationship and the old version real function call series, and determine the currently restored function call relationship of the new version based on the new version static function call relationship and the new version real function call sequence;

[0011] According to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version, a plurality of old version functions are matched with a plurality of new version functions to obtain a plurality of matching function pairs; the matching function pairs include the old version function and the new version function that match each other;

[0012] Determining at least one candidate patch function from a plurality of matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version;

[0013] According to each candidate patch function and the second preset test case pool, fuzz testing is performed on the old version binary program and the new version binary program to determine target input data that can trigger the vulnerability of the old version binary program.

[0014] In a second aspect, the present application discloses a device for reproducing input data that triggers a software vulnerability, comprising:

[0015] A first acquisition module is used to obtain a plurality of old version functions and old version static function call relationships included in an old version binary program of the target software before the vulnerability is patched, and to obtain a plurality of new version functions and new version static function call relationships included in a new version binary program of the target software after the vulnerability is patched;

[0016] a second acquisition module, configured to acquire an old version of a real function call sequence of the old version of the binary program during execution of a first test case, and to acquire a new version of a real function call sequence of the new version of the binary program during execution of the first test case; the first test case belonging to a first preset test case pool;

[0017] A first determining module is configured to determine the currently restored function call relationship of the old version based on the static function call relationship of the old version and the real function call series of the old version, and to determine the currently restored function call relationship of the new version based on the static function call relationship of the new version and the real function call sequence of the new version;

[0018] a matching module, configured to match a plurality of old version functions with a plurality of new version functions according to the calling relationship of the old version currently restored function and the calling relationship of the new version currently restored function, to obtain a plurality of matching function pairs; the matching function pairs include old version functions and new version functions that match each other;

[0019] A second determining module is configured to determine at least one candidate patch function from a plurality of matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version;

[0020] The third determination module performs fuzz testing on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool, and determines target input data that can trigger the vulnerability of the old version binary program.

[0021] In a third aspect, the present application discloses an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0022] The memory stores computer-executable instructions;

[0023] The processor executes the computer-executable instructions stored in the memory to implement the method as described in the first aspect.

[0024] In a fourth aspect, the present application discloses a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method described in the first aspect.

[0025] In a fifth aspect, the present application discloses a computer program product, comprising a computer program, which implements the method described in the first aspect when executed by a processor.

[0026] In combination with the above technical solution, the present application obtains the calling relationships of multiple old version functions and old version static functions included in the old version binary program of the target software before patching the vulnerability, and obtains the calling relationships of multiple new version functions and new version static functions included in the new version binary program of the target software after patching the vulnerability; obtains the old version real function calling sequence of the old version binary program in the process of running the first test case, and obtains the new version real function calling sequence of the new version binary program in the process of running the first test case; the first test case belongs to the first preset test case pool; according to the old version static function calling relationship and the old version real function calling series, it is determined that the old version currently has restored function calling relationship, and according to the new version static function calling The relationship and the new version's real function call sequence are used to determine the new version's currently restored function call relationship; based on the old version's currently restored function call relationship and the new version's currently restored function call relationship, multiple old version functions are matched with multiple new version functions to obtain multiple matching function pairs; the matching function pairs include mutually matching old version functions and new version functions; based on the old version's currently restored function call relationship and the new version's currently restored function call relationship, at least one candidate patch function is determined from the multiple matched old version functions; based on each candidate patch function and a second preset test case pool, the old version binary program and the new version binary program are fuzz tested to determine target input data that can trigger vulnerabilities in the old version binary program. Since the old version's currently restored function call relationship can reflect the internal structure and characteristics of the old version binary program, the new version's currently restored function call relationship can reflect the internal structure and characteristics of the new version binary program. Therefore, based on the old version's currently restored function call relationship and the new version's currently restored function call relationship, multiple old version functions can be matched with multiple new version functions to obtain multiple matching function pairs. Furthermore, based on the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version, the candidate patch function that may have caused the vulnerability of the old version binary program can be determined from the matched old version functions of the matching function pair, and then the old version binary program and the new version binary program are fuzz tested based on the candidate patch function and the preset second test case pool, so that the old version binary program is more inclined to execute the candidate patch function during the fuzz testing process, which can increase the probability of reproducing the target input data that can trigger the vulnerability of the old version binary program in the fuzz testing, and more efficiently reproduce the input data that can trigger the repaired vulnerability. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] FIG1 is a network architecture diagram corresponding to an application scenario of a method for reproducing input data that triggers a software vulnerability provided by an embodiment of the present application;

[0028] FIG2 is a flow chart of a method for reproducing input data that triggers a software vulnerability according to the first embodiment of the present application;

[0029] FIG3 is a schematic diagram of a call relationship of a currently restored function of an old version provided according to a fourth embodiment of the present application;

[0030] FIG4 is a flow chart of a method for reproducing input data that triggers a software vulnerability according to a sixth embodiment of the present application;

[0031] FIG5 is a flow chart of fuzzy testing in a method for reproducing input data that triggers a software vulnerability according to a sixth embodiment of the present application;

[0032] FIG6 is a schematic diagram of the structure of a device for reproducing input data that triggers a software vulnerability according to a seventh embodiment of the present application;

[0033] FIG7 is a schematic structural diagram of an electronic device provided according to Embodiment 8 of the present application. DETAILED DESCRIPTION

[0034] The terms "first", "second", "third", "fourth", "fifth", etc. in the description, claims and drawings of the embodiments of the present application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices. Furthermore, as used in this article, the singular forms "a", "an" and "the" are intended to also include plural forms. The terms "or", "and / or", "including at least one of the following" and the like can be interpreted as inclusive, or mean any one or any combination. For example, “comprising at least one of the following: A, B, C” means “any of the following: A; B; C; A and B; A and C; B and C; A and B and C”; and for another example, “A, B or C” or “A, B and / or C” means “any of the following: A; B; C; A and B; A and C; B and C; A and B and C”. An exception to this definition will occur only when a combination of elements, functions, steps or operations are inherently mutually exclusive in some manner.

[0035] The following is a detailed description and analysis of the prior art involved in this application.

[0036] Software vulnerabilities pose a serious threat to the computer industry, impacting end users, industry entities, and network security. Therefore, discovering and remediating software vulnerabilities promptly, as well as proactively protecting against attack signatures, is crucial. However, in addition to undiscovered vulnerabilities in software, already discovered and patched vulnerabilities can also pose a security threat. This is because users may not immediately apply patches after they are released by software vendors, while attackers can analyze and locate vulnerabilities by comparing pre- and post-patched software. Therefore, if users do not immediately install the patches and continue to use unpatched software, reproducing the input data that triggers the vulnerability can enable the deployment of attack detection systems within the network systems hosting the user software. By detecting attack signature byte sequences in network traffic, attack traffic can be identified, preemptively intercepted, and the end-user's network security protected.

[0037] Since software vendors don't release specific information about the patched vulnerabilities after they've been patched, analyzing the patches released by the software vendors for vulnerabilities patched via incremental updates can potentially reproduce input data that triggers the patched vulnerabilities. However, for software patched via full updates, due to the large amount of code, analyzing the vulnerabilities and reproducing input data that triggers the patched vulnerabilities by comparing the differences between the software before and after the patch is inefficient, making it impossible to effectively reproduce input data that triggers the patched vulnerabilities.

[0038] Software fuzz testing is a mainstream method for discovering software vulnerabilities. Fuzz testing constructs large amounts of random data as input to the software under test and monitors the software for operational anomalies, such as crashes, after the random data is input. However, most fuzz testing solutions do not consider the internal structure and characteristics of the software under test, and only observe its output and abnormal operating conditions, making vulnerability discovery inefficient.

[0039] In summary, in the prior art, for software that patches vulnerabilities through a full update, there is a problem of being unable to efficiently reproduce the input data that can trigger the patched vulnerability.

[0040] When faced with the problems in the existing technology, the inventors, through creative research, found that in order to efficiently reproduce the input data that can trigger software vulnerabilities, it is necessary to consider the internal structure of the software, and the function call relationship of the binary program can reflect the internal structure of the target software. At the same time, patching software vulnerabilities often changes the function call relationship in the binary program. Therefore, the function call relationship between the old version of the binary program and the new version of the binary program can be restored, and the function call relationship can be combined with fuzz testing to more accurately and efficiently reproduce the input data that can trigger the repaired vulnerability.

[0041] Therefore, the inventor proposed the technical solution of the present application, which is to obtain the multiple old version functions and old version static function call relationships included in the old version binary program of the target software before the vulnerability is patched, and obtain the multiple new version functions and new version static function call relationships included in the new version binary program of the target software after the vulnerability is patched; obtain the old version real function call sequence of the old version binary program in the process of running the first test case, and obtain the new version real function call sequence of the new version binary program in the process of running the first test case; the first test case belongs to the first preset test case pool; according to the old version static function call relationship and the old version real function call series, determine that the old version currently has restored function call relationship, and according to the new version static function call relationship The function call relationship and the new version's actual function call sequence are used to determine the new version's currently restored function call relationship; based on the old version's currently restored function call relationship and the new version's currently restored function call relationship, multiple old version functions are matched with multiple new version functions to obtain multiple matching function pairs; the matching function pairs include mutually matching old version functions and new version functions; based on the old version's currently restored function call relationship and the new version's currently restored function call relationship, at least one candidate patch function is determined from the multiple matched old version functions; based on each candidate patch function and a second preset test case pool, the old version binary program and the new version binary program are fuzz tested to determine target input data that can trigger vulnerabilities in the old version binary program. Since the old version's currently restored function call relationship can reflect the internal structure and characteristics of the old version binary program, the new version's currently restored function call relationship can also reflect the internal structure and characteristics of the new version binary program. Therefore, based on the old version's currently restored function call relationship and the new version's currently restored function call relationship, multiple old version functions can be matched with multiple new version functions to obtain multiple matching function pairs. Furthermore, based on the calling relationship of the currently restored functions of the old version and the calling relationship of the currently restored functions of the new version, the candidate patch function that may have caused the vulnerability of the old version binary program can be determined from the matched old version functions of the matching function pair, and then the old version binary program and the new version binary program are fuzz tested based on the candidate patch function and the preset second test case pool, so that the old version binary program is more inclined to execute the candidate patch function during the fuzz testing process, which can increase the probability of reproducing the target input data that can trigger the vulnerability of the old version binary program in the fuzz testing, and more efficiently reproduce the input data that can trigger the repaired vulnerability.

[0042] The method, device, equipment, and medium for reproducing input data that triggers software vulnerabilities provided by this application are intended to solve the above technical problems of the prior art. The technical solution of this application and how the technical solution of this application solves the above technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0043] The following will introduce the network architecture and application scenarios of the method for reproducing input data that triggers software vulnerabilities provided by the embodiment of the present application. When the following description refers to the drawings, unless otherwise indicated, the same data in different drawings represent the same or similar elements.

[0044] Figure 1 is a diagram of the network architecture corresponding to an application scenario of the method for reproducing input data that triggers a software vulnerability provided by an embodiment of the present application. As shown in Figure 1, the network architecture corresponding to an application scenario provided by an embodiment of the present application includes: an electronic device 10, a user terminal 11, a cloud server 12, and an attack device 13.

[0045] The user terminal 11 is in communication with the cloud server 12, and the cloud server 12 provides computing, storage and other services for the user terminal 11. The target software before the vulnerability is patched is installed on the user terminal 11.

[0046] The electronic device 10 obtains multiple old version functions and old version static function call relationships included in the old version binary program of the target software before the vulnerability is patched, and obtains multiple new version functions and new version static function call relationships included in the new version binary program of the target software after the vulnerability is patched.

[0047] The electronic device 10 obtains the old version real function call sequence of the old version binary program during the process of running the first test case, and obtains the new version real function call sequence of the new version binary program during the process of running the first test case; the first test case belongs to the first preset test case pool.

[0048] The electronic device 10 determines the currently restored function call relationship of the old version based on the old version static function call relationship and the old version real function call series, and determines the currently restored function call relationship of the new version based on the new version static function call relationship and the new version real function call sequence.

[0049] The electronic device 10 matches multiple old version functions with multiple new version functions according to the old version currently restored function call relationship and the new version currently restored function call relationship to obtain multiple matching function pairs; the matching function pairs include old version functions and new version functions that match each other.

[0050] The electronic device 10 determines at least one candidate patch function from a plurality of matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version.

[0051] The electronic device 10 performs fuzz testing on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool, and determines target input data that can trigger the vulnerability of the old version binary program.

[0052] The electronic device 10 sends the target input data that can trigger the vulnerability of the old version of the binary program to the cloud server 12. When the cloud server 12 is providing services to the user terminal 11, if the attack device 13 attacks the user terminal 11 through the vulnerability of the old version of the binary program, the attack data will have the same characteristic byte sequence as the target input data. Therefore, the cloud server 12 detects network traffic based on the characteristic byte sequence of the target input data, and when it detects attack data with the same characteristic byte sequence as the target input data, it intercepts the attack data, thereby ensuring the network security of the user terminal.

[0053] The following embodiments of the present application will be described in conjunction with the accompanying drawings. The embodiments described in the following embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with certain aspects of the present application as detailed in the appended claims.

[0054] Example 1

[0055] FIG2 is a flow chart of a method for reproducing input data that triggers a software vulnerability according to a first embodiment of the present application. As shown in FIG2 , the execution subject of the present application is a device for reproducing input data that triggers a software vulnerability, and the device for reproducing input data that triggers a software vulnerability is located in an electronic device. The method for reproducing input data that triggers a software vulnerability provided in this embodiment includes steps 201 to 206.

[0056] Step 201: Obtain multiple old version functions and old version static function call relationships included in the old version binary program of the target software before patching the vulnerability, and obtain multiple new version functions and new version static function call relationships included in the new version binary program of the target software after patching the vulnerability.

[0057] Optionally, in step 201, "obtaining the calling relationships between multiple old version functions and old version static functions included in the old version binary program of the target software before patching the vulnerability" is further refined to include step 201a, and "obtaining the calling relationships between multiple new version functions and new version static functions included in the new version binary program of the target software after patching the vulnerability" is further refined to include step 201b.

[0058] Step 201a, using a static disassembler to identify the old version binary program, and obtaining a plurality of old version functions and old version static function call relationships;

[0059] In step 201b, a static disassembler is used to identify the new version binary program, and a plurality of new version functions and new version static function calling relationships are obtained.

[0060] In this embodiment, the electronic device can use a static disassembler to disassemble an old version of the target software binary program before the vulnerability is patched, and a new version of the target software binary program after the vulnerability is patched, respectively, to obtain an old version of the assembly program corresponding to the old version of the binary program, and a new version of the assembly program corresponding to the new version of the binary program. The static disassembler can be pre-configured in the electronic device.

[0061] Furthermore, the electronic device can use a static disassembler to identify the old and new versions of the assembler, obtaining multiple old functions included in the old binary program, the old static function call relationships included in the old binary program, multiple new functions included in the new binary program, and the new static function call relationships included in the new binary program. The terms "new version" and "old version" are used to facilitate the distinction and description of the target software's binary program, assembler, function call relationships, etc. before and after the vulnerability is patched, and should not be construed as limiting the technical solution of this application.

[0062] In this embodiment, the static function call relationship can be a static function call relationship graph, or other data format that can reflect the function call relationship in the program. The static function call relationship graph includes nodes and directed edges, and the nodes are connected by directed edges. The nodes are used to represent functions included in the program, and the directed edges are used to represent the static call relationship between functions. The static call relationship is a function call relationship that can be directly identified from the assembly program, and generally includes a direct call relationship between functions.

[0063] Step 202: Obtain the old version real function call sequence of the old version binary program during the process of running the first test case, and obtain the new version real function call sequence of the new version binary program during the process of running the first test case; the first test case belongs to the first preset test case pool.

[0064] In this embodiment, the actual function call sequence refers to the functions actually called during the binary program's execution, as well as the order in which the functions are actually called. The electronic device can select a first preset test case from a first preset test case pool and input the first preset test case into both the old version binary program and the new version binary program for execution. The actual function call sequence of the old version of the binary program during execution of the first test case, as well as the actual function call sequence of the new version of the binary program during execution of the first test case, are recorded.

[0065] Specifically, the electronic device can obtain the old version of the real function calling sequence and the new version of the real function calling sequence through a preset dynamic instrumentation tool.

[0066] Step 203: Determine the currently restored function call relationship of the old version based on the old version static function call relationship and the old version real function call series, and determine the currently restored function call relationship of the new version based on the new version static function call relationship and the new version real function call series.

[0067] In this embodiment, since the static disassembler may make errors in the process of converting the binary program into the assembly program, and indirect function calls cannot be identified from the assembly language, the function calls included in the static function call relationship may have errors and omissions, and may not necessarily accurately and completely include all function calls in the binary program. The real function call sequence can reflect the function calls during the program execution process, and the real function call sequence includes indirect function calls. Therefore, the electronic device can determine the current restored function call relationship of the old version by combining the old version static function call relationship and the old version real function call sequence, and determine the current restored function call relationship of the new version by combining the new version static function call relationship and the new version real function call sequence.

[0068] Optionally, in step 203, "determine the currently restored function call relationship of the old version based on the static function call relationship of the old version and the real function call series of the old version" is refined to include step 203a, and "determine the currently restored function call relationship of the new version based on the static function call relationship of the new version and the real function call sequence of the new version" is refined to include step 203b.

[0069] Step 203a: Use the real function calling relationship existing in the old version's real function calling sequence to supplement the old version's static function calling relationship to obtain the old version's currently restored function calling relationship.

[0070] Step 203b: Use the real function call relationship existing in the new version real function call sequence to supplement the new version static function call relationship to obtain the new version currently restored function call relationship.

[0071] In this embodiment, since the function calls included in the static function call relationship may have errors and omissions, and the function call relationship included in the real function call sequence must have actually occurred during the program running process, although the binary program will only execute one program path in the process of running a test case, the function call relationship included in the real function call sequence may not be complete, it is still possible to obtain a more complete current restored function call relationship of the program relative to the static function call relationship and the real function call sequence based on the static function call relationship and the real function call sequence.

[0072] Specifically, for an old version of a binary program, the real function call relationship in the old version's real function call sequence can be used to supplement the old version's static function call relationship to obtain the old version's currently restored function call relationship. For a new version of a binary program, the real function call relationship in the new version's real function call sequence can be used to supplement the new version's static function call relationship to obtain the new version's currently restored function call relationship.

[0073] Optionally, for an old version of a binary program, the real function call relationships present in the old version's real function call sequence can be used to correct the erroneous function call relationships in the old version's static function call relationships, and the old version's static function call relationships can be supplemented to obtain the currently restored function call relationships of the old version. For a new version of a binary program, the real function call relationships present in the new version's real function call sequence can be used to correct the erroneous function call relationships in the new version's static function call relationships, and the new version's static function call relationships can be supplemented to obtain the currently restored function call relationships of the new version.

[0074] The method for reproducing input data that triggers a software vulnerability provided in this embodiment supplements the static function call relationship by using the real function call relationship existing in the real function call sequence. Therefore, a more complete current restored function call relationship can be obtained, which is beneficial to the subsequent determination of matching function pairs and candidate patch functions.

[0075] Step 204 , according to the calling relationship of the currently restored functions of the old version and the calling relationship of the currently restored functions of the new version, multiple old version functions are matched with multiple new version functions to obtain multiple matching function pairs; the matching function pairs include old version functions and new version functions that match each other.

[0076] In this embodiment, the electronic device matches multiple old version functions with multiple new version functions to find the new version functions corresponding to the old version functions in the new version binary program, thereby obtaining multiple matching function pairs. A matching function pair includes an old version function and a new version function, and the old version function and the new version function included in the matching function pair match each other.

[0077] It is understandable that due to the modification of the program code of the target software, the number of old version functions included in the old version binary may be different from the number of new version functions included in the new version binary program. Therefore, not every old version function has a matching new version function, and not every new version function has a matching old version function.

[0078] Step 205 : Determine at least one candidate patch function from a plurality of matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version.

[0079] In this embodiment, both the static function call relationship and the real function call sequence can reflect the function calls in the binary program, but the function calls in the static function call relationship do not necessarily occur during the program execution, while the function calls in the real function call sequence are the function calls that actually occur during the program execution.

[0080] In this embodiment, since patching the vulnerability of the target software will change the program code of the target software, and the change of the program code will affect the function calls of the target software during operation, the input data that can make the actual function call sequences of the new version binary program and the old version binary program different during operation may be the target input data that can trigger the vulnerability of the old version binary program. Therefore, after determining the matching function pair, the old version called function sequence set of each old version function can be determined based on the current restored function call relationship of the old version, and the new version called function sequence set of each new version function can be determined based on the current restored function call relationship of the new version. The called function sequence set includes at least one called function sequence, which is a sequence of functions called by the function call instruction sequence on a program branch in the function.

[0081] In this embodiment, the electronic device can determine, from multiple matching function pairs, a candidate patch function that is different from the new version called function set of the corresponding new version matching function based on the old version called function sequence set of the matched old version function and the new version called function set of the matched new version function. Furthermore, in the process of reproducing the target input data that triggers a vulnerability in the old version binary program, as long as the old version binary program is more likely to execute the candidate patch function, the target input data can be reproduced more efficiently. Furthermore, it should be understood that even if the old version binary program triggers a vulnerability during execution, it does not necessarily mean that the triggered vulnerability is caused by the old version binary program executing the candidate patch function.

[0082] Step 206 : Perform fuzz testing on the old version binary program and the new version binary program based on each candidate patch function and the second preset test case pool to determine target input data that can trigger the vulnerability of the old version binary program.

[0083] In this embodiment, the second preset test case pool includes multiple preset test cases. The electronic device uses each preset test case in the second preset test case pool to perform fuzz testing on the old version binary program and the new version binary program, based on the condition that the old version binary program is more likely to execute each candidate patch function during operation, to determine target input data that can trigger the vulnerability of the old version binary program.

[0084] In this embodiment, during the fuzz testing process, if the old version binary program and the new version binary program have different function call sequences when running the same test case, this test case can be determined as target input data.

[0085] The method for reproducing input data that triggers software vulnerabilities provided in this embodiment matches multiple old version functions with multiple new version functions based on the calling relationship of the currently restored functions in the new version to obtain multiple matching function pairs, and then determines the candidate patch functions that may have caused the vulnerability of the old version binary program from the matched old version functions, and then performs fuzz testing on the old version binary program and the new version binary program based on the candidate patch functions and a preset second test case pool, so that the old version binary program is more inclined to execute the candidate patch function during the fuzz testing process, which can increase the probability of reproducing the target input data that can trigger the vulnerability of the old version binary program in the fuzz testing, and more efficiently reproduce the input data that can trigger the repaired vulnerability.

[0086] Example 2

[0087] The method for reproducing input data that triggers a software vulnerability provided in this embodiment is based on the first embodiment, and step 204 "matching multiple old version functions with multiple new version functions according to the current restored function call relationship of the old version and the current restored function call relationship of the new version to obtain multiple matching function pairs" is refined to include steps 301 to 303.

[0088] Step 301 : determining matching information of each old version function according to the call relationship of the currently restored function of the old version.

[0089] Step 302: Determine matching information of each new version function based on the call relationship of the currently restored functions of the new version.

[0090] Step 303 : Match multiple old version functions with multiple new version functions according to the matching information of each old version function and the matching information of each new version function to obtain multiple matching function pairs.

[0091] In this embodiment, the matching information may include at least one of the following: the number of calls, the number of calls initiated, the number of preset call instruction types when initiating the call, the set of main calling functions when called, and whether the call relationship actually exists.

[0092] Among them, the number of calls and the number of calls initiated can be directly obtained from the currently restored function call relationship. For example, for an old version function, the number of times the old version function is called by other functions can be obtained from the old version's currently restored function call relationship as the number of calls, and the number of times the old version function calls other functions can be obtained as the number of calls initiated.

[0093] The set of main calling functions when a function is called can be obtained by forming a set of functions that call the function in the currently restored function call relationship.

[0094] The currently restored function call relationship may also include the call instruction type used when the function initiates the call. Furthermore, the number of each preset call instruction type when the function initiates the call can be obtained by counting each preset call instruction type used when the function initiates the call in the currently restored function call relationship. Among them, the call instruction type used when the function initiates the call can also be understood as the type of the target operand when the function initiates the call, or the address-taking method when the function initiates the call. Specifically, after decompiling the assembly program corresponding to the binary program, it can be determined based on the CALL Opcode corresponding to the assembly program when the function initiates the call.

[0095] The called relationship refers to the function being called by its calling function, which can be determined from the currently restored function call relationship. However, since the currently restored function call relationship is not necessarily accurate and complete, the called relationship may not actually occur when the program is running, while the real function call relationship does actually occur. Therefore, it is possible to determine whether the called relationship actually occurred based on the function calls that actually occurred in the real function call relationship.

[0096] The method for reproducing input data that triggers a software vulnerability provided in this embodiment can more accurately match multiple old version functions with multiple new version functions by combining multiple matching information.

[0097] Optionally, step 303 of “matching multiple old version functions with multiple new version functions according to the matching information of each old version function and the matching information of each new version function to obtain multiple matching function pairs” is further refined to include steps 401 to 404 .

[0098] Step 401 : Match the entry function of the old version binary program with the entry function of the new version binary program to obtain a matching function pair.

[0099] In this embodiment, the entry point function refers to the entry point of a program, also known as the main function, often written as main(). A program can only have one entry point function. Because the old version binary program and the new version binary program are the binary programs corresponding to the target software before and after the vulnerability is patched, the entry point function of the old version binary program and the entry point function of the new version binary program are determined as a matching function pair.

[0100] Step 402 : Calculate the matching value between each unmatched old version function and each unmatched new version function based on the matching information of each unmatched old version function and the matching information of each unmatched new version function.

[0101] Optionally, the matching information includes: the number of times called, the number of times calls are initiated, the number of preset call instruction types when the call is initiated, the set of main calling functions when called, whether the calling relationship actually exists, and step 402 "calculates the matching value between each unmatched old version function and each unmatched new version function based on the matching information of each unmatched old version function and the matching information of each unmatched new version function" is refined to include steps 501 to 507.

[0102] Optionally, since each old version function may be re-matched with each new version function during the subsequent fuzz testing process, the matching information may also include: the matching value between the old version function and the new version function during the historical matching process.

[0103] Step 501 : For any pair of unmatched old version functions and unmatched new version functions, perform the following operations: Step 502 to Step 507 .

[0104] In this embodiment, the term "caller" and "called" refers to the calling relationship between functions. A function that calls other functions is called the calling function, and a function called by other functions is called the called function. For example, if function F1 calls function F2, then function F2 is the called function of function F1, and function F1 is the calling function of function F2.

[0105] Step 502: Determine a first matching score based on the number of times the old version function and the new version function are called.

[0106] In this embodiment, the first matching score may be a ratio of a minimum value to a maximum value of the number of calls corresponding to the old version function and the new version function, respectively.

[0107] Step 503: Determine a second matching score based on the number of calls initiated by the old version function and the number of calls initiated by the new version function.

[0108] In this embodiment, the second matching score may be a ratio of a minimum value to a maximum value of the number of calls initiated by the old version function and the new version function, respectively.

[0109] For example, if the number of calls initiated by the unmatched old version function is 1 and the number of calls received is 2, and the number of calls initiated by the unmatched new version function is 4 and the number of calls received is 5, then the first matching score between the unmatched old version function and the unmatched new version function is 1 / 4, and the second matching score is 2 / 5.

[0110] Step 504 : Determine a third matching score based on the number of preset call instruction types corresponding to the old version function and the new version function when they initiate calls.

[0111] In this embodiment, the third matching score may be the ratio of the sum of the minimum values ​​plus one of the numbers of preset call instruction types corresponding to the old version function and the new version function when initiating calls to each other, to the sum of the average values ​​plus one.

[0112] Exemplarily, the preset call instruction types include a first call instruction type, a second call instruction type, and a third call instruction type. When the old version function initiates a call, the numbers of the first, second, and third call instruction types corresponding to each other are 0, 1, and 0, respectively, and when the new version function initiates a call, the numbers of the first, second, and third call instruction types corresponding to each other are 1, 2, and 1, respectively. Then the sum of the minimum values ​​of the numbers of each preset call instruction type corresponding to the old version function and the new version function when initiating a call is 0+1=1, the sum of the averages is (0+1+0) / 3+(1+2+1) / 3=5 / 3, and the third matching score is (1 / 3+1) / (5 / 3+1)=1 / 2. Among them, the sum of the minimum values ​​plus one and the sum of the averages plus one are in order to perform class normalization processing on the minimum value and the average, so that the calculated third matching score is more accurate.

[0113] Step 505 : Determine a fourth matching score based on the sets of main calling functions corresponding to the old version function and the new version function when they are called.

[0114] Optionally, the fourth matching score is the first preset value or the second preset value, the first preset value is greater than the second preset value, and step 505 "determine the fourth matching score based on the set of main calling functions corresponding to the old version function and the new version function when they are called" is further refined to include steps 601 to 602.

[0115] Step 601 : In response to a matching function pair existing between corresponding calling function sets when an old version function and a new version function are called, determining a fourth matching score to be a first preset value.

[0116] Step 602 : In response to the fact that no matching function pair exists between the corresponding calling function sets when the old version function and the new version function are called, determining that the fourth matching score is a second preset value.

[0117] In this embodiment, the first preset value may be 1, and the second preset value may be 0. Since a function in the target software may be called by multiple different calling functions, if there is a matching calling function between the old version function and the new version function, the fourth matching score between the old version function and the new version function may be determined as the first preset value. This is because functions called under a matching function are more likely to match each other.

[0118] The method for reproducing input data that triggers a software vulnerability provided in this embodiment is capable of more accurately matching multiple old version functions with multiple new version functions because when a matching function pair exists between the corresponding main calling function sets when the old version function and the new version function are called, the fourth matching score is set to the first preset value.

[0119] Step 506: Determine a fifth matching score based on whether the calling relationship between the old version function and the new version function actually exists.

[0120] Optionally, the fifth matching score is the third preset value or the fourth preset value, the third preset value is greater than the fourth preset value, and step 506 "determine the fifth matching score based on whether the calling relationship between the old version function and the new version function actually exists" is refined to include steps 701 to 702.

[0121] Step 701 : In response to the old version function's called relationship existing in the old version real function call sequence and the new version function's called relationship existing in the new version real function call sequence, determining that the fifth matching score is a third preset value.

[0122] Step 702 : In response to the old version function's called relationship not existing in the first old version real function call sequence, or the new version function's called relationship not existing in the new version real function call sequence, determine the fifth matching score to be a fourth preset value.

[0123] In this embodiment, since the called function is not necessarily called during program execution, if it is actually called during program execution, it will exist in the actual function call sequence. Therefore, it is necessary to determine whether the calling function of the old version function actually calls the old version function during program execution, and whether the calling function of the new version function actually calls the new version function during program execution.

[0124] In this embodiment, if the corresponding call relationships between an unmatched old version function and an unmatched new version function both exist in the corresponding real function call sequence, then the possibility of the two matching each other can be considered to be higher. Conversely, if the corresponding call relationships between the two actually occur in different situations, or if the corresponding call relationships between the two do not actually occur, then the possibility of the two matching each other can be considered to be lower.

[0125] Therefore, when the call relationship of the old version function exists in the old version real function call sequence, and the call relationship of the new version function exists in the new version real function call sequence, the fifth matching score is determined to be the third preset value. When the call relationship of the old version function does not exist in the first old version real function call sequence, or when the call relationship of the new version function does not exist in the new version real function call sequence, the fifth matching score is determined to be the fourth preset value. The third preset value can be 1, and the fourth preset value can be 0.

[0126] The method for reproducing input data that triggers a software vulnerability provided by this embodiment determines the fifth matching score based on whether the function call relationship exists in the actual function call sequence. Therefore, it is possible to match multiple new version functions with multiple old version functions based on the actual situation of the old version binary program and the new version binary program at runtime, thereby obtaining more accurate matching function pairs.

[0127] Step 507 : Perform weighted sum calculation on the first matching score, the second matching score, the third matching score, the fourth matching score, and the fifth matching score according to their corresponding preset weights to obtain a matching value between the unmatched old version function and the unmatched new version function.

[0128] In this embodiment, the first matching score, the second matching score, the third matching score, the fourth matching score and the fifth matching score can respectively correspond to different preset weights, so that in the process of matching multiple old version functions with multiple new version functions, the preset weights corresponding to each matching score can be adjusted, so as to more accurately match multiple old version functions with multiple new version functions.

[0129] The method for reproducing input data that triggers a software vulnerability provided in this embodiment calculates the matching value between an unmatched old version function and an unmatched new version function from different angles of multiple matching information, and performs weighted sum calculation on the first to fifth matching scores according to the corresponding preset weights. Therefore, the matching value between the old version function and the new version function can be accurately calculated.

[0130] Step 403: Determine a pair of unmatched old version functions and unmatched new version functions with the highest matching value as a matching function pair.

[0131] In this embodiment, the matching value reflects the degree of match between the old version function and the new version function. Therefore, the pair of unmatched old version functions and unmatched new version functions with the highest matching value is determined to be a matching function pair. It should be understood that the old version function in the matching function pair is the matched old version function, and the new version function in the matching function pair is the matched new version function. Neither the matched old version function nor the matched new version function participates in the next round of matching degree calculation.

[0132] Step 404, repeatedly executing the steps of calculating the matching value between each unmatched old version function and each unmatched new version function and determining a pair of unmatched old version functions and unmatched new version functions with the highest matching value as a matching function pair, until there are no unmatched old version functions, or until there are no unmatched new version functions, to obtain multiple matching function pairs.

[0133] In this embodiment, since the matching value between the unmatched old version function and the unmatched new version function may change after each matching function pair is determined, it is necessary to recalculate the matching value between each unmatched old version function and each unmatched new version function after each matching function pair is determined, and determine the pair of unmatched old version functions and unmatched new version functions with the highest matching value as a matching function pair, so that multiple old version functions can be matched with multiple new version functions more accurately.

[0134] The method for reproducing input data that triggers software vulnerabilities provided in this embodiment can reflect whether the old version function and the new version function match each other because the matching value is calculated based on the matching information of each unmatched function. Therefore, a pair of unmatched old version functions and unmatched new version functions with the highest matching value are determined as a matching function pair, which can accurately match multiple new version functions with multiple old version functions.

[0135] Example 3

[0136] The method for reproducing input data that triggers a software vulnerability provided in this embodiment is based on any of the above embodiments, and step 205 "determining at least one candidate patch function from multiple matched old version functions based on the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version" is refined to include steps 801 to 803.

[0137] Step 801, based on the old version currently restored function call relationship, determine the old version called function sequence set of the old version function in each matching function pair; the old version called function sequence set includes at least one old version called function sequence, and the old version called function sequence is the sequence of functions called by the function call instruction sequence on a program branch in the old version function.

[0138] In this embodiment, the function call relationship currently restored in the old version includes function calls and instructions that initiate function calls. For example, if the function call relationship currently restored in the old version is a function call relationship graph, function F1 and function F2 are connected by a directed edge from function F1 to function F2, then the directed edge records the instruction for calling function F2. The instruction for calling the function can be obtained by analyzing the assembly program or during program execution.

[0139] It is understandable that a function may have multiple program branches, and therefore a function may have multiple called function sequences. Furthermore, a function corresponds to a set of called function sequences.

[0140] Step 802, based on the function call relationship currently restored in the new version, determine the new version called function sequence set of the new version function in each matching function pair; the new version called function sequence set includes at least one new version called function sequence, and the new version called function sequence is the sequence of functions called by the function call instruction sequence on a program branch in the new version function.

[0141] In this embodiment, the method for determining the new version called function sequence set of the new version function in each matching function pair may refer to the method for determining the old version called function sequence set of the old version function in each matching function pair, which will not be described in detail here.

[0142] Step 803 : In response to the difference between the old version called function sequence set of the old version function and the new version called function sequence set of the new version function in the matching function pair, the old version function in the matching function pair is determined as a candidate patch function.

[0143] In this embodiment, if there are different called functions in the called function sequence, or the order of the called functions is different, then the called function sequences are different. If there are different old version called function sequences and new version called function sequences in the old version called function sequence set and the new version called function sequence set, then the called function sequence sets are different.

[0144] Exemplarily, the old version of the called function sequence includes functions F1, F2, and F3, and the order in which functions F1, F2, and F3 are called is F1, F2, and F3. If the new version of the called function sequence includes functions F1, F2, and F3, and the order in which functions F1, F2, and F3 are called is F1, F2, and F3, then the old version of the called function sequence is the same as the new version of the called function sequence. If the new version of the called function sequence includes functions F1, F2, and F3, and the order in which functions F1, F2, and F3 are called is F1, F3, and F2, then the old version of the called function sequence is different from the new version of the called function sequence. If the new version of the called function sequence includes functions F1, F2, and F4, and the order in which functions F1, F2, and F4 are called is F1, F2, and F4, then the old version of the called function sequence is different from the new version of the called function sequence.

[0145] The method for reproducing input data that triggers a software vulnerability provided in this embodiment can determine a candidate patch function that may trigger the vulnerability by comparing the called function sequence sets of the old version function and the new version function in the matching function pair.

[0146] Example 4

[0147] The method for reproducing input data that triggers software vulnerabilities provided in this embodiment is based on any of the above embodiments. The second preset test case pool includes multiple initial test cases, and the initial test cases can be successfully run by the new version binary program and the old version binary program. In addition, step 206 "Fuzz testing is performed on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool to determine the target input data that can trigger the vulnerability of the old version binary program" is refined to include step 901.

[0148] Step 901: perform a first traversal on each initial test case, and during the first traversal, perform a first operation once each time an initial test case is traversed.

[0149] The first operation includes: step 9011 to step 9018.

[0150] Step 9011: mutate the initial test case according to a preset mutation time and a preset mutation method to obtain a plurality of mutated test cases corresponding to the initial test case.

[0151] In this embodiment, the preset mutation time can be any appropriate time, and the preset mutation mode can be any appropriate mutation mode. Each initial test case can be mutated into multiple mutated test cases.

[0152] Step 9012: Run each mutated test case using the old version binary program to determine whether each mutated test case runs successfully in the old version binary program.

[0153] Step 9013: In response to any mutated test case being successfully executed in the old version binary program, the old version mutated function call sequence and the old version mutated program execution path during the old version binary program running the mutated test case are obtained.

[0154] In this embodiment, the mutated test case can be used as input data and run in the old version binary program. If the old version binary program becomes unresponsive, reports an error, and cannot be analyzed, the run fails. If the run succeeds, the old version's mutated function call sequence and the old version's mutated program execution path can be obtained.

[0155] The old version mutated function call sequence refers to the functions called by the old version binary program during the process of running the mutated test case, and the order of the called functions.

[0156] The execution path of the mutated legacy program includes the actual program branches executed by the legacy binary program during the execution of the mutated test case. Since the target software may include multiple branches, the target software binary program may choose to execute different branches during execution based on input data, judgment condition results, and other factors. For example, if the program includes conditional judgments, such as if-else statements, different branches will be executed when the condition is true and false. Similarly, if a switch statement executes different branches when the condition is different, different branches will be executed.

[0157] In this embodiment, the electronic device can obtain the function call sequence and program execution path of the old version after mutation by performing instrumentation tracking on the process of running each preset test case of the old version binary program and analyzing the operation log of the old version binary program.

[0158] Step 9014: Run each mutated test case using the new version of the binary program to determine whether each mutated test case runs successfully in the new version of the binary program.

[0159] Step 9015 , in response to any mutated test case being successfully executed in the new version binary program, a new version mutated function call sequence and a new version mutated program execution path during the execution of the mutated test case by the new version binary program are obtained.

[0160] Step 9014 and step 9015 are similar to step 9012 and step 9013 and are not described in detail here.

[0161] Step 9016 : In response to any mutated test case being successfully executed in the old version binary program and successfully executed in the new version binary program, the mutated test case is determined as a candidate test case.

[0162] In this embodiment, since the new version of the binary program is an updated version of the old version of the binary program, for the same mutated test case, whether it runs successfully in the old version of the binary program and the new version of the binary program may be different. Only the mutated test case that runs successfully in both the old version of the binary program and the new version of the binary program may be the input data that triggers the vulnerability of the old version of the binary program.

[0163] Step 9017: Determine the order of performing a second traversal on each candidate test case based on the old version mutated program execution path and the candidate patch function corresponding to each candidate test case.

[0164] In this embodiment, in order to determine the target input data from the candidate test cases, it is necessary to traverse each candidate test case and compare the old version mutated function call sequence and the new version mutated function call sequence corresponding to each candidate test case during the traversal process. In order to improve the efficiency of reproducing the target input data, based on the principle that the easier it is to execute the candidate patch function, the easier it is to trigger the vulnerability, the order of the second traversal of each candidate test case is determined according to the old version mutated program execution path and the candidate patch function corresponding to the candidate test case. If the candidate test case is more likely to cause the old version binary program to execute the candidate patch function, then the candidate test case will be traversed first.

[0165] In this embodiment, the order of traversing the candidate test cases may be determined based on the total distance between the old version mutated program execution path corresponding to the candidate test case and the candidate patch functions.

[0166] Step 9018: perform a second traversal on each candidate test case in the order in which the second traversal is performed on each candidate test case, and perform a second operation every time a candidate test case is traversed during the second traversal.

[0167] The second operation includes step 90181.

[0168] Step 90181: Determine whether the candidate test case is the target input data based on the old version mutated function call sequence and the new version mutated function call sequence corresponding to the candidate test case.

[0169] In this embodiment, since patching the vulnerability will change the function call relationship, if the old version of the mutated function call sequence and the new version of the mutated function call sequence corresponding to the candidate test case are different, for example, the functions included in the function call sequence and the order of function calls in the function call sequence are different, then the candidate test case can be determined as the target input data.

[0170] The method for reproducing input data that triggers a software vulnerability provided in this embodiment can improve the efficiency of obtaining target input data because the candidate patch function can affect the traversal order during the fuzz testing process.

[0171] Optionally, step 90181 “determining whether the candidate test case is the target input data based on the old version mutated function call sequence and the new version mutated function call sequence corresponding to the candidate test case” is further refined to include steps 1001 to 1002.

[0172] Step 1001 : determining an old version last segment function call sequence of an old version mutated function call sequence, and determining a new version last segment function call sequence of a new version mutated function call sequence.

[0173] In this embodiment, the last function call sequence refers to a preset number of functions that are last called during the running of the binary program.

[0174] Step 1002 : In response to the difference between the last segment function call sequence of the old version and the last segment function call sequence of the new version, determining the candidate test case as the target input data.

[0175] In this embodiment, since the function call sequence after the old version is mutated and the function call sequence after the new version is mutated is longer, and during the program running process, the last function call sequence can better reflect the difference in the function call sequence of the program. Therefore, by comparing the terminal function call sequence, if the old version binary program and the new version binary program have different last function call sequences when the input data is the same, it can be considered that this input data triggers the vulnerability in the old version binary program, and the target input data can be determined more efficiently.

[0176] Optionally, the refinement of "using the old version binary program to run each post-mutation test case" in step 9012 includes step 9012a, the refinement of "determining the old version of the last function call sequence of the old version of the post-mutation function call sequence" in step 1001 includes step 1001a, the refinement of "using the new version binary program to run each post-mutation test case" in step 9014 includes step 9014a, and the refinement of "determining the new version of the last function call sequence of the new version of the post-mutation function call sequence" in step 1001 includes step 1001b.

[0177] Step 9012a: Use the first circular array to record function calls during the process of running the mutated test case of the old version binary program.

[0178] Step 1001a: Determine the function calls recorded in the first ring array as the old version last segment function call sequence in order from the beginning to the end.

[0179] Step 9014a: Use a second circular array to record function calls during the process of running the mutated test case in the new version of the binary program; the length of the second circular array is the same as that of the first circular array.

[0180] Step 1001b: Determine the function calls recorded in the second ring array in order from the beginning to the end as the new version of the last function call sequence.

[0181] In this embodiment, since the circular array can record ordered data of a fixed length, when the mutated function call sequence is recorded through the circular array, if the length of the function call sequence exceeds the length of the circular array, the circular array can directly implement the update of the last segment of the function call sequence. When the binary program runs the mutated test case, the mutated function call sequence is recorded through the circular array. After the binary program is finished running, the old version of the last segment of the function call sequence and the new version of the last segment of the function call sequence can be more efficiently determined directly based on the data stored in the circular data.

[0182] Optionally, step 9017 “determining the order of performing a second traversal on each candidate test case according to the old version mutated program execution path and the candidate patch function corresponding to each candidate test case” is further refined to include steps 1101 to 1102 .

[0183] Step 1101, calculate the execution distance between the old version of the mutated program execution path corresponding to each candidate test case and each candidate patch function. In this embodiment, the program execution path includes functions that are actually called during the program running process. The candidate patch function may not be actually called by the old version binary program during the running of the mutated test case. When the old version of the mutated program execution path includes the candidate patch function, the execution distance between the old version of the mutated program execution path and the candidate patch function can be 0. When the old version of the mutated program execution path does not include the candidate patch function, the execution distance between the old version of the mutated program execution path and the candidate patch function can be determined as the minimum value of the distance between each function on the old version of the mutated program execution path and the candidate patch function according to the old version's currently restored function call relationship.

[0184] Step 1102 : Determine the order of performing a second traversal on each candidate test case based on the execution distance between the old version mutated program execution path corresponding to each candidate test case and each candidate patch function.

[0185] Optionally, step 1102 “determining the order of performing a second traversal on each candidate test case based on the execution distance between the old version mutated program execution path corresponding to each candidate test case and each candidate patch function” is further refined to include steps 11021 to 11022 .

[0186] Step 11021: For each candidate test case, sum the execution distances between the old version mutated program execution path and each candidate patch function to obtain a candidate distance corresponding to each candidate test case;

[0187] Step 11022: Determine the order of corresponding candidate distances from small to large as the order for performing a second traversal on each candidate test case.

[0188] In this embodiment, the smaller the sum of the execution distances between the old version of the mutated program execution path corresponding to the candidate test case and each candidate patch function, the smaller the sum of the execution distances between the old version of the mutated program execution path corresponding to the candidate test case and each candidate patch function is, the more likely it is that the candidate test case can make it easier for the old version of the binary program to execute more candidate patch functions. Therefore, the execution distances between the old version of the mutated program execution path corresponding to each candidate test case and each candidate patch function are determined in order from small to large, or from near to far, as the order of the second traversal of each candidate test case, so as to make it easier to execute the candidate patch function during the fuzz testing process and improve the efficiency of reproducing the target input data.

[0189] Optionally, step 1101 of “calculating the execution distance between the old version mutated program execution path corresponding to each candidate test case and each candidate patch function” is further refined to include steps 1201 to 1204 .

[0190] Step 1201: For an old version mutated program execution path and a candidate patch function, obtain a predecessor function of the candidate patch function on the old version mutated program execution path; the predecessor function exists on the old version mutated program execution path and is the main calling function of the candidate patch function that is closest to the candidate patch function.

[0191] In this embodiment, the predecessor function is the main calling function of the candidate patch function that is closest to the candidate patch function on the execution path of the old version of the program after the mutation. Specifically, the candidate patch function can be traced back in the old version's complete function relationship graph to find the predecessor function of the candidate patch function on the execution path of the old version of the program after the mutation.

[0192] For example, FIG3 is a schematic diagram of a currently restored function call relationship of an old version provided according to Example 4 of the present application. As shown in FIG3, the old version binary program includes functions A, B, C1, C2, C3, and C4. Function A can call functions B and C1, function B can call functions C2 and C3, and function C3 can call function C4. If the old version binary program includes functions A, B, and C2 on the old version mutated program execution path during the process of running the mutated test case, then the predecessor function of function C3 on the old version mutated program execution path is function B.

[0193] Step 1202 , calculating a first distance from the entry function of the old version binary program to the predecessor function according to the execution path of the old version mutated program.

[0194] In this embodiment, the first distance refers to the distance from the entry function to the predecessor function during program execution. The first distance can be the sum of the jump distances of all functions on the path from the entry function to the predecessor function. The jump distance of each function can be 1 or an adjacency distance. The adjacency distance is the sum of the reciprocal of twice the number of functions called within the function and 1.

[0195] Step 1203 : Calculate a second distance from the execution of the predecessor function to the candidate patch function.

[0196] In this embodiment, the second distance refers to the distance from the predecessor function to the candidate patch function, as determined from the call relationship of the restored current function in the old version. The second distance can be the sum of the jump distances of all functions on the path from the predecessor function to the candidate patch function.

[0197] Exemplarily, when the jump distance of each function is unit 1, in the old version of the currently restored function call relationship shown in Figure 3, the first distance from function A to execution to function B is the jump distance of function A, which is 1; the first distance from function A to function C2 is the sum of the jump distances of function A and function B, which is 2.

[0198] Step 1204 : Determine the sum of the first distance and the second distance as the execution distance between the execution path of the old version of the mutated program and the candidate patch function.

[0199] In this embodiment, the execution distance can be the sum of the first distance and the second distance. Continuing with the above example, as shown in Figure 3, if the old version of the mutated program execution path corresponding to the mutated test case is the path where functions A, B, and C2 are located, and function C3 is a candidate patch function, then the predecessor function of function C3 is function B. The execution distance between the old version of the mutated program execution path and function C3 can be the sum of the first distance from function A to function B and the second distance from function B to function C3. If the first distance from function A to function B is 1, and the second distance from function B to function C3 is 1, then the execution distance between the old version of the mutated program execution path and function C3 is 2.

[0200] The method for reproducing input data that triggers a software vulnerability provided in this embodiment first obtains the predecessor function of the candidate patch function on the execution path of the old version of the mutated program, and then calculates the execution distance between the execution path of the old version of the mutated program and the candidate patch function through the first distance between the entry function and the predecessor function, and the distance between the predecessor function and the candidate patch function. Therefore, the execution distance between the execution path of the old version of the mutated program and the candidate patch function can be accurately calculated, which facilitates the subsequent determination of whether the mutated test case can enable the old version of the binary program to execute the candidate patch function as much as possible based on the execution distance between the execution path of the old version of the mutated program and the candidate patch function.

[0201] Optionally, before step 901 "performing a first traversal of each initial test case, and during the first traversal, executing a first operation once for each initial test case traversed", steps 1301 to 1302 are also included, and the "performing a first traversal of each initial test case" in step 901 is further refined to include step 901a.

[0202] Step 1301: Obtain the old version initial program execution path corresponding to each initial test case.

[0203] Step 1302 : Determine the order of first traversal of each initial test case based on the old version initial program execution path corresponding to each initial test case and each candidate patch function.

[0204] Step 901a: perform a first traversal on each initial test case in the order in which the first traversal is performed on each initial test case.

[0205] In this embodiment, since each initial test case included in the second preset test case pool can be successfully executed by both the new version binary program and the old version binary program, the electronic device can pre-store the old version initial program execution path during the old version binary program's execution of each initial test case. Alternatively, the electronic device can use the old version binary program to run each initial test case to obtain the old version initial program execution path corresponding to each initial test case.

[0206] In this embodiment, the order of performing the first traversal of each initial test case can be determined based on the execution distance between the execution path of the old version initial program corresponding to each initial test case and each candidate patch function. The method for calculating the execution distance between each old version initial program execution path and each candidate patch function can be referred to the method for calculating the execution distance between the execution path of the old version mutated program and each candidate patch function, and is not further described here.

[0207] In this embodiment, the electronic device can determine the execution distances between each old version of the initial program execution path and each candidate patch function in ascending order as the order for the first traversal of each initial test case, so as to increase the probability that the mutated test case corresponding to the initial test case will execute the candidate patch function when running in the old version of the binary program, and more efficiently determine the target input data.

[0208] Example 5

[0209] The method for reproducing input data that triggers software vulnerabilities provided in this embodiment is based on the fourth embodiment. After step 9013 "in response to the successful execution of any mutated test case in the old version binary program, the old version mutated function call sequence and the old version mutated program execution path in the process of the old version binary program running the mutated test case are obtained", it also includes steps 1401 to 1403.

[0210] Step 1401 , for any mutated test case that has been successfully run in the old version binary program, perform the following operations: Step 1402 to Step 1403 .

[0211] Step 1402 , determining whether the old version of the mutated program execution path triggers new code coverage of the old version of the binary program.

[0212] Step 1403 : In response to the old version mutated program execution path triggering new code coverage of the old version binary program, the mutated test case is added as an initial test case to the second preset test case pool.

[0213] In this embodiment, in order to improve the code coverage of the old version binary program by fuzz testing, if the execution path of the old version mutated program corresponding to the mutated test case that runs successfully in the old version binary program triggers new code coverage in the old version binary program, the mutated test case is added as the initial test case to the second preset test case pool to update the second preset test case pool. The updated second preset test case pool can be used for the next round of fuzz testing.

[0214] Optionally, after step 9013 "In response to any mutated test case being successfully run in the old version binary program, obtaining the old version mutated function call sequence and the old version mutated program execution path in the process of the old version binary program running the mutated test case", steps 1501 to 1503 are also included.

[0215] Step 1501 , for any mutated test case that is successfully run in the new version of the binary program, perform the following operations: Step 1502 to Step 1503 .

[0216] Step 1502 , determining whether there is an old version new function call relationship in the old version mutated function call sequence that does not exist in the old version currently restored function call relationship.

[0217] Step 1503 : In response to the existence of an old version new function call relationship in the old version mutated function call sequence, the mutated test case is added as an initial test case to the second preset test case pool.

[0218] In this embodiment, the old version of the new function call relationship that does not exist in the old version of the currently restored function call relationship can be used to update the currently restored function call relationship, thereby changing the matching between each old version function and each new version function, and changing the candidate patch function. Therefore, if the old version of the mutated function call sequence corresponding to the mutated test case that runs successfully in the new version of the binary program contains an old version of the new function call relationship that does not exist in the old version of the currently restored function call relationship, then the mutated test case needs to be added to the second preset test case pool to update the second preset test case pool, and the updated second preset test case pool can be used for the next round of fuzz testing.

[0219] Optionally, after step 1502 of “determining whether there is an old version new function call relationship in the old version mutated function call sequence that does not exist in the old version currently restored function call relationship”, step 1601 is also included.

[0220] Step 1601 , in response to the existence of an old version new function calling relationship in the old version mutated function calling sequence, the old version new function calling relationship is used to supplement the currently restored function calling relationship of the old version.

[0221] In this embodiment, since there is an old version and new function calling relationship in the function calling sequence after the old version is mutated, the old version and new function calling relationship can be used to supplement the old version and currently restored function calling relationship to obtain a more complete old version and currently restored function calling relationship, and then more accurately match each old version function and each new version function.

[0222] Optionally, after step 9015 "In response to any mutated test case being successfully run in the new version of the binary program, obtaining the new version of the mutated function call sequence and the new version of the mutated program execution path during the process of running the mutated test case in the new version of the binary program", steps 1701 to 1703 are also included.

[0223] Step 1701 , for any mutated test case that is successfully run in the new version of the binary program, perform the following operations: Step 1702 to Step 1703 .

[0224] Step 1702 , determining whether the execution path of the new version of the mutated program triggers new code coverage of the new version of the binary program.

[0225] In step 1703 , in response to the execution path of the new version of the mutated program triggering new code coverage of the new version of the binary program, the mutated test case is added as an initial test case to the second preset test case pool.

[0226] In this embodiment, in order to improve the code coverage of the new version of the binary program by fuzz testing, if the new version of the mutated program execution path corresponding to the mutated test case that runs successfully in the new version of the binary program triggers new code coverage in the new version of the binary program, the mutated test case is added as the initial test case to the second preset test case pool to update the second preset test case pool. The updated second preset test case pool can be used for the next round of fuzz testing.

[0227] Optionally, after step 9015 "In response to any mutated test case being successfully run in the new version of the binary program, obtaining the new version of the mutated function call sequence and the new version of the mutated program execution path during the process of running the mutated test case in the new version of the binary program", steps 1801 to 1803 are also included.

[0228] Step 1801 , for any mutated test case that is successfully run in the new version of the binary program, perform the following operations: Step 1802 to Step 1803 .

[0229] Step 1802 , determining whether there is a new version new function call relationship in the new version mutated function call sequence that does not exist in the new version currently restored function call relationship.

[0230] Step 1803 : In response to the existence of a new version new function call relationship in the new version mutated function call sequence, the mutated test case is added as an initial test case to the second preset test case pool.

[0231] In this embodiment, the new version of the new function call relationship that does not exist in the new version of the currently restored function call relationship can be used to update the currently restored function call relationship, thereby changing the matching between each new version function and each new version function, and changing the candidate patch function. Therefore, if the new version of the mutated function call sequence corresponding to the mutated test case that runs successfully in the new version of the binary program contains a new version of the new function call relationship that does not exist in the new version of the currently restored function call relationship, then the mutated test case needs to be added to the second preset test case pool to update the second preset test case pool, and the updated second preset test case pool can be used for the next round of fuzz testing.

[0232] Optionally, after step 1802 of "determining whether there is a new version new function call relationship in the new version mutated function call sequence that does not exist in the new version currently restored function call relationship", the method further includes: step 1901.

[0233] Step 1901 , in response to the existence of a new version new function call relationship in the new version mutated function call sequence, the new version new function call relationship is used to supplement the currently restored function call relationship of the new version.

[0234] In this embodiment, since there is a new version-new function call relationship in the function call sequence after the new version is mutated, the new version-new function call relationship can be used to supplement the new version's currently restored function call relationship to obtain a more complete new version's currently restored function call relationship, and then more accurately match each new version function and each new version function.

[0235] Optionally, after step 901 of "performing a first traversal on each initial test case, and during the first traversal, executing a first operation once for each initial test case traversed", step 2001 is also included.

[0236] Step 2001, repeatedly executing the steps of matching multiple old version functions with multiple new version functions according to the old version currently restored function call relationship and the new version currently restored function call relationship to obtain multiple matching function pairs, determining at least one candidate patch function from multiple matched old version functions according to the old version currently restored function call relationship and the new version currently restored function call relationship, and performing a first traversal on each initial test case, and in the process of the first traversal, executing the first operation once for each initial test case traversed, until the end condition of the fuzz test is met.

[0237] In this embodiment, fuzz testing can be performed for multiple rounds until the end conditions of the fuzz testing are met. Therefore, in each round of fuzz testing, as long as new code coverage appears during the operation of the mutated test case, the second test case pool can be updated, and if a new function call appears, at least one of the second test case pool and the candidate patch function can be updated to improve the efficiency of the next round of fuzz testing in determining the target input data. Among them, the update of the candidate patch function requires the update of the matching function pair. The update of the matching function pair requires the update of at least one of the old version's currently restored function call relationship and the new version's currently restored function call relationship. Therefore, the old version's currently restored function call relationship can be updated through each old version's mutated function call sequence, and the new version's currently restored function call relationship can be updated through each new version's mutated function call sequence.

[0238] In this embodiment, the end condition of the fuzzy test may be that the number of running rounds of the fuzzy test reaches a preset number, the running time of the fuzzy test reaches a preset time, the number of determined target input data reaches a preset number, etc., which is not limited here.

[0239] Example 6

[0240] Figure 4 is a flow chart of a method for reproducing input data that triggers a software vulnerability according to Embodiment 6 of the present application. As shown in Figure 4 , in this embodiment, the method for reproducing input data that triggers a software vulnerability includes steps S2101 to S2107.

[0241] In step S2101, the electronic device obtains multiple old version functions and old version static function call relationships included in the old version binary program of the target software before the vulnerability is patched, and obtains multiple new version functions and new version static function call relationships included in the new version binary program of the target software after the vulnerability is patched.

[0242] In step S2102, the electronic device obtains an old version of a real function call sequence of the old version of the binary program during the execution of a first test case, and obtains a new version of a real function call sequence of the new version of the binary program during the execution of the first test case; the first test case belongs to a first preset test case pool.

[0243] In step S2103, the electronic device determines the currently restored function call relationship of the old version based on the static function call relationship of the old version and the real function call series of the old version, and determines the currently restored function call relationship of the new version based on the static function call relationship of the new version and the real function call sequence of the new version.

[0244] In step S2104, the electronic device matches multiple old version functions with multiple new version functions according to the calling relationship of the currently restored functions of the old version and the calling relationship of the currently restored functions of the new version to obtain multiple matching function pairs; the matching function pairs include old version functions and new version functions that match each other.

[0245] In step S2105, the electronic device determines the old version called function sequence set of the old version function in each matching function pair based on the old version currently restored function call relationship; and determines the new version called function sequence set of the new version function in each matching function pair based on the new version currently restored function call relationship.

[0246] Step S2106 , in response to the difference between the old version called function sequence set of the old version function and the new version called function sequence set of the new version function in the matching function pair, the electronic device determines the old version function in the matching function pair as a candidate patch function.

[0247] In step S2107 , the electronic device performs fuzz testing on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool to determine target input data that can trigger the vulnerability of the old version binary program.

[0248] FIG5 is a flow chart of fuzz testing in a method for reproducing input data that triggers a software vulnerability according to a sixth embodiment of the present application. As shown in FIG5 , the fuzz testing includes:

[0249] Step S2201: perform a first traversal on each initial test case, and during the first traversal, perform a first operation once each time an initial test case is traversed.

[0250] The first operation includes: step S2202 to step S2208.

[0251] Step S2202 , mutating the current initial test case according to a preset mutation time and a preset mutation method, to obtain a plurality of mutated test cases corresponding to the current initial test case.

[0252] Step S2203 , using the old version binary program to run each mutated test case, and determining whether each mutated test case runs successfully in the old version binary program.

[0253] Step S2204 , in response to any mutated test case being successfully executed in the old version binary program, obtaining the old version mutated function call sequence and the old version mutated program execution path during the process of the old version binary program running the mutated test case.

[0254] Step S2205 , running each mutated test case using the new version of the binary program to determine whether each mutated test case runs successfully in the new version of the binary program.

[0255] Step S2206 , in response to any mutated test case being successfully executed in the new version binary program, a new version mutated function call sequence and a new version mutated program execution path in the process of the new version binary program running the mutated test case are obtained.

[0256] Step S2207 : In response to any mutated test case being successfully executed in the old version binary program and successfully executed in the new version binary program, the mutated test case is determined as a candidate test case.

[0257] Step S2208, based on the old version mutated program execution path and candidate patch function corresponding to each candidate test case, determine the order of performing a second traversal on each candidate test case, and perform a second traversal on each candidate test case in the order of performing the second traversal on each candidate test case, and during the second traversal, perform the second operation each time a candidate test case is traversed.

[0258] The second operation includes: step S2209.

[0259] Step S2209 , determining whether the candidate test case is target input data based on the old version mutated function call sequence and the new version mutated function call sequence corresponding to the candidate test case.

[0260] Step S2204 also includes step S2210: for any mutated test case that is successfully run in the old version binary program or the new version binary program, perform the following operations:

[0261] Step S2211, determining whether the execution path of the old version of the mutated program corresponding to the mutated test case triggers new code coverage of the old version of the binary program, and whether the corresponding execution path of the new version of the mutated program triggers new code coverage of the new version of the binary program;

[0262] Step S2212 : In response to triggering new code coverage of the old version binary program or triggering new code coverage of the new version binary program, adding the mutated test case as an initial test case to the second preset test case pool.

[0263] Step S2204 also includes step S2213: for any mutated test case that is successfully run in the old version binary program or the new version binary program, perform the following operations:

[0264] Step S2214, determining whether there is an old version new function call relationship that does not exist in the old version currently restored function call relationship in the old version of the mutated function call sequence corresponding to the mutated test case, and whether there is a new version new function call relationship that does not exist in the new version currently restored function call relationship in the corresponding new version mutated function call sequence;

[0265] Step S2215 , in response to the existence of an old version-new function calling relationship or a new version-new function calling relationship, adding the mutated test case as an initial test case to the second preset test case pool.

[0266] Step S2215 also includes supplementing the currently restored function call relationship of the old version with the new version's new function call relationship, and / or supplementing the currently restored function call relationship of the new version with the new version's new function call relationship.

[0267] It should be noted that the various steps shown in Figures 4 and 5 do not constitute specific limitations on the present application. In other embodiments of the present application, the process of reproducing the input data that triggers the software vulnerability may include more or fewer steps than in Figure 4, the fuzz testing process may include more or fewer steps than in Figure 5, some steps in Figures 4 and 5 may be replaced by steps with the same function, or some steps in Figures 4 and 5 may be split into multiple steps.

[0268] Example 7

[0269] FIG6 is a schematic diagram of the structure of a device for reproducing input data that triggers a software vulnerability according to a seventh embodiment of the present application. As shown in FIG6 , the device 60 for reproducing input data that triggers a software vulnerability provided in this embodiment includes: a first acquisition module 61, a second acquisition module 62, a first determination module 63, a matching module 64, a second determination module 65, and a third determination module 66.

[0270] The first acquisition module 61 is used to obtain the calling relationships of multiple old version functions and old version static functions included in the old version binary program of the target software before the vulnerability is patched, and to obtain the calling relationships of multiple new version functions and new version static functions included in the new version binary program of the target software after the vulnerability is patched.

[0271] The second acquisition module 62 is used to obtain the old version of the real function call sequence of the old version binary program during the execution of the first test case, and to obtain the new version of the real function call sequence of the new version binary program during the execution of the first test case; the first test case belongs to the first preset test case pool.

[0272] The first determination module 63 is used to determine the currently restored function call relationship of the old version based on the old version static function call relationship and the old version real function call series, and to determine the currently restored function call relationship of the new version based on the new version static function call relationship and the new version real function call sequence.

[0273] The matching module 64 is used to match multiple old version functions with multiple new version functions according to the calling relationship of the old version currently restored functions and the calling relationship of the new version currently restored functions to obtain multiple matching function pairs; the matching function pairs include old version functions and new version functions that match each other.

[0274] The second determining module 65 is configured to determine at least one candidate patch function from a plurality of matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version.

[0275] The third determination module 66 is configured to perform fuzz testing on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool, and determine target input data that can trigger the vulnerability of the old version binary program.

[0276] Optionally, the first acquisition module 61 is specifically configured to: use a static disassembler to identify the old version binary program to obtain multiple old version functions and old version static function call relationships; use a static disassembler to identify the new version binary program to obtain multiple new version functions and new version static function call relationships.

[0277] Optionally, the first determination module 63 is specifically used to: use the real function call relationship existing in the old version of the real function call sequence to supplement the old version of the static function call relationship to obtain the old version of the currently restored function call relationship; use the real function call relationship existing in the new version of the real function call sequence to supplement the new version of the static function call relationship to obtain the new version of the currently restored function call relationship.

[0278] Optionally, the matching module 64 is specifically used to: determine the matching information of each old version function based on the calling relationship of the currently restored functions of the old version; determine the matching information of each new version function based on the calling relationship of the currently restored functions of the new version; match multiple old version functions with multiple new version functions based on the matching information of each old version function and the matching information of each new version function to obtain multiple matching function pairs.

[0279] Optionally, the matching module 64 is further specifically used to: match the entry function of the old version binary program with the entry function of the new version binary program to obtain a matching function pair; calculate the matching value between each unmatched old version function and each unmatched new version function based on the matching information of each unmatched old version function and the matching information of each unmatched new version function; determine a pair of unmatched old version functions and unmatched new version functions with the highest matching value as a matching function pair; repeat the steps of calculating the matching value between each unmatched old version function and each unmatched new version function and determining a pair of unmatched old version functions and unmatched new version functions with the highest matching value as a matching function pair, until there are no unmatched old version functions, or until there are no unmatched new version functions, to obtain multiple matching function pairs.

[0280] Optionally, the matching information includes: the number of times the function is called, the number of times the function is called, the number of preset call instruction types when the function is called, the set of main calling functions when the function is called, and whether the calling relationship actually exists. The matching module 64 is further configured to:

[0281] For any pair of unmatched old version functions and unmatched new version functions, the following operations are performed: determine a first matching score based on the number of calls corresponding to the old version function and the new version function respectively; determine a second matching score based on the number of calls initiated corresponding to the old version function and the new version function respectively; determine a third matching score based on the number of preset calling instruction types corresponding to the old version function and the new version function when the calls are initiated; determine a fourth matching score based on the set of main calling functions corresponding to the old version function and the new version function when they are called; determine a fifth matching score based on whether the calling relationship between the old version function and the new version function actually exists; perform weighted sum calculation on the first matching score, the second matching score, the third matching score, the fourth matching score and the fifth matching score according to the corresponding preset weights respectively to obtain the matching value between the unmatched old version function and the unmatched new version function.

[0282] Optionally, the fourth matching score is a first preset value or a second preset value; the first preset value is greater than the second preset value; optionally, the matching module 64 is further specifically used to: in response to the existence of a matching function pair between the main calling function sets corresponding to when the old version function and the new version function are called, determine that the fourth matching score is the first preset value; in response to the absence of a matching function pair between the main calling function sets corresponding to when the old version function and the new version function are called, determine that the fourth matching score is the second preset value.

[0283] Optionally, the fifth matching score is a third preset value or a fourth preset value; the third preset value is greater than the fourth preset value; optionally, the matching module 64 is further specifically used to: in response to the fact that the calling relationship of the old version function exists in the old version real function call sequence, and the calling relationship of the new version function exists in the new version real function call sequence, determine that the fifth matching score is the third preset value; in response to the fact that the calling relationship of the old version function does not exist in the first old version real function call sequence, or the calling relationship of the new version function does not exist in the new version real function call sequence, determine that the fifth matching score is the fourth preset value.

[0284] Optionally, the second determination module 65 is specifically used to: determine the old version called function sequence set of the old version function in each matching function pair based on the currently restored function call relationship of the old version; the old version called function sequence set includes at least one old version called function sequence, and the old version called function sequence is the sequence of functions called by the function call instruction sequence on a program branch in the old version function; determine the new version called function sequence set of the new version function in each matching function pair based on the currently restored function call relationship of the new version; the new version called function sequence set includes at least one new version called function sequence, and the new version called function sequence is the sequence of functions called by the function call instruction sequence on a program branch in the new version function; in response to the fact that the old version called function sequence set of the old version function is different from the new version called function sequence set of the new version function in the matching function pair, the old version function in the matching function pair is determined as a candidate patch function.

[0285] Optionally, the second preset test case pool includes multiple initial test cases, and the initial test cases can be successfully run by the new version binary program and the old version binary program; the third determination module 66 is specifically used to: perform a first traversal on each initial test case, and in the process of the first traversal, perform a first operation once each time an initial test case is traversed; the first operation includes: mutating the initial test case according to a preset mutation time and a preset mutation method to obtain multiple mutated test cases corresponding to the initial test case; using the old version binary program to run each mutated test case, and determine whether each mutated test case is successfully run in the old version binary program; in response to any mutated test case being successfully run in the old version binary program, obtain the old version mutated function call sequence and the old version mutated program execution path in the process of the old version binary program running the mutated test case; using the new version binary program to run each mutated test case, and determine whether each mutated test case is successfully run in the new version. Whether it runs successfully in the binary program; in response to any mutated test case running successfully in the new version of the binary program, obtain the new version mutated function call sequence and the new version mutated program execution path during the new version of the binary program running the mutated test case; in response to any mutated test case running successfully in the old version of the binary program and running successfully in the new version of the binary program, determine the mutated test case as a candidate test case; determine the order of the second traversal of each candidate test case according to the old version mutated program execution path and candidate patch function corresponding to each candidate test case; perform a second traversal on each candidate test case in the order of the second traversal, and in the process of the second traversal, perform a second operation for each candidate test case traversed; the second operation includes: determining whether the candidate test case is the target input data according to the old version mutated function call sequence and the new version mutated function call sequence corresponding to the candidate test case.

[0286] Optionally, the third determination module 66 is further specifically used to: determine the old version of the last function call sequence of the old version of the mutated function call sequence, and determine the new version of the last function call sequence of the new version of the mutated function call sequence; in response to the old version of the last function call sequence being different from the new version of the last function call sequence, determine the candidate test case as the target input data.

[0287] Optionally, the third determining module 66 is further configured to: use a first circular array to record function calls during the process of running the mutated test case in the old version binary program; determine the old version last segment function call sequence of the old version mutated function call sequence, including: determining the function calls recorded in the first circular array as the old version last segment function call sequence in order from the beginning to the end; use the new version binary program to run each mutated test case, including: use a second circular array to record function calls during the process of running the mutated test case in the new version binary program; the second circular array has the same length as the first circular array;

[0288] Determining a new version of the last segment of the function call sequence of the new version of the mutated function call sequence includes: determining the function calls recorded in the second ring array as the new version of the last segment of the function call sequence in order from the beginning to the end.

[0289] Optionally, the third determination module 66 is further specifically used to: calculate the execution distance between the old version of the mutated program execution path corresponding to each candidate test case and each candidate patch function; and determine the order of the second traversal of each candidate test case based on the execution distance between the old version of the mutated program execution path corresponding to each candidate test case and each candidate patch function.

[0290] Optionally, the third determination module 66 is further specifically used to: for an old version mutated program execution path and a candidate patch function, obtain a predecessor function of the candidate patch function on the old version mutated program execution path; the predecessor function exists on the old version mutated program execution path, and is the main calling function of the candidate patch function that is closest to the candidate patch function; calculate a first distance from the entry function of the old version binary program to the predecessor function along the old version mutated program execution path; calculate a second distance from the predecessor function to the candidate patch function; and determine the sum of the first distance and the second distance as the execution distance between the old version mutated program execution path and the candidate patch function.

[0291] Optionally, the third determination module 66 is further specifically used to: for each candidate test case, sum up the execution distances between the old version of the mutated program execution path and each candidate patch function to obtain the candidate distance corresponding to each candidate test case; and determine the order of the corresponding candidate distances from small to large as the order for the second traversal of each candidate test case.

[0292] Optionally, the third determination module 66 is further specifically used to: obtain the old version initial program execution path corresponding to each initial test case; determine the order of performing the first traversal of each initial test case based on the old version initial program execution path corresponding to each initial test case and each candidate patch function; perform the first traversal of each initial test case, including: performing the first traversal of each initial test case in the order of performing the first traversal of each initial test case.

[0293] Optionally, the third determination module 66 is further specifically used to: for any mutated test case that runs successfully in the old version binary program, perform the following operations: determine whether the execution path of the old version mutated program triggers new code coverage of the old version binary program; in response to the execution path of the old version mutated program triggering new code coverage of the old version binary program, add the mutated test case as an initial test case to the second preset test case pool.

[0294] Optionally, the third determination module 66 is further specifically used to: for any post-mutation test case that runs successfully in the old version binary program, perform the following operations: determine whether there is an old version new function call relationship in the old version post-mutation function call sequence that does not exist in the old version currently restored function call relationship; in response to the existence of an old version new function call relationship in the old version post-mutation function call sequence, add the post-mutation test case as an initial test case to the second preset test case pool.

[0295] Optionally, the third determining module 66 is further configured to: in response to the existence of an old version-new function calling relationship in the old version mutated function calling sequence, use the old version-new function calling relationship to supplement the currently restored old version function calling relationship.

[0296] Optionally, the third determination module 66 is further specifically used to: for any post-mutation test case that runs successfully in the new version of the binary program, perform the following operations: determine whether the execution path of the new version of the mutated program triggers new code coverage of the new version of the binary program; in response to the execution path of the new version of the mutated program triggering new code coverage of the new version of the binary program, add the post-mutation test case as an initial test case to the second preset test case pool.

[0297] Optionally, the third determination module 66 is also specifically used to: for any post-mutation test case that runs successfully in the new version of the binary program, perform the following operations: determine whether there is a new version new function call relationship in the new version post-mutation function call sequence that does not exist in the new version currently restored function call relationship; in response to the existence of a new version new function call relationship in the new version post-mutation function call sequence, add the post-mutation test case as an initial test case to the second preset test case pool.

[0298] Optionally, the third determining module 66 is further configured to: in response to the existence of a new version new function calling relationship in the new version mutated function calling sequence, supplement the currently restored function calling relationship of the new version with the new version new function calling relationship.

[0299] Optionally, the third determination module 66 is further specifically used to: repeatedly execute the steps of matching multiple old version functions with multiple new version functions according to the old version's currently restored function call relationship and the new version's currently restored function call relationship to obtain multiple matching function pairs, determining at least one candidate patch function from multiple matched old version functions according to the old version's currently restored function call relationship and the new version's currently restored function call relationship, and performing a first traversal on each initial test case, and during the first traversal, executing the first operation once for each initial test case traversed, until the end condition of the fuzz test is met.

[0300] The device for reproducing input data that triggers a software vulnerability provided in this embodiment can execute the method for reproducing input data that triggers a software vulnerability provided in any of the above embodiments. The specific implementation method and principle are similar and will not be repeated here.

[0301] Example 8

[0302] FIG7 is a schematic diagram of the structure of an electronic device according to an eighth embodiment of the present application. As shown in FIG7 , the electronic device 70 provided in this embodiment includes: a processor 72 and a memory 71 in communication with the processor 72 .

[0303] The memory 71 stores computer-executable instructions.

[0304] The processor 72 executes the computer execution instructions stored in the memory 71 to implement the method for reproducing the input data that triggers the software vulnerability provided by any of the above embodiments. The specific implementation method and principle are similar and will not be repeated here.

[0305] Optionally, the electronic device 70 further includes a transceiver. The transceiver is used to transmit and receive data. The transceiver, the memory, and the processor are interconnected.

[0306] The memory, processor, and transceiver can communicate and interconnect circuits via a bus. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, Figure 7 shows only one thick line, but this does not imply a single bus or type of bus.

[0307] The memory 71 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk, etc.

[0308] In an exemplary embodiment, the electronic device 70 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the above-mentioned method for reproducing input data that triggers software vulnerabilities.

[0309] Embodiments of the present application also provide a computer-readable storage medium storing computer-executable instructions. When executed by a processor, the computer-executable instructions are used to implement the method for reproducing input data that triggers a software vulnerability as provided in any of the above embodiments. The specific implementation method and principle are similar and will not be repeated here. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic tape, a floppy disk, an optical data storage device, or the like.

[0310] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the method for reproducing input data that triggers a software vulnerability provided by any of the above embodiments. The specific implementation method and principle are similar and will not be repeated here.

[0311] An embodiment of the present application further provides a computer program that, when executed by a processor, implements the method for reproducing input data that triggers a software vulnerability provided by any of the above embodiments. The specific implementation method and principle are similar and will not be repeated here.

[0312] An embodiment of the present application also provides a computer program stored on a computer-readable storage medium. When the computer program is executed by a processor, it implements the method for reproducing the input data that triggers the software vulnerability provided by any of the above embodiments. The specific implementation method is similar to the principle and will not be repeated here.

[0313] It should be understood that the above-mentioned device embodiments are merely illustrative, and the device of the present application may also be implemented in other ways. For example, the division of modules in the above-mentioned embodiments is merely a logical function division, and there may be other division methods in actual implementation. For example, multiple modules may be combined, or may be integrated into another system, or some features may be ignored or not executed. In addition, unless otherwise specified, the various functional modules in the various embodiments of the present application may be integrated into one module, or each module may exist physically separately, or two or more modules may be integrated together. The above-mentioned integrated modules may be implemented in the form of hardware or in the form of software program modules.

[0314] It should be noted that, for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application. Although the various steps in the flowchart are displayed in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be performed in other orders. Moreover, at least some of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these sub-steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0315] In this document, step codes such as 201, 202, 203a, and 203b are used for the purpose of expressing the corresponding content more clearly and concisely, and do not constitute a substantial limitation on the sequence. When implementing the steps, those skilled in the art may execute step 201 first and then step 202, or execute step 203a and step 203b at the same time, etc., but these should all be within the scope of protection of this application.

[0316] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0317] It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A method for reproducing input data that triggers a software vulnerability, characterized in that: include: Obtaining a plurality of old version functions and old version static function call relationships included in an old version binary program of the target software before the vulnerability is patched, and obtaining a plurality of new version functions and new version static function call relationships included in a new version binary program of the target software after the vulnerability is patched; Obtaining an old version of a real function call sequence of the old version of the binary program during the process of running the first test case, and obtaining a new version of a real function call sequence of the new version of the binary program during the process of running the first test case; The first test case belongs to a first preset test case pool; Determine the currently restored function call relationship of the old version according to the old version static function call relationship and the old version real function call series, and determine the currently restored function call relationship of the new version according to the new version static function call relationship and the new version real function call sequence; According to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version, a plurality of old version functions are matched with a plurality of new version functions to obtain a plurality of matching function pairs; the matching function pairs include the old version functions and the new version functions that match each other; Determine at least one candidate patch function from a plurality of matched old version functions according to the old version currently restored function call relationship and the new version currently restored function call relationship; According to each candidate patch function and the second preset test case pool, fuzz testing is performed on the old version binary program and the new version binary program to determine target input data that can trigger the vulnerability of the old version binary program.

2. The method according to claim 1, characterized in that: The obtaining of the calling relationships of multiple old version functions and old version static functions included in the old version binary program of the target software before the vulnerability is patched includes: Using a static disassembler to identify the old version binary program, and obtaining a plurality of old version functions and the old version static function call relationships; The obtaining of the multiple new version functions and new version static function call relationships included in the new version binary program of the target software after the vulnerability is patched includes: The new version binary program is identified by using a static disassembler to obtain a plurality of new version functions and the calling relationship between the new version static functions.

3. The method according to claim 1 or 2, characterized in that: The step of determining the currently restored function call relationship of the old version according to the old version static function call relationship and the old version real function call series includes: The real function calling relationship existing in the real function calling sequence of the old version is used to supplement the static function calling relationship of the old version to obtain the currently restored function calling relationship of the old version; Determining the currently restored function call relationship of the new version according to the new version static function call relationship and the new version real function call sequence includes: The new version static function call relationship is supplemented by the real function call relationship existing in the new version real function call sequence to obtain the currently restored function call relationship of the new version.

4. The method according to any one of claims 1 to 3, characterized in that: The step of matching a plurality of old version functions with a plurality of new version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version to obtain a plurality of matching function pairs includes: According to the calling relationship of the currently restored functions of the old version, matching information of each old version function is determined; According to the calling relationship of the functions currently restored in the new version, the matching information of each new version function is determined; According to the matching information of each old version function and the matching information of each new version function, a plurality of old version functions are matched with a plurality of new version functions to obtain a plurality of matching function pairs.

5. The method according to claim 4, characterized in that The method of matching multiple old version functions with multiple new version functions according to the matching information of each old version function and the matching information of each new version function to obtain multiple matching function pairs includes: Matching the entry function of the old version binary program with the entry function of the new version binary program to obtain a matching function pair; According to the matching information of each unmatched old version function and the matching information of each unmatched new version function, a matching value between each unmatched old version function and each unmatched new version function is calculated; A pair of unmatched old version functions and unmatched new version functions with the highest matching value is determined as a matching function pair; Repeat the steps of calculating the matching value between each unmatched old version function and each unmatched new version function and determining a pair of unmatched old version functions and unmatched new version functions with the highest matching value as a matching function pair until there are no unmatched old version functions, or until there are no unmatched new version functions, to obtain multiple matching function pairs.

6. The method according to claim 5, characterized in that The matching information includes: the number of times the call is made, the number of times the call is made, the number of preset call instruction types when the call is made, the set of main calling functions when the call is made, and whether the call relationship actually exists; The calculating, according to the matching information of each unmatched old version function and the matching information of each unmatched new version function, a matching value between each unmatched old version function and each unmatched new version function includes: For any pair of unmatched old-version functions and unmatched new-version functions, do the following: Determine a first matching score according to the number of calls of the old version function and the number of calls of the new version function respectively; Determine a second matching score according to the number of initiation calls corresponding to the old version function and the new version function respectively; Determine a third matching score according to the number of preset call instruction types corresponding to the old version function and the new version function when initiating calls respectively; Determine a fourth matching score according to a set of main calling functions corresponding to when the old version function and the new version function are called; Determine a fifth matching score according to whether the calling relationship between the old version function and the new version function actually exists; The first matching score, the second matching score, the third matching score, the fourth matching score and the fifth matching score are weighted and summed according to the corresponding preset weights to obtain a matching value between the unmatched old version function and the unmatched new version function.

7. The method according to claim 6, characterized in that The fourth matching score is the first preset value or the second preset value; the first preset value is greater than the second preset value; The determining of the fourth matching score according to the main calling function sets corresponding to the old version function and the new version function when they are called includes: In response to the existence of a matching function pair between the main calling function sets corresponding to the old version function and the new version function when they are called, determining that the fourth matching score is a first preset value; In response to the fact that there is no matching function pair between the main calling function sets corresponding to the old version function and the new version function when they are called, the fourth matching score is determined to be a second preset value.

8. The method according to claim 6 or 7, characterized in that: The fifth matching score is the third preset value or the fourth preset value; the third preset value is greater than the fourth preset value; The determining of the fifth matching score according to whether the calling relationship between the old version function and the new version function actually exists includes: In response to the fact that the calling relationship of the old version function exists in the old version real function calling sequence, and the calling relationship of the new version function exists in the new version real function calling sequence, determining that the fifth matching score is the third preset value; In response to the fact that the calling relationship of the old version function does not exist in the first old version real function calling sequence, or the calling relationship of the new version function does not exist in the new version real function calling sequence, the fifth matching score is determined to be the fourth preset value.

9. The method according to any one of claims 1 to 8, characterized in that: The step of determining at least one candidate patch function from a plurality of matched old version functions according to the old version currently restored function call relationship and the new version currently restored function call relationship comprises: Determine, according to the old version currently restored function call relationship, an old version called function sequence set of the old version function in each matching function pair; the old version called function sequence set includes at least one old version called function sequence, and the old version called function sequence is a sequence of functions called by a function call instruction sequence on a program branch in the old version function; Determine a set of new version called function sequences of the new version function in each matching function pair according to the new version currently restored function call relationship; the set of new version called function sequences includes at least one new version called function sequence, and the new version called function sequence is a sequence of functions called by a function call instruction sequence on a program branch in the new version function; In response to the difference between the old version called function sequence set of the old version function and the new version called function sequence set of the new version function in the matching function pair, the old version function in the matching function pair is determined as a candidate patch function.

10. The method according to any one of claims 1 to 9, characterized in that: The second preset test case pool includes a plurality of initial test cases, and the initial test cases can be successfully run by the new version binary program and the old version binary program; The step of performing fuzz testing on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool to determine target input data that can trigger the vulnerability of the old version binary program includes: Performing a first traversal on each initial test case, and during the first traversal, performing a first operation once for each initial test case traversed; The first operation includes: Mutate the initial test case according to a preset mutation time and a preset mutation method to obtain multiple mutated test cases corresponding to the initial test case; Using the old version binary program to run each of the mutated test cases, and determining whether each of the mutated test cases runs successfully in the old version binary program; In response to any of the mutated test cases being successfully run in the old version binary program, obtaining an old version mutated function call sequence and an old version mutated program execution path during the process of the old version binary program running the mutated test case; Run each of the mutated test cases using the new version of the binary program to determine whether each of the mutated test cases runs successfully in the new version of the binary program; In response to any of the mutated test cases being successfully run in the new version of the binary program, a new version of the mutated function call sequence and a new version of the mutated program are obtained during the process of the new version of the binary program running the mutated test case. Execution path; In response to any of the mutated test cases being successfully run in the old version of the binary program and being successfully run in the new version of the binary program, determining the mutated test case as a candidate test case; Determine the order of performing a second traversal on each of the candidate test cases according to the old version mutated program execution path and the candidate patch function corresponding to each of the candidate test cases; Perform a second traversal on each of the candidate test cases in the order in which the second traversal is performed on each of the candidate test cases, and during the second traversal, perform a second operation each time a candidate test case is traversed; The second operation includes: According to the old version mutated function call sequence and the new version mutated function call sequence corresponding to the candidate test case, it is determined whether the candidate test case is the target input data.

11. The method according to claim 10, characterized in that The determining whether the candidate test case is the target input data according to the old version mutated function call sequence and the new version mutated function call sequence corresponding to the candidate test case includes: Determine an old version of the last function call sequence of the old version of the mutated function call sequence, and determine a new version of the last function call sequence of the new version of the mutated function call sequence; In response to the old version final function call sequence being different from the new version final function call sequence, determining the candidate test case as the target input data.

12. The method according to claim 11, characterized in that The step of running each of the mutated test cases using the old version binary program includes: Using a first circular array to record function calls during the process of the old version binary program running the mutated test case; The determining of the old version last segment function call sequence of the old version mutated function call sequence comprises: Determine the function calls recorded in the first ring array as the old version last segment function call sequence in order from the beginning to the end; The step of running each of the mutated test cases using the new version of the binary program includes: A second circular array is used to record function calls during the process of the new version of the binary program running the mutated test case; the second circular array has the same length as the first circular array; The step of determining the new version of the last segment of the function call sequence of the new version of the mutated function call sequence comprises: The function calls recorded in the second ring array are determined as the new version last segment function call sequence in order from the beginning to the end.

13. The method according to any one of claims 10 to 12, characterized in that: The determining the order of performing a second traversal on each of the candidate test cases according to the old version mutated program execution path and the candidate patch function corresponding to each of the candidate test cases includes: Calculate the execution distance between the old version of the mutated program execution path corresponding to each candidate test case and each candidate patch function; The order of performing the second traversal on each of the candidate test cases is determined according to the execution distance between the old version mutated program execution path corresponding to each of the candidate test cases and each of the candidate patch functions.

14. The method according to claim 13, characterized in that The step of calculating the execution distance between the old version mutated program execution path corresponding to each candidate test case and each candidate patch function includes: For an old version mutated program execution path and a candidate patch function, obtain a predecessor function of the candidate patch function on the old version mutated program execution path; the predecessor function exists on the old version mutated program execution path and is the main calling function of the candidate patch function that is closest to the candidate patch function; Calculate a first distance from the entry function of the old version binary program to the predecessor function according to the execution path of the old version mutated program; calculating a second distance from the execution of the predecessor function to the candidate patch function; The sum of the first distance and the second distance is determined as the execution distance between the old version mutated program execution path and the candidate patch function.

15. The method according to claim 13 or 14, characterized in that The determining the order of performing the second traversal on each of the candidate test cases according to the execution distance between the old version mutated program execution path corresponding to each of the candidate test cases and each of the candidate patch functions comprises: For each candidate test case, the execution distances between the old version mutated program execution path and each candidate patch function are summed up and calculated to obtain a candidate distance corresponding to each candidate test case; The order of corresponding candidate distances from small to large is determined as the order of performing a second traversal on each of the candidate test cases.

16. The method according to any one of claims 10 to 15, characterized in that: The first traversal of each initial test case and, during the first traversal, before each traversal to an initial test case and performing a first operation, further includes: Obtaining the old version of the initial program execution path corresponding to each of the initial test cases; Determine the order of performing a first traversal on each of the initial test cases according to the old version initial program execution path corresponding to each of the initial test cases and each of the candidate patch functions; The first traversal of each initial test case includes: The initial test cases are first traversed in the order in which the initial test cases are first traversed.

17. The method according to any one of claims 10 to 16, characterized in that: In response to any of the mutated test cases being successfully run in the old version binary program, after obtaining the old version mutated function call sequence and the old version mutated program execution path in the process of the old version binary program running the mutated test case, the method further includes: For any post-mutation test cases that successfully run on the old binary, do the following: Determining whether the old version mutated program execution path triggers new code coverage of the old version binary program; In response to the old version mutated program execution path triggering new code coverage of the old version binary program, the mutated test case is added as an initial test case to the second preset test case pool.

18. The method according to any one of claims 10 to 17, characterized in that: In response to any of the mutated test cases being successfully run in the old version binary program, after obtaining the old version mutated function call sequence and the old version mutated program execution path in the process of the old version binary program running the mutated test case, the method further includes: For any post-mutation test cases that successfully run on the old binary, do the following: Determine whether there is a new function call relationship of the old version that does not exist in the currently restored function call relationship of the old version in the function call sequence after the old version is mutated; In response to the existence of the old version new function call relationship in the old version mutated function call sequence, the mutated test case is added as an initial test case to the second preset test case pool.

19. The method according to claim 18, characterized in that After determining whether there is an old version new function call relationship in the old version mutated function call sequence that does not exist in the old version currently restored function call relationship, the method further includes: In response to the existence of the old version new function calling relationship in the old version mutated function calling sequence, the old version new function calling relationship is used to supplement the old version currently restored function calling relationship.

20. The method according to any one of claims 10 to 19, characterized in that: In response to any of the mutated test cases being successfully run in the new version of the binary program, after obtaining the new version of the mutated function call sequence and the new version of the mutated program execution path in the process of the new version of the binary program running the mutated test case, the method further includes: For any mutated test case that runs successfully on the new version of the binary, do the following: Determining whether the execution path of the new version of the mutated program triggers new code coverage of the new version of the binary program; In response to the new version of the mutated program execution path triggering new code coverage of the new version of the binary program, the mutated test case is added as an initial test case to the second preset test case pool.

21. The method according to any one of claims 10 to 20, characterized in that: In response to any of the mutated test cases being successfully run in the new version of the binary program, after obtaining the new version of the mutated function call sequence and the new version of the mutated program execution path in the process of the new version of the binary program running the mutated test case, the method further includes: For any mutated test case that runs successfully on the new version of the binary, do the following: Determine whether there is a new version new function call relationship that does not exist in the new version currently restored function call relationship in the new version in the function call sequence after the new version is mutated; In response to the existence of the new version new function call relationship in the new version mutated function call sequence, the mutated test case is added as an initial test case to the second preset test case pool.

22. The method according to claim 21, characterized in that After determining whether there is a new version new function call relationship in the new version mutated function call sequence that does not exist in the new version currently restored function call relationship, the method further includes: In response to the new version new function calling relationship existing in the new version mutated function calling sequence, the new version new function calling relationship is used to supplement the currently restored function calling relationship of the new version.

23. The method according to claim 19 or 22, characterized in that The first traversal of each initial test case and during the first traversal, after performing a first operation once for each initial test case traversed, further includes: Repeat the steps of matching multiple old version functions with multiple new version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version to obtain multiple matching function pairs, the step of determining at least one candidate patch function from multiple matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version, and the step of performing a first traversal on each initial test case and executing the first operation once for each initial test case traversed during the first traversal until the end condition of the fuzz test is met.

24. A device for reproducing input data that triggers a software vulnerability, comprising: A first acquisition module is used to acquire a plurality of old version functions and old version static function call relationships included in an old version binary program of the target software before the vulnerability is patched, and to acquire a plurality of new version functions and new version static function call relationships included in a new version binary program of the target software after the vulnerability is patched; The second acquisition module is used to obtain the old version of the binary program in the process of running the first test case. A real function call sequence, and obtaining a new version of the real function call sequence of the new version of the binary program during the process of running the first test case; The first test case belongs to a first preset test case pool; A first determination module is used to determine the currently restored function call relationship of the old version according to the old version static function call relationship and the old version real function call series, and to determine the currently restored function call relationship of the new version according to the new version static function call relationship and the new version real function call sequence; A matching module, used for matching a plurality of old version functions with a plurality of new version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version, to obtain a plurality of matching function pairs; the matching function pairs include the old version function and the new version function that match each other; A second determination module is used to determine at least one candidate patch function from a plurality of matched old version functions according to the calling relationship of the currently restored function of the old version and the calling relationship of the currently restored function of the new version; The third determination module is used to perform fuzz testing on the old version binary program and the new version binary program according to each candidate patch function and the second preset test case pool, and determine the target input data that can trigger the vulnerability of the old version binary program.

25. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 23.

26. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 23 when executed by a processor.

27. A computer program product, characterized in that The invention comprises a computer program which, when executed by a processor, implements the method according to any one of claims 1 to 23.

28. A computer program, characterized in that include: When the computer program is executed by a processor, the method according to any one of claims 1 to 23 is implemented.

29. A computer program stored on a computer-readable storage medium, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 23 is implemented.

Images