CN115408700A - Open source component detection method based on binary program modularization - Google Patents

Abstract

The invention belongs to the technical field of open source component detection, and particularly relates to an open source component detection method based on binary program modularization. According to the method, through extracting the calling and address information of functions in the binary program, a coagulation algorithm for processing hierarchical community structure analysis of an undirected graph is improved into a BCM suitable for a directed graph, and the binary program module is divided by using the BCM. On the basis of binary program modularization, all modules are subjected to feature matching with the open source component, the specific module where the component is located is positioned, the multiplexing of the current file granularity is refined to the positioning detection of the module granularity, the search range of software security analysis tasks such as open source vulnerability detection is narrowed, and the efficiency of downstream tasks is improved. Experiments show that the method improves the detection precision of the open source assembly, greatly reduces the false alarm rate, and is improved by 60.12 percent compared with the existing open source assembly detection method B2SFinder with better file granularity; the detection efficiency is still maintained after the modular analysis is added.

Description

Open source component detection method based on binary program modularization

technical field

The invention belongs to the technical field of open source component detection, in particular to an open source component detection method based on binary program modularization.

Background technique

In the process of modern software development, with the increasing popularity of open source software (Open-Source Software, OSS), software reuse has become a common phenomenon. Developers often use the rich functions provided by open source software to shorten the development cycle and integrate more Time is spent on personalization development. In recent years, the amount of open source software has grown exponentially. As of now, there are more than 44 million repositories on Github, and a large number of open source software brings great convenience to software development. However, improper use of OSS can lead to potential security risks. Software with outdated OSS is more likely to be exploited. For example, a security flaw called Heartbleed was found in version 1.0.1 of OpenSSL, a popular cryptographic software library, before version 1.0.1g. For software using the vulnerable version 1.0.1 of this library, attackers can steal private information such as usernames and passwords, it affects many well-known software such as LibreOffice software from version 4.2.0 to 4.2.2 and VMware Workstation 10.

Commercial Off-The-Shelf (COTS) is usually released in a closed-source manner, and the source code cannot be directly obtained for software security analysis. In order to detect vulnerabilities in open source components, it is particularly important to identify reused open source software in binary programs. It plays an important role in various software security engineering related tasks, such as malware detection, vulnerability searching, reverse engineering, etc. Most of the current work extracts the features in the target binary program and source code, and selects an appropriate feature matching algorithm to identify open source components. However, existing works are deficient in two aspects, feature selection and recognition granularity of open source components in binary programs.

First of all, in terms of feature selection, some methods extract too few features or are easily affected by compilation optimization. Most methods rely on syntactic features such as strings and exported function names, but some commercial software strips strings in order to hide its software composition. Therefore, in order to overcome the singleness of features, control flow graph becomes a new choice. However, due to the influence of compilation optimization, the control flow is easy to change, so the control flow graph cannot be matched as a suitable feature.

Secondly, in terms of the recognition granularity of open source components in binary programs, the existing method is to detect open source components from the file granularity, that is, the entire binary program is used as the granular unit, and the extracted features are matched through algorithms such as direct mapping and hierarchical matching. Then calculate the feature similarity to judge whether open source components are reused in the entire program. For the identification of open source components of binary programs, some downstream tasks will be carried out, such as vulnerability detection, whether it contains high-risk vulnerabilities; whether it is affected by supply chain poisoning; pushing suppliers to update versions of important dependent components, etc. Based on the current method, if the downstream task is to search for open source vulnerabilities, the scope is the entire binary program, which is a high requirement for time and workload.

Contents of the invention

Aiming at the defects and problems existing in the open source component detection method, the present invention provides an open source component detection method based on binary program modularization.

The solution adopted by the present invention to solve the technical problem is: a binary program modularization-based open source component detection method, including binary program modularization and open source component identification, wherein the binary program modularization includes the following content:

