Open source component detection method based on binary program modularization

Abstract

This invention belongs to the field of open-source component detection technology, specifically relating to an open-source component detection method based on binary program modularization. This method extracts function call and address information from the binary program, improves the agglomerative algorithm used for hierarchical community structure analysis of undirected graphs to a BCM (Binary Community Structure) algorithm applicable to directed graphs, and uses the BCM to divide the binary program into modules. Based on binary program modularization, all modules are matched with the features of open-source components to locate the specific module where the component resides. This refines the current file-level reuse to module-level location detection, narrowing the search scope for software security analysis tasks such as open-source vulnerability detection and improving the efficiency of downstream tasks. Experiments show that this invention improves the accuracy of open-source component detection, significantly reduces the false positive rate, and achieves a 60.12% improvement compared to the current best file-level open-source component detection method, B2SFinder; it also maintains detection efficiency after adding modular analysis.

Description

Technical Field

[0001] This invention belongs to the field of open source component detection technology, specifically relating to an open source component detection method based on binary program modularization. Background Technology

[0002] In modern software development, with the increasing popularity of open-source software (OSS), software reuse has become a common phenomenon. Developers often leverage the rich functionality provided by open-source software to shorten development cycles and spend more time on personalized development. In recent years, the number of open-source software repositories has grown exponentially. Currently, there are over 44 million repositories on GitHub, and this vast amount of open-source software has greatly facilitated software development. However, improper use of OSS can lead to potential security risks. Software containing outdated OSS is more likely to be exploited. For example, a security vulnerability called Heartbleed was discovered in version 1.0.1 of OpenSSL (a popular cryptographic library), prior to version 1.0.1g. For vulnerable versions of 1.0.1 using this library, attackers could steal private information such as usernames and passwords. This affected many well-known software programs, such as LibreOffice versions 4.2.0 to 4.2.2 and VMware Workstation 10.

[0003] Commercial off-the-shelf (COTS) software is typically released in a closed-source manner, making it impossible to directly access the source code for software security analysis. Therefore, identifying reused open-source software within binary programs is crucial for detecting vulnerabilities in open-source components. This plays a vital role in various software security engineering tasks, such as malware detection, vulnerability searching, and reverse engineering. Current work largely involves extracting features from target binary programs and source code, then selecting appropriate feature matching algorithms for open-source component identification. However, existing work has shortcomings in two aspects: feature selection and the granularity of open-source component identification within binary programs.

[0004] Firstly, regarding feature selection, some methods extract too few features or are easily affected by compiler optimizations. Most methods rely on syntactic features such as strings and exported function names, but some commercial software removes strings to hide its software components. Therefore, to overcome the limitation of feature simplification, control flow graphs become a new option. However, due to the influence of compiler optimizations, control flow is easily altered, thus control flow graphs cannot be used as suitable features for matching.

[0005] Secondly, regarding the granularity of identifying open-source components in binary programs, existing methods detect open-source components at the file level. This means using the entire binary program as the unit of measurement, matching extracted features using algorithms such as direct mapping and hierarchical matching, and then calculating feature similarity to determine whether open-source components are reused throughout the program. Identifying open-source components in binary programs involves downstream tasks such as vulnerability detection (checking for high-risk vulnerabilities), assessing supply chain vulnerability poisoning, and pushing suppliers to update versions of critical dependent components. Based on current methods, searching for open-source vulnerabilities across the entire binary program is time-consuming and labor-intensive. Summary of the Invention

[0006] To address the shortcomings and problems of existing open-source component detection methods, this invention provides an open-source component detection method based on binary program modularization.

[0007] The solution adopted by this invention to solve its technical problem is: an open-source component detection method based on binary program modularization, including binary program modularization and open-source component identification, wherein binary program modularization includes the following:

[0008] (1) Extract function addresses and create function call graphs for binary programs. Construct the input graph of modular steps by extracting function addresses and directed function call relationships.

[0009] (2) The binary program modules are divided using the BCM algorithm based on modularity improvement;

[0010] Open source component identification includes the following:

