Memory image security analysis method, device and equipment and storage medium

Abstract

The application provides a memory image security analysis method, device and equipment and a storage medium. The method comprises the following steps: constructing a memory evidence graph based on a memory image of an electronic device to be detected; extracting an abnormal evidence subgraph from the memory evidence graph, generating a structured threat hypothesis and an evidence requirement set by using a large language model; matching the evidence requirement set with the memory evidence graph to generate evidence gap state information; determining a target evidence operation from candidate evidence operations according to a pre-registered evidence collection capability object, mapping the target evidence operation to an evidence plug-in and execution parameters and executing the target evidence operation; converting new evidence data into new memory evidence objects and backfilling the new memory evidence objects into the memory evidence graph; revising the structured threat hypothesis and the evidence requirement set and continuing evidence collection when a stop condition is not met, and outputting a security detection result bound with the memory evidence objects when the stop condition is met. The application realizes cross-platform evidence unified representation, evidence gap closed-loop evidence collection and traceable deterministic security judgment.

Description

Technical Field

[0001] This application belongs to the field of security detection technology, and relates to a memory image security analysis method, apparatus, device, and storage medium. Background Technology

[0002] With the increasing prevalence of memory-resident attack techniques such as advanced persistent threats, fileless attacks, process injection, and kernel object hiding, memory forensics has become a key technical means for endpoint security detection and incident response. Memory images contain rich volatile evidence such as processes, threads, modules, memory regions, handles, and network endpoints, making them an important data source for tracing attack traces.

[0003] However, existing memory forensics technologies have the following drawbacks in practical applications: First, the forensics process is rigid and difficult to dynamically adapt to actual needs; second, cross-platform evidence semantics are heterogeneous and difficult to represent uniformly; and third, the application of large language models has uncontrollable risks.

[0004] In conclusion, a new method for memory image security analysis is urgently needed to solve the aforementioned technical problems. Summary of the Invention

[0005] This application provides a memory image security analysis method, apparatus, device, and storage medium to solve the problems of fixed existing memory forensics processes, inconsistent cross-platform evidence semantics, uncontrollable conclusions from large language models, and difficulty in tracing security detection results.

[0006] Firstly, this application provides a memory image security analysis method. The method includes: acquiring a memory image of an electronic device under test; constructing a memory evidence graph corresponding to the memory image; extracting an abnormal evidence subgraph from the memory evidence graph, inputting the abnormal evidence subgraph into a large language model to obtain a set of structured threat hypotheses and evidence requirements output by the large language model according to a preset structured pattern; matching the set of evidence requirements with the memory evidence graph to generate evidence gap status information; determining a target evidence collection operation from multiple candidate evidence collection operations corresponding to pre-registered evidence collection capability objects based on the evidence gap status information; mapping the target evidence collection operation to pre-registered evidence collection plugins and execution parameters, performing the target evidence collection operation on the memory image using the evidence collection plugins and execution parameters to obtain new evidence collection data; converting the new evidence collection data into new memory evidence objects, backfilling the new memory evidence objects into the memory evidence graph, and updating the abnormal evidence subgraph and the evidence gap status information based on the updated memory evidence graph; determining whether a stopping condition is met based on the updated evidence gap status information, and outputting a security detection result bound to the memory evidence object based on the stopping condition.

[0007] In this application, the large language model is only responsible for generating structured "threat hypotheses" and "evidence requirements." Its output is strictly limited to preset patterns and ranges, significantly improving the accuracy and controllability of security analysis results. The large language model does not directly call any real plugins or commands. The system dynamically matches "evidence-gathering operations" with corresponding capabilities based on the current "evidence gap." This "requirement proposal-capability matching-whitelist scheduling" mechanism not only achieves on-demand evidence gathering but also ensures that every executed plugin and its parameters have a clear source and basis, forming a complete execution log chain, making the entire security detection process traceable and auditable. A closed-loop iterative mechanism is adopted. Whenever new evidence is acquired and backfilled into the in-memory evidence graph, the system re-evaluates the current hypothesis and evidence gap, continuously correcting its direction until a clear stopping condition is met. This closed-loop mechanism simulates the in-depth investigation logic of human experts, automatically uncovering hidden threats and avoiding missed detections. Simultaneously, the "insufficient evidence" stopping condition ensures the system can terminate reasonably, avoiding infinite loops.

[0008] In one implementation of the first aspect, constructing the memory evidence graph corresponding to the memory image includes: identifying the operating system information, kernel version information, and symbol trust information corresponding to the memory image; determining at least one initial forensic operation based on the operating system information, kernel version information, and symbol trust information, and performing the initial forensic operation on the memory image to obtain heterogeneous forensic data; converting the heterogeneous forensic data into memory evidence objects of a preset type, and constructing the memory evidence graph based on the object association relationships between the memory evidence objects.

[0009] In one implementation of the first aspect, the step of extracting anomaly evidence subgraphs from the memory evidence graph and inputting the anomaly evidence subgraphs into a large language model to obtain a set of structured threat hypotheses and evidence requirements output by the large language model according to a preset structured pattern includes: for memory evidence objects and object associations in the memory evidence graph, calculating node anomaly scores and / or edge anomaly scores based on at least two of the following: memory region permissions, module mapping status, thread entry address, process parent-child relationship, network endpoint reputation, object cross-view consistency, normal baseline deviation, and evidence quality information; identifying memory evidence objects or object associations whose node anomaly scores and / or edge anomaly scores meet preset anomaly conditions as anomaly seed evidence; extracting adjacent memory evidence objects and object associations associated with the anomaly seed evidence from the memory evidence graph centered on the anomaly seed evidence, according to a preset relationship type and a preset hop count range, to obtain candidate anomaly evidence subgraphs; and recursively analyzing the candidate anomaly evidence subgraphs that meet the normal baseline. The evidence objects are pruned or statistically summarized, and the corresponding evidence identifier, evidence source information, original memory location information, and evidence quality information are retained to obtain the abnormal evidence subgraph. According to a preset input template, the abnormal evidence subgraph is converted into structured hint data including a node list, edge list, evidence identifier, object type, evidence quality, evidence source information, and security domain label. The structured hint data, attack knowledge template, and preset structured pattern are input into the large language model, causing the large language model to output the structured threat hypothesis and the evidence requirement set. The structured threat hypothesis includes at least a hypothesis identifier, attack type, and target evidence object, and the evidence requirement set includes at least necessary evidence conditions, auxiliary evidence conditions, exclusionary evidence conditions, and supplementary evidence conditions. Structured pattern verification, enumeration value verification, and evidence identifier existence verification are performed on the structured threat hypothesis and the evidence requirement set output by the large language model. Upon successful verification, the structured threat hypothesis and the evidence requirement set are obtained.

[0010] In one implementation of the first aspect, the step of matching the evidence requirement set with the in-memory evidence graph to generate evidence gap status information includes: for each evidence condition in the evidence requirement set, performing node matching and edge or path matching in the in-memory evidence graph according to the target object type and graph relationship constraints in the evidence condition; if there exists an object group that satisfies the target object type and the graph relationship constraints, and the evidence quality of all necessary in-memory evidence objects in the object group reaches a preset threshold, then the corresponding evidence condition is marked as quality satisfied; if there exists an object group that satisfies the target object type and the graph relationship constraints, but at least one necessary in-memory evidence object in the object group... If the quality of the stored evidence object does not reach the preset threshold, the evidence condition is marked as insufficient quality; if the object attributes or object relationships of the memory evidence objects generated by different evidence collection paths are inconsistent, the corresponding evidence condition is marked as conflicting; if there is no memory evidence object that satisfies the target object type and graph relationship constraints, the corresponding evidence condition is marked as missing; if the exclusion evidence condition is met, the corresponding evidence condition is marked as hitting exclusion evidence; if the forced exclusion evidence has not yet been checked, the corresponding evidence condition is marked as unchecked; wherein, the evidence gap status information includes the quality satisfaction, quality insufficiency, conflict, missing, hitting exclusion evidence, or unchecked status of each evidence condition.

[0011] In one implementation of the first aspect, determining the target forensic operation from multiple candidate forensic operations corresponding to pre-registered forensic capability objects based on the evidence gap status information includes: calculating the coverage gain value of each candidate forensic operation on the evidence gap status information; calculating the operation score of the candidate forensic operation based on the coverage gain value, expected uncertainty reduction, evidence independence degree, expected execution cost, and execution risk; and selecting the candidate forensic operation whose operation score meets preset conditions as the target forensic operation from among the candidate forensic operations that satisfy prerequisite dependencies, permission conditions, and security policies.

