Patch Presence Testing Methods, Apparatus, Electronic Devices, and Storage Media

Abstract

This application relates to the technical field of software update, specifically to a method, apparatus, electronic device, and storage medium for patch existence testing. The method includes: acquiring static and dynamic features of the source code to be tested; the static features include at least one feature determined during the compilation of the source code; the dynamic features include at least one feature determined during the runtime of the program corresponding to the source code; determining the semantic similarity between a first function corresponding to the static and dynamic features and a second function corresponding to the patch in the initial source code before and after the patch; if the semantic similarity is greater than a preset threshold, then the source code to be tested is patched. Thus, analysis can be performed based on dynamic and static features, providing a more comprehensive analysis of whether the source code is patched, and the detection results are more accurate.

Description

Technical Field

[0001] This application relates to the technical field of software update, specifically to a patch existence testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Many downstream vendors use open-source kernels in their own programs. Open-source projects often contain a large number of vulnerabilities. Therefore, the source code of open-source projects may be patched later. At this time, programs that use the open-source kernel also need to be patched in a timely manner to prevent attacks.

[0003] In order to patch the source code in a timely manner while avoiding duplicate patching, a method is needed to confirm whether the source code has been patched. Summary of the Invention

[0004] In view of this, embodiments of this application aim to provide a patch presence testing method, apparatus, electronic device, and storage medium for confirming whether the kernel has been patched.

[0005] According to a first aspect of the embodiments of this application, a patch existence testing method is provided, comprising:

[0006] Obtain the static and dynamic characteristics of the source code to be tested;

[0007] Static features include: features of at least one first function determined during the compilation of the source code to be tested; dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein, the first function is the function corresponding to the patch in the source code to be tested;

[0008] Determine the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch;

[0009] If the semantic similarity is greater than a preset threshold, then the source code to be tested is source code with patches.

[0010] In one embodiment, determining the semantic similarity between the first function corresponding to the static feature and the dynamic feature and the second function corresponding to the patch in the initial source code before and after the patch includes:

[0011] The similarity of each feature in the static and dynamic features is determined. Based on the similarity, a preset deep learning algorithm is used to calculate the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch.

[0012] In one embodiment, the similarity of each feature among the static and dynamic features is determined. Based on this similarity, a preset deep learning algorithm is used to calculate the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch, including:

[0013] Based on the Minkowski distance algorithm, the similarity of each feature in the static and dynamic features is determined; where the similarity is used to characterize each feature, compared with the feature corresponding to the initial source code before patching and the feature corresponding to the initial source code after patching.

[0014] The similarity scores are input into a preset neural network module, which then determines the semantic similarity between the first function and the second function corresponding to the patch in the initial source code before and after the patch, based on the various similarity scores.

[0015] In one embodiment, obtaining the static and dynamic characteristics of the source code to be tested includes:

[0016] Compile the source code to be tested and identify the first function in the compiled source code;

[0017] Extract the features of the first function to obtain static features; wherein, the features of the first function include at least one of the following: the number of instructions within the function, the number of strings, the size of static variables, the maximum number of instructions in the basic block, the minimum number of instructions in the basic block, the maximum size of the basic block, and the minimum size of the basic block.

[0018] Determine the path in the first function;

[0019] Extract the characteristics of the path in the first function when the program corresponding to the source code to be tested is run, and obtain the dynamic characteristics; wherein, the characteristics of the path in the first function include at least one of the following: instruction quantity characteristics, system-level information characteristics, function and system call characteristics.

[0020] In one embodiment, determining the first function in the compiled source code to be tested includes:

[0021] Identify the functions affected by patches in the compiled source code to be tested;

[0022] Among them, the patch-affected function is the first function; the patch-affected function includes: the function containing the content modified after the patch is applied;

[0023] Determine the path in the first function during program execution, including:

[0024] Determine the affected paths of patches in the compiled source code to be tested;

[0025] Among them, the patch-affected path is the path in the first function; the patch-affected path includes: the path of the basic block affected by the patch; the patch-affected basic block is the basic block affected by the content modified after the patch is applied.

[0026] In one embodiment, determining the functions affected by the patch in the compiled source code to be tested includes:

[0027] Compile the source code to be tested with debugging information to obtain the corresponding symbol table;

[0028] Based on the patch information, determine the keys affected by the patch information;

[0029] Based on the key, the affected functions of the patch are determined by looking up the symbol table.

[0030] In one embodiment, determining the patch-affected paths in the compiled source code to be tested includes:

[0031] In the function that determines the impact of a patch, the patch impact basic block is defined to determine how modifications made after applying the patch affect the patch's impact.

[0032] The nearest necessary node from the basic block affected by the patch to the function exit is identified as the anchor point.

