Malicious code detection method and device for third-party tool, medium and product

Abstract

The invention discloses a malicious code detection method and device for a third-party tool, a medium and a product. The method comprises the following steps: acquiring code data of a third-party tool; static analysis is carried out on the code data of the third-party tool to obtain static features, and the static features comprise at least one of cross-language call graph features, multi-version control flow graph difference features and local entropy values; the code data of the third-party tool is dynamically analyzed, dynamic characteristics are obtained, and the dynamic characteristics comprise at least one of an API calling sequence, memory operation information and a taint propagation path; based on a pre-trained detection model, the static features and the dynamic features are detected, a detection result of the code data of the third-party tool is obtained, and the detection result is used for indicating whether the code data of the third-party tool belongs to malicious codes or not. According to the technical scheme, collaborative analysis can be carried out on the code data through the static features and the dynamic features, and the detection accuracy of malicious codes is improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a method, device, medium and product for detecting malicious code using third-party tools. Background Technology

[0002] With the rapid development of the open-source ecosystem, third-party tool libraries have become a core dependency for software development, but they have also become a major entry point for attacks on the software supply chain. Malicious code in third-party tools refers to malicious logic implanted through the software supply chain (such as open-source libraries and plugins), including behaviors such as data theft, remote control, and system damage. This can lead to data leaks and the theft of sensitive user information, memory corruption or resource exhaustion causing service interruptions and system paralysis, and dependency propagation infecting downstream applications, resulting in large-scale security incidents.

[0003] Currently, methods for detecting malicious code include single-modal analysis methods such as matching rules or syntax tree analysis to detect known vulnerabilities. These methods have a limited scope, resulting in blind spots and instances of false positives and false negatives. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for detecting malicious code in third-party tools, thereby enabling malicious code detection of third-party tools based on multimodal features, improving detection accuracy, and reducing false positive and false negative rates.

[0005] According to one aspect of the present invention, a method for detecting malicious code using third-party tools is provided, comprising:

[0006] Obtain code data from third-party tools;

[0007] Static analysis is performed on the code data of the third-party tool to obtain static features, which include at least one of cross-language call graph features, multi-version control flow graph difference features, and local entropy values.

[0008] The code data of the third-party tool is dynamically analyzed to obtain dynamic features, wherein the dynamic features include at least one of API call sequence, memory operation information and taint propagation path;

[0009] Based on a pre-trained detection model, the static features and the dynamic features are processed to obtain the detection results of the code data of the third-party tool. The detection results are used to indicate whether the code data of the third-party tool is malicious code.

[0010] Optionally, the method for determining the cross-language call graph features includes: performing multi-language unified parsing on the code data of the third-party tool to obtain code data with a unified language structure; identifying cross-language functions and cross-language function call relationships based on the code data with the unified language structure, generating the cross-language call graph, and marking the set functions in the cross-language call graph, wherein the set functions are pre-set risky functions; and extracting the cross-language call graph features of the cross-language call graph.

[0011] Optionally, the method for determining the multi-version control flow graph difference features includes: compiling the code data of the third-party tool based on at least two compilation optimization options to obtain at least two versions of binary data; disassembling the at least two versions of binary data to obtain at least two control flow graphs; parsing the feature information of the at least two control flow graphs; comparing the feature information of the at least two control flow graphs to obtain the multi-version control flow graph difference features.

[0012] Optionally, the method for determining the local entropy value includes: compiling the code data of the third-party tool to obtain binary data; scanning the binary data based on a set sliding window, and determining the local entropy value corresponding to the local binary data during the sliding process of the set sliding window.

[0013] Optionally, the code data of the third-party tool is dynamically analyzed to obtain dynamic features, including: setting instrumentation priorities for functions in the code data of the third-party tool according to the static features; instrumenting the code data of the third-party tool based on the instrumentation priorities and injecting monitoring code; recording the call information and memory recording information of the code data of the third-party tool during operation; forming the API call sequence based on the call information; and generating the memory operation information and the pollution propagation path based on the memory recording information.

[0014] Optionally, the method further includes: performing context binding and / or spatiotemporal alignment processing on the static features and the dynamic features.

[0015] Optionally, the detection model includes a hierarchical attention module, a fusion module, and a detection module;

[0016] The hierarchical attention module includes an instruction-level attention unit, a graph structure attention unit, and a cross-modal attention unit. The instruction-level attention unit converts the assembly instruction sequence in the static features into a semantic vector, determines the weights of the assembly instruction sequences in the static features, performs weighted processing, and outputs a weighted instruction semantic feature vector. The graph structure attention unit calculates the weights of the structured data in the static features and performs weighted processing to obtain a weighted graph node feature vector. The cross-modal attention unit calculates the correlation between the static features and the dynamic features, and outputs a cross-modal fusion feature vector.

