LLVM-based industrial software supply chain backdoor positioning method

Abstract

The invention discloses an LLVM-based industrial software supply chain backdoor positioning method. The method comprises the following steps: pre-creating a feature database of trusted industrial software; lLVMIR intermediate language code conversion is carried out on the to-be-detected software, and software structured features of the version corresponding to the to-be-detected software in the feature database are obtained; extracting predefined software structural features of the to-be-detected software; performing structure matching between the function call graphs by using the software structured features of the to-be-detected software and the software structured features of the corresponding trusted software, and creating an initial similar function mapping set to realize difference function identification; and sequentially carrying out structure matching between function control flow diagrams on each similar function mapping in the initial similar function mapping set, and identifying code differences of basic block granularity of to-be-detected software to obtain a supply chain backdoor candidate code area in the to-be-detected software. The method has higher automation and expansibility, does not depend on specific input simulation, and has higher backdoor candidate area positioning capability.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically to a method for locating backdoors in industrial software supply chains based on LLVM. Background Technology

[0002] Industrial software refers to software products applied in industrial production, manufacturing, and management, encompassing categories such as R&D and design, production and manufacturing, business management, and operation services. It is an indispensable part of industrial production. A software supply chain backdoor refers to malicious or unauthorized code being inserted into software during development, testing, distribution, or updates, allowing attackers to bypass software security verification mechanisms, remotely control the software, or execute malicious operations. Compared to ordinary software, industrial software has a massive amount of code and a more complex supply chain. For example, mainstream CAD software such as SolidWorks, Solid Edge, and Inventor contains approximately 30 to 45 million lines of code, incorporating open-source components from C, C++, and Java, and involving 200-300 technology partners. Figure 1 As shown, for complex industrial software supply chain systems, attackers can implant backdoors through six key links in the supply chain: code repositories, development tools, third-party dependency libraries, compilation processes, distribution channels, and update mechanisms. The implantation links for supply chain backdoor attacks are highly diverse. Under the increasingly severe international situation, foreign industrial software faces the risk of supply chain backdoor attacks.

[0003] Software supply chain backdoor detection aims to discover hidden malicious functions embedded within software. Detection can effectively improve system security and reduce potential software security threats. The location of candidate code for supply chain backdoors determines the efficiency and accuracy of backdoor detection. Accurately locating candidate code regions facilitates rapid backdoor discovery, reduces the workload of security analysis, and the code in the candidate regions should include the software backdoor as comprehensively as possible. Therefore, research on backdoor location technology in industrial software supply chains has significant social implications and promising application prospects.

[0004] The 2013 CCS conference paper, "Towards Reducing the Attack Surface of Software Backdoors," presented a scheme for identifying candidate backdoor regions in binary software. The authors, Felix Schuster et al., used standard FTP and SSH server protocols to generate user input in batches and implemented a GDB client in the system to connect to a remote gdbserver instance for dynamic debugging of suspicious software. This method uses control flow tracing techniques to model the execution path of specific inputs, constructing a call graph and decision tree. Heuristic methods are used to identify decisions related to authentication and command scheduling in the decision tree, defining these as candidate code regions where backdoor functionality resides.

[0005] The shortcomings of the background technology are as follows: The backdoor candidate region localization scheme proposed in "Towards Reducing the Attack Surface of Software Backdoors" relies on specific specification protocols or input specifications to generate inputs, resulting in low localization efficiency and lack of robustness; by identifying specific types of functions or specific control flow feature code regions as detection candidate regions, the localization type is limited and prone to missed detections; as the software scale increases, the complexity of dynamic debugging further increases. Summary of the Invention

[0006] This invention provides an LLVM-based method for locating backdoors in the industrial software supply chain. It addresses the problems of low efficiency, lack of robustness, limited location types, easy false negatives, and high complexity in dynamic debugging of current backdoor locating methods in the software supply chain.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0008] A method for locating backdoors in the industrial software supply chain based on LLVM includes:

[0009] The data preprocessing module pre-creates a feature database of trusted industrial software, which contains structured software features extracted from the intermediate language code level of each type of industrial software.

