Binary program-oriented unknown vulnerability mining method and related device

CN123013103APending Publication Date: 2026-10-30ANNING BUREAU OF ULTRA HIGH VOLTAGE TRANSMISSION
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611043588.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-14
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

[0004]在此条件下,反汇编或反编译方法虽然能够恢复部分指令和函数边界,但难以形成统一、完备的程序表示

Benefits of technology

[0016]为实现上述目的,本申请实施例的另一方面提出了一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时实现上述的方法。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123013103A_ABST
    Figure CN123013103A_ABST
Patent Text Reader

Abstract

The application provides a binary program unknown vulnerability mining method and related equipment, and belongs to the technical field of information security. The method comprises the following steps: performing program analysis and infrastructure recovery on a target file in the form of a binary program to obtain program basic analysis results; performing program semantic recovery and multi-dimensional relationship extraction on the program basic analysis results to obtain program intermediate representation results; performing graph modeling on multiple types of nodes and multiple types of edges of the target file according to the program intermediate representation results to obtain code attribute graph construction results; performing source code free taint propagation analysis on the code attribute graph construction results to obtain candidate dangerous propagation path results; performing vulnerability mode query and rule matching on the candidate dangerous propagation path results to obtain potential vulnerability mining results; and performing result aggregation and comprehensive scoring on the potential vulnerability mining results to obtain unknown vulnerability mining results. The application can improve the unknown vulnerability mining depth and analysis accuracy under the condition of no source code.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a method and related equipment for discovering unknown vulnerabilities in binary programs. Background Technology

[0002] With the continuous promotion of domestically developed IT software in critical infrastructure fields such as power, energy, government affairs, and industrial control, conducting security testing, vulnerability discovery, and risk management around domestically developed IT software has become an important foundation for ensuring business continuity and reliable system operation.

[0003] Vulnerability analysis techniques mostly rely on source code, symbol information, or debugging information to conduct syntax analysis, control flow analysis, and data flow analysis. However, in actual deployment scenarios of domestically developed software, the objects under test usually exist only as binary executable files, library files, or intermediate representations, lacking source code information that can be directly used for analysis.

[0004] Under these conditions, while disassembly or decompilation methods can recover some instruction and function boundaries, they struggle to form a unified and complete program representation. Due to the lack of accurate recovery of program structure and semantics, they often only uncover superficial issues such as formatting errors and dangerous function calls, failing to identify hidden data dependency defects, cross-path propagation defects, and complex exploit chain vulnerabilities, resulting in insufficient capabilities for discovering unknown vulnerabilities. Summary of the Invention

[0005] The main objective of this application is to propose a method and related equipment for discovering unknown vulnerabilities in binary programs, aiming to improve the depth and accuracy of unknown vulnerability discovery and analysis under conditions without source code.

[0006] To achieve the above objectives, one aspect of this application proposes a method for discovering unknown vulnerabilities in binary programs, the method comprising the following steps: The object file in binary program form is parsed and its basic structure is restored to obtain the basic program analysis results. The program semantics are restored and multidimensional relationships are extracted from the program's basic analysis results to obtain the intermediate representation of the program. Based on the intermediate representation results of the program, graph modeling is performed on the multiple types of nodes and multiple types of edges of the target file to obtain the code attribute graph construction results; The code attribute graph construction results are subjected to source code-free taint propagation analysis to obtain candidate dangerous propagation path results; Based on the code attribute graph construction results and the candidate danger propagation path results, vulnerability pattern queries and rule matching are performed on the target file to obtain potential vulnerability mining results. The results of the potential vulnerability discovery are aggregated and comprehensively scored to obtain the results of the unknown vulnerability discovery.

[0007] In some embodiments, the program fundamental analysis results include a function information table, basic block partitioning results, instruction parsing results, and an initial function call relationship table. The process of parsing and restoring the basic structure of a binary program object file to obtain the program fundamental analysis results includes the following steps: The format of the object file in binary program form is identified to obtain the program entry address, load layout information and code region information; The machine code of the code region information is disassembled and parsed to obtain the instruction parsing result, wherein the instruction parsing result is an instruction sequence organized by address, the instruction sequence includes the opcode, operands and instruction type of each instruction, and the instruction type includes jump instructions, call instructions and return instructions; The function boundary is identified based on the program entry address and the target address corresponding to the calling instruction, and the function information table is obtained. Based on the function information table and the jump instruction, the basic block is divided to obtain the basic block division result consisting of single-entry and single-exit instruction fragments; The initial function call relationship table is obtained by extracting the call relationship based on the function information table and the call instruction.

[0008] In some embodiments, the intermediate representation results of the program include a control flow graph, a data flow relation table, an alias association table, a cross-functional dependency relation table, and an approximate representation result of the program structure. The step of performing program semantic recovery and multi-dimensional relation extraction on the program's basic analysis results to obtain the intermediate representation results includes the following steps: Based on the program fundamental analysis results, control flow analysis is performed on jump instructions and branch relationships to obtain the control flow graph; Based on the program fundamental analysis results, data flow analysis is performed on the read and write operations of the program object to obtain the data flow relationship table; Based on the program fundamental analysis results, alias analysis is performed on the program objects to obtain the alias association table. The alias association table is used to record the program objects with alias relationships. The alias relationship indicates that multiple program objects point to the same memory object or reference the same storage area. Based on the program fundamental analysis results, cross-function dependencies are recovered through function parameter passing, return value passing, and shared memory access behavior to obtain the cross-function dependency table; Based on the program fundamental analysis results, the control flow graph, the data flow relation table, the alias association table, and the cross-functional dependency relation table, the missing structure tree is approximated to obtain the approximate representation of the program structure.

[0009] In some embodiments, the code attribute graph construction result includes a code attribute graph node set, a code attribute graph edge set, a node attribute table, an edge attribute table, and a complete code attribute graph. The step of performing graph modeling on the multiple types of nodes and edges of the target file based on the intermediate representation result of the program to obtain the code attribute graph construction result includes the following steps: Based on the intermediate representation results of the program, the functions, basic blocks, instructions, program objects, external input points, and sensitive operation points of the target file are abstracted into graph nodes and node attributes are recorded to obtain the code attribute graph node set and the node attribute table; Based on the intermediate representation results of the program, the control dependencies, data dependencies, calling relationships, parameter passing relationships, alias relationships, and attribute subordination relationships of the target file are abstracted into graph edges and edge attributes are recorded to obtain the code attribute graph edge set and the edge attribute table; The complete code attribute graph is obtained by performing graph modeling based on the set of nodes in the code attribute graph, the node attribute table, the set of edges in the code attribute graph, and the edge attribute table.

[0010] In some embodiments, the candidate hazard propagation path results include a set of taint source nodes, a set of sensitive sink nodes, a set of candidate hazard propagation paths, and a taint propagation relationship table. The step of performing source-code-free taint propagation analysis on the code attribute graph construction results to obtain the candidate hazard propagation path results includes the following steps: Based on preset pollution behaviors, the pollution source is located in the code attribute graph construction result to obtain the pollution source node set, wherein the pollution behaviors include user input, network packets, file input, device interaction input, and inter-process communication input; Sensitive sink points are located based on the code attribute graph construction result based on preset sensitive behaviors, and the sensitive sink point node set is obtained. The sensitive behaviors include command execution, dangerous memory writing, sensitive file access, system calls, access control and database operations. Using the pollution source node as the starting node and the sensitive sink node as the target node, the propagation chain of the relationship between the starting node and the target node is traced and identified based on the code attribute graph construction result, and the pollution propagation relationship table is obtained. Based on the taint propagation relationship table, the intermediate nodes between the starting node and the target node are taken as propagation path nodes to obtain the candidate dangerous propagation path set.

[0011] In some embodiments, the potential vulnerability discovery results include a set of potential vulnerability points, vulnerability type matching results, vulnerability propagation path results, and a set of vulnerability evidence fragments. The step of performing vulnerability pattern querying and rule matching on the target file based on the code attribute graph construction results and the candidate dangerous propagation path results to obtain the potential vulnerability discovery results includes the following steps: By encapsulating code structure features, data flow constraints, control condition constraints, function call context constraints, and sensitive operation constraints, the preset vulnerability patterns are transformed into executable query rules. Based on the executable query rules and the results of the dangerous propagation paths, a graph query matching is performed on the code attribute graph construction results to identify potential vulnerability points, vulnerability propagation paths, and dangerous code fragments in the target file that conform to the vulnerability pattern, thereby obtaining the vulnerability point set, the vulnerability type matching results, the vulnerability propagation path results, and the vulnerability evidence fragment set.

[0012] In some embodiments, the unknown vulnerability discovery results include a vulnerability result ranking table, vulnerability location and path description results, and vulnerability evidence output results. The process of aggregating and comprehensively scoring the potential vulnerability discovery results to obtain the unknown vulnerability discovery results includes the following steps: Based on the vulnerability point set, the vulnerability type matching result, the vulnerability propagation path result, and the vulnerability evidence fragment set, potential vulnerabilities are associated and integrated. Potential vulnerabilities with at least one identical vulnerability location, sensitive sink point, vulnerability type, and vulnerability propagation path are grouped into the same vulnerability record to obtain vulnerability aggregation result. The vulnerability aggregation results are deduplicated to obtain the vulnerability deduplication results; The deduplication results of the vulnerability are structured to obtain the vulnerability location and path description results and the vulnerability evidence output results; The deduplication results of the vulnerabilities are comprehensively evaluated based on the length of the vulnerability propagation chain, the risk level of sensitive operations, the degree of path constraint satisfaction, the complexity of the call context, and the completeness of evidence to obtain a comprehensive vulnerability score. The vulnerabilities are then sorted according to the comprehensive vulnerability score to obtain a vulnerability result ranking table.

