Vulnerability repair detection method and device, computer equipment, readable storage medium and program product

By dynamic instrumentation and decompilation processing of the application package to be detected, combined with the comparison and analysis of the control flow diagram, the problem that traditional methods cannot accurately judge vulnerability repair is solved, and accurate detection of vulnerability repair situations and improvement of software reliability is achieved.

CN119622740APending Publication Date: 2025-03-14CHINA TELECOM CORP LTD TECHNOLOGY INNOVATION CENTER +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411695644.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-25
Publication Date
2025-03-14

AI Technical Summary

Technical Problem

Traditional vulnerability detection methods cannot accurately determine whether the vulnerability has been fixed, especially when the application service cannot upgrade components.

Method used

By obtaining potential vulnerabilities and corresponding vulnerability patch information of the application package to be detected, using virtual machine tools for dynamic instrumentation processing, decompile the bytecode of the target class, and comparing and analyzing the control flow diagram to accurately determine whether the vulnerability has been fixed.

Benefits of technology

Accurate detection of vulnerability repair situations is achieved, and vulnerabilities in the software that have not been effectively repaired can be discovered in a timely manner, thereby improving the reliability of the software.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119622740A_ABST
    Figure CN119622740A_ABST
Patent Text Reader

Abstract

The invention relates to a vulnerability repair detection method and device, computer equipment, a readable storage medium and a program product. The method comprises the steps that multiple potential vulnerabilities of a to-be-detected application package are obtained, vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities are obtained from a vulnerability patch library, dynamic instrumentation processing is conducted on a target process of the to-be-detected application package through a virtual machine tool interface, and all loading classes in the target process are obtained, filtering the loading class according to the bug patch information to obtain a target class, decompiling byte codes of the target class to obtain a target code block, respectively obtaining a first control flow diagram of the target code block and a second control flow diagram of the bug patch code block, and comparing and analyzing the first control flow diagram and the second control flow diagram to obtain a bug patch code block; and obtaining vulnerability repair information of the to-be-detected application package according to a comparative analysis result. By adopting the method, whether the patch is valid or not can be accurately judged, and unrepaired vulnerabilities in software can be found in time.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of software security technology, and in particular to a vulnerability repair detection method, apparatus, computer equipment, readable storage medium and program product. Background Art

[0002] With the rapid advancement of Internet technology, the widespread use of open source components has become a major trend in the software development process. These components not only greatly accelerate the development process and reduce costs, but also promote the continuous innovation of computing technology. While open source components bring many conveniences, they also pose a potential threat to software security.

[0003] Traditional vulnerability detection and repair detection methods mainly rely on component versions and component vulnerability libraries. By comparing the current component version with the information in the vulnerability library, it can be determined whether the component has known vulnerabilities and whether corresponding repairs have been made.

[0004] However, in actual applications, some application services cannot upgrade components at will after they are launched due to business continuity and stability considerations. This means that even if a component has a known vulnerability, the problem cannot be solved by a simple version upgrade. In addition, component upgrades are often accompanied by certain risks and maintenance costs. In some cases, in order to reduce these risks and costs, the development team may choose not to upgrade the component, but to apply the vulnerability patch code directly to the service through hot updates. Therefore, traditional detection methods often cannot accurately determine whether the vulnerability has been fixed. Summary of the invention

[0005] Based on this, it is necessary to provide a vulnerability repair detection method, device, computer equipment, readable storage medium and program product that can accurately detect the vulnerability repair status in response to the above technical problems.

[0006] In a first aspect, the present application provides a vulnerability repair detection method, comprising:

[0007] Acquire multiple potential vulnerabilities of the application package to be detected, and acquire vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library;

[0008] Perform dynamic instrumentation on the target process of the application package to be detected through the virtual machine tool interface, obtain all loaded classes in the target process, filter the loaded classes according to the vulnerability patch information, and obtain the target class;

[0009] Decompile the bytecode of the target class to obtain a target code block, and obtain a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block respectively;

[0010] A comparative analysis is performed on the first control flow graph and the second control flow graph, and vulnerability repair information of the application package to be detected is obtained according to the result of the comparative analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0011] In one embodiment, a plurality of potential vulnerabilities of the application package to be detected are obtained, including:

[0012] Scan the application package to be detected by using a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version;

[0013] A plurality of potential vulnerabilities corresponding to the component information are obtained from a component vulnerability library.

