Method and system for recognizing version of binary software

Abstract

The invention discloses a version identification method and system for binary software, and belongs to the technical field of computer program detection. The method comprises the following steps: carrying out reverse analysis on a binary file, and extracting a character string and a constant serving as a function return value; performing layered filtering on the character string and the constant to screen out candidate version semantic features possibly containing version semantic information, and extracting a context environment of the candidate version semantic features in a binary file; performing semantic enhancement on the candidate version semantic features in combination with a context environment of the candidate version semantic features in a binary file; and performing version identification on the binary file according to the character string and the enhanced semantic features of the candidate versions to obtain a version identification result of the binary file. According to the method, the identification problem of the binary software multiplexing open source software version can be effectively solved, and the identification accuracy and the recall rate are improved.

Description

Technical Field

[0001] This invention relates to the field of computer program detection technology, and specifically to a method and system for identifying the version of binary software. Background Technology

[0002] With the continuous development and popularization of open source models, the composition and development process of software have undergone significant changes. Today, to ensure the agility and efficiency of software development, developers often prioritize reusing relevant open source software. However, reusing open source software is a double-edged sword: while it brings great convenience to software development, it can also introduce vulnerabilities into the software. In real-world scenarios, software is generally delivered in binary code form. This delivery method, coupled with the opaque and unpredictable risk environment caused by the complex software supply chain, makes it difficult to determine the existence of vulnerabilities in the binary program even if the open source version is identified as affected by a vulnerability.

[0003] Ideally, when a vulnerability is discovered in open-source software, the reused version should be quickly and correctly identified, and the vulnerability should be determined by version comparison. However, real-world computer software, especially commercially available software and device firmware, typically has the following characteristics: 1. No source code is available, only binary files; 2. Multiple compilation configuration options exist, such as different architectures, compilers, and compilation options, leading to different binary code being generated even with the same source code under different configurations; 3. The software development process is opaque, and there is no list of reused open-source software. Furthermore, to comprehensively detect open-source software reuse, the target is usually a large dataset. Under these conditions, most existing technologies cannot be used directly, necessitating new and efficient solutions for detection.

[0004] Currently, binary software version identification methods can be mainly divided into two categories: string matching-based methods and code similarity calculation-based methods. String matching-based methods typically identify reused versions by searching for version-related strings. For example, Almanee et al., in "Too Quiet in the Library: An Empirical Study of Security Updates in Android Apps' Native Code," summarized the general form of version-related strings and used heuristics to automatically generate regular expressions for searching. Inspired by LibRARIAN, Cheng et al., in "VERI: A Large-scale Open-Source Components Vulnerability Detection in IoTFirmware," used simple regular expressions to find strings with specific patterns and combined them with symbolic execution to determine whether the string represents the true version, thus reducing false positives.

[0005] Recognition methods based on code similarity calculation obtain results by calculating similarity with known versions of source code or binary code. Duan et al.'s "Identifying Open-Source License Violation and 1-day Security Risk at Large Scale" is one of the earlier works in this field. This tool mainly implements version-level detection, using string features and derived function features as code features for similarity calculation. Ban et al.'s "B2SMatcher: fine-Grained version identification of open-source software in binary files" addresses the shortcomings of OSSPolice by introducing function-level features with greater discriminative power between versions. These features include assignment constants in functions, in-degree and out-degree features of function call graphs, and constant features in function parameters, combined with program-level features for two-stage recognition. Furthermore, with the development of machine learning and deep learning technologies, Zeping Yu et al. proposed "CodeCMR: Cross-Modal Retrieval For Function-Level Binary Source CodeMatching," which employs a fully machine learning approach, treating source code and binary code as two modalities of input. It extracts multiple semantic features and uses neural networks to calculate code vectors, performing similarity detection at the function level. The commercial tool "BinaryAI: Binary Software Composition Analysis via Intelligent Binary Source Code Matching" developed by Tencent Security Keen Lab is also based on this research result.