[0017] The fusion module is used to fuse the weighted instruction semantic feature vector, the weighted graph node feature vector, and the cross-modal fusion feature vector to obtain fused features;

[0018] The detection module is used to perform detection processing on the fused features to obtain the detection result.

[0019] According to another aspect of the present invention, a malicious code detection device for third-party tools is provided, comprising:

[0020] The code data acquisition module is used to acquire code data from third-party tools;

[0021] The static analysis module is used to perform static analysis on the code data of the third-party tool to obtain static features. The static features include at least one of cross-language call graph features, multi-version control flow graph difference features, and local entropy values.

[0022] The dynamic analysis module is used to perform dynamic analysis on the code data of the third-party tool to obtain dynamic features, wherein the dynamic features include at least one of API call sequence, memory operation information and taint propagation path;

[0023] The detection module is used to perform detection processing on the static features and the dynamic features based on a pre-trained detection model to obtain the detection results of the code data of the third-party tool. The detection results are used to indicate whether the code data of the third-party tool belongs to malicious code.

[0024] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0025] At least one processor; and

[0026] A memory communicatively connected to the at least one processor; wherein,

[0027] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the malicious code detection method of the third-party tool described in any embodiment of the present invention.

[0028] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement the malicious code detection method of the third-party tool described in any embodiment of the present invention.

[0029] According to another aspect of the present invention, a computer program product is provided, which, when executed by a processor, implements a malicious code detection method for third-party tools as described in any of the embodiments of the present invention.

[0030] The technical solution in this embodiment performs static and dynamic analysis on the code data of third-party tools to obtain static and dynamic features. This enables collaborative analysis of code data using both static and dynamic features, improving the accuracy of malicious code detection. The static features include cross-language call graph features, unifying multi-language code into an intermediate representation. Combined with symbolic execution and data flow analysis, this fully reconstructs cross-language attack paths, resolving detection blind spots in multi-language interaction scenarios. The static features also include multi-version control flow graph difference features, comparing binary control flow graphs with different optimization levels to identify abnormally retained jump instructions. Further analysis using code entropy values ​​in static data locates highly obfuscated areas, effectively combating obfuscation techniques. The dynamic analysis utilizes a lightweight sandbox, setting instrumentation priorities for dynamic analysis, reducing CPU usage and memory monitoring overhead, meeting real-time detection requirements.

[0031] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0032] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a flowchart of a malicious code detection method using a third-party tool, as described in an embodiment of the present invention.

[0034] Figure 2This is a schematic diagram of the structure of a malicious code detection device for a third-party tool according to an embodiment of the present invention;

[0035] Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0036] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0038] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0039] Figure 1 This is a flowchart illustrating a method for detecting malicious code in third-party tools according to an embodiment of the present invention. This embodiment is applicable to situations involving malicious code detection of third-party tools. The method can be executed by a malicious code detection device for third-party tools as described in this embodiment. This device can be implemented using software and / or hardware and can be integrated into electronic devices such as mobile terminals, computer equipment, and servers. Mobile terminals include, but are not limited to, mobile phones and tablet computers. Figure 1 As shown, the method specifically includes the following steps:

[0040] S110, Obtain code data from third-party tools.

[0041] S120. Perform static analysis on the code data of the third-party tool to obtain static features, wherein the static features include at least one of cross-language call graph features, multi-version control flow graph difference features, and local entropy values.

[0042] S130. Perform dynamic analysis on the code data of the third-party tool to obtain dynamic features, wherein the dynamic features include at least one of API call sequence, memory operation information and taint propagation path.

[0043] S140. Based on the pre-trained detection model, the static features and the dynamic features are processed to obtain the detection result of the code data of the third-party tool. The detection result is used to indicate whether the code data of the third-party tool belongs to malicious code.

[0044] In this embodiment, third-party tools can be understood as non-self-developed tools within the business system, embedded or running within the system, and used for development assistance, system operation and maintenance, data processing, and office collaboration. The code data of third-party tools can exist in the form of source code, binary data, plugins / modules, etc. For example, third-party tools include, but are not limited to, development assistance tools such as code editors and code analysis tools, system operation and maintenance tools such as remote management tools and operation and maintenance plugins, and data processing tools such as file format conversion tools and office collaboration tools. The specific type of third-party tool is not limited here and can be determined based on the actual third-party tools included in the business system.

[0045] Third-party tools pose risks such as the potential for malicious code injection or inherent security vulnerabilities. Therefore, it is necessary to perform malware detection on the code data of third-party tools to avoid the impact on business systems and improve the security of business systems if malicious code is found in the code data.