[0014] In one embodiment, obtaining vulnerability patch information and vulnerability patch code blocks corresponding to potential vulnerabilities from a vulnerability patch library includes:

[0015] Get vulnerability information for potential vulnerabilities; vulnerability information includes Common Vulnerabilities and Exposures Identifiers;

[0016] Acquire vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from the vulnerability patch library.

[0017] In one embodiment, a target process of the application package to be detected is dynamically instrumented through a virtual machine tool interface to obtain all loaded classes in the target process, including:

[0018] Obtain the process IDs of all running processes in the application package to be detected, and determine the target process based on the process IDs;

[0019] The agent program is attached to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0020] In one embodiment, performing comparative analysis on the first control flow graph and the second control flow graph includes:

[0021] Performing depth-first search on the first control flow graph and the second control flow graph respectively to obtain corresponding first program call chains and second program call chains;

[0022] Merging the same items of the first program call chain and the second program call chain respectively to obtain a corresponding first node set and a second node set;

[0023] A comparative analysis is performed on the subset relationship and node execution order of the first node set and the second node set.

[0024] In one embodiment, obtaining vulnerability repair information of the application package to be detected according to the result of the comparative analysis includes:

[0025] When the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, it is determined that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

[0026] In a second aspect, the present application also provides a vulnerability repair detection device, including:

[0027] A vulnerability acquisition module is used to acquire multiple potential vulnerabilities of the application package to be detected, and to acquire vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library;

[0028] The target class acquisition module is used to dynamically insert the target process of the application package to be detected through the virtual machine tool interface, obtain all loaded classes in the target process, filter the loaded classes according to the vulnerability patch information, and obtain the target class;

[0029] A decompilation processing module is used to decompile the bytecode of the target class to obtain a target code block, and obtain a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block respectively;

[0030] The comparison and analysis module is used to compare and analyze the first control flow graph and the second control flow graph, and obtain vulnerability repair information of the application package to be detected according to the result of the comparison and analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0031] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method steps of any one of the first aspects are implemented.

[0032] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements any one of the method steps in the first aspect when the computer program is executed by a processor.

[0033] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which implements any one of the method steps in the first aspect when executed by a processor.

[0034] The above-mentioned vulnerability repair detection method, device, computer equipment, readable storage medium and program product can obtain the class actually loaded when the service is running by dynamically inserting the application package to be detected, which is closer to the actual operation of the application package to be detected. By decompiling the bytecode of the loaded class and then comparing the control flow chart with the patch code corresponding to the application package to be detected, it can accurately determine whether the patch has truly repaired the vulnerability, and can promptly discover vulnerabilities in the software that have not been effectively repaired, thereby improving the reliability of the software. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0036] Figure 1 A diagram of an application environment of a vulnerability repair detection method in an embodiment;

[0037] Figure 2 A schematic diagram of a process of a vulnerability repair detection method in one embodiment;

[0038] FIG3( a ) is a schematic diagram of a first control flow graph in one embodiment;

[0039] FIG3( b ) is a schematic diagram of a second control flow graph in one embodiment;

[0040] Figure 4 A schematic diagram of a flow chart of a vulnerability repair detection method in another embodiment;

[0041] Figure 5 is a structural block diagram of a vulnerability repair detection device in an embodiment;

[0042] Figure 6 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] The vulnerability repair detection method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. Among them, the terminal 102 is used to obtain multiple potential vulnerabilities of the application package to be detected, and obtain the vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from the vulnerability patch library, and dynamically insert the target process of the application package to be detected through the virtual machine tool interface to obtain all the loaded classes in the target process, filter the loaded classes according to the vulnerability patch information, obtain the target class, decompile the bytecode of the target class, obtain the target code block, and respectively obtain the first control flow graph of the target code block and the second control flow graph of the vulnerability patch code block, compare and analyze the first control flow graph and the second control flow graph, and obtain the vulnerability repair information of the application package to be detected according to the results of the comparative analysis. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices, and the Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car devices, projection devices, etc. The portable wearable device may be a smart watch, a smart bracelet, a head-mounted device, etc. The head-mounted device may be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server 104 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0045] In an exemplary embodiment, Figure 2 As shown, a vulnerability repair detection method is provided, which is applied to Figure 1 The terminal 102 in the example is used as an example to illustrate, including the following steps 202 to 206. Among them:

