Attack tracing method and device based on symbolic execution engine

Abstract

The invention relates to the technical field of attack tracing, in particular to an attack tracing method and device based on a symbolic execution engine, and the method comprises the steps: recognizing a plurality of dependent explosion functions of a pre-constructed execution unit sequence, so as to construct an independent subprogram; constructing a system call control flow diagram of a historical event processing cycle by combining static and dynamic analysis; auditing logs containing parameter values are collected in the execution period of the target program so as to construct a thread-level traceability graph; and according to the system call control flow diagram, determining whether a node of dependent explosion exists in the thread-level traceability diagram, if so, reconstructing the independent subprogram by using the node of dependent explosion, and analyzing the reconstructed independent subprogram by using a symbolic execution engine to reconstruct an attack path. Therefore, the problem that a related tracing attack method needs to carry out instrumentation on a system, or depends on static analysis, or depends on an unreliable application log, or needs to use additional auxiliary hardware to realize tracking is solved.

Description

Technical Field

[0001] This invention relates to the field of attack attribution technology, and in particular to an attack attribution method and apparatus based on a symbolic execution engine. Background Technology

[0002] As cyberattacks become increasingly sophisticated and covert, enterprises and critical infrastructure face continuous threats, leading to serious data breaches and financial losses. Attackers often remain lurking in target systems for extended periods, making post-incident investigation—tracing intrusion paths to pinpoint the root cause—a critical challenge in the cybersecurity field.

[0003] A mainstream approach to attack investigation is to use a source graph based on system audit logs. This method represents system entities such as processes and files as nodes, and their causal dependencies as edges. Analysts then perform forward and backward tracing on this graph to reconstruct the attack chain, pinpoint the root cause, and determine the full scope of the event's impact.

[0004] Traditional source graph analysis typically assumes that the output of a node depends on all its historical inputs, an assumption that leads to the well-known dependency explosion problem. This problem is particularly pronounced for long-running processes such as databases and web servers.

[0005] To alleviate this problem, existing research has proposed the method of Execution Unit Partitioning (EUP). For example... Figure 1 As shown in (a), EUP divides a thread into a series of execution units (U1, U2, ..., U...). n This restricts dependencies to their respective execution units. Through this transformation, a simplified one-to-one dependency pattern (I...) can be obtained. i →O i This pattern has been effectively addressed in previous studies.

[0006] for Figure 1(b) illustrates a more complex scenario where the core challenge lies in establishing input-output dependencies between Thread1 and Thread2. Existing methods can be broadly categorized into two types: (1) establishing dependencies between thread-level execution units (as shown by the dashed arrows in the figure); and (2) directly identifying dependencies between the inputs and outputs of two threads (i.e., establishing dependencies between Input i and Output j). For the first type of method, since cross-thread dependencies cannot be directly recovered from audit logs, additional auxiliary information is required. For example, BEEP uses instrumentation to capture cross-execution unit dependencies; Ma et al. infer dependencies between execution units by dividing audit logs into semantically consistent phases, thereby inferring inter-unit relationships without modifying application code; and Alchemist uses application logs to infer and establish these cross-thread relationships. For the second type of method, Rtag combines record-replay mechanisms with taint analysis to reconstruct the data flow between inputs and outputs; while Palantír uses hardware-assisted tracing (such as Intel PT) and static taint analysis to determine these input-output dependencies.

[0007] An efficient attack attribution system needs to meet several key requirements to balance practicality and broad applicability. 1) It should be instrumentation-free to improve versatility and facilitate deployment in real-world environments; 2) It must suppress spurious dependencies under complex execution models to provide high-precision dependency analysis results; 3) It should maintain platform independence, avoiding reliance on auxiliary hardware or additional logging mechanisms to ensure good adaptability in heterogeneous operating environments. However, existing methods cannot simultaneously meet all of these requirements. Some methods rely on instrumentation; some are based on static analysis, which cannot observe runtime data flow, leading to inaccurate dependency results; and others rely on unreliable application logs or hardware-assisted tracing, which not only limits cross-platform portability but also weakens the generality of the methods.

[0008] The logic of modern applications can be abstracted as an "input-computation-output" model, where the computation phase is responsible for establishing dependencies between inputs and outputs. Therefore, if the computational logic can be decoupled from the system environment, input-output dependencies can be accurately identified based solely on the computation itself. However, in concurrent programs, this logic is often very complex. For example... Figure 1 As shown in (c), a single "computation" may involve multiple functions distributed across different threads and executed iteratively. An input might be processed first by thread 1, then passed to thread 2 for further processing, ultimately producing an output, thus creating a many-to-many dependency that obscures the actual data flow (corresponding to...). Figure 1(The dashed arrow in (b)). The core idea is that if this kind of distributed logic can be extracted and reconstructed into a serial subroutine, symbolic execution can be used to resolve these uncertainties. For example, mapping relationships such as "Input 1 corresponds to Output 2" and "Input 2 corresponds to Output n" can be precisely established. Although this idea is intuitively natural, its implementation faces the following challenges: Challenge 1: Computation Module Construction. How to locate, extract, and refactor the core logic that leads to dependency explosion, transforming it into an independent, analyzable, sequential subroutine.

[0009] Challenge 2: Comprehensive I / O Capture. How to comprehensively capture the specific values ​​of all inputs and outputs during program execution.

[0010] Challenge 3: Dependency Analysis. How to accurately map the captured runtime values ​​to the inputs and outputs of the computation modules, and rigorously derive and confirm the resulting dependencies through symbolic execution. Summary of the Invention

[0011] This invention provides an attack tracing method and apparatus based on a symbolic execution engine to solve problems such as the need for related tracing attack methods to instrument the system, rely on static analysis, depend on unreliable application logs, or require additional auxiliary hardware to achieve tracing.

[0012] A first aspect of this invention provides an attack tracing method based on a symbolic execution engine, comprising the following steps: Construct the execution unit sequence of the target historical event processing loop and identify multiple dependency explosion functions of the execution unit sequence to construct independent subroutines; construct the system call control flow graph of the target historical event processing loop by combining static and dynamic analysis; collect audit logs containing parameter values ​​during the execution of the target program to construct a thread-level tracing graph; The system call control flow graph is used to determine whether there are nodes with dependency explosion in the thread-level source graph. If there are nodes with dependency explosion, the independent subroutine is reconstructed using the nodes with dependency explosion, and the reconstructed independent subroutine is analyzed using a symbolic execution engine to reconstruct the attack path.