[0010] The data preprocessing module uses a code conversion tool to convert the software to be detected into LLVM IR intermediate language code and obtains the software structured features corresponding to the version of the software to be detected from the feature database.

[0011] The software structured feature extraction module extracts predefined software structured features of the software under test by selecting and defining the attribute set of software structured features and using LLVMPython.

[0012] The differential code analysis module based on structure matching uses the software structure features of the software under test and the software structure features of the corresponding trusted software to perform structure matching between function call graphs, create an initial set of similar function mappings to realize differential function identification, and serve as the basis for fine-grained differential code identification;

[0013] The differential code analysis module based on structure matching performs structure matching between function control flow graphs for each similar function mapping in the initial set of similar function mappings, identifies code differences at the basic block level of the software to be detected, and obtains candidate code areas for backdoors in the supply chain within the software to be detected.

[0014] Based on this, the present invention can be further improved as follows:

[0015] The data preprocessing module pre-creates a feature database for trusted industrial software, specifically including:

[0016] The data preprocessing module uses the lightweight database SQLite to extract structured features of the software, and creates a feature database for trusted industrial software based on the extracted structured features.

[0017] Based on this, the present invention can be further improved as follows:

[0018] The attribute set of software structure features includes: the number of instructions contained in a function, the number of constants contained in a function, the number of strings contained in a function, the number of basic blocks contained in a function CFG, the number of edges contained in a function CFG, the number of sub-calls contained in a function CFG, the number of strings contained in a basic block, the shortest path length from a basic block to the CFG entry point, the shortest path length from a basic block to the CFG exit point, the number of sub-calls within a basic block, and the instruction mnemonics contained within a basic block.

[0019] Based on this, the present invention can be further improved as follows:

[0020] This document describes how to extract predefined structural features from the software under test using LLVM Python. Specifically, it includes:

[0021] LLVMPython is used to extract graph structure information representing function calls within the software under test, as well as the structure information, number of functions, and function instruction information of each function, thereby using structural data features to represent the binary software program.

[0022] Based on this, the present invention can be further improved as follows:

[0023] The differential code analysis module based on structure matching uses the software structure features of the software under test and the corresponding trusted software structure features to perform structure matching between function call graphs, creating an initial set of similar function mappings to achieve differential function identification, specifically including:

[0024] By performing structured matching of functions in the function call graph using a set of attributes and selectors, a set of initial function matching fixed points is obtained;

[0025] The triplet consisting of the number of nodes, edges, and subcalls in the function control flow graph is used as the selector, and the selector is regarded as a three-dimensional space vector;

[0026] Starting from the initial function matching fixed point, and combining it with the file function call relationship graph, the predecessor and successor relationships of the fixed point are used to propagate nodes to expand the mapping, and finally create a function call graph isomorphism between the two binary programs, that is, a set of similar function mappings.

[0027] Based on this, the present invention can be further improved as follows:

[0028] The structure-matching-based differential code analysis module performs structure matching between function control flow graphs for each similar function mapping in the initial set of similar function mappings, specifically including:

[0029] For matching the function control flow graph structure between a set of similar function mappings, a triple consisting of the number of basic blocks in the ingress shortest path, the number of basic blocks in the egress shortest path, and the number of subcalls is used as the selector. The attribute set consists of the number of basic block strings and the basic block SPP, where the basic block SPP is obtained by multiplying the odd prime numbers assigned to each node.

[0030] The LLVM-based backdoor location method for industrial software supply chains provided by this invention has the following advantages:

[0031] (1) This technology has stronger automation and scalability: the background technology relies on dynamic debugging to generate execution paths for specific inputs, which is not automated enough. The technology of this invention can handle large-scale industrial software without deep manual intervention, improving the automation and scalability of backdoor candidate region localization. Furthermore, it can adapt to new backdoor candidate region localization by updating and expanding the industrial software feature library.