[0012] In one implementation of the first aspect, the step of determining whether a stopping condition is met based on the updated evidence gap state information and outputting a security detection result bound to the memory evidence object based on the stopping condition includes: if the updated evidence gap state information does not meet the stopping condition, controlling the large language model to correct the structured threat hypothesis and the evidence requirement set based on the updated abnormal evidence subgraph, and repeating the steps of determining and executing the target evidence collection operation; if the stopping condition is met, verifying the structured threat hypothesis using preset deterministic evidence conditions, and outputting a security detection result bound to the memory evidence object.

[0013] In one implementation of the first aspect, the stopping conditions include a confirmed stopping condition, an exclusion stopping condition, and an insufficient evidence stopping condition; the confirmed stopping condition includes all necessary evidence reaching the corresponding evidence quality threshold and all mandatory exclusion evidence checks being completed without hitting any excluded evidence; the exclusion stopping condition includes hitting excluded evidence verified through an independent evidence collection path; the insufficient evidence stopping condition includes reaching the loop count, time budget, or resource budget, the expected information gain of the candidate evidence collection operation being lower than a threshold, or the image quality of the memory image being lower than the threshold for continuing parsing.

[0014] Secondly, this application provides a memory image security analysis device, the device comprising: a memory image acquisition module for acquiring a memory image of an electronic device under test; a memory evidence graph construction module for constructing a memory evidence graph corresponding to the memory image; a structured hypothesis generation module for extracting anomaly evidence subgraphs from the memory evidence graph and inputting the anomaly evidence subgraphs into a large language model to obtain structured threat hypotheses and a set of evidence requirements output by the large language model according to a preset structured pattern; an evidence gap state information generation module for matching the set of evidence requirements with the memory evidence graph to generate evidence gap state information; and a target forensic operation determination module for determining, based on the evidence gap state information, a target forensic operation determination from pre-registered forensic capabilities. The system identifies a target forensic operation from multiple candidate forensic operations corresponding to the object; an forensic execution module maps the target forensic operation to a pre-registered forensic plugin and execution parameters, and executes the target forensic operation on the memory image using the forensic plugin and execution parameters to obtain new forensic data; an evidence update module converts the new forensic data into a new memory evidence object, backfills the new memory evidence object into the memory evidence graph, and updates the abnormal evidence subgraph and the evidence gap status information based on the updated memory evidence graph; and a security detection result output module determines whether the stopping condition is met based on the updated evidence gap status information, and outputs the security detection result bound to the memory evidence object based on the stopping condition.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the memory mirror security analysis method described in any one of the first aspects of embodiments of this application.

[0016] Fourthly, embodiments of this application provide an electronic device, the electronic device comprising: a memory storing a computer program; and a processor communicatively connected to the memory, which executes the memory mirror security analysis method as described in any one of the first aspects of embodiments of this application when the computer program is invoked.

[0017] As described above, the memory image security analysis method, apparatus, device, and storage medium described in this application have the following beneficial effects:

[0018] 1) In this method, the large language model is only responsible for generating structured "threat hypotheses" and "evidence requirements." Its output is strictly limited to a preset pattern and range and is verified by evidence identifiers. The final attack conclusion does not depend on the text generation of the large language model, but is logically verified by the system through deterministic evidence conditions. This ensures that the semantic reasoning ability of the large language model is safely confined within the scope of "computability and verifiability," significantly improving the accuracy and controllability of security analysis results. The large language model does not directly call any real plugins or commands. The system dynamically matches "evidence collection operations" with corresponding capabilities based on the current "evidence gap." This "requirement proposal - capability matching - whitelist scheduling" mechanism not only realizes evidence collection on demand but also ensures that each executed plugin and its parameters have a clear source and basis, forming a complete execution log chain, making the entire security detection process traceable and auditable. A closed-loop iterative mechanism is adopted. Whenever new evidence is obtained and backfilled into the in-memory evidence graph, the system will re-evaluate the current hypothesis and evidence gap, continuously correcting the direction until a clear stopping condition is met. This closed-loop mechanism simulates the in-depth investigation logic of human experts, which can automatically uncover hidden threats and avoid underreporting. At the same time, the "insufficient evidence" termination condition ensures that the system can terminate reasonably and avoid infinite loops.

[0019] 2) By uniformly converting various heterogeneous raw forensic data into "in-memory evidence objects" containing standard fields such as "evidence identifier, object type, source location, and quality information," the format differences between underlying plugins and operating systems are shielded, allowing upper-layer security analysis (such as large model inference) to be free from concern for the underlying data format, significantly improving the system's cross-platform compatibility and scalability; by constructing an in-memory evidence graph through multi-dimensional relationships, isolated in-memory evidence objects are connected into a network graph with contextual logic, realizing the transformation from isolated data to structured context, providing a solid foundation for complex threat detection and model inference. Attached Figure Description

[0020] Figure 1A The flowchart shown is a memory image security analysis method provided in an embodiment of this application.

[0021] Figure 1B The flowchart shown is a process for extracting abnormal evidence subgraphs and generating structured threat hypotheses, provided in an embodiment of this application.

[0022] Figure 2A The flowchart shown is a process for constructing the memory evidence graph corresponding to the memory image provided in an embodiment of this application.

[0023] Figure 2B The diagram shown is a flowchart of heterogeneous forensic data conversion and memory evidence graph construction provided in an embodiment of this application.

[0024] Figure 3A The flowchart shown is a process for generating evidence gap status information according to an embodiment of this application.

[0025] Figure 3B The diagram shown illustrates the evidence requirements, quality calculation, and evidence gap generation process as provided in one embodiment of this application.

[0026] Figure 4A The flowchart shown is a process for determining a target forensics according to an embodiment of this application.

[0027] Figure 4B The diagram shown is a flowchart of the target forensics operation determination and execution mapping provided in an embodiment of this application.

[0028] Figure 5 The flowchart shown is a presentation of the output security detection results provided in an embodiment of this application.

[0029] Figure 6 The diagram shown is a flowchart of the large language model evidence gap closure analysis provided in an embodiment of this application.

[0030] Figure 7 The diagram shown is a structural diagram of a memory image security analysis device provided in an embodiment of this application.

[0031] Figure 8 The diagram shown is a structural diagram of an electronic device provided in an embodiment of this application.

[0032] Component designation explanation

[0033] S11~S18 step 75 Target Evidence Collection Operation Determination Module S21~S23 step 76 Evidence collection and execution module S31~S37 step 77 Evidence update module S41~S43 step 78 Safety test result output module S51~S52 step 80 electronic devices 70 Memory Image Security Analysis Device 81 processor 71 Memory Image Acquisition Module 82 Non-volatile storage media 72 Memory Evidence Graph Construction Module 83 System bus 73 Structured Hypothesis Generation Module 84 Internal memory 74 Evidence Gap Status Information Generation Module 85 Network interface Detailed Implementation

[0034] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0035] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The illustrations only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0036] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0037] like Figure 1A As shown, this application provides a flowchart of a memory image security analysis method. Figure 1A As shown, the memory image security analysis method provided in this application includes the following steps S11 to S18.

[0038] S11, Obtain the memory image of the electronic device under test.

[0039] For example, a memory image can be a full physical memory image, a virtual machine memory snapshot, a target process dump, or an incremental snapshot at multiple points in time.

[0040] S12, construct the memory evidence graph corresponding to the memory image.

[0041] The memory evidence graph is used to represent the relationships between memory evidence objects. Nodes in the graph represent memory evidence objects, and edges can represent ownership, loading, execution, connection, derivation, reference, support, exclusion, or conflict relationships. For example, a process node and a memory region node can have an ownership relationship, a thread node and a memory region node can have an entry point relationship, and a handle node and a process node can have a high-privilege reference relationship.

[0042] S13, extract an abnormal evidence subgraph from the memory evidence graph, and input the abnormal evidence subgraph into the large language model to obtain the structured threat hypothesis and evidence requirement set output by the large language model according to the preset structured mode.

[0043] The abnormal evidence subgraph can consist of abnormal nodes and their adjacent objects, such as executable private memory regions, abnormal parent-child process relationships, unsigned modules, abnormal thread entry points, abnormal network endpoints, and cross-view inconsistent objects.

[0044] The structured threat hypothesis is a machine-resolvable record used to describe the attack activity to be verified, and includes at least a hypothesis identifier, attack type, target process or target memory region, anomaly evidence identifier that triggered the hypothesis, and hypothesis state. The evidence requirement set consists of one or more structured evidence requirement conditions, and is associated with the corresponding structured threat hypothesis through the hypothesis identifier; each structured evidence requirement condition describes one piece of evidence required to verify the structured threat hypothesis.