[0006] However, existing version identification methods have certain limitations. First, string matching-based identification methods ignore the diversity of string representations. LibRARIAN uses heuristically generated regular expressions, which cannot encompass all possible version string forms, leading to a large number of false negatives; at the same time, its over-reliance on regular expression matching without sufficient validation may cause false positives. VERI's method also does not fully consider the diversity of string forms, and its symbolic execution-based function reachability analysis method is not applicable to library files without a main function, easily leading to a large number of false negatives. These methods essentially only study string patterns, ignoring the version semantic information of the string and its context. Second, identification methods based on code similarity calculation have limitations in the features they select. OSSPolice only selects string features and exported function features, resulting in low version discrimination and difficulty in accurately determining the version. The function-level features used by B2SMatcher are susceptible to compiler optimizations and symbol table removal. For example, function inlining can lead to changes in the function call graph and assignment sequence, and symbol table removal can erase function symbols, all of which can cause feature matching failures, resulting in high false negative and false positive rates. CodeCMR identifies functions at the granular level, but due to the large number of similar functions in different versions of open-source software, it may lead to a high false positive rate.

[0007] This demonstrates that existing methods cannot accurately detect vulnerabilities introduced by reusing open-source software, thus reducing software security. Therefore, there is an urgent need to develop a new version identification technology to improve the accuracy and recall rate of version identification. Summary of the Invention

[0008] This invention addresses the problems of low accuracy, high false negative rate, and susceptibility to compiler optimization and symbol table removal in existing binary software version identification methods. It provides a binary software version identification method and system that can significantly improve the accuracy and recall of binary software version identification in complex scenarios such as lack of source code, cross-architecture, cross-compilation options, and symbol table removal.

[0009] To achieve the above objectives, the present invention adopts the following technical solution: A method for identifying the version of binary software, the method comprising: Perform reverse analysis on binary files to extract strings and constants that are returned as function values; Hierarchical filtering is performed on strings and constants to filter out candidate version semantic features that may contain version semantic information, and the context of candidate version semantic features in binary files is considered. Semantic enhancement is performed on the semantic features of candidate versions by combining the context of the candidate version semantic features in the binary file; The binary file is version identified based on the string and the enhanced candidate version semantic features to obtain the version identification result of the binary file; wherein, the version identification result includes: version information of the binary file or version information of the binary file not being identified.

[0010] Further, the candidate version semantic features include: a first candidate version semantic feature, a second candidate version semantic feature, a third candidate version semantic feature, and a constant greater than a set threshold; wherein, the first candidate version semantic feature is a string containing several numeric sequences separated by one or more non-numeric characters, the numeric sequences being composed of one or more numeric characters; the second string feature is that the string contains numeric characters separated by delimiters; the third string feature is that the string contains version-related terms, the version-related terms including: version, release, and info; The context in the binary file includes: variable names, parent function names, calling function names, and parameter lists of the calling function; wherein, the variable values ​​in the parameter list are recovered using backward slicing and constant analysis techniques in static program analysis.

[0011] Furthermore, the semantic features of the candidate versions are semantically enhanced by combining the context of the candidate version semantic features in the binary file, including: For a string whose candidate version semantic feature is either the first candidate version semantic feature or the second candidate version semantic feature, the string is concatenated with the variable name, the parent function name, and the calling function name associated with the string to obtain the enhanced candidate version semantic feature; wherein, when the variable name, the parent function name, or the calling function name does not exist, null is used as the value at the corresponding position; For a string whose candidate version semantic feature is the third candidate version semantic feature, the placeholders in the string are replaced according to the order of appearance of the parameters in the parameter list to obtain a text string. The text string is then concatenated with the variable name, the upper-level function name, and the calling function name associated with the string to obtain the enhanced candidate version semantic feature. The placeholders include %s and %d. For a constant whose semantic feature of the candidate version is greater than a set threshold, the constant is used as the enhanced semantic feature of the candidate version.