[0013] To achieve the above objectives, another aspect of this application proposes a system for discovering unknown vulnerabilities in binary programs, the system comprising: The first module is used to parse and restore the basic structure of the target file in binary program form to obtain the basic program analysis results. The second module is used to perform program semantic recovery and multidimensional relation extraction on the program basic analysis results to obtain the intermediate representation results of the program. The third module is used to perform graph modeling on the multiple types of nodes and multiple types of edges of the target file based on the intermediate representation results of the program, and to obtain the code attribute graph construction results. The fourth module is used to perform source code-free taint propagation analysis on the code attribute graph construction results to obtain candidate dangerous propagation path results; The fifth module is used to perform vulnerability pattern query and rule matching on the target file based on the code attribute graph construction results and the candidate danger propagation path results to obtain potential vulnerability mining results; The sixth module is used to aggregate and comprehensively score the potential vulnerability discovery results to obtain the unknown vulnerability discovery results.

[0014] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0016] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0017] The embodiments of this application include at least the following beneficial effects: This application provides a method and related equipment for mining unknown vulnerabilities in binary programs. This scheme obtains program fundamental analysis results by parsing and restoring the basic structure of a target file in binary program form; extracting program semantics and multi-dimensional relationships from the program fundamental analysis results to obtain intermediate program representation results; performing graph modeling on multiple types of nodes and edges of the target file based on the intermediate program representation results to obtain code attribute graph construction results; performing source-code-free taint propagation analysis on the code attribute graph construction results to obtain candidate dangerous propagation path results; performing vulnerability pattern querying and rule matching on the candidate dangerous propagation path results to obtain potential vulnerability mining results; and aggregating and comprehensively scoring the potential vulnerability mining results to obtain unknown vulnerability mining results. This application can form a unified program semantic representation foundation under source-code-free conditions, and improve the depth and accuracy of unknown vulnerability mining by tracking taint propagation based on relationships in the code attribute graph. Attached Figure Description

[0018] Figure 1 This is a flowchart of an unknown vulnerability discovery method for binary programs provided in an embodiment of this application; Figure 2 This is a flowchart of another embodiment of the method for discovering unknown vulnerabilities in binary programs provided in this application; Figure 3 This is a schematic diagram of the structure of an unknown vulnerability mining system for binary programs provided in an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of systems and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] Before providing a detailed description of the embodiments of this application, the relevant technologies involved in the embodiments of this application will be described first.

[0022] In related technologies, security analysis of binary programs typically generates various intermediate results, such as control flow graphs (CFG), call graphs (CG), data flow relationships, and approximate representations of abstract syntactic structures. These analysis results are often stored separately and are independent of each other, lacking a unified modeling and joint reasoning mechanism, making it difficult to form an integrated program representation that covers multi-dimensional information such as "syntax, semantics, dependency, and call".

[0023] In the process of vulnerability discovery, many real-world vulnerabilities rely on the superposition of multiple relationships, such as external input reaching a sensitive point after multiple function calls, conditional branches, and memory operations. Without a unified code attribute graph mechanism, it is difficult to effectively express the complex characteristics of cross-level, cross-function, and cross-path vulnerabilities, thus limiting the ability to automatically discover unknown vulnerabilities.

[0024] Furthermore, most taint propagation analysis methods are designed for high-level language source code, where default variable definitions, parameter passing, and object lifecycles are relatively well-defined. However, in binary programs, register reuse is frequent, stack frame structures are unstable, memory alias relationships are complex, and there are numerous indirect calls, jump tables, inlining optimizations, and compiler reorderings, making it difficult to directly apply traditional taint propagation rules.

[0025] In the context of domestically developed software, programs typically contain numerous local interface calls, device interaction logic, mixed file and network input paths, and program structures generated by specific compilation chains. This makes taint source identification, taint propagation edge recovery, and taint convergence point determination more complex. In these scenarios, issues such as taint path interruption, propagation range distortion, or path expansion can easily occur, leading to both false negatives and false negatives, making it difficult to meet the requirements for accurate discovery of unknown vulnerabilities.

[0026] In view of this, this application provides a method and related equipment for mining unknown vulnerabilities in binary programs. This method involves parsing and restoring the basic structure of a target file in binary program form to obtain a basic program analysis result; performing semantic restoration and multi-dimensional relationship extraction on the basic program analysis result to obtain an intermediate program representation result; performing graph modeling on multiple types of nodes and edges of the target file based on the intermediate program representation result to obtain a code attribute graph construction result; performing source-code-free taint propagation analysis on the code attribute graph construction result to obtain candidate hazard propagation path results; performing vulnerability pattern query and rule matching on the candidate hazard propagation path results to obtain potential vulnerability mining results; and aggregating and comprehensively scoring the potential vulnerability mining results to obtain unknown vulnerability mining results. This method can improve the depth and accuracy of unknown vulnerability mining under source-code-free conditions.

[0027] The method for discovering unknown vulnerabilities in binary programs provided in this application relates to the field of information security. This method can be applied to terminals, servers, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the method for discovering unknown vulnerabilities in binary programs, but is not limited to the above forms.

[0028] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0029] Figure 1 This is an optional flowchart of an unknown vulnerability discovery method for binary programs provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S106.

[0030] Step S101: Perform program parsing and basic structure recovery on the target file in binary program form to obtain the program basic analysis results.

[0031] Step S102: Perform program semantic recovery and multidimensional relation extraction on the program basic analysis results to obtain the intermediate representation results of the program.

[0032] Step S103: Based on the intermediate representation results of the program, perform graph modeling on the multiple types of nodes and edges of the target file to obtain the code attribute graph construction result.

[0033] Step S104: Perform source code-free taint propagation analysis on the code attribute graph construction results to obtain candidate dangerous propagation path results.

[0034] Step S105: Based on the code attribute graph construction results and candidate danger propagation path results, perform vulnerability pattern query and rule matching on the target file to obtain potential vulnerability discovery results.

[0035] Step S106: Aggregate and comprehensively score the potential vulnerability discovery results to obtain the unknown vulnerability discovery results.

[0036] In this embodiment, to achieve unified modeling of the program structure and semantic information of source code-less domestically developed software, and on this basis, to complete automated unknown vulnerability mining, this embodiment uses a collaborative mechanism of binary parsing, program semantic recovery, code attribute graph construction, source code-less taint propagation, and vulnerability pattern query to realize the construction of a unified semantic graph for source code-less domestically developed software, construct a taint propagation analysis mechanism suitable for binary programs, and establish a query interface oriented towards vulnerability patterns. This can improve the automated mining capability, thereby enhancing the accuracy and scalability of unknown vulnerability mining.

[0037] Specifically, the binary executable file, dynamic link library file, intermediate code file, or other analyzable program object in the form of the domestic software binary program is first used as the target file, and the original program file is parsed and its basic structure is restored.

[0038] The program parser identifies the code region for disassembly parsing through format recognition, and then performs disassembly parsing on the code region to convert the binary machine language into assembly language.

[0039] The basic structure recovery is based on the analysis of function boundaries, basic block division and initial call relationship extraction in parsed assembly language, so as to obtain the basic analysis results of the underlying structure of the binary program.

[0040] Next, based on the program fundamental analysis results obtained in step S101, program semantic recovery and multidimensional relationship extraction methods are used to further extract higher-level program semantics and multidimensional relationships from the underlying structure, resulting in intermediate program representation results including control path relationships, data transfer relationships, memory object association relationships, and cross-function call dependency relationships.

[0041] Furthermore, in order to uniformly model control flow, data flow, call relationships, alias relationships, and node attribute information into a queryable and scalable graph structure, this embodiment performs graph modeling on multiple types of nodes and edges of the target file based on the intermediate representation results of the program, and obtains the code attribute graph construction results.

[0042] The code attribute graph construction results can utilize the attribute information of the program carried by the nodes, and establish various relationships between the nodes through edges, thereby providing a unified graph structure foundation for subsequent source code-free taint propagation analysis.

[0043] Taint propagation analysis is a method for tracing and analyzing the flow path of input data from "source" to "sink" in a program. By constructing a code property graph, all nodes that allow input data are treated as taint sources, and nodes containing dangerous operations are treated as sensitive sinks. The flow and propagation of taint sources in the code property graph are observed and tracked. It is checked whether the data from the taint source eventually reaches the sensitive sink, thereby tracking and recovering the taint propagation path. This improves the completeness and accuracy of dangerous propagation chain identification in complex binary program scenarios and yields candidate dangerous propagation path results.

[0044] To improve the ability to automatically discover unknown vulnerabilities, this embodiment pre-establishes a query interface based on the code attribute graph construction results and candidate danger propagation path results. Through the query interface, common vulnerability patterns are matched by rules to automatically discover vulnerabilities and obtain potential vulnerability discovery results. This reduces the complexity of security researchers directly manipulating the underlying graph structure and improves rule reusability and automated analysis efficiency.