[0046] In this embodiment, static and dynamic analyses are performed on the code data from third-party tools to obtain static and dynamic features. These static and dynamic features form multimodal features, providing comprehensive features for malicious code detection, avoiding the problem of single detection dimensions, and providing a data foundation for improving the accuracy of malicious code detection.

[0047] Static analysis involves extracting static features from the code data of a third-party tool before execution, by analyzing the structure, syntax, and semantics of the code data. Static features include at least one of the following: cross-language call graph features, multi-version control flow graph difference features, and local entropy values.

[0048] A cross-language call graph can be understood as a structured graph model used to describe the call relationships between functions / methods / modules in different programming languages ​​in a multi-language hybrid development system. It intuitively presents the code call relationships between different languages ​​through nodes and edges, and can be used to analyze the complexity, dependencies, and potential risks of multi-language code data. Nodes in a cross-language call graph represent executable units in different languages, such as functions, methods, or modules / libraries, while edges represent cross-language call relationships, with the direction from the caller to the callee. For example, when a Python function calls a function in a C dynamic link library, an edge is formed from a Python node to a C node. Features of a cross-language call graph can be obtained through feature extraction, such as node feature information, edge feature information, or graph structure feature information. For example, cross-language call graph features may include the number of nodes in different languages, node degree centrality information, and call chain length.

[0049] Optionally, the method for determining the cross-language call graph features includes: performing multi-language unified parsing on the code data of the third-party tool to obtain code data with a unified language structure; identifying cross-language functions and cross-language function call relationships based on the code data with the unified language structure, generating the cross-language call graph, and marking the set functions in the cross-language call graph, wherein the set functions are pre-set risky functions; and extracting the cross-language call graph features of the cross-language call graph.

[0050] Multilingual decoders can be used to perform unified parsing of code data from third-party tools, converting the syntactic structures of different languages ​​into code data with a unified language structure. Different decoders are used to extract the syntactic structure and identify cross-language functions for different language characteristics. For example, for scripting languages, the ast module (Python) or Esprima (JS) can be used to parse the scripting language into a syntax tree and identify functions; for compiled languages, Clang (C / C++) can generate an AST, and JavaParser can parse the Java code to extract functions / methods; for binary files, Ghidra can be used to decompile and restore function symbols (such as the exec_cmd function in a .so file). The syntactic elements of these different languages ​​are then standardized to obtain the node attributes corresponding to the functions / methods. These node attributes include fields such as language type, function name, parameter list, and module, achieving unified language structure processing across languages ​​and providing node information for constructing cross-language call graphs.

[0051] By employing symbolic execution and data flow analysis, the call relationships between functions in different languages—i.e., cross-language call relationships—are identified as edges between nodes in the language call graph, forming complete cross-language call paths. Specifically, symbolic execution traverses potential call paths, simulating program input through symbolic values. This process iterates through all possible execution paths, capturing the triggering logic of cross-language calls. For scenarios where compiled languages ​​call scripts (e.g., C calling Lua), symbolic execution traces the parameters (Lua script strings) of functions like `luaL_dostring`, identifying the functions called within the script (e.g., `os.execute`). Data flow analysis tracks cross-language parameter passing, analyzing data transmission paths between different languages ​​to verify the authenticity of cross-language call relationships. During data flow analysis, the binding logic between cross-language interfaces is identified, such as Python's `ctypes` type conversion and Java's JNI method mapping, ensuring that call relationships are not obscured by language differences. For example, Python function A() passes user input `s` to C function B(char*s), and C function B then calls the system function `system(s)`. Data flow analysis traces the complete chain of calls from Python to C and then to system calls, confirming that A()→B()→system() is a valid cross-language call chain.

[0052] The identified cross-language functions are converted into nodes, and the identified cross-language call relationships are converted into edges of the nodes, forming a cross-language call graph composed of nodes and edges. Nodes correspond to node attributes, and edges correspond to edge attributes. The edge attributes are used to record call triggering conditions and parameter passing methods, etc.

[0053] Obtain a list of functions including defined functions, where defined functions are high-risk functions. Match the functions in the cross-language call graph with each defined function in the function list. When a match is successful, confirm that the defined function is included in the cross-language call graph. Mark the node corresponding to the defined function in the cross-language call graph and mark the call path corresponding to the marked node in the cross-language call graph to provide prompt information for subsequent malicious code detection.

[0054] Cross-language call graph features include at least one feature. The algorithm for extracting call features is used to extract features from the cross-language call graph features to obtain cross-language call graph features. Here, there are no restrictions on the type of cross-language call graph features and the extraction algorithm.