[0012] Furthermore, based on this string and the enhanced semantic features of the candidate versions, version identification of the binary file is performed, including: Step 4.1: Based on the string and the enhanced candidate version semantic feature corresponding to the first candidate version semantic feature, perform binary file version identification: if version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.2. Step 4.2: Based on the string and the enhanced candidate version semantic feature corresponding to the second candidate version semantic feature, perform binary file version identification: if version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.3. Step 4.3: Based on the enhanced candidate version semantic features corresponding to the constants with candidate version semantic features greater than a set threshold, perform binary file version identification: If version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.4. Step 4.4: Based on the string and the enhanced candidate version semantic feature corresponding to the third candidate version semantic feature, perform binary file version identification: if version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.6. Step 4.5: Output the version information of the binary file; Step 4.6: Output version information for the binary file that was not recognized.

[0013] Further, based on the string and the enhanced candidate version semantic feature corresponding to the first candidate version semantic feature, binary file version identification is performed, including: Step 4.1.1: Detect whether there are any identifier elements in the enhanced candidate version semantic features that match the semantics of the known software name and version semantic elements that are associated with the semantics of version-related word roots: if both exist, determine that the string has version semantic information and jump to step 4.1.2; if not both exist, jump to step 4.1.3. Step 4.1.2: Extract the candidate version number from the string and match the candidate version number with the official version registry string: if the match is successful, proceed to step 4.1.4; if the match is unsuccessful, proceed to step 4.1.3. Step 4.1.3: Output version recognition failed; Step 4.1.4: Output the candidate version number as version information of the binary file.

[0014] Further, binary file version identification is performed based on the enhanced candidate version semantic features corresponding to constants whose candidate version semantic features are greater than a set threshold, including: Step 4.3.1: Obtain the function name of the function that directly calls the constant from the binary file; Step 4.3.2: Perform semantic analysis on the function name to determine whether the function name contains both a completely matching first substring and a completely matching second substring. If both are completely matched, proceed to step 4.3.3; if they are not completely matched or do not match completely, proceed to step 4.3.5. The first substring is the standardized form of a known software entity identifier, and the second substring is a standardized variant of the version semantic keywords. Step 4.3.3: Apply a mapping algorithm to map the constant into several candidate representations. The mapping algorithm includes: keeping the original decimal value, converting it into a hexadecimal string without a prefix, splitting it into two bits and recombining it into a new decimal number, or converting it into a BCD code string. Step 4.3.4: Match each candidate representation with the official version identifier set: If any candidate representation matches the official version identifier set successfully, proceed to step 4.3.6; if none of the candidate representations match the official version identifier set successfully, proceed to step 4.3.5. Step 4.3.5: Output version recognition failed; Step 4.3.6: Output the successfully matched candidate representations as version information of the binary file.

[0015] Furthermore, when the version identification result indicates that no version information for the binary file has been identified, the method further includes: Source code features are extracted from the known versions of the open-source software source code files and the binary files, and the similarity between each source code feature is calculated; wherein, the source code features include: strings, exported functions, global constant arrays, and libc library function call context; The average frequency of change of source code features throughout the open-source software lifecycle is used as the weight of the source code feature; Based on the similarity of each source code feature and the weight of that source code feature, the version similarity between the binary file and each known version of the open source software source code file is calculated to obtain the version information of the binary file.

[0016] Furthermore, the similarity between global constant arrays is calculated, including: Generate a binary data stream from the global constant array; Based on the binary data stream, the longest array matching strategy is used to compare bytes and obtain a global constant array that matches successfully; The similarity between global constant arrays is obtained based on the total number of successfully matched global constant arrays and the total number of global constant arrays in the binary file.

[0017] Furthermore, the similarity between libc library function call contexts is calculated, including: Construct function call trees for the known versions of the open-source software source code files and the binary files, respectively; The number of libc library functions called by each function can be obtained from the function call tree. Based on this number, the functions in the known versions of the open-source software source code files and the binary files are matched to obtain the number of successfully matched functions; The similarity between libc library function call contexts is obtained based on the number of successfully matched functions and the number of functions in the function call tree of the binary file.

