Static analysis guided program behavior association monitoring and dynamic analysis method

Abstract

The invention discloses a static analysis-guided program behavior association monitoring and dynamic analysis method, which comprises the following steps of: analyzing a function call structure diagram of a program source code by adopting a static analysis technology, and constructing a static program behavior diagram template in combination with an operating system behavior statement knowledge base; analyzing the dynamic behavior of the program based on the guidance of the static program behavior graph template, and expanding and perfecting the static program behavior graph template according to the related function interacting with the system behavior to obtain a static and dynamic fused expanded program behavior graph; and performing dynamic analysis on the program running process based on the extended program behavior graph, detecting whether the program deviates from the running expectation in real time, and performing clustering and chained recognition on abnormal behaviors. According to the method, collection of behavior information of the program in each dimension and systematic construction of program behaviors are realized, so that behavior characteristics of the program can be comprehensively analyzed, and the accuracy and reliability of an analysis result are improved.

Description

Technical Field

[0001] The present invention belongs to the field of computer security technology, and in particular relates to a program behavior correlation monitoring and dynamic analysis method guided by static analysis. Background Art

[0002] Program behavior analysis involves monitoring and analyzing a program's dynamic behavior at runtime to understand its functionality, performance, and security characteristics. This analysis primarily involves monitoring system calls, memory accesses, file operations, network communications, process scheduling, and other behaviors during program execution. In the field of computer security, program behavior analysis is an effective means of detecting security threats such as malware and APT (Advanced Persistent Threat) attacks. By analyzing program behavior patterns, developers can discover potential issues, optimize programs, and prevent security vulnerabilities, thereby more accurately identifying potential threats and effectively mitigating the damage of attacks.

[0003] Currently, existing program analysis technologies can generally be divided into two categories: static analysis and dynamic analysis. Static analysis is a technology that systematically checks program code before execution. Its core idea is to identify potential defects such as errors, vulnerabilities, security risks, and performance bottlenecks in the program by analyzing the program's structure, data flow, control flow, function call relationships, etc. For example, a common program control flow analysis solution based on static analysis technology first obtains the program source code and passes it to the analysis tool. After syntax parsing, the source code is converted into an abstract syntax tree; then a control flow graph is constructed based on the parsed abstract syntax tree; then path analysis is performed based on the control flow graph, automatically tracking each path in the control flow graph. By traversing the entire path, potential logical problems and execution path anomalies in the program are comprehensively detected.

[0004] Dynamic analysis is a technology that monitors and analyzes program behavior while the program is running. Unlike static analysis, dynamic analysis relies on the actual execution of the program, collecting and analyzing data generated during runtime in real time, such as system calls, memory accesses, file operations, network communications, thread scheduling, and other information. This helps developers understand the program's actual performance, performance, behavior, and potential security issues during operation. For example, common program behavior analysis solutions based on dynamic analysis technology achieve comprehensive tracking of program behavior by monitoring and collecting information from multiple dimensions in the system. The monitoring information for each dimension is associated with specific execution operations and processes, helping developers more clearly understand the specific behavior of the program during execution.

[0005] However, the above existing methods still have the following two shortcomings.

[0006] 1. Insufficient data coverage of program behavior analysis.

[0007] Specifically, program control flow analysis solutions based on static analysis techniques focus on program control flow. By statically analyzing program code, these solutions can clearly identify function call behavior during program execution. However, they only focus on internal function calls within the program and are unaware of the rich and diverse interactions between the program and the system. During program execution, programs interact extensively with the operating system and hardware devices, such as file access, network communication, and system resource calls. However, static analysis techniques fail to capture this crucial interaction information, resulting in significant gaps in analysis data. Dynamic analysis of program behavior analyzes program behavior by monitoring and collecting data during runtime based on the actual state of program execution. However, due to the lack of prior analysis of program code, these solutions cannot fully anticipate other possible dimensions of program behavior. Program behavior is complex and multifaceted. Beyond real-time performance, there may also be hidden behaviors that are triggered only under specific conditions. Without the prior information provided by static analysis, dynamic analysis solutions struggle to fully capture these potential behaviors, resulting in insufficient coverage of program behavior analysis data.

[0008] 2. The collection of program behavior data lacks systematicity.

[0009] Specifically, dynamic analysis of program behavior, lacking the guidance of static analysis results, results in fragmented and disorganized multi-dimensional behavioral data collected, making it difficult to construct a comprehensive and coherent program behavior model. During dynamic analysis, without the information about the program's overall structure and underlying behavioral patterns provided by static analysis, data collection is often performed randomly while the program is running. While this data captures a wide range of program behaviors at different times and in different scenarios, such as system calls, memory accesses, and network interactions, it lacks clear connections and logical order. This lack of systematic data collection makes subsequent analysis and understanding of program behavior difficult. Analysts must expend considerable time and effort organizing and correlating this fragmented data, and may also draw erroneous conclusions due to incomplete or inaccurate data.