[0046] S202: Acquire multiple potential vulnerabilities of the application package to be detected, and acquire vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library.

[0047] Optionally, the application package to be detected should be analyzed first to obtain multiple potential vulnerabilities that may exist in the application package to be detected. These potential vulnerabilities may be caused by various reasons such as non-standard code writing, insufficient external input verification, and security configuration errors. After the potential vulnerabilities are determined, the vulnerability patch information and vulnerability patch code blocks corresponding to these potential vulnerabilities are searched from the vulnerability patch library, where the vulnerability patch library is a resource library that stores information related to repair solutions for different vulnerabilities and specific code implementations. It can be maintained by software developers, security research institutions, etc. For example, for a known buffer overflow vulnerability, detailed instructions on how to repair the vulnerability (i.e., vulnerability patch information) and code snippets that specifically implement the repair function (i.e., vulnerability patch code blocks) can be found in the vulnerability patch library.

[0048] S204: Dynamically instrument the target process of the application package to be detected through the virtual machine tool interface to obtain all loaded classes in the target process, filter the loaded classes according to the vulnerability patch information, and obtain the target class.

[0049] Optionally, dynamic stub is a technology that inserts additional code during program execution, which can be used to obtain various information about the target process at runtime. Here, after dynamic stub processing, all loaded classes in the target process can be obtained, where loaded classes refer to classes that are loaded into memory when the program is running, and they contain various code logics and data structures required for program operation. After all loaded classes are obtained, these loaded classes are filtered according to the vulnerability patch information previously obtained from the vulnerability patch library. For example, according to the description of the characteristics, functions, etc. of the classes related to the vulnerability involved in the patch information, the target classes that are closely related to the potential vulnerability to be repaired are screened out from the numerous loaded classes.

[0050] S206: Decompile the bytecode of the target class to obtain a target code block, and obtain a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block respectively.

[0051] Optionally, bytecode is an intermediate form of code, usually generated by high-level language compilation, which runs on a virtual machine. The purpose of decompilation is to restore the bytecode to a code closer to the original high-level language form for subsequent analysis. After decompilation, the target code block is obtained, which more intuitively displays the code logic of the target class. After that, the control flow graphs of the target code block obtained by decompilation and the vulnerability patch code block obtained from the vulnerability patch library are obtained. Among them, the control flow graph (CFG) is a tool that graphically represents the execution process of program code. It uses nodes and directed edges to show the flow relationship between various statements, branches, loops and other structures in the code. Among them, the node usually represents the basic block in the program, that is, a sequence of code that is executed sequentially and has no branches. The directed edge represents the flow direction of program execution. For example, after executing from a basic block, it may turn to another basic block for continued execution based on conditional judgment (such as if statement). The path connecting the two basic blocks is represented by a directed edge.

[0052] S208: Compare and analyze the first control flow graph and the second control flow graph, and obtain vulnerability repair information of the application package to be detected according to the result of the comparative analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0053] Optionally, during the comparison process, focus on the differences between the two control flow graphs in terms of structure, execution path, key nodes, etc. For example, check whether the execution path of the target code block is different from the execution path of the vulnerability patch code block in the place where the vulnerability should be fixed, or whether there are differences in the processing methods of key nodes (such as nodes for input verification). The vulnerability repair information of the application package to be tested is obtained based on the results of the comparative analysis. Specifically, if it is found in the comparison that the execution path of the target code block is significantly different from the vulnerability patch code block, and these differences indicate that the target code block does not repair the potential vulnerability in the same way as the vulnerability patch code block, then it can be determined that there are unrepaired potential vulnerabilities in the application package to be tested.

[0054] In the above vulnerability repair detection method, by dynamically inserting the application package to be detected, the class actually loaded when the service is running can be obtained, which is closer to the actual operation of the application package to be detected. By decompiling the bytecode of the loaded class and then comparing the control flow chart with the patch code corresponding to the application package to be detected, it is possible to accurately determine whether the patch has truly fixed the vulnerability, and to promptly discover vulnerabilities in the software that have not been effectively repaired, thereby improving the reliability of the software.

[0055] In an exemplary embodiment, the step of obtaining multiple potential vulnerabilities of the application package to be detected includes: scanning the application package to be detected by a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; and obtaining multiple potential vulnerabilities corresponding to the component information from a component vulnerability library.