[0045] The evidence requirement set includes multiple evidence conditions. Each evidence condition includes at least a condition role, target object type, graph relationship constraints, and evidence quality threshold. The condition role includes at least one of necessary evidence, auxiliary evidence, and exclusionary evidence.

[0046] In some embodiments, the step of extracting anomaly evidence subgraphs from the memory evidence graph and inputting the anomaly evidence subgraphs into a large language model to obtain a set of structured threat hypotheses and evidence requirements output by the large language model according to a preset structured pattern includes: for memory evidence objects and object relationships in the memory evidence graph, calculating node anomaly scores and / or edge anomaly scores based on at least two of the following: memory region permissions, module mapping status, thread entry address, process parent-child relationship, network endpoint reputation, object cross-view consistency, normal baseline deviation, and evidence quality information; identifying memory evidence objects or object relationships whose node anomaly scores and / or edge anomaly scores meet preset anomaly conditions as anomaly seed evidence; extracting adjacent memory evidence objects and object relationships associated with the anomaly seed evidence from the memory evidence graph centered on the anomaly seed evidence, according to a preset relationship type and a preset hop count range, to obtain candidate anomaly evidence subgraphs; and identifying duplicate evidence pairs in the candidate anomaly evidence subgraphs that meet the normal baseline. The system performs pruning or statistical summarization processing on the image, retaining the corresponding evidence identifier, evidence source information, original memory location information, and evidence quality information to obtain the abnormal evidence subgraph. Following a preset input template, the abnormal evidence subgraph is converted into structured hint data including a node list, edge list, evidence identifier, object type, evidence quality, evidence source information, and security domain label. The structured hint data, attack knowledge template, and preset structured pattern are input into the large language model, causing the large language model to output the structured threat hypothesis and the evidence requirement set. The structured threat hypothesis includes at least a hypothesis identifier, attack type, and target evidence object, and the evidence requirement set includes at least necessary evidence conditions, auxiliary evidence conditions, exclusionary evidence conditions, and supplementary evidence conditions. Structured pattern verification, enumeration value verification, and evidence identifier existence verification are performed on the structured threat hypothesis and evidence requirement set output by the large language model. Upon successful verification, the structured threat hypothesis and evidence requirement set are obtained.

[0047] For example, firstly, anomaly seed evidence is selected based on node anomaly scores and edge anomaly scores; then, centered on the anomaly seed evidence, one to three hops are extended along the relationships of ownership, loading, entry point location, connection, reference, and derivation to form a candidate anomaly evidence subgraph; subsequently, duplicate nodes that meet the normal baseline and are not directly related to the anomaly link are deleted, while retaining the node identifier, object type, source plugin, original memory address, mirror hash, and evidence quality. The processed node list, edge list, and security domain label are filled into a preset input template and input together with the attack knowledge template into the large language model. The large language model must output the attack type, target object, necessary evidence, auxiliary evidence, excluded evidence, and evidence to be supplemented in preset JSON fields; the system then verifies whether the evidence identifier exists, whether the object type and relationship type belong to the registered enumeration values, and whether the threshold is within the allowed range; if the verification fails, the output is rejected.

[0048] For example, the Large Language Model (LLM) generates structured threat hypotheses based on anomaly evidence subgraphs and attack knowledge templates. Attack knowledge templates describe the evidence objects, necessary evidence, supporting evidence, excluded evidence, and action types that can be used to obtain the corresponding evidence typically involved in different attack types. Attack knowledge templates can be configured by security experts or generated from technical entries in an attack knowledge base.

[0049] The structured threat hypothesis includes a hypothesis identifier, attack type, target evidence object, anomaly seed evidence identifier, and hypothesis status. The hypothesis status includes pending verification, valid, excluded, or insufficient evidence. The evidence requirement set independently records necessary evidence conditions, auxiliary evidence conditions, exclusionary evidence conditions, and supplementary evidence conditions to avoid duplicate storage of evidence conditions in the structured threat hypothesis.

[0050] The large language model outputs a pre-defined structured pattern. The system performs pattern validation, enumeration validation, and evidence identification validation on the output. The large language model can output evidence requirements and action type suggestions, but it must not output real plugin names, system commands, file paths, or executable parameters; real plugins and execution parameters are determined by the scheduling module based on pre-registered evidence collection capability objects.

[0051] For example, the structured evidence requirement conditions include condition identifiers, associated hypothesis identifiers, condition roles, target evidence object type, target object attribute constraints, graph relationship constraints, evidence quality thresholds, whether it is a mandatory check item, and recommended action type. Among these, the condition role can be necessary evidence, auxiliary evidence, or exclusionary evidence. Matching states such as quality satisfied, insufficient quality, conflict, missing, hit exclusionary evidence, and unchecked are not pre-given by the large language model, but are written into the evidence gap status information after the evidence requirement set and the in-memory evidence graph are matched.

[0052] For example, before inputting the abnormal evidence subgraph into the large language model, the method further includes: marking the command lines, strings, web page content, script content, and file paths extracted from the memory image as untrusted evidence data, and placing the system instructions, evidence collection capability objects, and the untrusted evidence data in different security domains; the large language model must not directly output the real plugin name, system command, file path, or executable parameters, and the real plugin and execution parameters are determined by the scheduling module from a whitelist.

[0053] S14, Match the evidence requirement set with the memory evidence graph to generate evidence gap status information.

[0054] Among them, the evidence gap status information is not a natural language description, but a structured status record indexed by evidence conditions, which can be used by the scheduling module to calculate the next evidence collection operation.

[0055] Among them, the evidence gap status information is used to indicate whether each piece of evidence is in a state of being satisfied, missing, insufficient, conflicting, excluding evidence, or unchecked.

[0056] For example, when the evidence gap state information indicates that evidence from different evidence collection paths conflict with each other, a candidate evidence collection operation that is different from the evidence collection path that generated the conflicting evidence and has a different underlying memory structure is preferentially selected as the target evidence collection operation, and the new evidence generated by the target evidence collection operation is used to update the conflict state.

[0057] It should be noted that the evidence gap status information is a key data structure driving the closed-loop mechanism of this application. For each structured threat hypothesis, the security detection device matches each evidence condition in the necessary evidence set, the auxiliary evidence set, and the excluded evidence set with the in-memory evidence graph.

[0058] When there are evidence objects in the evidence graph that satisfy the object type, graph relationship constraints, and evidence quality threshold, the corresponding evidence condition is marked as quality satisfied; when there is no relevant evidence, it is marked as missing; when there is relevant evidence but the evidence quality does not reach the threshold, it is marked as insufficient quality; when the object attributes or object relationships generated by different evidence collection paths are inconsistent, it is marked as conflicting; when the conditions for excluding evidence are met, it is marked as excluding evidence hit; when the mandatory exclusion evidence has not yet been checked, it is marked as unchecked.

[0059] Unlike simply calculating confidence levels, this application categorizes evidence status into quality-satisfied, missing, insufficient, conflicting, excluded evidence hit, and unchecked, so that the scheduling module knows whether the next step is to supplement missing evidence, improve low-quality evidence, cross-validate conflicting evidence, or complete the exclusion evidence check.

[0060] For example, the evidence gap status information includes at least three of the following: condition identifier, condition role, matched evidence identifier, missing evidence type, current status, quality difference, source of conflict, whether it is a mandatory check item, and recommended action type. Because this information can be parsed by a computer, it can directly drive the selection of candidate evidence-gathering actions.

[0061] S15, Based on the evidence gap status information, determine the target evidence collection operation from multiple candidate evidence collection operations corresponding to the pre-registered evidence collection capability objects.

[0062] For example, each candidate forensic operation corresponds to a forensic capability object. The forensic capability object includes action identifier, applicable operating system, kernel or symbolic constraints, input object type, execution scope, type of evidence that can be generated, prerequisites, expected execution cost, degree of evidence independence, and execution risk.

[0063] S16, the target forensic operation is mapped to a pre-registered forensic plugin and execution parameters, and the target forensic operation is performed on the memory image using the forensic plugin and the execution parameters to obtain new forensic data.

[0064] S17, the newly added evidence data is converted into a new memory evidence object, the new memory evidence object is backfilled into the memory evidence graph, and the abnormal evidence subgraph and the evidence gap status information are updated based on the updated memory evidence graph.

[0065] Among them, memory evidence objects are used to convert native forensic results generated by different platforms and plugins into unified evidence semantics. Memory evidence objects can include process evidence objects, thread evidence objects, module evidence objects, memory region evidence objects, network endpoint evidence objects, handle evidence objects, command evidence objects, and persistent evidence objects.