[0010] In summary, existing program analysis methods have the shortcomings of insufficient data dimension coverage and a lack of systematic data collection methods. This leads to one-sided and discrete monitoring of program behavior, making it impossible to fully analyze the behavioral characteristics of the program, affecting the accuracy and reliability of the analysis results, hindering developers from accurately identifying potential threats, and affecting the security and stability of the system. Summary of the Invention

[0011] In order to solve the above problems existing in the prior art, the present invention provides a method for program behavior correlation monitoring and dynamic analysis guided by static analysis. The technical problem to be solved by the present invention is achieved through the following technical solutions:

[0012] In a first aspect, the present invention proposes a method for program behavior correlation monitoring and dynamic analysis guided by static analysis, comprising:

[0013] Step 1: Use static analysis technology to analyze the function call structure diagram of the program source code, and build a static program behavior diagram template in combination with the operating system behavior statement knowledge base;

[0014] Step 2: Based on the guidance of the static program behavior graph template, analyze the dynamic behavior of the program, and expand and improve the static program behavior graph template according to the functions that interact with the system behavior, to obtain an expanded program behavior graph that integrates static and dynamic behavior.

[0015] Step 3: Dynamically analyze the program running process based on the extended program behavior graph, detect in real time whether the program deviates from the expected running state, and cluster and chain identify abnormal behaviors.

[0016] Beneficial effects of the present invention:

[0017] 1. The present invention provides a method for program behavior association monitoring and dynamic analysis guided by static analysis. First, the program source code is analyzed using static analysis technology to construct a static program behavior graph template. Then, under the guidance of the static program behavior graph template, the program dynamic behavior is analyzed, and the static program behavior graph template is expanded and improved through the functions involved in interacting with the system behavior to obtain an extended program behavior graph that integrates static and dynamic. Finally, based on the extended program behavior graph, the program running process is dynamically analyzed to detect in real time whether the program deviates from the expected running state, and abnormal behaviors are clustered and chained. This method pre-analyzes the function call graph of the program source code through static analysis, and then annotates the functions involved in interacting with the system behavior based on the guidance of the static program behavior graph template, so as to know in advance which dimensions of behavior will occur during the dynamic operation of the program, and monitor and collect behavior information during dynamic analysis, thereby achieving comprehensive collection of program behavior information in various dimensions; at the same time, the collected behavior information is abstracted into behavior nodes and expanded into the program behavior graph, realizing the systematic construction of program behavior, so that the behavioral characteristics of the program can be comprehensively analyzed, the accuracy and reliability of the analysis results can be improved, which is conducive to developers to accurately identify potential threats, thereby improving the security and stability of the system.

[0018] 2. The present invention provides a static analysis-guided program behavior correlation monitoring and dynamic analysis method, which adopts a graph expansion and analysis parallel execution mechanism. It can expand the behavior graph in real time during program execution and perform anomaly detection based on the behavior graph, thereby identifying potential abnormal behaviors in the shortest time without waiting for the complete program execution, and has high real-time and high efficiency.

[0019] 3. The present invention provides a method for program behavior correlation monitoring and dynamic analysis guided by static analysis. It uses static analysis results to guide dynamic analysis. By limiting the scope of instrumentation and guiding path analysis, it avoids excessive analysis of redundant paths and low-risk paths, reduces the computational overhead in the dynamic analysis process, and improves the efficiency of the system.

[0020] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 A flowchart of a static analysis-guided program behavior correlation monitoring and dynamic analysis method provided by an embodiment of the present invention;

[0022] Figure 2 A flowchart of another static analysis-guided program behavior correlation monitoring and dynamic analysis method provided by an embodiment of the present invention;

[0023] Figure 3 A schematic diagram of the process of constructing a program behavior graph provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0024] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0025] The first aspect of the present invention provides a method for monitoring and analyzing program behavior associations guided by static analysis. Figure 1 and Figure 2 , Figure 1 A schematic diagram of a process flow of a static analysis-guided program behavior correlation monitoring and dynamic analysis method provided by an embodiment of the present invention. Figure 2 A flowchart of another static analysis-guided program behavior correlation monitoring and dynamic analysis method provided by an embodiment of the present invention mainly includes the following steps:

[0026] Step 1: Use static analysis technology to analyze the function call structure diagram of the program source code, and build a static program behavior diagram template in combination with the operating system behavior statement knowledge base.

