Multi-level binary component identification method for industrial Internet of Things firmware

Abstract

The invention belongs to the field of malicious software protection, and particularly relates to a multilevel binary component identification method for industrial Internet of Things firmware. Comprising the following steps: S1, extracting a to-be-detected binary component and a function in a known binary component library; s2, calculating similarity according to a known binary component library and a function in a to-be-detected binary component to obtain a function region, and generating a function region for each anchor point; s3, calculating the similarity between the function region of the binary component to be detected and the function region in the binary component library to determine whether the function region forms a code reuse region or not, and if the function region is the reuse region, determining that the binary component is an effective binary component; s4, collecting Internet of Things components and component information therein; s5, identifying the component by using component version information in the component information; s6, extracting binary code features from the binary file of the component; s7, constructing a component version coordinate system, and screening candidate versions from the coordinate system; and S8, determining a final component version from the candidate versions.

Description

Technical Field

[0001] The present invention belongs to the field of malware protection, and in particular is a multi-level binary component identification method for industrial Internet of Things firmware. Background Art

[0002] From the perspective of component supply chain, there are relatively few studies on the detection and identification of third-party components in IoT firmware. Current research on the detection of third-party open source libraries is mainly concentrated in the Android field. Zhan et al. used parallel root packages as interdependent parts to form an open source library and proposed version-based Android vulnerability detection (Zhan X, Fan L, Chen S, We F, Liu T, Luo X, Liu Y. Atvhunter: Reliable version detection of third-party libraries for vulnerability identification in android applications, Proc. of ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021). They extracted the control flow graph (CFG) of the Android application and used the CFG graph as a coarse-grained feature to match potential open source libraries. Then, they extracted the opcodes in each basic block of the CFG as fine-grained features and used the opcodes to accurately identify the third-party library version. Yang et al. proposed Modx, a framework that uses novel program modularization technology to decompose programs into function-based fine-grained modules (Yang C, Xu Z, Chen H, Liu Y, Gong X, Liu B. ModX: binary level partially imported third-party library detection via program modularization and semantic matching, Proc. of Proceedings of the 44th International Conference on Software Engineering, 2022). This scheme uses program modularization technology to group individual functions into modules, and extracts grammatical and semantic features from between and within modules as similarity features to detect whether open source library modules are called in Android programs. Compared with the detection of open source libraries in Android programs, the components in IoT firmware appear in the form of binary executable files, and the source code is not easy to obtain. The above-mentioned library source code-based method cannot be applied to the detection of binary components.Zhang et al. analyzed the lack of updates for third-party components in a small number of IoT firmwares and proposed a centrally maintained IoT software functional framework (Zhang H, Anilkumar A, Fredrikson M, Agarwal Y. Capture: Centralized Library Management for Heterogeneous {IoT} Devices, Proc. of 30th USENIX Security Symposium (USENIX Security 21), 2021). This framework provides third-party component software functions in firmware while also centrally maintaining components to reduce attacks from vulnerabilities in IoT internal components. Zhao et al. proposed a framework for identifying component vulnerabilities in firmware (Zhao B, Ji S, Xu J, TianY, Wei Q, Wang Q, Lyu C, Zhang X, Lin C. A large-scale empirical analysis of the vulnerabilities introduced by third-party components in IoT firmware, Proc. of Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, 2022). This framework uses grammatical features and control flow graph features to detect third-party component versions in firmware and then identify corresponding vulnerabilities. Cheng et al. used lightweight symbolic execution and static analysis to identify component versions and solved the problem of version string confusion (Cheng Y, Yang S, Lang Z, Shi Z, Sun L. VERI: A Large-scale Open-Source Components Vulnerability Detection inIoT Firmware, Proc. of Computers&Security, 2023).Chen et al. proposed to use TCP retransmission messages to expand the fingerprint space of IoT devices, so that the device identification granularity reaches the device model level, and the connectionless detection method greatly reduces the time overhead of large-scale identification (Chen Y, Pan J, Yu D, Ma Y, Yang Y.Retransmission-Based TCP fingerprints for fine-grain IoV edge device identification, Proc. of IEEE Transactions on Vehicular Technology, 2022). Li et al. proposed an area matching framework for detecting third-party components in binary files (Li S, Wang Y, DongC, Yang S, Li H, Sun H, Lang Z, Chen Z, Wang W, Zhu H, Sun L. LibAM: An areamatching framework for detecting third-party libraries in binaries, Proc. ofACM Transactions on Software Engineering and Methodology, 2023), which connects isolated functions on the function call graph (FCG) to function areas and detects third-party components by comparing the similarities of these function areas, thereby significantly reducing the impact of different optimization options and architectures. Dong et al. proposed a method for identifying open source software versions (Dong C, Li S, Yang S, Xiao Y, Wang Y, Li H, Li Z, Sun L.LibvDiff: Library Version Difference Guided OSS Version Identification in Binaries, Proc. of Proceedings of the 46. thIEEE / ACM International Conference on Software Engineering. 2024), using binary code similarity detection to detect subtle differences through precise symbol information and function-level code changes. Existing work mainly focuses on Web and Android application scenarios, and there are relatively few studies on binary component identification in IoT firmware. At the same time, there are problems such as repeated version strings, similarity of non-homologous functions, and heterogeneous binary codes across platforms in binary components, which will make it difficult to improve the scale and accuracy of binary component identification using existing methods. Summary of the invention

