Network security malware binary search method and system

Abstract

The application provides a network security malicious code binary search method and system, and relates to the technical field of data processing.The method comprises the following steps: based on a function level control flow semantic feature vector, the multi-dimensional structural similarity between a to-be-detected binary file and each standard binary reference file is calculated; according to the multi-dimensional structural similarity, the final matched standard binary reference file is determined; the to-be-detected binary file and the final matched standard binary reference file are subjected to fine-grained difference analysis, and a fine-grained difference analysis result is obtained; based on the fine-grained difference analysis result, combined with sensitive data operation behavior feature detection, it is judged whether the to-be-detected binary file is a malicious tampered version, and a malicious code injection point is located.The application overcomes the defects that the prior art is too dependent on fixed features and sensitive to compilation optimization.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a network security malicious code binary search method and system. BACKGROUND

[0002] In the field of online services such as Internet e-commerce, open source components such as Nginx and OpenSSL are widely used in core business systems, and their stability and security are directly related to the confidentiality of user sensitive data. The binary versions of these components may be tampered with in the supply chain, for example, versions with the same name as the official files but with modified functions may be produced; such tampered files have a high degree of camouflage: the version identification string is often removed to evade feature-based matching; the compilation optimization changes the instruction order and register allocation, causing the binary code sequence to differ from the official version; and only a small amount of additional code is injected in the key functions, with most of the function structure remaining unchanged, making it extremely difficult to detect.

[0003] Currently, the detection and tracing of such tampered code mainly rely on binary search and comparison techniques. Some existing methods have limitations: first, many methods rely on fixed static features for matching, such as version strings, exported function name hashes, or file sizes; once these explicit features are removed or modified, such methods become ineffective and cannot associate suspicious files with the correct official versions. Second, compilation optimization can significantly change the instruction arrangement, redundant instructions, and jump logic within basic blocks, resulting in a sharp decline in instruction sequence similarity. Traditional control flow graph matching is very sensitive to minor changes in nodes and edges, and is easily misjudged by the differences introduced by optimization, treating the same legitimate versions as different files.

[0004] Based on the above shortcomings, there is an urgent need for a binary search analysis method that can penetrate the interference of compilation optimization and effectively associate tampered files with legitimate source versions. SUMMARY

[0005] The present application provides a network security malicious code binary search method and system, which overcomes the defects of excessive dependence on fixed features and sensitivity to compilation optimization in the prior art.

[0006] To solve the above technical problems, the technical solutions of the present application are as follows:

[0007] In a first aspect, a network security malicious code binary search method is provided, which includes:

[0008] Obtaining file attribute information of a binary file to be detected;

[0009] Retrieving a matching candidate legitimate version from an open source component version library based on the file attribute information, and generating a corresponding standard binary reference file set;

[0010] The disassembly and basic block division are performed on the to-be-detected binary file and the files in the standard binary reference file set respectively, and a function-level control flow graph is extracted, wherein each node represents a basic block, and an edge represents a control flow transition between basic blocks; a loop control structure composed of basic blocks in the control flow graph is abstracted into a polygon, and a distribution of an outer angle sequence of the polygon is calculated and counted to quantify a turning mode and complexity of a control flow path, and a topological feature vector is formed; the topological feature vector and a node attribute feature of the control flow graph are fused to construct a function-level control flow semantic feature vector;

[0011] Based on the function-level control flow semantic feature vector, multi-dimensional structural similarities between the to-be-detected binary file and each standard binary reference file are calculated; and a final matched standard binary reference file is determined according to the multi-dimensional structural similarities.

[0012] Fine-grained difference analysis is performed on the to-be-detected binary file and the final matched standard binary reference file to obtain a fine-grained difference analysis result; based on the fine-grained difference analysis result, sensitive data operation behavior feature detection is combined to determine whether the to-be-detected binary file is a malicious tampered version, and a malicious code injection point is located.

[0013] In a second aspect, a network security malicious code binary search system includes:

[0014] The acquisition module is configured to acquire file attribute information of a to-be-detected binary file, retrieve matched candidate legal versions from an open source component version library based on the file attribute information, and generate a corresponding standard binary reference file set.

[0015] The construction module is configured to perform disassembly and basic block division on the to-be-detected binary file and the files in the standard binary reference file set respectively, extract a function-level control flow graph, wherein each node represents a basic block, and an edge represents a control flow transition between basic blocks; abstract a loop control structure composed of basic blocks in the control flow graph into a polygon, calculate and count a distribution of an outer angle sequence of the polygon to quantify a turning mode and complexity of a control flow path, and form a topological feature vector; fuse the topological feature vector and a node attribute feature of the control flow graph to construct a function-level control flow semantic feature vector.

[0016] The determination module is configured to calculate multi-dimensional structural similarities between the to-be-detected binary file and each standard binary reference file based on the function-level control flow semantic feature vector; and determine a final matched standard binary reference file according to the multi-dimensional structural similarities.

[0017] A judgment module is configured to perform fine-grained difference analysis on the to-be-detected binary file and the final matched standard binary reference file to obtain a fine-grained difference analysis result; based on the fine-grained difference analysis result, in combination with sensitive data operation behavior feature detection, it is judged whether the to-be-detected binary file is a malicious tampered version, and a malicious code injection point is located.

[0018] The above scheme of the present application at least includes the following beneficial effects:

[0019] By abstracting the loop control structure in the control flow graph into a polygon and calculating the distribution of the outer angle sequence, a semantic vector capable of describing the essential characteristics of the program control flow topology is constructed, which effectively removes the surface differences such as instruction arrangement, redundant code and local jump logic changes caused by compiler optimization, so that more stable and accurate similarity comparison can be performed at the code semantic level, and the probability of misjudging the same legal version as different files due to different optimization options is reduced.

[0020] The present application does not rely on vulnerable static features such as version string and file size which are easy to be tampered with, but performs multi-dimensional structural similarity calculation based on function-level control flow semantic features, which makes it possible to accurately associate suspicious tampered files to the corresponding legal source version in the open source component version library through deep code structure similarity even if the version identifier is intentionally removed, solving the problem of association failure caused by feature failure in traditional methods.

[0021] On the basis of accurate version matching, through fine-grained difference analysis and in combination with context detection of sensitive data operation behavior, abnormal code segments introduced by malicious injection and different from normal compilation differences can be effectively identified, this method not only can judge whether the file is tampered as a whole, but also can accurately locate the specific injection point of malicious code, providing a clear target for subsequent analysis and disposal, effectively avoiding the risk of missed detection due to small proportion of local malicious code. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 is a flowchart of the network security malicious code binary search method provided by the embodiment of the present application;

[0023] Figure 2 is a schematic diagram of the network security malicious code binary search system provided by the embodiment of the present application. DETAILED DESCRIPTION

[0024] Exemplary embodiments of the present disclosure will be described in greater detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in many forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art.

[0025] As Figure 1 shown, the embodiments of the present application propose a network security malicious code binary search method, the method comprising the following steps:

[0026] Step 1, obtaining the file attribute information of the binary file to be detected;

[0027] Step 2, retrieving the matched candidate legal version from the open source component version library based on the file attribute information, and generating the corresponding standard binary reference file set;

[0028] Step 3, disassembling and basic block partitioning the binary file to be detected and the files in the standard binary reference file set respectively, extracting the function level control flow graph, wherein each node represents a basic block and the edge represents the control flow transition between basic blocks; abstracting the loop control structure composed of basic blocks in the control flow graph into a polygon, calculating and counting the outer angle sequence distribution of the polygon to quantify the turning mode and complexity of the control flow path, forming a topological feature vector; fusing the topological feature vector with the node attribute features of the control flow graph to construct a function level control flow semantic feature vector;

[0029] Step 4, calculating the multi-dimensional structural similarity between the binary file to be detected and each standard binary reference file based on the function level control flow semantic feature vector; determining the final matched standard binary reference file according to the multi-dimensional structural similarity;

[0030] Step 5, performing fine-grained difference analysis on the binary file to be detected and the final matched standard binary reference file to obtain fine-grained difference analysis results; based on the fine-grained difference analysis results, combining sensitive data operation behavior feature detection to determine whether the binary file to be detected is a malicious tampered version and locate the malicious code injection point; the file attribute information includes file size, export symbol table information and core function signature, and the multi-dimensional structural similarity includes basic block layout similarity, function call relationship similarity and data flow dependence similarity.

[0031] In this embodiment, the method first screens the matching candidate legal version from the open source component version library based on file size, exported symbol table information, and core function function signature file attribute information, and generates a standard binary reference file set. This design avoids the blind comparison with irrelevant versions or irrelevant files in the traditional method, greatly reduces the object range of the subsequent feature extraction, similarity calculation, and other core steps, effectively reduces the overall calculation amount, shortens the detection response period, and can quickly adapt to the efficiency requirements of large-scale binary file detection scenarios. In the feature extraction link, the loop control structure in the control flow graph is abstracted as a polygon, the turning mode and complexity of the control flow path are captured by quantizing the outer angle sequence distribution, and the function-level control flow semantic feature vector is constructed by fusing the node attribute features of the control flow graph. This feature representation method can not only deeply mine the core structure logic and semantic information of the binary file, but also effectively shield the surface difference interference caused by non-malicious modifications such as code compilation optimization and format fine-tuning, making the feature have stronger stability and discrimination, providing a high-precision feature basis for subsequent similarity matching, and improving the accuracy of malicious tampering detection from the source.

[0032] Through the multi-dimensional evaluation model of basic block layout similarity, function call relationship similarity, and data flow dependence similarity, the structural consistency of the binary file to be detected and the standard reference file is fully described. Compared with single-dimensional similarity calculation, this method can verify the structural consistency of the file from different aspects, ensure that the standard reference file matched is the legal version with the strongest relevance to the binary file to be detected, avoid distortion of subsequent difference analysis caused by matching deviation, and provide a reliable comparison benchmark for the identification of malicious tampering behavior. The verification logic combining fine-grained difference analysis and sensitive data operation behavior feature detection can not only accurately judge whether the binary file to be detected has non-legal tampering, but also accurately locate the injection position of malicious code. This design breaks through the limitation of traditional detection methods that can only determine whether it is malicious, provides a clear technical basis for subsequent security disposal, code tracing, and risk control, effectively reduces the false negative rate and the false positive rate, and improves the landing practicality of the detection result.

[0033] This method is optimized for the malicious tampering detection scene of open source component related binary files, and can compatible with the binary file detection needs of different versions and different types of open source components. Its detection logic does not depend on the pre-constructed malicious code feature library and real-time update, but realizes malicious behavior identification through comparison with legal standard versions, and has good detection ability for unknown forms of malicious tampering behavior. At the same time, the feature extraction and similarity calculation logic of this method can be flexibly adjusted according to the needs of different scenes, has strong expansibility, and can adapt to the security detection needs of more types of binary files, providing flexible and efficient technical support for the legality verification of binary files.

[0034] In a preferred embodiment of the present application, the above step 1 of obtaining the file attribute information of the binary file to be detected can include:

[0035] The file to be detected is completely loaded into the memory buffer through the system file read-write interface, while recording the storage path, access permission, last modification time and other auxiliary metadata of the file; the binary format type of the file (such as ELF format of Linux system, PE format of Windows system, Mach-O format of macOS system, etc.) is identified, and it is judged whether the file is a standard executable file or dynamic library file by analyzing the characteristic fields of the file header, so as to exclude invalid types such as text files, empty files and damaged files; it is checked whether the file exists in abnormal conditions such as truncation and redundant data splicing by verifying whether the actual byte length of the file is consistent with the size recorded by the file system, so as to ensure the completeness of the loaded file data.

[0036] The original byte size (unit: byte) of the file to be detected is obtained based on the byte length statistics of the memory buffer or directly calling the file system metadata interface; the block alignment difference of different file systems (such as some file systems will align the file size to the sector size upwards) is shielded, and the byte length of the actual effective data of the file is taken as the final file size attribute value; the standardized file size is stored in the temporary attribute set as one of the basic screening conditions for subsequent search for candidate versions.

[0037] According to the binary file format specification, the file header and section table structure are parsed to locate the memory offset address and data length of the exported symbol table; the symbol table raw data is read, combined with the corresponding string table, and the name, virtual address, binding type (global / local), symbol type (function / data) and other information of each symbol are parsed; the exported symbols of global binding and function type (excluding local symbols, debugging symbols, data symbols and other non-core types) are screened out to avoid redundant invalid symbols added by tamperers;

[0038] The exported symbols parsed are de-duplicated (to exclude duplicate symbol entries), and the legality of the symbol name is verified (such as filtering abnormal symbols containing special invalid characters), and finally a structured exported symbol table information list (containing symbol name, corresponding function entry address, symbol visibility and other fields) is generated and stored in the temporary attribute set. Combined with the preliminary identification of the file to be detected, the type of the open source component to which it may belong is determined; the standard name of the core function is obtained by calling the official document or source code analysis result of the component; the specific memory address of the core function in the binary file is located by matching the core function name with the extracted exported symbol table; if the core function name is removed from the exported symbol table, the function entry instruction characteristics (such as the stack frame initialization instruction sequence at the beginning of the function) and the adjacent function call relationship are used for fuzzy matching and positioning.

[0039] The located core function function is preliminarily disassembled, and signature is constructed by extracting feature information, including function entry address, stack frame initialization mode, key instruction segment (such as characteristic instructions of core business logic, excluding redundant instructions caused by compilation optimization), parameter passing mode (such as register passing / stack passing characteristics), return value type related instruction characteristics, etc. Non-core differences caused by compilation optimization (such as instruction sequence adjustment, register allocation difference) are shielded, the core logic characteristics (such as key jump instruction position, core calculation instruction segment) of the function are retained, a standardized core function function signature set is generated, and is stored in a temporary attribute set.

[0040] The file size, export symbol table information list, core function function signature set, and recorded auxiliary metadata are integrated to form a complete binary file attribute information data set, which is organized in a structured format (such as key-value pair, list) for subsequent step retrieval and calling; the logical consistency between the attribute information is verified, for example, the entry address corresponding to the core function function signature needs to be within the effective memory address range of the file, and the function address in the export symbol table needs to match the address of the core function function positioning; the abnormal attributes with logical conflicts are removed to ensure the reliability of the data set; the attribute information data set that passes the verification is taken as the final output result of step 1, and is transmitted to step 2 for candidate legal version retrieval of the open source component version library.

[0041] Through the above implementation process, step 1 can obtain file attribute information with completeness, reliability and standardization, which not only avoids the interference of invalid files, but also retains the core matching characteristics for the disguise characteristics (such as removing version identification, compilation optimization) of tampered files.

[0042] In a preferred embodiment of the present application, step 2, based on the file attribute information, retrieves the matched candidate legal version from the open source component version library, and generates a corresponding standard binary reference file set, including:

[0043] Step 2.1, the file size of the binary file to be detected is taken as the primary filtering condition, and all historical version source codes with file sizes within a preset tolerance range in the open source component version library are screened out to form a preliminary candidate set, which specifically includes: starting the open source component version library retrieval pre-process, initializing the retrieval environment to ensure smooth communication link with the open source component version library; the open source component version library is pre-constructed with a hierarchical index structure, which takes component category-version number as the core level, wherein the component category is divided according to the function attribute of the open source component (such as Web server class, encryption tool class, data processing class, etc.), and the version number is arranged according to the version sequence officially released by each component. Each level node is associated with a corresponding data storage path pointer to realize fast positioning; at the same time, each historical version source code package stored in the version library is bound with a preset structured metadata, which at least includes: the standard size range of the binary file generated after the corresponding version source code is compiled by the official default compilation process (covering the mainstream compilation optimization levels, i.e. O0, O1, O2, O3 optimization levels), the adapted operating system architecture (such as ARM64, PowerPC, etc.), the version release timestamp, the official compilation tool chain version information, the core function module list, etc. fields; by calling the preset metadata retrieval interface of the open source component version library, a retrieval ready signal is sent to the version library, and the retrieval parameter format specification returned by the interface is obtained to complete the retrieval pre-process.