[0027] Static analysis is the basis for building program behavior templates. By parsing the program source code through static analysis, the program operation logic is deeply analyzed, and key function points that may interact with the operating system are identified as areas of focus for subsequent dynamic behavior monitoring. This embodiment uses static analysis technology to parse the target program source code, extract function entities and the calling relationships between them, and construct a function call graph with function entities as nodes and function call relationships as edges. Combined with the library function information provided by the operating system, the behavioral characteristics of each function entity are deeply analyzed, and the key functions involved in the transition between user mode and kernel mode are identified and marked, locating potential runtime behavior trigger points that are difficult to cover with static analysis. Based on the above analysis results, a program behavior graph template guided by static analysis is generated to provide structured support for subsequent dynamic behavior analysis.

[0028] See Figure 3 , Figure 3 A schematic diagram of the process of constructing a program behavior graph provided by an embodiment of the present invention.

[0029] Specifically, in this embodiment, step 1 can be implemented according to the following sub-steps 1.1-1.4.

[0030] Step 1.1: Parse the program source code, extract function entities and function call relationships, and construct a function call structure graph with function entities as nodes and function call relationships as edges.

[0031] First, the program source code is parsed at the syntax level to extract function entities (referred to as functions), call relationships, and context information. This process can be implemented using different static analysis frameworks depending on the programming language, such as Clang AST for C / C++, JavaParser for Java, and AST modules for Python.

[0032] Through the operation, the function set in the program source code is extracted, which is expressed as:

[0033] F={f1,f2,...,f n};

[0034] Where F represents the function set and n represents the total number of functions.

[0035] At the same time, identify the calling relationship between functions. If function f i Function f is called j , then:

[0036] E={(f i ,fj )|f i →f j};

[0037] Where E represents the function call relationship set.

[0038] Then, based on the function set F and the function call relationship set E, a function call structure graph is constructed with function entities as nodes and function call relationships as edges, which can be expressed as:

[0039] G=(F,E);

[0040] Where G represents the function call structure graph.

[0041] This diagram shows the function dependencies and call paths under the static structure of the program.

[0042] Step 1.2: Build an operating system behavior statement knowledge base based on the operating system library functions.

[0043] First, typical behavior categories and corresponding typical functions are extracted based on the library functions of the operating system to construct a basic classification system table.

[0044] Generally speaking, operating system library functions can be roughly categorized by their behavioral scope, covering the key behavioral dimensions of program interaction with the external environment. This example combs through the official operating system API documentation, extracts typical behavioral categories and representative functions, and constructs a basic classification system, as shown in Table 1 below.

[0045] Table 1 Basic classification system of operating system library functions

[0046]

[0047]

[0048] It can be seen that in this embodiment, the basic classification system table mainly includes four behavioral dimensions: file reading and writing, network communication, memory management, and process communication. Each dimension includes some typical functions, also called key functions.

[0049] Then, a mapping table between function names and behavior dimensions is created based on the basic classification system table, thereby building an operating system behavior statement knowledge base. The created mapping table is stored in JSON format using a static dictionary mapping method.

[0050] Step 1.3: Based on the operating system behavior statement knowledge base, label each function entity in the function call structure diagram with a behavior dimension label to generate a semantic label for each node;

[0051] First, for each function entity in the function call structure graph, all function call subsets inside it are extracted.

[0052] Specifically, based on the results of the operating system behavior statement knowledge base, for each function f i ∈F extracts all function subsets inside it, expressed as:

[0053] {c1,c2,…,c m};

[0054] Where m represents the function f i The total number of corresponding function subsets (also called subcalls).

[0055] Then, for each function call subset, if there is a typical function matching it in the operating system behavior statement knowledge base, the function call subset is labeled with the corresponding behavior dimension label, thereby generating a semantic label for each node; among them, if a function call subset involves multiple behavior dimensions, multiple behavior dimension labels are merged.

[0056] Specifically, for each subcall c j , search the operating system behavior statement knowledge base to see if there is a match, if c j ∈BehaviorMap, then the behavior dimension is marked:

[0057] L(f i )=BehaviorMap(c j );

[0058] Where, L(f i ) represents a function (or node) f i The behavior dimension label of BehaviorMap represents the operating system behavior statement knowledge base function, which realizes the matching of sub-calls and knowledge base.

[0059] If a function involves multiple dimensions, such as calling socket() and fork() at the same time, the labels are merged, that is,

[0060] L(f i )={Net_IO,Proc Comm};

[0061] Finally, in the function call structure graph G = (F, E), for each node f i Attach its corresponding behavior label L(f i ), highlighting the "potential system interaction points" in the static diagram through the behavior label.