[0033] The path that starts from the entry point of the patch-affected function, passes through the patch-affected basic block, and ends at the anchor point is defined as the patch-affected path, where the patch-affected path is the path in the first function.

[0034] In one embodiment, it also includes:

[0035] Obtain a preset number of similarity sample groups and the identifier corresponding to each similarity sample group as training samples;

[0036] The identifier is used to indicate whether the source code corresponding to the similarity sample group has a patch; the preset number of similarity sample groups includes: similarity sample groups corresponding to source code with patches and similarity sample groups corresponding to source code without patches;

[0037] Training samples are input into a pre-built neural network model for training, resulting in a neural network module.

[0038] According to a second aspect of the embodiments of this application, a patch presence testing apparatus is provided, comprising:

[0039] The acquisition module is used to acquire the static and dynamic features of the source code to be tested;

[0040] Static features include: features of at least one first function determined during the compilation of the source code to be tested; dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein the first function is a function in the source code to be tested.

[0041] The first determining module is used to determine the semantic similarity between the first function corresponding to the static features and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch;

[0042] The second determination module determines that the source code to be tested is a source code with a patch if the semantic similarity is greater than a preset threshold.

[0043] According to a third aspect of the embodiments of this application, an electronic device is provided, comprising:

[0044] processor;

[0045] Memory used to store processor-executable instructions;

[0046] The processor is used for the patch presence testing method described above.

[0047] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which computer program instructions are stored, which, when executed by a processor, cause the processor to perform the above-described patch existence test method.

[0048] An embodiment of this application provides a patch existence testing method, comprising: acquiring static and dynamic features of the source code to be tested; the static features include: features of at least one first function determined during the compilation of the source code to be tested; the dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein, the first function is the function corresponding to the patch in the source code to be tested; determining the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch; if the semantic similarity is greater than a preset threshold, then the source code to be tested is a source code with a patch. This setup allows for analysis based on both dynamic and static features, comprehensively considering both to determine whether the source code has been patched. Compared to methods that only consider static features, this approach provides a more comprehensive analysis of whether the source code has been patched, and the results obtained are more accurate. Attached Figure Description

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0050] Figure 1 This is a schematic flowchart of a patch existence test method provided in an embodiment of this application;

[0051] Figure 2 This is a partial flowchart illustrating a patch existence testing method provided in an embodiment of this application.

[0052] Figure 3 This is a partial flowchart illustrating a patch existence testing method provided in an embodiment of this application.

[0053] Figure 4 This is a partial flowchart illustrating a patch existence testing method provided in an embodiment of this application.

[0054] Figure 5 This is a partial flowchart illustrating a patch existence testing method provided in an embodiment of this application.

[0055] Figure 6 This is a partial flowchart illustrating a patch existence testing method provided in an embodiment of this application.

[0056] Figure 7 A schematic diagram of the structure of a patch presence testing device provided in an embodiment of this application;

[0057] Figure 8 This is a schematic diagram of an electronic device structure provided for another embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0059] Application Overview

[0060] Many downstream vendors use open-source kernels in their own programs. Open-source projects often contain a large number of vulnerabilities. Therefore, the source code of open-source projects may be patched later. At this time, programs that use the open-source kernel also need to be patched in a timely manner to prevent attacks.

[0061] In order to patch the source code in a timely manner while avoiding duplicate patching, a method is needed to confirm whether the source code has been patched.

[0062] To address the aforementioned issues, embodiments of this application provide a patch existence testing method, comprising: acquiring static and dynamic features of the source code to be tested; the static features include: features of at least one first function determined during the compilation of the source code to be tested; the dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein the first function is a function in the source code to be tested. The semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch is determined; if the semantic similarity is greater than a preset threshold, then the source code to be tested is a patched source code. This setup allows for analysis based on both dynamic and static features, comprehensively considering both to determine whether the source code has been patched. Compared to methods that only consider static features, this provides a more comprehensive analysis of whether the source code has been patched, and the results obtained are more accurate.

[0063] Having introduced the basic principles of this application, various non-limiting embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0064] Exemplary methods

[0065] Figure 1 A schematic flowchart of a patch existence testing method provided in an embodiment of this application; see reference Figure 1 Patch existence testing methods include:

[0066] S101, Obtain the static and dynamic features of the source code to be tested;

[0067] It should be noted that static features include: features of at least one first function determined during the compilation of the source code to be tested; dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein, the first function is the function corresponding to the patch in the source code to be tested; in practical applications, the static and dynamic features can be obtained by the user directly uploading based on the client, or by obtaining the source code to be tested provided by the user, and then obtaining the static and dynamic features based on the source code to be tested, and this application does not restrict this.

[0068] S102, determine the semantic similarity between the first function corresponding to the static features and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch;