[0013] Optionally, the step of constructing a sequence of execution units for processing target historical events and identifying multiple dependency explosion functions of the sequence of execution units to construct independent subroutines includes: The target historical event processing loop is divided into stages to obtain multiple stages, and multiple core logs are obtained from the multiple stages. The recurring event patterns in the multiple core logs are analyzed to characterize the finite state machine of a single execution unit structure; The finite state machine is used to convert a continuous log stream into a discrete, ordered sequence of execution units; Identify multiple dependency explosion functions in the execution unit sequence and analyze the dependency relationships between the multiple dependency explosion functions to form a set of dependency function pairs; Based on the program slicing method, independent subroutines that can be used for symbolic execution are constructed from the set according to the dependent functions.

[0014] Optionally, the process of constructing the system call control flow graph of the target historical event processing loop by combining static and dynamic analysis includes: Obtain the fused static and dynamic information of the target historical event processing loop, and construct a hybrid control flow graph using the fused static and dynamic information; The hybrid control flow graph is pruned and normalized to generate the system call control flow graph.

[0015] Optionally, the step of collecting audit logs containing parameter values ​​during the execution of the target program to construct a thread-level tracing graph includes: A dual data collection strategy is employed to collect audit logs containing parameter values ​​during program execution; The thread-level source graph is constructed based on the audit log containing parameter values. The master nodes in the thread-level source graph adopt a hierarchical structure, and the directed edges in the thread-level source graph represent system events, with their directions indicating data flow or control flow.

[0016] Optionally, determining whether there are dependency explosion nodes in the thread-level source graph based on the system call control flow graph includes: Locate the corresponding loop unit in the thread-level source graph and extract the system call sequence in the loop unit; The system call sequence is matched with the system call control flow graph to identify the program entry function; The program entry function performs node identification in the independent subroutine to determine whether there are nodes with dependency explosion.

[0017] Optionally, in the case of nodes with the dependency explosion, the independent subroutine is reconstructed using the nodes with the dependency explosion, and the reconstructed independent subroutine is analyzed to reconstruct the attack path, including: Based on the indexing mechanism, the dependency explosion subroutines corresponding to the nodes of the dependency explosion are retrieved and extracted from the pre-built independent subroutine database. Identify the input and output parameter values ​​in the dependent explosion subroutine; The input and output parameter values ​​are then filled back into the independent subroutine to obtain the reconstructed independent subroutine. The reconstructed independent subroutines are analyzed using a symbolic execution engine to reconstruct the attack path.

[0018] A second aspect of the present invention provides an attack tracing device based on a symbolic execution engine, comprising: A program module is constructed to build a sequence of execution units for processing target historical events and to identify multiple dependency explosion functions of the sequence of execution units in order to construct independent subroutines. A control flow graph construction module is used to construct the system call control flow graph of the target historical event processing loop by combining static and dynamic analysis. The source graph construction module is used to collect audit logs containing parameter values ​​during the execution of the target program in order to build a thread-level source graph; The determination module is used to determine whether there are nodes with dependency explosion in the thread-level tracing graph based on the system call control flow graph; The refactoring and analysis module is used to refactor the independent subroutine using the nodes of the dependency explosion when such nodes exist, and to analyze the refactored independent subroutine using a symbolic execution engine in order to reconstruct the attack path.

[0019] A third aspect of the present invention provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the attack tracing method based on the symbolic execution engine as described in the above embodiments.

[0020] A fourth aspect of the present invention provides a computer program product that, when executed by a processor, implements the above-described attack tracing method based on a symbolic execution engine.

[0021] A fifth aspect of the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described attack tracing method based on a symbolic execution engine.

[0022] The attack tracing method and apparatus based on symbolic execution engine proposed in this invention first identifies the functions that lead to dependency explosion and reconstructs them into independent subroutines through program slicing. Simultaneously, a system call control flow graph is constructed by combining static and dynamic analysis to accurately map runtime values ​​to variables in the source code during subsequent processes. During the actual program execution phase, the framework records all system calls and their parameter values ​​to construct a thread-level tracing graph, ensuring complete capture of system call parameters. When a node with dependency explosion is found in the tracing graph, its corresponding subroutine is located. The runtime-collected values ​​are mapped back to code variables using the system call control flow graph, and symbolic execution analysis is performed on the subroutine to accurately deduce input and output dependencies, thereby reconstructing the attack path.

[0023] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0024] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 The diagrams are schematics of traditional program execution models, where (a) is a single-threaded, sequential execution model, (b) is a complex execution model involving inter-thread interaction, and (c) is a program where functions are distributed between two cooperating threads. Figure 2 This is a schematic diagram illustrating the overall framework of an attack tracing method based on a symbolic execution engine according to an embodiment of the present invention. Figure 3 A flowchart illustrating an attack tracing method based on a symbolic execution engine according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating an example of httpd source code provided according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a causal relationship analysis survey based on the DFP algorithm according to an embodiment of the present invention; Figure 6 This is a schematic diagram of an algorithm 2 for tracking control flow matching according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a DFP node according to an embodiment of the present invention; Figure 8 This is a schematic diagram illustrating a modification of the DFP subroutine of Algorithm 3 according to an embodiment of the present invention; Figure 9 This is a schematic diagram illustrating a case study of the evaluation of the value of 15 types of projects and their courses according to an embodiment of the present invention; Figure 10 This is a schematic diagram of an attack investigation and evaluation index provided according to an embodiment of the present invention; Figure 11 This is a schematic diagram illustrating the evaluation of system performance and overhead across 15 applications according to an embodiment of the present invention. Figure 12 This is a schematic diagram of the runtime overhead of SPEC CPU 2006 according to an embodiment of the present invention; Figure 13 This is a schematic diagram of CPU runtime overhead provided according to an embodiment of the present invention; Figure 14 A block diagram illustrating an attack tracing device based on a symbolic execution engine according to an embodiment of the present invention; Figure 15 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention.

[0025] Explanation of reference numerals in the attached figures: 140 - Attack tracing device based on symbolic execution engine, 1401 - Construction program module, 1402 - Control flow graph construction module, 1403 - Source graph construction module, 1404 - Determination module, 1405 - Reconstruction and analysis module, 1501 - Memory, 1502 - Processor and 1503 - Communication interface. Detailed Implementation