[0056] Optionally, the software component analysis tool is a tool specifically used to analyze the composition of software. During the scanning process, the tool will extract detailed information about each component, including the name, type, function and other related attributes of the component, and will also determine the version of the component. The component vulnerability library is a database that stores a large amount of information about the vulnerabilities of various software components, including the vulnerabilities that may appear in different components under different versions. According to the name and version of the component, the corresponding entry is searched in the component vulnerability library to obtain the potential vulnerability information related to these components.

[0057] In this embodiment, by first analyzing the components of the software and then searching for vulnerabilities in the corresponding components, it is possible to avoid missing certain vulnerabilities hidden in the components, fully obtain potential vulnerabilities in the application package to be detected, and improve the accuracy of vulnerability detection.

[0058] In an exemplary embodiment, the step of obtaining vulnerability patch information and vulnerability patch code blocks corresponding to potential vulnerabilities from a vulnerability patch library includes: obtaining vulnerability information of the potential vulnerability; the vulnerability information includes a universal vulnerability disclosure identifier; and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from the vulnerability patch library.

[0059] Optionally, the Common Vulnerability Exposure Identifier (CVEID) is a standardized identification method used to uniquely identify a known security vulnerability. By searching for records with the same CVE number in the vulnerability patch library, the entry corresponding to the potential vulnerability is found, thereby obtaining the vulnerability patch information and vulnerability patch code block contained in the entry. Among them, the vulnerability patch information includes but is not limited to the jar package name, package name, class name, and function name of the relevant vulnerability patch code, among which the jar package name refers to the name of the Java Archive (JAR) file containing the relevant vulnerability patch code. The jar package is a file format that packages multiple Java class files, related resources, and metadata together. The package name is a namespace mechanism used to organize and manage classes in Java programs. Each Java class belongs to a package package. The package name clarifies the scope of the class in the entire program code organization structure. The class name is the name of a specific class in a Java program. Each class has its own unique functions and uses. In the process of vulnerability repair, a specific class will undertake the corresponding repair task. The function name refers to the function name in the class class used to perform specific operations.

[0060] In this embodiment, by acquiring corresponding vulnerability patch information and vulnerability patch code blocks from a vulnerability patch library according to the vulnerability information, required patch information and code blocks can be found quickly, thereby improving the accuracy of subsequent comparative analysis.

[0061] In an exemplary embodiment, the target process of the application package to be detected is dynamically instrumented through the virtual machine tool interface to obtain all loaded classes in the target process, including: obtaining the process IDs of all running processes in the application package to be detected, and determining the target process based on the process ID; attaching an agent program to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0062] Optionally, when an application package is running in the system, it may contain multiple processes. The process ID (pid) is a number used by the operating system to uniquely identify each process. Through specific system tools or programming interfaces, the process IDs of all running processes in the application package to be detected can be obtained. Among them, the target process is the process related to the dynamic instrumentation process.

[0063] Optionally, the virtual machine tool interface provides a way to interact with the virtual machine where the application is running. In programming languages ​​such as Java, applications usually run on top of a virtual machine environment. This interface allows external tools (here, tools for dynamic instrumentation) to communicate and control the virtual machine. By attaching the agent to the target process through the virtual machine tool interface, all loaded classes in the virtual machine of the target process can be obtained. In a virtual machine environment, classes are dynamically loaded as needed during program execution. These loaded classes contain various code logics and data structures actually used when the application is running. The agent can traverse and obtain information about these loaded classes, such as class names, inheritance relationships, method lists, etc., through the internal mechanisms provided by the virtual machine.

[0064] For example, in Java, the attach method is used to attach an already running Java virtual machine (JVM) to the current process, so that the operation of the virtual machine can be monitored and controlled. Through the attach method, you can obtain the running status information of the JVM, such as thread status, memory usage, garbage collection (GC) status, etc., and even send commands, such as forced GC, thread suspension, thread recovery, etc. The agent package usually contains one or more Java classes, which define the behavior of the agent. After successfully connecting to the service process through the attach method, the agent package can be "applied" to the running service. After the agent package successfully acts on the service process, the get All Loaded Classes method can be used to obtain all loaded classes in the JVM. Through the get All Loaded Classes method, the agent package can traverse the JVM and collect relevant information of all currently loaded classes, such as the name of the class, the attributes of the class, methods, etc. Afterwards, the class names are filtered through the patch information, and the target class contents related to the patch are selected from the many loaded classes. Then, the class files in the form of Java bytecode are restored into code files that are closer to the original Java source code through the jad method.