[0069] It should be noted that in practical applications, program vendors can apply open-source kernels to their own developed programs. However, some open-source kernels are constantly updated. After an open-source kernel patch is released, the program vendor needs to check whether the open-source kernel portion of their developed program has been patched. In this case, the source code of the downstream vendor's program is the source code to be tested, the source code corresponding to the open-source kernel is the initial source code, the source code corresponding to the open-source kernel before patching is the pre-patch initial source code, and the source code corresponding to the open-source kernel after patching is the post-patch initial source code. Furthermore, a source code can be considered as consisting of multiple functions. Compiling the source code to be tested yields the functions that constitute the source code. For the source code to be tested, some of its functions are related to the open-source kernel, while others are not; that is, some functions are related to the patch, and others are not. In this application, the first function is the patch-related function in the source code to be tested. Correspondingly, for the initial source code, all its functions can be considered patch-related. Therefore, the second function can be all the functions in the initial source code. With this setup, there is a corresponding relationship between the second functions, which makes the following comparison easier.

[0070] It's important to emphasize that the concept of "related" in patch-related functions is somewhat vague. To more accurately determine the impact of a patch, and then, by checking whether these impacts have occurred, to determine whether the source code under test needs to be patched, we can define patch-related functions as patch-affecting functions. The process of determining patch-affecting functions will be described in detail below. It should be noted that the impact of a patch will be reflected in the static and dynamic characteristics of the obtained source code under test.

[0071] S103, if the semantic similarity is greater than the preset threshold, then the source code to be tested is the source code with a patch.

[0072] If the semantic similarity is greater than a preset threshold, it means that the source code to be tested is closer to the initial source code after the patch than to the initial source code before the patch. It can be considered that the source code to be tested at this time is the source code with the patch.

[0073] This setup allows for analysis based on both dynamic and static features, taking both into account to determine whether the source code under test has been patched. Compared to methods that only consider static features, this approach provides a more comprehensive analysis of whether the source code has been patched, resulting in more accurate analysis results.

[0074] Furthermore, refer to Figure 2 "Obtaining the static and dynamic characteristics of the source code to be tested" specifically includes:

[0075] S201, Compile the source code to be tested and determine the first function in the compiled source code to be tested;

[0076] It should be noted that the source code to be tested includes the initial source code and the source code added by the customer. Based on this, when determining the first function, it is necessary to identify the function related to the initial source code as the first function; thereby enabling a comparison between the "functions related to the initial source code in the source code to be tested" and the "corresponding functions in the initial source code".

[0077] Specifically, the source code to be tested can be compiled using a preset compilation tool to obtain the compiled file and symbol table of the source code to be tested; the initial source code can be compiled to obtain the compiled file and symbol table corresponding to the initial source code; by comparing the compiled file and symbol table of the initial source code, the part related to the initial source code can be found in the compiled file and symbol table of the source code to be tested, that is, the first function can be found.

[0078] S202, extract the features of the first function to obtain the static features;

[0079] Specifically, the characteristics of the first function include at least one of the following: the number of instructions within the function, the number of strings, the size of static variables, the maximum number of instructions in the basic block, the minimum number of instructions in the basic block, the maximum size of the basic block, and the minimum size of the basic block.

[0080] In practical applications, the specific method for extracting features from the first function is as follows: using pre-set software, information corresponding to the features to be extracted from the first function is collected. It should be noted that in practical applications, the more comprehensive the extracted static features, the better the detection effect; therefore, the extracted features should be as comprehensive as possible.

[0081] S203, determine the path in the first function;

[0082] Specifically, the link paths of the various basic blocks within the first function are determined as follows: In the first function, the path refers to the compiled file corresponding to the source code to be tested; find the basic block corresponding to the first function, and then find the link paths of the basic blocks.

[0083] S204: Extract the path characteristics in the first function during the runtime of the program corresponding to the source code to be tested, and obtain the dynamic characteristics.

[0084] Specifically, the features of the path in the first function include at least one of the following: instruction quantity features, system-level information features, function and system call features. It should be noted that in practical applications, the more comprehensive the extracted dynamic features, the better the detection effect; therefore, the extracted features should be as comprehensive as possible. In practical applications, the specific method for extracting the features of the path in the first function is as follows: information corresponding to the features to be extracted from the path in the first function is collected using pre-set software.

[0085] It should be noted that if too many features are extracted, the detection speed will be greatly reduced, affecting the user experience. Based on this, the solution provided in this application can further simplify the first function, that is, to more accurately determine the patch influence function as the first function.

[0086] Specifically, the method for determining the first function in the compiled source code to be tested is as follows:

[0087] Identify the functions affected by patches in the compiled source code to be tested;