[0018] A binary software version identification system, the system comprising: The data extraction module is used to perform reverse analysis on binary files, extracting strings and constants that are returned as function values. The feature filtering module is used to perform hierarchical filtering on strings and constants to filter out candidate version semantic features that may contain version semantic information, and the context of the candidate version semantic features in the binary file. The semantic enhancement module is used to semantically enhance the semantic features of candidate versions by combining the context of the candidate version semantic features in the binary file; The result generation module is used to identify the version of the binary file based on the string and the enhanced candidate version semantic features, and obtain the version identification result of the binary file; wherein, the version identification result includes: version information of the binary file or version information of the binary file not being identified.

[0019] Compared with the prior art, the present invention has the following technical effects.

[0020] 1) Systematically use “version semantics” to introduce feature context semantic information and code structure information, combine “string” and “constant” features, and significantly improve the recognition ability of weak semantic features through semantic enhancement strategies to reduce false positives and false negatives.

[0021] 2) It innovatively introduces two core features: "global constant arrays" and "libc library function call context," and, in conjunction with "string" and "export table" features, constructs a multi-layered, semantically rich signature system. This significantly improves robustness to compiler optimizations and symbol stripping, achieving more accurate and stable recognition capabilities in complex and ever-changing compilation environments.

[0022] 3) A hierarchical semantic recognition architecture with a two-stage recognition process is adopted. In the first stage, based on the likelihood of features containing version semantics (strong -> medium -> weak), a multi-level filtering strategy is used for fast and highly reliable semantic recognition, prioritizing high-value features. If the first stage fails to identify version semantic features, a second stage of highly generalized code similarity calculation is performed. This effectively avoids time-consuming similarity calculations for all files, improving the overall recognition accuracy and efficiency.

[0023] 4) It can effectively solve the problem of binary software version identification in real-world scenarios such as no source code, cross-architecture, multiple compilation options, and removal of symbol tables. Attached Figure Description

[0024] Figure 1 This is a flowchart of the version identification phase based on version semantic features.

[0025] Figure 2 This is a flowchart of the version identification phase based on code similarity calculation. Detailed Implementation

[0026] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0027] The overall idea of ​​this invention is to take the binary file to be identified as input, first identify the version information of the binary file based on version semantic features, and if the identification fails, then adopt steps such as version identification based on code similarity calculation, and finally output the accurate version information of the reused open source software.

[0028] This invention includes, for example Figure 1 The version identification based on version semantic features (steps 1 to 4) stages shown and as follows Figure 2 The version identification stage (steps 5 to 7) based on code similarity calculation is shown.

[0029] Phase 1: Version identification based on version semantic features.

[0030] Step 1: Perform reverse analysis on the binary file to extract strings and constants that are returned as function values.

[0031] This invention uses a disassembler (such as IDA Pro) to reverse engineer the target binary file and extract all strings as constants that are function return values.

[0032] Step 2: Perform hierarchical filtering on strings and constants to filter out candidate version semantic features that may contain version semantic information, and the context of the candidate version semantic features in the binary file.

[0033] The extracted string and constant features are subjected to hierarchical filtering to select candidate version semantic features that may contain version semantic information. These candidate version semantic features include: first candidate version semantic features, second candidate version semantic features, third candidate version semantic features, and constants greater than a set threshold.

[0034] The semantic features of the first candidate version are: the string contains several sequences of numbers and the sequences of numbers are separated by one or more non-numeric characters. The sequences of numbers are composed of one or more numeric characters, such as the numeric string patterns "xxx", "x_x_x" and "xxxx".

[0035] The semantic features of the second candidate version are: the string contains numeric characters and the numeric characters are separated by delimiters.

[0036] The third candidate version semantic features: a formatted string containing version-related terms such as "version", "release", and "info".

[0037] Constants greater than the set threshold: Only filter constants with values ​​greater than 10000.

[0038] Finally, this invention extracts the semantic features of candidate versions from the context of the binary file, including variable names, parent function names, calling function names, and the parameter list of the calling function. For the variable values ​​in the parameter list, backward slicing and constant analysis techniques from static program analysis are used for recovery.