(1) Extract the function address and create the function call graph for the binary program, and construct the input graph of the modularization step through the extraction of the function address and the function-directed call relationship;

(2) Use the improved BCM algorithm based on modularity to divide the binary program modules;

Open source component identification includes the following:

(1) Feature selection and extraction: For each module of the binary program, the complex branch sequences of character types and functions in each module are extracted as extraction features, where the character types include string literals, string arrays, and exported function names ; For the complex branch sequence of the function, the branch sequence of switch/case, if/else is used as the selected feature;

(2) Open source component identification at module granularity: compare the extracted features of each module of the binary program with the source code features, and detect the binary modules where the open source components are located.

In the above-mentioned open source component detection method based on binary program modularization, the division of binary program modules includes the following steps:

Ⅰ. Initially assume that each function is an independent module. For any adjacent node i and node j, calculate the corresponding modularity increment ΔQ when node i is added to the module C where its neighbor node j is located.

In the formula: S _{i, in} represents the sum of the weights of nodes i and the internal functions of module C; m is the sum of the weights of all edges in the network; W _c is the sum of the weights of all edges in module _C ; The sum of the weights of the edges associated with the internal function;

Then calculate the modularity increment of node i and all neighbor nodes, and select the largest one; when the value is positive, add node i to the module where the corresponding neighbor node is located; otherwise, node i stays in the original module;

Repeat until the merging phenomenon no longer occurs, and the first layer of modules is divided;

Ⅱ. Based on the module results formed in Ⅰ, repeat the method in Ⅰ to divide the new module results into modules, and obtain the second layer of modules, where the weight of the edges between the modules is the sum of the weights of the edges of all nodes between the two modules ;

Repeat until the network modularity does not increase any more, and the binary program module division is completed.

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

The above-mentioned open source component detection method based on binary program modularization, the process of extracting the exported function name from the binary program is as follows: firstly, it is necessary to obtain all the function names in the module, and then by traversing the exported function names in the entire binary program, retain The name of the exported function in the module.

The above-mentioned open source component detection method based on binary program modularization, the comparison process of open source components is: traverse the feature types to be matched, obtain the features of this type of modules and open source components; traverse the acquired features, and add the matching features to the matching features In the list, when the matched feature score exceeds the threshold, the type of feature is added to the matched feature type list. If the list is not empty, the module reuses open source components.

The above-mentioned open source component detection method based on binary program modularization, when identifying open source components,

a. For character type features, when the binary program module is consistent with the character features in the open source component, the feature is determined to be a match;

b. For the complex branch sequence of the function, the if/else feature is matched by the length of the longest common subsequence. When the length of the longest common subsequence exceeds the set threshold, it is determined as a match.

Beneficial effects of the present invention: the present invention is based on the hierarchical characteristics of binary program functions, extracts function addresses and calling relationships, and performs binary program modularization; feature-based module granularity open source component detection, and extracts binary modules and source codes according to feature selection criteria The features of open source components are detected on the test data set, and the accuracy is 60.12% higher than that of B2SFinde, which greatly reduces the false positive rate and improves the efficiency of feature extraction.

When the present invention evaluates the detection efficiency of module granularity and the application of open source components in COTS, the results show that even if the modularization process is added, the detection efficiency is still maintained; and the present invention can detect the reuse of open source components in COTS, and locate specific modules, Improve the efficiency of downstream tasks in software security analysis.

Description of drawings

Figure 1 is a schematic diagram of the overall framework of the present invention.

Figure 2 is a frequency statistical diagram of the number of open source component positioning modules.

Figure 3 is a statistical chart of the reuse frequency of open source components.

Detailed ways

The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