[0003] In order to solve the above problems, the present invention provides a multi-level binary component identification method for industrial Internet of Things firmware.

[0004] The present invention adopts the following technical solution: a multi-level binary component identification method for industrial Internet of Things firmware, comprising: S1: Extract functions from the binary component to be detected and the known binary component library, represent all functions as vectors, and calculate the cosine similarity between the binary component to be detected and all function vectors in the known binary component library. When the cosine similarity between two functions exceeds a certain threshold, these functions are called anchor points. S2: Calculate the similarity based on the known binary component library and the functions in the binary component to be detected, obtain the function region, and generate a function region for each anchor point; S3: by calculating the similarity between the function area of ​​the binary component to be detected and the function area in the binary component library, to determine whether it constitutes a code reuse area, if it is a reuse area, it is considered to be a valid binary component; S4: Collect IoT components and information about their components; S5: using component version information in the component information to identify the component; S6: extract binary code features from the binary file of the component; S7: Build a component version coordinate system and filter candidate versions from the coordinate system; S8: Determine the final component version from the candidate versions.

[0005] In some embodiments, step S1 includes: S11: extracting functions from the binary component to be detected and the known binary component library; S12: Use the Structure2vec network to obtain the vector representation of the function and calculate the cosine similarity between the target binary file and all function vectors in the known binary component library; S13: When the cosine similarity between two functions exceeds a certain threshold, these functions are called anchor points.

[0006] In some embodiments, the cosine similarity in step S12 is calculated by the following formula: Assume that the two function vectors are: Then the cosine similarity is .

[0007] In some embodiments, step S2 includes: S21: After the anchor points are generated, the anchor points of the binary component to be detected correspond to the anchor points in the known binary component library, which are called anchor pairs. The anchor pairs with too large substructure differences are pre-filtered from the anchor pairs obtained in S1; S22: The anchor point and all calling functions are considered as a region, and the isolated function nodes are connected to the region on the anchor point using the function call graph.

[0008] In some embodiments, step S3 includes: S31: Determine the structural similarity of the anchor point pairs in each region; Input the function region into the trained graph neural network, convert the region into a vector through the graph neural network, output the vector corresponding to the function region, and then calculate the cosine similarity between the vectors, the result is the structural similarity; S32: determining the maximum alignment length of anchor point pairs in each region; Pick a pair of anchor points as the starting point, and then randomly select the next generation of anchor points as the new starting point, making sure they do not overlap; Record the alignment length of the new list ,if ,but , and reiterate the selection; when the number of iterations reaches the upper limit, the iteration stops and does not update value; S33: If the structural similarity and alignment length of the regions exceed the set thresholds, these regions are identified as reused regions, and the binary components and their related functions within these reused regions are recorded to identify valid binary components.

[0009] In some embodiments, step S4 includes: S41: Collect IoT components using crawlers, real-world device extraction, and OTA methods; S42: Perform IoT component preprocessing, filter obvious non-firmware files by suffix matching, analyze the remaining collected files, and delete non-component files based on the returned file type, using Binwalkand other component image extraction tools to extract the firmware internal file directory.