[0055] A control flow graph can be understood as a graphical model used to represent code execution paths and branching logic, visually displaying the control flow of code data through nodes and edges. Figure 1Generally, it is obtained through code compilation and disassembly. Different compilation optimization options during code compilation can form different versions of control flow graphs. In this embodiment, the difference features between different versions of control flow graphs are extracted.

[0056] Optionally, the method for determining the differences in the multi-version control flow graph includes: compiling the code data of the third-party tool based on at least two compilation optimization options to obtain at least two versions of binary data; disassembling the at least two versions of binary data to obtain at least two control flow graphs; parsing the feature information of the at least two control flow graphs; comparing the feature information of the at least two control flow graphs to obtain the differences in the multi-version control flow graph.

[0057] Compiler optimization options can be understood as the optimization options provided by the open-source encoder. For example, an open-source encoder might be GCC (GNU Compiler Collection), and compiler optimization options could include O0, O1, O2, and O3, with different optimization levels. At least two compiler optimization options can be used to compile the code data of a third-party tool, resulting in at least two versions of binary data. By disassembling the binary data, a control flow graph is obtained. Correspondingly, disassembling different versions of binary data yields different versions of control flow graphs, which may include different nodes and edges.

[0058] For example, the code data of a third-party tool is compiled based on compilation optimization options O0 and O3 respectively, and the resulting binary data is disassembled to obtain two versions of control flow graphs. The control flow graph corresponding to optimization option O0 includes complete logical branches, has a large number of nodes, high edge complexity, and strongly corresponds to the code data of the third-party tool. The control flow graph corresponding to optimization option O3 does not include invalid elements and redundant logic, has fewer nodes, high edge simplicity, high execution efficiency but low readability.

[0059] This process involves analyzing different versions of the control flow graph and extracting nodes and edges from each graph. It identifies the maximum common subgraph (MCS) across these versions, specifically by traversing the nodes of each SCS and performing graph similarity matching to determine the MCS. It also identifies newly added, deleted, and retained nodes and edges in each version. Based on these additions, deletions, and retentions, it determines the differences in nodes and edges. Difference nodes include newly added and deleted nodes, while differences in edges include deleted, added, and modified edges. Finally, it extracts multi-version control flow graph difference features, which may include the number of difference nodes, the number of difference edges, the semantic features of deleted nodes, and the semantic features of added nodes.

[0060] Code entropy can be understood as an indicator used to quantify the randomness, complexity, or disorder of information in code. It can be used as a numerical feature to measure the "suspiciousness" of code. Among them, the entropy value of malicious code (such as packed programs and obfuscated code) is higher than that of normal code, while normal code usually has a lower entropy value due to the existence of repetitive patterns (such as function templates and library code).

[0061] Optionally, the method for determining the local entropy value includes: compiling the code data of the third-party tool to obtain binary data; scanning the binary data based on a set sliding window, and determining the local entropy value corresponding to the local binary data during the sliding process of the set sliding window. The compilation method of the binary data is not limited here.

[0062] A sliding window can be set, for example, a window with a set number of bytes, such as a 521-byte window. The binary data is scanned using this sliding window, and the local entropy value of a portion of the binary data within the window is calculated during the sliding process. The code segment is then determined based on this local entropy value.

[0063] Optionally, multiple local entropy values ​​are compared based on a set threshold to determine local entropy values ​​that are greater than the set threshold. The address range of the code segment corresponding to the local entropy values ​​that are greater than the set threshold is marked as a high-entropy address region to provide prompt information for the dynamic analysis process and improve the priority of the entropy address region.

[0064] Based on the above embodiments, dynamic analysis can be understood as obtaining dynamic characteristics by acquiring the behavior and data flow during the execution of code data from third-party tools in a controlled environment. The controlled environment can be a sandbox environment. To address the problem of high resource consumption caused by traditional dynamic analysis requiring the execution of all code data, this embodiment sets function priorities, prioritizing the processing of high-priority functions to reduce CPU usage and memory consumption.

[0065] Optionally, the code data of the third-party tool is dynamically analyzed to obtain dynamic features, including: setting instrumentation priorities for functions in the code data of the third-party tool according to the static features; instrumenting the code data of the third-party tool based on the instrumentation priorities and injecting monitoring code; recording the call information and memory recording information of the code data of the third-party tool during operation; forming the API call sequence based on the call information; and generating the memory operation information and the pollution propagation path based on the memory recording information.