Embodiment 1: The open source component detection method based on binary program modularization provided by this embodiment, as shown in FIG. 1 , is divided into two stages as a whole, namely binary program modularization and feature-based module granularity open source component identification. In the modularization stage, the direct function call information of the binary program is extracted, and the information is represented in the form of a graph, and the functions in the binary program are clustered using the improved BCM method based on modularity. In the open source component recognition stage at module granularity, extract character strings, exported function names, string arrays, and complex branch sequence features in functions, match each module of the binary program with the open source component, and identify the correspondence between the binary module and the open source component .

The first stage: binary program modularization, mainly includes the following contents

1. Attribute selection and graph creation

In the work of binary program analysis, common graphs include call graph (call graph, CG), control-flow graph (control-flow graph, CFG) and data flow graph (data flow graph, DFG).

Both the call graph and the control flow graph are graphs representing directed transfer, but the emphasis is different from the nodes. The call graph represents the call relationship between functions in the entire program, and it is the flow direction of function calls in the program. The flow direction nodes are functions, and the edges represent the call relationship. The control flow graph is a graph that represents the program execution flow within a function, and represents the statement jump flow in the function. The flow direction nodes are program statements, and the edges represent the execution flow. A data flow graph represents a graph of data dependencies between a series of operations. The edges in the graph represent the data flow from the result of one operation to the input of another operation. Once all the input data values of an instruction are consumed, it is will execute. When an instruction executes, it generates a new data value, and this data value is propagated to other connected instructions. Binary program analysis staff use more control flow graphs and data flow graphs to better understand functions.

But the modularization of binary programs is a global analysis. In this case, the control flow graph and data flow graph are not applicable. Therefore, the function call graph is selected to have a global analysis of the entire binary program. The function call graph shows how different functions of a program call each other. The functions that call each other generally cooperate to complete the same function, so they have a greater probability of belonging to the same module. The input graph of the modularization step is constructed by extracting the function address and the directed calling relationship of the function.

2. Binary program module division

(1) Module Quality Metrics

Modularity Q is a commonly used standard to measure the quality of community division. Its basic idea is to compare the network after community division with the corresponding null model to measure the quality of community division. The so-called null model corresponding to a network refers to a random graph model that has some of the same properties as the network, such as the same number of edges or the same degree distribution, and is completely random in other respects. Binary program module division is clustering for functions, which can be compared to community detection in network graphs. Therefore, this paper uses the modularity Q in community detection as a measure of the effect of module division, and the modularity is defined as:

Among them, i and j represent nodes; m is the sum of all edge weights in the network; A _ij represents the edge weight between nodes i and j; k _i represents the sum of edge weights connected to node i; c _i represents the community to which node i belongs ;c _j indicates the community to which node j belongs; δ( _ci ,c _j ) indicates whether node i and node j belong to the same community, and the belonging value is 1, otherwise it is 0.

(2) Binary program modularization method

The community structure of the network has the characteristics that the internal nodes of each community are relatively closely connected, and the connections between various communities are relatively sparse. The "high cohesion, low coupling" module of the program is very similar to the "community" of the complex network, and the development of community detection technology is relatively mature. Therefore, this embodiment uses the community detection method to modularize the binary program. However, some community detection algorithms need to know the number of communities in advance, such as spectral analysis, community detection algorithms based on machine learning, and the number of modules of binary programs is unknown. The algorithm based on the concept of modularity does not need to know the number of communities in advance.

In this embodiment, the agglomeration algorithm based on the concept of modularity applicable to undirected graphs is improved through the extracted binary function addresses and function directed call information, and a BCM method for directed graph detection is obtained to modularize binary programs. Each functional module implemented in the software is hierarchical, and it is represented as a file in each folder in the source code file directory. The algorithm for selecting hierarchical community structure analysis fits the hierarchical characteristics of software function realization.

Specifically, using the BCM algorithm to divide binary program modules into two stages:

Ⅰ. Initially assume that each function is an independent module; for any adjacent node i and node j, calculate the corresponding modularity increment when adding node i to the module where its neighbor node j is located (denoted as module C) ΔQ,