[0066] Each memory evidence object can include: evidence identifier, object type, native object type, cross-plugin association key, source plugin, plugin version, execution parameters, mirror hash, object address, virtual address, physical address, original output index, symbol confidence, page integrity, evidence quality, security domain label, and collection time. These fields enable the detection results to be reviewed against the original mirror location and original evidence output.

[0067] For example, the EPROCESS process object in the Windows operating system and the task_struct task structure in the Linux operating system can both be converted into process evidence objects; VAD in Windows and VMA in Linux can both be converted into memory region evidence objects; Windows ETHREAD objects and Linux thread execution contexts can both be converted into thread evidence objects.

[0068] S18, determine whether the stopping condition is met based on the updated evidence gap status information, and output the security detection result of the memory evidence object based on the stopping condition.

[0069] Specifically, the system determines whether the stopping condition is met based on the updated evidence gap status information; if the stopping condition is not met, the system controls the large language model to correct the structured threat hypothesis and the evidence requirement set based on the updated abnormal evidence subgraph, and repeats steps S15 to S17; if the stopping condition is met, the system verifies the structured threat hypothesis using preset deterministic evidence conditions and outputs a security detection result bound to the memory evidence object.

[0070] Specifically, if any necessary evidence fails to meet the corresponding evidence quality threshold, or if there is an incomplete mandatory exclusion evidence check, the output of a security detection result indicating that the structured threat hypothesis is valid is prohibited.

[0071] Please see Figure 1B , Figure 1B The flowchart shown is a process for extracting abnormal evidence subgraphs and generating structured threat hypotheses, provided in an embodiment of this application.

[0072] like Figure 1B As shown, the extraction and structured output of the abnormal evidence subgraph includes six steps: abnormal scoring, abnormal seed selection, relation expansion, normal baseline pruning, structured cue assembly, and restricted output and verification of the large language model.

[0073] This application provides a memory image security analysis method. In this method, the large language model is only responsible for generating structured "threat hypotheses" and "evidence requirements." Its output is strictly limited to a preset pattern and range and is verified by evidence identifiers. The final attack conclusion does not depend on the text generation of the large language model, but is logically verified by the system through deterministic evidence conditions. This securely confines the semantic reasoning ability of the large language model within the scope of "computability and verifiability," significantly improving the accuracy and controllability of the security analysis results. Existing forensic processes typically rely on human experience or fixed scripts, and allowing the large language model to directly call system commands poses significant security risks and lacks auditability. In this application, the large language model does not directly call any real plugins or commands; the system dynamically matches "forensic operations" with corresponding capabilities based on the current "evidence gap." This "requirement submission-capability matching-whitelist scheduling" mechanism not only enables on-demand evidence collection but also ensures that every executed plugin and its parameters have a clear source and basis, forming a complete execution log chain. This makes the entire security detection process traceable and auditable. Traditional single scans often only discover local anomalies and are difficult to construct a complete attack chain. This application adopts a closed-loop iterative mechanism. Whenever new evidence is acquired and backfilled into the in-memory evidence graph, the system re-evaluates the current hypothesis and evidence gaps, continuously correcting its direction until a clear stopping condition is met. This closed-loop mechanism simulates the in-depth investigation logic of human experts, automatically uncovering hidden threats and avoiding missed detections. At the same time, the "insufficient evidence" stopping condition ensures that the system can terminate reasonably, avoiding infinite loops.

[0074] like Figure 2A As shown, this application embodiment provides a flowchart for constructing a memory evidence graph corresponding to the memory image, as follows: Figure 2A As shown, the method for constructing the memory evidence graph corresponding to the memory image provided in this application embodiment includes the following steps S21 to S23.

[0075] S21, identify the operating system information, kernel version information and symbol trust information corresponding to the memory image.

[0076] For example, the operating system type is determined by scanning the file header features and magic words in the memory image; the kernel version information is extracted by parsing the kernel version data structure corresponding to the operating system; and the symbol trust information is determined by extracting the kernel code segment digest and comparing it with a pre-set trusted hash library, as well as verifying the rationality of key memory pointers.

[0077] S22, determine at least one initial forensic operation based on the operating system information, the kernel version information and the symbol trust information, and perform the initial forensic operation on the memory image to obtain heterogeneous forensic data.

[0078] Specifically, heterogeneous forensic data consists of raw parsing results generated by different operating systems, underlying memory structures, and forensic operations. This includes process enumeration records, thread enumeration records, module lists, virtual memory region records, network socket records, handle records, command-line strings, and raw output indexes. For example, both Windows' EPROCESS and Linux's task_struct can provide process identifiers, parent process identifiers, image paths, command lines, and object addresses, but their field names, address formats, and parsing sources differ, thus classifying them as heterogeneous forensic data.

[0079] For example, the initial forensic operations include at least two of the following: process enumeration, process tree parsing, thread enumeration, module enumeration, memory region parsing, network connection scanning, handle enumeration, and command line extraction. These initial forensic operations can be performed by the Volatility framework, a custom parser, or other read-only forensic plugins.

[0080] S23, the heterogeneous forensic data is converted into memory evidence objects of a preset type, and a memory evidence graph is constructed based on the object association relationships between the memory evidence objects.

[0081] The memory evidence object includes at least an evidence identifier, an object type, evidence source information, original memory location information, evidence quality information, and a security domain label.

[0082] For example, heterogeneous forensic data is converted into in-memory evidence objects, and an in-memory evidence graph is constructed based on the object addresses, process identifiers, thread identifiers, address spaces, loading relationships, ownership relationships, connection relationships, derivation relationships, execution relationships, supporting relationships, and contradictory relationships among these in-memory evidence objects. Nodes in the in-memory evidence graph represent in-memory evidence objects, and edges represent object relationships.

[0083] Specifically, during the conversion, a unique evidence identifier is generated for each original parsing result; based on the platform mapping table, EPROCESS or task_struct is mapped to process evidence objects, ETHREAD or thread execution context is mapped to thread evidence objects, and VAD or VMA is mapped to memory region evidence objects; then, association keys such as process identifier, object address, address space identifier, thread identifier, and network 5-tuple are extracted to establish ownership, loading, entry point location, connection, reference, and derived edges. A memory image typically corresponds to multiple memory evidence objects. For example, the same process can be associated with multiple thread objects, module objects, memory region objects, network endpoint objects, and handle objects; these objects together constitute a memory evidence graph that can describe the attack chain, rather than drawing conclusions from a single object.

[0084] Please see Figure 2B , Figure 2BThe diagram shown is a flowchart of heterogeneous forensic data conversion and memory evidence graph construction provided in an embodiment of this application.

[0085] Depend on Figure 2B It can be seen that heterogeneous evidence data is mapped by the platform, normalized by fields and extracted by association keys to form multiple in-memory evidence objects, and then an in-memory evidence graph is built based on the object relationships.

[0086] This application provides a method for constructing a memory evidence graph corresponding to the memory image. In this method, various heterogeneous raw forensic data are uniformly converted into "memory evidence objects" containing standard fields such as "evidence identifier, object type, source location, and quality information." This shields the format differences between underlying plugins and operating systems, allowing upper-layer security analysis (such as large model inference) to be free from concern for the underlying data format, significantly improving the system's cross-platform compatibility and scalability. By constructing a memory evidence graph through multi-dimensional relationships, isolated memory evidence objects are connected into a network graph with contextual logic, realizing the transformation from isolated data to structured context and providing a solid foundation for complex threat detection and model inference.

[0087] like Figure 3A As shown in the figure, this application provides a flowchart for generating evidence gap status information, as follows: Figure 3A As shown, the method for generating evidence gap status information provided in this application embodiment includes the following steps S31 to S37.

[0088] S31, for each evidence condition in the evidence requirement set, perform node matching and edge or path matching in the memory evidence graph according to the target object type and graph relationship constraints in the evidence condition.

[0089] S32, if there exists an object group that satisfies the target object type and the graph relationship constraint, and the evidence quality of the necessary memory evidence objects in the object group all reach a preset threshold, then the evidence condition is marked as quality satisfied.

[0090] The quality of evidence can be calculated based on the completeness of the mirrored page, the credibility of the symbol, the execution status of the plugin, the consistency across evidence collection operations, the consistency of time, and the credibility of the evidence source. These factors are normalized to the range of 0 to 1 and then weighted and summed according to preset weights to obtain the evidence quality. If the symbol credibility is below a threshold, the quality of evidence obtained by relying on the same symbol path is reduced, and the scheduling module prioritizes candidate evidence collection operations that do not rely on that symbol path.