[0066] Based on static characteristics, functions in the code data of third-party tools are divided into two instrumentation priorities: first priority and second priority, with the first priority being higher than the second priority. Specifically, functions in the cross-language call graph can be set to first priority, functions in high-entropy address regions can be set to first priority, cross-language interfaces can be set to first priority, and other functions can be set to second priority. Functions and interfaces corresponding to the first priority are instrumented and monitoring code is injected, while functions or interfaces of the second priority are not instrumented to reduce CPU overhead.

[0067] During the execution of code data from third-party tools, call information and memory recording information are recorded. Among them, only high-entropy address regions are scanned and monitored, while low-entropy regions are ignored to reduce read and write overhead. In addition, only the call paths of set functions and the data flow paths from sensitive data sources to cross-language API interfaces are tracked to avoid the computational burden of full pollution analysis.

[0068] The recorded call information may include the called function name, call timestamp, process / thread ID, function input parameter values, the code location initiating the call, and the call return value. Memory record information may include memory operation type and memory details. Memory operation type may include allocation, deallocation, read, and write. Memory details may include, but are not limited to, memory address, size, data content being operated on, and the operation function.

[0069] The API call sequence is formed based on the call information, including: sorting the captured functions and / or PAI interfaces by call timestamps to form the API call sequence.

[0070] Memory operation information includes at least one memory metric. Generating the memory operation information based on the memory record information includes: statistically analyzing the memory record information based on statistical rules of the memory metric to obtain the memory metric. The memory metric may include, but is not limited to, memory operation frequency, memory read / write anomaly information, and sensitive memory location information. The memory operation frequency can be the number of malloc / free calls per unit time. Memory read / write anomaly information can include write operation information to read-only memory areas and excessively large memory allocation information, where excessively large memory allocation can be understood as a single allocation exceeding a set resource amount. Sensitive memory location information can be high-frequency read information of password / key regions stored in the process address space.

[0071] The pollution propagation path is generated based on the memory record information, including: marking untrusted data as tainted data, where untrusted data includes user input (such as parameters of read / recv), file content, network data, etc. The transmission path of tainted data in memory is statistically analyzed using memory record data, for example, from the recv buffer → temporary variable → system parameters.

[0072] Building upon the above embodiments, dynamic analysis further includes identifying sensitive behaviors based on call information and / or memory recording information. This involves pre-setting conditions for sensitive behaviors, and when the call information and / or memory recording information meet these conditions, it is determined that sensitive information has been detected, and the sensitive behavior information is recorded. For example, a sensitive behavior might include a potential spray attack, the conditions of which include allocating memory blocks exceeding a certain threshold within a set time period.

[0073] Since static analysis cannot confirm whether cross-language calls actually trigger malicious behavior, and dynamic analysis struggles to understand code structure, this embodiment correlates static and dynamic features to establish multi-dimensional feature relationships, improving the accuracy and interpretability of malicious code risk assessment. Optionally, the static and dynamic features are subjected to context binding and / or spatiotemporal alignment processing.

[0074] Static features reflect the "potential capabilities" of code (such as whether it contains the `system` function or whether the control flow is complex), while dynamic features reflect the "actual behavior" of code (such as whether it actually calls `system` to execute malicious commands or whether input data flows to sensitive functions). There is a disconnect between these two aspects, which is addressed through context binding. Context binding can associate static and dynamic features based on code location or logical semantics. For example, the static feature "high degree centrality of the `system` function node in the CFG" (potential risk) can be context-bound to the dynamic feature "`system` is called in the API call sequence with the user-inputted rm-rf / ` (actual malicious behavior), clearly establishing a direct association between the "static high-risk node" and the "dynamic malicious behavior." For instance, the static feature "Python:exec calls C:system in the cross-language call graph" (structural risk) can be bound to the dynamic feature "taint propagation path shows user input directly passed to exec" (data risk), confirming the authenticity of the risk chain.

[0075] Static analysis focuses on code text or binary structures (spatial dimension, such as the offset address of a function in a file), while dynamic analysis focuses on runtime behavior (temporal dimension, such as a function being called at the 10th second). Mismatches may exist between their spatial locations and temporal sequences. Spatiotemporal alignment establishes a mapping relationship between static and dynamic features. Optionally, spatiotemporal alignment includes spatial alignment and temporal alignment. Spatial alignment uses symbol tables, debugging information, or dynamic relocation records to associate code blocks / functions in static analysis with their memory addresses during dynamic execution, resolving positional discrepancies caused by compiler optimizations and Address Randomization (ASLR). Temporal alignment aligns the timestamps of dynamic features (such as the order of API calls) with the control flow paths of static features (such as the branch execution order in a CFG) to determine which execution stage of the static structure the dynamic behavior occurs in. For example, for spatiotemporal alignment, if the dynamic behavior occurs in a high-entropy region marked by static analysis, an association is established, and the risk weight of that behavior is increased.