[0010] In some embodiments, step S5 includes: According to the storage format of the version string in the component, there are two methods to extract it: If the version string is an integrated string, first use a regular expression to match the version string, then filter it through the natural language processing model to extract the actual version string; For components whose version strings are non-integrated, restore the control flow graph and call graph of the component; then locate the entry point and candidate version point, and based on the control flow graph and points, delete irrelevant nodes and edges from the control flow graph; finally, use input-driven symbolic execution to determine whether the path from the entry point to the candidate version point is reachable. If the candidate version point is reachable, the corresponding string literal is regarded as the true version.

[0011] In some embodiments, step S6 includes: In order to capture the code changes between different versions, the component source code is compiled into a binary file. First, the binary code is converted into assembly language code using a disassembly tool. Then the program control flow graph is built, the structural information of the code is extracted, and symbol parsing is performed. Finally, extraction is performed based on the analysis results.

[0012] In some embodiments, step S7 includes: S71: Establish a component version coordinate system, the coordinate system consists of the reference version and the version coordinates of all versions, and select version o and version n that contain sufficient version difference features as the reference version; S72: Version The version coordinates are obtained by the following formula: in, Represents the name of the extracted function in the binary of component i version. Indicates the new differences between component version o and version n. Represents the deletion difference between component version o and version n; S73: For version , whose version coordinates are ,when This version will be retained if the following conditions are met; in, represents the threshold for similar version positioning, representing the target binary file, X i Indicates the difference between the current component version and version o, Y i Indicates the difference between the current component version and version n, XB Indicates the difference between the target binary component version and version o, Y B Indicates the difference between the target binary component version and version n.

[0013] In some embodiments, step S8 includes: S81: Generate all anchor paths of the target binary using a function call-based anchor path filter, collect the version difference function anchor paths of each candidate version, and find the same anchor nodes in the target binary file; S82: Select an anchor path in the target binary file that has the same call type sequence as the candidate version; S83: Count the terminal nodes in the selected anchor path in the target binary file and select the function with the highest frequency.

[0014] Compared with the prior art, the present invention has the following beneficial effects: 1. The present invention proposes an IoT high-risk binary component identification technology based on anchor regions, program control flow and binary code features, analyzes the reuse similarity of anchor regions in target binary files, and determines specific code fragments reused in target binary files, thereby achieving effective distinction between different components.

[0015] 2. The present invention uses text classification and program control flow to establish dependencies between firmware and binary components on a large scale; by enhancing the intermediate language after decompiling the executable code, it overcomes the cross-platform and cross-compilation heterogeneous problems of similarity detection of binary codes of high-risk components, thereby achieving accurate identification of component versions.

[0016] 3. The present invention uses large-scale multi-level component identification based on binary codes, breaking through the difficulty of identifying components and their dependencies in IoT firmware. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A schematic diagram of the IoT binary component recognition based on anchor point regions according to the method of the present invention; Figure 2 A schematic diagram of large-scale binary component version identification based on program control flow of the method of the present invention; Figure 3 This is a schematic diagram of fine-grained component version identification based on binary code features of the method of the present invention. DETAILED DESCRIPTION

[0018] The present invention is described in detail below through specific embodiments in conjunction with the accompanying drawings, but does not constitute a limitation of the present invention.

[0019] This embodiment provides an example of high-risk component identification using the method of the present invention.

[0020] In summary, when IoT manufacturers use components, the generated component binary execution codes are polymorphic and heterogeneous due to the influence of the firmware operating environment and compilation. How to accurately identify polymorphic and heterogeneous binary components in IoT firmware is a great challenge. The method of the present invention includes two levels: "component identification" and "component version identification". At the "component identification" level, the existing IoT binary component identification methods are difficult to achieve a balance between high precision and efficiency when facing different optimization options and architectures, and their identification results are usually limited to the file level and cannot deeply reveal complex code reuse relationships. The present invention uses anchor area technology to efficiently identify binary components on a large scale; at the "component version identification" level, component version information is usually stored in binary files in the form of strings. The present invention proposes a large-scale binary component version identification method based on program control flow. In view of the difficulty in identifying binary components where the developer does not provide a version string or loses the version string during the compilation process, the present invention proposes a fine-grained component version identification based on binary code features.