Among them, S _{i, in} represents the sum of the weights of nodes i and the internal functions of module C; m is the sum of all edge weights in the network; W _c is the weight sum of all edges inside module C; S _c is the sum of all edges connected to module C The weight sum of the edges associated with the function of .

Calculate the modularity increments of node i and all neighbor nodes, and then select the largest one. When the value is positive, add node i to the module where the corresponding neighbor node is located; otherwise, node i stays in the original module. This module merging process is repeated until no more merging occurs, thus dividing the first layer of modules.

Ⅱ. A new module result is formed based on the process Ⅰ. The weight of the connection between the modules is the sum of the weights of all the node connections between the two modules. Then repeat the method in I to divide the new module results into modules to obtain the second layer of modules. And so on, until the network modularity Q no longer increases.

The binary program modularization example algorithm is shown in Table 1.

Initialize the modularity of each module to -1 (line 2), and then iteratively move the nodes to obtain the modularity after movement (lines 5-6). If the modularity increases, merge the modules (lines 7-9) , until the modularity no longer increases (lines 10-11), stop the iterative process.

Table 1 Binary program modularization example algorithm

Using community detection technology to divide binary programs into modules solves the current problem of binary program module clustering and provides a basis for open source component detection at the new module granularity.

Phase 2: Open Source Component Identification

At present, the recognition granularity of open source components for binary programs is at the file level. The problem to be solved is to detect whether the entire binary program reuses open source components, and the location of open source components is not accurately located. In this embodiment, the binary program modules are matched with the open source components one by one, the modules of the open source components are located, the identification of the file granularity is refined to the module granularity, and the analysis scope is narrowed for the downstream tasks in the software security work. The main contents are as follows.

1. Feature selection and extraction

Commonly used features of existing methods include strings, exported function names, integer constants, global arrays, call graphs (callgraph, CG), and control-flow graphs (control-flow graph, CFG). After most open source components extract features, there is almost no enumeration array. In the process of detecting open source components, the ratio of detecting open source components through integer arrays is close to zero. Integer constants are obviously affected by compilation. During compilation and optimization, a large number of immediate values that have nothing to do with the source code, such as memory offsets and stack offsets, are introduced into the binary code as noise. The call graph and control flow graph will also change due to compilation optimizations.

This embodiment excludes the above-mentioned global arrays that have no practical value for detection and will increase the workload of feature extraction, and integer constants, call graphs, and control flow graph features that are easily affected by compilation optimization, and select strings, string arrays, and exported function names. and complex branching sequences of functions. The extracted features are shown in Table 2.

Table 2 Feature selection

For the detection of open source components, some existing methods are to compile the source code into a binary program, and then perform binary comparison. But it will produce features such as reducing strings, resulting in lower matching rate compilation settings and time consumption problems.

This embodiment is directly aimed at source code analysis, combining compilation information before extracting features, and extracting features only from files related to compilation. On the one hand, it reduces the workload of feature extraction. On the other hand, it eliminates irrelevant codes that will not be reused by binary programs, such as test files.

(1) Strings and arrays, export function names

For each module of the binary program, through the address of each function in the module, obtain all instruction addresses of the function, traverse the data references of the instructions, and extract the referenced strings.

Take the string extraction algorithm as an example to describe the process of extracting features from binary modules. as shown in Table 3.

Table 3 Module string extraction algorithm flow

Obtain all fragments of the function through the address of each function in the module (lines 3-4), traverse all instructions in each function fragment, and traverse the data reference address of the instruction (lines 5-6), when the address When storing a string, add the address and value of the string to the string list (lines 7-13).

All exported function names can be obtained from the entire binary program, which is different from extracting the exported function names in the module. First, you need to obtain all the function names in the module, and then by traversing the exported function names in the entire binary program, keep them in the module. The exported function name. For a given source code file, the source code is parsed into an abstract syntax tree (Abstract Syntax Tree, AST) by clang, and the feature extraction of the source code is converted into an operation on the AST, thereby extracting strings, string arrays and functions in the source code name. But string features are easy to remove, especially as log messages and error messages. When the software does not contain useful string features that can be matched, the selection of other features needs to be considered.