[0045] It is understandable that the potential vulnerability discovery results contain a large number of vulnerability records, some of which are high-risk, while others may only be general suspicious paths. In order to improve the credibility and acceptability of the vulnerability output results, this embodiment performs result aggregation and comprehensive scoring on the potential vulnerability discovery results. By using aggregation, deduplication, sorting and output, unknown vulnerability discovery results are formed for security analysis and platform display.

[0046] In some embodiments, step S101 may include, but is not limited to, steps S201 to S205.

[0047] Step S201: The target file in binary program form is formatted to obtain the program entry address, load layout information and code region information.

[0048] Step S202: Disassemble and parse the machine code of the code region information to obtain the instruction parsing result. The instruction parsing result is an instruction sequence organized by address. The instruction sequence includes the opcode, operands and instruction type of each instruction. The instruction type includes jump instructions, call instructions and return instructions.

[0049] Step S203: Based on the program entry address and the target address corresponding to the calling instruction, function boundary identification is performed to obtain the function information table.

[0050] Step S204: Based on the function information table and jump instructions, perform basic block partitioning to obtain the basic block partitioning result consisting of single-entry and single-exit instruction fragments.

[0051] Step S205: Extract the call relationship based on the function information table and the call instructions to obtain the initial function call relationship table.

[0052] In this embodiment, the program basic analysis results include a function information table, basic block partitioning results, instruction parsing results, and an initial function call relationship table. The function information table, basic block partitioning results, and instruction parsing results provide the program basic structure basis for the control flow analysis, data flow analysis, and alias analysis in the next step, while the initial function call relationship table provides call entry information for subsequent cross-function dependency recovery.

[0053] Specifically, the binary executable file, dynamic link library file, intermediate code file, or other analyzable program object of the software to be tested are taken as input, and the program basic structure restoration process is preferably performed in the order of format recognition, disassembly parsing, function boundary recognition, basic block division, and initial call relationship extraction.

[0054] During the format recognition stage, the file type, program header information, section / segment layout, load base address, code segment location, data segment location, program entry address, and import / export information of the target file in binary program form are identified. From this, key information such as program entry address, load layout information, and code region information are extracted. This information is mainly used to determine the target code region, address mapping relationship, and initial entry position for subsequent disassembly parsing and function boundary recognition.

[0055] During the disassembly and parsing stage, based on the code segment location and address information obtained from format recognition, the machine code in the target code region is disassembled to obtain an instruction sequence organized by address. The opcode, operands, and instruction type of each instruction in the instruction sequence are identified, thus forming the instruction parsing result. This provides an instruction-level basis for basic block partitioning and initial call relationship extraction. The instruction types include jump instructions, call instructions, and return instructions. Jump instructions are used for basic block partitioning, while call instructions are used for initial function call relationship extraction. Operands are the data objects operated on during instruction execution. Together with the opcode, they constitute a complete instruction. The opcode determines "what to do," while the operand determines "to whom to do it."

[0056] During the function boundary identification stage, based on the program entry address, the target address of the calling instruction, function entry characteristics, and the reachability of control transfer, the starting address and ending range of functions in the program are identified, and the instruction range contained in each function is determined, thereby forming a function information table. The function information table formed through function boundary identification provides function context for the attribution of basic blocks and calling relationships.

[0057] It should be noted that the function information table includes at least the function identifier, entry address, end address, and the instruction range to which it belongs.

[0058] During the basic block partitioning phase, a basic block is a continuous sequence of instructions in the program that satisfies the following conditions: control flow can only enter from the first statement of the block and exit from the last statement, without being interrupted by jumps or being executed repeatedly. Each basic block has a unique entry point and a unique exit point; once entered, all instructions within the block are executed sequentially. Based on the function boundary identification results and the instruction sequence obtained from disassembly, the instructions within functions are processed. According to the jump target location, the branch successor location, and the control transfer boundaries formed by jump / return instructions, the instruction sequence is partitioned to obtain basic block partitioning results consisting of single-entry, single-exit instruction fragments.

[0059] In the initial call relationship extraction stage, the call relationship between the function containing the call instruction and the target function is extracted based on the call instructions obtained from disassembly and the function boundary identification results.

[0060] Optionally, if the call target cannot be resolved to an internal function, it can be marked as an external call relationship. An initial function call relationship table is formed by summarizing these different call relationships.

[0061] In summary, this embodiment recovers the basic structural information of a program by identifying the program entry address, function boundaries, instruction sequences, jump instructions, and call instructions, and organizes the functions, basic blocks, and instruction levels in the binary program, providing basic input for subsequent control flow analysis and data flow analysis.

[0062] In some embodiments, step S102 may include, but is not limited to, steps S301 to S305.

[0063] Step S301: Perform control flow analysis on jump instructions and branch relationships based on the program basic analysis results to obtain a control flow graph.

[0064] Step S302: Perform data flow analysis on the read and write operations of the program object based on the program basic analysis results to obtain a data flow relationship table.

[0065] Step S303: Based on the results of the basic program analysis, perform alias analysis on the program objects to obtain an alias association table. The alias association table is used to record program objects with alias relationships. The alias relationship indicates that multiple program objects point to the same memory object or reference the same storage area.

[0066] Step S304: Based on the program's fundamental analysis results, restore the cross-function dependency relationship through function parameter passing, return value passing, and shared memory access behavior to obtain the cross-function dependency relationship table.

[0067] Step S305: Based on the program basic analysis results, control flow graph, data flow relationship table, alias association table, and cross-functional dependency relationship table, perform structural approximation processing on the missing structure tree to obtain the program structure approximation representation result.

[0068] In this embodiment, the intermediate representation result is a multi-dimensional intermediate representation describing the program execution logic and data behavior, including a control flow graph, a data flow relation table, an alias association table, a cross-functional dependency relation table, and an approximate representation result of the program structure. The control flow graph, data flow relation table, alias association table, and cross-functional dependency table will serve as the core inputs for the next step of constructing the code attribute graph, and the approximate representation result of the program structure is used to supplement the semantic information and structural attribute information of the nodes.

[0069] Specifically, based on the function information table, basic block partitioning results, instruction parsing results, and initial function call relationship table obtained in the aforementioned steps, control flow analysis is further performed on the target file to be tested. In this step, each function is used as a unit, and the basic blocks inside each function are used as nodes. Graph edges are constructed according to the instruction types of the basic blocks.

[0070] For example, if the instruction in the current basic block is a jump instruction, and the jump instruction is unconditional, then a directed edge is established between the current basic block and the target basic block; if the jump instruction is conditional, then the program has two possible paths: one corresponding to jump to the specified basic block when the condition is met, and the other corresponding to jump to another basic block when the condition is not met. By traversing all basic blocks, a control flow graph is finally generated, and the directed edges in the control flow graph represent the control dependencies of the target file.

[0071] Meanwhile, based on the function information table, basic block partitioning results, instruction parsing results, and initial function call relationship table obtained from the aforementioned steps, data dependencies are extracted by tracking the read and write operations of program objects to obtain a data flow relationship table. Among these, program objects include registers, stack variables, heap objects, and memory.

[0072] For example, the mov instruction writes a value to a register or memory address, while the add instruction reads the value from the register and performs operations. The dependency caused by reading and writing the same program object is called a data dependency, which determines the execution order of instructions.

[0073] Alias ​​analysis examines the consistency of references, address passing relationships, base-address-offset access relationships, pointer assignment relationships, and cross-function parameter passing relationships among registers, stack variables, heap objects, and memory reference objects in a binary program. It identifies whether multiple program objects might point to the same memory object or reference the same storage region. After identifying pairs of objects with alias relationships, it records information such as object identifier, object type, associated address range, alias type, and the function context in which it resides, thus forming an alias association table.

[0074] Cross-function dependencies describe how the execution or data state of one function depends on the output or global state of another function. In this embodiment, cross-function dependencies are restored based on function information tables, basic block partitioning results, instruction parsing results, and initial function call relationship tables, through function parameter passing, return value passing, and shared memory access behavior.

[0075] Since this application deals with binary programs, which lack precise syntactic information such as source code-level abstract syntax trees, the approximate representation of the program structure is based on the function information table, basic block partitioning results, instruction parsing results, and initial function call relationship table, combined with the control flow graph, data flow relationship table, alias association table, and cross-function dependency relationship table. This structured representation is obtained by uniformly abstracting, hierarchically organizing, and integrating the relationships of functions, basic blocks, instructions, variables, registers, and memory objects in the program.

[0076] Understandably, the approximate representation of the program structure is obtained based on the aforementioned multi-type analysis data, according to control dependencies, data dependencies, call relationships, and object associations, after unified abstraction and structural organization. It is mainly used to supplement the structural attribution information and semantic association information of program nodes, and serves as one of the inputs for the subsequent construction of the code attribute graph.

[0077] In some embodiments, step S103 may include, but is not limited to, steps S401 to S403.

[0078] Step S401: Based on the intermediate representation results of the program, the functions, basic blocks, instructions, program objects, external input points and sensitive operation points of the target file are abstracted into graph nodes and the node attributes are recorded to obtain the code attribute graph node set and the node attribute table.