[0032] (2) This technology does not rely on specific input simulation: The background method triggers and identifies backdoor candidate region codes by simulating user input, which requires accurate prediction or reproduction of the input that triggers the backdoor, and may not cover all potential backdoor triggering situations. The method of this invention, by combining a prior feature knowledge base for similarity calculation and difference analysis, can more comprehensively identify potential backdoor candidate regions, without being limited to the prediction or simulation of specific inputs.

[0033] (3) This technology has a stronger ability to locate backdoor candidate regions: The background technology uses heuristic methods to identify decision points related to authentication and command scheduling, which limits its effectiveness in detecting novel or complex backdoors. The method of this invention, by constructing a complete industrial software feature knowledge base, can more comprehensively discover complex backdoor candidate regions other than specific functions and special control flows.

[0034] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0035] Figure 1 A schematic diagram of the main links in the software supply chain backdoor implantation model provided in this embodiment of the invention;

[0036] Figure 2 A schematic diagram of the software supply chain backdoor candidate area positioning process provided in an embodiment of the present invention;

[0037] Figure 3 This is a schematic diagram of the overall architecture of the SCBL method provided in an embodiment of the present invention;

[0038] Figure 4 This is a schematic diagram of the TISSDB construction process provided in an embodiment of the present invention;

[0039] Figure 5 This diagram illustrates the LLVM IR generated by assembly language and translation under different architectures, as provided in embodiments of the present invention. Detailed Implementation

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

[0041] To address the aforementioned problems in backdoor location within the current software supply chain, this invention proposes a backdoor location method based on intermediate language. The research process is as follows: Figure 2As shown, the SCBL processing steps for binary industrial software are divided into three parts. The first part is the data preprocessing module, which includes two aspects: the construction of the Trusted Industrial Software Signature Database (TISSDB) and the LLVM intermediate language conversion of the software to be tested. SCBL first pre-creates the Trusted Industrial Software Signature Database (TISSDB), which contains software structural features (SSFs) extracted from the intermediate language code level of each type of industrial software. Then, SCBL uses the code conversion tool RetDec to convert the binary software to be tested into LLVMIR intermediate language code and obtains the SSF corresponding to the version of the software to be tested from TISSDB. The second part is the software structural feature extraction module. SCBL uses LLVMPython to extract the predefined SSFs of the binary software to be tested by selecting and defining the attribute set of software structural features. The third part is the differential code analysis module based on structure matching. SCBL first uses the SSF of the software under test and the corresponding trusted SSF to perform structural matching between function call graphs, creating an initial set of bidirectional similar function mappings to achieve differential function identification, which serves as the basis for fine-grained differential code identification. Then, for each similar function mapping, structural matching between function control flow graphs is performed sequentially to identify code differences at the basic block level of the software under test, obtaining candidate backdoor code regions within the software's supply chain. The following section will detail the research and implementation methods of SCBL's main modules, including a data preprocessing module, a software structured feature extraction module, and a differential code analysis module based on structural matching. The overall architecture of SCBL is as follows: Figure 3 As shown.

[0042] The details are explained below.

[0043] A method for locating backdoors in the industrial software supply chain based on LLVM includes:

[0044] The data preprocessing module pre-creates a feature database of trusted industrial software, which contains structured software features extracted from the intermediate language code level of each type of industrial software.

[0045] The data preprocessing module uses a code conversion tool to convert the software to be detected into LLVM IR intermediate language code and obtains the software structured features corresponding to the version of the software to be detected from the feature database.

[0046] The software structured feature extraction module extracts predefined software structured features of the software under test by selecting and defining the attribute set of software structured features and using LLVMPython.

[0047] The differential code analysis module based on structure matching uses the software structure features of the software under test and the software structure features of the corresponding trusted software to perform structure matching between function call graphs, create an initial set of similar function mappings to realize differential function identification, and serve as the basis for fine-grained differential code identification;

[0048] The differential code analysis module based on structure matching performs structure matching between function control flow graphs for each similar function mapping in the initial set of similar function mappings, identifies code differences at the basic block level of the software to be detected, and obtains candidate code areas for backdoors in the supply chain within the software to be detected.

[0049] The following sections describe the data preprocessing module, the software structured feature extraction module, and the differential code analysis module based on structure matching.