[0026] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0027] The following describes an attack tracing method and apparatus based on a symbolic execution engine according to embodiments of the present invention, with reference to the accompanying drawings. Addressing the problems mentioned in the background art regarding related attack tracing methods that require system instrumentation, static analysis, unreliable application logs, or additional auxiliary hardware for tracing, the present invention provides an attack tracing method based on a symbolic execution engine, such as... Figure 2As shown, this method unfolds in three stages: The first stage is offline preparation, which prepares two key components. First, this embodiment of the invention constructs a system call-aware control flow graph (Syscall CFG) by generating, aligning, and merging the static and dynamic control flow graphs (CFGs) of the software, retaining only system call nodes. Simultaneously, this embodiment of the invention analyzes execution logs to identify dependency explosion functions (DEFs) and dependency function pairs (DFPs). For each DFP, a self-executable DFP subroutine is extracted using program slicing techniques and stored in a database. This operation separates the DFP from the complex control flow and equips it with the logic required for independent execution. The second stage is runtime monitoring. During program execution, we collect system audit logs to construct a thread-level source graph. This log data, including detailed parameters, is structured and stored in a parameterized system call log database for later use. The final stage is attack investigation. Once an anomaly is detected, it is first determined whether the relevant node is a DFP explosion node. If so, the corresponding DFP subroutine is retrieved, its input / output parameter values ​​are identified from the log database, and these values ​​are integrated into the subroutine to create a version ready for concolic execution. This process addresses the dependency explosion problem by enumerating input-output matches to establish a mapping from inputs to malicious outputs. For non-DFP nodes, traditional forward and backward analysis is performed using Causality Tracker. This process is repeated until the investigation is complete.

[0028] Specifically, Figure 3 This is a flowchart illustrating an attack tracing method based on a symbolic execution engine, provided in an embodiment of the present invention.

[0029] like Figure 3 As shown, this attack tracing method based on the symbolic execution engine includes the following steps: In step S301, an execution unit sequence of the target historical event processing loop is constructed, and multiple dependency explosion functions of the execution unit sequence are identified to construct independent subroutines.

[0030] In some embodiments, a sequence of execution units for a target historical event processing loop is constructed, and multiple dependency explosion functions of the execution unit sequence are identified to construct independent subroutines, including: The target historical event processing loop is divided into stages to obtain multiple stages, and multiple core logs are obtained from multiple stages. The event patterns that recur in multiple core logs are analyzed to characterize the finite state machine of a single execution unit structure; A finite state machine is used to convert a continuous log stream into a discrete, ordered sequence of execution units. Identify multiple dependency explosion functions in the execution unit sequence and analyze the dependency relationships between these functions to form a set of dependency function pairs; Based on the program slicing method, independent subroutines that can be used by symbolic execution are constructed from the set according to the dependency functions.

[0031] In actual execution, this embodiment of the invention defines an execution unit as: a set of system calls executed by a thread in one event processing loop (e.g., retrieving and processing a task from a queue) and the corresponding logs generated therein. It should be noted that a complete external request may span multiple such execution units, or even be distributed across multiple threads.

[0032] Specifically, in this embodiment of the invention, the main event processing stage of the target historical event processing loop is first distinguished from and segmented from initialization, termination, and other stages to obtain multiple stages. Subsequently, in this core log segment, the event patterns that repeatedly occur across multiple log files are analyzed to construct a finite state machine (FSM) that characterizes the structure of a single execution unit. By applying the trained FSM, this embodiment of the invention can convert a continuous log stream into a discrete, ordered sequence of execution units, where each execution unit corresponds to a complete event processing stage.

[0033] Furthermore, after successfully dividing the execution flow into a sequence of execution units (Units), the analysis granularity delves from the macroscopic thread level to the microscopic Unit level. However, in order to establish causal relationships between cross-thread Units, it is necessary to identify the core functions executed by these Units. To this end, this embodiment of the invention proposes the following two key definitions: Dependency Explosion Function (DEF): A dependency explosion function is a function in a program responsible for managing and scheduling events. Its core characteristic is the implementation of an event handling loop that runs continuously throughout the process's lifecycle. This function typically serves as the main structure for threads to perform their core tasks.

[0034] Dependency Function Pair (DFP): In this embodiment of the invention, a DFP is defined as a pair of DEFs, denoted as...<P_DEF,C_DEF> In this structure, a producer P_DEF and a consumer C_DEF interact through a shared data structure (e.g., a task queue). This pattern is a typical characteristic of dependencies in a Type IV blast scenario. This invention addresses this blast problem by establishing precise correspondences between the producers' and consumers' Units, determining which producer Unit's behavior caused which consumer Unit's response by mapping their respective inputs and outputs.

[0035] In order to systematically identify these DEFs and DFPs in the source code, this invention has summarized a set of heuristic rules for identification based on in-depth analysis of multiple large-scale applications. This invention has found that DEFs usually have the following characteristics: (1) they appear frequently at the end of the common prefix of the call stack; (2) the function body contains an infinite loop that processes the core logic; and (3) the infinite loop is nested at the top or second-to-top level within the function. The characteristic of a DFP is that there is direct data transfer through shared memory between a pair of DEFs that meet the above conditions.

[0036] like Figure 4 As shown, this embodiment of the invention uses the httpd source code to illustrate these concepts. The server_main_loop, as well as the listener_thread and worker_thread created in child processes, are all identified as DEFs because they contain top-level infinite loops that handle core tasks. Furthermore, since the listener_thread is responsible for writing requests to the shared task queue worker_queue, and the worker_thread is responsible for reading from it, these two DEFs interact directly through shared memory. Therefore, this embodiment of the invention identifies...<listener_thread, worker_thread> This constitutes a typical Dependency Explosion (DFP). This DFP is the core analysis target for subsequent symbolic execution in this embodiment of the invention to solve the dependency explosion problem.

[0037] Specifically, the Dynamic Function Trace Analyzer (DFTA) is first used to identify dependency function pairs (DFPs) associated with dependency explosion. Then, subprograms are constructed around these DFPs to eliminate complex execution models such as multithreading and multiprocessing at the subprogram level. Based on these DFP subprograms, symbolic execution effectively mitigates the nondeterminism introduced by concurrency and significantly reduces the path space.