[0062] Step 1.4: Combine the function entity set, function call relationship set, and node semantic label set in the function call structure diagram to generate a static program behavior diagram template.

[0063] Finally, the static program behavior graph template obtained by combining the function entity set F, the function call relationship set E, and the node semantic label L in the function call structure graph can be expressed as:

[0064] T s =(F,E,L);

[0065] Where, T s Represents a static program behavior graph template, where the node semantic labels L, also known as node label mappings, reflect the behavioral dimension. This behavior graph template is stored in JSON format. It demonstrates the logical structure of program behavior and provides predictions about the program's dynamic behavior, providing clear focus points and completion paths for subsequent dynamic analysis.

[0066] Step 2: Based on the guidance of the static program behavior graph template, analyze the dynamic behavior of the program, and expand and improve the static program behavior graph template according to the functions that interact with the system behavior, and obtain an extended program behavior graph that integrates static and dynamic.

[0067] Based on the static program behavior graph template constructed in the first step, this embodiment uses dynamic analysis methods to collect and complete the behavior of the program during actual operation according to the guidance of the static analysis results, thereby constructing a behavior graph with a more complete structure and richer semantics. From the analysis scope, path structure to behavioral semantics, it forms a complementary and verification closed loop with the static results.

[0068] Specifically, based on static analysis, dynamic analysis is conducted to capture key behaviors of the program interacting with the operating system during execution, including but not limited to network communication, file reading and writing, memory access, and process communication. By monitoring and supplementing these dynamic behaviors that are difficult to cover with static analysis, the program behavior graph is expanded and improved, ultimately constructing a program behavior model that integrates static and dynamic features.

[0069] Optionally, in this embodiment, step 2 can be implemented according to the following sub-steps 2.1-2.4.

[0070] Step 2.1: Based on the static program behavior graph template, perform instrumentation scope limitation, path planning guidance, and function behavior semantic label expected modeling to guide the dynamic analysis process.

[0071] The core concept of static analysis-guided dynamic analysis is to use the static program behavior graph templates obtained during the static analysis phase to guide the dynamic analysis process. This guidance is primarily reflected in three key aspects: instrumentation scope limitation, path planning guidance, and expected modeling of function behavior semantic labels. These are described below.

[0072] 1. Limitation of the scope of pile insertion

[0073] Specifically, the dynamic instrumentation phase needs to accurately monitor the key points where the program interacts with the external system environment during runtime to reduce unnecessary performance overhead.

[0074] This embodiment uses the function entity set F and the node semantic label set L in the static program behavior graph template to implement dynamic instrumentation only in the nodes with behavior labels and their important call paths, and obtains the instrumented node set, which is recorded as:

[0075]

[0076] Where, F * Represents a collection of instrumented nodes. Represents the empty set.

[0077] By precisely limiting the scope of instrumentation, the overhead of dynamic analysis can be made manageable and the analysis more effective.

[0078] 2. Path Planning Guidance

[0079] Specifically, since a program may involve a large number of path combinations during actual operation, dynamic monitoring of all possible paths will result in huge overhead and complexity. Therefore, this embodiment uses the function call structure diagram in the static program behavior graph template to plan a clear priority path for dynamic behavior monitoring, which is recorded as:

[0080] Path dynamic ={f start →f i →…→f end ∣(f i ,f j )∈E,f i ,f j ∈F *};

[0081] Where, Path dynamic represents the priority path for dynamic behavior monitoring, f start Indicates the starting node of the path, f end Indicates the end node of the path.

[0082] Through path planning guidance, the analysis investment on redundant paths or low-risk paths can be reduced, and the accuracy and efficiency of dynamic monitoring can be improved.

[0083] 3. Expected Modeling of Function Behavior Semantic Labels

[0084] Based on the node semantic label set in the static program behavior graph template, a function behavior expectation model is constructed to clarify the possible interaction behavior types between the function and the system, and use it as the basis for judgment of anomaly analysis.

[0085] Specifically, the static behavior graph template assigns clear behavioral semantic labels L to function nodes. These semantic labels reflect the types and modes of interactions that the program may have with the operating system during runtime. In the dynamic analysis phase, these labels can be used as expected behavior models.

[0086] Behavior expected (f i )=L(f i ),f i ∈F * ;

[0087] During the dynamic instrumentation process, specific types of system interaction behaviors can be clearly monitored. If the behaviors captured at runtime are inconsistent with the static annotations, or if new unlabeled behavior types appear, they will be immediately regarded as potential abnormal behaviors, thereby guiding dynamic analysis to further focus and troubleshoot.

[0088] Step 2.2: Based on the guidance of the static program behavior graph template, perform dynamic analysis on typical function nodes, capture dynamic behavior events during program execution, obtain new functions and new call paths, and complete the function call structure diagram in the static program behavior graph template.