[0011] (1) Feature selection and extraction: For each module of the binary program, extract the character types and complex branch sequences of functions in each module as extracted features. The character types include string literals, string arrays and exported function names. For the complex branch sequences of functions, the branch sequences of switch / case and if / else are selected as features.

[0012] (2) Module-level open source component identification: The extracted features of each module of the binary program are compared with the source code features to detect the binary module where the open source component is located.

[0013] The above-mentioned open-source component detection method based on binary program modularization includes the following steps in dividing binary program modules:

[0014] I. Initial assumption: Each function is an independent module. For any adjacent nodes i and j, calculate the module degree increment ΔQ when node i is added to the module C containing its neighbor node j.

[0015]

[0016] In the formula: S i,in W represents the sum of the edge weights connecting node i to the internal function of module C; m is the sum of the edge weights in the network; W c It is the sum of the weights of all edges within module C; S c It is the sum of the weights of all edges associated with functions inside module C;

[0017] Then calculate the module degree increment between node i and all its neighboring nodes, and select the one with the largest value; when the value is positive, add node i to the module where the corresponding neighboring node is located; otherwise, node i remains in its original module.

[0018] Repeat this process until no more merging occurs, thus defining the first-level module.

[0019] II. Based on the module results formed in I, repeat the method in I to divide the new module results into modules to obtain the second layer of modules, where the weight of the edge between modules is the sum of the weights of all the edges between the nodes of the two modules;

[0020] Repeat until the network modularity no longer increases, completing the binary program module partitioning.

[0021] The above-mentioned open-source component detection method based on binary program modularization extracts strings from binary modules as follows: obtain all fragments of each function in the module by its address, traverse all instructions in each function fragment, traverse the data reference address of the instruction, and when the address stores a string, add the address and value of the string to the string list.

[0022] The above-mentioned open-source component detection method based on binary program modularization extracts exported function names from the binary program as follows: First, it is necessary to obtain all function names in the module, and then retain the exported function names in the module by traversing the exported function names in the entire binary program.

[0023] The above-mentioned open-source component detection method based on binary program modularization has the following comparison process: traverse the feature types to be matched and obtain the features of the same type for the module and the open-source component; traverse the obtained features and add the matching features to the matching feature list; when the score of the matching feature exceeds the threshold, add the feature of that type to the matching feature type list; if this list is not empty, then the module reuses the open-source component.

[0024] The aforementioned open-source component detection method based on binary program modularity, when identifying open-source components,

[0025] a. For character type features, if the character features of the binary program module are consistent with those of the open-source component, then the feature is determined to be a match;

[0026] b. For complex branch sequences of a function, the if / else feature is matched by the length of the longest common subsequence. If the length of the longest common subsequence exceeds a set threshold, it is considered a match.

[0027] The beneficial effects of this invention are as follows: Based on the hierarchical nature of binary program functions, this invention extracts function addresses and call relationships to modularize binary programs; based on feature-based module-level open-source component detection, it extracts features of binary modules and source code according to feature selection criteria, and performs open-source component detection on the test dataset, achieving an accuracy 60.12% higher than B2SFinde, greatly reducing the false positive rate and improving feature extraction efficiency.

[0028] When evaluating the efficiency of module-level detection and the application of open-source components in COTS, the results show that even with the addition of a modularization process, the detection efficiency is still maintained. Moreover, the present invention can detect the reuse of open-source components in COTS and locate specific modules, thereby improving the efficiency of downstream tasks in software security analysis. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the overall framework of the present invention.

[0030] Figure 2 A frequency statistics chart of the number of modules located for open source components.

[0031] Figure 3 A statistical chart showing the frequency of reuse of open-source components. Detailed Implementation

[0032] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0033] Example 1: This example provides an open-source component detection method based on binary program modularity, such as... Figure 1 As shown, the process is divided into two stages: binary program modularization and feature-based module-level open-source component identification. In the modularization stage, direct function call information is extracted from the binary program and represented as a graph. An improved BCM method based on modularity is used to cluster the functions in the binary program. In the module-level open-source component identification stage, features such as strings, derived function names, string arrays, and complex branch sequences within functions are extracted. Each module of the binary program is then matched with open-source components to identify the correspondence between binary modules and open-source components.