[0038] DFP identification is divided into two steps: (1) identifying Dependency Explosion Functions (DEFs); (2) analyzing the dependencies between DEFs to assemble a set of DFPs. During DFTA training, eBPF probes are attached to function entry points and system call entry points to capture call sequences associated with each input in real time. Subsequently, statistical analysis is performed on the call sequence prefixes; for functions that frequently appear at the end of common prefixes, further static analysis is performed to detect internal loops and measure nesting depth. If a function continuously drives application logic (e.g., the main scheduling loop or the global entry point of a long-running service) and its internal loop nesting depth does not exceed 2, it is marked as a DEF. To characterize the relationships between DEFs, the Abstract Syntax Tree (AST) is parsed, and the declaration and usage locations of shared memory are enumerated. Such shared memory is usually represented as a struct or class container (array, linked list, circular buffer, etc.) and is equipped with dedicated enqueue / dequeue routines. Subsequently, taint analysis is performed on each DEF and its called functions, all read and write operations on these shared regions are collected, and the interaction results are stored in a mapping structure. Based on this, the dependencies between DEFs are constructed using shared memory as a medium, ultimately obtaining the DFP set.

[0039] After obtaining the DFP set, we focus on the computation modules corresponding to these DFPs and construct independent subroutines that can be used by symbolic execution. A pipeline with three stages is proposed: dynamic path localization, static dependency completion, and concurrent sequentialization. While preserving readability and reproducibility as much as possible, the symbolic search space is minimized. (1) Dynamic path localization. Using the analysis results based on DFTA and the Valgrind-callgrind traces collected during training, the source code lines and functions that trigger dependency explosion are accurately marked. Then, branches that have never been executed are pruned according to the execution frequency, as well as exception handling and debugging paths, to reduce invalid path exploration. (2) Static dependency completion. Through the mapping from source code to binary, the required header files, structure definitions, and declarations and initializations of global / local variables are automatically collected. Context dependencies (including global variables, constants, and configuration items) are parsed and completed. Conditional compilation and macro expansion are handled to introduce missing definitions. Placeholders for callbacks or registered logic outside of slices are synthesized. Third-party libraries and system APIs are imported according to the call relationship. Finally, the header file and global definitions are placed at the top of the file, functions are arranged in the observed call order, and local declarations are kept near the actual execution line, thus generating a self-contained DFP subroutine. (3) Concurrency Sequencing. Thread / process creation and synchronization primitives (such as pthread_create, fork, mutexes, condition variables, semaphores, and atomic operations) are statically examined, and the "removal and linearization" transformation is applied to convert concurrent behavior into an equivalent single-threaded model. This transformation eliminates the temporal ambiguity caused by concurrent scheduling without changing the key semantics, and significantly improves the efficiency and robustness of symbolic execution.

[0040] In step S302, a system call control flow graph of the target historical event processing loop is constructed by combining static and dynamic analysis.

[0041] In some embodiments, a system call control flow graph for the target historical event processing loop is constructed by combining static and dynamic analysis, including: Acquire the fused static and dynamic information of the target historical event processing loop, and construct a hybrid control flow graph by fusing the static and dynamic information; The hybrid control flow graph is pruned and normalized to generate a system call control flow graph.

[0042] In actual execution, firstly, a hybrid control flow graph (Hybrid CFG) is constructed by integrating static and dynamic information; secondly, the graph is pruned and normalized around system calls to generate a system call control flow graph (Syscall CFG).

[0043] In the first phase, to address the limitations of static analysis in capturing dynamic features such as indirect calls, we enhance the static CFG using dynamic execution trajectories. This process optimizes the representation of indeterminate control flow transfers, generating a hybrid CFG with higher path coverage.

[0044] In the second phase, the hybrid CFG is refined around system calls. Specific refinement operations include: pruning irrelevant paths through correlation analysis, unifying function entry and exit points, and abstracting threads and signal handling into single branches. Furthermore, the internal paths of library functions encapsulating system calls are expanded. This process generates a SyscallCFG that significantly reduces its size while preserving critical path reachability. Compared to path matching on the original full CFG, the Syscall CFG approach effectively alleviates the search space explosion problem caused by irrelevant branches, loops, and function calls. Therefore, this significantly reduces the computational overhead associated with parameter value location and matching.

[0045] In step S303, audit logs containing parameter values ​​are collected during the execution of the target program to construct a thread-level tracing graph.

[0046] In some embodiments, audit logs containing parameter values ​​are collected during the execution of the target program to construct a thread-level tracing graph, including: A dual data collection strategy is employed to collect audit logs containing parameter values ​​during program execution; A thread-level source graph is constructed based on audit logs containing parameter values. The master nodes in the thread-level source graph adopt a hierarchical structure, and the directed edges in the thread-level source graph represent system events, with their directions indicating data flow or control flow.

[0047] In actual execution, after the offline preparation phase is completed, the application's runtime behavior is monitored online, and system calls and their parameter values ​​are continuously collected and written to the database. This database serves as the foundation for building the attribution graph, supporting not only subsequent attack attribution analysis but also providing data support for symbolic execution-related analysis.

[0048] Specifically, a dual data collection strategy is employed, with data collection performed at the kernel level. The primary tool is the open-source utility sysdig, which captures most system call events generated by the target process and its threads. To supplement this and collect unavailable data, such as kernel-generated random values, a custom eBPF probe is deployed. The collected event logs are organized into {(pname, pid, tid)} triples, containing important parameters for variable matching, and sorted by timestamp to maintain the integrity of thread execution. For efficiency, only necessary information is filtered and retained: system call name, timestamp, process and thread identifiers, parameter values, return values, and associated raw data. These structured logs are stored in a dedicated system call log database with parameter values.

[0049] Furthermore, a thread-level source graph was designed based on structured logs to model causal relationships between system entities, represented as subject nodes and object nodes. The subject nodes employ a hierarchical structure, explicitly depicting the parent-child relationships between processes and their threads, thus supporting fine-grained thread-level behavioral analysis. Directed edges in the graph represent system events (e.g., system calls), with their directions indicating data or control flow, and edge attributes encapsulating key metadata such as timestamps and operation types. To meet real-time requirements, an incremental construction strategy is adopted: the system continuously parses newly generated log records and translates them into local atomic operations on the graph (i.e., adding, deleting, and modifying nodes and edges). This approach avoids global reconstruction overhead, maintaining near real-time synchronization between the source graph and the system state, laying the foundation for online source analysis in high-throughput environments.

[0050] In step S304, the existence of a dependency explosion node in the thread-level source graph is determined based on the system call control flow graph.

[0051] In some embodiments, determining whether a dependency explosion node exists in the thread-level source graph based on the system call control flow graph includes: Locate the corresponding loop unit in the thread-level source graph and extract the system call sequence within the loop unit; The system call sequence is matched with the system call control flow graph to identify the program entry function; Node identification is performed in an independent subroutine based on the program entry function to determine whether there are nodes with dependency explosion.