[0050] (I) Data Preprocessing Module

[0051] The data preprocessing module is designed to obtain the SSF file corresponding to the software under test from TISSDB and to perform intermediate language translation of the software. This module consists of two parts: a pre-created trusted industrial software feature database and LLVM intermediate language conversion of the binary code of the software under test. The TISSDB construction flowchart is shown below. Figure 4 As shown.

[0052] (1.1) Construction of a Trusted Industrial Software Feature Database

[0053] Rapid identification of backdoor code in the industrial software supply chain based on SCBL technology requires a large amount of structured feature data extracted from trusted binary industrial software. Therefore, it is necessary to pre-collect reviewed industrial software executables in batches through secure means, extract and save their SSF (Software Structural Features). This study's TISSDB construction module is developed using Python, enabling automated batch invocation of intermediate language conversion tools and extraction of industrial software SSFs. Furthermore, since industrial software typically has a large amount of code—for example, mainstream CAD software such as SolidWorks, Solid Edge, and Inventor have approximately 30 to 45 million lines of code—a suitable database system is needed to effectively and completely preserve code features. Therefore, this module uses the lightweight database SQLite to access and extract industrial software features. SQLite does not require a separate server process or system; it stores the features of each specific version of industrial software as a corresponding independent disk file, thus constructing the TISSDB data foundation for this experimental study.

[0054] (1.2) LLVM intermediate language conversion

[0055] Since binary software is typically compiled from different processor architectures, and these architectures have different instruction sets and registers, unified analysis is difficult. This invention solves the cross-architecture problem by converting binary executables from different architectures into a unified intermediate language, and then using this intermediate language as a basis for software feature extraction and cross-architecture binary software similarity detection.

[0056] Intermediate language abstraction aims to convert binary code from different architectures into a unified, architecture-independent code format, making similarity comparison more direct and accurate. Chris Lattner proposed LLVM IR (Intermediate Representation), which abstracts the details of specific hardware, converting binary programs from different architectures into the same intermediate representation. Currently, tools capable of converting binary files to LLVM IR include McSema, RetDec, and Dagger. Among them, RetDec supports binary files in ELF, PE, and Mach-O formats for various architectures such as Intel x86, ARM, and MIPS, effectively solving the intermediate code conversion problem. Therefore, given the wide application of LLVM IR in security research and its mature conversion technology, this invention first uses RetDec to implement the conversion of binary files to LLVM IR, completing the code intermediate language conversion preprocessing process.

[0057] LLVM IR addresses the differences between different architectures by proposing the following representation methods.

[0058] (1) Virtual registers

[0059] Because the number and names of registers differ across architectures, LLVM IR replaces the physical registers in traditional machine instructions with digital virtual registers. Virtual registers do not correspond to any specific hardware register and are assigned unique values ​​at definition. Registers with the same function, such as the EAX register in x86 architecture, R0 in ARM architecture, and $8 in MIPS architecture, are represented by the same global variable in LLVM IR and treated as the same type of digital register.

[0060] (2) Unified syntax representation

[0061] LLVM IR defines a unified syntax for different architectures, allowing different assembly codes to be abstracted and represented using the same syntax. LLVM uses expressions to represent operands in a code statement, including the results of operations such as memory loading, register reading, and arithmetic operations. For example, `%result = add i32 %a, %b` means adding integers `%a` and `%b` and storing the result in `%result`. LLVM uses instructions to represent the state changes to registers and memory caused by an operation. For example, the LLVM instruction statement `%addr = allocate i32` means allocating a 32-bit integer in memory and storing it in `%addr`.

[0062] By defining syntax rules and intermediate representation objects, LLVM IR can translate assembly languages ​​with different instruction sets into intermediate representations with the same syntax rules. In the data preprocessing module of SCBL, SCBL uses scripts to automatically call RetDec, extracting SSF files from a large number of trusted industrial software binaries and storing them in a database, creating a complete TISSDB. On the other hand, the RetDec tool translates the software's binary code into an LLVM intermediate language representation. Figure 5 Assembly languages ​​and LLVMIRs generated under different architectures.