(2) Complex branching sequences of functions

Call graphs and control flow graphs commonly used in binary similarity comparison work are easily affected by compilation optimization. In order to achieve the purpose of supplementing code features that are resistant to compilation optimization, these two types of features are excluded from the selection range. Through analysis, it is found that the switch/case and if/else structures in the function are stable during the compilation process. Therefore, the branch sequence of switch/case and if/else can be used as the selected feature, which includes comparison and jump in the function and relatively complete information about branches.

For the binary module, the if/else feature is extracted by analyzing its comparison and jump instructions, and the switch/case feature is extracted by using the function jump table in the module. After clang parses the source code, it analyzes the branch sequence of the intermediate code and extracts features.

2. Open source component identification at module granularity

As shown in Figure 1, the detection stage of open source components is to match each module of the binary program with the source code of the open source components. The specific process is to extract strings, export function names, and complex branch sequence features of functions from each module and source code of the binary program, compare each module feature with the source code feature, and detect the binary module where the open source component is located.

For character-type features, when the binary program module is consistent with the character features in the open source component, the features are considered to match.

A complex branching sequence of functions is characterized by semantically matching them. The if/else feature is matched by the length of the longest common subsequence, and it is determined as a match when the length of the longest common subsequence exceeds the set threshold. Sequence alignment of the switch/case unordered list with the default branch added to the source code and the switch/case in the module. The threshold involved in the matching judgment of each feature is determined based on experience. When the matching score of the feature exceeds the threshold, it is determined that the module reuses open source components.

An example of the specific matching process between each module and the open source component is shown in Table 4.

Table 4 Example of module granular open source component monitoring algorithm

Traverse the feature types to be matched (line 4), obtain the features of this type of modules and open source components (lines 6-7), traverse the acquired features, and add the matched features to the matching feature list (lines 8-11 ), when the matched feature score exceeds the threshold, add this type of feature to the matched feature type list, if the list is not empty, then the module reuses open source components (lines 12-15).

Embodiment 2: This embodiment evaluates the open source component identification of module granularity, the impact of global array features on detection results, and detection efficiency through experiments, and carries out detection and analysis on actual commercial software (COTS). Use IDAPro to disassemble the binary program, use IDAPython to extract function call information and the features of each module of the binary program, and use clang and llvm tools to extract the source code features.

1. Dataset

Open Source Component Identification at Module Granularity The binary programs in the evaluation experiments use binary programs with known reuse relationships as test data sets, including the test programs in BCFinder, ISRD and ModX. The source code is obtained from hosting platforms such as Github. The binary program test data set and the source code description of the open source components that have a reuse relationship with it are shown in Table 5

Table 5 Datasets used for accuracy evaluation

Some software datasets involved in COTS detection applications at module granularity are shown in Table 6.

Table 6 Part COTS

2. Comparison method

The experiment selects the open source B2SFinder and BinaryAI, an online software component analysis platform officially released by Tencent Security Keen Lab, as comparison methods from the existing open source component detection work. B2SFinder selects more comprehensive features in the current work of matching binary programs with file granularity to the source code of open source components, and the results are better than other methods. BinaryAI is an intelligent analysis platform for software component analysis (SCA) of binary files. Compare B2SFinder and BinaryAI with the recognition results of open source components at module granularity in this paper.

3. Detection and evaluation of module granularity

(1) Evaluation indicators

The experiment selects precision, Recall and F1-Score as evaluation indicators, defined as shown in the formula.

Among them, TP refers to the number of correctly matched open source components, TN is correctly matched as the number of non-reusable open source components, FN refers to the number of wrongly matched open source components, and TP is correctly matched as non-reusable open source components The number of components.