[0052] In actual implementation, the attack tracing method proposed in this embodiment of the invention starts from an abnormal event e0 and performs forward causal analysis (reverse analysis is similar, but forward analysis is used as an example here). The overall process is as follows: Figure 5As shown, the analysis process employs breadth-first search (BFS). For each event, the system call trace of its associated thread is first extracted and matched against the syscall control flow graph (syscall CFG) to locate its corresponding entry function. Then, it is checked whether this function belongs to a dependency function pair (DFP). If a corresponding DFP exists, meaning the event falls on a DFP Explosion Node, the subroutine is converted into a form usable by symbolic execution using the function ModifyDFPSubprogram. This process injects relevant input and output parameter values ​​(I_args and O_args) extracted from the trace. The symbolic execution engine then identifies candidate events causally related to this event. If no DFP is found, the preceding event is retrieved directly from the log. This logic handles the second type (linear) and third type (structured) dependency explosion nodes, defined in the "Process Node Classification" and "Unit Definition and Partition" sections, and its implementation is encapsulated in the system's Causality Tracker module. Finally, the candidate events are screened for legitimacy, and valid candidate events are added to a queue as the starting point for the next iteration. This process is repeated until the source of the attack is located and the complete analysis path is returned.

[0053] Specifically, during the source tracing analysis, it is essential to determine whether a process node is a DFP Explosion Node in order to select an appropriate handling strategy. To support this determination, a three-step identification mechanism is proposed: First, locate the Unit corresponding to the thread from the audit logs; second, identify the program entry function by matching the system call trajectory with the control flow graph; third, consult a pre-built set of Dependency Function Pairs (DFPs) to confirm whether the process node belongs to a DFP Explosion Node. Specifically, this identification process consists of the following three key steps.

[0054] For a given event e, first extract the system call log of the thread that triggered it. This log typically contains multiple execution loops, each referred to as a Unit. Then, pinpoint the specific Unit corresponding to event e and extract the system call sequence of that Unit, denoted as syscall_trace.

[0055] Furthermore, after obtaining the syscall_trace, it is precisely matched with the offline-built syscall control flow graph (syscall CFG). For example... Figure 6As shown, the algorithm first traverses each subgraph in the CFG (line 2). For each subgraph, it initializes the state to the entry node of that subgraph, establishes an air conditioning stack, and sets the index of the system call trajectory (line 3). In the main loop, the algorithm first checks if the current state is a function call node; if so, it pushes the return address onto the call stack (lines 5–7). Then, it calls the FindTransitions function to find matching transition edges for system calls in the current trajectory (line 8). If no matching transition is found (line 9), the algorithm attempts to backtrack by popping the return address from the call stack (lines 10–12); if the call stack is empty, it indicates that matching cannot continue in the current subgraph, and the algorithm ends the matching process for the current subgraph (lines 13–15). Once a valid transition is found, the algorithm updates the current state and increments the trajectory index (line 17). A match is considered successful if and only if all three of the following conditions are met simultaneously: all system calls in the trace have been matched; the current state is at the exit node of the subgraph; and the call stack is empty (lines 19–21). In this case, the function returns True and marks the function corresponding to the subgraph as the thread's entry function. If the current subgraph fails to match, the function continues to try the next subgraph; if all subgraphs fail to match, the function returns False (lines 22–23). Through the above process, the subgraph that precisely corresponds to a given syscall_trace can be located in the syscall CFG, thereby determining the thread's program entry function.

[0056] After identifying the entry function, it is further determined whether the entry function belongs to a pre-built set of Dependency Function Pairs (DFPs), denoted as... P_DEF, C_DEF If the function matches a DFP member, its corresponding process node is marked as a DFP Explosion Node. Otherwise, the node will be analyzed and processed by the Causality Tracker module using traditional methods.

[0057] In step S305, when there are nodes with dependency explosion, the independent subroutines are reconstructed using the nodes with dependency explosion, and the reconstructed independent subroutines are analyzed using the symbolic execution engine to reconstruct the attack path.

[0058] In some embodiments, when nodes with dependency explosions exist, the independent subroutines are reconstructed using these nodes, and the reconstructed independent subroutines are analyzed to reconstruct the attack path, including: Based on the indexing mechanism, the dependency explosion subroutines corresponding to the nodes of dependency explosion are retrieved and extracted from the pre-built independent subroutine database. Identify the input and output parameter values ​​in the dependency explosion subroutine; The input and output parameter values ​​are then filled back into the independent subroutine to obtain the reconstructed independent subroutine. The reconstructed independent subroutines are analyzed using a symbolic execution engine to reconstruct the attack path.

[0059] In actual execution, once the process node associated with the currently analyzed event is confirmed to be a DFP node, the system initiates a dedicated four-stage processing pipeline to perform precise dependency analysis. The first step involves extracting complete DFP subroutines from a pre-built DFP subroutine database. The second step identifies all input and output parameter values ​​involved in the DFP subroutine. The third step populates these parameter values ​​back into the DFP subroutine; this stage includes parameter type inference, symbolic variable binding, and execution context construction, ensuring that all preconditions required for symbolic execution are met. Finally, the symbolic execution engine analyzes the reconstructed DFP subroutine, identifying input edges (predecessor events) with genuine causal dependencies on the currently tracked event (output edge), effectively filtering out a large number of spurious dependencies common in traditional heuristic methods.

[0060] Specifically, after obtaining the DFP name during the DFP node identification phase, the corresponding DFP subroutine is retrieved and extracted from a pre-built DFP subroutine database using an indexing mechanism. This step provides the necessary semantic foundation for subsequent analysis phases.

[0061] By using a "parameter value mapping" strategy, parameter values ​​in kernel-level logs are associated with source code variables, thereby identifying the input and output parameter values ​​of DFP subroutines.

[0062] For output parameter values, the consumer thread's unit is analyzed first. Based on compile-time debugging information and semantic analysis, a precise mapping is established between the parameter values ​​recorded in the system call log (e.g., the file path / path / to / file recorded in the open call) and the corresponding variables in the source code. Through this process, the complete set of values ​​for all output parameters of this subroutine can be obtained.