[0039] Step 3: Enhance the semantic features of the candidate versions by combining the context of the binary file.

[0040] For candidate strings that match the semantic features of the first or second candidate version, concatenate the candidate string with the associated variable name, parent function name, and calling function name to form a single combined semantic string. The concatenation operation uses the fixed delimiter "&&", and the connection order is: candidate string, variable name, parent function name, calling function name. If any contextual information is missing, "Null" is used as the value at that position.

[0041] For candidate strings that match the semantic features of the third candidate version, perform formatted string recovery to obtain the parameter list of the candidate string in the calling function. Match the placeholders "%s" or "%d" in the candidate string in the order of their appearance in the parameter list. For each placeholder, replace it with the parameter value at the corresponding position in the parameter list. After the replacement, obtain a complete text string without placeholders. Then, concatenate this complete text string with the variable name, parent function name, and calling function name associated with the candidate string to form a single semantic string. The concatenation operation uses the fixed delimiter "&&", and the concatenation order is: complete text string, variable name, parent function name, calling function name. If any context information is missing, "Null" is used as the value at that position.

[0042] If the candidate version semantic feature that may contain version semantic information is a constant greater than a set threshold, the constant is directly used as the enhanced candidate version semantic feature.

[0043] In one embodiment, the present invention performs semantic enhancement processing on the candidate version semantic features (such as "libopenssl-version-3.0.2") to construct enhanced candidate version semantic features (such as "openssl version3.0.2"). Step 4: Based on the string and the enhanced candidate version semantic features, perform version identification on the binary file to obtain the version identification result of the binary file; wherein, the version identification result includes: version information of the binary file or version information of the binary file not being identified.

[0044] This invention categorizes version semantic features into three types based on their semantic strength: strong version semantic features (first candidate version semantic features), medium version semantic features (second candidate version semantic features), and weak version semantic features (constants exceeding a set threshold and third candidate version semantic features). Strong version semantic features consist only of string features and can determine the version based on their semantics alone. Medium version semantic features include both string and constant features, requiring the integration of other static information for accurate judgment. Weak version semantic features also include both string and constant features, requiring an understanding of the functionality of higher-level functions for accurate judgment. The priority of judgment decreases as follows: first candidate version semantic features, second candidate version semantic features, constants exceeding the set threshold, and third candidate version semantic features.

[0045] For enhanced candidate version semantic features that possess the semantic features of the first, second, or third candidate versions, this invention simultaneously detects whether there are identifier elements that semantically match known software names (e.g., "openssl", matched by removing the prefix "lib" from "libopenssl" and normalizing to lowercase), and version semantic elements that semantically relate to version-related word roots (e.g., "version", matched by a preset vocabulary {"version", "ver", "release", "rel", "info", "build"} after case normalization). Version semantics are only determined to exist when both coexist. Subsequently, candidate version numbers (e.g., "3.0.2") are extracted from the original string and precisely matched against the official version registry. Only when they are completely identical are they confirmed as valid identification results. If the extracted version, such as "3.0.2-beta", does not exist precisely in the official version list, it is not confirmed even if the semantic structure matches.

[0046] For version number identification based on constants, this invention first identifies candidate constants in the target program and obtains the function names of the functions that directly call them. Secondly, it performs semantic analysis on the function names to determine whether they simultaneously contain two completely matching substrings: one is the form of a known software entity identifier (such as "OpenSSL") after standardization (removing the preset prefix "lib", "Lib" or the suffix "-", "." and converting it to lowercase); the other is the version semantic keywords (such as "version", "ver", "release", "rel", "info", "build") after adding spaces, hyphens, and underscores. Standardized variants (such as "version" and "release-info") are formed by separating the constants with lines or dots and converting them to lowercase. If both exist, the candidate constant is considered to have version semantic association, and at least one reversible and semantically consistent mapping algorithm is applied to its value to generate candidate representations. The algorithm includes: keeping the original decimal value, converting it to a prefix-free uppercase hexadecimal string, splitting it into two bits and recombining it into a new decimal number, or converting it to a BCD code string. Then, each candidate form is precisely compared with a preset set of official version identifiers. When any candidate is completely consistent with the official entry, the official version identifier is output as the final identification result.