[0076] In this embodiment, the correlation between static and dynamic features can reduce the problems of false positives and false negatives in the malicious code detection process.

[0077] Based on the above embodiments, a pre-trained detection model is used to detect malicious code on both static and dynamic features, achieving end-to-end malicious code detection using multimodal data and providing comprehensive and accurate detection. This detection model can be a neural network model. Optionally, the detection model can be used to detect malicious code on static and dynamic features after context binding and / or spatiotemporal alignment processing to obtain detection results.

[0078] In some optional embodiments, before performing malware detection on static and dynamic features based on the detection model, the dynamic features are further converted into numerical features that the detection model can process. Specifically, the conversion is performed based on the conversion rules of the dynamic features, for example, converting the API call sequence into a time-series vector, where each PAI corresponds to a unique ID, and the sequence is sorted by time. For memory operation information, the number of memory allocations within the statistical window, average block size, and executable region ratio are calculated; for taint propagation paths, the data flow path is represented using a graph structure, and the path length and number of sensitive nodes are extracted. For high-entropy memory content, entropy values ​​are calculated and N-gram statistics are performed on the written content to generate feature vectors.

[0079] Optionally, the detection model includes a hierarchical attention module, a fusion module, and a detection module; wherein, the hierarchical attention module includes an instruction-level attention unit, a graph structure attention unit, and a cross-modal attention unit; the instruction-level attention unit is used to convert the assembly instruction sequence in the static features into a semantic vector, determine the weights of the assembly instruction sequence in the static features and perform weighted processing, and output a weighted instruction semantic feature vector; the graph structure attention unit calculates the weights of the structured data in the static features and performs weighted processing, to obtain a weighted graph node feature vector; the cross-modal attention unit is used to calculate the correlation between the static features and the dynamic features, and output a cross-modal fusion feature vector; the fusion module is used to fuse the weighted instruction semantic feature vector, the weighted graph node feature vector, and the cross-modal fusion feature vector to obtain a fused feature; the detection module is used to perform detection processing on the fused feature to obtain the detection result.

[0080] Instruction-level attention units, graph-structured attention units, and cross-modal attention units are configured in parallel and connected to the fusion module, which in turn is connected to the detection module. The network structure of the instruction-level attention units, graph-structured attention units, and cross-modal attention units is not limited here.

[0081] The detection model was trained using a sample dataset, which included both positive and negative samples. Positive samples were sourced from historical malicious code repositories, while negative samples were sourced from official open-source libraries. During training, the model recovered its context by acquiring static and dynamic features from the sample code data and randomly masking assembly instructions or API names based on these features. Alternatively, data augmentation (such as node deletion or edge perturbation of cross-language call graphs or control flow graphs) was used to generate similar graph pairs, enabling the model to distinguish between malicious and benign graph structures.

[0082] During the inference process of the detection model, instruction semantic feature vectors, graph node feature vectors, and cross-modal fusion feature vectors are extracted from static and dynamic features respectively, and feature fusion is performed. A hierarchical attention mechanism is used to dynamically weight static and dynamic features to verify the consistency of static and dynamic evidence, reducing the false positive and false negative rates. The processing objects and functions of the instruction-level attention unit, graph structure attention unit, and cross-modal attention unit are shown in Table 1.

[0083] Table 1

[0084]

[0085] The fusion module combines the instruction semantic feature vector, graph node feature vector, and cross-modal fusion feature vector through concatenation or weighted summation to obtain fused features. The detection module can be a fully connected layer containing 1-2 layers of nonlinear transformations (such as the ReLU activation function) to reduce the dimensionality of the fused features and perform feature interaction, extracting core risk information. Finally, an output layer maps the processing result to the detection result. The output layer is typically a single neuron with a sigmoid activation function.

[0086] The detection result can be probability data between 0 and 1, representing the probability that the code data of a third-party tool contains malicious code. The probability data can be used to determine whether the code data of a third-party tool is malicious. For example, if the probability data is less than a first threshold, the code data of the third-party tool is determined not to be malicious; if the probability data is greater than a second threshold, the code data of the third-party tool is determined to be malicious; and if the probability data is between the first and second thresholds, manual review is triggered. The second threshold is greater than the first threshold.

[0087] If the code data of the third-party tool is malicious, the code data of the third-party tool will be blocked. The CI / CD integration layer enables seamless integration between the device and mainstream automation tools, ensuring that malicious code is blocked in real time during the build phase. It is automatically triggered in the pipeline, supports parallel detection, ensures that build efficiency is not affected, provides real-time feedback and blocking, and outputs a detailed detection report, including the location of malicious code, behavioral characteristics, and remediation suggestions.