[0021] In order to achieve the purpose of the present invention, the technical solution adopted is summarized as follows: 1. “Component Identification” Level Large-scale and efficient identification of binary components via anchor region techniques S1: Extract functions from the binary component to be detected and the known binary component library, represent all functions as vectors, and calculate the cosine similarity between all function vectors in the binary component to be detected and the known binary component library. When the cosine similarity between two functions exceeds a certain threshold, these functions are called anchor points.

[0022] S2: Based on the known binary component library and the functions in the binary component to be detected, the similarity is calculated to obtain the function region, and a function region is generated for each anchor point.

[0023] S3: By calculating the similarity between the function area of ​​the binary component to be detected and the function area in the binary component library, it is determined whether it constitutes a code reuse area. If it is a reuse area, it is considered to be a valid binary component.

[0024] 2. “Component Version Identification” Level Large-scale binary component version identification based on program control flow S4: Collect IoT components and information about their components.

[0025] S5: Identify the component using the component version information in the component information.

[0026] Fine-grained component version identification based on binary code features S6: Extracting binary code features from binary files S7: Build a high-risk component version coordinate system and screen candidate versions.

[0027] S8: Use binary code similarity detection technology to determine the final high-risk component version.

[0028] The specific implementation method of step S1 is as follows: S11: Extract functions from the binary component to be detected and the known binary component library through IDA Pro; S12: Use the Structure2vec network to obtain the vector representation of the function and calculate the cosine similarity between the target binary file and all function vectors in the known binary component library; Cosine similarity is calculated using the following formula: Assume that the two function vectors are: Then the cosine similarity is .

[0029] S13: When the cosine similarity between two functions exceeds a certain threshold, these functions are called anchor points.

[0030] The reason why the function vector cosine similarity calculation method is used in step S1 is that in the IoT environment, due to the complex characteristics of cross-architecture and cross-compilation, existing code reuse detection methods such as string extraction or function matching often lead to inaccurate recognition results when identifying high-risk component codes in target binary files due to repeated occurrences of strings and a large number of similar non-homologous functions, making it difficult to meet actual application requirements. In addition, existing methods have difficulty in identifying specific code fragments that are reused in target binary files. By calculating the cosine similarity between two functions, and when it exceeds a certain threshold, these functions are called anchor points.

[0031] The specific implementation method of step S2 is as follows: S21: After the anchor points are generated, the anchor points of the binary components to be detected correspond to the anchor points in the known binary component library, which are called anchor pairs. Since the number of anchor pairs directly determines the time complexity and space complexity of the similarity comparison, the anchor pairs with too large substructure differences are pre-filtered from the anchor pairs obtained in S1, thereby reducing the number of comparisons of the anchor pairs.

[0032] Design a filter based on anchor point features. The filter is based on the structural features of the anchor point in the CG graph. Starting from the anchor point, the minimum spanning tree (MST) is obtained based on the depth-first method, and the depth features of the tree are extracted from the MST. , use layer traversal to obtain the number of anchor points contained in each layer of the MST Composition sequence ,Will and Two parameters are used as input to calculate the weighted comprehensive score , and set the acceptance threshold (1) Among them, α and β are feature weights. Greater than , accept the anchor pair, otherwise skip the anchor pair in subsequent region comparisons.

[0033] S22: The anchor point and all calling functions are considered as a region, and the isolated function nodes are connected to the region on the anchor point using the function call graph.

[0034] The specific implementation method of step S3 is as follows: The two regions of the anchor pair are actually two function lists. The function region of the binary component to be detected is a function list without function names, and the TPL region is a function list with function names. After obtaining the two regions, we aim to compare the similarities of the two regions to determine whether they are reused regions. We design an anchor alignment algorithm by calculating the maximum alignment length of the anchor pairs in the two regions. to evaluate the similarity.

[0035] S31: Determine the structural similarity of the anchor point pairs in each region; Specifically, the function region is input into the trained graph neural network (here graph neural network), the graph neural network converts the region into a vector, outputs the vector corresponding to the function region, and then calculates the cosine similarity between the vectors, and the result is the structural similarity; S32: determining the maximum alignment length of anchor point pairs in each region; Pick a pair of anchor points as the starting point, and then randomly select the next generation of anchor points as the new starting point, making sure they do not overlap; Record the alignment length of the new list l ,if ,but , and reiterate the selection; when the number of iterations reaches the upper limit, the iteration stops and does not update value; S33: If the structural similarity and alignment length of the regions exceed the set thresholds, these regions are identified as reused regions, and the binary components and their related functions within these reused regions are recorded to identify valid binary components.