[0089] First, according to the node semantic labels marked in the static program behavior graph template, the functions with system interaction behavior labels are screened and their entry points or key call locations are determined as the insertion points, that is,

[0090]

[0091] P instrument ={entry(f i ),callsite(c j )|f i ∈F * ,c j ∈Body(f i )};

[0092] Where, entry(f i ) represents the function f i The entrance position, callsite(c j ) indicates the location where the system function is called in the function body, and the set of insertion points P instrument As the entry point for subsequent monitoring.

[0093] Then, during program execution, when the control flow hits an instrumentation point, it is recorded as a dynamic behavior event, and all collected dynamic behavior events are grouped into a set.

[0094] Specifically, when the control flow hits the instrumentation point, the following dynamic behavior events are recorded:

[0095] e k =(f k ,L(f k ),t k ,ctx k );

[0096] Among them, f k Indicates the function node that triggers the behavior, L(f k ) represents the expected behavior label of the function, t k Indicates the timestamp of function triggering, ctx k Represents runtime context information. All collected events are grouped into a set, i.e.

[0097] ε={e1,e2,…,e K};

[0098] Where K represents the total number of dynamic behavior events.

[0099] Then, based on the timestamp t in the dynamic behavior event k and context information ctx k , restore the function call path in the calling order to form a dynamic path set, recorded as:

[0100]

[0101] Finally, the actual function edges are extracted based on the dynamic path set to complete the function call structure diagram in the static program behavior graph template.

[0102] Among them, the actual function edge is expressed as:

[0103] E dynamic ={(f i ,f j )|f i f is called during operation j};

[0104] These edges complete the control flow that is missed in the static program behavior graph template due to conditional branches, function pointers, etc.

[0105] Step 2.3: Parse and extract system interaction behavior events from the dynamic behavior event set as system interaction behavior nodes, and expand them into the static program behavior graph template.

[0106] First, based on the context information contained in each dynamic behavior event in the dynamic behavior event set, the system interaction behavior events are parsed and extracted.

[0107] Specifically, in the dynamic behavior event set collected during the dynamic analysis phase,

[0108] ε={e k =(f k ,L(f k ),t k ,ctx k )};

[0109] Among them, some events k The context contained in ctx k The underlying system behavior caused by the program will be explicitly or implicitly recorded in the system, such as system call name, behavior parameters, kernel log or API interception return value and other information. Through these running data, a set of system interaction behavior events can be parsed and extracted, recorded as

[0110]

[0111] Among them, type j ∈{File_RW,Net_IO,Mem_Access,Proc_Comm}, args j Indicates the key parameters of the behavior.

[0112] Then, based on the dimension mapping function of the system interaction behavior, for each system interaction behavior event, find the dimension to which its type belongs, and clarify the behavior dimension label of each system interaction behavior event.

[0113] Specifically, for each Find the dimension to which its type belongs:

[0114]

[0115] Next, the system interaction behavior events are converted into system interaction behavior nodes in the program behavior graph, and an association edge is established between the system interaction behavior nodes and the function nodes that trigger the behavior in the source code.

[0116] The system interaction behavior analyzed above is converted into the system behavior node set in the program behavior graph, that is,

[0117]

[0118] And establish its connection with the function node f that triggers the behavior in the source code i The associated edge of

[0119]

[0120] in, represents f i The operation behavior of the system leads to the system behavior s in terms of time and logic. j The occurrence of an event is determined by the call stack, argument association, or temporal proximity.

[0121] Finally, the system interaction behavior nodes and their corresponding behavior dimension labels are extended to the static program behavior graph template, that is,

[0122]

[0123] Where, F sys A node set representing the expanded system interaction behavior.

[0124] Step 2.4: Merge the function entity nodes in the static program behavior graph template with the new function obtained in step 2.2 and the system interaction behavior nodes obtained in step 2.3 to form a complete node set; and merge the function call structure diagram in the static program behavior graph template, the new call path obtained in step 2.2, and the behavioral causal relationship between the program and the system to obtain an extended program behavior graph that is a fusion of static and dynamic.

[0125] Specifically, the function node set F extracted in the static analysis phase is combined with the newly added function nodes F identified in the dynamic acquisition phase. dynamic , and the node set F obtained by expanding the system interaction behavior sys Merge to get the complete node set, that is

[0126] F ′ =F∪F dynamic ∪F sys ;

[0127] Among them, F represents the static source code function node, F dynamic Indicates the newly discovered function calls in dynamic collection, F sys Indicates the system-level behavior node triggered by the program during operation.

[0128] After the node set is fused, the calling relationship between functions and the causal relationship between programs and system behaviors are then structurally merged to form a complete edge set, i.e.