[0065] In this embodiment, through dynamic instrumentation, it is possible to go deep into the operating environment of the application, obtain the classes that are actually loaded and used during the actual operation process, and capture the classes that are dynamically loaded according to different operating scenarios and user operations, so as to more comprehensively detect the vulnerabilities of the application.

[0066] In an exemplary embodiment, the step of comparatively analyzing the first control flow graph and the second control flow graph includes: performing depth-first search on the first control flow graph and the second control flow graph respectively to obtain the corresponding first program call chain and the second program call chain; merging the first program call chain and the second program call chain respectively to obtain the corresponding first node set and the second node set; and comparatively analyzing the subset relationship and node execution order of the first node set and the second node set.

[0067] Optionally, depth-first search (DFS) is a graph traversal algorithm used to explore as deeply as possible along a path in a graph structure until it is impossible to continue or the target condition is reached, and then backtrack and continue to explore other paths. When applied to a control flow graph, starting from a certain starting node, the nodes and edges in the graph are traversed in a depth-first manner, and the sequence of nodes passed is recorded. This sequence forms the call chain of the program. For the first control flow graph and the second control flow graph, the depth-first search operation is performed independently, and the corresponding first program call chain and second program call chain can be obtained. Since some nodes may be repeatedly visited during the execution of the program, in order to more clearly present the different node situations involved in the execution of the program, it is necessary to perform the same-item merge operation to obtain the corresponding first node set and second node set.

[0068] Further, the subset relationship and the node execution order between the first node set and the second node set are compared, wherein, when judging the vulnerability repair situation, if the node set of the patch code is a subset of the target code node set, it means that there may be the same access node as the patch code in the target code block, that is, the target code block may have repaired the vulnerability corresponding to the patch code block, and on this basis, further judgment is made in combination with the node execution order. Even if the node set of the patch code is a subset of the target code node set, if the execution order of these nodes in the target code does not meet the execution order of the patch code expected to repair the vulnerability, then the vulnerability may still not be repaired. Therefore, only when the node set of the patch code is a subset of the target code node set, and the execution order in the target code also meets the requirements of the patch code to repair the vulnerability, can the corresponding vulnerability be confirmed to be repaired.

[0069] In this embodiment, by comparing the differences between the target code block and the patch code block in combination with the execution order, it is possible to accurately discover situations where vulnerabilities have not been repaired due to patch position problems, and to more comprehensively and accurately detect vulnerability repair situations, thereby improving detection accuracy.

[0070] In an exemplary embodiment, vulnerability repair information of the application package to be detected is obtained based on the results of the comparative analysis, including: when the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, determining that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

[0071] For example, as shown in Figure 3 (a) and Figure 3 (b), Figure 3 (a) is the first control flow graph of the target code block, and Figure 3 (b) is the second control flow graph of the vulnerability patch code block. The first control flow graph starts from node 1, and after a depth-first traversal of a series of nodes, the resulting call chain is [1,2,3,5,4,6,7,8]. A depth-first search is performed on the second control flow graph, and the call chain of [2,3,5,7] is obtained. The first program call chain and the second program call chain are merged with the same items to obtain the corresponding first node set and second node set, where the first node set is represented as: {1,2,[(3,5),4],6,7,8}, and the second node set is represented as: {2,3,5,7}. It can be seen that the elements in the second node set {2,3,5,7} of the patch code can all be found in the first node set {1,2,[(3,5),4],6,7,8} of the target code, which means that the second node set is a subset of the first node set, and the execution order of the nodes is the same, which means that the target code block has fixed the potential vulnerability corresponding to the patch code block, so that all vulnerability repair conditions of the application package to be tested can be obtained.

[0072] In this embodiment, by comparing the subset relationship and execution order between the second node set and the first node set, it is possible to accurately determine whether the patch code corresponding to each potential vulnerability is correctly applied in the target code, thereby accurately obtaining the unpatched potential vulnerabilities.

[0073] In an exemplary embodiment, Figure 4 As shown, a vulnerability repair detection method is provided, which includes the following steps:

[0074] The application package to be detected is scanned by a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; and multiple potential vulnerabilities corresponding to the component information are obtained from a component vulnerability library.