[0088] Among them, the patch-affected function is the first function; the patch-affected function includes: the function containing the content modified after the patch is applied;

[0089] Specifically, refer to Figure 3 The specific process of determining the affected functions of the patch in the compiled source code to be tested includes:

[0090] S301, compile the source code to be tested with debugging information to obtain the corresponding symbol table;

[0091] When performing step S301, the source code to be tested can be compiled with debugging information based on the preset compilation software to obtain the corresponding compiled file and symbol table.

[0092] It should be noted that a symbol table is a data structure that stores key-value pairs; it is an abstract data type that supports both insertion and lookup operations. In the solution provided in this application, to determine the functions affected by the patch, the source code to be tested is first compiled with debugging information to obtain the symbol table. Then, further analysis is performed based on the symbol table to determine the functions affected by the patch. The specific process is as follows:

[0093] S302, Based on patch information, determine the keys affected by the patch information;

[0094] Specifically, the key affected by the patch information can be determined as follows: First, compile the initial source code before the patch using a pre-defined compiler to obtain the corresponding compiled files and symbol tables. Second, compile the initial source code after the patch using the same pre-defined compiler to obtain the corresponding compiled files and symbol tables. Third, compare the compiled files and symbol tables corresponding to the initial source code before and after the patch to determine the changed keys, i.e., determine the keys affected by the patch information.

[0095] It should be noted that patch information can be pre-entered or determined based on pre-entered initial source code before and after patching. Based on the patch information, the keys affected by the patch are determined, thus providing a basis for subsequent symbol table lookups.

[0096] S303, based on keys, determines the affected functions of a patch by looking up the symbol table.

[0097] Specifically, using pre-defined compilation software, the system searches the symbol table corresponding to the source code under test based on the keys affected by the patch information to determine the functions affected by the patch.

[0098] It should be noted that there are various ways to look up the symbol table, which will not be elaborated here. The core of the solution provided in this application is to determine the patch effect function based on looking up the symbol table, so as to avoid introducing too many quantities unrelated to the patch in subsequent calculations, reduce the amount of data to be analyzed, and improve the efficiency of analysis.

[0099] Correspondingly, the process of determining the path in the first function is as follows:

[0100] Determine the patch-affected paths in the compiled source code to be tested; these paths are defined as paths within the first function; they include paths that pass through the patch-affected basic blocks; and the patch-affected basic blocks are those affected by the modifications made after the patching. This setup makes the acquired dynamic features more relevant to the patches.

[0101] Specifically, refer to Figure 4 Determine the affected paths of patches in the compiled source code to be tested, including:

[0102] S401, in the function that determines the impact of a patch, is the patch impact basic block that is affected by the changes made after the patch is applied;

[0103] It should be noted that the function contains multiple basic blocks. In the solution provided in this application, the path affected by the patch is determined based on the basic block that affects the patch.

[0104] Specifically, the key to determining the impact of patch information can be: First, compile the initial source code before patching with debug information using a pre-defined compiler, obtaining the corresponding compiled files and symbol tables. Then, compile the initial source code after patching with debug information using the same pre-defined compiler, obtaining the corresponding compiled files and symbol tables. Compare the compiled files and symbol tables corresponding to the initial source code before and after patching to determine the basic changes, i.e., determine the basic impact of the patch information.

[0105] S402, determine the nearest necessary node from the basic block affected by the patch to the function exit as the anchor point;

[0106] It should be noted that the path from the patch-affected basic block to the function exit is relatively long. The portion of this path closest to the function exit is minimally affected by the patch and can be considered unaffected. Therefore, the solution provided in this application further simplifies the path using anchor points. Specifically, based on the compiled files and symbol table, the nearest necessary node from the patch-affected basic block to the function exit can be found; this necessary node is then designated as the anchor point.

[0107] S403, the path starting from the entry point of the patch-affected function, passing through the patch-affected basic block, and ending at the anchor point is defined as the patch-affected path, where the patch-affected path is the path in the first function.

[0108] This setup more accurately determines the patch impact path, and the dynamic features obtained based on the patch impact path are more relevant to the patch. It also eliminates some irrelevant dynamic features, avoids introducing too many quantities unrelated to the patch in subsequent calculations, reduces the amount of data that needs to be analyzed, and improves the efficiency of the analysis.

[0109] Furthermore, refer to Figure 5 The semantic similarity between the first function corresponding to static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch can be determined as follows:

[0110] The similarity of each feature in the static and dynamic features is determined. Based on the similarity, a preset deep learning algorithm is used to calculate the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch.

[0111] Specifically, the steps include the following:

[0112] 501, determine the feature vector of each feature in the static and dynamic features, and determine the similarity of each feature based on the feature vector;