[0044] The attribute information data set of the binary file to be detected output in step 1 is called, and two core retrieval parameters are extracted from the data set: one is the standardized size of the binary file to be detected, which is the actual effective data byte length of the file that has been verified in step 1 (the block alignment difference of different file systems is shielded); the other is the open source component category to which the detected file belongs, which is preliminarily determined by the core function function signature matching in step 1 (such as matching the core function signature to the feature of Nginx component, then the component category is determined as Web server class); the two core parameters are standardized, wherein the standardized size is converted to an integer value (unit: byte), and the component category is converted to the corresponding standard category identification string in the version library index structure; at the same time, the validity of the two parameters is checked, if the standardized size is not a positive number or the component category is undefined, the attribute information re-extraction process of step 1 is triggered, if the parameters are valid, the next operation link is entered.

[0045] A preset tolerance rule base is acquired, the tolerance rule base being a structured rule set constructed in advance based on volume features and compilation fluctuation data of a large number of open source component binary files, the rule base containing tolerance range standards corresponding to open source components of different volume levels, and the tolerance range being dynamically adapted according to the component volume; the extracted standardized size of the binary file to be detected is compared with the volume threshold in the tolerance rule base to determine the corresponding tolerance range: if the standardized size of the file to be detected is greater than 10 MB (10485760 bytes), the first preset tolerance standard in the tolerance rule base is matched to determine that the preset tolerance range is ±5%; if the standardized size of the file to be detected is between 1 MB (1048576 bytes) and 10 MB, the second preset tolerance standard in the tolerance rule base is matched to determine that the preset tolerance range is ±4%; if the standardized size of the file to be detected is less than 1 MB, the third preset tolerance standard in the tolerance rule base is matched to determine that the preset tolerance range is ±3%; based on the determined tolerance range and the standardized size of the file to be detected, the actual size search interval (i.e. the interval between the standardized size minus the number of bytes corresponding to the tolerance and the standardized size plus the number of bytes corresponding to the tolerance) of the file to be detected is calculated, and the search interval is converted into a numerical interval format recognizable by the metadata search interface.

[0046] The standardized component category identifier and the calculated actual size search interval are taken as core search parameters, the search request is packaged in the format required by the metadata search interface, and is sent to the metadata search interface of the open source component version library; after the version library receives the search request, all historical version source package metadata sets of the corresponding component category are quickly located based on the component category hierarchical index, and each historical version source package metadata in the set is traversed to extract the binary file standard size range field (the field covers the size fluctuation interval under the mainstream compilation optimization level, for example, the binary file size of a certain version source code after compilation is 5 MB under the O0 optimization level and 4.8 MB under the O3 optimization level, and the standard size range is recorded as 4.8 MB-5 MB) generated by the official default compilation in each metadata; the intersection of the standard size range of each historical version and the actual size search interval of the file to be detected is determined, if there is an overlapping part between the two intervals (i.e. the minimum value of the standard size range of the historical version is less than or equal to the maximum value of the actual size search interval of the file to be detected, and the maximum value of the standard size range of the historical version is greater than or equal to the minimum value of the actual size search interval of the file to be detected), it is determined that the historical version source package meets the preliminary screening condition, and its metadata information is retained; if there is no intersection between the two intervals, the metadata of the historical version source package is directly excluded from the subsequent processing.

[0047] The metadata of the qualified historical version source code package screened is subjected to deduplication processing, and the deduplication basis is the version number field in the metadata. If there are multiple metadata records with the same version number (which may be caused by redundant synchronization of version library mirroring), only the metadata record with the latest synchronization time is retained. Then, the deduplicated metadata records are subjected to structured arrangement, the key information fields in each record are extracted and organized in a preset format, and the arranged information includes the unique version number of the historical version source code package, complete structured metadata information (including standard size range, adaptive architecture, release timestamp, etc.), actual storage path in the version library, and official compilation tool chain version information. The arranged information is arranged in ascending order of version number to construct a structured preliminary candidate set, and the set adopts a tabular data format (including row index, version number, metadata summary, storage path, and screening matching basis columns).

[0048] Step 2.2, analyze the export symbol table information of the binary file to be detected, extract the list of exported function names and the number of exported functions; compare the list of exported function names and the number of exported functions with the official export symbol declaration of each historical version source code in the preliminary candidate set, and select the historical version source code with a first threshold value of export symbol matching degree to form a secondary candidate set, which specifically includes: extracting the structured export symbol table information list from the binary file attribute information data set; the list contains the name, binding type, symbol type, memory address, and visibility of each exported symbol, and each entry in the list is parsed to start the symbol preprocessing process. The preprocessing operation specifically includes three steps: the first step is attribute screening, which screens out symbols with global binding attributes (excludes symbols with local binding attributes, which are mostly internal calls and have no version matching reference value) according to the binding type field of the symbol, and screens out function type symbols (excludes data type symbols to avoid data symbols interfering with version matching at the function level) according to the symbol type field; the second step is abnormal symbol elimination, which performs character checking on the screened symbol name according to a preset invalid character rule library (including non-printable characters, special control characters, and illegal encoding characters, etc.), and if the symbol name contains invalid characters in the rule library, or the symbol name is empty or longer than a preset threshold (such as 256 characters), it is determined as an abnormal symbol and is eliminated; the third step is deduplication processing, which builds a symbol name hash table, and stores the symbol names screened and eliminated in the hash table, and if there are duplicate symbol name entries (redundant due to file parsing errors), only the first stored entry is retained, and the deduplicated list of exported function names to be detected is finally generated. After the list is generated, the total number of symbols in the list is counted and recorded as N, and N is subjected to validity checking (if N is 0, the export symbol table re-extraction process in step 1 is triggered), and after the checking is passed, the list of exported function names to be detected and the value of N are stored in a temporary buffer area for subsequent comparison operations.

[0049] The traversal process of the preliminary candidate set is performed according to the arrangement order (ascending version number) of the historical version source code packages in the set, and the version library interface is called to obtain the official export symbol declaration information of the corresponding version. For each historical version source code package, first, a retrieval request is sent through the version library interface, and the request parameters include the unique version number, component category identifier, and storage path of the version. The ready-made official export symbol declaration file associated with the version is called first. The ready-made declaration file includes three types: one is the export interface header file built in the source code, the second is the symbol list document officially published, and the third is the link script. If the version library interface returns a response result without associated declaration file, a lightweight static analysis process is started: the pure source code of the historical version is pulled through the version library storage path, the core header file (according to the core header file path list preset according to the official document of the component) and the link configuration file (such as Makefile, link script) in the source code directory are located, syntax analysis is performed on the core header file, and the function declaration with the export identifier is extracted, keyword matching analysis is performed on the link configuration file, and the analysis results are integrated to generate the official export function name list of the version, which is denoted as M. For each M list generated, the same de-duplication processing is performed, and the total number of symbols (denoted as len(M)) of each M list is counted, and the extraction method (ready-made declaration file calling or lightweight static analysis) of the export symbol of the version is recorded. The M list, len(M), and the extraction method are associated with the metadata information of the corresponding historical version, and stored in the temporary comparison data set.

[0050] For each historical version in the temporary comparison dataset, start the bidirectional coverage matching process of the to-be-detected export function name list and the M list of this version. First, build a hash index of the to-be-detected export function name list, and then match each symbol name in the M list with the hash index one by one, and count the number of intersection symbols (i.e. the number of symbol names existing in both the to-be-detected list and the M list), which is denoted as C. If C is 0, it is directly determined that the export symbol matching degree of this version is 0, and no subsequent calculation is needed. If C is greater than 0, perform bidirectional coverage matching calculation: on the one hand, calculate the coverage ratio of the to-be-detected list to the M list (i.e. the ratio of C to N, reflecting the coverage degree of the to-be-detected file export symbol in the official export symbol of this version), and on the other hand, calculate the coverage ratio of the M list to the to-be-detected list (i.e. the ratio of C to len(M), reflecting the coverage degree of the official export symbol of this version in the to-be-detected file export symbol), and then take the arithmetic mean of the two coverage ratios to obtain the bidirectional matching degree of the export symbol of this historical version. In the calculation process, the matching details are recorded synchronously, including the intersection symbol name list, the number of difference symbols unique to the to-be-detected list (N-C), the number of difference symbols unique to the M list (len(M)-C), and the matching degree value and matching details are associated with the metadata information of the corresponding historical version, and the temporary comparison dataset is updated.

[0051] According to the preset threshold configuration library, the first threshold default parameter (the default value is 70%) of the export symbol matching degree is retrieved; then, the number N of to-be-detected export functions recorded in the temporary buffer area is obtained, and the first threshold is dynamically adjusted according to the value of N. The adjustment rule is as follows: if N is greater than 100 (indicating that the total amount of to-be-detected file export symbols is large, and a small amount of symbol loss or difference does not affect the accuracy of version matching), the first threshold is lowered to 65%; if N is less than 20 (indicating that the total amount of to-be-detected file export symbols is small, and the matching threshold needs to be increased to avoid false matching), the first threshold is increased to 75%; if N is between 20 and 100, the default threshold 70% is maintained unchanged. After the adjustment is completed, the final determined first threshold is range checked (to ensure that the threshold is between 50% and 90%, to avoid too high threshold leading to missing screening or too low threshold leading to false screening), and after the check is passed, the threshold is used as the judgment standard for subsequent version screening.

[0052] Traverse all historical version source code package metadata in the temporary comparison dataset, compare the export symbol matching degree of each version with the adjusted first threshold one by one, and screen out the historical version source code package whose matching degree is greater than or equal to the first threshold (that is, the qualified version). The screened qualified versions are sorted in descending order of export symbol matching degree, and if there are multiple versions with the same matching degree, they are sorted in descending order of version release timestamp (preferentially retaining the newer version to improve subsequent matching accuracy). After sorting, the information of each qualified version is structured and sorted, including version number, export symbol matching degree value, matching details (intersection symbol name list, two types of difference symbol name and quantity), official export symbol extraction method, metadata summary and version library storage path; at the same time, the screening basis of each qualified version (that is, the specific value of the matching degree reaching the first threshold) is marked to ensure that the screening process is traceable. Finally, the integrity of the sorted qualified version information is checked to ensure that there is no missing key field in each version and the storage path is accessible. After passing the check, a structured secondary candidate set is generated (using tabular data format, including row index, version number, matching degree, matching details, storage path, etc.).

[0053] Step 2.3, extract the core function signature of the binary file to be detected; in the secondary candidate set, perform static analysis on each historical version source code to extract the function signature of the publicly declared core interface, and perform similarity calculation with the core function signature of the binary file to be detected, and screen out the historical version whose function signature matching degree reaches the second threshold to determine the final candidate legal version; the core function signature at least includes function name, key parameter sequence and return type characteristics, specifically including: a set of core function signatures of the binary file to be detected, which contains non-standardized fields such as original collected function name (including compiler automatically generated name modifier characters), complete parameter sequence (including parameter name, passing order, data type), return type and return logic characteristics; start the signature standardization processing procedure and execute the following sub-steps:

[0054] According to the preset compiler name modification rule library (covering the modification character rules of mainstream compilers such as GCC and MSVC), redundant compiler modification characters in the function name are stripped off by regular matching algorithm, only the combination of function name core identifier and parameter type abbreviation is retained, and uniqueness check is performed on the stripped function name to eliminate duplicate entries; parse the original parameter sequence field, extract the core data type of each parameter, eliminate non-core differences such as parameter name and parameter passing order, and generate structured key parameter sequence characteristics; extract the data type (such as void, int , enumeration type), identify whether a preset error code return branch is included (such as NULL, a preset enumeration error value, and other core return logic identifiers), remove non-core information such as return statement formats and comments, integrate the return data type and error code return characteristics into a structured return type characteristic, generate a standardized to-be-detected core signature list, each signature in the list includes three core fields: a standardized function name, a structured key parameter sequence, and a structured return type characteristic; perform integrity checking (no empty fields, no invalid characters) on the list, if there is a missing field, trigger the step 1 core function signature re-extraction process, and after the checking passes, store the list in a local temporary buffer area as the baseline data for subsequent matching.

[0055] The traversal process of the secondary candidate set generated in step 2.2 is as follows: the version export symbol matching degree in the set is in descending order, and each historical version source code package is processed one by one:

[0056] Get the official document preset core interface list of the corresponding open source component (this list is a pre-constructed structured data, including the component's core interface name, declaration file path, and key logic feature identifier), pull the pure source code package of this version from the version library storage path and decompress it to a temporary analysis directory, and locate the core interface declaration file in the source code according to the path information in the core interface list; perform syntax analysis on the located declaration file, extract the original function declaration information of each core interface, process the function name (strip compiler modifier characters), parameter sequence (extract data types and remove non-core differences), and return type (extract data types and error code return characteristics in source code annotations / logics) according to the standardization rules, and generate the core interface basic signature field; perform deep static analysis on the core interface implementation source code file, identify the function internal key loop control structure identifier (such as the for loop for traversing the core data structure, the while loop for listening to events, and other preset feature identifiers) through control flow graph (CFG) analysis, identify the key dependent function call relationship (such as the call chain of the malloc core dependent function) through call graph (CG) analysis, and integrate the above key logic features into the basic signature as supplementary fields; perform the same standardization processing as the to-be-detected signature on the integrated basic signature and core logic features to ensure that the field format and naming are completely unified, and generate a standardized candidate core signature list for this version; at the same time, perform deduplication processing (remove duplicate core interface signature entries) on the list, count the number of core signatures in the list, record the extraction log of the core signature of this version (including the located declaration file path, the analyzed source code line number, and the number of supplemented logic features), and associate the standardized candidate core signature list, the signature number, and the extraction log to the metadata information of the corresponding version, and store them in the candidate signature data set.

[0057] According to the preset field weight configuration library, the weight parameters (function name accounts for 50%, key parameter sequence accounts for 30%, return type feature accounts for 20%, and the total score is 100) of each field of the core signature are called, and field-by-field matching verification and similarity calculation are performed on each historical version in the candidate signature data set:

[0058] The function name in the standardized to-be-detected core signature list is compared with the standardized function name of the candidate version one by one, if they are completely consistent, 50 points are obtained; if the core identifier is consistent and only the difference of the modifier character / abbreviation form exists, the score is calculated according to the actual matching proportion of the core identifier; if there is no intersection of the core identifier, 0 points are obtained; the structured feature of the standardized key parameter sequence is compared, if all the parameter types and structures are completely consistent, 30 points are obtained; if the core parameter types (such as business core parameters) are consistent and the types of the secondary auxiliary parameters exist differences (the matching proportion is 90%), the score is calculated according to the actual matching proportion; if there is no intersection of the core parameter types, 0 points are obtained; the structured return type feature is compared, if the return data type and the error code return branch feature are completely consistent, 20 points are obtained; if the return data type is consistent but the number / type of the error code return branch exists differences (the matching proportion is 70%), the score is calculated according to the actual matching proportion; if there is no intersection of the return data type, 0 points are obtained; for a single core signature, the scores of the above three fields are added to obtain the matching degree (full score 100) of the signature; the arithmetic mean of the matching degrees of all signatures in the standardized to-be-detected core signature list and the corresponding candidate signatures is calculated, and the average value is converted into a percentage format as the overall signature similarity of the version;

[0059] The matching details of each version are recorded synchronously, including the specific scores of the fields, the single signature matching degree details, the average value calculation process, the core difference fields (such as function name modification difference, parameter type absence, return logic inconsistency, etc.), and the candidate signature data set is updated. According to the preset threshold configuration library, the second threshold default parameter (the default value is 85%) of the exported symbol matching degree is called; then the number of entries of the standardized to-be-detected core signature list in the temporary buffer area is read, and the threshold is dynamically adjusted according to the number: if the number of core signatures is less than 5 (indicating that the sample size of the core signature is small, and the threshold needs to be increased to reduce the probability of false matching), the second threshold is increased to 90%; if the number of core signatures is greater than or equal to 5, the default 85% is maintained; the adjusted second threshold is checked in the range to ensure that the threshold is in a reasonable interval of 80%-95% (considering the screening accuracy and version coverage), and the final determination threshold is determined after the check is passed.

[0060] The candidate signature data set is traversed, the historical versions (qualified versions) with the overall signature similarity greater than or equal to the final determination threshold are screened out, and the final candidate legal version is determined according to the following rules:

[0061] If the number of qualified versions is ≥ 3: sort the versions in descending order of the overall signature similarity, and select the top 3 versions to be included in the final list of candidate legitimate versions; if the number of qualified versions is 2: arrange the two versions in descending order of the overall signature similarity, and include both versions in the final list of candidate legitimate versions; if the number of qualified versions is 1: directly determine the version as the final candidate legitimate version.

[0062] Step 2.4: Obtain the pure source code from the final candidate legitimate version and compile it to generate a corresponding standard binary reference file; form a standard binary reference file set according to the standard binary reference file, specifically including: parse the header information of the binary file to be detected output in step 1, extract its operating system type (Linux / Windows / macOS), hardware architecture, and compiler features, and build a standardized compilation environment: match the compiler version and compilation tool chain recommended by the official of the open source component; configure the compilation parameters of the mainstream compilation optimization level; according to the dependency list of the official document of the version open source component, automatically install all compilation dependent libraries to ensure that the dependent version is consistent with the official recommendation; through the version control branch interface of the open source component version library, pull the pure source code of the final candidate legitimate version, eliminate all non-official modification records and redundant files, and ensure the integrity and purity of the source code; in the standardized compilation environment, according to the official recommended compilation process, execute the automatic compilation of the pure source code: execute the configuration command, compilation command and installation and packaging command in turn, and for each final candidate legitimate version, complete the compilation under 4 compilation optimization levels to generate multiple binary products (executable files or dynamic link libraries); perform validity verification on the binary products generated by the compilation, verify that the product format is consistent with the format of the binary file to be detected, parse the product export symbol table, and confirm that the core function is normally exported; call the core interface of the product to verify that the interface return result meets the official expectation and there is no running exception; structure the binary products that pass the verification, generate a file name according to the naming rule of component name-version number-compilation optimization level-hardware architecture, record the compilation environment parameters (compiler version, optimization level, dependent library version) of each product, and form a standard binary reference file set. Through the above implementation process, the candidate legitimate version can be accurately retrieved and matched from the open source component version library, and a standardized and highly reliable standard binary reference file set can be generated, effectively avoiding the comparison deviation caused by irrelevant version interference and compilation environment difference, and providing a solid technical foundation for subsequent malicious code detection.

[0063] In a preferred embodiment of the present application, in step 3, the binary file to be detected and the files in the standard binary reference file set are respectively disassembled and basic block partitioned to extract the function-level control flow graph, wherein each node represents a basic block and the edge represents the control flow transition between the basic blocks; the loop control structure composed of basic blocks in the control flow graph is abstracted as a polygon, and the outer angle sequence distribution of the polygon is calculated and counted to quantify the turning mode and complexity of the control flow path, forming a topological feature vector; the topological feature vector and the node attribute features of the control flow graph are fused to construct a function-level control flow semantic feature vector, including:

[0064] Step 3.1, respectively disassemble and identify functions of each file in the binary file to be detected and the standard binary reference file set, parse the corresponding assembly instruction sequence, and identify the entry address of each function to define the starting boundary of all functions, specifically including: reading the binary file to be processed (a single file in the reference file set or the file to be detected) into a pre-set memory buffer, and the buffer size is dynamically allocated according to the actual byte length of the file, with a 10% redundant space reserved to avoid memory overflow; At the same time, record the storage path, access permission, last modification time and other auxiliary metadata of the file for subsequent abnormal tracing; According to the preset binary format rule library (covering ELF, PE, Mach-O, etc. Main executable file / dynamic library format), determine the file format type by parsing the magic number field (such as 0x7F454C46 for ELF, 0x4D5A for PE, and 0xFEEDFACE for Mach-O) at the starting position of the file; If the magic number matching fails or the file header field is missing, it is determined as an invalid file (such as a text file, a damaged file, or an empty file), and the file is directly excluded; For files that pass the format verification, parse the header structure, extract the architecture identifier, instruction set feature, and compiler feature (indirectly identified by the compiler version field, instruction alignment method, and segment naming rule reserved in the header, such as the.section naming feature of GCC compiled files and the export table structure feature of MSVC compiled files); At the same time, check whether the actual byte length of the file is consistent with the size recorded in the header, and check for file truncation and redundant data splicing abnormalities; Integrate the above analysis results to generate a file header feature list (including format type, architecture, instruction set, compiler, and data integrity identifier), and store it in a temporary processing data set as a configuration basis for subsequent disassembly.

[0065] Based on the configuration information of the header feature list, start the code segment positioning and disassembly process:

[0066] Code segment accurate positioning: Analyze the section table / segment table structure of the binary file, filter out executable code segments through segment type identification; record the virtual address, file offset, segment length, and permission attributes (ensure executable permissions) of each code segment; exclude non-executable segments such as data segments, debugging segments, and note segments; generate a code segment information list; according to the architecture, instruction set, and compiler information in the header feature list, configure instruction set extension options (such as SSE / AVX extensions for x86, NEON extensions for ARM), and compiler instruction feature adaptation rules (such as GCC instruction alignment, MSVC redundant instruction features) to ensure compatibility of the disassembly.

[0067] Instruction-by-instruction analysis and information recording: Based on the code segment information list, start from the starting file offset of each code segment, and parse byte by byte according to the instruction length: read the current byte sequence, match the corresponding instruction template, and restore the assembly instruction (including opcode, operand, and instruction mnemonic); record the core information of each instruction: virtual address (calculated by offsetting the code segment virtual address), opcode byte sequence, operand type (register, memory, immediate number), operand value / address, and instruction length; if an unmatched byte sequence is encountered during parsing (such as data mixed into the code segment), it is marked as an abnormal instruction segment, its address range is recorded, and it is skipped to avoid affecting the overall disassembly process; integrate the parsing results of all code segments to generate a complete assembly instruction sequence list (sorted in ascending order of virtual address), each record in the list contains the above core information; perform integrity verification on the list (ensure that all executable bytes of the code segment are parsed, and the proportion of abnormal instruction segments does not exceed 5% of the total length of the code segment); if the verification is passed, store it in the temporary processing dataset as the basis for function entry recognition.

[0068] Function entry address recognition and verification based on rule library: load the preset function recognition rule library and start the function entry address recognition process:

[0069] Rule base initialization: the function identifies the rule base as a pre-constructed structured data set, covering the function entry characteristics of mainstream compilers (GCC, MSVC, Clang) and mainstream architectures (ARMv8, PowerPC): including stack frame initialization instruction sequence, function entry jump characteristics (such as "b / bl" entry jump instruction of ARM architecture), export symbol table associated entry (if the file has an export symbol table, the function address recorded in the table is used as a candidate entry), and compiler-inserted function entry identifier; traverse the assembly instruction sequence list and filter the suspected function entry addresses according to the following rules: match the stack frame initialization instruction sequence in the rule base, and take the starting address of the sequence as the suspected entry; match the function entry jump instruction characteristics in the rule base, and take the jump target address as the suspected entry; associate the parsed export symbol table, and include the function entry address recorded in the table into the suspected entry; identify the instruction addresses of the start of the code segment and the position of the permission switch within the segment, and supplement the suspected entry; integrate all suspected entry addresses, perform de-duplication processing (remove duplicate addresses), and generate a suspected entry address list; for each address in the suspected entry address list, perform the following verification operations, i.e. instruction logic verification: check if the subsequent instructions of the address conform to the function stack frame construction logic (such as whether there are stack operations, function calls, and return instructions after stack frame initialization), and exclude data segment instructions, redundant padding instructions (such as NOP instruction sequences), and interference of abnormal instruction fragments; context association verification, i.e. analyze the pre-sequences of the address, if the pre-sequences are jump / call instructions and the targets are the current address, or the pre-sequences are function return instructions, then the credibility of the address as a function entry is enhanced; if the pre-sequences are consecutive data bytes, then it is determined as an invalid entry and is excluded; cross-file consistency verification (only for reference files), i.e. compare different optimization level reference files compiled from the same version of source code, if a suspected entry exists in multiple files and the instruction characteristics are consistent, then its validity is confirmed; integrate the verified addresses to generate a final function entry address list, each record in the list contains an entry address, a matching rule type, and a verification passing basis, and is stored in a temporary processing data set.

[0070] Function start boundary definition and mapping table generation, i.e. based on the final function entry address list, complete function start boundary definition and mapping table construction:

[0071] Start boundary accurate definition, i.e. taking each function entry address as the core, defining the start boundary of the corresponding function, i.e. the start position is the instruction position corresponding to the entry address; by analyzing the execution logic of the assembly instruction sequence (such as whether other function entry addresses appear subsequently, whether there is a segment boundary), the termination range of the function is preliminarily divided (the termination boundary is not accurately positioned, only used to distinguish the start segment of different functions); ensure that the start boundary of each function is unique and does not overlap.

[0072] The mapping table is structured, that is, a function entry address-instruction sequence start position mapping table is generated, the table includes three core fields: function unique identifier, function entry address (virtual address), and instruction sequence start position (line index in the assembly instruction sequence list, facilitating quick positioning); meanwhile, auxiliary fields are supplemented, that is, matched entry feature rules, verification passing basis, and belonging code segment identifier; it is checked that each entry address in the mapping table corresponds to a valid instruction in the assembly instruction sequence list (no empty pointer, no abnormal address), and each instruction sequence start position is unique and within a legal range; if there is an invalid entry address (such as exceeding the code segment range), the entry is removed and the verification process is re-executed; after verification, the mapping table is taken as the input data of step 3.2.

[0073] In step 3.2, based on the entry address of each function, the entry instruction of the function is taken as the starting point for sequential scanning, and the instruction sequence that is continuous, has no internal jump target, and has only one entry and one exit is divided into a basic block; when an unconditional jump, conditional jump, or function return instruction is encountered, the current basic block is ended, and the target address of the jump instruction is taken as the starting point of the next basic block, until the division of the entire function instruction sequence is completed, and the basic block set of the function is obtained, which specifically includes: basic block division pre-initialization: first, load the function entry address-instruction sequence start position mapping table output in step 3.1, and the assembly instruction sequence list, and complete the following initialization operations:

[0074] Take the function unique identifier in the mapping table as the key to associate the corresponding function entry address and instruction sequence start line index, generate a structured function instruction index table; allocate an independent temporary division buffer for each function, and preset the basic block core attribute fields (unique identifier, start address, end address, instruction list, entry type, exit type), wherein the entry type is marked as function entry / jump target, and the exit type is marked as jump / return / sequential end. Load the jump / return instruction rule library, which covers the characteristics of unconditional jump, conditional jump, and function return instructions under different architectures, including instruction mnemonic, operation code characteristics, and target address analysis rules.

[0075] Sequential function instruction sequence scanning and basic block division: according to the function unique identifier in the function instruction index table, sequentially execute the basic block division for each function:

[0076] The starting point is located and the scanning is started. For the current processing function, starting from the instruction sequence starting line index corresponding to the entry address of the function, the instruction is marked as the starting instruction of the current basic block, the instruction list of the current basic block is initialized, and the assembly instruction sequence is scanned line by line in the ascending order of virtual addresses. If the scanned instruction is a normal sequential execution instruction (non-jump, non-return, such as mov, add, push, etc.): check whether the virtual address of the instruction is the target address of other jump instructions. If not, the instruction is added to the instruction list of the current basic block, and the next instruction is scanned. If yes, the current basic block division is terminated (the last instruction is taken as the end instruction of the current basic block), the jump target address is marked as the starting point of the new basic block, and the scanning is restarted. If the scanned instruction is an unconditional jump instruction, the instruction is added to the instruction list of the current basic block, the exit type of the current basic block is marked as unconditional jump, and the current basic block division is terminated. The target address of the jump instruction is parsed (the virtual address is extracted through the operand, and the address offset calculation of the relative jump is processed), and the target address is marked as the starting point of the new basic block. If the scanned instruction is a conditional jump instruction: the instruction is added to the instruction list of the current basic block, the exit type of the current basic block is marked as conditional jump, and the current basic block division is terminated. The target address of the jump instruction is parsed and marked as the starting point of the new basic block. The next instruction address of the current instruction is recorded as the sequential execution candidate starting point. If the scanned instruction is a function return instruction: the instruction is added to the instruction list of the current basic block, the exit type of the current basic block is marked as function return, the current basic block division is terminated, and the scanning of the current function in this round is ended. Unprocessed instruction iterative scanning: for the marked starting point of the new basic block, firstly, it is checked whether it has been included in the divided basic blocks (through address matching). If not, the above scanning and division logic is repeated from the starting point. If yes, the starting point is skipped to avoid repeated processing. Until all assembly instructions of the current function are scanned and divided into corresponding basic blocks.

[0077] The basic block address hash table is constructed, the start address and end address of each divided basic block are taken as the hash key, and all basic blocks are traversed: if the same key value already exists in the hash table (indicating that instruction sequence overlap leads to repeated division, such as instruction reuse in compilation optimization), the basic block with a more complete instruction list is retained, and the redundant repeated block is removed; if the basic blocks only partially overlap in start / end address, the consistency of the instruction sequence is checked, the overlapping section is split and re-divided; basic block unique identification allocation: a unique identification is allocated to each valid basic block according to the function ID-basic block sequence number rule, wherein the function ID is the function unique identification of step 3.1, and the basic block sequence number is incremented from 001 according to the division order; record the complete attribute information of each basic block: unique identification, belonging function ID, start virtual address, end virtual address, instruction list (containing the virtual address, operation code and operand of each instruction), entry type, exit type and jump target address (if any); integrate all valid basic blocks according to the function dimension to generate a basic block set with the function as a unit, and the set adopts a structured table format (containing function ID, basic block unique identification and core attribute column); check whether the basic block set of each function covers all executable instructions (without missing instructions or invalid instructions), and after the check is passed, the basic block set is taken as the input data of step 3.3.

[0078] In step 3.3, based on the function-based basic block set, the directed edges are established between the basic blocks according to the target address of the jump instruction and the logic of sequential execution, to obtain a function-level control flow graph, which specifically includes: based on the basic block set generated in step 3.2, an independent control flow graph (CFG) structure is created for each function, and the core attributes of the CFG are initialized: graph unique identification (consistent with the function unique identification), node set, edge set and function exit node; each basic block of the function is mapped to a node of the CFG, and the node attributes are associated with the basic block unique identification, the belonging function ID, the start / end address, the instruction quantity, the entry type and the exit type; the function exit node is taken as a special node, and the attribute is marked as function termination, without instruction association; the edge attribute is preset, that is, the core attributes of the control flow edge are defined: edge unique identification, source node identification, target node identification, transfer type (unconditional transfer / condition true transfer / condition false transfer / function return) and jump instruction address.

[0079] Based on the jump logic, the directed edge is constructed, that is, each basic block node in the current function basic block set is traversed, and the directed edge construction is performed according to the exit type:

[0080] If the basic block exit type is unconditional jump, the target address of the last instruction (unconditional jump instruction) in the basic block is extracted, and the basic block node (target node) corresponding to the target address is matched in the basic block set. A directed edge is created, the source node is the current basic block node, the target node is the matched basic block node, the transfer type in the edge attribute is marked as unconditional transfer, and the jump instruction address records the virtual address of the unconditional jump instruction. If the basic block exit type is conditional jump, the target address of the last instruction (conditional jump instruction) in the basic block is extracted, and the corresponding basic block node (condition true target node) is matched. First, a first directed edge is created: the source node is the current basic block node, the target node is the condition true target node, and the transfer type in the edge attribute is marked as condition true transfer. Secondly, the next instruction address (sequential execution address) of the last instruction of the current basic block is calculated, the basic block node (condition false target node) corresponding to the address is matched, and a second directed edge is created: the source node is the current basic block node, the target node is the condition false target node, and the transfer type in the edge attribute is marked as condition false transfer. The jump instruction addresses of the two edges both record the virtual address of the conditional jump instruction.

[0081] If the basic block exit type is function return, a directed edge is created, the source node is the current basic block node, the target node is the exit node of the function, the transfer type in the edge attribute is marked as function return, and the jump instruction address records the virtual address of the return instruction. The sequential execution corresponding edge is supplemented. If the exit type of the basic block is sequential end (no jump / return instruction, terminated only because the subsequent is a jump target address), the next instruction address of the last instruction is calculated, the corresponding basic block node is matched, and a directed edge is created: the source node is the current basic block node, the target node is the matched node, and the transfer type in the edge attribute is marked as sequential execution transfer.

[0082] Traverse each node in the CFG, check whether its in-edges / out-edges are consistent with the jump logic in the assembly instruction sequence: if a node has in-edges but no corresponding jump instruction points to the node (missing source node), trace back the starting address of the node, find the jump instruction in the assembly instruction sequence that points to the address, supplement the corresponding source node and directed edge; if a node has out-edges but the target node does not exist (invalid target), re-analyze the target address of the jump instruction, correct the target node or remove the invalid edge; if the sequentially executed basic block is not built corresponding edge, supplement the sequential execution transfer edge; verify whether the CFG covers all basic block nodes of the function, ensure that each node has at least one in-edge (the in-edge of the function entry basic block node is the function entry identifier) and at least one out-edge (the function exit node has no out-edge); if there is an isolated node (no in-edge and no out-edge), backtrack the basic block division process in step 3.2, check whether the instruction sequence of the node is valid, and remove the invalid isolated node; compare the edge transfer logic of the CFG with the jump rules of the assembly instruction sequence, such as the conditional jump instruction must correspond to two edges, and the unconditional jump instruction only corresponds to one edge, if there is a logic conflict (such as conditional jump only builds one edge), re-analyze the instruction and correct the edge structure. After completing the integrity verification and correction, arrange the node set in ascending order according to the node identifier, arrange the edge set in ascending order according to the edge identifier, supplement the metadata of the CFG (construction time, belonging function ID, total number of basic blocks, total number of edges); generate a standardized function-level control flow graph data file, including node list, edge list, graph structure relationship description (source node-target node-transfer type mapping); take the control flow graph as the input data of step 3.4.

[0083] Step 3.4, analyze the function-level control flow graph, identify all the loop control structures in it; the loop control structure is composed of one or more basic blocks, and its control flow transfer relationship forms at least one closed path, specifically including:

[0084] The CFG unique identifier, node set, edge set, and graph structure relationship description of each function are extracted from the parsed control flow graph data file, and a function ID-CFG-node-edge multi-level index table is constructed to support fast retrieval of the in-edge / out-edge of the node, the transition type of the edge, and the target node. A preset loop feature rule library is loaded, which is a structured data set and includes the following core features: loop control structure core features: composed of one or more basic blocks, at least one closed control flow path (from a node to return to the node through several edges), including a loop entry basic block (the first node entering the loop, unique and the first node inside the loop pointed by the node outside the loop), a loop condition judgment basic block (containing a condition jump instruction of loop termination condition, which is the core judgment node of loop execution or not), and a loop back jump basic block (the node of control flow pointing to the loop entry basic block, which is the key to form a closed path); closed path judgment rule: the transition logic of all edges in the path needs to form a closed loop without interruption, and the nodes in the closed loop belong to the same function; a preset pseudo loop identification rule library is loaded, and two types of pseudo loop control structures to be excluded are defined: compiler optimization type redundant closed path: such as the closed path formed by the redundant jump instruction inserted by the compiler for instruction alignment (without initialization, execution, and termination of complete logic); function call type temporary closed path: such as temporary address closure caused by calling the function itself (recursion) without loop termination condition or calling other functions (without actual loop execution logic); and the core basis for excluding pseudo loops is defined, that is, whether it has the complete logic chain of initialization-condition judgment-loop execution-back jump.

[0085] Control flow graph traversal and loop feature subgraph identification: traverse the control flow graph of each function in order of CFG unique identifier, and perform loop feature subgraph identification.

[0086] Traverse all directed edges of the CFG, starting from each node, initiate a depth-first search (DFS) algorithm to track all control flow paths from the node: if a path returns to the starting node after passing through several edges, and the path contains nodes / edges belonging to the same function, it is determined to be a closed path; record the node set, edge set, starting node (candidate loop entry), and jump instruction information of all closed paths; for the closed paths screened initially, check whether they meet the three elements of a loop: loop entry basic block check: identify the first node inside the loop that is pointed to by the unique node outside the loop in the closed path. If there are multiple such nodes or no such node, it is determined to be an ineffective loop; loop condition judgment basic block check: find the node containing the condition jump instruction of the loop termination condition in the closed path. If there is no such node, it is determined to be an ineffective loop; loop back jump basic block check: find the node pointing to the loop entry basic block in the closed path. If there is no such node, it is determined to be an ineffective loop; for the closed paths that meet the three elements, backtrack the instruction sequence to verify whether they have a complete logic chain of initialization (such as loop variable assignment) - condition judgment (termination condition check) - loop execution (core business logic instruction) - back jump (pointing to the entry): identify the loop variable initialization operation from the instruction sequence of the loop entry basic block, identify the termination condition from the condition judgment basic block, identify the loop execution logic (such as data operation, memory read / write) from the intermediate nodes in the closed path, and identify the jump instruction pointing to the entry from the back jump basic block. If the logic chain is missing, it is determined to be an ineffective loop.

[0087] Pseudo loop control structure exclusion and effective loop marking:

[0088] Compare the candidate loop control structures that have passed the three-element check and logic chain verification with the pseudo loop types in the pseudo loop recognition rule library: if the closed path is only composed of redundant jump instructions inserted by compilation optimization (without loop variables and execution logic), it is determined to be a compilation optimization type pseudo loop and is excluded; if the closed path is formed by function recursive calls and cross-function temporary address jumps (without fixed termination conditions), it is determined to be a function call type pseudo loop and is excluded; for the remaining effective loop control structures, classify and label them according to the loop type: divide them into counting type loops (such as for loops, containing explicit loop counts) and conditional type loops according to the execution logic; divide them into single-layer loops and nested loops (containing at least two closed paths) according to the level; record the complete attributes of each effective loop control structure: loop unique identifier, function ID, all basic block node identifiers, control flow edge identifiers, loop entry / condition judgment / back jump basic block identifiers, loop type, closed path number, and core termination condition instruction address.

[0089] Integrate all effective loop control structures by function dimension, generate loop control structure set, the set adopts tabular format, the core columns include: loop unique identification, function ID, node list, edge list, loop three-element node, loop type, logical chain integrity identification; Check whether the loop control structure set of each function covers all its effective loops (no missing closed path, no false loop mixed), if there is a loop node / edge that does not match the node / edge in CFG, backtrack and identify again; The loop control structure set that passes the check is used as the input data of step 3.5.

[0090] Step 3.5, abstract the basic blocks contained in the loop control structure as the vertices of the polygon, and abstract the deterministic control flow transfer edges between the basic blocks as the edges of the polygon, to map the loop control structure to the abstract polygon, specifically including:

[0091] Extract the unique identification, contained basic block node, control flow edge, loop type (highlight nested loop) of each loop control structure in the set, and build a loop identification-node-edge index table; Load the preset deterministic control flow transfer edge rule library, define the deterministic edge as: control flow edge with fixed execution logic, no dynamic branch, including unconditional transfer edge, condition true / false transfer edge (corresponding to the fixed condition branch in the loop, such as the judgment of loop termination / continuation); Exclude non-deterministic edges: function call edge, exception handling edge (such as the jump edge corresponding to try-catch), dynamic address jump edge (such as jump based on register value); Load the nested loop level identification rule, the core is: determine the level through the inclusion relationship of closed path (all nodes of inner loop belong to the node set of outer loop), process in the order of outer and inner, and generate independent abstract polygon for each layer.

[0092] Traverse each loop control structure, extract all basic block nodes contained therein, assign a unique polygon vertex identification to each basic block node, the vertex identification rule is loop unique identification-vertex sequence; establish a basic block unique ID-vertex identification mapping relationship, record the vertex corresponding basic block core attributes (starting address, instruction quantity); for nested loop control structure, first identify the node boundary of outer loop, map the outer polygon vertex for the basic block of outer loop; identify the node boundary of inner loop (excluding outer nodes), map the inner polygon vertex for the basic block of inner loop, ensure that the inner and outer vertices have no overlap and no interference. Traverse all control flow edges of the loop control structure, filter out the deterministic control flow transfer edges according to the deterministic edge rule library: retain unconditional transfer edges, condition true / false transfer edges (related to loop termination / continue judgment), eliminate function call edges, exception handling edges, dynamic jump edges; assign a unique polygon edge identification to each filtered deterministic edge (the rule is loop unique identification-edge sequence), establish a control flow edge identification-polygon edge identification mapping relationship; the direction of the polygon edge is consistent with the direction of the control flow edge (the vertex corresponding to the source node is the starting point, and the vertex corresponding to the target node is the end point), and the edge attribute is associated with the transfer type of the control flow edge (unconditional / condition true / condition false).

[0093] Take the vertex corresponding to the loop entry basic block as the starting vertex, follow the execution direction of the deterministic control flow transfer edge, arrange all vertices in the logical order of loop entry, condition judgment, loop execution, back jump and entry; if there are branch paths (such as two directions of conditional jump), integrate the vertices in the order of condition true path and condition false path, ensure that the path has no break; connect the polygon edges corresponding to adjacent vertices in the order of sorted vertices, finally connect the last vertex and the starting vertex through the polygon edge, form a closed abstract polygon; record the edge connection order of the polygon; for nested loops, first complete the vertex sorting and polygon closure of the outer loop (covering all deterministic edges of the outer loop); then for each inner loop, based on its independent vertex set, repeat the above sorting and closure operation to generate the inner abstract polygon; mark the hierarchical relationship between the inner polygon and the outer polygon.

[0094] Record core attributes for each abstract polygon: polygon unique identifier, loop identifier to which it belongs, vertex number, edge number, vertex ordering sequence, edge connection relationship, loop type (single-layered / nested), level (outer / inner); generate loop control structure-abstract polygon mapping relationship table, core columns include: loop unique identifier, polygon unique identifier, vertex list (basic block ID-vertex identifier mapping), edge list (control flow edge ID-polygon edge identifier mapping), vertex ordering sequence, polygon closure state; check the integrity of the mapping relationship table (all loop control structures have corresponding polygons, all vertices / edges are mapped), consistency (polygon edge connection relationship is consistent with control flow edge transition logic); if there is a polygon that cannot be closed (cannot return to the starting vertex after ordering the vertices), backtrack the ordering logic and modify the vertex order; use the mapping relationship table that passes the check as the input data for step 3.6, and the above implementation process completely covers the full-link operation from loop control structure identification to abstract polygon mapping.

[0095] Step 3.6, traverse each edge of the abstract polygon, calculate the external angle between two adjacent edges; according to the traversal order, record the values of all external angles, form the external angle sequence of the loop control structure, which specifically includes: extracting the core information in the table, including the unique identification of the polygon, the identification of the loop to which it belongs, the number of vertices, the number of edges, the vertex ordering sequence and the edge connection relationship; construct a multi-level index table of polygon identification-vertex-edge-direction, where the edge direction is associated with the logical direction of the control flow transfer (such as sequential execution, condition true jump, condition false jump, back jump); load the preset abstract polygon edge logical direction vector rule library, which gives the control flow logical direction a standardized vector representation (non-geometric coordinate vector): define the basic logical direction set (such as the corresponding direction dimension 1 for sequential execution, the corresponding direction dimension 2 for condition true jump, the corresponding direction dimension 3 for condition false jump, and the corresponding direction dimension 4 for back jump to the entrance), and preset the angle mapping rule between adjacent direction dimensions (such as the angle between dimension 1 and dimension 2 is 90°, and the angle between dimension 3 and dimension 4 is 120°), as a logical reference for external angle calculation; load the external angle sequence validity checking rule, including: the sequence length needs to be consistent with the number of polygon edges, the external angle value needs to be in the preset reasonable interval (0°-360°), and there is no continuous repeated abnormal extreme value (such as multiple 360° or 0°), which is caused by vertex ordering error and needs to trigger the correction process. Traverse all abstract polygons in order of their unique identification (nested loops of inner and outer polygons are traversed separately), taking the starting vertex of each polygon (the vertex corresponding to the loop entry basic block) as the traversal starting point, and traversing all edges of the polygon in a clockwise direction; for each polygon edge traversed, retrieve its associated control flow transfer logical direction from the index table, match the standardized direction vector in the logical direction vector rule library; record the vector identifier (such as dimension 1, dimension 2) and vector attribute (corresponding to the control flow transfer type) of each edge, and generate a polygon edge identification-direction vector mapping list; for closed polygons, after traversing the last edge, supplement the traversal link of the last edge to the starting vertex corresponding edge, to ensure that the angle between the last edge and the first edge is included in the calculation range.

[0096] In a clockwise traversal order, the current edge and the next edge are marked as an adjacent edge pair, and for the last edge of the closed polygon, its adjacent edge is the first edge; based on the geometric definition of the external angle as a logical reference, the external angle value is calculated based on the direction vector angle mapping rule of the adjacent edge pair: first determine the direction dimension of the adjacent edge, retrieve the corresponding angle value in the rule library, and then determine the final external angle value according to the external angle = 360°- adjacent edge vector angle” (or directly take the angle value, depending on the rule library preset), which reflects the turning degree of the control flow path (such as 90° corresponding to a right-angle turning of the control flow, and 180° corresponding to no substantial turning of the control flow); in the traversal order, the external angle value of each adjacent edge pair is sequentially stored in the sequence buffer, and the corresponding external angle sequence is generated for each loop control structure, and the sequence identifier is bound to the unique identifier of the loop; for nested loops, independent external angle sequences of the outer polygon and the inner polygon are generated, and the hierarchical correlation is marked.

[0097] The length of each external angle sequence is checked whether it is consistent with the number of edges of the corresponding polygon (such as 4 edges corresponding to 4 external angle values), and if the length is not consistent, it is determined that the vertex ordering is wrong, the vertex ordering process is backtracked, and the external angle is recalculated after the vertex order is corrected; each external angle value in the sequence is traversed, and if the value exceeds the interval of 0°-360°, or there are three or more consecutive identical extreme values (such as 0°), it is marked as an abnormal value; for the abnormal value, the direction vector of the adjacent edge is matched again, the angle calculation logic is corrected, and if it is still abnormal, the value is excluded and the result of the re-calculation is supplemented; for the external angle sequence that passes the check, metadata (corresponding loop identifier, polygon identifier, sequence length, generation time) is supplemented, all loop control structure external angle sequences are integrated according to the function dimension, a structured external angle sequence list is generated, and the list core column includes: loop unique identifier, polygon level (outer / inner), external angle sequence, value rationality identifier; the list is used as the input data of step 3.7.

[0098] Step 3.7, analyze all the outer angle sequences of the loop control structure, calculate the statistical characteristics, including: extract the core information of each outer angle sequence in the list (sequence value, loop identification, polygon level, function ID), build a function ID-loop identification-outer angle sequence-level index table; load the preset multi-dimensional statistical feature rule library, define the core statistical feature categories to be extracted: basic statistics (mean, median, mode, variance), reflecting the concentration and dispersion of the turning mode; extreme value features (number and proportion of extreme values, extreme values are defined as >180° or <90° values), reflecting the frequency of significant turning; trend features (increasing, decreasing, fluctuating, determined by the difference between adjacent values), reflecting the change trend of the turning mode; difference distribution features (mean and variance of the difference between adjacent values), reflecting the change rate of the turning mode; load the nested loop statistical rules, the core is hierarchical calculation and overall integration: first calculate the statistical features of the inner loop outer angle sequence, then calculate the statistical features of the outer loop (excluding the outer angle corresponding to the inner layer node), and finally integrate them into the overall statistical features of the nested loop according to the preset weight (outer layer accounts for 60%, inner layer accounts for 40%).

[0099] For each single loop (non-nested) outer angle sequence, perform basic statistical calculation: mean: arithmetic mean of all sequence values; median: value at the middle position after sorting the sequence; mode: value with the highest frequency in the sequence; variance: deviation of sequence values from the mean; associate the calculation results to the identification of the loop, record the numerical precision (retain 2 decimal places); traverse the sequence values, count the number of extreme values (>180° or <90° values), calculate the extreme value proportion (number of extreme values / total length of the sequence), record the distribution interval of extreme values (e.g. 90°-120°, 180°-270°); calculate the difference between adjacent values in the sequence, count the proportion of positive (increasing), negative (decreasing), and zero (stable) differences: if the increasing proportion is >60%, it is determined to be an increasing trend; if the decreasing proportion is >60%, it is determined to be a decreasing trend; otherwise, it is determined to be a fluctuating trend; calculate the mean (reflecting the average change amplitude) and variance (reflecting the dispersion of change amplitude) of all adjacent angle differences, record the maximum and minimum values; integrate the above four types of statistical features into the statistical feature set of the single loop, and bind the feature set identification with the unique loop identification. Extract the outer polygon outer angle sequence of the nested loop, calculate the outer statistical feature set, and mark it as the outer feature; extract the inner polygon outer angle sequence of the nested loop (calculate separately for multiple inner loops and take the average), calculate the inner statistical feature set, and mark it as the inner feature; perform weighted calculation on the basic statistics, extreme value proportion, and difference distribution features according to the preset weight (outer layer accounts for 60%, inner layer accounts for 40%), and generate the overall statistical feature set of the nested loop, marking the nested level attribute.

[0100] Integrate the statistical feature set of all loops (single loop and nested loop) under the function ID according to the function ID, and calculate the arithmetic mean of the same type of feature (such as mean) of all loops (the nested loop is calculated according to the overall feature); generate a function-level outer angle sequence statistical feature set for each function, and the core columns of the set include: function unique identifier, basic statistics (mean / median / mode / variance), extreme value feature (number / percentage), trend feature, difference distribution feature (difference mean / variance), and number of contained loops; check that all feature values in the set are non-empty and non- abnormal values (such as percentage > 100%), and if there are abnormalities, backtrack the outer angle sequence of the corresponding loop to recalculate; after passing the verification, the set is taken as the input data of step 3.8.

[0101] Step 3.8, the statistical features are combined and normalized in order to form a fixed-length vector, which is used as a topological feature vector, which specifically includes:

[0102] Extract all statistical feature values of each function in the set, classify and organize them according to feature categories, and construct a function ID-feature category-feature value index table; load the preset feature sorting rule library to define the ordered combination rule: the first order is the basic statistics (mean, median, mode, variance), the second order is the extreme value feature (extreme value number, extreme value percentage), the third order is the trend feature (digital coding: increasing = 1, decreasing = 2, fluctuation = 3), and the fourth order is the difference distribution feature (difference mean, difference variance); load the preset normalization rule library to define the linear normalization method: map each feature value to the [0, 1] interval, specifically: normalized value = (feature value-feature minimum value) / (feature maximum value-feature minimum value); wherein the feature minimum value / maximum value is the global extreme value of the same type of feature value of all functions (previously calculated and stored); the fixed length of the topological feature vector is preset (such as 10 dimensions, corresponding to 10 statistical features), and a unique feature category is bound to each dimension (such as dimension 1 = mean, dimension 2 = median, …, dimension 10 = difference variance), ensuring that the vector length of all functions is consistent.

[0103] According to the order of the feature sorting rule library, the statistical feature values of each function are sequentially arranged: the basic statistical quantities (mean, median, mode, variance) are extracted and sequentially arranged; the extreme value features (extreme value number, extreme value proportion) are extracted and sequentially arranged; the trend feature is digitally coded and sequentially arranged; the difference value distribution features (difference value mean, difference value variance) are extracted and sequentially arranged; an ordered feature list is formed; if the length of the ordered feature list is less than the preset vector length, 0 is supplemented as the padding value (padded to the preset length); if the length exceeds the preset value, the non-core features at the end are removed according to the principle of giving priority to the basic statistical quantities (such as difference value variance), to ensure that the list length is consistent with the vector space. From the normalization rule library, the global minimum value and the global maximum value of each feature category are retrieved (for example, the global minimum value of the mean is 0°, and the global maximum value is 360°; the global minimum value of the extreme value proportion is 0, and the global maximum value is 1); for each feature value in the ordered feature list, the normalized value is calculated according to the linear normalization method: if the feature value is equal to the global minimum value, the normalized value is 0; if the feature value is equal to the global maximum value, the normalized value is 1; otherwise, the result is calculated according to the formula, and the result is rounded to four decimal places; for the digital coding (1 / 2 / 3) of the trend feature, it is mapped to the [0, 1] interval according to "(coding value-1) / 2"; if the normalized value exceeds the [0, 1] interval (because the feature value exceeds the global extreme value), it is corrected to 0 (less than the minimum value) or 1 (greater than the maximum value), to ensure that all normalized values are within the effective interval. The normalized feature values are filled into the preset fixed-length vector space in order, and each dimension corresponds to a normalized feature value, generating a function-level topology feature vector; the vector identifier is bound to the function unique identifier, and the mapping relationship between the vector dimension and the feature category is recorded (for example, dimension 1 = normalized mean, dimension 2 = normalized median); the dimension number of the vector is checked to be consistent with the preset length, all dimension values are within the [0, 1] interval, and the mapping relationship between the feature value and the vector dimension is correct; the topology feature vector is associated with the function unique identifier and the corresponding cycle statistical feature digest, to generate a standardized topology feature vector list.

[0104] Step 3.9, extract the node attribute features of each basic block in the control flow graph of the function level, including: type distribution vector of instructions in the basic block, feature coding reflecting operand access mode, and total number of instructions in the basic block, specifically including:

[0105] The basic block set is parsed, the function unique identifier, the basic block unique identifier, and the instruction list of each function are extracted, a function ID-basic block ID-instruction list multi-level index table is constructed to support fast retrieval of complete instruction information of each basic block; a preset instruction type rule library is loaded, the rule library is a structured data set, and the assembly instruction classification of mainstream architectures (ARMv8, etc.) is covered: arithmetic operation instructions (such as add, sub, mul, div, etc.); logical operation instructions (such as and, or, xor, not, etc.); jump instructions (such as jmp, je, jne, etc., including conditional and unconditional); memory access instructions (such as mov, load, store, etc., including read / write operations); function call instructions (such as call, bl, etc.); other instructions (such as stack operations or redundant instructions such as push, pop, nop, etc.); and the characteristic code (such as the operation code prefix, the mnemonic keyword) of each instruction type is defined to support fast matching of instruction types; a preset operand access mode rule library is loaded, which mainly includes: operand type classification (register operand, memory operand, immediate number) and identification rules (determined by the instruction operand field format, such as the register prefix % and the memory address format [addr]); register usage preference determination rules (according to the preset core register list of the architecture, such as the x86 architecture general-purpose registers rax, rbx, rcx, etc., the usage frequency of each register is counted); characteristic code specification (convert the access mode into a fixed-length digital code, such as the register operand occupies a high proportion corresponding to the code 01, and the memory operand is the main one corresponding to the code 02); and a structured storage template of preset node attribute characteristics, including four core fields of basic block unique ID, first-class characteristics (instruction type distribution vector), second-class characteristics (operand access mode characteristic code), and third-class characteristics (total number of instructions), which provides a standardized format for subsequent feature extraction.

[0106] Basic block node attribute feature extraction: according to the function ID-basic block ID order, three types of node attribute feature extraction are performed for each basic block:

[0107] The first type of feature is the instruction type distribution vector extraction: instruction type statistics: traverse the instruction list of the current basic block, for each instruction, determine its type by matching the characteristic code of the instruction type rule library, and count the number of each type of instruction (such as 5 arithmetic operations, 3 logical operations, 1 jump, etc.); proportion calculation: calculate the proportion of the number of each type of instruction in the total number of instructions of the basic block (such as 50% for arithmetic operations, 30% for logical operations, etc.); vector construction: according to the preset instruction type order of the rule library (arithmetic operation, logical operation, jump, memory access, function call, and other), the proportions of each type are combined into a fixed-length instruction type distribution vector (such as a 6-dimensional vector corresponding to the proportions of 6 types of instructions), and the sum of the values of each dimension of the vector is 1.

[0108] The second type of feature, the operand access mode feature code extraction: operand type statistics: traverse all instructions of the current basic block, extract the operands of each instruction, determine the operand type (register / memory / constant) according to the rule library, and count the access frequency of each type of operand (such as register operand access 10 times, memory operand access 3 times, and constant access 2 times); register usage preference analysis: count the usage frequency of the core register (such as rax usage 4 times and rbx usage 2 times under x86 architecture), and determine whether there is a register preference (the usage frequency of a core register accounts for more than 30% is considered to have a preference); feature code conversion: according to the coding specification of the rule library, convert the operand type proportion and register preference into standardized feature codes (such as register operand proportion 66.7% and rax preference corresponding code 0101). The third type of feature, instruction total extraction: count the number of valid instructions of the current basic block instruction list (excluding NOP and other redundant padding instructions), and take the number as the third type of feature (such as the total number of valid instructions is 12). Feature effectiveness verification, preliminary verification of the three types of features extracted: the sum of the proportion of each dimension of the instruction type distribution vector should be 1, the feature code should meet the preset specification, and the instruction total should be a positive integer. If there is an exception, re-traverse the instruction list to perform extraction.

[0109] Fill in the three types of attribute features of each basic block according to the storage template, associate the unique ID of the basic block, and generate the node attribute feature record of the single basic block. Mapping table construction, integrate all basic block feature records according to function dimension, generate basic block-node attribute feature mapping table, and the core columns in the table include: function unique identifier, basic block unique ID, instruction type distribution vector, operand access mode feature code, and instruction total. Integrity and consistency verification, ensure that each basic block has corresponding feature record, no empty field, no missing basic block; the dimension of the instruction type distribution vector of all basic blocks in the same function is consistent, and the feature code format is uniform; if there is a missing or format exception, backtrack the feature extraction process of the corresponding basic block and reprocess.

[0110] Step 3.10, for each basic block, aggregate its node attribute features to generate a corresponding node attribute summary vector, specifically including: loading the basic block-node attribute feature mapping table, completing the following initialization operations: mapping table data parsing and grouping, grouping the feature records in the mapping table according to the function unique identifier to obtain the corresponding relationship of the function- belonging basic block feature set, ensuring that all basic block features of the same function are processed in the feature set; loading the aggregation rule library, loading the preset feature aggregation rule library, the core includes: instruction type distribution vector aggregation rule (calculating the mean vector of all basic block distribution vectors under the same function, taking the arithmetic mean of each dimension); operand access mode feature encoding aggregation rule (statistical frequency of all basic block feature encoding under the same function, taking the highest frequency encoding as the global feature encoding; if there are multiple encodings with the same frequency, take the encoding that is more consistent with the function core logic); instruction total number aggregation rule (calculate the mean, maximum and minimum of the total number of instructions of all basic blocks under the same function to reflect the basic block size distribution); summary vector template initialization, preset the structured template of the node attribute summary vector, the vector length is fixed and adapted to the dimension of the topology feature vector of step 3.8 (such as the topology feature vector is 10-dimensional, the summary vector is set to 8-dimensional, to ensure the compatibility of subsequent splicing), the structured template contains the aggregation feature sequence preset as: instruction type distribution mean vector (6-dimensional), operand access mode global encoding (1-dimensional, after digital conversion) and instruction total number statistical features (3-dimensional: mean, maximum and minimum, here to adapt the vector length, 3-dimensional can be integrated into 2-dimensional, such as mean and range, range = maximum - minimum).

[0111] The function node attribute feature aggregation: according to the function unique identifier order, the function is executed feature aggregation: instruction type distribution vector aggregation, extract the instruction type distribution vector of all basic blocks under the function, calculate the mean value of each dimension according to the aggregation rule (such as a function contains 3 basic blocks, the arithmetic operation dimension proportion is 50%, 40% and 60% respectively, and the mean value is 50%), and generate the instruction type distribution mean value vector of the function (the dimension is consistent with the single basic block distribution vector, such as 6 dimensions). The operand access mode feature code aggregation: code frequency statistics, statistics of the operand access mode feature code of all basic blocks under the function, record the occurrence frequency of each code (such as code 0101 appears 8 times, and code 0102 appears 2 times); Global code determination, take the code with the highest frequency as the global feature code of the operand access mode of the function (such as 0101); Digital conversion, convert the global feature code into a numerical value (such as 0101 is converted into 101), which is a dimension of the summary vector; Instruction total number statistics feature aggregation, basic statistical quantity calculation: extract the instruction total number of all basic blocks under the function, calculate the mean value (the arithmetic average of the instruction number of all basic blocks), the maximum value (the number of basic blocks with the largest number of instructions), and the minimum value (the number of basic blocks with the smallest number of instructions); Feature integration: to adapt to the fixed length of the summary vector, integrate the maximum value and the minimum value into the range (range = maximum value - minimum value), finally retain the mean value and the range as two dimensions of the summary vector; According to the order of the initialized summary vector template, combine the instruction type distribution mean value vector (6 dimensions), the operand access mode global code numerical value (1 dimension) and the instruction total number statistical characteristics (mean value, range, 2 dimensions) into an 8-dimensional node attribute summary vector, and ensure the fixed length of the vector. Check the dimension of the node attribute summary vector of each function and the preset template, and the numerical value of each dimension is normal (such as the mean value is positive and the range is non-negative); If there is a dimension inconsistency or numerical value abnormality, backtrack the corresponding function feature aggregation process for reprocessing; Associate the unique identifier of each function with the corresponding node attribute summary vector to generate a function-node attribute summary vector mapping table.

[0112] Step 3.11, splice the topology feature vector and the node attribute summary vector to form a comprehensive feature vector, specifically including: according to the standardized topology feature vector list and the function-node attribute summary vector mapping table, the following initialization operations are completed: associate the two mapping tables according to the function unique identifier, obtain the topology feature vector and the node attribute summary vector corresponding to each function, and ensure that the two vectors of the same function are accurately matched; load the preset dimension compatibility verification rule, the core of which includes: vector format consistency verification (both vectors are numerical fixed-length vectors, without character type fields); dimension conflict judgment (no repeated dimensions with the same meaning, such as the mean of the topology feature vector and the mean of the node attribute summary vector belong to different feature categories, which are not considered as conflicts); and the storage template of the preset comprehensive feature vector, including four core fields of function unique identifier, comprehensive feature vector, dimension information (total dimension = topology feature vector dimension + node attribute summary vector dimension), and dimension feature meaning description (such as the first 10 dimensions are topology features, and the 11th-18th dimensions are node attribute features).

[0113] Compatibility verification is performed on the two vectors of each function: format verification: confirm that both vectors are numerical fixed-length vectors without format errors; dimension conflict verification: compare the dimension feature meanings of the two vectors to confirm that there is no repeated dimension (such as topology feature focusing on loop control structure statistics, and node attribute focusing on instruction / operand features, without meaning duplication); if there is a format error or dimension conflict, backtrack to the previous step to correct the corresponding vector; perform vector splicing in the preset order (topology feature vector first, and node attribute summary vector second): if the topology feature vector is 10-dimensional and the node attribute summary vector is 8-dimensional, an 18-dimensional comprehensive feature vector is generated after splicing, the first 10 dimensions are topology feature values, and the 11th-18th dimensions are node attribute feature values; record the total dimension of each comprehensive feature vector (such as 18 dimensions), and specify the feature meaning corresponding to each dimension (such as the first dimension is the mean of the outer angle sequence, the 11th dimension is the arithmetic operation dimension proportion of the instruction type distribution mean vector, and the 18th dimension is the total number of instructions range, etc.), to ensure that the features are traceable.

[0114] Integrate the unique identifier, comprehensive feature vector, dimension information, and feature meaning description of each function according to the storage template to generate a comprehensive feature vector record of a single function; integrate the comprehensive feature vector records of all functions to generate a function-level comprehensive feature vector list; ensure that each function has a corresponding comprehensive feature vector record, without missing or duplication; after verification, the list is used as the input data of step 3.12.

[0115] Step 3.12, dimension reduction and standardization processing are performed on the integrated feature vector to obtain a function-level control flow semantic feature vector, specifically including: loading a function-level integrated feature vector list, completing the following initialization operations: parsing the list, extracting the integrated feature vector, dimension information, and feature meaning description of each function, and constructing a function ID-integrated feature vector-feature meaning index table; loading a preset dimension reduction algorithm (such as a principal component analysis PCA algorithm) and dimension reduction rules, the core including: a redundant feature judgment rule (by calculating the correlation coefficient between features, a correlation coefficient > 0.8 is considered to be highly correlated, and is judged as a redundant feature); a core feature retention standard (retaining principal components with a cumulative variance contribution rate ≥ 85%, to ensure that the feature discrimination is not lost); a preset vector dimension after dimension reduction (the vector dimension after dimension reduction of all functions is consistent, such as being uniformly reduced to 12 dimensions); loading a preset standardization rule library, defining a standardization processing method (mapping the numerical value of each dimension of the vector after dimension reduction to the standard normal distribution interval, i.e., the mean is 0 and the variance is 1), the specific rules including: global statistical quantity calculation (calculating the global mean and global standard deviation of the feature values of the same dimension of all functions); standardization conversion formula (performing numerical mapping according to the standard normal distribution conversion logic); abnormal value correction rule (if the converted numerical value exceeds the [-3, 3] interval, it is considered to be an abnormal value, and is corrected to -3 or 3); a preset control flow semantic feature vector storage template, including four core fields of file identification, function unique identification, semantic feature vector, and feature source description (topological feature / node attribute feature), wherein the file identification is associated with the unique ID of the binary file to be detected or the standard binary reference file.

[0116] Call the dimension reduction algorithm to perform feature correlation analysis on the comprehensive feature vector of all functions: calculate the correlation coefficient of any two dimensional feature values, and filter out highly correlated feature pairs with a correlation coefficient > 0.8 (such as the correlation coefficient between the average of the external angle sequence of the topological feature and the average of the total number of instructions of the node attribute feature is 0.85); calculate the variance contribution rate of each feature through the dimension reduction algorithm, retain the core feature dimension with cumulative variance contribution rate ≥ 85% (such as extracting 12-dimensional core features from the 18-dimensional comprehensive vector), and eliminate redundant feature dimensions (such as eliminating 6-dimensional highly correlated redundant features); map the comprehensive feature vector of each function to the retained core feature dimension to generate a fixed-length reduced vector (such as 12 dimensions), ensuring that the dimensions of the reduced vectors of all functions are consistent; verify the feature discrimination degree of the reduced vector (by calculating the distance between different function vectors, and the distance difference ≥ the preset threshold is considered to be qualified for discrimination degree), if the discrimination degree is insufficient, backtrack to adjust the dimension reduction rules (such as lowering the correlation coefficient threshold, increasing the cumulative variance contribution rate standard) to re-reduce. For each dimension of the reduced vector, calculate the global mean and global standard deviation of the feature values of that dimension for all functions; according to the standardization conversion logic of the rule library, map the values of each dimension of the reduced vector of each function to the standard normal distribution interval (mean 0, variance 1); traverse the standardized vector values, if a dimension value exceeds the [-3, 3] interval, correct it to -3 (less than -3) or 3 (greater than 3) according to the rules, to avoid interference of abnormal values on subsequent similarity calculation; verify that the mean of each dimension of the standardized vector is close to 0 and the variance is close to 1, to ensure that the standardization effect meets the requirements.

[0117] The standardized vector is used as the final function-level control flow semantic feature vector, which contains the topological features of the loop control structure (resistant to compiler optimization interference) and the node attribute features of the basic block (reflecting semantic logic); integrate the semantic feature vector with the corresponding file identifier, function unique identifier, and feature source description according to the storage template to generate a single function semantic feature vector record; integrate all function semantic feature vector records of the binary files to be detected and the standard binary reference files to generate a structured feature vector library, which supports fast retrieval of corresponding semantic feature vectors by file identifier and function identifier; perform integrity and consistency checks on the library: integrity check: ensure that all functions of all files to be processed have corresponding semantic feature vector records, with no missing; consistency check: all semantic feature vector dimensions are consistent and the format is uniform; after passing the check, complete the entire implementation process of step 3.12, and the feature vector library is used for subsequent steps.

[0118] Through the automated implementation of the above steps, the entire chain of processing from basic block node attribute extraction to control flow semantic feature vector construction can be completed. This semantic feature vector, through the fusion of topological features and node attribute features, combined with dimensionality reduction and standardization, can effectively shield surface interferences such as instruction order adjustment, register allocation differences, and redundant instruction insertion caused by compilation optimization, accurately capture the core control flow topology and semantic logic features of the function, and provide a high-discrimination and high-stability core feature foundation for similarity calculation in step 4.

[0119] In a preferred embodiment of the present invention, step 4, calculating the multi-dimensional structural similarity between the binary file to be detected and each standard binary reference file based on the function-level control flow semantic feature vector; determining the final matching standard binary reference file based on the multi-dimensional structural similarity includes:

[0120] Step 4.1: Based on the function-level control flow semantic feature vectors, calculate the function similarity between the binary file to be detected and each standard binary reference file. Specifically, this includes: extracting all function-level control flow semantic feature vectors of the binary file to be detected (denoted as the detection feature set F) from the feature vector library, and all function-level control flow semantic feature vectors of each standard binary reference file (denoted as standard feature sets S1, S2…S…). n (where n is the total number of standard reference files), construct a three-level index table of file identifiers, function identifiers, and semantic feature vectors; load the preset function matching rule library, the core rules include: priority matching rule (functions with the same name are prioritized to establish a correspondence, and the matching is uniquely identified by the function name); auxiliary matching rule (when functions with the same name are missing, the semantic feature vector clustering matching is performed, the features of the function to be detected are clustered with the features of the standard file functions, and the closest ones are regarded as matching pairs); anomaly handling rule (when the number of functions to be detected is inconsistent with the number of functions in the standard file, the unmatched functions are marked as isolated functions, and they are processed according to the preset weight in subsequent calculations); select the cosine similarity algorithm as the core algorithm for calculating the similarity of function feature vectors (adapted to high-dimensional vector similarity calculation scenarios), initialize the algorithm parameters (such as vector dimension alignment threshold, number of bits to retain for calculation precision); at the same time, preset the similarity weight of isolated functions (the default value is assigned 0.2, which is lower than the weight of matched functions, reducing the interference of isolated functions on the overall result). Traverse each function in the feature set to be detected F (denoted as f). i (where i is the index of the function to be detected), and the standard feature sets S are retrieved from the index table. k The function name and f in (k = 1 to n) i A consistent function (denoted as s) kj (j is the function number in the standard file), create f i -s kjThe same name matching pair is recorded as a same name matching type; for a to-be-detected isolated function f0 that does not find a same name function, a vector clustering algorithm (such as K-means clustering) is called to cluster the semantic feature vector of f0 with all isolated function feature vectors of the corresponding standard feature set S k The vector distance (Euclidean distance) of f0 and each isolated function is calculated, the standard function with the smallest distance and less than a preset distance threshold is selected as a matching object, and f0-S k0 The clustering matching pair is recorded as a clustering matching type; the function semantic feature vector dimensions of all matching pairs are checked for consistency, and the number of matching pairs and the number of isolated functions of each standard file and the to-be-detected file are counted to generate a function matching relationship table.

[0121] For each matching pair in the function matching relationship table, a cosine similarity algorithm is called to calculate the similarity value (value range [0, 1], the closer to 1, the higher the similarity) of the to-be-detected function feature vector and the standard function feature vector; for an unmatched isolated function, a preset weight is assigned to the similarity value (the similarity of the to-be-detected isolated function and the standard file is calculated as 0.2, and the similarity of the standard file isolated function and the to-be-detected file is calculated as 0.2); the function similarity average of the to-be-detected file and the current standard file S k is calculated as a weight of the number of matching pairs (i.e., the weighted sum of all matching pair similarity values divided by the total number of matching pairs, and the isolated function similarity is counted into the total sum according to the weight); a to-be-detected file-standard file S k function similarity corresponding relationship record is generated, which includes core information: to-be-detected file identifier, standard file identifier, number of matching pairs, number of isolated functions, per-matching pair similarity value, and function similarity average; all records are integrated according to the standard file dimension to generate a function similarity list.

[0122] Step 4.2, based on the function level control flow graph, extract the function call relationship graph of the binary file to be detected and the current standard binary reference file respectively; according to the function call relationship graph, calculate the function call relationship similarity, specifically including: parsing the CFG of each file, extracting the function unique identifier, function call instruction information (caller function ID, callee function ID, call frequency), and constructing the file identifier-function ID-call relationship index table; load the preset function call relationship graph construction rule, the core including: node definition (with function unique identifier as node, node attribute containing function name, semantic feature vector abstract); edge definition (with the call relationship between functions as directed edge, edge attribute containing call frequency, call type (direct call / indirect call)); graph structure specification (constructing from high to low according to call level, such as the main function as the top layer node, the called function as the lower layer node). Traverse the CFG index table of the file to be detected, take each function as a node, and extract all the call relationships of the function: if function A contains the instruction of calling function B, a directed edge from A to B is established, and the edge attribute records the call frequency; if function A indirectly calls function B through a function pointer, a directed edge from A to B is established, and the edge attribute is marked as indirect call; integrate all nodes and edges to generate the function call relationship graph G0 of the file to be detected; construct the corresponding function call relationship graph for each standard binary reference file according to the same rule above; check whether the nodes of each call relationship graph cover all the functions of the corresponding file and whether the edges completely record the call relationship between the functions (no missing call instructions, no false call edges), if there is a missing, reparse the CFG.

[0123] Based on the function matching relationship table constructed in step 4.1, the number of matching nodes (i.e. the number of function nodes with matching pairs) between the call relationship graph G0 to be detected and the current standard file call relationship graph G k is counted, and the node matching degree = the number of matching nodes / (the total number of G0 nodes + the total number of G k nodes - the number of matching nodes).

[0124] Edge matching degree calculation: traverse all directed edges (from A to B) of the call relationship graph G0 to be detected, search for the corresponding matching edge (the matching function of A to the matching function of B) in the current standard file call relationship graph G k , count the number of matching edges; at the same time, compare the attributes of the matching edges (call frequency deviation ≤ preset threshold (such as 20%) is considered as attribute matching), edge matching degree = the number of attribute matching edges / (the total number of G0 edges + the total number of G k edges - the number of attribute matching edges); through the depth first search (DFS) of the graph, compare G0 and G kthe calling hierarchy (such as the hierarchical path of the main function, the sub-function, and the grandchild function), the key calling path (such as the calling chain of the core function), the number of paths with consistent topologies, and the topology consistency = the number of consistent paths / (the total number of G0 key paths + G k the total number of key paths - the number of consistent paths);

[0125] The calling relationship similarity is calculated according to the preset weight = node matching degree x 40% + edge matching degree x 30% + topology consistency x 30%, and the result value range is [0, 1]. The function call relationship similarity list is generated by integrating the calculation results of all standard files.

[0126] Step 4.3, based on the basic block set of the function and the control flow graph at the function level, data flow analysis is performed to identify the definition-use chain in each function and the data dependency between basic blocks; by comparing the key data flow patterns of the to-be-detected binary file and the current standard binary reference file in the corresponding function, the data flow dependency similarity is calculated, which specifically includes: parsing the basic block set and CFG, extracting the function unique identifier, the basic block instruction list (including variable definition / use instructions), and the control flow transfer relationship between basic blocks, and constructing the file identifier-function ID-basic block-variable operation index table; loading the preset data flow analysis rule library, which mainly includes: definition-use chain (DU chain) identification rule (the path from the variable definition instruction (such as mov, add assignment) to the use instruction (such as cmp, call parameter transfer), which needs to include the complete link of the variable not being redefined); basic block data dependency judgment rule (if the input variable of basic block B1 is the output variable of basic block A1, and there is a control flow path from A1 to B1, then A1 and B1 have data dependency); key data flow pattern definition (core variable DU chain, core data dependency path across basic blocks, data dependency topology structure); selected DU chain matching degree + data dependency structure matching degree comprehensive algorithm, preset weight of each dimension (DU chain matching degree accounts for 50%, data dependency structure matching degree accounts for 50%). According to the function dimension (based on the function matching relationship in step 4.1), the DU chain matching degree and the data dependency structure matching degree of each to-be-detected function f i Perform data flow analysis, DU chain extraction: traverse the basic block instruction list of f i , identify the definition instruction and the use instruction of the core variable (function parameter, global variable, loop variable), track the path of the variable not being redefined, and generate the DU chain of each core variable (record the definition point, the use point, and the path length); basic block data dependency extraction, based on the control flow transfer relationship of CFG, analyze the input / output variables of each basic block in f i , identify the data flow dependency between basic blocks (record the dependent source basic block, the dependent target basic block, and the dependent variable); integrate the DU chain and the data dependency information to generate the to-be-detected function fi Key data flow pattern P i ; according to the same rule, for each standard file S k , the matching function (f i match) performs data flow analysis to generate the corresponding key data flow pattern Q kj ; compare the core variable DU chain of the function pattern P i to be detected and the function pattern Q kj : match the core variable (match by variable type and scope); compare the DU chain path of the matching variable (definition point, use point, path length deviation ≤ preset threshold (such as 10%) is considered to match); DU chain matching degree = number of matching DU chains / (total number of DU chains of P i + total number of DU chains of Q kj - number of matching DU chains); compare the basic block data dependency of P i and Q kj , match the dependent source / target basic block (based on the basic block matching relationship in step 3.2); compare the topology of dependent variables and dependent paths (such as dependency level, branch number deviation ≤ preset threshold is considered to match); data dependency structure matching degree = number of matching data dependencies / (total number of data dependencies of P i + total number of data dependencies of Q kj - number of matching data dependencies); calculate the single function data flow dependency similarity according to the preset weight = DU chain matching degree × 50% + data dependency structure matching degree × 50%; calculate the data flow dependency similarity average of the file to be detected and the current standard file S k (the weighted sum of the data flow dependency similarities of all matching functions divided by the total number of matching functions), generate the data flow dependency similarity corresponding relationship record of the file to be detected-standard file S k , integrate the calculation results of all standard files to generate a data flow dependency similarity list.

[0127] Step 4.4, weight and integrate the function similarity, function call relationship similarity and data flow dependency similarity to obtain the multi-dimensional structural similarity between the binary file to be detected and the current standard binary reference file, which specifically includes: according to the function similarity list in step 4.1, the function call relationship similarity list in step 4.2 and the data flow dependency similarity list in step 4.3, the following initialization operations are completed:

[0128] According to the file to be detected identifier-standard file identifier as the key, associate the similarity data in the three lists to obtain three groups of similarity values corresponding to each standard file S k , namely function similarity F k , function call relationship similarity C k and data flow dependency similarity D k; load preset multi-dimensional structural similarity weight configuration library, the core weight (determined based on domain experimental data and business requirements) is: function similarity weight WF=50%, function call relationship similarity weight WC=25%, data flow dependence similarity weight WD=25%; the weight can be dynamically adjusted according to the actual scene (preset weight adjustment range [30%-60%], [15%-35%], [15%-35%]); select the weighted sum algorithm as the core fusion algorithm, initialize the calculation precision (retain 4 decimal places), and the result normalization rule (ensure that the multi-dimensional structural similarity after fusion is in the range [0, 1]).

[0129] For each standard file S k , call the weighted sum algorithm to calculate the multi-dimensional structural similarity, that is, the multi-dimensional structural similarity M k = F k × WF + C k × WC + D k × WD; if M k is out of the interval [0, 1] (due to weight adjustment or single-dimensional similarity anomaly), it is mapped to the interval [0, 1] according to the normalization rule (for example, if M k >1, it is corrected to 1, and if M k <0, it is corrected to 0); if any single-dimensional similarity value of a standard file S k is missing (for example, the data flow dependence similarity is not calculated), the preset default value (for example, 0.5) of this dimension is used for calculation, and it is marked as partial dimension missing, and its priority is reduced in subsequent matching; generate a multi-dimensional structural similarity record for each standard file S k , including core information: to-be-detected file identifier, standard file identifier, function similarity F k , function call relationship similarity C k , data flow dependence similarity D k , weight configuration, multi-dimensional structural similarity M k , and calculation state (complete calculation / partial dimension missing); integrate the records of all standard files to generate a multi-dimensional structural similarity list of to-be-detected file-standard binary reference file.

[0130] Step 4.5, according to the multi-dimensional structural similarity, determine the final matched standard binary reference file, specifically including: loading the preset matching threshold configuration library, the core includes: default matching threshold T (value 80%, based on a large amount of experimental data to determine, balance matching accuracy and coverage); threshold dynamic adjustment rule (if the file to be detected is generated by special architecture / compiler, the threshold is lowered by 5%-10%; if the number of core functions of the file to be detected is less than 5, the threshold is raised by 5%-10%); priority determination rule (the priority of the standard file with complete calculation is higher than that of the file with missing dimensions; under the same similarity, the priority of the standard file with the latest release time is higher); the structured storage template of the preset matching result, including the core fields: the identification of the file to be detected, the identification list of the final matching standard file, the multi-dimensional structural similarity of each matching file, the matching threshold, the matching basis, and the abnormal prompt (if there is); according to the attribute information (architecture, compiler, core function quantity) of the file to be detected, determine the final matching threshold T0 according to the threshold dynamic adjustment rule (for example, if the file to be detected is ARM architecture and the number of core functions is 3, the default threshold is 80% up to 90%); traverse the multi-dimensional structural similarity list, filter out the standard files with multi-dimensional structural similarity M k ≥T0 (standard file meeting the standard); at the same time, distinguish the calculation state, that is, the standard file meeting the standard with complete calculation is included in the core matching candidate set; the standard file meeting the standard with missing dimensions is included in the alternative matching candidate set (only used when there is no result in the core candidate set); candidate set sorting, that is, core candidate set sorting, according to multi-dimensional structural similarity M k from high to low; if M k is the same, sort according to the standard file release timestamp from new to old (preferentially match the newer version to improve the practicability of subsequent vulnerability repair and version compatibility); the alternative candidate set is sorted according to the same rule as the core candidate set.

[0131] Core candidate set result determination, if the number of core candidate set is ≥3, select the top 3 standard files as the final matched standard binary reference file (provide multiple matching options to improve matching flexibility); if the number of core candidate set is 2, include both files in the final matching list; if the number of core candidate set is 1, directly determine the file as the final matched standard file; if the core candidate set is empty, enable the alternative candidate set, select the final matching file according to the above rules; if there is no standard file meeting the standard in the core candidate set and the alternative candidate set (all standard files M kgenerating a retrieval anomaly prompt, including core information: to-be-detected file identification, matching threshold T0, multi-dimensional structure similarity details of all standard files, core mismatch points (such as generally low function similarity and large calling relationship structure difference); meanwhile, triggering a backtracking process: backtracking the semantic feature vector generation process (re-extracting features) of step 3 or the candidate legal version screening process (supplementing more standard reference files) of step 2, to ensure the closed loop of the matching process; verifying the core function matching relationship and the consistency of the key data flow pattern between the determined final matching standard file and the to-be-detected file, to ensure that the matching result has no logical conflict.

[0132] Through the implementation process of the above steps, the whole-link processing from single-dimensional similarity calculation to multi-dimensional fusion matching can be completed. Through the comprehensive evaluation of the similarity of the three core dimensions of function semantic features, calling relationship and data flow dependence, the process effectively shields the surface interference caused by compilation optimization and architecture difference, accurately locates the most matched standard reference file of the to-be-detected binary file, and provides a reliable matching basis for subsequent malicious code detection, vulnerability tracing and version verification.

[0133] In a preferred embodiment of the present application, step 5, fine-grained difference analysis is performed on the to-be-detected binary file and the final matched standard binary reference file, to obtain a fine-grained difference analysis result; based on the fine-grained difference analysis result, sensitive data operation behavior feature detection is combined to judge whether the to-be-detected binary file is a malicious tampered version, and to locate the malicious code injection point, including:

[0134] Step 5.1, according to the final matched standard binary reference file, each function in the binary file to be detected is accurately aligned with its corresponding function in the standard binary reference file to form a corresponding function mapping relationship, specifically including: loading the final matched standard binary reference file result output in step 4.5, completing the following initialization operations: extracting the binary file to be detected identifier, the final matched standard reference file identifier, calling the function set of the file to be detected (including function unique identifier, starting / ending memory address, instruction list, semantic feature vector) from the database, the corresponding function set of the standard reference file, constructing the file identifier-function identifier-function basic attribute index table; loading the preset function accurate alignment rule library, the core rules include: basic alignment rule (the function starting / ending memory address offset is within the preset threshold (such as ±10 bytes) and is considered as preliminary alignment); semantic enhanced alignment rule (based on the control flow semantic feature vector of step 3.12, the function with a cosine similarity ≥90% is considered as semantic matching, and the deficiency of address alignment is supplemented); boundary checking rule (the entry instruction and exit instruction of the function are consistent and are considered as boundary matching); mapping relationship template initialization, preset function mapping relationship template, including core fields: binary file to be detected identifier, standard reference function identifier, alignment type, alignment confidence and memory address offset.

[0135] Function-by-function accurate alignment is performed, i.e. preliminary address alignment: each function (denoted as Fd) of the file to be detected is traversed, and functions (denoted as Fs) with function starting addresses in the standard reference file offset from Fd ≤±10 bytes are searched, and are marked as address candidate matching pairs; semantic enhanced verification, i.e. for the address candidate matching pairs, the cosine similarity of the control flow semantic feature vectors of Fd and Fs is calculated, and if the similarity ≥90%, it is determined as an accurate alignment pair; for the function pairs with no address matching but semantic similarity ≥95%, they are marked as semantic compensation alignment pairs (adapted to address offset caused by compilation optimization); isolated function marking, i.e. for the binary file to be detected functions / standard reference functions without matching objects, they are marked as isolated functions, and their function identifiers and memory address ranges are recorded, which are separately marked in subsequent difference analysis.

[0136] Function mapping relationship generation and verification, i.e. mapping relationship construction, all accurate alignment pairs and semantic compensation alignment pairs are arranged according to the mapping relationship template, and the one-to-one correspondence relationship between the binary file to be detected and the standard reference function is determined, and the alignment type, confidence and address offset are recorded; integrity verification, verifying that the core functions (business logic functions accounting for ≥80% of the total number of functions) of the binary file to be detected are all aligned, and if the core function alignment rate <80%, the similarity calculation process of step 4 is traced back to verify the accuracy of the matched standard file; generating the binary file to be detected-standard reference function mapping relationship table.

[0137] Step 5.2, for each pair of function mapping relationship, instruction level comparison is performed to obtain instruction level difference points, specifically including: according to the function mapping relationship table, the complete instruction list (including instruction address, operation code, operand and instruction type) of the calling function to be detected and the standard reference function is called according to the alignment pair, and the function alignment pair-instruction list index table is constructed; instruction comparison rule library loading, that is, the preset instruction level comparison rule library is loaded, the core rules include: instruction equivalence judgment rule (operation code is the same and operand type is consistent (such as both are register operands) is regarded as equivalent, ignoring the difference of register allocation; redundant instruction filtering rule (eliminating NOP, instruction alignment padding and other redundant instructions without business logic, only comparing effective instructions); difference type definition (new instruction, delete instruction, modify instruction (operation code change), replace instruction (operand change) and sequence adjustment instruction); difference point recording template initialization, that is, the preset instruction level difference point template, which contains the core fields: function alignment pair identification, difference instruction address, difference type, to-be-detected instruction content, standard reference instruction content and difference confidence.

[0138] The effective instructions of the function to be detected and the standard reference function are arranged in execution order, and a one-to-one correspondence relationship of instructions is established according to instruction address offset (adapt to a small amount of instruction sequence adjustment); the following judgment is performed by traversing the aligned instruction pair: if there is a certain instruction in the function to be detected and there is no standard reference function, it is marked as a new instruction; if there is a certain instruction in the standard reference function and there is no function to be detected, it is marked as a delete instruction; if the operation code is different, it is marked as a modify instruction; if the operation code is the same but the operand is different, it is marked as a replace instruction; if the instruction content is consistent but the sequence is exchanged, it is marked as a sequence adjustment instruction; for the marked difference points, it is verified whether it is a harmless difference caused by compilation optimization (such as register renaming, instruction rearrangement), if it is a harmless difference, it is marked as a compilation optimization difference, and its weight is reduced. All instruction level difference points are sorted according to the template, aggregated according to the function alignment pair dimension, and the function alignment pair-instruction level difference point list is generated.

[0139] Step 5.3, for each aligned function pair, control flow structure comparison is performed to obtain control flow difference points, specifically including: loading the control flow graphs (CFGs) of the aligned functions in the to-be-detected file and the standard reference file, extracting the core attributes of the CFGs: node number (basic block number), edge number (control flow transition edge number), loop control structure feature (loop number, loop entry / condition judgment node), and branch structure feature (branch number, branch condition instruction), and constructing the function alignment pair-CFG attribute index table; loading the preset control flow structure comparison rule library, the core rules including: topological structure comparison rule (node number / edge number deviation ≤10% is considered as topological basic consistency, and deviation >20% is considered as significant difference); loop control structure comparison rule (corresponding relationship of loop entry node, condition judgment node, and jump back node, and consistent loop termination condition instruction is considered as loop control structure matching); branch structure comparison rule (operation number and judgment logic of branch condition instruction are consistent, which is considered as branch matching); control flow difference point template initialization, that is, presetting the control flow difference point template, which contains the core fields: function alignment pair identification, difference type (topological structure difference / loop control structure difference / branch structure difference), difference node / edge identification, difference description, and impact range.

[0140] The node number and edge number deviation rate of the CFGs of the to-be-detected function and the standard reference function are calculated, and if the deviation rate >20%, it is marked as topological structure significant difference, and the identification of the deviation node / edge is recorded; the loop control structure of the aligned function (generated in step 3.4) is extracted, the corresponding relationship of the loop entry, condition judgment, and jump back node is compared, and if the loop termination condition instruction is changed and the loop number is increased or decreased, it is marked as loop control structure difference; the condition branch node (such as the basic block where the je and jne instructions are located) in the CFG is extracted, the judgment logic (such as the operation number and comparison operator) of the branch condition is compared, and if the judgment logic is changed (such as jl to jg), it is marked as branch structure difference; all control flow difference points are sorted according to the template, the corresponding basic block / node identification is associated, and the function alignment pair-control flow difference point list is generated.

[0141] Step 5.4, for the instruction-level difference points and the control flow difference points, data flow analysis is performed to obtain data flow impact analysis results, specifically including: according to the instruction-level difference point list and the control flow difference point list, extracting the function alignment pair, memory address range and basic block identification where the difference points are located, and constructing a difference point-basic block-data flow attribute index table; loading a preset data flow impact analysis rule library, the core rules including: impact range determination rule (whether the variable involved by the difference instruction is a core variable (function parameter, global variable, sensitive data variable)); propagation path tracking rule (the number of basic blocks covered by the definition-use chain of the difference variable, whether it propagates across functions); impact degree classification rule (core variable value change is considered as high impact, non-core variable change is considered as low impact, and no variable change is considered as no impact);

[0142] Difference variable extraction, that is, traversing the instruction-level / control flow difference points, extracting all variables involved in the difference region (such as registers in operands, variables corresponding to memory addresses), and marking them as difference variables; DU chain tracking, that is, for each difference variable, tracking its definition-use chain in the function to be detected / function / standard reference function, comparing the coverage range and use scenarios (such as whether it is used for conditional judgment, data output, function call parameter) of the DU chain; impact degree determination, that is, if the difference variable is a sensitive data variable (such as user privacy data, system configuration parameter) and the DU chain covers the output instruction (such as write, send), it is determined as high impact; if the difference variable is a local temporary variable and there is no cross-basic block propagation, it is determined as low impact; if the difference is only instruction order adjustment and there is no variable value change, it is determined as no impact; generating difference point-data flow impact analysis records, including difference point identification, involved variables, impact range, impact degree and propagation path.

[0143] Step 5.5, according to the instruction-level difference points, control flow difference points and data flow impact analysis results, generating fine-grained difference analysis results, specifically including: loading the instruction-level difference point list, control flow difference point list and data flow impact analysis record, constructing a function alignment pair-difference type-impact analysis correlation index; presetting a fine-grained difference analysis result template, including core dimensions: function-level difference summary (the number of difference points, type proportion of each function alignment pair); instruction-level difference details (difference address, type, content); control flow difference details (structure change type, involved nodes / edges); data flow impact summary (high / medium / low impact difference point number, sensitive variable involvement);

[0144] Dimension aggregation, i.e. aligning dimensions by functions, aggregating the number of instruction level / control flow difference points of the function, the data flow impact degree distribution; by difference type dimension, statistics of added / deleted / modified instruction proportion, topology / cycle / branch structure difference proportion; by impact degree dimension, statistics of high / medium / low impact difference point number and proportion; sensitive difference marking, i.e. marking the difference points involving sensitive data variables and high impact as key attention difference points; generating standardized fine-grained difference analysis results according to fine-grained difference analysis result templates.

[0145] Step 5.6, constructing a sensitive data operation behavior feature library, the sensitive data operation behavior feature library is formed by collecting known malicious code samples and extracting their operation mode features of sensitive data, specifically including: calling the binary samples of known malicious tampering versions (including viruses, trojans, ransomware, etc.) from the malicious code sample library, extracting their disassembled instruction sequences and sensitive data operation records; loading the preset sensitive data operation mode classification rules, the core categories include: sensitive data stealing (reading user privacy data, system key and writing to temporary files / network sockets); sensitive data tampering (modifying system configuration parameters, permission configuration); sensitive data export (sending sensitive data to external addresses through network instructions (such as send, connect)); permission elevation (modifying process permissions, injecting malicious code into high-privilege processes); loading feature encoding rules, converting sensitive operation modes into standardized semantic feature codes (such as reading sensitive data and network export corresponding feature code S01, tampering system configuration corresponding feature code S02).

[0146] Perform disassembly on each malicious sample, extract the instruction sequence pattern corresponding to the sensitive data operation, abstract it as an operation mode at the semantic level (not the literal instruction); perform deduplication on the extracted operation mode, classify it by sensitive operation category, assign a unique feature code, description information, and typical instruction sequence example to each mode; store the classified sensitive operation mode into the sensitive data operation behavior feature library, establish the association relationship of feature code-operation mode-typical instruction sequence-malicious behavior description, support fast retrieval by feature code / operation mode; extract new sensitive operation modes from new malicious samples regularly, supplement them to the feature library, update the feature encoding rules, and ensure the timeliness of the feature library.

[0147] Step 5.7, based on the fine-grained difference analysis results, extract all instruction-level difference points and control flow difference points corresponding to the specific memory addresses in the binary file to be detected as the code region set to be scanned, specifically including: extracting the memory address information of all instruction-level / control flow difference points according to the fine-grained difference analysis results; loading the preset code region extraction rule library, the core rules including: basic region rule (expanding ±20 bytes before and after the difference instruction address as the basic scanning region, covering the complete instruction sequence); deduplication rule (merging overlapping scanning regions into a continuous region); boundary rule (scanning region does not exceed the start / end address range of the function it belongs to);

[0148] Traverse all difference points, extract their corresponding memory addresses (instruction start addresses), and expand them into basic scanning regions according to the rules; merge overlapping scanning regions into continuous regions; mark the scanning regions corresponding to the difference points in isolated functions as isolated scanning regions; sort all scanning regions by memory address to generate the set of code regions to be scanned, including region start / end address, function identifier, and associated difference point identifier.

[0149] Step 5.8, traverse the set of code regions to be scanned, and perform disassembly on each code region to obtain its corresponding instruction sequence fragment; compare each instruction sequence fragment with the typical operation mode features in the sensitive data operation behavior feature library at the semantic level to identify the sensitive data operation instruction mode contained therein, specifically including: loading the set of code regions to be scanned, configuring disassembly parameters (instruction length, opcode table); loading the sensitive data operation behavior feature library, constructing a feature code-operation mode-semantic matching rule index, loading the preset semantic matching rule library, the core rules including: instruction sequence semantic equivalence rule (different instructions but identical function are considered as matching); pattern matching threshold (semantic similarity of instruction sequence fragment and feature library pattern ≥ 85% is considered as matching).

[0150] For each code region to be scanned, obtain its complete instruction sequence fragment (including instruction address, opcode, operand, and instruction function description); convert the instruction sequence fragment into a semantic feature sequence, ignoring register allocation, instruction order adjustment, and other superficial differences; compare the extracted semantic feature sequence with all patterns in the sensitive data operation behavior feature library, calculate the semantic similarity, and if the similarity ≥ 85%, mark it as a sensitive operation pattern match, record the matching feature code, operation mode, and confidence; generate the scanned region-sensitive operation matching record, including region address, instruction sequence fragment, matching feature code and operation mode, and confidence.

[0151] Step 5.9, for each difference point of the sensitive data operation instruction pattern, analyze its context in the data flow impact analysis result to obtain a difference point with malicious behavior characteristics, specifically including: constructing a to-be-scanned region-sensitive operation matching-data flow impact association index according to the sensitive operation matching record and the data flow impact analysis record; obtaining a preset malicious behavior judgment rule library, the core rules including: a core judgment rule (sensitive operation pattern matching + high impact data flow + involving sensitive data variables, regarded as a malicious behavior characteristic difference point); an auxiliary judgment rule (sensitive operation pattern matching + new instruction + no legal business logic, regarded as a suspected malicious difference point); an exclusion rule (sensitive operation pattern matching but standard reference file original logic, semantic equivalent change caused by only compilation optimization, regarded as harmless difference).

[0152] For each sensitive operation matching to-be-scanned region, verify whether it satisfies sensitive operation matching, high-impact data flow and sensitive data variables: if it satisfies, it is directly marked as a difference point with malicious behavior characteristics; if it does not satisfy but meets sensitive operation matching, new instruction and no legal logic, it is marked as a suspected malicious difference point; for the marked malicious / suspected malicious difference point, analyze the business logic of the function to which it belongs (such as normal function is file reading and writing, difference point adds network sending instruction), verify whether the difference point deviates from the normal business logic; for the sensitive operation matching difference point which belongs to the original logic of the standard reference file or is caused by compilation optimization, mark it as harmless matching and exclude it from the malicious difference point list; integrate all difference points with malicious behavior characteristics and suspected malicious difference points to generate a malicious difference point list, including difference point address, matching sensitive operation pattern, data flow impact and malicious judgment basis.

[0153] Step 5.10, according to the difference point with malicious behavior characteristics, the corresponding code region is located as a malicious code injection point, specifically including: extracting the memory address of the difference point, the function to which it belongs and the associated instruction sequence fragment according to the malicious difference point list of step 5.9; loading a preset injection point positioning rule library, the core rules including: accurate positioning rule (the starting memory address of the malicious difference point is the core address of the injection point, and the starting / ending address of the basic block where it is located is extended to the injection point range); association positioning rule (if multiple malicious difference points belong to the same continuous memory region, merge them into one injection point); verification rule (the injection point instruction sequence has no legal business logic and is a new instruction segment, regarded as an effective injection point); preset malicious code injection point positioning report template, including core fields: injection point address range, function to which it belongs, associated malicious difference point, matching sensitive operation pattern, malicious behavior description and positioning confidence.

[0154] The preliminary range of the injection point is determined by taking the difference point address with malicious behavior characteristics as the core, and extending to the start / end address of the basic block to which the difference point belongs; the injection point ranges corresponding to the continuous malicious difference points in the same function are merged into a complete injection area, which is marked as a malicious code injection segment; it is verified whether the instruction sequence of the injection area is newly added in the to-be-detected file and does not match the corresponding standard reference file instruction, and it is also confirmed that the area has no legal business logic support; the injection area corresponding to the malicious difference point in the isolated function is marked as an isolated injection point, and its risk level is marked separately.

[0155] A malicious code injection point positioning report is generated according to the malicious code injection point positioning report template, and the injection point address range, the function to which the injection point belongs, the malicious behavior characteristics, and the positioning confidence are determined; tampered version judgment: if there is at least one difference point with malicious behavior characteristics and a corresponding effective injection point, the to-be-detected binary file is determined to be a malicious tampered version; if there is only a suspected malicious difference point, it is determined to be a suspected malicious tampered version; if there is no malicious / suspected malicious difference point, it is determined to be a non-malicious tampered version; the judgment result, the injection point report, the to-be-detected file identifier, and the standard reference file identifier are stored in the database, and the full-link analysis log is recorded.

[0156] Through the above steps, the full-link processing from function accurate alignment, fine-grained difference analysis to sensitive operation detection and malicious injection point positioning can be completed, which can not only accurately determine whether the to-be-detected binary file is a malicious tampered version, but also determine the injection position of the malicious code, thereby providing accurate technical basis for subsequent malicious code cleaning and vulnerability repair.

[0157] As shown in Figure 2 , the network security malicious code binary search system comprises:

[0158] The acquisition module is configured to acquire file attribute information of a to-be-detected binary file, retrieve a matched candidate legal version from an open source component version library based on the file attribute information, and generate a corresponding standard binary reference file set;

[0159] The construction module is configured to perform disassembly and basic block division on the to-be-detected binary file and the files in the standard binary reference file set, respectively, to extract a function-level control flow graph, wherein each node represents a basic block, and an edge represents a control flow transfer between the basic blocks; a loop control structure composed of the basic blocks in the control flow graph is abstracted as a polygon, and the outer angle sequence distribution of the polygon is calculated and counted to quantify the turning mode and complexity of the control flow path, thereby forming a topological feature vector; the topological feature vector and the node attribute features of the control flow graph are fused to construct a function-level control flow semantic feature vector;

[0160] The determining module is configured to calculate multi-dimensional structural similarities between the to-be-detected binary file and each standard binary reference file based on the function-level control flow semantic feature vector; and determine the final matched standard binary reference file according to the multi-dimensional structural similarities.

[0161] The judging module is configured to perform fine-grained difference analysis on the to-be-detected binary file and the final matched standard binary reference file to obtain a fine-grained difference analysis result; and judge whether the to-be-detected binary file is a malicious tampered version and locate a malicious code injection point based on the fine-grained difference analysis result and in combination with sensitive data operation behavior feature detection.

[0162] The above describes the preferred embodiments of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, which should also be considered as the protection scope of the present application.

Claims

1. A network security malware binary search method, characterized by, The method comprises: obtaining file attribute information of a binary file to be detected; based on the file attribute information, retrieving a matched candidate legal version from an open source component version library, and generating a corresponding standard binary reference file set; disassembling and basic block partitioning are performed on the binary file to be detected and the files in the standard binary reference file set, respectively, to extract function-level control flow graphs, wherein each node represents a basic block, and the edges represent the control flow transitions between basic blocks; the loop control structures composed of basic blocks in the control flow graph are abstracted into polygons, the outer angle sequence distribution of the polygons is calculated and counted to quantify the turning mode and complexity of the control flow path, and a topology feature vector is formed, including: analyzing the function-level control flow graph to identify all loop control structures; the loop control structure is composed of one or more basic blocks, and the control flow transition relationship forms at least one closed path; the basic blocks contained in the loop control structure are abstracted as the vertices of the polygon, and the deterministic control flow transition edges between the basic blocks are abstracted as the edges of the polygon, so as to map the loop control structure into an abstract polygon; each edge of the abstract polygon is traversed, and the outer angle between the adjacent two edges is calculated; according to the traversal order, the values of all outer angles are recorded to form the outer angle sequence of the loop control structure; the outer angle sequences of all loop control structures are analyzed to calculate and count the statistical characteristics; the statistical characteristics are sequentially combined and normalized to form a fixed-length vector as the topology feature vector; the topology feature vector and the node attribute features of the control flow graph are fused to construct a function-level control flow semantic feature vector; based on the function-level control flow semantic feature vector, the multi-dimensional structural similarity between the binary file to be detected and each standard binary reference file is calculated; and the final matched standard binary reference file is determined according to the multi-dimensional structural similarity; fine-grained difference analysis is performed on the binary file to be detected and the final matched standard binary reference file to obtain a fine-grained difference analysis result; based on the fine-grained difference analysis result, sensitive data operation behavior feature detection is combined to determine whether the binary file to be detected is a malicious tampered version, and to locate the malicious code injection point.

2. The network security malware binary search method of claim 1, wherein, The file attribute information includes file size, export symbol table information and core function signature, and the multi-dimensional structural similarity includes basic block layout similarity, function call relationship similarity and data flow dependence similarity.

3. The network security malware binary search method of claim 2, wherein, Based on the file attribute information, the matched candidate legal version is retrieved from the open source component version library, and the corresponding standard binary reference file set is generated, including: the file size of the binary file to be detected is used as a primary filtering condition to filter out all historical version source codes with a file size within a preset tolerance range in the open source component version library to form a preliminary candidate set; the export symbol table information of the binary file to be detected is parsed to extract the export function name list and the number; the export function name list and the number are compared with the official export symbol declaration of each historical version source code in the preliminary candidate set to filter out the historical version source codes with a first threshold of export symbol matching degree to form a secondary candidate set; extracting a core function function signature of a binary file to be detected; in the secondary candidate set, performing static analysis on each historical version source code to extract the function signature of the core interface publicly declared by the historical version source code, and performing similarity calculation on the core function function signature of the binary file to be detected, and screening out the historical version with a function signature matching degree reaching a second threshold to determine as a final candidate legal version; obtaining a pure source code from the final candidate legal version and compiling to generate a corresponding standard binary reference file; and forming a standard binary reference file set according to the standard binary reference file.

4. The network security malware binary search method of claim 3, wherein, The core function function signature at least includes a function name, a key parameter sequence, and a return type feature; performing disassembly and basic block division on the binary file to be detected and the files in the standard binary reference file set respectively to extract a function-level control flow graph, wherein each node represents a basic block, and an edge represents a control flow transition between basic blocks, including: performing disassembly and function recognition on each file in the binary file to be detected and the standard binary reference file set respectively, to obtain a corresponding assembly instruction sequence, and to identify an entry address of each function to define a starting boundary of all functions; based on the entry address of each function, sequentially scanning from the entry instruction of the function, dividing a continuous instruction sequence without an internal jump target and with only one entry and one exit into a basic block; when an unconditional jump, a conditional jump, or a function return instruction is encountered, ending the current basic block, and taking the target address of the jump instruction as a starting point of the next basic block, until the division of the entire function instruction sequence is completed, to obtain a basic block set of the function; based on the basic block set of the function, establishing a directed edge between each basic block according to the target address of the jump instruction and the logic of sequential execution, to obtain a function-level control flow graph.

5. The network security malware binary search method of claim 4, wherein, fusing the topological feature vector and the node attribute feature of the control flow graph to construct a function-level control flow semantic feature vector, including: extracting a node attribute feature of each basic block in the function-level control flow graph, the node attribute feature including: a type distribution vector of instructions in the basic block, a feature code reflecting an operand access pattern, and a total number of instructions in the basic block; for each basic block, aggregating the node attribute feature to generate a corresponding node attribute summary vector; splicing the topological feature vector and the node attribute summary vector to form a comprehensive feature vector; performing dimension reduction and standardization processing on the comprehensive feature vector to obtain a function-level control flow semantic feature vector.

6. The network security malware binary search method of claim 5, wherein, based on the function-level control flow semantic feature vector, calculating a multi-dimensional structural similarity between the binary file to be detected and each standard binary reference file; determining a final matched standard binary reference file according to the multi-dimensional structural similarity, including: based on the function-level control flow semantic feature vector, calculating a function similarity between the binary file to be detected and each standard binary reference file; Based on the function level control flow graph, the function call relationship graph of the binary file to be detected and the current standard binary reference file is extracted respectively; according to the function call relationship graph, the function call relationship similarity is calculated; Based on the function basic block set and the function level control flow graph, data flow analysis is performed to identify the definition-use chain in each function and the data dependency relationship between basic blocks; by comparing the key data flow patterns of the binary file to be detected and the current standard binary reference file in the corresponding function, the data flow dependency similarity is calculated; The function similarity, function call relationship similarity and data flow dependency similarity are weighted and fused to obtain the multi-dimensional structural similarity between the binary file to be detected and the current standard binary reference file; According to the multi-dimensional structural similarity, the final matched standard binary reference file is determined.

7. The network security malware binary search method of claim 6, wherein, The binary file to be detected and the final matched standard binary reference file are subjected to fine-grained difference analysis to obtain a fine-grained difference analysis result, including: According to the final matched standard binary reference file, each function in the binary file to be detected is accurately aligned with the corresponding function in the standard binary reference file to form a corresponding function mapping relationship; For each pair of function mapping relationships, instruction level comparison is performed to obtain instruction level difference points; For each pair of aligned functions, control flow structure comparison is performed to obtain control flow difference points; For the regions where the instruction level difference points and the control flow difference points are located, data flow analysis is performed to obtain data flow impact analysis results; According to the instruction level difference points, the control flow difference points and the data flow impact analysis results, the fine-grained difference analysis result is generated.

8. The network security malware binary search method of claim 7, wherein, Based on the fine-grained difference analysis result, combined with sensitive data operation behavior feature detection, it is judged whether the binary file to be detected is a malicious tampered version, and the malicious code injection point is located, including: A sensitive data operation behavior feature library is constructed, and the sensitive data operation behavior feature library is formed by collecting known malicious code samples and extracting their operation mode features on sensitive data; Based on the fine-grained difference analysis result, the specific memory addresses in the binary file to be detected corresponding to all instruction level difference points and control flow difference points are extracted as a code region set to be scanned; The code region set to be scanned is traversed, and the corresponding instruction sequence fragment is obtained by disassembling each code region; each instruction sequence fragment is compared with the typical operation mode feature in the sensitive data operation behavior feature library at the semantic level to identify the sensitive data operation instruction mode contained therein; For each difference point of the sensitive data operation instruction mode, the context in the data flow impact analysis result is analyzed to obtain a difference point with malicious behavior characteristics; According to the difference point with malicious behavior characteristics, the corresponding code region is located as a malicious code injection point.

9. A network security malware binary search system, the system implementing the method of any of claims 1 to 8, characterized by, It includes: An acquisition module is configured to acquire file attribute information of a binary file to be detected; Based on the file attribute information, a matched candidate legal version is retrieved from an open source component version library, and a corresponding standard binary reference file set is generated; The constructing module is configured to respectively decompile and divide basic blocks of a to-be-detected binary file and files in a standard binary reference file set, extract a function-level control flow graph, wherein each node represents a basic block and an edge represents a control flow transition between basic blocks; abstract a loop control structure composed of basic blocks in the control flow graph into a polygon, calculate and count a sequence distribution of outer angles of the polygon, so as to quantify a turning mode and complexity of a control flow path, and form a topological feature vector; and fuse the topological feature vector and node attribute features of the control flow graph to construct a function-level control flow semantic feature vector. The determining module is configured to calculate multi-dimensional structural similarities between the to-be-detected binary file and each standard binary reference file based on the function-level control flow semantic feature vector; and determine a final matched standard binary reference file according to the multi-dimensional structural similarities. The judging module is configured to perform fine-grained difference analysis on the to-be-detected binary file and the final matched standard binary reference file, and obtain a fine-grained difference analysis result. Based on the fine-grained difference analysis result and in combination with sensitive data operation behavior feature detection, it is determined whether the to-be-detected binary file is a malicious tampered version, and a malicious code injection point is located. ​

Images