[0047] Phase Two: Version identification based on code similarity calculation.

[0048] Step 5: When the version identification result is that the version information of the binary file is not identified, extract code features from the known version of the open source software source code file and the binary file respectively, and calculate the similarity between each code feature.

[0049] This invention selects four source code features that are resistant to compiler optimization, resistant to symbol table removal, and have version differentiation: strings, exported functions, global constant arrays, and the call context of libc library functions.

[0050] a) Source code feature extraction.

[0051] This invention uses the IDA Pro tool to extract strings, exported functions, and libc library function call relationships from a C Tree generated by parsing binary code files. For global constant arrays, instead of extracting them directly from the binary data, they are converted into a binary data stream for retrieval within the binary file.

[0052] In another embodiment, if the known version of the open-source software source code file is a C / C++ program file, then a syntax analysis tool (such as Tree-sitter) is used to generate an Abstract Syntax Tree (AST) for the C / C++ program file. Cross-file code analysis techniques are then used to precisely extract features such as strings, exported functions, global constant arrays, and libc library function call contexts, and a function call tree list and a global symbol table are constructed. To reduce interference, C / C++ program files in folders named "test", "fuzz", and "example" are pre-filtered.

[0053] b) Code similarity calculation based on feature matching.

[0054] For string features and derived function features, this invention adopts a full matching strategy, which compares the feature set extracted from the binary file with the feature set extracted from the source code one-to-one.

[0055] For global constant arrays, this invention transforms the constant arrays extracted from the source code into four possible binary data streams: 2 bytes, 4 bytes, 8 bytes, and 16 bytes, and then searches for them within the data segment of the binary file. To address the issue of inconsistent lengths caused by adding or deleting array elements, a "longest array matching" strategy is adopted, prioritizing the matching of the longest array instance.

[0056] For the contextual features of libc library function call relationships, this invention uses the number of calls to represent the call relationships. Specifically, this feature is expressed as the number of times a function calls libc library functions, in the form of... This paper finds that this feature has a certain degree of version differentiation. Taking the open-source software OpenSSL as an example, in... Version The function uses the libc library function memset, therefore the number of times the libc library function memset is used in this function is 1, denoted as . However, in the subsequent In version, Function repurposed The function replaces the memset function, and in this case, the number of libc library functions used by the function is 0, denoted as . This example demonstrates that the libc library function call context features vary between versions, and these differences are also reflected in the binary files, thus making it a feature that meets the requirements of this paper.

[0057] Similarity calculation: The similarity of a single feature is calculated using the formula... Calculation, where The number of features that were successfully matched. This represents the total number of features extracted from the binary file.

[0058] Step 6: Use the average frequency of change of source code features during the open-source software lifecycle as the weight of the source code feature.

[0059] To address the differences in version differentiation of different features across different open-source software, the average frequency of feature changes throughout the open-source software lifecycle is used as the weight. The weight of feature F is: in, N( represents the total number of features in version i) ∩ Let be the number of common features of versions i and i+1, and n be the number of versions.

[0060] Step 7: Based on the similarity of each source code feature and the weight of that source code feature, calculate the version similarity between the binary file and each known version of the open source software source code file to obtain the version information of the binary file.

[0061] Version similarity between a binary file and a known version of open-source software source code file for: Finally, the version with the highest version similarity was selected as the recognition result.