[0113] Specifically, in practical applications, the similarity of each feature in static and dynamic features can be determined based on the Minkowski distance algorithm. The similarity is used to characterize the degree of similarity between the features corresponding to the initial source code before patching and the features corresponding to the initial source code after patching.

[0114] It should be noted that, based on the Minkowski distance algorithm, the method for determining the similarity of each feature in static and dynamic features can be based on a preset formula to directly determine "the degree of similarity between each feature and the feature corresponding to the initial source code before patching and the feature corresponding to the initial source code after patching".

[0115] Alternatively, one could determine the "first similarity between each feature and the feature corresponding to the initial source code before patching" and the "second similarity between each feature and the feature corresponding to the initial source code before patching", and then compare the first and second similarities to obtain "the degree of similarity between each feature and the feature corresponding to the feature corresponding to the initial source code before patching and the feature corresponding to the initial source code after patching".

[0116] Specifically, the general form of the Minkowski distance formula is as follows:

[0117]

[0118] In this formula, f and g are two distinct function pairs (either the first function and the second function corresponding to the patch in the initial source code before patching, or the first function and the second function corresponding to the patch in the initial source code after patching), k refers to the kth execution environment used, x and y represent the features of f and g respectively, and the amount of data inside features x and y is n. P is set to 3.

[0119] Furthermore, the final result of the first or second similarity for each feature is the average of the similarity distances obtained across all execution environments. The similarity calculation equation is as follows (k is the execution environment number):

[0120]

[0121] In the formula, sim(f, g) represents the similarity between a certain feature of the first function and the corresponding second function in the initial source code before patching or the corresponding second function in the initial source code after patching. When f and g in the formula are the first function and the corresponding second function in the initial source code before patching, sim(f, g) represents the first similarity; when f and g in the formula are the first function and the corresponding second function in the initial source code after patching, sim(f, g) represents the second similarity.

[0122] Furthermore, to obtain the similarity of each feature, the first similarity and the second similarity need to be compared to obtain the similarity of the feature relative to the feature corresponding to the initial source code before patching and the feature corresponding to the initial source code after patching.

[0123] The above calculations will be performed for each feature to obtain the similarity, which will then be used as the input variable for the neural network. Specifically, refer to step S502.

[0124] S502, the similarity is input into the preset neural network module, and the neural network module determines the semantic similarity between the first function and the second function corresponding to the patch in the initial source code before and after the patch based on each similarity.

[0125] The similarity scores are input into a pre-defined neural network module, which then determines the semantic similarity between the first function and the second function corresponding to the patch in the initial source code before and after the patch, based on the various similarity scores.

[0126] It should be noted that the solution provided in this application introduces a neural network module to analyze the similarity of features. By combining dynamic features, static features and deep learning methods, the similarity of multiple features is used as the input value for model training. The model output is a weighted average similarity value of multiple features, which does not rely on any single feature and is more representative of the relationship between functions.

[0127] Specifically, the neural network module includes: the neural network input layer has 'a' layers, where 'a' is the number of features; generally, there are 48 static features and 21 dynamic features, so 'a' is 69; the hidden layer has 1 layer and 50 neurons; the output layer has 1 neuron and is the average similarity of each feature, i.e., the overall similarity prediction value.

[0128] Furthermore, the patch existence testing method provided in this application also includes: training a neural network module, specifically the training method as follows:

[0129] Obtain a preset number of feature group samples and the corresponding identifier for each feature group sample as training samples;

[0130] The identifier is used to characterize whether the source code corresponding to the feature group sample has a patch. Each feature group sample includes at least one static feature and at least one dynamic feature. The preset number of feature group samples includes: feature group samples corresponding to source code with patches and feature group samples corresponding to source code without patches.

[0131] Training samples are input into a pre-built neural network model for training, resulting in a neural network module.

[0132] In practical applications, refer to Figure 6 The specific process is as follows:

[0133] S601, first obtain the sample source code to be tested and the initial source code before and after the patch;

[0134] It should be noted that the number of sample source codes to be tested here is relatively large, and they need to cover most of the architecture of the current application devices. Only in this way can the neural network modules obtained after subsequent training have better detection performance.

[0135] S602, based on the sample source code to be tested and the initial source code before and after patching, builds a model and generates training samples;

[0136] It should be noted that model building can be combined with Figure 6 Referring to the relevant descriptions of the neural network modules above, the process of obtaining training samples can also refer to the above-described "process of obtaining the static and dynamic features of the source code to be tested, and determining the similarity of each feature".

[0137] S603 trains the constructed model to obtain a neural network module.

[0138] It should be noted that this neural network module can be used to output a semantic similarity when the similarity of various features is input. This semantic similarity is used to represent the similarity between the first function and the second function corresponding to the patch in the initial source code before patching, and the second function corresponding to the patch in the initial source code after patching.