[0075] Obtain vulnerability information of potential vulnerabilities; the vulnerability information includes a common vulnerability disclosure identifier; obtain vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from a vulnerability patch library.

[0076] Obtain the process IDs of all running processes in the application package to be detected, and determine the target process according to the process ID; attach the agent program to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0077] Filter the loaded classes according to the vulnerability patch information to obtain the target class.

[0078] The bytecode of the target class is decompiled to obtain a target code block, and a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block are obtained respectively.

[0079] Performing depth-first search on the first control flow graph and the second control flow graph respectively to obtain the corresponding first program call chain and the second program call chain; merging the first program call chain and the second program call chain respectively to obtain the corresponding first node set and the second node set; and comparing and analyzing the subset relationship and node execution order of the first node set and the second node set.

[0080] When the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, it is determined that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

[0081] In this embodiment, by dynamically inserting the application package to be detected, the class actually loaded when the service is running can be obtained, which is closer to the actual operation of the application package to be detected. By decompiling the bytecode of the loaded class and then comparing the control flow chart with the patch code corresponding to the application package to be detected, it is possible to accurately determine whether the vulnerability is truly repaired, and vulnerabilities in the software that have not been effectively repaired can be discovered in time, thereby improving the reliability of the software.

[0082] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0083] Based on the same inventive concept, the embodiment of the present application also provides a vulnerability repair detection device for implementing the vulnerability repair detection method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more vulnerability repair detection device embodiments provided below can refer to the limitations of the vulnerability repair detection method above, and will not be repeated here.

[0084] In an exemplary embodiment, Figure 5 As shown, a vulnerability repair detection device is provided, including: a vulnerability acquisition module 10, a target class acquisition module 20, a decompilation processing module 30 and a comparison analysis module 40, wherein:

[0085] The vulnerability acquisition module 10 is used to acquire multiple potential vulnerabilities of the application package to be detected, and acquire vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from the vulnerability patch library.

[0086] The target class acquisition module 20 is used to dynamically insert the target process of the application package to be detected through the virtual machine tool interface, obtain all loaded classes in the target process, filter the loaded classes according to the vulnerability patch information, and obtain the target class.

[0087] The decompile processing module 30 is used to decompile the bytecode of the target class to obtain a target code block, and respectively obtain a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block.

[0088] The comparison and analysis module 40 is used to compare and analyze the first control flow graph and the second control flow graph, and obtain vulnerability repair information of the application package to be detected according to the result of the comparison and analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0089] In an exemplary embodiment, the vulnerability acquisition module 10 is also used to scan the application package to be detected through a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; and multiple potential vulnerabilities corresponding to the component information are obtained from the component vulnerability library.

[0090] In an exemplary embodiment, the vulnerability acquisition module 10 is further used to obtain vulnerability information of potential vulnerabilities; the vulnerability information includes a universal vulnerability disclosure identifier; and to obtain vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from a vulnerability patch library.

[0091] In an exemplary embodiment, the target class acquisition module 20 is also used to obtain the process IDs of all running processes in the application package to be detected, and determine the target process based on the process ID; attach the agent program to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0092] In an exemplary embodiment, the comparative analysis module 40 is also used to perform depth-first search on the first control flow graph and the second control flow graph, respectively, to obtain the corresponding first program call chain and the second program call chain; to merge the first program call chain and the second program call chain, respectively, to obtain the corresponding first node set and second node set; to perform comparative analysis on the subset relationship and node execution order of the first node set and the second node set.

[0093] In an exemplary embodiment, the comparison and analysis module 40 is also used to determine that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired when the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set.

[0094] Each module in the above vulnerability repair detection device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0095] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 6As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a vulnerability repair detection method is implemented. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0096] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0097] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the following steps when executing the computer program: obtaining multiple potential vulnerabilities of an application package to be detected, and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library; dynamically inserting a target process of the application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, filtering the loaded classes according to the vulnerability patch information to obtain a target class; decompiling the bytecode of the target class to obtain a target code block, and respectively obtaining a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block; comparing and analyzing the first control flow graph and the second control flow graph, and obtaining vulnerability repair information of the application package to be detected according to the result of the comparative analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0098] In one embodiment, obtaining multiple potential vulnerabilities of an application package to be detected when a processor executes a computer program includes: scanning the application package to be detected by a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; and obtaining multiple potential vulnerabilities corresponding to the component information from a component vulnerability library.