(2) Evaluation of the detection effect of open source components at module granularity

For the experimental test data set, the module granularity detection and evaluation are carried out, and the module granularity detection BSCA-M in this paper is compared with three methods, namely, the detection BSCA without modularization, and the comparison between the current binary program matching source code of open source components. The results of the excellent B2SFinder and BinaryAI methods are shown in Table 7.

Table 7 Detection effect evaluation

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%

It can be seen from the table that the accuracy of the module granularity detection open source component of the present invention is 82.35%, which is close to BinaryAI. Compared with the accuracy of only 51.43% achieved by B2SFinder, the accuracy of this paper is significantly improved by about 60.12%. The reason is that the detection of module granularity in the present invention greatly reduces false positive cases and lowers false alarm rate. The recall rate is between B2SFinder and BinaryAI, which balances the phenomenon that the difference between the recall rates of the two methods is too large.

From the overall evaluation results, the F1-Score of the method of the present invention reaches 71.8%, which is 14.22% and 3.71% higher than BinaryAI and B2SFinder respectively, and the detection of whether the binary program contains open source components is refined to locate the specific binary module where the component is located .

(3) Impact assessment of global array features

The modularized open-source component detection method of the present invention does not select integer arrays and enumeration array features, and the feature selection of B2SFinder includes global arrays. In order to evaluate the impact of global array features on detection results and efficiency, the process of modularization needs to be excluded. Therefore, BSCA (without modularization) and B2SFinder were compared and analyzed, and the results are shown in Table 8.

Table 8 Impact assessment of global array features

method precision recall F1-Score time consuming BSCA 64% 72.73% 69.33% 920.38 B2SFinder 60% 81.82% 69.23% 1151.01

It can be seen from the table that compared with B2SFinder, BSCA without modularization has a slightly lower recall rate, but slightly higher precision. The main reason is that some false positive cases in B2SFinder are matched by such global arrays, which reduces the detection rate. precision. F1-Score tends to be equal, indicating that removing the integer array and enumeration array in B2SFinder has little effect on F1-Score.

Feature extraction was performed for all open source components involved in the test, comparing the efficiency of no extraction with extraction of such global arrays. It can be seen from the table that compared with B2SFinder, BSCA significantly reduces the feature extraction time consumption of open source components by 20% due to the fact that integer and enumerated array features are not selected.

Therefore, this embodiment removes the selection of the global integer array and the enumeration array, reduces the feature extraction workload for the global array, and avoids the comparison of invalid features in the stage of feature matching.

(4) Efficiency evaluation

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

Table 9 Efficiency Evaluation

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

It can be seen from the data in the table that, compared with the method BSCA-M of the present invention and B2SFinder, the time consumption of the whole process is relatively close. Although the method of the present invention includes a modularization stage for binary programs, this process increases the time for extracting binary program information and using community detection technology to divide binary modules, and in the detection stage, features are extracted and matched for each module, but it still remains efficiency.

(5) Quantity and frequency analysis of open source component positioning modules

Analysis of the detection results of open source components at the granularity of binary program modules reveals that more than one module is located in multiplexed open source components. The ideal situation is that the functions that reuse open source components are divided into the same module, and there is only one module that matches the open source component. For all test binary programs, the number of open source component positioning modules and the corresponding frequency statistics are performed, as shown in Figure 2.

It can be seen from the figure that the frequency of the number of open source component positioning modules is 1 is 57.14%, and the frequency of more than 3 is only 21.42%. Therefore, the modularization result of the binary program is generally better. The functions that cooperate to complete the same function are divided into the same module, and the functions that reuse the same component will not be mistakenly divided into other modules. In the open source component detection stage, the complex The open source components used are accurately positioned in the same module, achieving better module granularity detection results.

4. COTS open source component detection application with module granularity