[0079] Step S402: Based on the intermediate representation results of the program, the control dependency, data dependency, calling relationship, parameter passing relationship, alias relationship and attribute subordination relationship of the target file are abstracted into graph edges and edge attributes are recorded to obtain the code attribute graph edge set and edge attribute table.

[0080] Step S403: Perform graph modeling based on the code attribute graph node set, node attribute table, code attribute graph edge set, and edge attribute table to obtain a complete code attribute graph.

[0081] In this embodiment, the code attribute graph construction result includes a code attribute graph node set, a code attribute graph edge set, a node attribute table, an edge attribute table, and a complete code attribute graph. The code attribute graph node set, edge set, and complete code attribute graph provide a unified graph structure foundation for the next step of source code-free taint propagation analysis, while the node attribute table and edge attribute table provide attribute support for subsequent taint source identification, sensitive sink identification, and vulnerability pattern constraint matching.

[0082] Specifically, based on the control flow graph, data flow relationship table, alias association table, cross-function dependency relationship table, and approximate representation of program structure obtained from the intermediate representation results of the program, functions, basic blocks, instructions, registers, variables, memory objects, external input points, and sensitive operation points are abstracted into graph nodes, and node attributes are attached to the nodes. Among them, node attributes include, but are not limited to, type identifier, address information, belonging function information, context attributes, and risk marker information, resulting in a code attribute graph node set and a node attribute table.

[0083] For example, each function node corresponds to a function in the program. When a function node is created, the node attributes such as the function representation, the function start address, and the function end address are recorded through the node attribute table, and these attribute information is associated with the function node.

[0084] Basic block nodes correspond to the basic blocks in the program. When a basic block node is created, the node attribute table records the node attributes such as the basic block start address, basic block end address, entry statement, and exit statement, and associates these attribute information with the basic block node.

[0085] Each instruction node corresponds to a single instruction obtained from instruction parsing. When an instruction node is created, its attributes, such as instruction address, opcode, operands, instruction type, instruction length, instruction jump target address, or instruction call target address, are recorded in the node attribute table, and these attribute information is associated with the instruction node.

[0086] Program object nodes encompass program objects that carry data, such as registers, variables, and memory objects. When creating a program object node, a corresponding node is created for each program object, and the node attributes are recorded and associated with the program object node.

[0087] External input point nodes correspond to locations that can receive external input data, while sensitive operation point nodes correspond to locations in the program that may perform security-sensitive operations or leak private data to external devices. These two types of nodes can be created as independent node types, or they can be achieved by attaching node labels to existing nodes.

[0088] After completing the node construction, control dependencies, data dependencies, call relationships, parameter passing relationships, alias relationships, and attribute subordination relationships are abstracted into graph edges, and edge attribute information is attached to the edges to obtain the code attribute graph edge set and edge attribute table.

[0089] For example, by traversing the control flow graph, a control dependency edge is created for each directed edge in the control flow graph, wherein the direction of the control dependency edge is consistent with the direction of the directed edge.

[0090] By traversing the data flow relationship table, a data dependency edge is created for each record according to the data usage and transmission direction.

[0091] By traversing the cross-function dependency table and the initial function call table, a call edge is created for each function call based on the function call and the called state.

[0092] The parameter passing edge is created for each parameter passing based on the function parameter passing and return value passing information recorded across function dependencies.

[0093] By traversing the alias association table, for program object nodes with alias relationships, an alias edge is created between the two nodes. Since alias relationships are usually symmetrical, you can choose to create a bidirectional edge or create a directed edge and record the symmetrical relationship in the edge attribute.

[0094] Based on the subordinate relationships such as inclusion, belonging, or association between functions, basic blocks, instructions, and parameters, an attribute subordinate edge is established between two nodes.

[0095] Finally, based on the completed code attribute graph node set, node attribute table, code attribute graph edge set, and edge attribute table, a unified model is constructed for the various types of nodes and edges in the program, resulting in a complete code attribute graph for binary programs of domestically developed software.

[0096] In some embodiments, step S104 may include, but is not limited to, steps S501 to S504.

[0097] Step S501: Based on the preset pollution behavior, locate the pollution source of the code attribute graph construction result to obtain a set of pollution source nodes. The pollution behavior includes user input, network packets, file input, device interaction input, and inter-process communication input.

[0098] Step S502: Based on preset sensitive behaviors, locate sensitive sinks in the code attribute graph construction results to obtain a set of sensitive sink nodes. Among them, sensitive behaviors include command execution, dangerous memory writing, sensitive file access, system calls, access control and database operations.

[0099] Step S503: Using the pollution source node as the starting node and the sensitive sink node as the target node, the propagation chain of the relationship between the starting node and the target node is traced and identified based on the code attribute graph construction results, and a taint propagation relationship table is obtained.

[0100] Step S504: Based on the taint propagation relationship table, the intermediate nodes between the starting node and the target node are taken as propagation path nodes to obtain a set of candidate hazard propagation paths.

[0101] In this embodiment, the candidate hazard propagation path results include a set of tainted source nodes, a set of sensitive sink nodes, a set of candidate hazard propagation paths, and a tainted propagation relationship table. The set of candidate hazard propagation paths and the tainted propagation relationship table will serve as the main inputs for the next step of vulnerability pattern query and automated mining. The set of tainted source nodes and the set of sensitive sink nodes will be used to constrain the range of vulnerability rule matching, thereby improving mining efficiency and accuracy.

[0102] Specifically, in the process of pollution source location and processing, by identifying preset pollution behaviors, nodes with behaviors such as user input, network packets, file input, device interaction input, and inter-process communication input are identified as pollution sources, and all identified pollution sources are integrated to obtain a set of pollution source nodes.

[0103] During the sensitive node location process, nodes with behaviors such as command execution, dangerous memory writing, sensitive file access, system calls, access control, and database operations are identified by recognizing preset sensitive behaviors. All identified sensitive nodes are then integrated to obtain a set of sensitive node nodes.

[0104] Next, using the taint source node as the starting node and the sensitive sink node as the target node, taint propagation analysis is performed on the graph structure based on the data dependency edges, control dependency edges, call edges, and parameter passing edges in the code property graph, and the relationships between nodes are continuously tracked.

[0105] For example, on the complete code property graph, reachable paths that satisfy propagation constraints between the two are identified, and propagation chains formed by one or more intermediate nodes and one or more edges connecting the taint source node to the sensitive sink node are identified to discover candidate dangerous propagation paths from external input to sensitive operation, thereby obtaining potential risk propagation chains in cross-block, cross-function and cross-module scenarios, and obtaining a taint propagation relationship table.

[0106] It should be noted that the danger propagation path can be a propagation chain from the taint source to the sensitive sink, consisting of one or more combinations of data dependency edges, control dependency edges, call edges, and parameter passing edges.

[0107] Meanwhile, intermediate nodes located between the starting node and the target node in the propagation chain are taken as propagation path nodes to obtain a set of candidate dangerous propagation paths.

[0108] In some embodiments, step S105 may include, but is not limited to, steps S601 to S602.

[0109] Step S601 involves encapsulating code structure features, data flow constraints, control condition constraints, function call context constraints, and sensitive operation constraints to transform the preset vulnerability pattern into executable query rules.

[0110] Step S602: Perform graph query matching on the code attribute graph construction result based on the executable query rules and dangerous propagation path results to identify potential vulnerability points, vulnerability propagation paths and dangerous code fragments that match the vulnerability pattern in the target file, and obtain the vulnerability point set, vulnerability type matching result, vulnerability propagation path result and vulnerability evidence fragment set.

[0111] In this embodiment, the potential vulnerability discovery results include at least a set of potential vulnerability points, vulnerability type matching results, vulnerability propagation path results, and a set of vulnerability evidence fragments. The set of potential vulnerability points, vulnerability type matching results, and vulnerability propagation path results will serve as inputs for the vulnerability results output and display in the next step, while the set of vulnerability evidence fragments will be used to support analysts in locating, reviewing, and interpreting the vulnerability results.

[0112] Specifically, vulnerability patterns can be mainly divided into command injection, path traversal, out-of-bounds access, unvalidated input propagation, misuse of dangerous interfaces, and privilege bypass. This embodiment encapsulates code structure features, data flow constraints, control condition constraints, function call context constraints, and sensitive operation constraints to transform the above vulnerability patterns into executable query rules, thereby establishing a query language interface for vulnerability mining.

[0113] Then, based on the preset vulnerability pattern constructed through executable query rules, the target program is automatically queried based on the code attribute graph and the candidate dangerous propagation path results. Through graph query matching, potential vulnerability points, vulnerability paths and dangerous code fragments in the program are identified, and candidate results that match the vulnerability pattern are output, resulting in a set of vulnerability points, vulnerability type matching results, vulnerability propagation path results and a set of vulnerability evidence fragments.

[0114] For example, the candidate hazard propagation path results may include at least the identifier and type of the starting taint source node, the identifier and type of the ending sensitive sink node, the sequence of intermediate nodes traversed by the path, the type sequence of each edge in the path, the function, basic block or module identifier involved in the path, the path length, the number of times crossing functions, the number of times crossing modules, and whether there are constraint information such as verification nodes, filtering nodes, boundary check nodes, and permission check nodes in the path.