[0088] The technical solution in this embodiment performs static and dynamic analysis on the code data of third-party tools to obtain static and dynamic features. This enables collaborative analysis of code data using both static and dynamic features, improving the accuracy of malicious code detection. The static features include cross-language call graph features, unifying multi-language code into an intermediate representation. Combined with symbolic execution and data flow analysis, this fully reconstructs cross-language attack paths, resolving detection blind spots in multi-language interaction scenarios. The static features also include multi-version control flow graph difference features, comparing binary control flow graphs with different optimization levels to identify abnormally retained jump instructions. Further analysis using code entropy values ​​in static data locates highly obfuscated areas, effectively combating obfuscation techniques. The dynamic analysis utilizes a lightweight sandbox, setting instrumentation priorities for dynamic analysis, reducing CPU usage and memory monitoring overhead, meeting real-time detection requirements.

[0089] Figure 2 This is a schematic diagram of a malicious code detection device for a third-party tool provided in an embodiment of the present invention. The device can be implemented using software and / or hardware, and can be integrated into any device that provides data processing capabilities, such as… Figure 2 As shown, the device specifically includes: a code data acquisition module 210, a static analysis module 220, a dynamic analysis module 230, and a detection module 240.

[0090] Among them, the code data acquisition module 210 is used to acquire code data from third-party tools;

[0091] Static analysis module 220 is used to perform static analysis on the code data of the third-party tool to obtain static features, wherein the static features include at least one of cross-language call graph features, multi-version control flow graph difference features, and local entropy values.

[0092] The dynamic analysis module 230 is used to perform dynamic analysis on the code data of the third-party tool to obtain dynamic features, wherein the dynamic features include at least one of API call sequence, memory operation information and taint propagation path;

[0093] The detection module 240 is used to perform detection processing on the static features and the dynamic features based on a pre-trained detection model to obtain the detection result of the code data of the third-party tool. The detection result is used to indicate whether the code data of the third-party tool belongs to malicious code.

[0094] The technical solution in this embodiment performs static and dynamic analysis on the code data of third-party tools to obtain static and dynamic features. This enables collaborative analysis of code data using both static and dynamic features, improving the accuracy of malicious code detection. The static features include cross-language call graph features, unifying multi-language code into an intermediate representation. Combined with symbolic execution and data flow analysis, this fully reconstructs cross-language attack paths, resolving detection blind spots in multi-language interaction scenarios. The static features also include multi-version control flow graph difference features, comparing binary control flow graphs with different optimization levels to identify abnormally retained jump instructions. Further analysis using code entropy values ​​in static data locates highly obfuscated areas, effectively combating obfuscation techniques. The dynamic analysis utilizes a lightweight sandbox, setting instrumentation priorities for dynamic analysis, reducing CPU usage and memory monitoring overhead, meeting real-time detection requirements.

[0095] Based on the above embodiments, optionally, the static analysis module 220 is further configured to: perform multilingual unified parsing on the code data of the third-party tool to obtain code data with a unified language structure; identify cross-language functions and cross-language function call relationships based on the code data with the unified language structure, generate the cross-language call graph, and mark the set functions in the cross-language call graph, wherein the set functions are pre-set risky functions; and extract the cross-language call graph features of the cross-language call graph.

[0096] Optionally, the static analysis module 220 is further configured to: compile the code data of the third-party tool based on at least two compilation optimization options to obtain at least two versions of binary data; disassemble the at least two versions of binary data to obtain at least two control flow graphs; parse the feature information of the at least two control flow graphs; compare the feature information of the at least two control flow graphs to obtain the difference features of the multi-version control flow graphs.

[0097] Optionally, the static analysis module 220 is further configured to: compile the code data of the third-party tool to obtain binary data; scan the binary data based on a set sliding window, and determine the local entropy value corresponding to the local binary data during the sliding process of the set sliding window.

[0098] Based on the above embodiments, optionally, the dynamic analysis module 230 is further configured to: set instrumentation priorities for functions in the code data of the third-party tool according to the static characteristics; perform instrumentation processing on the code data of the third-party tool based on the instrumentation priorities and inject monitoring code; record the call information and memory recording information of the code data of the third-party tool during operation; form the API call sequence based on the call information; and generate the memory operation information and the pollution propagation path based on the memory recording information.

[0099] Based on the above embodiments, optionally, the device further includes a feature association module for performing context binding and / or spatiotemporal alignment processing on the static features and the dynamic features.

[0100] Based on the above embodiments, optionally, the detection model includes a hierarchical attention module, a fusion module, and a detection module;