[0062] To better illustrate the technical effects of this invention, researchers compared it with existing representative tools such as BinaryAI, Cybellum, OSSPolice, B2SMatcher, and LibDB. The results are shown in Table 1. On the comparative experimental dataset, this invention achieved a recognition accuracy and recall rate of 86.76%. Compared to B2SMatcher, which has the highest recognition accuracy, this system has a 1.24% higher accuracy; compared to BinaryAI, which has the highest recall rate, this system has a 23.11% higher recall rate. Compared to BinaryAI, the best-performing tool, the F1 score is improved by 15.57%. Table 1. Performance Comparison Experiment Results of the Invention and Existing Technologies Furthermore, through experiments on large-scale datasets, as shown in Table 2, the overall recognition accuracy and recall rate of the present invention both reached 88.91%, 89.10% for ELF files and 87.44% for PE files, indicating that the present invention also exhibits good performance in cross-platform binary program detection. Table 2. Version identification results of this invention under large-scale datasets. The above embodiments are provided merely for the purpose of describing the present invention and are not intended to limit the scope of the invention. The scope of the invention is defined by the appended claims. Various equivalent substitutions and modifications made without departing from the spirit and principles of the invention should be covered within the scope of the invention.

Claims

1. A method for identifying the version of binary software, characterized in that, The method includes: Perform reverse analysis on the binary file to extract strings and constants that are returned as function values; Layered filtering is performed on strings and constants to filter out candidate version semantic features that may contain version semantic information, and the context of the candidate version semantic features in the binary file is extracted. Semantic enhancement is performed on the semantic features of candidate versions by combining the context of the candidate version semantic features in the binary file; The binary file is version identified based on the string and the enhanced candidate version semantic features to obtain the version identification result of the binary file; wherein, the version identification result includes: version information of the binary file or version information of the binary file not being identified.

2. The method according to claim 1, characterized in that, The candidate version semantic features include: a first candidate version semantic feature, a second candidate version semantic feature, a third candidate version semantic feature, or a constant greater than a set threshold; wherein, the first candidate version semantic feature is a string containing several numeric sequences separated by one or more non-numeric characters, the numeric sequences being composed of one or more numeric characters; the second string feature is that the string contains numeric characters separated by delimiters; the third string feature is that the string contains version-related terms, the version-related terms including: version, release, and info; The semantic features of the candidate version in the context of the binary file include: variable name, upper-level function name, calling function name, and parameter list of the calling function; wherein, the variable values ​​in the parameter list are recovered using backward slicing and constant analysis techniques in static program analysis.

3. The method according to claim 2, characterized in that, Semantic enhancement of candidate version semantic features is performed by combining the candidate version semantic features with the context of the binary file, including: For a string whose candidate version semantic feature is either the first candidate version semantic feature or the second candidate version semantic feature, the string is concatenated with the variable name, the parent function name, and the calling function name associated with the string to obtain the enhanced candidate version semantic feature; wherein, when the variable name, the parent function name, or the calling function name does not exist, null is used as the value at the corresponding position; For a string whose candidate version semantic feature is the third candidate version semantic feature, the placeholders in the string are replaced according to the order of appearance of the parameters in the parameter list to obtain a text string. The text string is then concatenated with the variable name, the upper-level function name, and the calling function name associated with the string to obtain the enhanced candidate version semantic feature. The placeholders include %s and %d. For a constant whose semantic feature of the candidate version is greater than a set threshold, the constant is used as the enhanced semantic feature of the candidate version.

4. The method according to claim 2, characterized in that, Version identification of the binary file is performed based on the string and the enhanced candidate version semantic features, including: Step 4.1: Based on the string and the enhanced candidate version semantic feature corresponding to the first candidate version semantic feature, perform binary file version identification: if version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.

2. Step 4.2: Based on the string and the enhanced candidate version semantic feature corresponding to the second candidate version semantic feature, perform binary file version identification: if version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.

3. Step 4.3: Based on the enhanced candidate version semantic features corresponding to the constants with candidate version semantic features greater than a set threshold, perform binary file version identification: If version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.

4. Step 4.4: Based on the string and the enhanced candidate version semantic feature corresponding to the third candidate version semantic feature, perform binary file version identification: if version identification is successful, proceed to step 4.5; if version identification fails, proceed to step 4.

6. Step 4.5: Output the version information of the binary file; Step 4.6: Output version information for the binary file that was not recognized.