[0063] (II) Software Structured Feature Extraction Module

[0064] To identify discrepancies in the code within the software under test, we analyze the program's structural information and the control flow within functions to extract representative features at the granular level, such as software functions, basic blocks, and instructions. Software programs themselves possess multiple features, including constant features such as function names and variable names, instruction features such as assembly instructions, basic block assembly code, and function pseudocode, and structural features such as function control flow diagrams and function call relationship diagrams. The software structured feature extraction module selects appropriate program constant features, instruction features, and structural features as fingerprints for extraction and storage, thus serving as the foundation for subsequent code similarity detection techniques based on structure matching.

[0065] Software structured features abstract binary programs into two types of structured graphs: function call graphs (CG) and function control flow graphs (CFG), visually representing the program's internal structure. A CG represents the calling relationships between functions within the program and can be represented using sets. Let V represent the set of each function node in the binary file, assuming function v i v was calledj Then the two functions v i and v j The directed edges between them use (v i v j )∈E represents the function. CFG represents the execution order and flow of instructions within a function. Nodes in the CFG represent basic blocks, and directed edges within the CFG represent jump relationships between basic blocks. We selected 11 attributes as shown in Table 1 as the attribute set representing the structural characteristics of binary software. The attributes selected in this study include three categories: the first category is the quantity characteristics representing the logical structure in the function code block. The number of instructions, constants, and strings can describe the function code block from the data level. The number of basic blocks, edges, and sub-calls in the CFG can describe the CFG graph structure information inside the function. The second category is the quantity characteristics in the basic block code, including the number of strings, the number of sub-calls, and the shortest paths to the entry and exit points. These can describe the quantity characteristics in the basic block code and the position information of each basic block in the CFG. The third category is instruction mnemonics, representing the most basic instruction characteristics contained within the basic block.

[0066] Table 1 Attributes for Software Structured Feature Selection

[0067]

[0068]

[0069] By extracting SSF (Search Function Files) from binary software programs, we can extract graph structure information representing function calls within the program, as well as the structure information, number of functions, and function instruction information for each function. This allows us to represent the binary software program using structural data features. This module uses an SSF feature extraction tool written in the LLVMPython library to process the binary software files converted by the RetDec tool and obtain the software's structured feature attributes at the intermediate code data level.

[0070] (III) Difference Code Analysis Module Based on Structure Matching

[0071] After obtaining the structured features of the binary software, SCBL, based on a trusted software feature database, uses structure-matching-based code similarity detection technology to identify differing codes within the software to be tested. By analyzing the structured features of the code within the binary software, the similarity detection problem is transformed into structure matching between two abstract graphics, CG and CFG, representing the features of the software code. SCBL's differing code analysis module is divided into two parts. The first part is the function initialization mapping, used to create...

[0072] The first part is to construct an initial bidirectional mapping set of similar functions between two executable files and use it as the basis for subsequent matching. The second part is CFG structure matching, which is used to identify similar basic blocks between the CFGs of each similar function mapping. Each part is described in detail below.

[0073] (3.1) Initial mapping of functions

[0074] By performing structural matching on the function call graphs (CGs) of two executable files to be identified, an initial set of similar function mappings between binary files is created, serving as the starting point for subsequent structural matching between CFGs. This is the first step of the SCBL-based structural matching differential code analysis module. We define the call graph representing a binary file as G = (V, E), consisting of a vertex set V and an edge set E, where V = {v1, ..., v...}. n Let E = {e1, ..., e} be a non-empty finite set of points. n Let} represent a finite set of edges. `up: V→(V)` represents the mapping from the set of points V to its predecessor node, and `down: V→(V)` represents the mapping from the set of points V to its successor node. Simultaneously, a selector `s: V1×(V2)→V2` is defined, representing finding the edge that matches `v` in the given set. i The most similar and unique node. To reduce the size of the set of inputs to the selector and increase the probability that the selector returns a non-empty set, the attribute u is defined as a mapping from graphs G1 and G2 to the subsets contained in their point sets, denoted as (G1, G2) → → (V′1, V′2), where V′1 ∈ V′1 and V′2 ∈ V′2.