[0036] The specific implementation method of step S4 is as follows: S41: Collect IoT components using crawlers, real-world device extraction, and OTA methods; Firmware is collected mainly from three sources: 1) official website; 2) FTP Site; 3) Community, formulate different crawler strategies for websites and web data sources of different manufacturers and different architectures, crawl firmware and firmware manufacturer, model and version information, and use the crawler from the actual device or device upgrade when the crawler cannot take effect due to the website settings (strong anti-crawler, registration requirements, etc.) OTA The former obtains the firmware from the flash chip on the actual device development board or through UART and JTAG The debugging interface extracts the firmware, which sniffs the traffic of the device, extracts the binary data stream from the TCP Segment, and finally generates the firmware locally according to different protocol combinations.

[0037] S42: Perform IoT component preprocessing, filter obvious non-firmware files by suffix matching, analyze the remaining collected files, and delete non-component files based on the returned file type, using Binwalk and other component image extraction tools to extract the firmware internal file directory.

[0038] (1) Filter obvious non-firmware files by suffix matching, such as .txt files. (2) Use BinaryAnalysis Next Generation (BANG) to analyze the remaining collected files and delete non-firmware files based on the returned file type. (3) Use Binwalk and other firmware image extraction tools to extract the firmware internal file directory, but some firmware is encrypted by the manufacturer and needs to be used Binwalk Determine whether the firmware cannot be extracted due to encryption, and then determine the decompression method of the firmware through network search. Binwalk Unable to handle the file system, using sasquatch and jefferson to replace binwalk In unsquashfs and jffsdump , and by designing new plugins for binwalk Unable to process file system.

[0039] The specific implementation method of step S5 is as follows: The specific implementation method is as follows: Based on the firmware collection and decompression, the component version information in the component information is used to identify the component. The semantic information in these component binary files is written by the open source software development team when writing the source code, using GNU binutils Under the kit stringsThe command prints out a readable string containing the version number of the component. The version string of the component is stored in two forms. For the integrated string, that is, the (BusyBox v1.22.1) form, a regular expression is used to match all class version information, and then filtered through a natural language processing model. The model consists of a word embedding layer, a CNN layer, a BiGRU layer, and an MHA layer. The word embedding layer consists of Word2Vec Skip-gram generates word embedding representation on the preprocessed semantic output; the CNN layer and BiGRU layer extract local features and global features of the semantic output respectively; the MHA layer extracts key semantic features, and finally Softmax Implement readable string classification to extract real version information; For non-integrated version strings, restore the control flow graph (CFG) and call graph (CG) of the component. The CFG shows all possible execution paths in the component. In the CFG, nodes are basic blocks and edges are transfers of control. You can also use IDA Pro Provided idpython Build a CFG for each basic block of a binary function using idappython Extract function information and convert the CFG block-block Connect with the call relationship to create the CG of the binary function. Use the depth-first search algorithm and topological sorting to traverse all paths between the entry point and the candidate version point, cut off the nodes and edges in the CFG graph that are not involved in the path, and then determine the irrelevant callers based on the pollution propagation of data dependencies and prune them to reduce time consumption. Finally, use symbolic execution to determine which candidate version point is reachable through the pruned CFG and function hooks. The specific process is as follows: Figure 2 shown.

[0040] The specific implementation method of step S6 is as follows: In order to capture the code changes between different versions, the component source code is compiled into a binary file, and the necessary binary features are extracted from the component binary file using a static feature extraction method. First, the binary code is converted into assembly language code using a disassembly tool, and then the program control flow graph is constructed to extract the structural information of the code, perform symbolic parsing, and finally extract based on the analysis results.

[0041] The specific implementation method of step S7 is as follows: The specific implementation method is as follows: In order to quantify the gap between high-risk component versions, a high-risk component version coordinate system is introduced. The coordinate system consists of the version coordinates of the reference version and all versions.