[0129] E ′ =E∪E dynamic ∪E causal ;

[0130] Among them, E represents the call edge between static functions, E dynamic Indicates a new call path triggered at runtime, E causal Indicates the triggering or dependency relationship between source code function nodes and system behavior nodes.

[0131] The behavioral dimension labels of all nodes also need to be merged and updated to form a unified label mapping, that is,

[0132] L ′ =L∪L dynamic ∪L sys ;

[0133] Among them, L represents the statically labeled system interaction label, L dynamic Indicates the node label newly identified in dynamic operation, L sys Indicates the type of the system behavior node.

[0134] Finally, a complete extension behavior graph is constructed, which is recorded as

[0135] T ext =(F ′ ,E ′ ,L ′ );

[0136] The graph has the following characteristics: the nodes cover all observable functions and system interactions during the static and dynamic execution of the program; the edge structure fully expresses the control flow, call logic and operation causality; and the label information reflects the semantic distribution of system behavior and risk areas.

[0137] The extended program behavior graph constructed in this embodiment is stored in a structured form of JSON, so that the program dynamic behavior analysis can be performed later based on the program extended behavior graph.

[0138] The present invention adopts a method of guiding dynamic analysis by static analysis results. By limiting the scope of instrumentation and guiding path analysis, it avoids excessive analysis of redundant paths and low-risk paths, reduces the computational overhead in the dynamic analysis process, and improves the efficiency of the system.

[0139] Step 3: Dynamically analyze the program running process based on the extended program behavior graph, detect in real time whether the program deviates from the expected running state, and cluster and chain identify abnormal behaviors.

[0140] This embodiment uses an extended program behavior graph constructed through a fusion of static and dynamic methods to track the behavior path and analyze the characteristics of the program during execution. By matching the actual execution behavior with the structures and nodes in the behavior graph, it can identify abnormal behavior patterns and potential security risks, enabling accurate modeling, monitoring, and analysis of the program's dynamic behavior, providing support for applications such as security testing and performance evaluation.

[0141] In this step, the program dynamic analysis based on the behavior graph uses the program behavior graph T ext =(F ′ ,E ′ ,L ′ ) as the analysis benchmark, tracking the program's execution path in real time to determine whether it deviates from structural and semantic expectations, and clustering and chaining abnormal behaviors. This process works in parallel with the expansion of the behavioral graph structure, building a self-enhancing "model-while-analyzing" analysis system. The analysis process primarily includes the following four key steps: 3.1-3.4.

[0142] Step 3.1: During program execution, continuously collect function calls and their corresponding system behaviors through instrumentation, construct a program behavior path sequence, and map it to the expected path in the extended program behavior graph.

[0143] Specifically, the system continuously collects function calls and their corresponding system behaviors through instrumentation, and the constructed behavior path sequence is expressed as follows:

[0144]

[0145] The path is immediately mapped to the current behavior graph structure and checked for consistency with the path structure in the graph. This process has the following characteristics: dynamic paths can be analyzed in any sampling window, without waiting for program execution to complete; nodes and edges must exist in the graph and be in a valid order to be considered a "structurally consistent" path; the behavior dimension also serves as the basis for semantic mapping, supporting subsequent label consistency checks.

[0146] Step 3.2: Compare the actual execution path with the expected path in the extended program behavior graph to identify whether the current actual execution path is abnormal, and collect the corresponding abnormal node, edge deviation, and semantic deviation information.

[0147] Specifically, during the path mapping process, the system performs a structural and semantic deviation analysis, comparing the actual execution path with the expected path in the program behavior graph, and identifying the following three types of deviations:

[0148] a. Node deviation, also known as abnormal node: a function f in the path i Not included in the current graph structure F ′ ;

[0149] b. Edge deviation: Function call edges not recorded in the graph appear in the call sequence (f i ,f j );

[0150] c. Semantic deviation: The system behavior triggered by a function when running is inconsistent with the behavioral dimensions marked in its diagram, that is:

[0151]

[0152] Once any of the above deviations occur, the current path It is marked as an abnormal path, and the corresponding abnormal nodes, edges and semantic offset information are collected.

[0153] Step 3.3: Classify and aggregate abnormal nodes based on the system interaction behavior dimensions triggered at runtime to assist in determining whether the current abnormal behavior has a systematic bias.

[0154] In this embodiment, based on the system interaction behavior dimensions triggered by abnormal function nodes during runtime, they are classified and aggregated to identify whether the anomalies are concentrated in a certain type of behavior pattern, such as network communication (Net_IO), file access (File_RW), memory management (Mem_Access) or process control (Proc_Comm).