[0075] The function initial mapping generation process of this invention is shown in Algorithm 1. The process of establishing the initial function mapping first involves structured matching of functions in CG using a set of attributes u and selectors s, thereby obtaining a set of initial function matching fixed points. The significance of this step lies in selecting some related functions from a large number of functions as fixed points relied upon in subsequent node propagation, avoiding global comparison work and thus improving the overall matching algorithm efficiency. The inputs to this algorithm are selectors s and attribute set u = {u1, ..., u...}. i}, and G1 and G2 representing the function call graphs of two binary files, where G1 = (V1, E1) and G2 = (V2, E2). For the CG graph, SCBL uses the number of function calls, the number of times the function is called, the function name, and the number of strings contained in the function as the attribute set u. The triple consisting of the number of nodes, edges, and sub-calls in the function CFG graph is used as the selector s, and this selector is regarded as a three-dimensional space vector, as shown in Equation 1:

[0076]

[0077] The similar function mappings created using attribute u and selector s are only a small subset of the final similar function mapping set, therefore, this set needs to be refined and expanded. As described in Algorithm 1, SCBL starts from the initial function matching fixed point selected in the previous step, combines the file function call relationship graph, and uses the predecessor and successor relationships of the fixed point to propagate nodes, thereby expanding the mapping, and finally creating CG isomorphism between the two binary programs, i.e., the similar function mapping set. At this point, the initial function mapping generation process is complete. The output of Algorithm 1 includes V′1, V′2, and p, where V′1 and V′2 represent the sets containing all similar functions in the two files, and p: V′1→V′2 represents the relationship between the functions.

[0078] Algorithm 1: Function Initial Mapping Generation Algorithm

[0079] Algorithm input: selector s, attribute set Figure G1 = (V1, E1), Figure G2 = (V2, E2)

[0080] Algorithm output: V1′, V2′, p

[0081]

[0082]

[0083] (3.2) CFG structure matching

[0084] By iteratively generating fixed points and propagating nodes on the function call graph (CG), a similar function mapping containing the maximum number of matches can eventually be generated. To identify structural changes at the basic code block granularity within the software to be detected, this invention uses a set of similar function mappings as a basis to perform structured matching on the control flow graph (CFG) corresponding to each function, achieving CFG isomorphism between two similar related functions. This step's algorithmic idea is similar to Algorithm 1, and it also consists of two processes: establishing initial basic block matching fixed points through selector s and attribute set u, and basic block node propagation. However, the inputs to the algorithm differ.

[0085] The CFG structure matching algorithm used in this invention takes selector s and attribute set u = {u1, ..., u} as inputs. i}, and G1 and G2 representing two function control flow graphs, where G1 = (V1, E1) and G2 = (V2, E2). For CFG structure matching between a set of similar function mappings, SCBL uses a triple consisting of the number of basic blocks in the ingress shortest path, the number of basic blocks in the egress shortest path, and the number of subcalls as the selector s. The attribute set u consists of the number of basic block strings and the basic block SPP, where the basic block SPP is obtained by multiplying the odd prime numbers assigned to each node.

[0086] Because the target binary file generated from the source code undergoes instruction rearrangement within basic blocks after intermediate language conversion under different compilation environments, feature matching between basic blocks is prone to mismatches due to instruction rearrangement when the number of nodes in a function CFG is too large. That is, the selector information of two basic blocks is consistent, but the contents of the instructions they contain are unrelated. Therefore, to ensure the consistency of basic block matching during the isomorphism process of similar function mapping CFG, this invention extracts the basic block instruction mnemonic as a program instruction granularity feature and introduces the Small Primes Product (SPP) algorithm. As shown in Algorithm 2, by assigning a corresponding small prime number to each instruction in the basic block, the product of the prime numbers corresponding to all instructions in the basic block can generate an SPP value representing the basic block. If the prime products of two basic blocks are the same, based on the unique decomposition form of the prime product and the commutative nature of the multiplication factors, it can be determined that the set of prime numbers in the product is the same, that is, the set of instructions in the corresponding basic blocks is the same. The basic block SPP, to a certain extent, represents the precise characteristics of the instruction set contained within a basic block. By adding the basic block SPP attributes to the attribute set used by the fixed-point selection algorithm, the mismatch problem caused by instruction rearrangement can be effectively solved.