[0115] During the automatic query process, for each candidate dangerous propagation path, the system sequentially reads the starting point type and ending point type of the path, reads the node type sequence and edge type sequence traversed by the path, determines whether there are corresponding security verification nodes or constraint nodes in the path, and matches the above information with preset vulnerability pattern rules. If the source point constraint, sink point constraint, and path constraint of a certain vulnerability pattern are met but the protection constraint is not met, the path is marked as the corresponding vulnerability type, and the vulnerability point, vulnerability type, propagation path, and evidence fragment corresponding to the path are output.

[0116] It should be noted that the vulnerability evidence fragment set is structured evidence extracted to support the identification of potential vulnerabilities, and includes at least: (1) The taint source node identifier, node type and input source information corresponding to the potential vulnerability.

[0117] (2) Sensitive sink node identifiers, node types and dangerous operation types information corresponding to potential vulnerabilities.

[0118] (3) Critical propagation path segments from taint source nodes to sensitive sink nodes.

[0119] (4) Information on key intermediate nodes on the path and their corresponding data dependency edges, control dependency edges, call edges or parameter passing edges.

[0120] (5) Missing verification, missing filtering, missing boundary checks, missing permission checks, or dangerous interface call conditions related to vulnerability pattern matching.

[0121] (6) The function identifier, basic block identifier, instruction address, offset position or module identifier corresponding to the above nodes and paths.

[0122] In some embodiments, step S106 may include, but is not limited to, steps S701 to S704.

[0123] Step S701: Based on the vulnerability point set, vulnerability type matching result, vulnerability propagation path result, and vulnerability evidence fragment set, potential vulnerabilities are associated and integrated. Potential vulnerabilities with at least one identical vulnerability location, sensitive sink, vulnerability type, and vulnerability propagation path are grouped into the same vulnerability record to obtain vulnerability aggregation result.

[0124] Step S702: Perform deduplication on the vulnerability aggregation results to obtain the deduplicated vulnerability results.

[0125] Step S703: The deduplication results of the vulnerability are structured to obtain the vulnerability location and path description results and the vulnerability evidence output results.

[0126] Step S704: The vulnerability deduplication results are comprehensively evaluated based on the vulnerability propagation chain length, the risk level of sensitive operations, the degree of path constraint satisfaction, the complexity of the call context, and the completeness of evidence to obtain a comprehensive vulnerability score. The vulnerability results are then sorted according to the comprehensive vulnerability score to obtain a vulnerability result ranking table.

[0127] In this embodiment, based on the obtained set of potential vulnerability points, vulnerability type matching results, vulnerability propagation path results, and vulnerability evidence fragments, candidate vulnerabilities are aggregated, deduplicated, sorted, and output to form unknown vulnerability mining results for security analysis and platform display.

[0128] Specifically, the potential vulnerability points, vulnerability types, propagation paths, and evidence fragments are first associated and integrated. Potential vulnerabilities with the same or related vulnerability locations, the same sensitive sinks, the same vulnerability types, or shared key propagation path fragments are grouped into the same vulnerability record to complete vulnerability aggregation and obtain vulnerability aggregation results.

[0129] Subsequently, deduplication is performed on the aggregated vulnerability results. For the same vulnerability record with the same vulnerability location or located in the same instruction address range / basic block range, the same sensitive sink, the same or highly overlapping critical propagation path segments, and the same vulnerability type or evidence segment overlap degree meeting the preset conditions, it can be determined as a duplicate or homogeneous vulnerability record, and merged into a candidate vulnerability record. By deduplicating different vulnerability records, the vulnerability deduplication result is obtained.

[0130] Furthermore, the specific location of the vulnerability, the taint propagation path, and the vulnerability evidence are structured from the vulnerability deduplication results and described in natural language to obtain the vulnerability location and path description results and vulnerability evidence output results.

[0131] After aggregation and deduplication, the system comprehensively considers factors such as the length of the vulnerability propagation chain, the risk level of sensitive operations, the degree of path constraint satisfaction, the complexity of the call context, and the completeness of evidence to give a comprehensive score to the vulnerability.

[0132] For example, the comprehensive vulnerability score can be expressed as: Risk j = α · Path j + β · Sensj + γ · Ctx j + δ · Evid j ; In the formula, j Indicates the vulnerability number. Risk j Indicates the first j The overall vulnerability score for each vulnerability. Path j Indicates the first j Each vulnerability corresponds to a different level of danger in its propagation path. Sens j Indicates the first j Each vulnerability corresponds to a risk level associated with sensitive operations. Ctx j Indicates the first j The complexity of the call context and control conditions in which the vulnerability occurs. Evid j Indicates the first j The completeness of evidence for each vulnerability α , β , γ , δ This indicates the configurable weight coefficient for the corresponding indicator.

[0133] Then, based on the comprehensive vulnerability score, the vulnerabilities are sorted to obtain a vulnerability result ranking table. The higher the comprehensive vulnerability score, the higher the risk of the vulnerability, so as to give priority to outputting the results of high-risk vulnerabilities.

[0134] Optionally, by using a pre-set report template, the vulnerability result sorting table, vulnerability location and path description results, and vulnerability evidence output results can be filled into the corresponding positions to form an automated unknown vulnerability discovery report.

[0135] The following is a detailed description and explanation of the solutions in the embodiments of the present invention, using specific application examples: Unlike traditional general-purpose software, domestically developed IT software typically involves complex deployment environments, diverse components, and long adaptation chains. Furthermore, in practical applications, it is often delivered only as binary programs, dynamic link libraries, intermediate code, or encapsulated components, lacking complete source code information that can be directly used for security analysis. This application's embodiments reveal the following prominent technical problems in the current process of discovering unknown vulnerabilities in domestically developed IT software binary programs: 1. In the absence of source code, the semantic recovery capability of programs is insufficient, making it difficult to support in-depth vulnerability discovery. Vulnerability analysis of related technologies mostly relies on source code, symbol information, or debugging information to conduct syntax analysis, control flow analysis, and data flow analysis. However, in actual deployment scenarios of domestically developed software, the tested object usually exists only as a binary executable file, library file, or intermediate representation, lacking source code information that can be directly used for analysis. Currently, binary analysis methods mainly recover the low-level structure of the program through disassembly, function identification, and basic block division. Under these conditions, although disassembly or decompilation methods can recover some instruction and function boundaries, their ability to recover variable definitions, parameter passing, object boundaries, data object meanings, and high-level syntax structures is weak. Especially in complex optimization or obfuscation scenarios, blurred function boundaries, frequent indirect calls, and hidden cross-module dependencies make it difficult for the analysis results to fully reflect the true logic of the program.

[0136] Due to its limited ability to express high-level semantics, variable dependencies, cross-function call relationships, and complex control logic, binary analysis methods often only perform local rule matching or shallow risk checks, making it difficult to support continuous mining and deep correlation analysis of complex unknown vulnerabilities, resulting in insufficient ability to discover unknown vulnerabilities.

[0137] 2. Fragmented binary analysis results lack a unified code attribute graph representation mechanism. Security analysis of binary programs typically generates multiple intermediate results, such as control flow graphs (CFG), call graphs (CG), data flow relationships, and approximate representations of abstract syntax structures. These analysis results are often stored separately and are independent of each other, lacking a unified association mechanism and a shared data carrying structure.

[0138] For example, control flow graphs mainly describe program execution paths, data flow analysis focuses on variable passing relationships, and function call graphs describe cross-function dependencies. However, current solutions usually cannot unify and correlate the results of the above heterogeneous analyses, making it difficult to form an integrated program representation that covers multi-dimensional information such as "syntax, semantics, dependency, and call".

[0139] The fragmented nature of current analysis results leads to a lack of holistic approach in vulnerability discovery, resulting in low accuracy in automated assessment. During vulnerability discovery, many real-world vulnerabilities rely on the combined judgment of multiple relationships. A single vulnerability often depends simultaneously on the input source, path conditions, cross-function call relationships, and the location of dangerous operations. For example, untrusted external input may reach a sensitive point after multiple function calls, conditional branches, and memory write operations. Relying solely on a single graph structure is insufficient to accurately reconstruct the attack chain. Without a unified code attribute graph mechanism, it is difficult to effectively express the complex characteristics of cross-level, cross-function, and cross-path vulnerabilities, thus limiting the ability to automatically discover unknown vulnerabilities.

[0140] 3. Taint propagation analysis has limited accuracy and is difficult to adapt to the complex execution semantics of domestically developed software. Currently, most taint propagation analysis methods are designed for high-level language source code, where default variable definitions, parameter passing, and object lifecycles are relatively clear. However, in binary programs, register reuse is frequent, stack frame structures are unstable, memory alias relationships are complex, and there are numerous indirect calls, jump tables, inlining optimizations, and compiler reorderings, making traditional taint propagation rules difficult to apply directly.

[0141] In the context of domestic IT innovation software, programs typically contain a large number of local interface calls, device interaction logic, mixed input paths of files and networks, and program structures generated by specific compilation chains, making taint source identification, taint propagation edge recovery, and taint convergence point judgment more complex.

[0142] In the aforementioned scenarios, the relevant technologies are prone to problems such as interruption of taint paths, distortion of propagation range, or path expansion, which can lead to both false positives and false negatives, making it difficult to meet the needs of accurate discovery of unknown vulnerabilities.