[0091] Specifically, the evidence quality Q can be calculated as Q = w1 × P + w2 × S + w3 × E + w4 × C + w5 × T + w6 × Rs, where P is the integrity of the mirrored page, S is the symbol credibility, E is the plugin execution status score, C is the consistency across forensic operations, T is the temporal consistency, and Rs is the credibility of the evidence source. Each factor is normalized to 0 to 1, and w1 to w6 are preset non-negative weights whose sum is 1. Graph relationship constraints include at least node type constraints, endpoint attribute constraints, relationship type constraints, and hop count constraints. For example, the condition that the thread entry point is located in a private executable memory region requires that the entry address of the thread node falls within the address range of the memory region node, there is an edge between them that says "entry point is located", and the memory region belongs to the target process. The evidence quality threshold can be configured from 0.60 to 0.90 according to the attack type and the credibility of the mirrored image; in general terminal detection scenarios, necessary evidence can be set to 0.70, and necessary evidence on which high-risk conclusions are based can be set to 0.80 or higher.

[0092] Please see Figure 3B , Figure 3B The diagram shown illustrates the evidence requirements, quality calculation, and evidence gap generation process as provided in one embodiment of this application.

[0093] The specific matching process includes: first, performing node matching based on the target object type and attribute conditions in the evidence conditions to obtain a candidate node set; then, performing edge matching or path matching between the candidate nodes based on graph relationship constraints to determine the object group that satisfies the relationship constraints; finally, comparing the evidence quality Q of each evidence object in the object group with the quality threshold of the evidence condition. If an object group exists and the Q of all necessary objects is not lower than the threshold, it is marked as quality satisfied; if an object group exists but the Q of at least one necessary object is lower than the threshold, it is marked as quality insufficient; if the object attributes or relationships obtained from different independent evidence collection paths contradict each other, it is marked as conflict; if no object group exists, it is marked as missing. Evidence gap status information is generated by summarizing each condition identifier, matching object identifier, status, quality difference, and conflict source.

[0094] S33. If there exists an object group that satisfies the target object type and the graph relationship constraint, but the evidence quality of at least one necessary memory evidence object in the object group does not reach the preset threshold, then the evidence condition is marked as insufficient in quality.

[0095] S34. If the object attributes or object relationships of memory evidence objects generated by different evidence collection paths are inconsistent, the corresponding evidence conditions will be marked as conflicting.

[0096] S35. If there is no memory evidence object that satisfies the target object type and graph relationship constraints, then the corresponding evidence condition is marked as missing.

[0097] S36. If the conditions for excluding evidence are met, the corresponding evidence condition is marked as evidence that has been excluded.

[0098] S37 If the evidence to be forcibly excluded has not yet been examined, then the corresponding evidence condition shall be marked as unexamined.

[0099] The evidence gap status information includes the following: the quality of each evidence condition is met, the quality is insufficient, there is a conflict, there is a missing condition, there is evidence that is excluded, or there is no checked status.

[0100] It should be noted that the evidence gap status information is a key data structure driving the closed-loop mechanism of this application. For each structured threat hypothesis, the security detection device matches each evidence condition in the necessary evidence set, the auxiliary evidence set, and the excluded evidence set with the in-memory evidence graph.

[0101] Unlike simply calculating confidence levels, this application categorizes evidence status into quality-satisfied, missing, insufficient, conflicting, excluded evidence hit, and unchecked, so that the scheduling module knows whether the next step is to supplement missing evidence, improve low-quality evidence, cross-validate conflicting evidence, or complete the exclusion evidence check.

[0102] It should be noted that the evidence gap status information includes condition identifier, condition role, matched evidence identifier, missing evidence type, current status, quality difference, source of conflict, whether it is a mandatory check item, and recommended action type. Because this information can be parsed by a computer, it can directly drive the selection of candidate evidence-gathering operations.

[0103] like Figure 4A As shown in the figure, this application provides a flowchart for determining a target forensics operation, as follows: Figure 4A As shown, the method for determining the target forensic operation provided in this application embodiment includes the following steps S41 to S43.

[0104] S41, calculate the coverage gain value of each candidate evidence collection operation on the evidence gap state information.

[0105] For example, the scheduling module first filters candidate forensic operations that do not meet operating system, permission, prerequisite dependencies, or security policies; then it calculates the coverage gain value of the candidate forensic operations on the current evidence gap state. The coverage gain value can be determined based on the weight of the missing evidence that the candidate forensic operation can fill, the weight of the low-quality evidence that it can improve, the weight of the conflicting evidence that it can verify, and the weight of the mandatory exclusion check that it can complete.

[0106] Specifically, the coverage gain value is the evidence gap coverage gain. For a candidate evidence collection operation a, it can be calculated as G(a)=Σi[Wi×Δi(a)], where Wi is the weight of the i-th unmet evidence condition, and Δi(a) represents the expected improvement in the condition after executing a; when a can supplement the missing condition to meet the quality requirement, Δi(a) is 1; when it can only improve the quality deficiency condition to near the threshold, Δi(a) is a predicted value between 0 and 1; when a can provide independent verification of conflicting conditions or complete mandatory exclusion checks, it is included according to the corresponding preset weight. The predicted value is determined by the evidence types that can be generated registered by the evidence collection capability object, the historical plugin success rate, the current image integrity, and the accessibility of the target object.

[0107] The scheduling module selects operations that can fill the current evidence gap based on the type of evidence that can be generated, the scope of execution, prerequisites, costs, risks, and independence.

[0108] The forensic capability object is a pre-registered capability description record, not an executable instruction generated by a large language model. It is used to limit the applicable platform, supplementary evidence types, input object range, prerequisite dependencies, costs, risks, and independence of candidate forensic operations before determining the target forensic operation. After selecting the target forensic operation, the scheduling module maps the target forensic operation to the read-only forensic plugin, plugin version, and restricted execution parameters registered in the forensic capability object. Therefore, "the capability object is used for candidate generation and constraints, the target forensic operation is used for sorting and selection, and the plugin and parameter mapping is used for actual execution," and these three are sequentially linked.

[0109] Among them, the information on evidence gaps includes missing status, insufficient quality status, conflict status, and unchecked status.

[0110] S42, calculate the operation score of the candidate forensic operation based on the coverage gain value, expected uncertainty reduction, degree of evidence independence, expected execution cost, and execution risk.

[0111] For example, the calculation formula for the operation score of candidate forensic operation a is as follows:

[0112] S(a)=α×G(a)+β×I(a)+γ×V(a)-δ×T(a)-ε×Rr(a),

[0113] Wherein, G(a) is the evidence gap coverage gain, I(a) is the expected reduction in uncertainty, V(a) is the degree of evidence independence, T(a) is the expected execution cost, Rr(a) is the execution risk, and α, β, γ, δ, and ε are non-preset weights. I(a) is determined by how many high-weight evidence conditions are expected to change from missing, insufficient quality, or conflicting states to a decidable state by this operation; V(a) is determined by whether it uses a different underlying memory structure, different plug-in path, or different data source than existing evidence; T(a) and Rr(a) are obtained from the historical runtime, memory usage, permission requirements, and impact level on the target system of the evidence collection capability object.

[0114] Where α, β, γ, δ, and ε are all non-negative preset weights, and satisfy α+β+γ+δ+ε=1; each index is normalized to the interval between 0 and 1 before calculation. To facilitate the selection of candidate operations using a unified threshold, the normalized operation score Sn(a)=[S(a)+δ+ε] / (α+β+γ+δ+ε) can be further calculated, so that Sn(a) is in the interval between 0 and 1, and Sn(a) represents the normalized operation score.

[0115] Please see Figure 4B , Figure 4B The diagram shown is a flowchart of the target forensics operation determination and execution mapping provided in an embodiment of this application.

[0116] Depend on Figure 4B It can be seen that candidate operations are first screened based on the evidence collection capability, then the evidence gap coverage gain and normalized operation score are calculated, the target evidence collection operation is selected according to preset conditions, and it is mapped to whitelist plugins and restricted parameters for execution.

[0117] It should be noted that when the evidence gap status information points to a specific process, thread, or memory region, the scheduling module restricts the execution scope of the target forensic operation to the corresponding address space, object set, or physical page range, rather than rescanning the entire memory image. This reduces irrelevant forensic operations and redundant scans.

[0118] It should be noted that when the evidence gap status information is conflicting, the scheduling module prioritizes candidate forensic operations that differ from the forensic path that generated the conflicting evidence and have a different underlying memory structure. For example, if the thread entry point obtained by linked list enumeration is inconsistent with the scan result, then an independent verification operation based on page table or execution context is prioritized.