[0139] Specifically, the semantic similarity can be a value between -1 and 1. The greater the semantic similarity, the closer the first function is to the second function corresponding to the patch in the initial source code after the patching.

[0140] S604, obtain the source code to be tested;

[0141] The source code to be tested here is provided by the user through a preset client. It should be noted that this application does not impose any restrictions on the specific format of the source code to be tested provided by the user.

[0142] S605, obtain the static characteristics of the patch-affected function and the dynamic characteristics of the patch-affected path in the source code to be tested;

[0143] It should be noted that by only obtaining the static characteristics of the patch's impact function and the dynamic characteristics of the patch's impact path, the impact of the patch can be determined more accurately, avoiding interference from irrelevant characteristics in the subsequent analysis process.

[0144] S606, determine the similarity of each feature in the static and dynamic features; where the similarity is used to characterize the degree of similarity between the features corresponding to the initial source code before patching and the features corresponding to the initial source code after patching.

[0145] For the specific calculation process, please refer to the relevant description of step S501 in the previous text.

[0146] S607, The similarity is input into the preset neural network module, and the neural network module determines the semantic similarity between the first function and the second function corresponding to the patch in the initial source code before and after the patch based on the various similarities.

[0147] It should be noted that the neural network module used here is the one trained in step S603 above. Therefore, the selection of the patch impact function and patch impact path must be consistent during model training and the testing of the source code, and the acquired features must correspond.

[0148] S608: If the semantic similarity is greater than a preset threshold, then the source code to be tested is a source code with a patch.

[0149] In the above embodiments, by combining dynamic and static features with deep learning, the similarity of multiple features is used as the input value for model training. The model output is a weighted average similarity value of multiple features, which does not rely on any single feature and is more representative of the relationship between functions. Furthermore, detection based on a deep learning model does not incur significant time consumption. Especially for large-scale detection tasks, it can guarantee detection efficiency to a certain extent.

[0150] Exemplary device

[0151] Reference Figure 7 This application provides a patch existence testing apparatus, comprising:

[0152] Module 71 is used to acquire the static and dynamic features of the source code to be tested.

[0153] Static features include: features of at least one first function determined during the compilation of the source code to be tested; dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein the first function is a function in the source code to be tested.

[0154] The first determining module 72 is used to determine the semantic similarity between the first function corresponding to the static features and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch;

[0155] The second determining module 73 determines that the source code to be tested is a source code with a patch if the semantic similarity is greater than a preset threshold.

[0156] Specifically, module 81 is used for:

[0157] Compile the source code to be tested and identify the first function in the compiled source code;

[0158] Extract the features of the first function to obtain static features; wherein, the features of the first function include at least one of the following: the number of instructions within the function, the number of strings, the size of static variables, the maximum number of instructions in the basic block, the minimum number of instructions in the basic block, the maximum size of the basic block, and the minimum size of the basic block.

[0159] Determine the path in the first function;

[0160] Extract the characteristics of the path in the first function when the program corresponding to the source code to be tested is executed to obtain dynamic characteristics; wherein, the characteristics of the path in the first function include at least one of the following: instruction quantity characteristics, system-level information characteristics, function and system call characteristics.

[0161] The first function in the compiled source code to be tested includes:

[0162] Identify the functions affected by patches in the compiled source code to be tested;

[0163] Wherein, the patch impact function is the first function; the patch impact function includes: the function containing the content modified after the patch is applied;

[0164] Determining the path in the first function during program execution includes:

[0165] Determine the affected paths of patches in the compiled source code to be tested;

[0166] The patch-affected path is the path in the first function; the patch-affected path includes: the path through the patch-affected basic block; the patch-affected basic block is the basic block affected by the content modified after the patch is applied.

[0167] In one embodiment, determining the patch-affected functions in the compiled source code to be tested includes:

[0168] The source code to be tested is compiled with debugging information to obtain the corresponding symbol table;

[0169] Based on the patch information, determine the keys affected by the patch information;

[0170] Based on the key, the patch-affected function is determined by looking up the symbol table.

[0171] In one embodiment, determining the patch impact path in the compiled source code to be tested includes:

[0172] In the patch impact function, determine the patch impact basic block that is affected by the modifications made after the patch is applied;

[0173] The nearest necessary node from the basic block affected by the patch to the function exit is identified as the anchor point.

[0174] The path starting from the entry point of the patch-affected function, passing through the patch-affected basic block, and ending at the anchor point is defined as the patch-affected path, wherein the patch-affected path is the path in the first function.

[0175] In one embodiment, the first determining module 82 is specifically used for:

[0176] Determine the feature vector of each feature in the static and dynamic features, and determine the similarity of each feature based on the feature vector;