[0101] The hierarchical attention module includes an instruction-level attention unit, a graph structure attention unit, and a cross-modal attention unit. The instruction-level attention unit converts the assembly instruction sequence in the static features into a semantic vector, determines the weights of the assembly instruction sequences in the static features, performs weighted processing, and outputs a weighted instruction semantic feature vector. The graph structure attention unit calculates the weights of the structured data in the static features and performs weighted processing to obtain a weighted graph node feature vector. The cross-modal attention unit calculates the correlation between the static features and the dynamic features, and outputs a cross-modal fusion feature vector.

[0102] The fusion module is used to fuse the weighted instruction semantic feature vector, the weighted graph node feature vector, and the cross-modal fusion feature vector to obtain fused features;

[0103] The detection module is used to perform detection processing on the fused features to obtain the detection result.

[0104] The malicious code detection device of the aforementioned third-party tool can execute the malicious code detection method of the third-party tool provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0105] Figure 3 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0106] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0107] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0108] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as malicious code detection methods of third-party tools.

[0109] In some embodiments, the malicious code detection method for third-party tools may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the malicious code detection method for third-party tools described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the malicious code detection method for third-party tools by any other suitable means (e.g., by means of firmware).

[0110] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0111] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0112] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0113] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0114] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0115] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0116] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0117] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the malicious code detection method of a third-party tool according to any embodiment of the invention.

[0118] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0119] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for detecting malicious code using third-party tools, characterized in that, include: Obtain code data from third-party tools; Static analysis is performed on the code data of the third-party tool to obtain static features, which include at least one of cross-language call graph features, multi-version control flow graph difference features, and local entropy values. The code data of the third-party tool is dynamically analyzed to obtain dynamic features, wherein the dynamic features include at least one of API call sequence, memory operation information and taint propagation path; Based on a pre-trained detection model, the static features and the dynamic features are processed to obtain the detection results of the code data of the third-party tool. The detection results are used to indicate whether the code data of the third-party tool is malicious code.

2. The method according to claim 1, characterized in that, The method for determining the cross-language call graph features includes: The code data of the third-party tools is parsed using a unified multilingual parsing method to obtain code data with a unified language structure. Based on the code data of the unified language structure, the system identifies the function call relationships between the language and the cross-language functions, generates the cross-language call graph, and marks the pre-defined functions in the cross-language call graph, wherein the pre-defined functions are functions with pre-set risks; Extract the cross-language call graph features from the cross-language call graph.

3. The method according to claim 1, characterized in that, The method for determining the differences in the multi-version control flow graph includes: The code data of the third-party tool is compiled based on at least two compilation optimization options to obtain at least two versions of binary data. The at least two versions of binary data are then disassembled to obtain at least two control flow graphs. The feature information of the at least two control flow graphs is parsed, and the feature information of the at least two control flow graphs is compared to obtain the difference features of the multi-version control flow graphs.

4. The method according to claim 1, characterized in that, The methods for determining the local entropy value include: The code data of the third-party tool is compiled to obtain binary data; The binary data is scanned based on a set sliding window to determine the local entropy value of the local binary data during the sliding process of the set sliding window.

5. The method according to claim 1, characterized in that, Dynamic features are obtained by dynamically analyzing the code data of the third-party tool, including: Based on the static characteristics, instrumentation priorities are set for functions in the code data of the third-party tool. Based on the instrumentation priorities, instrumentation processing is performed on the code data of the third-party tool, and monitoring code is injected to record the call information and memory recording information of the code data of the third-party tool during operation. The API call sequence is formed based on the call information; The memory operation information and the pollution propagation path are generated based on the memory record information.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: The static features and dynamic features are subjected to context binding and / or spatiotemporal alignment.

7. The method according to claim 1, characterized in that, The detection model includes a hierarchical attention module, a fusion module, and a detection module; The hierarchical attention module includes an instruction-level attention unit, a graph structure attention unit, and a cross-modal attention unit. The instruction-level attention unit converts the assembly instruction sequence in the static features into a semantic vector, determines the weights of the assembly instruction sequences in the static features, performs weighted processing, and outputs a weighted instruction semantic feature vector. The graph structure attention unit calculates the weights of the structured data in the static features and performs weighted processing to obtain a weighted graph node feature vector. The cross-modal attention unit calculates the correlation between the static features and the dynamic features, and outputs a cross-modal fusion feature vector. The fusion module is used to fuse the weighted instruction semantic feature vector, the weighted graph node feature vector, and the cross-modal fusion feature vector to obtain fused features; The detection module is used to perform detection processing on the fused features to obtain the detection result.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the malicious code detection method of the third-party tool according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the malicious code detection method of any one of the third-party tools according to claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the malicious code detection method of the third-party tool according to any one of claims 1-7.

Images