[0087] Algorithm 2 Basic Block SPP Algorithm Description:

[0088]

[0089]

[0090] The LLVM-based backdoor location method for industrial software supply chains provided by this invention has the following advantages:

[0091] (1) This technology has stronger automation and scalability: the background technology relies on dynamic debugging to generate execution paths for specific inputs, which is not automated enough. The technology of this invention can handle large-scale industrial software without deep manual intervention, improving the automation and scalability of backdoor candidate region localization. Furthermore, it can adapt to new backdoor candidate region localization by updating and expanding the industrial software feature library.

[0092] (2) This technology does not rely on specific input simulation: The background method triggers and identifies backdoor candidate region codes by simulating user input, which requires accurate prediction or reproduction of the input that triggers the backdoor, and may not cover all potential backdoor triggering situations. The method of this invention, by combining a prior feature knowledge base for similarity calculation and difference analysis, can more comprehensively identify potential backdoor candidate regions, without being limited to the prediction or simulation of specific inputs.

[0093] (3) This technology has a stronger ability to locate backdoor candidate regions: The background technology uses heuristic methods to identify decision points related to authentication and command scheduling, which limits its effectiveness in detecting novel or complex backdoors. The method of this invention, by constructing a complete industrial software feature knowledge base, can more comprehensively discover complex backdoor candidate regions other than specific functions and special control flows.

[0094] Optionally, in some possible implementations, the data preprocessing module pre-creates a feature database of trusted industrial software, specifically including:

[0095] The data preprocessing module uses the lightweight database SQLite to extract structured features of the software, and creates a feature database for trusted industrial software based on the extracted structured features.

[0096] Optionally, in some possible implementations, the attribute set of the software structure features includes: the number of instructions contained in a function, the number of constants contained in a function, the number of strings contained in a function, the number of basic blocks contained in a function CFG, the number of edges contained in a function CFG, the number of sub-calls contained in a function CFG, the number of strings contained in a basic block, the shortest path length from a basic block to the CFG entry point, the shortest path length from a basic block to the CFG exit point, the number of sub-calls within a basic block, and the instruction mnemonics contained within a basic block.

[0097] Optionally, in some possible implementations, LLVMPython is used to extract predefined software structure features of the software to be detected, specifically including:

[0098] LLVMPython is used to extract graph structure information representing function calls within the software under test, as well as the structure information, number of functions, and function instruction information of each function, thereby using structural data features to represent the binary software program.

[0099] Optionally, in some possible implementations, the differential code analysis module based on structure matching uses the software structure features of the software under test and the corresponding trusted software to perform structure matching between function call graphs, creating an initial set of similar function mappings to achieve differential function identification, specifically including:

[0100] By performing structured matching of functions in the function call graph using a set of attributes and selectors, a set of initial function matching fixed points is obtained;

[0101] The triplet consisting of the number of nodes, edges, and subcalls in the function control flow graph is used as the selector, and the selector is regarded as a three-dimensional space vector;

[0102] Starting from the initial function matching fixed point, and combining it with the file function call relationship graph, the predecessor and successor relationships of the fixed point are used to propagate nodes to expand the mapping, and finally create a function call graph isomorphism between the two binary programs, that is, a set of similar function mappings.

[0103] Optionally, in some possible implementations, the structure-matching-based differential code analysis module sequentially performs structure matching between function control flow graphs for each similar function mapping in the initial set of similar function mappings, specifically including:

[0104] For matching the function control flow graph structure between a set of similar function mappings, a triple consisting of the number of basic blocks in the ingress shortest path, the number of basic blocks in the egress shortest path, and the number of subcalls is used as the selector. The attribute set consists of the number of basic block strings and the basic block SPP, where the basic block SPP is obtained by multiplying the odd prime numbers assigned to each node.