[0099] In one embodiment, the process of obtaining vulnerability patch information and vulnerability patch code blocks corresponding to potential vulnerabilities from a vulnerability patch library when a processor executes a computer program includes: obtaining vulnerability information of the potential vulnerability; the vulnerability information includes a universal vulnerability disclosure identifier; and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from the vulnerability patch library.

[0100] In one embodiment, when a processor executes a computer program, it involves dynamically instrumenting a target process of an application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, including: obtaining the process IDs of all running processes in the application package to be detected, and determining the target process based on the process ID; attaching an agent program to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0101] In one embodiment, the comparative analysis of a first control flow graph and a second control flow graph involved in the execution of a computer program by a processor includes: performing a depth-first search on the first control flow graph and the second control flow graph respectively to obtain a corresponding first program call chain and a second program call chain; performing a same-item merge on the first program call chain and the second program call chain respectively to obtain a corresponding first node set and a second node set; and performing a comparative analysis on a subset relationship and a node execution order between the first node set and the second node set.

[0102] In one embodiment, the acquisition of vulnerability repair information of an application package to be detected based on the results of comparative analysis involved when a processor executes a computer program includes: when the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, determining that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

[0103] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented: obtaining multiple potential vulnerabilities of an application package to be detected, and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library; dynamically inserting a target process of the application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, filtering the loaded classes according to the vulnerability patch information to obtain a target class; decompiling the bytecode of the target class to obtain a target code block, and respectively obtaining a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block; performing comparative analysis on the first control flow graph and the second control flow graph, and obtaining vulnerability repair information of the application package to be detected according to the result of the comparative analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0104] In one embodiment, obtaining multiple potential vulnerabilities of an application package to be detected when a computer program is executed by a processor includes: scanning the application package to be detected by a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; and obtaining multiple potential vulnerabilities corresponding to the component information from a component vulnerability library.

[0105] In one embodiment, when a computer program is executed by a processor, the steps involved in obtaining vulnerability patch information and vulnerability patch code blocks corresponding to potential vulnerabilities from a vulnerability patch library include: obtaining vulnerability information of the potential vulnerability; the vulnerability information includes a universal vulnerability disclosure identifier; and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from the vulnerability patch library.

[0106] In one embodiment, when a computer program is executed by a processor, dynamic instrumentation is performed on a target process of an application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, including: obtaining process IDs of all running processes in the application package to be detected, and determining the target process based on the process ID; and attaching an agent program to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0107] In one embodiment, a comparative analysis of a first control flow graph and a second control flow graph involved in execution of a computer program by a processor includes: performing a depth-first search on the first control flow graph and the second control flow graph respectively to obtain a corresponding first program call chain and a second program call chain; performing a same-item merge on the first program call chain and the second program call chain respectively to obtain a corresponding first node set and a second node set; and performing a comparative analysis on a subset relationship and a node execution order between the first node set and the second node set.

[0108] In one embodiment, when a computer program is executed by a processor, the method involves obtaining vulnerability repair information of an application package to be detected based on the results of a comparative analysis, including: when the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, determining that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

[0109] In one embodiment, a computer program product is provided, including a computer program, which implements the following steps when executed by a processor: obtaining multiple potential vulnerabilities of an application package to be detected, and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library; dynamically inserting a target process of the application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, filtering the loaded classes according to the vulnerability patch information to obtain a target class; decompiling the bytecode of the target class to obtain a target code block, and respectively obtaining a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block; performing comparative analysis on the first control flow graph and the second control flow graph, and obtaining vulnerability repair information of the application package to be detected according to the result of the comparative analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

[0110] In one embodiment, obtaining multiple potential vulnerabilities of an application package to be detected when a computer program is executed by a processor includes: scanning the application package to be detected by a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; and obtaining multiple potential vulnerabilities corresponding to the component information from a component vulnerability library.

[0111] In one embodiment, when a computer program is executed by a processor, the steps involved in obtaining vulnerability patch information and vulnerability patch code blocks corresponding to potential vulnerabilities from a vulnerability patch library include: obtaining vulnerability information of the potential vulnerability; the vulnerability information includes a universal vulnerability disclosure identifier; and obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the vulnerability information from the vulnerability patch library.