[0034] Phase 1: Binary program modularization, mainly including the following content

[0035] 1. Attribute selection and graph creation

[0036] In binary program analysis, common graphs include call graphs (CG), control-flow graphs (CFG), and data flow graphs (DFG).

[0037] Call graphs and control flow graphs are both graphs representing directed transmission, but they differ in their focus and nodes. A call graph represents the call relationships between functions throughout a program, showing the flow of function calls within the program. Flow nodes are functions, and edges represent call relationships. A control flow graph, on the other hand, represents the execution flow within a function, showing the flow of statement jumps within the function. Flow nodes are program statements, and edges represent execution flow. A data flow graph represents the data dependencies between a series of operations. Edges in the graph represent the data flow from the result of one operation to the input of another. Once all input data values ​​of an instruction have been consumed, it is executed. When an instruction is executed, it generates new data, which is propagated to other connected instructions. Those working in binary program analysis frequently utilize control flow graphs and data flow graphs for a better understanding of functions.

[0038] However, modularization of binary programs requires a global analysis. In this case, control flow graphs and data flow graphs are not applicable. Therefore, function call graphs are chosen to provide a global analysis of the entire binary program. A function call graph represents how different functions in a program call each other. Functions that call each other generally collaborate to complete the same function, and therefore are more likely to belong to the same module. The input graph for the modularization steps is constructed by extracting function addresses and directed function call relationships.

[0039] 2. Binary program module division

[0040] (1) Module quality measurement

[0041] Modularity Q is a commonly used metric for measuring the quality of community partitioning. Its basic idea is to compare the partitioned network with the corresponding null model to measure the quality of the partitioning. The null model corresponding to a network refers to a random graph model that shares some properties with the network, such as the same number of edges or the same degree distribution, but is completely random in other aspects. Binary program modularization is a clustering of functions, which can be compared to community detection in network graphs. Therefore, this paper uses modularity Q from community detection as a metric for the effectiveness of modular partitioning. Modularity is defined as:

[0042]