[0119] S43, among the candidate forensic operations that meet the prerequisites, permission conditions and security policies, select the candidate forensic operation whose operation score meets the preset conditions as the target forensic operation.

[0120] Specifically, prerequisites include at least target operating system matching, availability of required symbols or page table information, and location of the target process or target address range; permission conditions include at least that the current analysis account has permission to read the corresponding image data; and security policies include at least that the operation belongs to a pre-registered whitelist, is a read-only operation, and its execution scope does not exceed the target object and resource budget. Preset conditions can be that the normalized operation score Sn(a) is not lower than a scoring threshold and ranks in the top N among candidate operations, or that the expected improvement in the state of at least one necessary evidentiary condition reaches a set threshold within the budget; for example, operations with Sn(a) not lower than 0.60 and ranking in the top 1 to 3 can be selected as target forensic operations.

[0121] like Figure 5 As shown in the figure, this application embodiment provides a flowchart for outputting security detection results, such as... Figure 5 As shown, the method for outputting security detection results provided in this application embodiment includes the following steps S51 to S52.

[0122] S51, if the updated evidence gap status information does not meet the stopping condition, control the large language model to correct the structured threat hypothesis and the evidence requirement set based on the updated abnormal evidence subgraph, and repeat the steps of determining and executing the target evidence collection operation.

[0123] For example, in Windows process injection detection, the first round of anomaly evidence subgraph only contains the private executable memory region R3412 and the abnormal parent-child relationship. The model generates the "process injection" hypothesis and proposes "the thread entry point is located in R3412" as necessary supplementary evidence. After thread scanning, it is found that the entry address of thread T901 is located in R3412. After reverse association of the handle, evidence of a high-privilege handle is obtained. The system fills the anomaly evidence subgraph with T901 and the handle node. After the update, the subgraph adds the edges "thread entry point is located" and "high-privilege reference". Based on this, the model converts the original evidence to be supplemented into necessary evidence that has been satisfied, and deletes the unnecessary duplicate thread enumeration requirement, while retaining the just-in-time compilation region check as a condition for mandatory exclusion of evidence.

[0124] S52, if the stopping condition is met, the structured threat hypothesis is verified using preset deterministic evidence conditions, and a security detection result bound to the memory evidence object is output.

[0125] The deterministic evidence conditions are combinations of conditions corresponding to the attack type, which can be evaluated by the rule engine on the memory evidence graph using Boolean rules, rather than natural language conclusions from a large language model. Taking process injection as an example, deterministic evidence conditions may include: the existence of a private executable memory region; the existence of a thread whose entry address falls within that region; the region, thread, and target process satisfying a preset ownership or entry point relationship; the quality of each necessary piece of evidence not lower than the corresponding threshold; and the completion of mandatory exclusion evidence checks such as just-in-time compilation regions, trusted security software, and legitimate debugging behavior without any match. The rule engine outputs "Threat hypothesis established" only when all the above conditions are met; if exclusion evidence verified by an independent path is found, it outputs "Threat hypothesis excluded"; if the budget is exhausted or the key evidence is still insufficient, it outputs "Insufficient evidence".

[0126] In some embodiments, the stopping conditions include a confirmed stopping condition, an exclusion stopping condition, and an insufficient evidence stopping condition; the confirmed stopping condition includes all necessary evidence reaching the corresponding evidence quality threshold and all mandatory exclusion evidence checks being completed without hitting any excluded evidence; the exclusion stopping condition includes hitting excluded evidence verified through an independent evidence collection path; the insufficient evidence stopping condition includes reaching the loop count, time budget, or resource budget, the expected information gain of the candidate evidence collection operation being lower than a threshold, or the image quality of the memory image being lower than the threshold for continuing parsing.

[0127] The confirmation stopping condition also includes that all evidence identifiers used for the final result exist in the current memory evidence graph.

[0128] The security detection results include whether the threat hypothesis is true, whether the threat hypothesis is excluded, or whether the evidence is insufficient. These results can also be linked to evidence identifiers, mirror hashes, memory addresses, forensic operation versions, execution parameters, and original output indexes. When necessary evidence is missing or of insufficient quality, the output "insufficient evidence" is displayed instead of "no threat found." When exclusionary evidence is found, the output "excluded" or "risk level reduced." Only when necessary evidence is met and the mandatory exclusion check fails to detect a threat hypothesis is displayed.

[0129] It should be noted that this application divides the cessation conditions into confirmed cessation conditions, excluded cessation conditions, and insufficient evidence cessation conditions, in order to avoid misjudging the lack of evidence as the absence of an attack, and to avoid prematurely confirming the attack when excluded evidence has not been examined.

[0130] Please see Figure 6 , Figure 6 The diagram shown is a flowchart of the evidence gap closure analysis for a large language model provided in an embodiment of this application. Figure 6 The specific execution steps are shown in Figures 1 to 14 above. Figure 5 The details have already been explained in the previous document, and will not be repeated here.

[0131] The scope of protection of the memory image security analysis method described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0132] This application also provides a memory image security analysis device, which can implement the memory image security analysis method described in this application. However, the implementation device of the memory image security analysis method described in this application includes, but is not limited to, the structure of the memory image security analysis device listed in this embodiment. All structural modifications and substitutions of the prior art made based on the principles of this application are included within the protection scope of this application.

[0133] like Figure 7 As shown, in one embodiment, the memory image security analysis device 70 of this application includes a memory image acquisition module 71, a memory evidence graph construction module 72, a structured hypothesis generation module 73, an evidence gap state information generation module 74, a target evidence collection operation determination module 75, an evidence collection execution module 76, an evidence update module 77, and a security detection result output module 78.

[0134] The memory image acquisition module 71 is used to acquire the memory image of the electronic device under test.

[0135] The memory evidence graph construction module 72 is used to construct the memory evidence graph corresponding to the memory image.

[0136] The structured hypothesis generation module 73 is used to extract anomaly evidence subgraphs from the memory evidence graph and input the anomaly evidence subgraphs into the large language model to obtain the structured threat hypothesis and evidence requirement set output by the large language model according to the preset structured mode.

[0137] The evidence gap status information generation module 74 is used to match the evidence requirement set with the memory evidence graph to generate evidence gap status information.

[0138] The target evidence collection operation determination module 75 is used to determine the target evidence collection operation from multiple candidate evidence collection operations corresponding to the pre-registered evidence collection capability objects based on the evidence gap status information.

[0139] The evidence collection execution module 76 is used to map the target evidence collection operation to a pre-registered evidence collection plugin and execution parameters, and use the evidence collection plugin and execution parameters to execute the target evidence collection operation on the memory image to obtain new evidence collection data.

[0140] The evidence update module 77 is used to convert the newly added evidence data into a new memory evidence object, fill the new memory evidence object back into the memory evidence graph, and update the abnormal evidence subgraph and the evidence gap status information based on the updated memory evidence graph.

[0141] The security detection result output module 78 is used to determine whether the stopping condition is met based on the updated evidence gap status information, and output the security detection result bound to the memory evidence object based on the stopping condition.

[0142] The structure and principle of the memory image acquisition module 71, the memory evidence graph construction module 72, the structured hypothesis generation module 73, the evidence gap state information generation module 74, the target evidence collection operation determination module 75, the evidence collection execution module 76, the evidence update module 77, and the security detection result output module 78 correspond one-to-one with the steps in the memory image security analysis method described above, and therefore will not be repeated here.

[0143] It should be noted that, to reduce the risk of injection vulnerabilities, the memory image security analysis device 70 marks command lines, strings, web page content, script content, and file paths extracted from the memory image as untrusted evidence data. This untrusted evidence data is only used as structured field values ​​input to the large language model and must not overwrite system instructions, forensic capability objects, or security policies.

[0144] System commands, forensic capability objects, and untrusted evidence data are placed in different security domains. These different security domains can be implemented through message role isolation, structured field isolation, permission tags, or system-level configurations that cannot be covered by evidence fields.

[0145] When the large language model outputs unregistered evidence types, object types, action types, or evidence identifiers, the pattern verification module rejects the output; when the large language model attempts to output real plugin names, system commands, file paths, or executable parameters, the scheduling module refuses to execute. Only read-only evidence operations pre-registered in the evidence-gathering capability object can be mapped to actual plugins and parameters by the scheduling module.

[0146] Please refer to Embodiment 1 of this application, Windows Process Injection Detection

[0147] In the Windows process injection detection embodiment, the memory image security analysis device 70 performs initial process enumeration, process tree parsing, module enumeration, network connection scanning and executable memory region parsing on the memory image, and finds that process P1260 has a private executable memory region R3412 that does not correspond to the loaded module, and the parent-child relationship of the process is abnormal.