[0063] For input parameter values, we first need to identify the correct producer thread and then map its parameters. Since the same process may contain multiple producer / consumer threads, we first use a lightweight, pre-trained Transformer model to analyze and classify the system call sequence patterns of all threads, thereby accurately distinguishing the producer thread from other threads. After identifying the producer thread, we divide its complete system call log into periodic Units and apply the same source code mapping method as on the consumer side to each Unit, constructing a candidate set of "all possible input parameter values". This exhaustive process is necessary because at the beginning of the analysis, we do not know which specific Unit of the producer thread has a real causal relationship with the current consumer Unit.

[0064] like Figure 7 As shown, when analyzing process 2, the system must establish the correspondence between each Unit of the producer thread and the Unit of the consumer thread. After locating Consumer Thread Unit 1 through forward analysis, the system matches its audit log with the source code. Assuming that p output variables are identified in the subroutine (C_DEF) corresponding to the consumer thread, a set of output parameter values ​​can be obtained. To address the uncertainty of the input source, the system performs parameter mapping on all Units of the producer thread and maps them to input variables in the source code. Assuming that multiple input variables are matched in the producer subroutine (P_DEF), multiple sets of candidate input parameters will be obtained.

[0065] The collected system call parameter values ​​are integrated into the DFP subroutine, and its code is automatically edited to adapt it for subsequent symbolic execution. For example... Figure 8 As shown, the processing flow is described in detail in Algorithm 3, with the goal of reconstructing a "Symbolic-Execution-Ready Program" that uses assertions to check I / O feasibility. First, the algorithm iterates through the candidate set of input parameters, I_args, creating and inserting enumeration constraints at the beginning of the subroutine, mapping the values ​​recorded in the log to the input parameters in the program (corresponding to lines 3–6 of the algorithm). Second, the algorithm processes the output parameter set, O_args, saving the expected output values ​​(lines 7–9). Finally, assertion statements are automatically generated and appended at the end of the subroutine (line 16). These assertions are generated by a "type-aware" function (lines 11–14) to check whether the output and return values ​​generated by the subroutine during actual execution are consistent with the results observed in the log. Through this automated process, the DFP subroutine is transformed into a form suitable for behavioral verification without the need for manual explicit declaration of symbolic variables.

[0066] Based on the refactored Symbolic-Execution-Ready Program, the final-stage module employs a hybrid symbolic execution strategy (combining concrete execution with symbolic execution) to systematically explore paths and perform reachability analysis for all possible input-output combinations. Leveraging an automated symbolic reasoning mechanism, the system can accurately determine whether each input-output pair is "feasible." In other words, whether a given input can indeed produce the output observed in the logs. Figure 7 As shown, the symbolic execution engine enumerates and verifies the pairing relationships sequentially. Assume the final result shows that in the Symbolic-Execution-ReadyProgram, the input of producer thread Unit 2 can indeed generate the output observed by consumer thread Unit 1. Therefore, using this verification result from the symbolic execution engine, the intra-process dependency between producer and consumer threads can be precisely confirmed within the DFP node, i.e., the causal edge represented by the red dashed arrow in the diagram.

[0067] The attack tracing method based on symbolic execution engine proposed in this invention will be described in detail below through several specific embodiments.

[0068] like Figure 9 As shown, experiments were conducted on 15 applications to evaluate the system's effectiveness in attack investigations. Each application reproduced a real CVE vulnerability to simulate an attack scenario close to reality. For each attack simulation, audit logs were first collected, and a corresponding proof graph was generated. Then, precise attack paths were manually annotated on this graph as "ground truth," used for quantitative comparison with the attack paths automatically identified by the system. The attack paths identified by the system were denoted as investigated_trace.

[0069] Construction and Verification of Ground Truth. When constructing ground truth, starting from the original audit logs, a source graph capable of distinguishing threads is first built. Then, starting from a pre-identified sink event (i.e., attack symptom), a backward breadth-first search (BFS) is manually performed. During this process, all edges leading to the current attack path nodes are iteratively identified, and the source nodes of these edges are manually marked as malicious nodes. Through continuous expansion, the final set of nodes and edges constitutes the real attack path. In the verification experiment, the system uses the exact same audit logs as the manually labeled data and applies a pre-built control flow graph (CFG) to independently generate its own investigated_trace. Experimental results show that in all 15 application scenarios, the system completely reconstructed the real attack path without generating any false positives.

[0070] To verify the system's accuracy in accurately mapping system calls and their parameter values ​​from audit logs back to source code variables, a set of verification experiments based on ground truth annotations was designed. Specifically, the same group of 15 applications used in the previous section were selected and instrumented using the Intel Pin framework. Through this process, a source-level ground truth trace was generated for each application, which accurately recorded the source code file and line number corresponding to each actual system call executed.

[0071] It is important to emphasize that PIN instrumentation on the application is only used to construct the true annotations required for verification; in normal operating mode, the system runs entirely based on standard audit logs and does not rely on any form of instrumentation.

[0072] like Figure 10 As shown, experimental results demonstrate that for all system calls recovered by the system, the corresponding call sites and related variable types are completely consistent with the ground truth generated by Intel Pin. Across all 15 test applications, the system achieved 100% precision and 100% recall in the task of mapping system call parameter values ​​to corresponding source code variables. This result rigorously verifies the high fidelity of the method's source code-level mapping capabilities.

[0073] Storage overhead was evaluated across 15 applications. Since the system collects and stores audit logs on the host machine, static disk usage of log data generated by each application within a 5-minute time interval was measured, and the results are as follows: Figure 11As shown in the figure. In addition, the number of nodes and edges in the system call level control flow graph (syscall CFG) generated for each application is reported to illustrate its relatively small size. The results indicate that the storage footprint of the syscall CFG itself is almost negligible. Overall, the storage requirements of this system are feasible in a real-world deployment scenario.

[0074] The time overhead of the two main computational phases of this system was measured: (1) matching system call parameter values ​​in the logs with code variables; and (2) using symbolic execution to resolve dependencies. Experimental results show that the average time for the parameter value matching phase was 12.05 seconds per application; the time for the symbolic execution phase was significantly lower, averaging only 0.267 seconds, and did not exceed 0.5 seconds in any test case. This low time overhead indicates that the embodiments of the present invention are sufficiently efficient even in high-concurrency environments.