[0143] 4. Lack of query interfaces targeting vulnerability patterns leads to low efficiency and poor customizability in automated vulnerability discovery. Current binary vulnerability analysis tools mostly rely on manually written rules, scripts, or plugins to complete security checks. The rule description methods are inconsistent between different tools, requiring analysts to have a high threshold of knowledge in program analysis and low-level security. Only by mastering program analysis details, graph structure semantics, and vulnerability feature description methods can customized discovery targeting specific vulnerability patterns be achieved, resulting in a high barrier to entry.

[0144] For different vulnerability types such as command injection, path traversal, out-of-bounds access, and unauthorized sensitive operations, the analysis process typically requires repeatedly combining control flow constraints, data dependencies, call context, and dangerous operation characteristics. There is a lack of a unified vulnerability mining query language interface oriented towards code attribute graphs, making it impossible to standardize and encapsulate common vulnerability patterns, code structure characteristics, and propagation constraints.

[0145] Therefore, when faced with large-scale domestic software samples, there are common problems such as low rule reuse rate, low batch analysis efficiency, high degree of human involvement, and poor consistency of results, which are not conducive to the formation of a sustainable and evolving automated vulnerability discovery capability.

[0146] 5. Difficulty in balancing the ability to discover unknown vulnerabilities with the requirements for engineering implementation. Detection methods based on signature libraries, dangerous function blacklists, or known vulnerability pattern matching, while efficient in some known vulnerability scenarios, are insufficient in identifying variant vulnerabilities, combined vulnerabilities, and unknown vulnerabilities with concealed exploit paths. On the other hand, while methods such as pure symbolic execution and full-path solving theoretically possess strong analytical capabilities, they suffer from path explosion, high computational overhead, and strong environmental dependence, making large-scale deployment difficult in practical scenarios involving batch testing of domestically developed software.

[0147] Especially in critical industries such as power and energy, the variety of domestically developed software, diverse versions, and complex deployment environments demand not only highly automated vulnerability discovery technologies with the ability to find unknown vulnerabilities, but also stable, reproducible, and scalable analysis processes capable of supporting platform integration and batch processing. Currently, related technologies have not yet achieved an effective balance between analytical depth, detection accuracy, and engineering application efficiency, limiting their application value in critical infrastructure domestically developed security scenarios.

[0148] The aforementioned issues present significant technical challenges to the discovery of unknown vulnerabilities in domestically developed software, particularly in areas such as program representation, semantic recovery, path analysis, and automated detection. While methods like source code-level static analysis, rule matching, taint analysis, symbolic execution, and fuzzing are widely used in vulnerability discovery techniques—including static source code analysis (relying on abstract syntax trees, control flow graphs, and data flow graphs for systematic analysis of code logic), taint analysis (identifying injection, out-of-bounds access, and privilege circumvention by tracing the propagation of untrusted input to sensitive operations), and symbolic execution (deeply exploring potential vulnerability paths by solving program path conditions)—these methods largely rely on readily available source code, a clear semantic structure, and a fully recoverable program context. They are often difficult to apply directly in scenarios without source code binary programs.

[0149] Especially in the context of domestic IT software development, programs are often processed through specific compilation toolchains, resulting in numerous compilation optimizations, inlining expansions, register reuse, indirect jumps, dynamic linking, and mixed calls. While traditional disassemblers and decompiles can recover some instruction and function boundaries, their ability to recover high-level semantics, variable roles, cross-function dependencies, complex control constraints, and memory alias relationships is limited, leading to severely fragmented analysis results. Control flow graphs, call graphs, and data flow dependencies typically exist as separate intermediate results, making it difficult to form a unified carrier of program knowledge and to support complex rule-based reasoning for unknown vulnerabilities.

[0150] In recent years, Code Property Graph (CPG), as a unified program representation that integrates abstract syntactic structures, control flow relationships, and data dependencies, has demonstrated strong comprehensive capabilities in the field of source code security analysis. By mapping syntactic information, control dependencies, data dependencies, and call relationships in a program to a unified graph structure, CPG is better suited to expressing the various interconnected constraints involved in the formation of complex vulnerabilities, providing a unified foundation for automated vulnerability discovery and graph query analysis.

[0151] However, most current research on code attribute graphs focuses on the construction of high-level language source code, where the relationships between graph nodes and edges are highly dependent on the semantic elements of the source code. There is still a lack of mature solutions for node abstraction methods, dependency recovery methods, unified graph modeling mechanisms, and query interface design in binary program scenarios.

[0152] In view of this, and to address the aforementioned shortcomings, this embodiment aims to achieve unified modeling of the program structure and semantic information of domestically developed software without source code, and on this basis, to complete automated discovery of unknown vulnerabilities. Through technological innovations such as "recovery of multi-dimensional intermediate representations of binary programs, unified graph modeling of control flow and data flow, analysis of taint propagation without source code, and construction of query interfaces oriented towards vulnerability patterns," a unified semantic expression and automated discovery of unknown vulnerabilities in the binary programs of domestically developed software are achieved, significantly improving the accuracy, scalability, and platform integration capabilities of vulnerability discovery in source-code scenarios.

[0153] Specifically, refer to Figure 2 , Figure 2 Another embodiment of this application provides a method for discovering unknown vulnerabilities in binary programs. This method designs a modular method architecture for the security analysis scenario of domestically developed software, supports the collaborative implementation of code attribute graph construction, taint propagation analysis, vulnerability pattern query and result output, and can be further integrated into the intelligent vulnerability discovery platform for domestically developed software to support batch sample detection, continuous risk discovery and engineering application deployment.

[0154] First, this embodiment constructs a code attribute graph that integrates control flow relationships, data dependency relationships, function call relationships, and node attribute information by disassembling and parsing the binary program of the domestically developed software, identifying functions, dividing basic blocks, and performing control flow analysis, data flow analysis, and alias analysis. This forms a unified semantic representation foundation for the program without source code, providing structured support for subsequent unknown vulnerability mining and realizing the construction of a unified semantic graph for domestically developed software without source code.

[0155] Next, this embodiment designs a taint propagation analysis method for source code-less scenarios. By constructing a taint propagation analysis mechanism suitable for binary programs, it can identify taint sources such as external input points, file input points, network input points, and device interaction points. Based on data dependencies, control dependencies, and cross-function call relationships in the code property graph, it tracks and recovers the taint propagation path, thereby improving the completeness and accuracy of identifying dangerous propagation chains in complex binary program scenarios.

[0156] This embodiment also establishes a vulnerability mining query interface based on code attribute graphs and vulnerability patterns. By encapsulating common vulnerability pattern characteristics, code structure constraints, data flow constraints, and control condition constraints, it enables security researchers to conduct automated queries and detection of various types of vulnerabilities such as command injection, out-of-bounds access, path traversal, and privilege bypass in a unified manner, reducing the threshold for manual analysis and improving the efficiency of rule reuse.

[0157] By combining unified code attribute graph modeling with taint propagation analysis, vulnerability analysis is no longer limited to dangerous function matching or local rule judgment. Instead, it can comprehensively consider complex dependencies across basic blocks, functions, and paths, enabling in-depth mining of unknown vulnerabilities and vulnerability variants. At the same time, it supports the continuous expansion of new vulnerability patterns, improving the accuracy and scalability of unknown vulnerability mining.

[0158] For example, the binary program of the domestically developed software under test is parsed and its basic structure is restored. The output function information table, basic block partitioning results, instruction parsing results, and initial function call relationship table are used as the basic analysis results of the program.

[0159] In this step, the basic structural information of the program is recovered by identifying the program entry address, function boundaries, instruction sequence, jump instructions, and call instructions. The functions, basic blocks, and instruction levels in the binary program are organized to provide basic input for subsequent control flow analysis and data flow analysis.

[0160] Based on the program fundamental analysis results obtained above, control flow analysis, data flow analysis, aliasing analysis, and cross-functional dependency analysis are performed. The output control flow graph, data flow relationship table, aliasing association table, cross-functional dependency relationship table, and approximate program structure representation results are used as intermediate program representation results.

[0161] In this step, a control flow graph is constructed by analyzing jump instructions and branch relationships. Data flow relationships are extracted by tracing registers, stack variables, heap objects, and memory read and write operations. Cross-function dependencies are restored through function parameter passing, return value passing, and shared memory access behavior, thereby forming a multi-dimensional intermediate representation describing the program execution logic and data behavior.

[0162] Based on the intermediate representation results obtained above, a unified model is performed on multiple types of nodes and edges, and the code attribute graph node set, edge set, attribute table, and complete code attribute graph are output as the code attribute graph construction results.

[0163] In this step, functions, basic blocks, instructions, registers, variables, memory objects, external input points, and sensitive operation points are abstracted as graph nodes. Control dependencies, data dependencies, call relationships, parameter passing relationships, alias relationships, and attribute subordination relationships are abstracted as graph edges. Each node and edge is then assigned a type identifier, address information, function information, context attributes, and risk marker information, thereby forming a unified code attribute graph that carries the program's syntax, semantics, and dependencies.

[0164] Based on the code attribute graph construction results obtained above, taint sources and sensitive sinks are identified, and source code-free taint propagation analysis is performed. The candidate dangerous propagation path set and taint propagation relationship table are output as candidate dangerous propagation path results.