[0177] The similarity is input into a preset neural network module, which then determines the semantic similarity between the first function and the second function corresponding to the patch in the initial source code before and after the patch, based on the various similarities.

[0178] In one embodiment, a training module is further included, configured to: obtain a preset number of similarity sample groups and an identifier corresponding to each similarity sample group as training samples; wherein the identifier is used to characterize whether the source code corresponding to the similarity sample group has a patch; the preset number of similarity sample groups includes: similarity sample groups corresponding to source code with patches and similarity sample groups corresponding to source code without patches; and input the training samples into a pre-built neural network model for training to obtain the neural network module.

[0179] Exemplary electronic devices

[0180] Another embodiment of this application also proposes an electronic device, please refer to Figure 8 , Figure 8 This is a schematic diagram of an electronic device structure provided in another embodiment of this application. The device includes:

[0181] Memory 800 and processor 810;

[0182] The memory 800 is connected to the processor 810 and is used to store programs;

[0183] The processor 810 is configured to implement the patch existence test method disclosed in any of the above embodiments by running a program stored in the memory 800.

[0184] Specifically, the above-mentioned patch existence test method may also include: bus, communication interface 820, input device 830 and output device 840.

[0185] The processor 810, memory 800, communication interface 820, input device 830, and output device 840 are interconnected via a bus. Among them:

[0186] A bus can include a pathway for transmitting information between various components of a computer system.

[0187] The processor 810 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0188] The processor 810 may include a main processor, as well as a baseband chip, modem, etc.

[0189] The memory 800 stores a program that executes the technical solution of this invention, and may also store an operating system and other key business functions. Specifically, the program may include program code, which includes computer operation instructions. More specifically, the memory 800 may include read-only memory (ROM), other types of static storage devices capable of storing static information and instructions, random access memory (RAM), other types of dynamic storage devices capable of storing information and instructions, disk storage, flash memory, etc.

[0190] Input device 830 may include means for receiving data and information input by the user.

[0191] Output device 840 may include a device that allows information to be output to a user, such as a display screen.

[0192] The communication interface 820 may include a device that uses any transceiver to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0193] The processor 810 executes the program stored in the memory 800 and calls other devices, which can be used to implement the various steps of any of the patch existence test methods provided in the above embodiments of this application.

[0194] Exemplary computer program products and storage media

[0195] In addition to the methods and apparatus described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the patch presence testing methods according to various embodiments of this application described in the "Exemplary Methods" section of this specification.

[0196] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0197] Furthermore, embodiments of this application may also be storage media storing a computer program, which is executed by a processor in the patch existence testing method according to various embodiments of this application described in the "Exemplary Methods" section above. Specifically, the following steps can be implemented:

[0198] Obtain the static and dynamic characteristics of the source code to be tested;

[0199] Static features include: features of at least one first function determined during the compilation of the source code to be tested; dynamic features include: features of paths in at least one first function determined during the runtime of the program corresponding to the source code to be tested; wherein, the first function is a function in the source code to be tested;

[0200] Determine the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch;

[0201] If the semantic similarity is greater than a preset threshold, then the source code to be tested is source code with patches.

[0202] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0203] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0204] The steps in the methods of the various embodiments of this application can be adjusted, merged, or deleted in order according to actual needs, and the technical features described in each embodiment can be replaced or combined.

[0205] The modules and sub-modules in the various embodiments of the present application's devices and terminals can be merged, divided, and deleted according to actual needs.

[0206] It should be understood that the disclosed terminals, devices, and methods can be implemented in other ways, given the several embodiments provided in this application. For example, the terminal embodiments described above are merely illustrative. For instance, the division of modules or sub-modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple sub-modules or modules may be combined or integrated into another module, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0207] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0208] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0209] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0210] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0211] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0212] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A patch existence testing method, characterized in that, include: Compile the source code to be tested and identify the first function in the compiled source code; Extract the features of the first function to obtain the static features; Determine the path in the first function; Extract the characteristics of the path in the first function during program execution corresponding to the source code to be tested to obtain dynamic features; The static features include at least one feature determined during the compilation of the source code to be tested; the dynamic features include at least one feature determined during the runtime of the program corresponding to the source code to be tested. Determine the semantic similarity between the first function corresponding to the static feature and the dynamic feature and the second function corresponding to the patch in the initial source code before and after the patch, wherein the semantic similarity is the similarity between the first function and the second function corresponding to the patch in the initial source code before the patch, or the first function and the second function corresponding to the patch in the initial source code after the patch; If the semantic similarity is greater than a preset threshold, and the source code to be tested is closer to the initial source code after patching, then the source code to be tested is the source code with a patch. Determining the semantic similarity between the first function corresponding to the static features and the dynamic features and the second function corresponding to the patch in the initial source code before and after the patch includes: Based on the Minkowski distance algorithm, the similarity of each feature in the static and dynamic features is determined. The similarity is input into a preset neural network module, which analyzes the similarity. Combining dynamic features, static features, and deep learning methods, a weighted average similarity value of multiple features is output. The weighted average similarity value is used as the similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before patching, or between the first function and the second function corresponding to the patch in the initial source code after patching.