[0105] Optionally, some possible implementations may include all or part of the above-described implementations.

[0106] It should be understood that in the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this description, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples described in this specification, as well as some features of different embodiments or examples.

[0107] Of course, those skilled in the art can make various corresponding changes and modifications based on the present invention without departing from its spirit and essence, but such changes and modifications should all fall within the protection scope of the claims of the present invention.

Claims

1. A method for locating backdoors in an industrial software supply chain based on LLVM, characterized in that, include: The data preprocessing module pre-creates a feature database of trusted industrial software, which contains structured software features extracted from the intermediate language code level of each type of industrial software. The data preprocessing module uses a code conversion tool to convert the software to be detected into LLVM IR intermediate language code and obtains the software structure features corresponding to the version of the software to be detected from the feature database. The software structured feature extraction module extracts predefined software structured features of the software under test by selecting and defining the attribute set of software structured features and using LLVMPython. The differential code analysis module based on structure matching uses the software structure features of the software under test and the software structure features of the corresponding trusted software to perform structure matching between function call graphs, create an initial set of similar function mappings to realize differential function identification, and serve as the basis for fine-grained differential code identification; The differential code analysis module based on structure matching performs structure matching between function control flow graphs for each similar function mapping in the initial set of similar function mappings, identifies code differences at the basic block level of the software to be detected, and obtains candidate code areas for backdoors in the supply chain within the software to be detected.

2. The method for locating backdoors in the industrial software supply chain based on LLVM according to claim 1, characterized in that, The data preprocessing module pre-creates a feature database for trusted industrial software, specifically including: The data preprocessing module uses the lightweight database SQLite to extract structured features of the software, and creates a feature database for trusted industrial software based on the extracted structured features.

3. The method for locating backdoors in the industrial software supply chain based on LLVM according to claim 1, characterized in that, The attribute set of software structure features includes: the number of instructions contained in a function, the number of constants contained in a function, the number of strings contained in a function, the number of basic blocks contained in a function CFG, the number of edges contained in a function CFG, the number of sub-calls contained in a function CFG, the number of strings contained in a basic block, the shortest path length from a basic block to the CFG entry point, the shortest path length from a basic block to the CFG exit point, the number of sub-calls within a basic block, and the instruction mnemonics contained within a basic block.

4. The method for locating backdoors in the industrial software supply chain based on LLVM according to claim 3, characterized in that, This document describes how to extract predefined structural features from the software under test using LLVM Python. Specifically, it includes: LLVMPython is used to extract graph structure information representing function calls within the software under test, as well as the structure information, number of functions, and function instruction information of each function, thereby using structural data features to represent the binary software program.

5. The method for locating backdoors in the industrial software supply chain based on LLVM according to claim 1, characterized in that, The differential code analysis module based on structure matching uses the software structure features of the software under test and the corresponding trusted software structure features to perform structure matching between function call graphs, creating an initial set of similar function mappings to achieve differential function identification, specifically including: By performing structured matching of functions in the function call graph using a set of attributes and selectors, a set of initial function matching fixed points is obtained; The triplet consisting of the number of nodes, edges, and subcalls in the function control flow graph is used as the selector, and the selector is regarded as a three-dimensional space vector; Starting from the initial function matching fixed point, and combining it with the file function call relationship graph, the predecessor and successor relationships of the fixed point are used to propagate nodes to expand the mapping, and finally create a function call graph isomorphism between the two binary programs, that is, a set of similar function mappings.

6. The method for locating backdoors in the industrial software supply chain based on LLVM according to claim 1, characterized in that, The structure-matching-based differential code analysis module performs structure matching between function control flow graphs for each similar function mapping in the initial set of similar function mappings, specifically including: For matching the function control flow graph structure between a set of similar function mappings, a triple consisting of the number of basic blocks in the ingress shortest path, the number of basic blocks in the egress shortest path, and the number of subcalls is used as the selector. The attribute set consists of the number of basic block strings and the basic block SPP, where the basic block SPP is obtained by multiplying the odd prime numbers assigned to each node.

Images