[0148] The large language model generates the process injection hypothesis H003 based on an anomaly evidence subgraph including process P1260 and memory region R3412. Necessary evidence for this hypothesis includes a private executable memory region and the thread entry point located within that memory region; supporting evidence includes cross-process high-privilege handles and unmapped module code; exclusionary evidence includes known just-in-time (JIT) compilation regions, trusted security software, and legitimate debugging behavior.

[0149] The memory image security analysis device 70 compares the current evidence with the aforementioned evidence requirements to obtain the first round of evidence gap status: the private executable memory region is satisfied, the abnormal thread entry point is missing, the cross-process handle quality is insufficient, the unmapped module code is satisfied, and the exclusion checks for just-in-time (JIT) compiled regions have been completed and were not hit. Based on this, the scheduling module selects the target thread scan and handle reverse association operation, instead of executing all plugins unrelated to the current hypothesis.

[0150] The target thread scan yielded evidence E-THREAD-901, indicating that the entry address of thread T901 is located at R3412; the reverse handle association yielded evidence E-HANDLE-220, indicating that process P884 holds a high-privilege handle pointing to process P1260. After the new evidence was added and backfilled, all necessary evidence was satisfied, the forced exclusion check was completed and failed, and the deterministic verification module confirmed that the process injection hypothesis was valid.

[0151] Please refer to Example 2, Linux Fileless Attack Detection

[0152] In the Linux fileless attack detection embodiment, the memory image security analysis device 70 converts the task_struct task structure, VMA virtual memory region, and socket object into process evidence objects, memory region evidence objects, and network endpoint evidence objects, respectively. The aforementioned unified object type is consistent with the upper-level field definition in the Windows embodiment.

[0153] Initial evidence indicates that interpreter process P2100 contains an anonymous executable memory region R820 and an abnormal external link N33, but the current symbol confidence level is 0.45, which is lower than the set threshold of 0.70. Because the quality of thread evidence obtained based on the current symbol path is insufficient, the system will not directly use this thread evidence as evidence to confirm the attack.

[0154] The large language model generates interpreter-driven, fileless payload execution hypotheses and proposes evidence requirements such as execution context, anonymous region content, and network endpoint attribution. The scheduling module prioritizes page table scans, target address range content extraction, and socket reverse association operations that do not depend on the current low-confidence symbol path.

[0155] When new evidence proves that the anonymous region R820 contains an executable payload, that the execution flow enters R820, and that network endpoint N33 belongs to process P2100, the deterministic verification module confirms the corresponding threat hypothesis; when the anonymous region cannot be reliably resolved due to a mirror page fault, the system output shows an anomaly but insufficient evidence, rather than outputting that no threat was found.

[0156] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0157] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0158] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0159] This application also provides an electronic device. Figure 8 The diagram shown is a structural schematic of an electronic device 80 in one embodiment of this application. The memory mirroring security analysis method provided in this embodiment can be applied to... Figure 8 The electronic devices shown are 80, but not limited to these. For example... Figure 8As shown, the electronic device 80 includes a processor 81, a memory, a system bus 83, and a network interface 85. The memory may include a non-volatile storage medium 82 and internal memory 84.

[0160] The non-volatile storage medium 82 can store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to perform any of the memory mirror security analysis methods provided in the embodiments of this application.

[0161] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0162] The internal memory 84 provides an environment for the execution of computer programs in non-volatile storage media. When the computer program is executed by the processor, it enables the processor to perform any of the memory mirror security analysis methods provided in the embodiments of this application.

[0163] This network interface 85 is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0164] It should be understood that processor 81 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, the general-purpose processor can be a microprocessor or any conventional processor.

[0165] The electronic device 80 in this application embodiment may include terminal devices such as tablet computers, laptop computers, mobile phones, supercomputers, and smart wearable devices. It can also be applied to databases, servers, and service response systems based on terminal artificial intelligence. This application embodiment does not impose any restrictions on the specific type of electronic device.

[0166] For example, electronic devices can be stations (STs) in WLANs, cellular phones, cordless phones, Session Initiation Protocol (SIP) phones, Wireless Local Loop (WLL) stations, handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, computers, laptops, handheld communication devices, handheld computing devices, and / or other devices for communicating over wireless systems, as well as next-generation communication systems, such as mobile terminals in 5G networks, mobile terminals in future evolved Public Land Mobile Networks (PLMNs), or mobile terminals in future evolved Non-terrestrial Networks (NTNs).

[0167] This application also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0168] This application embodiment may also provide a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application embodiment are generated. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0169] When the computer program product is executed by a computer, the computer performs the method described in the foregoing method embodiments. The computer program product can be a software installation package; when the foregoing method is required, the computer program product can be downloaded and executed on the computer.

[0170] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0171] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A memory image security analysis method, characterized by, The method includes: Obtain the memory image of the electronic device under test; Construct the memory evidence graph corresponding to the memory image; The construction of the memory evidence graph corresponding to the memory image includes: identifying the operating system information, kernel version information, and symbol trust information corresponding to the memory image; determining at least one initial forensic operation based on the operating system information, kernel version information, and symbol trust information, and performing the initial forensic operation on the memory image to obtain heterogeneous forensic data; converting the heterogeneous forensic data into memory evidence objects of a preset type, and constructing a memory evidence graph based on the object association relationships between the memory evidence objects; An abnormal evidence subgraph is extracted from the memory evidence graph, and the abnormal evidence subgraph is input into the large language model to obtain the structured threat hypothesis and evidence requirement set output by the large language model according to the preset structured mode. The step of extracting anomaly evidence subgraphs from the memory evidence graph and inputting the anomaly evidence subgraphs into a large language model to obtain a set of structured threat hypotheses and evidence requirements output by the large language model according to a preset structured pattern includes: for memory evidence objects and object relationships in the memory evidence graph, calculating node anomaly scores and / or edge anomaly scores based on at least two of the following: memory region permissions, module mapping status, thread entry address, process parent-child relationship, network endpoint reputation, object cross-view consistency, normal baseline deviation, and evidence quality information; identifying memory evidence objects or object relationships whose node anomaly scores and / or edge anomaly scores meet preset anomaly conditions as anomaly seed evidence; extracting adjacent memory evidence objects and object relationships associated with the anomaly seed evidence from the memory evidence graph according to preset relationship types and preset hop count ranges, centered on the anomaly seed evidence, to obtain candidate anomaly evidence subgraphs; and pruning duplicate evidence objects in the candidate anomaly evidence subgraphs that meet the normal baseline. The abnormal evidence subgraph is obtained by performing branch or statistical summary processing and retaining the corresponding evidence identifier, evidence source information, original memory location information, and evidence quality information. Following a preset input template, the abnormal evidence subgraph is converted into structured prompt data including a node list, edge list, evidence identifier, object type, evidence quality, evidence source information, and security domain label. The structured prompt data, attack knowledge template, and preset structured pattern are input into the large language model, causing the large language model to output the structured threat hypothesis and the evidence requirement set. The structured threat hypothesis includes at least a hypothesis identifier, attack type, and target evidence object, and the evidence requirement set includes at least necessary evidence conditions, auxiliary evidence conditions, exclusion evidence conditions, and supplementary evidence conditions. Structured pattern verification, enumeration value verification, and evidence identifier existence verification are performed on the structured threat hypothesis and evidence requirement set output by the large language model. Upon successful verification, the structured threat hypothesis and evidence requirement set are obtained. The large language model outputs evidence requirements and action type suggestions, but does not output the real plugin name, system command, file path, or executable parameters; the real plugin and executable parameters are determined by the scheduling module based on the pre-registered evidence collection capability objects; The evidence requirement set is matched with the memory evidence graph to generate evidence gap status information; The step of matching the evidence requirement set with the memory evidence graph to generate evidence gap status information includes: for each evidence condition in the evidence requirement set, performing node matching and edge or path matching in the memory evidence graph according to the target object type and graph relationship constraints in the evidence condition; if there exists an object group that satisfies the target object type and the graph relationship constraints, and the evidence quality of all necessary memory evidence objects in the object group reaches a preset threshold, then the corresponding evidence condition is marked as quality satisfied; if there exists an object group that satisfies the target object type and the graph relationship constraints, but the evidence quality of at least one necessary memory evidence object in the object group is insufficient... If the quality of evidence does not meet the preset threshold, the evidence condition is marked as insufficient; if the object attributes or object relationships of memory evidence objects generated by different evidence collection paths are inconsistent, the corresponding evidence condition is marked as conflicting; if there is no memory evidence object that satisfies the target object type and graph relationship constraints, the corresponding evidence condition is marked as missing; if the exclusion evidence condition is met, the corresponding evidence condition is marked as hitting exclusion evidence; if the forced exclusion evidence has not yet been checked, the corresponding evidence condition is marked as unchecked; wherein, the evidence gap status information includes the quality satisfaction, quality insufficiency, conflict, missing, hitting exclusion evidence, or unchecked status of each evidence condition; Based on the evidence gap status information, the target evidence collection operation is determined from multiple candidate evidence collection operations corresponding to the pre-registered evidence collection capability objects; The step of determining the target forensic operation from multiple candidate forensic operations corresponding to pre-registered forensic capability objects based on the evidence gap status information includes: calculating the coverage gain value of each candidate forensic operation on the evidence gap status information; calculating the operation score of the candidate forensic operation based on the coverage gain value, expected uncertainty reduction, evidence independence degree, expected execution cost, and execution risk; and selecting the candidate forensic operation whose operation score meets preset conditions as the target forensic operation from among the candidate forensic operations that meet the prerequisite dependencies, permission conditions, and security policies. The target forensic operation is mapped to a pre-registered forensic plugin and execution parameters. The forensic plugin and execution parameters are used to perform the target forensic operation on the memory image to obtain new forensic data. The newly collected evidence data is converted into a new memory evidence object, the new memory evidence object is backfilled into the memory evidence graph, and the abnormal evidence subgraph and the evidence gap status information are updated based on the updated memory evidence graph; Based on the updated evidence gap status information, determine whether the stopping condition is met, and output the security detection result bound to the memory evidence object based on the stopping condition.