[0165] In this step, the system identifies nodes such as user input, network packets, file input, device interaction input, and inter-process communication input as taint sources, and nodes such as command execution, dangerous memory writes, sensitive file access, system calls, access control interfaces, and database operation interfaces as sensitive sinks. Using taint source nodes as starting nodes and sensitive sink nodes as target nodes, the system continuously tracks the relationships between nodes based on data dependency edges, control dependency edges, call edges, and parameter passing edges in the code property graph. It identifies propagation chains formed by one or more intermediate nodes and one or more edges connecting taint source nodes to sensitive sink nodes. Intermediate nodes along the propagation chain can be used as propagation path nodes, thereby obtaining potential risk propagation chains in scenarios across basic blocks, functions, and modules.

[0166] Based on the candidate danger propagation path results output above, and the complete code attribute graph obtained in step 3, vulnerability pattern query and rule matching are performed to output the potential vulnerability point set, vulnerability type matching results, vulnerability propagation path results, and vulnerability evidence fragment set as potential vulnerability mining results.

[0167] In this step, the system encapsulates vulnerability patterns such as command injection, path traversal, out-of-bounds access, unvalidated input propagation, misuse of dangerous interfaces, and privilege circumvention into executable query rules by encapsulating code structure features, data flow constraints, control condition constraints, function call context constraints, and sensitive operation constraints. Then, based on the code attribute graph and candidate dangerous propagation path results, the system performs automated queries on the target program and outputs candidate results that match the vulnerability patterns.

[0168] Based on the potential vulnerability discovery results obtained above, candidate vulnerabilities are aggregated, deduplicated, sorted, and output, ultimately forming a vulnerability result sorting table, vulnerability evidence output results, and an automated unknown vulnerability discovery report.

[0169] In this step, the system first integrates potential vulnerability points, vulnerability types, propagation paths, and evidence fragments. Analysis results with the same or related vulnerability locations, the same sensitive sinks, the same vulnerability types, or shared key propagation path fragments are grouped into the same candidate vulnerability record to complete the candidate vulnerability aggregation.

[0170] Subsequently, the system performs deduplication on the aggregated candidate vulnerability records. For candidate vulnerability records with the same vulnerability location or located in the same instruction address range / basic block range, the same sensitive sink, the same or highly overlapping critical propagation path segments, and the same vulnerability type or evidence segment overlap degree meeting the preset conditions, they can be identified as duplicate or homogeneous vulnerability records and merged into one candidate vulnerability result.

[0171] After aggregation and deduplication, the system comprehensively evaluates candidate vulnerabilities by considering factors such as the length of the vulnerability propagation chain, the risk level of sensitive operations, the degree of path constraint satisfaction, the complexity of the call context, and the completeness of evidence.

[0172] It should be noted that, in response to the problem that domestically developed software in practical scenarios generally only provides binary programs, dynamic link libraries, or intermediate code and lacks source code, this embodiment performs disassembly analysis, function boundary identification, basic block division, and call relationship recovery on the binary program, and further integrates the results of control flow analysis, data flow analysis, and alias analysis to uniformly map the originally fragmented multi-type program analysis information into a code attribute graph, thereby forming a computable, queryable, and scalable unified program semantic representation without source code.

[0173] This embodiment does not merely generate a single control flow graph or call graph, but rather integrates function nodes, basic block nodes, instruction nodes, register nodes, variable nodes, memory object nodes, and sensitive operation nodes into a unified graph structure, establishing various edge relationships such as control dependency edges, data dependency edges, function call edges, parameter passing edges, and alias association edges. Through this unified graph modeling mechanism, program execution paths, data propagation links, and cross-function dependencies can be expressed simultaneously, providing a structural foundation for joint reasoning of complex and unknown vulnerabilities.

[0174] The taint propagation analysis method for complex semantics in binary programs proposed in this embodiment can identify taint sources such as user input, network input, file input, and device interaction input under conditions of register reuse, stack space reuse, complex alias relationships, frequent indirect calls, and compiler optimization. It then performs propagation analysis along data dependencies, control dependencies, and call relationships in the code attribute graph, thereby recovering candidate dangerous paths between external inputs and sensitive operations and improving the completeness and accuracy of taint propagation analysis in source-free scenarios.

[0175] The code attribute graph query interface construction method proposed in this embodiment encapsulates the graph structure features, code destructuring features, data flow propagation constraints, control condition constraints, and function context constraints in the code attribute graph into executable query rules. Through this query interface, common vulnerability patterns such as command injection, path traversal, out-of-bounds access, unvalidated input propagation, misuse of dangerous interfaces, and privilege escalation can be expressed as standardized rules. This reduces the complexity for security researchers to directly manipulate the underlying graph structure and improves rule reusability and automated analysis efficiency.

[0176] This embodiment proposes a candidate vulnerability aggregation and ranking mechanism for unknown vulnerability discovery. Based on vulnerability pattern query results, it further aggregates, deduplicates, and ranks potential vulnerability points, vulnerability propagation paths, sensitive operation locations, and evidence fragments. It then constructs a comprehensive candidate vulnerability scoring mechanism by combining factors such as the hazard level of the propagation path, the risk level of sensitive operations, context complexity, and evidence completeness. This mechanism can prioritize the identification of high-risk, highly reliable unknown vulnerabilities from a large pool of candidate results, improving the interpretability and engineering application value of vulnerability discovery results.

[0177] Unlike current methods that mainly rely on binary boosting, path tracing, and specific vulnerability scenario analysis, this embodiment can form a more complete and structured program semantic representation without source code, significantly enhancing the ability to express the causes of complex vulnerabilities.

[0178] Current closed-source vulnerability analysis methods typically focus on specific vulnerability types, specific memory operation scenarios, or specific path tracing logic. When faced with binary programs that have register reuse, complex alias relationships, frequent indirect calls, and obvious cross-function propagation, problems such as incomplete analysis, broken propagation chains, or insufficient rule adaptability are likely to occur.

[0179] This embodiment proposes a source code-free taint propagation analysis mechanism for binary complex semantics. Based on the unified structure of the code attribute graph, it can uniformly identify external input points, data propagation nodes, and sensitive operation points, and perform cross-basic block, cross-function, and cross-module propagation analysis along data dependency edges, control dependency edges, call edges, and parameter passing edges.

[0180] Therefore, compared with current closed-source program vulnerability analysis methods, this embodiment has stronger recovery capabilities for dangerous propagation paths in complex domestic software application scenarios, and has a higher ability to discover covert, combined, and variant vulnerabilities.

[0181] Current vulnerability discovery methods typically detect closed-source vulnerabilities through fixed rules, specific function matching, or preset path features. Their rule expression capabilities are relatively limited, and when faced with multiple types of vulnerability patterns, manual adjustment of the analysis logic is often required, resulting in a low degree of automation.

[0182] This embodiment further proposes a method for constructing a code attribute graph query interface oriented towards vulnerability patterns, which can encapsulate code structure features, data flow constraints, control condition constraints, and call context constraints into graph query rules.

[0183] This interface allows for the standardized expression of vulnerability patterns such as command injection, path traversal, out-of-bounds access, unvalidated input propagation, misuse of dangerous interfaces, and privilege escalation, and supports customized extensions. Compared to existing technologies, this embodiment significantly reduces the difficulty of rule writing, improves rule reusability and batch automated mining efficiency, and is more suitable for platform applications and continuous analysis.

[0184] Currently, closed-source vulnerability discovery techniques are mostly used to detect known patterns, known dangerous behaviors, or local risk scenarios. However, their analytical capabilities remain limited when it comes to complex and unknown vulnerabilities that require comprehensive analysis of control paths, data dependencies, call contexts, and sensitive operations.

[0185] This embodiment employs a collaborative mechanism of "unified code attribute graph + source code-free taint propagation + vulnerability pattern query," enabling vulnerability analysis to move beyond single functions, instruction fragments, or paths. Instead, it allows for joint reasoning about complex dependencies within a program at the global graph structure level. Furthermore, it incorporates candidate vulnerability aggregation, deduplication, and ranking mechanisms, combining the severity of propagation paths, the risk level of sensitive operations, contextual complexity, and evidence completeness for comprehensive scoring, thereby improving the credibility and interpretability of vulnerability output results. In comparison, this embodiment more effectively distinguishes between high-risk real vulnerabilities and general suspicious paths, achieving higher overall accuracy in discovering unknown vulnerabilities.

[0186] In summary, this embodiment explicitly focuses on the analysis object of domestically developed software binary programs. It addresses the needs of domestically developed software in key industries for source-code-free delivery, complex call chains, component-based deployment, and automated vulnerability discovery. Through a technical chain of "binary parsing—program semantic recovery—code attribute graph construction—source-code-free taint propagation—vulnerability pattern query—result aggregation and output," it achieves fully automated vulnerability discovery for domestically developed software binary programs, from the original input file to the output of unknown vulnerability results. This can serve as the underlying core capability of a domestically developed software vulnerability intelligent discovery platform. This mechanism supports both in-depth analysis of single binary programs and continuous vulnerability discovery of batch samples, providing a unified foundation for subsequent supply chain analysis, vulnerability verification, and platform deployment.

[0187] Reference Figure 3 This application also provides a system for discovering unknown vulnerabilities in binary programs, which can implement the above-described method. The system includes: The first module is used to parse and restore the basic structure of target files in binary program form, and obtain the basic analysis results of the program.