[0112] In one embodiment, when a computer program is executed by a processor, dynamic instrumentation is performed on a target process of an application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, including: obtaining process IDs of all running processes in the application package to be detected, and determining the target process based on the process ID; and attaching an agent program to the target process through the virtual machine tool interface to obtain all loaded classes in the virtual machine of the target process through the agent program.

[0113] In one embodiment, a comparative analysis of a first control flow graph and a second control flow graph involved in execution of a computer program by a processor includes: performing a depth-first search on the first control flow graph and the second control flow graph respectively to obtain a corresponding first program call chain and a second program call chain; performing a same-item merge on the first program call chain and the second program call chain respectively to obtain a corresponding first node set and a second node set; and performing a comparative analysis on a subset relationship and a node execution order between the first node set and the second node set.

[0114] In one embodiment, when a computer program is executed by a processor, the method involves obtaining vulnerability repair information of an application package to be detected based on the results of a comparative analysis, including: when the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, determining that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

[0115] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0116] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0117] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A vulnerability repair detection method, characterized in that: The method comprises: Acquire multiple potential vulnerabilities of the application package to be detected, and acquire vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library; Dynamically instrument the target process of the application package to be detected through a virtual machine tool interface to obtain all loaded classes in the target process, and filter the loaded classes according to the vulnerability patch information to obtain the target class; Decompiling the bytecode of the target class to obtain a target code block, and respectively obtaining a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block; A comparative analysis is performed on the first control flow graph and the second control flow graph, and vulnerability repair information of the application package to be detected is obtained according to the result of the comparative analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

2. The method according to claim 1, characterized in that The obtaining of multiple potential vulnerabilities of the application package to be detected includes: Scanning the application package to be detected by a software component analysis tool to obtain component information of the application package to be detected; the component information includes component information and component version; A plurality of potential vulnerabilities corresponding to the component information are obtained from a component vulnerability library.

3. The method according to claim 1, characterized in that The step of obtaining vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerability from a vulnerability patch library includes: Obtain vulnerability information of the potential vulnerability; the vulnerability information includes a common vulnerability disclosure identifier; The vulnerability patch information and the vulnerability patch code block corresponding to the vulnerability information are obtained from the vulnerability patch library.

4. The method according to claim 1, characterized in that: The dynamically inserting the target process of the application package to be detected through the virtual machine tool interface to obtain all loaded classes in the target process includes: Obtaining the process IDs of all running processes in the application package to be detected, and determining the target process according to the process IDs; The agent program is attached to the target process through the virtual machine tool interface, so as to obtain all loaded classes in the virtual machine of the target process through the agent program.

5. The method according to claim 1, characterized in that: The comparing and analyzing the first control flow graph and the second control flow graph includes: Performing depth-first search on the first control flow graph and the second control flow graph respectively to obtain corresponding first program call chains and second program call chains; Merging the first program call chain and the second program call chain for the same items respectively to obtain a corresponding first node set and a second node set; A comparative analysis is performed on the subset relationship and the node execution order of the first node set and the second node set.

6. The method according to claim 5, characterized in that The obtaining the vulnerability repair information of the application package to be detected according to the result of the comparative analysis includes: When the second node set is not a subset of the first node set, or the node execution order of the second node set is inconsistent with the node execution order of the first node set, it is determined that the potential vulnerability corresponding to the vulnerability patch code corresponding to the second node set has not been repaired.

7. A vulnerability repair detection device, characterized in that: The device comprises: A vulnerability acquisition module is used to acquire multiple potential vulnerabilities of the application package to be detected, and to acquire vulnerability patch information and vulnerability patch code blocks corresponding to the potential vulnerabilities from a vulnerability patch library; A target class acquisition module is used to dynamically instrument the target process of the application package to be detected through a virtual machine tool interface, obtain all loaded classes in the target process, filter the loaded classes according to the vulnerability patch information, and obtain the target class; A decompilation processing module, used for decompiling the bytecode of the target class to obtain a target code block, and respectively obtaining a first control flow graph of the target code block and a second control flow graph of the vulnerability patch code block; A comparison and analysis module is used to compare and analyze the first control flow graph and the second control flow graph, and obtain vulnerability repair information of the application package to be detected based on the results of the comparison and analysis; the vulnerability repair information includes potential vulnerabilities that have not been repaired in the application package to be detected.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.