Commercial software is usually released in a closed-source manner. When open-source code containing vulnerabilities is reused in the 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 experimental selection Some commonly used commercial software is used for detection, and the list of some open source components reused by COTS is shown in Table 10.

Table 10 COTS reused open source components

According to the open source component detection of COTS module granularity, the analysis found that some open source components are frequently reused in COTS. Combining with the open source components reused in the detection and evaluation of module granularity, the frequency of reuse of such open source components was counted. The result As shown in Figure 3.

The figure shows the top 5 frequently reused open source components, among which xz is the most frequently reused among these components, accounting for 50%, followed by zlib and libpng, accounting for 16.67%. Therefore, when a component contains a vulnerability, the open-source component detection at the module granularity of the present invention can narrow the search scope of the vulnerability in a large number of programs that reuse such components, and only need to perform vulnerability detection in the corresponding module.

Claims (6)

1. A method for detecting open source components based on binary program modularization, characterized in that: comprise binary program modularization and open source component identification, wherein binary program modularization includes the following: (1) Extract the function address and create the function call graph for the binary program, and construct the input graph of the modularization step through the extraction of the function address and the function-directed call relationship; (2) Use the improved BCM algorithm based on modularity to divide the binary program modules; Open source component identification includes the following: (1) Feature selection and extraction: For each module of the binary program, the complex branch sequences of character types and functions in each module are extracted as extraction features, where the character types include string literals, string arrays, and exported function names ; For the complex branch sequence of the function, the branch sequence of switch/case, if/else is used as the selected feature; (2) Open source component identification at module granularity: compare the extracted features of each module of the binary program with the source code features, and detect the binary modules where the open source components are located. 2. the open-source component detection method based on binary program modularization according to claim 1, is characterized in that: the binary program module division comprises the following steps: Ⅰ. Initially assume that each function is an independent module. For any adjacent node i and node j, calculate the corresponding modularity increment ΔQ when node i is added to the module C where its neighbor node j is located.

In the formula: S _{i, in} represents the sum of the edge weights between node i and the internal function of module C; m is the sum of all edge weights in the network; W _c is the weight sum of all edges inside module _C ; The sum of the weights of the edges associated with the internal function; Then calculate the modularity increment of node i and all neighbor nodes, and select the largest one; when the value is positive, add node i to the module where the corresponding neighbor node is located; otherwise, node i stays in the original module; Repeat until the merging phenomenon no longer occurs, and the first layer of modules is divided; Ⅱ. Based on the module results formed in Ⅰ, repeat the method in Ⅰ to divide the new module results into modules, and obtain the second layer of modules, where the weight of the edges between the modules is the sum of the weights of the edges of all nodes between the two modules ; Repeat until the network modularity does not increase any more, and the binary program module division is completed. 3. the open-source component detection method based on binary program modularization according to claim 1, is characterized in that: the process of extracting character string from binary module is: obtain all fragments of this function by the address of each function in the module, 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. 4. The open source component detection method based on binary program modularization according to claim 1, characterized in that: the process of extracting and exporting function names from the binary program is as follows: firstly all function names in the module need to be obtained, and then by traversing the entire The method of exporting function names in the binary program retains the exporting function names in the module. 5. The open source component detection method based on binary program modularization according to claim 1, characterized in that: the comparison process of the open source component is: traverse the feature type to be matched, and obtain the type feature of the module and the open source component; traverse and obtain feature, add the matching feature to the matching feature list, when the matching feature score exceeds the threshold, add this type of feature to the matching feature type list, if the list is not empty, the module reuses open source components. 6. The open source component detection method based on binary program modularization according to claim 5, characterized in that: when the open source component is identified, a. For character type features, when the binary program module is consistent with the character features in the open source component, the feature is determined to be a match; b. For the complex branch sequence of the function, the if/else feature is matched by the length of the longest common subsequence. When the length of the longest common subsequence exceeds the set threshold, it is determined as a match.

Images