[0155] Specifically, first, for each abnormal node f i ∈F abnormal ∪F semantic_deviation , obtain the behavioral dimension label L observed at runtime obs (f i ).

[0156] Then, according to the predefined behavior classification system, all abnormal nodes with the same behavior label are classified into the same cluster to form a dimensional clustering result, which is recorded as:

[0157] Cluster k ={f i ∣L obs (f i )=l k},

[0158] l k ∈{File_RW,Net_IO,Mem_Access,Proc_Comm};

[0159] The clustering results can be used to assist in determining whether the current abnormal behavior has a systematic bias (for example, a high proportion of abnormal behavior is concentrated in network access behavior), thereby providing a dimensional perception basis for response strategy decisions.

[0160] Step 3.4: Build an abnormal behavior chain based on time sequence or control flow logic to identify whether multiple abnormal nodes constitute a high-risk complex attack process.

[0161] In order to reveal the causal path and potential attack chain between abnormal behaviors, on the basis of dimensional clustering, we further construct an abnormal behavior chain based on time sequence or control flow logic to represent the execution order of a group of related abnormal function nodes during program running.

[0162] First, the current actual execution path All abnormal nodes in the path are extracted in sequence according to their position in the path, and abnormal function subsequences are constructed to form an abnormal behavior chain, which is recorded as:

[0163]

[0164] Then, the abnormal behavior chain is processed and analyzed by setting the chain length threshold, filtering out noise nodes, and judging whether the chain spans multiple behavioral dimensions. In addition, the function parameter characteristics, thread context, and system call parameter information are combined to identify whether multiple abnormal nodes constitute a high-risk compound attack process.

[0165] By processing and analyzing abnormal behavior chains, it is possible to effectively identify whether there is a common cause path between multiple abnormal nodes and whether it constitutes a high-risk complex attack process.

[0166] The present invention provides a method for program behavior association monitoring and dynamic analysis guided by static analysis. First, the program source code is analyzed using static analysis technology to construct a static program behavior graph template. Then, under the guidance of the static program behavior graph template, the program dynamic behavior is analyzed, and the static program behavior graph template is expanded and improved through the functions involved in interacting with the system behavior to obtain an extended program behavior graph that integrates static and dynamic. Finally, based on the extended program behavior graph, the program running process is dynamically analyzed to detect in real time whether the program deviates from the running expectation, and abnormal behavior is clustered and chained. This method pre-analyzes the function call graph of the program source code through static analysis, and then annotates the functions involved in interacting with the system behavior based on the guidance of the static program behavior graph template, so as to know in advance which dimensions of behavior will occur during the dynamic operation of the program, and monitor and collect behavior information during dynamic analysis, thereby achieving comprehensive collection of program behavior information in various dimensions; at the same time, the collected behavior information is abstracted into behavior nodes and expanded into the program behavior graph, realizing the systematic construction of program behavior, so that the behavioral characteristics of the program can be comprehensively analyzed, the accuracy and reliability of the analysis results can be improved, which is conducive to developers to accurately identify potential threats, thereby improving the security and stability of the system.

[0167] In addition, this method adopts a parallel execution mechanism of graph expansion and analysis, which can expand the behavior graph in real time during program execution and perform anomaly detection based on the behavior graph, thereby identifying potential abnormal behaviors in the shortest time without waiting for the complete program execution, with high real-time and high efficiency.

[0168] The above is a further detailed description of the present invention in conjunction with specific preferred embodiments, and the specific implementation of the present invention should not be considered to be limited to these descriptions. For those skilled in the art of the present invention, without departing from the concept of the present invention, several simple deductions or substitutions can be made, which should be considered to fall within the scope of protection of the present invention.

Claims

1. A static analysis-guided program behavior correlation monitoring and dynamic analysis method, characterized in that: include: Step 1: Use static analysis technology to analyze the function call structure diagram of the program source code, and build a static program behavior diagram template in combination with the operating system behavior statement knowledge base; Step 2: Based on the guidance of the static program behavior graph template, analyze the dynamic behavior of the program, and expand and improve the static program behavior graph template according to the functions that interact with the system behavior, to obtain an expanded program behavior graph that integrates static and dynamic behavior. Step 3: Dynamically analyze the program running process based on the extended program behavior graph, detect in real time whether the program deviates from the expected running state, and perform clustering and chain identification on abnormal behaviors.

2. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 1, characterized in that: Step 1 includes: Step 1.1: Parse the program source code, extract function entities and function call relationships, and construct a function call structure graph with function entities as nodes and function call relationships as edges; Step 1.2: Build an operating system behavior statement knowledge base based on the operating system's library functions; Step 1.3: Based on the operating system behavior statement knowledge base, label each function entity in the function call structure diagram with a behavior dimension label to generate a semantic label for each node; Step 1.4: Generate a static program behavior graph template by combining the function entity set, function call relationship set, and node semantic label set in the function call structure graph.

3. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 2, characterized in that: Step 1.2 includes: Extract typical behavior categories and corresponding typical functions based on the operating system's library functions, and construct a basic classification system table; the basic classification system table includes four behavior dimensions: file reading and writing, network communication, memory management, and process communication; A mapping table between function names and behavior dimensions is created based on the basic classification system table, thereby constructing an operating system behavior statement knowledge base.

4. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 3, characterized in that: Step 1.3 includes: For each function entity in the function call structure diagram, extract all function call subsets within it; For each function call subset, if there is a typical function matching it in the operating system behavior statement knowledge base, the function call subset is labeled with the corresponding behavior dimension label, thereby generating a semantic label for each node; among them, if a function call subset involves multiple behavior dimensions, multiple behavior dimension labels are merged.

5. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 2, characterized in that: Step 2 includes: Step 2.1: Based on the static program behavior graph template, perform instrumentation scope limitation, path planning guidance, and function behavior semantic label expectation modeling to guide the dynamic analysis process; Step 2.2: Based on the guidance of the static program behavior graph template, dynamic analysis is performed on typical function nodes to capture a set of dynamic behavior events during program execution, and new functions and new call paths are obtained to complete the function call structure diagram in the static program behavior graph template; Step 2.3: Parse and extract system interaction behavior events from the dynamic behavior event set as system interaction behavior nodes, and expand them into the static program behavior graph template; Step 2.4: Merge the function entity nodes in the static program behavior graph template with the new function obtained in step 2.2 and the system interaction behavior nodes obtained in step 2.3 to form a complete node set; and merge the function call structure diagram in the static program behavior graph template, the new call path obtained in step 2.2, and the behavioral causal relationship between the program and the system to obtain an extended program behavior graph that is a fusion of static and dynamic.

6. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 5, characterized in that: Step 2.2 includes: According to the node semantic labels marked in the static program behavior graph template, functions with system interaction behavior labels are screened to determine their entry points or key call locations as insertion points; During program execution, when the control flow hits an instrumentation point, it is recorded as a dynamic behavior event, and all collected dynamic behavior events are grouped together; Based on the timestamp and context information in the dynamic behavior event, restore the function call path in the calling order to form a dynamic path set; Based on the dynamic path set, actual function edges are extracted to complete the function call structure graph in the static program behavior graph template.

7. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 6, characterized in that: Step 2.3 includes: Parsing and extracting system interaction behavior events based on context information contained in each dynamic behavior event in the dynamic behavior event set; Based on the dimension mapping function of system interaction behavior, for each system interaction behavior event, find the dimension to which its type belongs and clarify the behavior dimension label of each system interaction behavior event; Converting the system interaction behavior event into a system interaction behavior node in a program behavior graph, and establishing an association edge between the system interaction behavior node and the function node that triggers the behavior in the source code; The system interaction behavior nodes and their corresponding behavior dimension labels are expanded into the static program behavior graph template.

8. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 1, characterized in that: Step 3 includes: Step 3.1: During program execution, continuously collect function calls and their corresponding system behaviors through instrumentation, construct a program behavior path sequence, and map it to an expected path in the extended program behavior graph; Step 3.2: Compare the actual execution path with the expected path in the extended program behavior graph to identify whether the current actual execution path is abnormal, and collect corresponding abnormal node, edge deviation, and semantic deviation information; Step 3.3: Classify and aggregate the abnormal nodes based on the system interaction behavior dimensions triggered during runtime to assist in determining whether the current abnormal behavior has a systematic bias; Step 3.4: Build an abnormal behavior chain based on time sequence or control flow logic to identify whether multiple abnormal nodes constitute a high-risk complex attack process.

9. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 8, characterized in that: Step 3.3 includes: For each abnormal node, obtain its behavioral dimension label observed during runtime; According to the predefined behavior category system, all abnormal nodes with the same behavior label are classified into the same cluster to form a dimensional clustering result.

10. The method for program behavior correlation monitoring and dynamic analysis guided by static analysis according to claim 8, characterized in that: Step 3.4 includes: Extract all abnormal nodes in the current actual execution path in order of their position in the path, and construct abnormal function subsequences to form abnormal behavior chains; The abnormal behavior chain is processed and analyzed by setting a chain length threshold, filtering noise nodes, determining whether the chain spans multiple behavior dimensions, and combining function parameter characteristics, thread context, and system call parameter information to identify whether multiple abnormal nodes constitute a high-risk composite attack process.

Images