5. The method according to claim 4, characterized in that, Binary file version identification is performed based on the string and the enhanced candidate version semantic features corresponding to the first candidate version semantic features, including: Step 4.1.1: Detect whether there are any identifier elements in the enhanced candidate version semantic features that match the semantics of the known software name and version semantic elements that are associated with the semantics of version-related word roots: if both exist, determine that the string has version semantic information and jump to step 4.1.2; if not both exist, jump to step 4.1.

3. Step 4.1.2: Extract the candidate version number from the string and match the candidate version number with the official version registry string: if the match is successful, proceed to step 4.1.4; if the match is unsuccessful, proceed to step 4.1.

3. Step 4.1.3: Output version recognition failed; Step 4.1.4: Output the candidate version number as version information of the binary file.

6. The method according to claim 4, characterized in that, Binary file version identification is performed based on the enhanced candidate version semantic features corresponding to constants whose candidate version semantic features are greater than a set threshold, including: Step 4.3.1: Obtain the function name of the function that directly calls the constant from the binary file; Step 4.3.2: Perform semantic analysis on the function name to determine whether the function name contains both a completely matching first substring and a completely matching second substring. If both are completely matched, proceed to step 4.3.3; if they are not completely matched or do not match completely, proceed to step 4.3.

5. The first substring is the standardized form of a known software entity identifier, and the second substring is a standardized variant of the version semantic keywords. Step 4.3.3: Apply a mapping algorithm to map the constant into several candidate representations. The mapping algorithm includes: keeping the original decimal value, converting it into a hexadecimal string without a prefix, splitting it into two bits and recombining it into a new decimal number, or converting it into a BCD code string. Step 4.3.4: Match each candidate representation with the official version identifier set: If any candidate representation matches the official version identifier set successfully, proceed to step 4.3.6; if none of the candidate representations match the official version identifier set successfully, proceed to step 4.3.

5. Step 4.3.5: Output version recognition failed; Step 4.3.6: Output the successfully matched candidate representations as version information of the binary file.

7. The method according to any one of claims 1 to 6, characterized in that, When the version identification result is that no version information of the binary file is identified, the method further includes: Source code features are extracted from the known versions of the open-source software source code files and the binary files, and the similarity between each source code feature is calculated; wherein, the source code features include: strings, exported functions, global constant arrays, and libc library function call context; The average frequency of change of source code features throughout the open-source software lifecycle is used as the weight of the source code feature; Based on the similarity of each source code feature and the weight of that source code feature, the version similarity between the binary file and each known version of the open source software source code file is calculated to obtain the version information of the binary file.

8. The method according to claim 7, characterized in that, Calculate the similarity between global constant arrays, including: Generate a binary data stream from the global constant array; Based on the binary data stream, the longest array matching strategy is used to compare bytes and obtain a global constant array that matches successfully; The similarity between global constant arrays is obtained based on the total number of successfully matched global constant arrays and the total number of global constant arrays in the binary file.

9. The method according to claim 7, characterized in that, Calculate the similarity between libc library function call contexts, including: Construct function call trees for the known versions of the open-source software source code files and the binary files, respectively; The number of libc library functions called by each function can be obtained from the function call tree. Based on this number, the functions in the known versions of the open-source software source code files and the binary files are matched to obtain the number of successfully matched functions; The similarity between libc library function call contexts is obtained based on the number of successfully matched functions and the number of functions in the function call tree of the binary file.

10. A binary software version identification system, characterized in that, The system includes: The data extraction module is used to perform reverse analysis on binary files, extracting strings and constants that are returned as function values. The feature filtering module is used to perform hierarchical filtering on strings and constants to filter out candidate version semantic features that may contain version semantic information, and the context of the candidate version semantic features in the binary file. The semantic enhancement module is used to semantically enhance the semantic features of candidate versions by combining the context of the candidate version semantic features in the binary file; The result generation module is used to identify the version of the binary file based on the string and the enhanced candidate version semantic features, and obtain the version identification result of the binary file; wherein, the version identification result includes: version information of the binary file or version information of the binary file not being identified.

Images