[0075] The runtime overhead of this system was evaluated using the SPEC CPU 2006 benchmark and a set of 15 real-world applications. Specifically, the overhead difference was compared between the experimental system with full sysdig-based data collection enabled and the baseline system with sysdig disabled. For the SPEC benchmark, the full test set was run on both systems; such as... Figure 12 As shown, the average runtime overhead of this embodiment of the invention is 4.81%. For real-world applications, a dedicated script is written to measure CPU utilization within a one-hour window; as... Figure 13 As shown, its average overhead is lower, at only 3.21%. The overall overhead ranges from 0.5% to 11.2%, with the higher overhead mainly coming from some applications with frequent I / O activity, which leads to higher CPU load.

[0076] In summary, the attack tracing method based on the symbolic execution engine proposed in this invention has the following beneficial effects: (1) An automated analysis pipeline was designed to automatically identify functions that cause dependency explosion, model the interactions between these functions, and reconstruct them into self-contained, analyzable computational modules, thereby extracting the core computational logic directly related to input-output dependencies.

[0077] (2) A hybrid analysis method combining static and dynamic methods is proposed, which integrates static control flow graphs with runtime information to construct system call level control flow graphs, thereby achieving high-precision mapping between system call parameter values ​​in logs and source code variables.

[0078] (3) A complete attack tracing framework was designed and implemented: the computing module was extracted and reconstructed in the offline stage, the system calls and their parameters were fully recorded at runtime, and the complex input-output dependency relationship was accurately parsed on the above computing module by symbolic execution in the attack investigation stage, so as to reconstruct the real attack path under the complex execution model of multi-threading and multi-stage.

[0079] (4) Extensive empirical evaluation on 15 CVEs and 3 real attack cases shows that the attack chain can be reconstructed with 100% accuracy without any program instrumentation or auxiliary hardware. In terms of performance, it also shows high efficiency: the average runtime overhead on the SPEC CPU 2006 benchmark is only 4.81%, and the average overhead on typical Linux applications is only 3.21%. That is, it is significantly better than existing similar research in terms of attack chain reconstruction accuracy, general applicability and runtime overhead, providing a feasible path for deploying a high-precision, low-overhead and platform-independent attack tracing scheme in real systems.

[0080] Next, with reference to the accompanying drawings, an attack tracing device based on a symbolic execution engine according to an embodiment of the present invention is described.

[0081] Figure 14 This is a block diagram illustrating an attack tracing device based on a symbolic execution engine according to an embodiment of the present invention.

[0082] like Figure 14 As shown, the attack tracing device 140 based on symbolic execution engine includes: a construction program module 1401, a control flow graph construction module 1402, a tracing graph construction module 1403, a determination module 1404, and a reconstruction and analysis module 1405.

[0083] The module 1401 constructs the execution unit sequence of the target historical event processing loop and identifies multiple dependency-exploding functions in the execution unit sequence to construct independent subroutines. The control flow graph construction module 1402 combines static and dynamic analysis to construct the system call control flow graph of the target historical event processing loop. The source graph construction module 1403 collects audit logs containing parameter values ​​during the execution of the target program to construct a thread-level source graph. The determination module 1404 determines whether dependency-exploding nodes exist in the thread-level source graph based on the system call control flow graph. The refactoring and analysis module 1405, in the case of dependency-exploding nodes, refactors the independent subroutines using the dependency-exploding nodes and analyzes the refactored independent subroutines using a symbolic execution engine to reconstruct the attack path.

[0084] In some embodiments, the constructor module 1401 includes: The partition unit is used to divide the target historical event processing cycle into stages to obtain multiple stages, and to obtain multiple core logs from multiple stages. The analysis unit is used to analyze recurring event patterns in multiple core logs to characterize a finite state machine of a single execution unit structure. A transformation unit is used to convert a continuous log stream into a discrete, ordered sequence of execution units using a finite state machine. The identification unit is used to identify multiple dependency explosion functions in the execution unit sequence and analyze the dependency relationships between multiple dependency explosion functions to form a set of dependency function pairs; Construction unit, used to construct independent subroutines that can be used by symbolic execution based on the program slicing method and the dependent function set.

[0085] In some embodiments, constructing the control flow graph module 1402 includes: The acquisition and construction unit is used to acquire the fused static and dynamic information of the target historical event processing loop, and to construct a hybrid control flow graph by fusing the static and dynamic information. The generation unit is used to prune and normalize the hybrid control flow graph to generate a system call control flow graph.

[0086] In some embodiments, the source map construction module 1403 includes: The collection unit is used to collect audit logs containing parameter values ​​during program execution using a dual data collection strategy; The building unit is used to construct a thread-level source graph based on audit logs containing parameter values. The master nodes in the thread-level source graph adopt a hierarchical structure, and the directed edges in the thread-level source graph represent system events, with their directions indicating data flow or control flow.

[0087] In some embodiments, the determining module 1404 includes: Extraction unit, used to locate the corresponding loop unit in the thread-level source graph and extract the system call sequence in the loop unit; The matching unit is used to match the system call sequence with the system call control flow graph to identify the program entry function; The identification unit is used to identify nodes in independent subroutines based on the program entry function in order to determine whether there are nodes with dependency explosion.

[0088] In some embodiments, the reconstruction and analysis module 1405 includes: The extraction unit is used to retrieve and extract the dependency explosion subroutines corresponding to the nodes of dependency explosion from a pre-built independent subroutine database based on an indexing mechanism. The identification unit is used to identify the input and output parameter values ​​in the dependent explosion subroutine. The backfill unit is used to backfill the input and output parameter values ​​into the independent subroutine to obtain the reconstructed independent subroutine; The analysis unit is used to analyze the reconstructed individual subroutines using the symbolic execution engine in order to reconstruct the attack path.

[0089] It should be noted that the foregoing explanation of the attack tracing method embodiment based on symbolic execution engine also applies to the attack tracing device based on symbolic execution engine in this embodiment, and will not be repeated here.

[0090] The attack tracing device based on a symbolic execution engine proposed in the embodiments of the present invention has the following beneficial effects: (1) An automated analysis pipeline was designed to automatically identify functions that cause dependency explosion, model the interactions between these functions, and reconstruct them into self-contained, analyzable computational modules, thereby extracting the core computational logic directly related to input-output dependencies.

[0091] (2) A hybrid analysis method combining static and dynamic methods is proposed, which integrates static control flow graphs with runtime information to construct system call level control flow graphs, thereby achieving high-precision mapping between system call parameter values ​​in logs and source code variables.

[0092] (3) A complete attack tracing framework was designed and implemented: the computing module was extracted and reconstructed in the offline stage, the system calls and their parameters were fully recorded at runtime, and the complex input-output dependency relationship was accurately parsed on the above computing module by symbolic execution in the attack investigation stage, so as to reconstruct the real attack path under the complex execution model of multi-threading and multi-stage.