2. The patch existence testing method according to claim 1, characterized in that, The step of determining the similarity of each feature in the static and dynamic features, and using a preset deep learning algorithm to calculate the semantic similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before and after the patch, includes: Determine the feature vector of each feature in the static and dynamic features, and determine the similarity of each feature based on the feature vector; The similarity is input into a preset neural network module, which then determines the semantic similarity between the first function and the second function corresponding to the patch in the initial source code before and after the patch, based on the various similarities.

3. The patch existence testing method according to claim 1, characterized in that, in, The first function has at least one of the following characteristics: the number of instructions within the function, the number of strings, the size of static variables, the maximum number of instructions in a basic block, the minimum number of instructions in a basic block, the maximum size of a basic block, and the minimum size of a basic block. The path characteristics in the first function include at least one of the following: instruction quantity characteristics, system-level information characteristics, function and system call characteristics.

4. The patch existence testing method according to claim 3, characterized in that, The first function in the compiled source code to be tested includes: Identify the functions affected by patches in the compiled source code to be tested; Wherein, the patch impact function is the first function; the patch impact function includes: the function containing the content modified after the patch is applied; Determining the path in the first function includes: Determine the affected paths of patches in the compiled source code to be tested; The patch-affected path is the path in the first function; the patch-affected path includes: the path through the patch-affected basic block; the patch-affected basic block is the basic block affected by the content modified after the patch is applied.

5. The patch existence testing method according to claim 4, characterized in that, The functions affected by the patch in the compiled source code to be tested include: The source code to be tested is compiled with debugging information to obtain the corresponding symbol table; Based on the patch information, determine the keys affected by the patch information; Based on the key, the patch-affected function is determined by looking up the symbol table.

6. The patch existence testing method according to claim 4, characterized in that, The path affected by patches in the compiled source code to be tested is determined, including: In the patch impact function, determine the patch impact basic block that is affected by the modifications made after the patch is applied; The nearest necessary node from the basic block affected by the patch to the function exit is identified as the anchor point. The path starting from the entry point of the patch-affected function, passing through the patch-affected basic block, and ending at the anchor point is defined as the patch-affected path, wherein the patch-affected path is the path in the first function.

7. The patch existence testing method according to claim 1, characterized in that, Also includes: Obtain a preset number of similarity sample groups and the identifier corresponding to each similarity sample group as training samples; The identifier is used to indicate whether the source code corresponding to the similarity sample group has a patch; the preset number of similarity sample groups includes: similarity sample groups corresponding to source code with patches and similarity sample groups corresponding to source code without patches; The training samples are input into a pre-built neural network model for training to obtain the neural network module.

8. A patch presence testing device, characterized in that, include: The acquisition module is used to compile the source code to be tested and determine the first function in the compiled source code to be tested; Extract the features of the first function to obtain the static features; Determine the path in the first function; Extract the characteristics of the path in the first function during program execution corresponding to the source code to be tested to obtain dynamic features; The static features include at least one feature determined during the compilation of the source code to be tested; the dynamic features include at least one feature determined during the runtime of the program corresponding to the source code to be tested. The first determining module is used to determine the semantic similarity between the first function corresponding to the static feature and the dynamic feature and the second function corresponding to the patch in the initial source code before and after the patch, wherein the semantic similarity is the similarity between the first function and the second function corresponding to the patch in the initial source code before the patch, or the first function and the second function corresponding to the patch in the initial source code after the patch; The second determining module determines that if the semantic similarity is greater than a preset threshold, and the source code to be tested is closer to the initial source code after patching, then the source code to be tested is the source code with a patch. Determining the semantic similarity between the first function corresponding to the static features and the dynamic features and the second function corresponding to the patch in the initial source code before and after the patch includes: Based on the Minkowski distance algorithm, the similarity of each feature in the static and dynamic features is determined. The similarity is input into a preset neural network module, which analyzes the similarity. Combining dynamic features, static features, and deep learning methods, a weighted average similarity value of multiple features is output. The weighted average similarity value is used as the similarity between the first function corresponding to the static and dynamic features and the second function corresponding to the patch in the initial source code before patching, or between the first function and the second function corresponding to the patch in the initial source code after patching.

9. An electronic device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the patch existence test method as described in any one of claims 1 to 7.

Images