2. The method according to claim 1, characterized in that, The step of determining whether the stopping condition is met based on the updated evidence gap status information, and outputting the security detection result bound to the memory evidence object based on the stopping condition, includes: If the updated evidence gap status information does not meet the stopping condition, the large language model is controlled to correct the structured threat hypothesis and the evidence requirement set based on the updated abnormal evidence subgraph, and the steps of determining and executing the target evidence collection operation are repeated. If the stopping condition is met, the structured threat hypothesis is verified using preset deterministic evidence conditions, and a security detection result bound to the memory evidence object is output.

3. The method according to claim 2, characterized in that, The stopping conditions include confirmed stopping conditions, excluded stopping conditions, and stopping conditions due to insufficient evidence. The confirmation and cessation conditions include all necessary evidence reaching the corresponding evidence quality threshold and all mandatory exclusion evidence checks being completed without hitting any exclusion evidence. The exclusion cessation condition includes hitting excluded evidence that has been verified through an independent forensic path; The insufficient evidence stopping conditions include reaching the required number of iterations, time budget, or resource budget, the expected information gain of the candidate forensic operation being lower than a threshold, or the image quality of the memory image being lower than a threshold for continuing parsing.

4. A memory image security analysis device, characterized in that, The device includes: The memory image acquisition module is used to acquire the memory image of the electronic device under test. A memory evidence graph construction module is used to construct a memory evidence graph corresponding to the memory image. Constructing the memory evidence graph includes: identifying the operating system information, kernel version information, and symbol trust information corresponding to the memory image; determining at least one initial forensic operation based on the operating system information, kernel version information, and symbol trust information, and performing the initial forensic operation on the memory image to obtain heterogeneous forensic data; converting the heterogeneous forensic data into memory evidence objects of a preset type, and constructing a memory evidence graph based on the object association relationships between the memory evidence objects. A structured hypothesis generation module is used to extract anomaly evidence subgraphs from the memory evidence graph, and input the anomaly evidence subgraphs into a large language model to obtain a set of structured threat hypotheses and evidence requirements output by the large language model according to a preset structured pattern. The extraction of anomaly evidence subgraphs from the memory evidence graph and inputting them into the large language model to obtain the set of structured threat hypotheses and evidence requirements output by the large language model according to a preset structured pattern includes: calculating node anomaly scores and / or edge anomaly scores for memory evidence objects and object associations in the memory evidence graph, based on at least two of the following: memory region permissions, module mapping status, thread entry address, process parent-child relationship, network endpoint reputation, object cross-view consistency, normal baseline deviation, and evidence quality information; identifying memory evidence objects or object associations whose node anomaly scores and / or edge anomaly scores meet preset anomaly conditions as anomaly seed evidence; and extracting adjacent memory evidence objects and object associations associated with the anomaly seed evidence from the memory evidence graph, centered on the anomaly seed evidence, according to a preset relationship type and a preset hop count range. The relationship is used to obtain a candidate abnormal evidence subgraph; duplicate evidence objects in the candidate abnormal evidence subgraph that meet the normal baseline are pruned or statistically summarized, and the corresponding evidence identifier, evidence source information, original memory location information and evidence quality information are retained to obtain the abnormal evidence subgraph; according to the preset input template, the abnormal evidence subgraph is converted into structured prompt data including a node list, edge list, evidence identifier, object type, evidence quality, evidence source information and security domain label; the structured prompt data, attack knowledge template and the preset structured pattern are input into the large language model, so that the large language model outputs the structured threat hypothesis and the evidence requirement set, wherein the structured threat hypothesis includes at least a hypothesis identifier, attack type and target evidence object, and the evidence requirement set includes at least necessary evidence conditions, auxiliary evidence conditions, exclusion evidence conditions and supplementary evidence conditions; the structured threat hypothesis and the evidence requirement set output by the large language model are subjected to structured pattern verification, enumeration value verification and evidence identifier existence verification, and the structured threat hypothesis and the evidence requirement set are obtained after the verification is passed; The large language model outputs evidence requirements and action type suggestions, but does not output the real plugin name, system command, file path, or executable parameters; the real plugin and executable parameters are determined by the scheduling module based on the pre-registered evidence collection capability objects; An evidence gap status information generation module is used to match the evidence requirement set with the in-memory evidence graph to generate evidence gap status information. The matching of the evidence requirement set with the in-memory evidence graph to generate evidence gap status information includes: for each evidence condition in the evidence requirement set, performing node matching and edge or path matching in the in-memory evidence graph according to the target object type and graph relationship constraints in the evidence condition; if there exists an object group that satisfies the target object type and the graph relationship constraints, and the evidence quality of all necessary in-memory evidence objects in the object group reaches a preset threshold, then the corresponding evidence condition is marked as quality satisfied; if there exists an object that satisfies the target object type and the graph relationship constraints... If the quality of at least one necessary memory evidence object in the object group does not meet the preset threshold, the evidence condition is marked as insufficient quality; if the object attributes or object relationships of memory evidence objects generated by different evidence collection paths are inconsistent, the corresponding evidence condition is marked as conflicting; if there is no memory evidence object that satisfies the target object type and graph relationship constraints, the corresponding evidence condition is marked as missing; if the exclusion evidence condition is met, the corresponding evidence condition is marked as hitting exclusion evidence; if the forced exclusion evidence has not yet been checked, the corresponding evidence condition is marked as unchecked; wherein, the evidence gap status information includes the quality satisfaction, quality insufficiency, conflict, missing, hitting exclusion evidence, or unchecked status of each evidence condition; The target forensic operation determination module is used to determine a target forensic operation from multiple candidate forensic operations corresponding to pre-registered forensic capability objects based on the evidence gap status information. The determination of the target forensic operation from multiple candidate forensic operations corresponding to pre-registered forensic capability objects based on the evidence gap status information includes: calculating the coverage gain value of each candidate forensic operation on the evidence gap status information; calculating the operation score of the candidate forensic operation based on the coverage gain value, expected uncertainty reduction, evidence independence degree, expected execution cost, and execution risk; and selecting the candidate forensic operation whose operation score meets preset conditions from among the candidate forensic operations that satisfy prerequisite dependencies, permission conditions, and security policies as the target forensic operation. The evidence collection execution module is used to map the target evidence collection operation to a pre-registered evidence collection plugin and execution parameters, and use the evidence collection plugin and execution parameters to execute the target evidence collection operation on the memory image to obtain new evidence collection data; The evidence update module is used to convert the newly added evidence data into a new memory evidence object, fill the new memory evidence object back into the memory evidence graph, and update the abnormal evidence subgraph and the evidence gap status information based on the updated memory evidence graph; The security detection result output module is used to determine whether the stopping condition is met based on the updated evidence gap status information, and output the security detection result bound to the memory evidence object based on the stopping condition.

5. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 3.

6. An electronic device, characterized in that, The electronic device includes: A memory that stores a computer program; The processor, which is communicatively connected to the memory, executes the method of any one of claims 1 to 3 when the computer program is invoked.

Images