[0093] (4) Extensive empirical evaluation on 15 CVEs and 3 real attack cases shows that the attack chain can be reconstructed with 100% accuracy without any program instrumentation or auxiliary hardware. In terms of performance, it also shows high efficiency: the average runtime overhead on the SPEC CPU 2006 benchmark is only 4.81%, and the average overhead on typical Linux applications is only 3.21%. That is, it is significantly better than existing similar research in terms of attack chain reconstruction accuracy, general applicability and runtime overhead, providing a feasible path for deploying a high-precision, low-overhead and platform-independent attack tracing scheme in real systems.

[0094] Figure 15 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention.

[0095] The electronic device may include: a memory 1501, a processor 1502, and a computer program stored on the memory 1501 and executable on the processor 1502.

[0096] When the processor 1502 executes the program, it implements the attack tracing method based on the symbolic execution engine provided in the above embodiments.

[0097] Furthermore, electronic devices also include: Communication interface 1503 is used for communication between memory 1501 and processor 1502.

[0098] The memory 1501 is used to store computer programs that can run on the processor 1502.

[0099] The memory 1501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0100] If the memory 1501, processor 1502, and communication interface 1503 are implemented independently, then the communication interface 1503, memory 1501, and processor 1502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 15 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0101] Optionally, in a specific implementation, if the memory 1501, processor 1502, and communication interface 1503 are integrated on a single chip, then the memory 1501, processor 1502, and communication interface 1503 can communicate with each other through an internal interface.

[0102] Processor 1502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.

[0103] This invention also provides a computer program product that, when executed by a processor, implements the above-described attack tracing method based on a symbolic execution engine.

[0104] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described attack tracing method based on a symbolic execution engine.

[0105] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0106] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0107] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0108] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0109] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0110] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0111] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0112] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of the present invention have been shown and described above, it is to be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. An attack tracing method based on a symbolic execution engine, characterized in that, Includes the following steps: Construct a sequence of execution units for the target historical event processing loop, and identify multiple dependency explosion functions of the sequence of execution units to construct independent subroutines; By combining static and dynamic analysis, a system call control flow graph of the target historical event processing loop is constructed; Collect audit logs containing parameter values ​​during the execution of the target program to build a thread-level source graph; Determine whether there are nodes with dependency explosion in the thread-level source graph based on the system call control flow graph; In the presence of nodes with the aforementioned dependency explosion, the independent subroutines are reconstructed using the nodes with the dependency explosion, and the reconstructed independent subroutines are analyzed using a symbolic execution engine to reconstruct the attack path.

2. The attack tracing method based on a symbolic execution engine according to claim 1, characterized in that, The process of constructing a sequence of execution units for processing target historical events and identifying multiple dependency explosion functions within that sequence of execution units to construct independent subroutines includes: The target historical event processing loop is divided into stages to obtain multiple stages, and multiple core logs are obtained from the multiple stages. The recurring event patterns in the multiple core logs are analyzed to characterize the finite state machine of a single execution unit structure; The finite state machine is used to convert a continuous log stream into a discrete, ordered sequence of execution units; Identify multiple dependency explosion functions in the execution unit sequence and analyze the dependency relationships between the multiple dependency explosion functions to form a set of dependency function pairs; Based on the program slicing method, independent subroutines that can be used for symbolic execution are constructed from the set according to the dependent functions.

3. The attack tracing method based on a symbolic execution engine according to claim 1, characterized in that, The system call control flow graph for constructing the target historical event processing loop by combining static and dynamic analysis includes: Obtain the fused static and dynamic information of the target historical event processing loop, and construct a hybrid control flow graph using the fused static and dynamic information; The hybrid control flow graph is pruned and normalized to generate the system call control flow graph.

4. The attack tracing method based on a symbolic execution engine according to claim 1, characterized in that, The step of collecting audit logs containing parameter values ​​during the execution of the target program to construct a thread-level source graph includes: A dual data collection strategy is employed to collect audit logs containing parameter values ​​during program execution; The thread-level source graph is constructed based on the audit log containing parameter values. The master nodes in the thread-level source graph adopt a hierarchical structure, and the directed edges in the thread-level source graph represent system events, with their directions indicating data flow or control flow.

5. The attack tracing method based on a symbolic execution engine according to claim 1, characterized in that, The step of determining whether there are dependency explosion nodes in the thread-level source graph based on the system call control flow graph includes: Locate the corresponding loop unit in the thread-level source graph and extract the system call sequence in the loop unit; The system call sequence is matched with the system call control flow graph to identify the program entry function; The program entry function performs node identification in the independent subroutine to determine whether there are nodes with dependency explosion.

6. The attack tracing method based on a symbolic execution engine according to claim 1, characterized in that, In the presence of nodes with the dependency explosion, the independent subroutines are reconstructed using these nodes, and the reconstructed independent subroutines are analyzed to reconstruct the attack path, including: Based on the indexing mechanism, the dependency explosion subroutines corresponding to the nodes of the dependency explosion are retrieved and extracted from the pre-built independent subroutine database. Identify the input and output parameter values ​​in the dependent explosion subroutine; The input and output parameter values ​​are then filled back into the independent subroutine to obtain the reconstructed independent subroutine. The reconstructed independent subroutines are analyzed using a symbolic execution engine to reconstruct the attack path.

7. An attack tracing device based on a symbolic execution engine, characterized in that, include: A program module is constructed to build a sequence of execution units for processing target historical events and to identify multiple dependency explosion functions of the sequence of execution units in order to construct independent subroutines. A control flow graph construction module is used to construct the system call control flow graph of the target historical event processing loop by combining static and dynamic analysis. The source graph construction module is used to collect audit logs containing parameter values ​​during the execution of the target program in order to build a thread-level source graph; The determination module is used to determine whether there are nodes with dependency explosion in the thread-level tracing graph based on the system call control flow graph; The refactoring and analysis module is used to refactor the independent subroutine using the nodes of the dependency explosion when such nodes exist, and to analyze the refactored independent subroutine using a symbolic execution engine in order to reconstruct the attack path.

8. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the attack tracing method based on a symbolic execution engine as described in any one of claims 1-6.

9. A computer program product, characterized in that, When the computer program / instruction is executed by the processor, it implements the attack tracing method based on the symbolic execution engine as described in any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the attack tracing method based on the symbolic execution engine as described in any one of claims 1-6.

Images