[0043] Where i and j represent nodes; m is the sum of the weights of all edges in the network; A ij k represents the edge weight between nodes i and j; i c represents the sum of the edge weights connected to node i; i Indicates the community to which node i belongs; c j Indicates the community to which node j belongs; δ(c i ,c j The value indicates whether node i and node j belong to the same community; a value of 1 indicates that they belong, and a value of 0 indicates otherwise.

[0044] (2) Binary Program Modularization Method

[0045] The community structure of a network is characterized by tightly connected nodes within each community, while connections between communities are relatively sparse. The "high cohesion, low coupling" modules of a program are very similar to the "communities" of a complex network, and community detection technology is relatively mature. Therefore, this embodiment uses a community detection method for modularizing the binary program. However, some community detection algorithms require prior knowledge of the number of communities, such as spectral analysis and machine learning-based community detection algorithms, while the number of modules in a binary program is unknown. Algorithms based on the concept of modularity do not require prior knowledge of the number of communities.

[0046] This embodiment improves the agglomerative algorithm based on the concept of modularity, applicable to undirected graphs, by extracting binary function addresses and directed function call information, resulting in a BCM method for directed graph detection, which modularizes the binary program. The various functional modules implemented in the software are hierarchical, represented by files in different folders in the source code directory. The chosen algorithm for hierarchical community structure analysis aligns with the hierarchical characteristics of the software's functional implementation.

[0047] Specifically, the BCM algorithm for partitioning binary program modules is divided into two stages:

[0048] I. Initially, assume that each function is an independent module; for any adjacent nodes i and j, calculate the module degree increment ΔQ when node i is added to the module (denoted as module C) containing its neighbor node j.

[0049]

[0050] Among them, S i,in W represents the sum of the edge weights connecting node i to the internal function of module C; m is the sum of the edge weights in the network; W c It is the sum of the weights of all edges within module C; S c It is the sum of the weights of all edges associated with functions inside module C.

[0051] Calculate the module degree increment of node i relative to all its neighboring nodes, and then select the largest one. If the value is positive, add node i to the module containing the corresponding neighboring node; otherwise, node i remains in its original module. This module merging process is repeated until no further merging occurs, thus defining the first layer of modules.

[0052] II. Based on process I, a new module result is formed. The weight of the edges between modules is the sum of the weights of all edges between nodes in the two modules. Then, the method in I is repeated to partition the new module result into modules, resulting in the second layer of modules. This process is continued until the network module degree Q no longer increases.

[0053] Example algorithms for modular binary programs are shown in Table 1.

[0054] Initialize the module degree of each module to -1 (line 2), then iterate through the node movement to obtain the module degree after the movement (lines 5-6). If the module degree increases, merge the modules (lines 7-9) until the module degree no longer increases (lines 10-11), then stop the iteration process.

[0055] Table 1. Example Algorithms for Binary Program Modularization

[0056]

[0057] Using community detection technology to divide binary programs into modules effectively solves the current problem of binary program module clustering, and also provides a foundation for the detection of open source components at a new module granularity.

[0058] Phase Two: Open Source Component Identification

[0059] Currently, the granularity for identifying open-source components in binary programs is at the file level. This addresses the issue of detecting whether the entire binary program reuses open-source components, but it doesn't accurately pinpoint the location of these components. This embodiment matches each binary program module with an open-source component, locating the module containing the open-source component. This refines the identification from the file level to the module level, narrowing the analysis scope for downstream tasks in software security work. The main contents are as follows.

[0060] 1. Feature selection and extraction

[0061] Existing methods commonly use features including strings, exported function names, integer constants, global arrays, call graphs (CG), and control-flow graphs (CFG). After feature extraction, most open-source components almost entirely lack enumerated arrays. In the process of detecting open-source components, the detection rate using integer arrays is close to zero. Integer constants are significantly affected by compilation; during compilation and optimization, a large number of immediate values ​​unrelated to the source code, such as memory offsets and stack offsets, are introduced as noise into the binary code. Call graphs and control-flow graphs also change due to compilation optimizations.

[0062] This embodiment excludes global arrays, integer constants, call graphs, and control flow graphs, which are of no practical value for detection and only increase the workload of feature extraction. Instead, it selects strings, string arrays, exported function names, and complex branch sequences of functions. The extracted features are shown in Table 2.

[0063] Table 2 Feature Selection

[0064]

[0065] For open-source component detection, some existing methods compile the source code into binary programs and then perform binary comparisons. However, this results in reduced features such as strings, leading to lower matching rates and time consumption issues in compilation settings.

[0066] This embodiment focuses directly on source code analysis. Before extracting features, it incorporates compilation information and extracts features only from files related to compilation. This reduces the workload of feature extraction and eliminates irrelevant code that will not be reused by the binary program, such as files like "test".

[0067] (1) Strings and arrays, exported function names

[0068] For each module of the binary program, obtain the addresses of all instructions for that function by using the address of each function in the module, traverse the data references of the instructions, and extract the referenced strings.

[0069] The process of extracting features from binary modules is described using a string extraction algorithm as an example, as shown in Table 3.

[0070] Table 3 Module String Extraction Algorithm Flow

[0071]

[0072] Get all segments of each function in the module by the address of each function (lines 3-4), traverse all instructions in each function segment, traverse the data reference address of the instruction (lines 5-6), and when the address stores a string, add the address and value of the string to the string list (lines 7-13).

[0073] Extracting exported function names from a module differs from retrieving them from the entire binary program. First, all function names within the module need to be obtained. Then, by traversing the exported function names throughout the binary program, the module's exported function names are retained. For a given source code file, clang parses the source code into an Abstract Syntax Tree (AST), transforming source code feature extraction into AST operations, thereby extracting strings, string arrays, and function names from the source code. However, string features are easily deleted, especially those from log messages and error messages. When the software lacks matching useful string features, alternative feature selections need to be considered.

[0074] (2) Complex branching sequences of functions

[0075] Call graphs and control flow graphs, commonly used in binary similarity comparison, are easily affected by compiler optimizations. To supplement code features resistant to compiler optimizations, these two types of features are excluded from the selection scope. Analysis reveals that switch / case and if / else structures within functions are stable during compilation. Therefore, switch / case and if / else branch sequences can be selected as features, as they contain relatively complete information about comparisons, jumps, and branches within the function.

[0076] For binary modules, if / else features are extracted by analyzing their comparison and jump instructions, while switch / case features are extracted using the module's function jump table. After clang parses the source code, it analyzes the branch sequences in the intermediate code to extract features.

[0077] 2. Identification of open-source components at the module level

[0078] like Figure 1 As shown, the detection phase of the open-source component involves matching each module of the binary program with the source code of the open-source component. Specifically, this process involves extracting strings, function names, and complex branch sequence features from each module and source code of the binary program. Each module's features are then compared with the source code features to detect the binary module containing the open-source component.

[0079] For character type characteristics, a characteristic is considered a match if the character characteristics of the binary program module and the open-source component are consistent.

[0080] Complex branch sequences of functions are semantically matched for features. The longest common subsequence length (LCS) is used to match if / else features; a match is considered complete when the LCS length exceeds a set threshold. The unordered switch / case statements with default branches in the source code are compared with the switch / case statements in the module. The thresholds for matching each feature are determined empirically; if a feature's matching score exceeds the threshold, the module is considered to be reusing an open-source component.

[0081] Table 4 shows examples of the specific matching process between each module and open-source component.

[0082] Table 4 Examples of Open Source Component Monitoring Algorithms at the Module Granularity Level

[0083]

[0084] Iterate through the feature types to be matched (line 4), get the features of that type from the module and open source components (lines 6-7), iterate through the obtained features, add the matching features to the matching feature list (lines 8-11), when the score of the matching feature exceeds the threshold, add the feature of that type to the matching feature type list. If this list is not empty, then the module reuses the open source component (lines 12-15).

[0085] Example 2: This example evaluates the impact of global array features on detection results and detection efficiency for module-level open-source component identification through experiments, and conducts detection analysis on actual commercial software (COTS). IDA Pro is used to disassemble the binary program, IDA Python is used to extract function call information and features of each module in the binary program, and clang and LLVM tools are used to extract source code features.

[0086] 1. Dataset

[0087] The binary programs used in the module-level open-source component identification and evaluation experiment utilize binary programs with known reuse relationships as the test dataset, including test programs from BCFinder, ISRD, and ModX. The source code was obtained from hosting platforms such as GitHub. Table 5 shows the binary program test dataset and descriptions of the open-source component source code with which it has reuse relationships.

[0088] Table 5 shows the dataset used for accuracy evaluation.

[0089]

[0090] Table 6 shows some of the software datasets involved in the module-level COTS detection application.

[0091] Table 6 Partial COTS

[0092]

[0093] 2. Comparison Methods

[0094] The experiment selected the open-source B2SFinder and BinaryAI, an online software component analysis platform officially released by Tencent Security Keen Lab, as comparison methods for existing open-source component detection work. B2SFinder, in current work on matching open-source component source code with binary programs at the file level, selects more comprehensive features and achieves better results than other methods. BinaryAI is an intelligent analysis platform for binary file software component analysis (SCA). The results of B2SFinder and BinaryAI are compared with the open-source component identification results at the module level presented in this paper.

[0095] 3. Module granularity detection and evaluation

[0096] (1) Evaluation indicators

[0097] The experiment selected precision, recall, and F1-Score as evaluation metrics, defined as shown in the formula.

[0098]

[0099]

[0100]

[0101] Among them, TP refers to the number of components correctly matched as reused open source components, TN refers to the number of components correctly matched as non-reused open source components, FN refers to the number of components incorrectly matched as reused open source components, and TP refers to the number of components correctly matched as non-reused open source components.

[0102] (2) Evaluation of the effectiveness of open source component detection at the module level

[0103] For the experimental test dataset, a module-level detection evaluation was conducted. The module-level detection method BSCA-M in this paper was compared with three other methods: BSCA without modularization, B2SFinder (which is currently considered superior in open-source binary program matching component source code), and BinaryAI. The results are shown in Table 7.

[0104] Table 7 Evaluation of Detection Results

[0105] method precision recall F1-Score BSCA-M 82.35％ 63.64％ 71.8％ B2SFinder 60％ 81.82％ 69.23％ BinaryAI 84.62％ 50％ 62.86％

[0106] As shown in the table, the accuracy of the open-source component for module-level granularity detection in this invention is 82.35%, close to that of BinaryAI. Compared to B2SFinder's accuracy of only 51.43%, the accuracy of this invention is significantly improved by approximately 60.12%. This is because the module-level granularity detection in this invention greatly reduces false positives and lowers the false positive rate. The recall rate is between that of B2SFinder and BinaryAI, effectively balancing the large difference in recall rates between the two methods.

[0107] Overall, the method of this invention achieved an F1-Score of 71.8%, which is 14.22% and 3.71% higher than BinaryAI and B2SFinder, respectively. Furthermore, it refines the detection of whether a binary program contains open-source components to locate the specific binary module where the component is located.

[0108] (3) Impact assessment of global array features

[0109] The modular open-source component detection method of this invention does not select integer arrays or enumerated array features, while B2SFinder's feature selection includes global arrays. To evaluate the impact of global array features on detection results and efficiency, the modularization process needs to be excluded. Therefore, BSCA (without modularization) and B2SFinder are compared and analyzed, and the results are shown in Table 8.

[0110] Table 8. Impact Assessment of Global Array Features

[0111] method precision recall F1-Score Time consumption BSCA 64％ 72.73％ 69.33％ 920.38 B2SFinder 60％ 81.82％ 69.23％ 1151.01

[0112] As can be seen from the table, the recall rate of the unmodularized BSCA is slightly lower than that of B2SFinder, but the precision is slightly higher. The main reason is that some false positives in B2SFinder are matched through such global arrays, which reduces the detection precision. The F1-Scores are close to equal, indicating that removing the integer array and enumeration array in B2SFinder has almost no impact on the F1-Score.

[0113] Feature extraction was performed on all open-source components involved in the test, and the efficiency of extracting such global arrays was compared. The table shows that BSCA, compared to B2SFinder, significantly reduced the feature extraction time for open-source components by 20% because it did not select integer and enumerated array features.

[0114] Therefore, this embodiment eliminates the selection of global integer arrays and enumeration arrays, reducing the workload of feature extraction for global arrays, and avoiding the comparison of invalid features during the feature matching stage.

[0115] (4) Efficiency Evaluation

[0116] The time for the two stages of BSCA-M for module granularity detection in this paper, namely the modularization process and open source component detection, is compared with that of B2SFinder for open source component detection. The results are shown in Table 9, with the unit being seconds (s).

[0117] Table 9 Efficiency Assessment

[0118] method Modular Open source component detection sum BSCA-M 63.402 1356.527 1419.929 B2SFinder — 1255.682 1255.682

[0119] As can be seen from the data in the table, the overall process time of the BSCA-M method of this invention is similar to that of B2SFinder. Although the method of this invention includes a modularization stage for binary programs, which increases the time for extracting binary program information and dividing binary modules using community detection technology, and further involves extracting features and matching each module during the detection stage, it still maintains efficiency.

[0120] (5) Analysis of the number and frequency of open source component location modules

[0121] Analysis of the open-source component detection results at the module level of binary programs revealed that reused open-source components were located in more than one module. Ideally, functions reusing open-source components should be grouped into the same module, with only one module matching the open-source component. Statistics were compiled on the number of open-source component-located modules and their corresponding frequencies for all test binary programs. Figure 2 As shown.

[0122] As shown in the figure, the frequency of open-source component location modules with 1 value is 57.14%, while those with more than 3 value account for only 21.42%. Therefore, the overall modularization result of binary programs is good. Functions that collaborate to complete the same function are divided into the same module, and functions that reuse the same component will not be incorrectly classified into other modules. In the open-source component detection stage, reused open-source components can be accurately located in the same module, achieving good module granularity detection results.

[0123] 4. Application of COTS open-source component detection at the module level

[0124] Commercial software is usually released in a closed-source manner. When open-source code containing vulnerabilities is reused in software, the software faces certain security risks. Therefore, open-source component detection is performed on commercial software to locate the specific module where the component is located. The experiment selects some commonly used commercial software for detection. A list of some open-source components reused by COTS is shown in Table 10.

[0125] Table 10 COTS Reusable Open Source Components

[0126]

[0127] Based on the detection and analysis of open-source components at the COTS module level, it was found that some open-source components are frequently reused in COTS. Combining this with the evaluation of reused open-source components at the module level, the frequency of reuse of these open-source components was statistically analyzed, and the results are as follows: Figure 3 As shown.

[0128] The figure shows the top 5 most frequently reused open-source components. Among them, xz is reused the most frequently, accounting for 50%, followed by zlib and libpng, at 16.67%. Therefore, when a component contains a vulnerability, the module-level open-source component detection of this invention can narrow the search scope of the vulnerability in a large number of programs that reuse such components, and vulnerability detection only needs to be performed in the corresponding module.

Claims

1. A method for detecting open-source components based on binary program modularity, characterized in that: This includes binary program modularization and open-source component identification, among which, Binary program modularization includes the following: (1) Extract function addresses and create function call graphs for binary programs. Construct the input graph of modular steps by extracting function addresses and directed function call relationships. (2) Divide the binary program into modules, specifically including the following steps: I. Initial assumption: Each function is an independent module. For any adjacent nodes i and j, calculate the module degree increment ΔQ when node i is added to the module C containing its neighbor node j. In the formula: S i,in W represents the sum of the edge weights connecting node i to the internal function of module C; m is the sum of the edge weights in the network; W c It is the sum of the weights of all edges within module C; S c It is the sum of the weights of all edges associated with functions inside module C; Then calculate the module degree increment between node i and all its neighboring nodes, and select the one with the largest value; when the value is positive, add node i to the module where the corresponding neighboring node is located; otherwise, node i remains in its original module. Repeat this process until no more merging occurs, thus defining the first-level module. II. Based on the module results formed in I, repeat the method in I to divide the new module results into modules to obtain the second layer of modules, where the weight of the edge between modules is the sum of the weights of all the edges between the nodes of the two modules; Repeat until the network modularity no longer increases, thus completing the binary program module partitioning; Open source component identification includes the following: (1) Feature selection and extraction: For each module of the binary program, extract the character types and complex branch sequences of functions in each module as extracted features. The character types include string literals, string arrays and exported function names. For complex branch sequences of functions, the branch sequences of switch / case or if / else are selected as features. (2) Module-level open source component identification: The extracted features of each module of the binary program are compared with the source code features to detect the binary module where the open source component is located.

2. The open-source component detection method based on binary program modularization according to claim 1, characterized in that: The process of extracting strings from a binary module is as follows: obtain all segments of each function in the module by its address, traverse all instructions in each function segment, traverse the data reference address of the instruction, and when the address stores a string, add the address and value of the string to the string list.

3. The open-source component detection method based on binary program modularization according to claim 1, characterized in that: The process of extracting exported function names from a binary program is as follows: First, all function names in the module need to be obtained. Then, the exported function names in the module are retained by traversing the exported function names in the entire binary program.

4. The open-source component detection method based on binary program modularization according to claim 1, characterized in that: The comparison process for open-source components is as follows: iterate through the feature types to be matched, and obtain the feature types of the module and the open-source component; iterate through the obtained features, and add the matching features to the matching feature list. When the score of the matching feature exceeds the threshold, add the feature type to the matching feature type list. If this list is not empty, then the module reuses the open-source component.

5. The open-source component detection method based on binary program modularization according to claim 4, characterized in that: When identifying open-source components a. For character type features, if the character features of the binary program module are consistent with those of the open-source component, then the feature is determined to be a match; b. For complex branch sequences of a function, the if / else feature is matched by the length of the longest common subsequence. If the length of the longest common subsequence exceeds a set threshold, it is considered a match.

Images