[0042] Reference versions are used to provide the version difference and build axis. Component versions are sorted by release date and two versions are selected that contain enough version difference features to detect functions modified in the other version. In the high-risk component version coordinate system, the version coordinate of each version is a two-element tuple (x, y), whose value represents the difference between the target binary and the two reference versions.

[0043] For efficiency, only extracted function names are used as features when calculating version coordinates, because these function names are stable and will be retained in the binary file. and , The version coordinates of are calculated as follows: (2) in, Represents the name of the extracted function in the binary of component i version. Indicates the new differences between component version o and version n. Indicates the deletion difference between component version o and version n. When selecting the possible versions of the target binary file from all versions in the database, in order to narrow the gap between the screening versions, a candidate function filter is proposed to screen out candidate functions in two steps. First, for version , whose version coordinates are ,when This version will be retained when formula 3 is satisfied.

[0044] (3) in, The threshold for similar version positioning represents the target binary. In other words, any version that is close enough to the target binary will be retained as a potential candidate version. Secondly, by comparing the versions one by one, the versions with added and deleted basic features (the extracted basic features include function names and string literals, etc.) in the version differences are further filtered. If two versions cannot be distinguished directly by the added and deleted basic features, both versions will be retained as candidate versions. Otherwise, versions with fewer matching functions will be filtered out.

[0045] The specific implementation method of step S8 is as follows: The specific implementation methods are as follows: S81: Generate all anchor paths of the target binary using a function call-based anchor path filter, collect version difference function anchor paths of each candidate version, and find the same anchor nodes in the target binary file.

[0046] S82: Select an anchor path in the target binary file that has the same call type sequence as the candidate version; Anchor Paths: Anchor paths are paths extracted from the software call graph based on the extracted functions. In the paths, the edges are labeled according to the call types. Call paths represent direct and indirect call relationships from one node to another in the software call graph. The extracted functions are designated as anchors, and the paths originating from them are named anchor paths.

[0047] S83: Count the terminal nodes in the selected anchor path in the target binary file and select the function with the highest frequency.

[0048] The function embedding features are generated based on the intermediate code enhancement method. Function embedding features: Function embedding is a feature vector generated by a binary code similarity detection tool, which represents the semantics of a binary function.

[0049] After binary code decompilation, the assembly code is converted into the same intermediate code LLVM-IR , which can be divided into four steps: (1) Function normalization: Regularly replace the assembly instructions of the terminal node function and the candidate version function, such as replacing the numerical constant with 0 and replacing the string literal with < STR >, replace other symbolic constants with < TAG > etc.; (2) LLVM-IR Generate: Instruction-by-instruction conversion generation LLVM-IR . Change the code LLVM-IR Registers in the code are changed to global variables, and registers and temporary variables are renamed in sequence. (3) Redundant code cleaning: In order to effectively eliminate the generation of LLVM-IR The difference between instructions is calculated by designing a code redundancy removal algorithm based on correlation. By minimizing the correlation between instructions, the purpose of removing redundant code is achieved: in is a collection of schemas, For instructions and The joint probability of the architecture, is the prior probability of the architecture. (4) Structural feature analysis: By analyzing the dependencies of the data, LLVM-IR Select a directed acyclic graph. Transformer The semantic model obtains the vector representation of the component to be tested, solving the problem from LLVM-IR The problem of characterization of binary components is solved by comparing and learning the binary component vectors. The features of the binary components are further extracted to improve the accuracy of identifying high-risk binary components in device firmware. Finally, the similarity is calculated based on the feature vectors to determine the final high-risk component version.

Claims

1. A multi-level binary component identification method for industrial Internet of Things firmware, characterized in that: include: S1: Extract functions from the binary component to be detected and the known binary component library, represent all functions as vectors, and calculate the cosine similarity between the binary component to be detected and all function vectors in the known binary component library. When the cosine similarity between two functions exceeds a certain threshold, these functions are called anchor points. S2: Calculate the similarity based on the known binary component library and the functions in the binary component to be detected, obtain the function region, and generate a function region for each anchor point; S3: by calculating the similarity between the function area of ​​the binary component to be detected and the function area in the binary component library, to determine whether it constitutes a code reuse area, if it is a reuse area, it is considered to be a valid binary component; S4: Collect IoT components and information about their components; S5: using component version information in the component information to identify the component; S6: extract binary code features from the binary file of the component; S7: Build a component version coordinate system and filter candidate versions from the coordinate system; S8: Determine the final component version from the candidate versions.

2. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S1 comprises: S11: extracting functions from the binary component to be detected and the known binary component library; S12: Use the Structure2vec network to obtain the vector representation of the function and calculate the cosine similarity between the target binary file and all function vectors in the known binary component library; S13: When the cosine similarity between two functions exceeds a certain threshold, these functions are called anchor points.

3. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 2 is characterized in that: The cosine similarity in step S12 is calculated by the following formula: Assume that the two function vectors are: Then the cosine similarity is 。 4. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S2 comprises: S21: After the anchor points are generated, the anchor points of the binary component to be detected correspond to the anchor points in the known binary component library, which are called anchor pairs. The anchor pairs with too large substructure differences are pre-filtered from the anchor pairs obtained in S1; S22: The anchor point and all calling functions are considered as a region, and the isolated function nodes are connected to the region on the anchor point using the function call graph.

5. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S3 comprises: S31: Determine the structural similarity of the anchor point pairs in each region; Input the function region into the trained graph neural network, convert the region into a vector through the graph neural network, output the vector corresponding to the function region, and then calculate the cosine similarity between the vectors, the result is the structural similarity; S32: determining the maximum alignment length of anchor point pairs in each region; Pick a pair of anchor points as the starting point, and then randomly select the next generation of anchor points as the new starting point, making sure they do not overlap; Record the alignment length of the new list ,if ,but , and reiterate the selection; when the number of iterations reaches the upper limit, the iteration stops and does not update value; S33: If the structural similarity and alignment length of the regions exceed the set thresholds, these regions are identified as reused regions, and the binary components and their related functions within these reused regions are recorded to identify valid binary components.

6. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S4 comprises: S41: Collect IoT components using crawlers, real-world device extraction, and OTA methods; S42: Perform IoT component preprocessing, filter obvious non-firmware files by suffix matching, analyze the remaining collected files, and delete non-component files based on the returned file type, using Binwalk and other component image extraction tools to extract the firmware internal file directory.

7. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S5 comprises: According to the storage format of the version string in the component, there are two methods to extract it: If the version string is an integrated string, first use a regular expression to match the version string, then filter it through the natural language processing model to extract the actual version string; For components whose version strings are non-integrated, restore the control flow graph and call graph of the component; then locate the entry point and candidate version point, and based on the control flow graph and points, delete irrelevant nodes and edges from the control flow graph; finally, use input-driven symbolic execution to determine whether the path from the entry point to the candidate version point is reachable. If the candidate version point is reachable, the corresponding string literal is regarded as the true version.

8. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S6 comprises: In order to capture the code changes between different versions, the component source code is compiled into a binary file. First, the binary code is converted into assembly language code using a disassembly tool. Then the program control flow graph is built, the structural information of the code is extracted, and symbol parsing is performed. Finally, extraction is performed based on the analysis results.

9. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S7 comprises: S71: Establish a component version coordinate system, the coordinate system consists of the reference version and the version coordinates of all versions, and select version o and version n that contain sufficient version difference features as the reference version; S72: Version The version coordinates are obtained by the following formula: in, Represents the name of the extracted function in the binary of component i version. Indicates the new differences between component version o and version n. Represents the deletion difference between component version o and version n; S73: For version , whose version coordinates are ,when This version will be retained if the following conditions are met; in, represents the threshold for similar version positioning, represents the target binary file, X i Indicates the difference between the current component version and version o, Y i Indicates the difference between the current component version and version n, X B Indicates the difference between the target binary component version and version o, Y B Indicates the difference between the target binary component version and version n.

10. The multi-level binary component identification method for industrial Internet of Things firmware according to claim 1 is characterized in that: The step S8 comprises: S81: Generate all anchor paths of the target binary using a function call-based anchor path filter, collect the version difference function anchor paths of each candidate version, and find the same anchor nodes in the target binary file; S82: Select an anchor path in the target binary file that has the same call type sequence as the candidate version; S83: Count the terminal nodes in the selected anchor path in the target binary file and select the function with the highest frequency.

Images