[0188] The second module is used to perform program semantic recovery and multidimensional relation extraction on the program's basic analysis results to obtain the intermediate representation results of the program.

[0189] The third module is used to perform graph modeling on the multiple types of nodes and edges of the target file based on the intermediate representation results of the program, and obtain the code attribute graph construction results.

[0190] The fourth module is used to perform source code-free taint propagation analysis on the code attribute graph construction results to obtain candidate dangerous propagation path results.

[0191] The fifth module is used to perform vulnerability pattern queries and rule matching on the target file based on the code attribute graph construction results and candidate danger propagation path results, so as to obtain potential vulnerability discovery results.

[0192] The sixth module is used to aggregate and comprehensively score the results of potential vulnerability discovery to obtain the results of unknown vulnerability discovery.

[0193] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0194] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0195] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0196] Reference Figure 4 , Figure 4 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0197] The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 using the methods described in the embodiments of this application.

[0198] The input / output interface 903 is used to implement information input and output.

[0199] The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0200] Bus 905 transmits information between various components of the device, such as processor 901, memory 902, input / output interface 903, and communication interface 904.

[0201] The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0202] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0203] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0204] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0205] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0206] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0207] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0208] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0209] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0210] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0211] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0212] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0213] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0214] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0215] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0216] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0217] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for discovering unknown vulnerabilities in binary programs, characterized in that, The method includes the following steps: The object file in binary program form is parsed and its basic structure is restored to obtain the basic program analysis results. The program semantics are restored and multidimensional relationships are extracted from the program's basic analysis results to obtain the intermediate representation of the program. Based on the intermediate representation results of the program, graph modeling is performed on the multiple types of nodes and multiple types of edges of the target file to obtain the code attribute graph construction results; The code attribute graph construction results are subjected to source code-free taint propagation analysis to obtain candidate dangerous propagation path results; Based on the code attribute graph construction results and the candidate danger propagation path results, vulnerability pattern queries and rule matching are performed on the target file to obtain potential vulnerability mining results. The results of the potential vulnerability discovery are aggregated and comprehensively scored to obtain the results of the unknown vulnerability discovery.

2. The method according to claim 1, characterized in that, The program fundamental analysis results include a function information table, basic block partitioning results, instruction parsing results, and an initial function call relationship table. The process of parsing and restoring the basic structure of the object file in binary program form to obtain the program fundamental analysis results includes the following steps: The format of the object file in binary program form is identified to obtain the program entry address, load layout information and code region information; The machine code of the code region information is disassembled and parsed to obtain the instruction parsing result, wherein the instruction parsing result is an instruction sequence organized by address, the instruction sequence includes the opcode, operands and instruction type of each instruction, and the instruction type includes jump instructions, call instructions and return instructions; The function boundary is identified based on the program entry address and the target address corresponding to the calling instruction, and the function information table is obtained. Based on the function information table and the jump instruction, the basic block is divided to obtain the basic block division result consisting of single-entry and single-exit instruction fragments; The initial function call relationship table is obtained by extracting the call relationship based on the function information table and the call instruction.

3. The method according to claim 1, characterized in that, The intermediate representation results of the program include control flow graphs, data flow relationship tables, alias association tables, cross-functional dependency relationship tables, and approximate representation results of program structure. The process of performing program semantic recovery and multi-dimensional relationship extraction on the program's basic analysis results to obtain the intermediate representation results includes the following steps: Based on the program fundamental analysis results, control flow analysis is performed on jump instructions and branch relationships to obtain the control flow graph; Based on the program fundamental analysis results, data flow analysis is performed on the read and write operations of the program object to obtain the data flow relationship table; Based on the program fundamental analysis results, alias analysis is performed on the program objects to obtain the alias association table. The alias association table is used to record the program objects with alias relationships. The alias relationship indicates that multiple program objects point to the same memory object or reference the same storage area. Based on the program fundamental analysis results, cross-function dependencies are recovered through function parameter passing, return value passing, and shared memory access behavior to obtain the cross-function dependency table; Based on the program fundamental analysis results, the control flow graph, the data flow relation table, the alias association table, and the cross-functional dependency relation table, the missing structure tree is approximated to obtain the approximate representation of the program structure.

4. The method according to claim 1, characterized in that, The code attribute graph construction result includes a code attribute graph node set, a code attribute graph edge set, a node attribute table, an edge attribute table, and a complete code attribute graph. The step of performing graph modeling on the multiple types of nodes and edges of the target file based on the intermediate representation results of the program to obtain the code attribute graph construction result includes the following steps: Based on the intermediate representation results of the program, the functions, basic blocks, instructions, program objects, external input points, and sensitive operation points of the target file are abstracted into graph nodes and node attributes are recorded to obtain the code attribute graph node set and the node attribute table; Based on the intermediate representation results of the program, the control dependencies, data dependencies, calling relationships, parameter passing relationships, alias relationships, and attribute subordination relationships of the target file are abstracted into graph edges and edge attributes are recorded to obtain the code attribute graph edge set and the edge attribute table; The complete code attribute graph is obtained by performing graph modeling based on the set of nodes in the code attribute graph, the node attribute table, the set of edges in the code attribute graph, and the edge attribute table.

5. The method according to claim 1, characterized in that, The candidate hazard propagation path results include a set of taint source nodes, a set of sensitive sink nodes, a set of candidate hazard propagation paths, and a taint propagation relationship table. The process of performing source-code-free taint propagation analysis on the code attribute graph construction results to obtain the candidate hazard propagation path results includes the following steps: Based on preset pollution behaviors, the pollution source is located in the code attribute graph construction result to obtain the pollution source node set, wherein the pollution behaviors include user input, network packets, file input, device interaction input, and inter-process communication input; Sensitive sink points are located based on the code attribute graph construction result based on preset sensitive behaviors, and the sensitive sink point node set is obtained. The sensitive behaviors include command execution, dangerous memory writing, sensitive file access, system calls, access control and database operations. Using the pollution source node as the starting node and the sensitive sink node as the target node, the propagation chain of the relationship between the starting node and the target node is traced and identified based on the code attribute graph construction result, and the pollution propagation relationship table is obtained. Based on the taint propagation relationship table, the intermediate nodes between the starting node and the target node are taken as propagation path nodes to obtain the candidate dangerous propagation path set.

6. The method according to claim 1, characterized in that, The potential vulnerability discovery results include a set of potential vulnerability points, vulnerability type matching results, vulnerability propagation path results, and a set of vulnerability evidence fragments. The step of performing vulnerability pattern querying and rule matching on the target file based on the code attribute graph construction results and the candidate dangerous propagation path results to obtain the potential vulnerability discovery results includes the following steps: By encapsulating code structure features, data flow constraints, control condition constraints, function call context constraints, and sensitive operation constraints, the preset vulnerability patterns are transformed into executable query rules. Based on the executable query rules and the results of the dangerous propagation paths, a graph query matching is performed on the code attribute graph construction results to identify potential vulnerability points, vulnerability propagation paths, and dangerous code fragments in the target file that conform to the vulnerability pattern, thereby obtaining the vulnerability point set, the vulnerability type matching results, the vulnerability propagation path results, and the vulnerability evidence fragment set.

7. The method according to claim 6, characterized in that, The unknown vulnerability discovery results include a vulnerability result ranking table, vulnerability location and path description results, and vulnerability evidence output results. The process of aggregating and comprehensively scoring the potential vulnerability discovery results to obtain the unknown vulnerability discovery results includes the following steps: Based on the vulnerability point set, the vulnerability type matching result, the vulnerability propagation path result, and the vulnerability evidence fragment set, potential vulnerabilities are associated and integrated. Potential vulnerabilities with at least one identical vulnerability location, sensitive sink point, vulnerability type, and vulnerability propagation path are grouped into the same vulnerability record to obtain vulnerability aggregation result. The vulnerability aggregation results are deduplicated to obtain the vulnerability deduplication results; The deduplication results of the vulnerability are structured to obtain the vulnerability location and path description results and the vulnerability evidence output results; The deduplication results of the vulnerabilities are comprehensively evaluated based on the length of the vulnerability propagation chain, the risk level of sensitive operations, the degree of path constraint satisfaction, the complexity of the call context, and the completeness of evidence to obtain a comprehensive vulnerability score. The vulnerabilities are then sorted according to the comprehensive vulnerability score to obtain a vulnerability result ranking table.

8. A system for discovering unknown vulnerabilities in binary programs, characterized in that, The system includes: The first module is used to parse and restore the basic structure of the target file in binary program form to obtain the basic program analysis results. The second module is used to perform program semantic recovery and multidimensional relation extraction on the program basic analysis results to obtain the intermediate representation results of the program. The third module is used to perform graph modeling on the multiple types of nodes and multiple types of edges of the target file based on the intermediate representation results of the program, and to obtain the code attribute graph construction results. The fourth module is used to perform source code-free taint propagation analysis on the code attribute graph construction results to obtain candidate dangerous propagation path results; The fifth module is used to perform vulnerability pattern query and rule matching on the target file based on the code attribute graph construction results and the candidate danger propagation path results to obtain potential vulnerability mining results; The sixth module is used to aggregate and comprehensively score the potential vulnerability discovery results to obtain the unknown vulnerability discovery results.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.