Memory detection method and system for virtual machine

By combining inter-process communication and the virtual machine manager interface, the problem of poor stability of the virtual machine memory detection system is solved, achieving efficient and stable memory security detection and avoiding the resource consumption and bypass risks of proxy software.

CN122173197APending Publication Date: 2026-06-09ALIBABA CLOUD COMPUTING CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
ALIBABA CLOUD COMPUTING CO LTD
Filing Date
2024-12-09
Publication Date
2026-06-09

Smart Images

  • Figure CN122173197A_ABST
    Figure CN122173197A_ABST
Patent Text Reader

Abstract

The application discloses a memory detection method and system of a virtual machine. The method is applied to a memory detection system, and the memory detection system is used for running a main process to execute the following method: in response to an inter-process communication request of at least one detection process, determining to-be-detected memory of a virtual machine; performing memory analysis on the to-be-detected memory according to a detection item, and obtaining an analysis result, wherein the analysis result comprises memory information of the to-be-detected memory under an operating system where the virtual machine is located; transmitting the analysis result to the detection process through inter-process communication between the main process and the detection process, wherein the analysis result is used for detection according to the detection item in the detection process, and a memory detection result is obtained; and obtaining the memory detection result corresponding to the analysis result through inter-process communication. The application solves the technical problem that the stability of a detection system for detecting memory of a virtual machine by relying on proxy software is poor.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of memory security detection technology, and more specifically, to a method and system for detecting memory in a virtual machine. Background Technology

[0002] Currently, cloud host security employs the same agent-based memory detection scheme as traditional information technology (IT) systems. This involves injecting a process into the client machine to collect information from its memory and perform security checks. However, injecting a process into the client machine consumes client resources, and if the malware is sophisticated enough, this process can be bypassed, resulting in poor stability of virtual machine memory detection systems.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method and system for detecting the memory of a virtual machine, so as to at least solve the technical problem of poor stability of virtual machine memory detection systems based on agent software in related technologies.

[0005] According to one aspect of the embodiments of this application, a virtual memory detection method is provided, applied to a memory detection system. The memory detection system runs a main process to execute the following methods: responding to inter-process communication requests from at least one detection process, determining the memory to be detected in a virtual machine, wherein the inter-process communication request is used to request information associated with detection items of the memory to be detected; parsing the memory to be detected according to the detection items to obtain a parsing result, wherein the parsing result includes memory information of the memory to be detected under the operating system of the virtual machine; transmitting the parsing result to the detection process through inter-process communication between the main process and the detection process, wherein the parsing result is used to perform detection according to the detection items in the detection process to obtain a memory detection result, the memory detection result being used to indicate the security level of the memory to be detected under the detection items; and obtaining the memory detection result corresponding to the parsing result through inter-process communication.

[0006] According to one aspect of the embodiments of this application, a virtual memory detection method is provided, applied to a memory detection system. The memory detection system runs a detection process to perform the following methods: transmitting an inter-process communication request to the main process via inter-process communication between the detection process and the main process of the memory detection system; wherein the inter-process communication request is used to request information associated with detection items of the memory to be detected in the virtual machine; the inter-process communication request is used to enable the memory detection system to determine the memory to be detected in the main process; the memory to be detected is used to enable the memory detection system to perform memory parsing according to the detection items in the main process, obtaining parsing results, the parsing results including memory information of the memory to be detected under the operating system of the virtual machine; obtaining the parsing results from the main process via inter-process communication; detecting the parsing results according to the detection items to obtain memory detection results, wherein the memory detection results are used to indicate the safety level of the memory to be detected under the detection items; and transmitting the memory detection results to the main process via inter-process communication.

[0007] According to another aspect of the embodiments of this application, a memory detection device for a virtual machine is also provided, comprising: a determining module, configured to determine the memory to be detected of the virtual machine in response to inter-process communication requests from at least one detection process, wherein the inter-process communication request is used to request information associated with detection items of the memory to be detected; a parsing module, configured to perform memory parsing on the memory to be detected according to the detection items to obtain a parsing result, wherein the parsing result includes memory information of the memory to be detected under the operating system of the virtual machine; and a first transmission module, configured to transmit the parsing result to the detection process through inter-process communication between the main process and the detection process, wherein the parsing result is used to perform detection according to the detection items in the detection process to obtain a memory detection result, wherein the memory detection result is used to indicate the security level of the memory to be detected under the detection items.

[0008] According to one aspect of the embodiments of this application, a virtual memory detection device is provided, comprising: a second transmission module, configured to transmit an inter-process communication request to the main process through inter-process communication between a detection process and the main process of a memory detection system, wherein the inter-process communication request is used to request information associated with detection items of the memory to be detected in a virtual machine, the inter-process communication request is used to enable the memory detection system to determine the memory to be detected in the main process, the memory to be detected is used to enable the memory detection system to perform memory parsing according to the detection items in the main process, and obtain parsing results, the parsing results including memory information of the memory to be detected under the operating system where the virtual machine is located; a second acquisition module, configured to acquire the parsing results from the main process through inter-process communication; a detection module, configured to detect the parsing results according to the detection items, and obtain memory detection results, wherein the memory detection results are used to indicate the security level of the memory to be detected under the detection items; and a third transmission module, configured to transmit the memory detection results to the main process through inter-process communication.

[0009] According to another aspect of the embodiments of this application, a virtual machine memory detection system is also provided, including a memory detection end and a memory parsing end. The memory detection end runs at least one detection process, and the memory parsing end runs a main process. The memory detection end is used to transmit an inter-process communication request to the main process through inter-process communication between the detection process and the main process. The inter-process communication request is used to request information associated with detection items of the memory to be detected in the virtual machine. The memory parsing end is used to respond to the inter-process communication request, determine the memory to be detected, and perform memory parsing on the memory to be detected according to the detection items to obtain a parsing result. The parsing result includes memory information of the memory to be detected under the operating system where the virtual machine resides. The memory detection end is used to obtain the parsing result from the main process through inter-process communication; and to detect the parsing result according to the detection items to obtain a memory detection result. The memory detection result is used to indicate the security level of the memory to be detected under the detection items.

[0010] According to another aspect of the embodiments of this application, a computer terminal is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0011] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0012] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0013] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0014] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0015] This application provides a method for detecting virtual machine memory, applied to a memory detection system. After responding to an inter-process communication request from at least one detection process, the method can determine information associated with the detection item in the memory to be detected within the virtual machine based on the inter-process communication request. Then, it performs memory parsing on the memory to be detected according to the detection item to obtain the parsing result. The parsing result includes the memory information of the memory to be detected under the operating system of the virtual machine. Subsequently, the parsing result is transmitted to the detection item process through inter-process communication between the main process and the detection process. After receiving the parsing result, the detection process can detect the detection item corresponding to the parsing result to obtain the memory detection result. After obtaining the memory detection result, the detection process can transmit the memory detection result to the main process through inter-process communication so that the main process can obtain the memory detection result corresponding to the parsing result. In other words, in this embodiment, an inter-process communication (IPC) connection is established between the detection process and the virtual machine. The detection process can obtain memory information under the operating system of the virtual machine through IPC requests, and then detect the memory information under the operating system of the virtual machine to obtain memory detection results. The memory detection results are then transmitted to the main process through IPC between the detection process and the main process. That is, outside the virtual machine, memory parsing logic and security detection logic can be decoupled through IPC. When the detection process detects the memory information under the operating system of the virtual machine, multiple detection processes are independent of each other and can be executed in parallel. If any detection process encounters an error or exception, it will not affect the normal operation of the main process or other detection processes, thus improving the stability (robustness) of the memory detection system. Furthermore, since there is no need to install agent software in the virtual machine, the potential performance overhead and the risk of being exploited or bypassed by malware are avoided, greatly reducing the resource consumption of the virtual machine. This achieves the goal of effectively detecting the memory security of the virtual machine, improving the memory detection efficiency of the virtual machine, and enhancing the stability and scalability of the virtual machine memory detection system. In turn, it solves the technical problem of poor stability of memory detection systems that rely on agent software to detect the memory of virtual machines in related technologies.

[0016] It is worth noting that the general description above and the detailed description that follow are merely for illustrative purposes and do not constitute a limitation on this application. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a memory detection method for a virtual machine according to an embodiment of this application.

[0019] Figure 2 This is a structural block diagram of a computing environment according to an embodiment of this application;

[0020] Figure 3 This is a structural block diagram of a service mesh according to an embodiment of this application;

[0021] Figure 4 This is a flowchart of a virtual machine memory detection method according to an embodiment of this application;

[0022] Figure 5 This is a flowchart of another virtual machine memory detection method according to an embodiment of this application;

[0023] Figure 6 This is a structural diagram of a virtual machine memory detection system according to an embodiment of this application;

[0024] Figure 7 This is a schematic diagram of the structure of a agentless memory detection system according to an embodiment of this application;

[0025] Figure 8 This is a schematic diagram of an interface organized hierarchically according to an embodiment of this application;

[0026] Figure 9 This is a schematic diagram of a memory detection process according to an embodiment of this application;

[0027] Figure 10 This is a flowchart of a detection method for checking whether a Java process has loaded a malicious dynamically loaded library, according to an embodiment of this application;

[0028] Figure 11 This is a schematic diagram illustrating the decoupling of detection logic and semantic reconstruction logic through a rule engine, according to an embodiment of this application.

[0029] Figure 12 This is a schematic diagram of a virtual machine memory detection device according to an embodiment of this application;

[0030] Figure 13 This is a schematic diagram of another virtual machine memory detection device according to an embodiment of this application;

[0031] Figure 14 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

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

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

[0034] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0035] Memory detection can uncover security threats or extract other valuable information from memory.

[0036] Security detection is the process of identifying security threats in computer systems.

[0037] Detection tasks, specifically security detection targeting a particular type of threat;

[0038] A process control block (PCB) is a structure in an operating system that stores runtime information about a process.

[0039] Semantic reconstruction refers to reconstructing high-level semantic information, such as process information, page tables, and network connection information, from the original physical memory.

[0040] Agent software refers to processes injected into virtual machines that can perform monitoring, security detection, and interception capabilities.

[0041] Agentless software refers to technologies that achieve monitoring, security detection, and other capabilities without relying on agent processes on the client machine.

[0042] A hypervisor (also known as a Virtual Machine Manager) is the software or firmware that runs on a host machine to create and run virtual machines. The hypervisor can be used to obtain the running status of virtual machines.

[0043] Virtual Machine Introspection (VMI) is a technology that allows virtual machine managers to monitor and manage the internal state of virtual machines. Through VMI, the operating data of virtual machines, such as memory, central processing unit (CPU), and disk, can be obtained without interfering with the operation of the virtual machine.

[0044] Agentless cloud server security technology, based on data such as the virtual machine's memory, CPU, and disk, enables multiple security detection capabilities outside the virtual machine without relying on agent software. Agentless cloud server security technology has the advantages of no performance loss for users and difficulty for malicious software to bypass.

[0045] According to an embodiment of this application, a method for detecting memory in a virtual machine is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0046] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a memory detection method for a virtual machine is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor (MCU) or a field-programmable gate array (FPGA), etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0047] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0048] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the method in the above embodiments. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0049] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0050] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0051] Figure 1 The hardware structure block diagram shown can serve not only as an exemplary block diagram of the aforementioned computer terminal 10 (or mobile device), but also as an exemplary block diagram of the aforementioned server. In one optional embodiment, Figure 2 The use of the above is illustrated in a block diagram. Figure 1 The computer terminal 10 (or mobile device) shown is an embodiment of a computing node in computing environment 201. Figure 2 A block diagram of a computing environment is shown, such as Figure 2 As shown, computing environment 201 includes multiple computing nodes (such as servers) running on a distributed network (shown as 210-1, 210-2, ... in the diagram). Each computing node contains local processing and memory resources, and end user 202 can remotely run applications or store data within computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 within computing environment 201, representing services "A", "D", "E", and "H", respectively.

[0052] End user 202 can provide and access services through a web browser or other software application on a client. In some embodiments, the provisioning and / or requests of end user 202 can be provided to ingress gateway 230. Ingress gateway 230 may include a corresponding agent to handle the provisioning and / or requests for services (one or more services provided in computing environment 201).

[0053] Services are provided or deployed based on various virtualization technologies supported by the computing environment 201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar methods. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While the machine is virtualized by a virtual machine, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance.

[0054] In one embodiment based on container virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). For example, such as Figure 2 As shown, service 220-2 can be equipped with one or more Pods 240-1, 240-2, ..., 240-N (collectively referred to as Pods). A Pod can include a proxy 245 and one or more containers 242-1, 242-2, ..., 242-M (collectively referred to as containers). One or more containers within a Pod handle requests related to one or more corresponding functions of the service. Proxy 245 typically controls service-related network functions such as routing and load balancing. Other services can also be equipped with similar Pods.

[0055] During operation, executing a user request from end user 202 may require invoking one or more services in computing environment 201, and executing one or more functions of one service may require invoking one or more functions of another service. For example... Figure 2 As shown, service "A" 220-1 receives user requests from terminal user 202 from ingress gateway 230. Service "A" 220-1 can call service "D" 220-2, and service "D" 220-2 can request service "E" 220-3 to perform one or more functions.

[0056] The aforementioned computing environment can be a cloud computing environment, where resource allocation is managed by cloud services, allowing functionality development without needing to consider implementation, adjustment, or server scaling. This computing environment allows developers to execute event-responsive code without building or maintaining complex infrastructure. Services can be partitioned into a set of functions that can automatically and independently scale, rather than scaling a single hardware device to handle potential loads.

[0057] In another alternative embodiment, Figure 3 The use of the above is illustrated in a block diagram. Figure 1 The computer terminal 10 (or mobile device) shown is an embodiment of a service mesh. Figure 3 A block diagram of a service mesh structure is shown, such as Figure 3 As shown, the service mesh 300 is mainly used to facilitate secure and reliable communication between multiple microservices. Microservices refer to the decomposition of an application into multiple smaller services or instances, which are distributed across different clusters / machines.

[0058] like Figure 3 As shown, a microservice may include application service instance A and application service instance B, which together form the functional application layer of service mesh 300. In one implementation, application service instance A runs as a container / process 308 on machine / workload container group 314 (Pod), and application service instance B runs as a container / process 310 on machine / workload container group 316 (Pod).

[0059] like Figure 3 As shown, application service instance A and grid agent (sidecar) 303 coexist in machine / workload container group 314, and application service instance B and grid agent 305 coexist in machine / workload container group 316. Grid agents 303 and 305 form the data plane layer of service mesh 300. Grid agents 303 and 305 run as containers / processes 304 and 306 respectively, and can receive requests 312 for determining the memory to be tested in virtual machines. Grid agent 303 and application service instance A can communicate bidirectionally, as can grid agent 305 and application service instance B. Furthermore, grid agents 303 and 305 can also communicate bidirectionally.

[0060] In one implementation, traffic from application service instance A is routed to the appropriate destination via mesh proxy 303, and network traffic from application service instance B is routed to the appropriate destination via mesh proxy 305. It should be noted that the network traffic mentioned here includes, but is not limited to, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), high-performance, general-purpose open-source frameworks (Google Remote Procedure Call, gRPC), and open-source in-memory data structure storage systems (Redis).

[0061] In one implementation, the functionality of the extended data plane layer can be achieved by writing custom filters for the agents (Envoy) in service mesh 300. The service mesh agent configuration can enable the service mesh to correctly proxy service traffic, achieving service interoperability and service governance. Mesh agents 303 and 305 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability.

[0062] like Figure 3 As shown, the service mesh 300 also includes a control plane layer. This control plane layer can consist of a set of services running in a dedicated namespace, hosted by a managed control plane component 301 within machine / workload container groups (machine / Pods) 302. Figure 3 As shown, the managed control plane component 301 communicates bidirectionally with grid agents 303 and 305. The managed control plane component 301 is configured to perform various control and management functions. For example, the managed control plane component 301 receives telemetry data transmitted from grid agents 303 and 305 and can further aggregate this telemetry data. In addition to these services, the managed control plane component 301 can also provide a user-facing Application Programming Interface (API) to facilitate easier manipulation of network behavior and the provision of configuration data to grid agents 303 and 305.

[0063] Under the aforementioned operating environment, this application provides the following: Figure 4 The virtual machine memory detection method shown is applied to a memory detection system. Figure 4 This is a flowchart of a virtual machine memory detection method according to an embodiment of this application.

[0064] Step S401: In response to inter-process communication requests from at least one detection process, determine the memory of the virtual machine to be detected.

[0065] In the technical solution provided in step S401 of this application, at least one detection process is located outside the virtual machine, and at least one detection process can communicate with the main process through inter-process communication (IPC). The inter-process communication request is used to request process information from the main process. This process information includes, but is not limited to, the following: a list of processes in the memory to be detected, detailed information about a specific process, the virtual address of the process, network connection information of the process, and a list of open files, etc., without specific limitations. It should be noted that the list of processes in the memory to be detected should at least include: basic information about the processes included in the list, such as process name, process identifier (ID), parent process ID, executable file path, and process startup parameters. Detailed information about a specific process should at least include: the ID of the specified process, basic information about the specified process, addresses and permissions of each memory segment of the specified process, and the mapped file path of the memory segment of the specified process. The virtual address of the process should at least include: the ID of the specified process, memory address, and read length. Among these methods, identifying all running processes through the process list in the memory to be inspected is fundamental for detecting security threats. For example, when inspecting a cryptocurrency mining program, an abnormal process with high CPU usage might be a mining program; when inspecting a Trojan horse program, a process communicating with a suspicious remote server might be a Trojan horse carrier. Detailed information about a specific process allows for a deeper analysis of its behavioral characteristics and resource usage, such as CPU utilization, open files, and network connections. By inspecting process information, it's possible to determine whether security threats exist in the virtual machine's memory, such as malware (e.g., rootkits), Trojan horses, ransomware, etc.

[0066] For example, when detecting a Trojan program, the detection process might request the following information: the process's network connection list, the executable file path and startup parameters, and the list of open files. Since Trojan programs typically need to communicate with external servers, obtaining the process's connection information can reveal unexpected network connections, which is a key clue for Trojan detection. By detecting whether the process's executable file comes from a legitimate path and whether the startup parameters are abnormal, well-disguised Trojan programs can be identified. Trojans may need to read and write specific files, such as log files and configuration files; obtaining the list of open files can reveal the Trojan's file access behavior. This is merely an example and does not limit the information requested by the detection process when detecting a particular item.

[0067] In this embodiment, the number of detection processes is variable. One detection item can correspond to one detection process. That is, one detection process is used to detect one detection item in the memory to be detected. Different detection items can correspond to different detection processes. Different detection processes can be executed in parallel, dynamically loaded, and independently updated to improve the scalability and robustness of the operating system.

[0068] Optionally, after the detection process starts, it can generate an inter-process communication request based on the items it wants to detect. This inter-process communication request follows the Hypertext Transfer Protocol (HTTP). After generating the inter-process communication request, the detection process can transmit it to the main process via inter-process communication (IPC) between the detection process and the main process. The inter-process communication uses Unix Domain Sockets (UDS) as the communication mechanism to achieve data transmission between the detection process and the main process. The UDS communication mechanism allows the detection process and the main process to establish a connection through pathnames in the file system, thereby enabling bidirectional data transmission.

[0069] Optionally, if the inter-process communication request requests a list of processes in the memory to be detected, the inter-process communication request needs to specify the virtual machine ID (vm-id). If the inter-process communication request requests detailed information about a specific process in the memory to be detected, the inter-process communication request needs to specify the virtual machine ID and the target process ID. If the inter-process communication request requests the virtual address of a specific process in the memory to be detected, the inter-process communication request needs to specify the virtual machine ID, the target process ID, and provide the starting address and length of the virtual memory of the process to be read in the path parameter.

[0070] Optionally, after receiving the inter-process communication request from the detection process, the main process can determine the virtual machine's memory to be detected based on the virtual machine ID carried in the inter-process communication request.

[0071] In this step, the security detection of the memory to be tested is divided into different detection items. Each detection item focuses on a specific security threat, such as rootkits, Trojans, ransomware, etc. This modular design makes the system easy to expand. New detection items can be easily added to deal with new security threats without modifying the logic of the main process or restarting the entire system, which greatly improves the system's flexibility and response speed.

[0072] Furthermore, since the detection process can be executed in parallel, this fully utilizes the capabilities of multi-core processors, enabling the simultaneous detection of multiple threat types and significantly accelerating the detection speed. Compared to single-process detection, this method can significantly reduce the total detection time and is particularly effective when dealing with large-scale virtual machine environments.

[0073] Step S402: Perform memory parsing on the memory to be tested according to the detection items, and obtain the parsing results.

[0074] In the technical solution provided in step S402 of this application, memory parsing can also be called semantic reconstruction. The specific process of memory parsing is to extract information associated with the detection items from the memory to be tested, and then parse and reconstruct higher-level, more semantically meaningful operating system runtime state data from the memory to be tested based on the extracted information associated with the detection items. Memory parsing is a prerequisite for memory security testing of the memory to be tested. Based on the high-level semantics obtained from memory parsing, various security checks can be performed on the detection items in the virtual machine's memory to be tested. For example, checking whether there are malicious processes in the virtual machine, or whether any process has loaded a dynamic link library containing malicious code. The parsing result includes the memory information of the memory to be tested under the operating system of the virtual machine. This memory information may include: a process list, detailed information about a process, the virtual address of a process, etc., without specific limitations here.

[0075] In this embodiment, after the main process determines the memory to be tested in the virtual machine, it can use the memory parser in the main process to perform memory parsing of the memory to be tested. The memory parser can read the process information in the memory to be tested in the virtual machine through the VMI interface provided by the hypervisor, and parse the read process information in the runtime environment provided by the hypervisor to obtain the parsing result.

[0076] Optionally, the memory parser can locate the kernel image starting address in the memory to be tested. This kernel image starting address is used to represent the starting address of the operating system image loaded in the memory to be tested. This kernel image starting address contains the code and data required for the operating system to run. When the operating system starts, the kernel image is loaded into the memory to be tested.

[0077] Optionally, after determining the kernel image's starting address, the memory resolver can locate various key kernel data structures based on the offsets between these structures and the kernel image's starting address. These key kernel data structures can include kernel page tables, process list starting addresses, etc., but this is merely an example and does not limit the specific key kernel data structures. Optionally, the offsets are determined based on the definitions of data structures used in different operating systems. After determining the operating system version, the offsets between each key kernel data structure and the kernel image's starting address can be determined based on the definitions of its key kernel data structures.

[0078] Optionally, since the process list links together the process control blocks (PCBs) of all active processes on the current operating system, and this PCB is a data structure of virtual machine memory, after locating the process list, it is possible to traverse the process list and read all currently existing processes, detailed process information, or information about each memory segment of the process in the memory to be tested based on the detection items. The detailed process information can be extracted from the PCB, and through this information, details such as the process name, process ID, executable file path, and startup parameters of each process can be obtained. The information about each memory segment indicates the start and end addresses and permissions of the process in the memory to be tested. For example, in mainstream operating systems, process memory segments are usually organized in the form of a binary tree. By obtaining the starting address of the binary tree from the PCB and traversing the binary tree of memory segments, the start and end addresses and permissions of each memory segment in a process's virtual memory space can be obtained. Based on this, memory parsing can be performed on the relevant content in the memory to be tested according to the information associated with the detection items in the inter-process communication request, and the parsing results can be obtained.

[0079] Optionally, after obtaining the parsing result corresponding to the detection item, the main process can send the parsing result back to the detection process.

[0080] In this step, memory parsing is performed on the memory to be tested according to the detection items. Only memory information directly related to the detection items can be parsed. For example, when setting a detection item, the type of threat to be detected and the types of memory information and data structures that need to be accessed to detect these threats can be determined. Then, after receiving an inter-process communication request for the detection item, the information associated with the memory information and data structures requested by the inter-process communication request can be parsed without performing full memory parsing. This avoids unnecessary data processing and transmission, allowing the detection process to quickly obtain detailed information about the required memory segments, thereby significantly improving detection efficiency and response speed. Moreover, it avoids injecting processes into the virtual machine to obtain the running status information in the memory to be tested, saving virtual machine memory space. Memory parsing can provide in-depth information about the running status of the virtual machine, providing data support for more efficient and comprehensive security detection.

[0081] Step S403: The parsing result is transmitted to the detection process through inter-process communication between the main process and the detection process.

[0082] In the technical solution provided by step S403 of this application, the main process provides different calling interfaces to the outside world (the detection process) to realize inter-process communication between the main process and the detection process. These interfaces may include: an interface for obtaining a process list, an interface for obtaining detailed information about a specific process, an interface for obtaining the virtual memory of a specific process, and an interface for reporting memory detection results. Each interface is used to transmit one type of memory information.

[0083] In this embodiment, after determining the parsing result through step S402, the detection process calls the interface provided by the main process for transmitting the parsing result to obtain it. This parsing result corresponds to the inter-process communication request in step S401.

[0084] Optionally, the interfaces are organized according to resource hierarchy, with the resource hierarchy being "virtual machine → process on the virtual machine → virtual memory of the process". For example, when a detection process requests an interface to obtain a list of processes, it needs to specify the virtual machine ID in the request path. In this case, the main process can return a list of processes through this interface, which may include basic information such as process name, process ID, parent process ID, file path, and startup parameters.

[0085] Optionally, when the detection process requests an interface to obtain detailed information about a certain process, it needs to specify the virtual machine ID and the target process ID in the request path. Based on this, the main process can return the basic information of the process (such as process name, process ID, parent process ID, file path, startup parameters) and the process's memory segment information (such as the start and end virtual addresses of each segment, access permissions, etc.) through this interface.

[0086] Optionally, when the detection process requests to call the interface to obtain the virtual memory of a certain process, it needs to specify the virtual machine ID, the target process ID, and the starting address and length of the virtual memory to be read in the request path parameter. Based on this, the main process can return a raw binary buffer through the interface, the content and length of which are the same as the virtual address and length specified in the parameter.

[0087] Optionally, the above method is a resource-oriented, hierarchical design, which makes the interface highly extensible. For example, to provide an interface for querying files opened by a specific process, a sub-resource type under the process of open files can be added; if an interface for querying all network connections on a virtual machine is to be provided, a resource type named network connections can be added under the virtual machine.

[0088] Optionally, after receiving the parsing result, the detection process can perform detection on the parsing result according to the detection items to obtain the memory detection result, which is used to indicate the safety level of the memory to be detected under the detection items.

[0089] For example, after the detection process calls the interface for listing processes to obtain the current process list, it can iterate through the list to find the ID of a specific process. After calling the interface describing process details to obtain the memory segment information for that process, the detection process can iterate through each memory segment, checking if each segment contains mapped files. For memory segments with mapped files, it checks the file paths and whether they contain suspected malicious dynamic libraries. For memory segments that contain suspected malicious dynamic libraries, the detection process calls the interface for reading virtual memory to obtain the virtual memory of the process in question. It can then detect whether there is malicious code in the virtual memory and generate memory detection results based on the results.

[0090] Optionally, after obtaining the memory detection results, the detection process can transmit the memory detection results to the main process through inter-process communication, so that the main process can obtain the memory detection results corresponding to the parsing results.

[0091] For example, as described above, the main process also provides an interface for reporting memory detection results. Based on this, after obtaining the memory detection results, the detection process can call the interface in the main process to report the memory detection results and send the memory detection results back to the main process.

[0092] Optionally, the calling interface provided by the main process enables the detection process to accurately obtain the virtual machine's memory information (parsing results), and then to detect the obtained memory information, thereby improving the accuracy of detecting security threats such as malicious processes and malicious code injection.

[0093] In steps S401 to S403 above, memory detection and memory parsing are both implemented outside the virtual machine. Specifically, memory parsing can read the virtual machine's memory through the VMI interface provided by the virtual machine manager and parse it in the runtime environment provided by the virtual machine manager to obtain the virtual machine's memory information. Then, through inter-process communication, the parsed memory information is transmitted to the memory detection process located outside the virtual machine for detection. The memory detection process performs the detection. The two parts are decoupled through inter-process communication, realizing the scalability and stability of the virtual machine's memory detection system.

[0094] The memory detection method for the virtual machine described above will be further introduced through specific implementation methods.

[0095] As an optional implementation, step S401, in response to an inter-process communication request from at least one detection process, determines the memory to be detected in the virtual machine, including: in response to the inter-process communication request, determining the interface corresponding to the inter-process communication request; and using the interface to call the virtual machine manager to read the memory to be detected.

[0096] In this embodiment, as described above, the main process provides different calling interfaces to the outside world (the detection process) to realize inter-process communication between the main process and the detection process. These interfaces may include: an interface for obtaining a process list, an interface for obtaining detailed information about a specific process, an interface for obtaining the virtual memory of a specific process, and an interface for reporting memory detection results. This is merely an example; the interfaces can be extended according to actual needs. The information associated with the item to be detected in the inter-process communication request may include, but is not limited to, the following: a list of processes in the memory to be detected, detailed information about a specific process, and the virtual address of the process. Based on this, after responding to the inter-process communication request from the detection process, the interface corresponding to the inter-process communication request can be determined based on the information associated with the item to be detected requested in the inter-process communication request.

[0097] For example, if the information associated with the detection item in the inter-process communication request is a list of processes in the memory to be detected, then the interface corresponding to the inter-process communication request can be determined to be the interface for obtaining the process list. Similarly, if the information associated with the detection item in the inter-process communication request is an interface for obtaining detailed information about a specific process in the memory to be detected, then the interface corresponding to the inter-process communication request can be determined to be the interface for obtaining detailed information about that specific process.

[0098] Optionally, after determining the interface corresponding to the inter-process communication request, the interface can be used to call the virtual machine manager to read the memory to be tested.

[0099] In this step, the detection process can use inter-process communication (IPC) via an interface to call the virtual machine manager to read the memory to be detected, achieving accurate acquisition of the memory information and avoiding resource waste. Furthermore, multiple detection processes can execute in parallel, improving the efficiency of reading the memory. This IPC method is also generally highly stable. Even if a detection process malfunctions, it will not directly affect the main process, thus improving the overall system robustness.

[0100] As an optional implementation, in response to an inter-process communication request, determining the interface corresponding to the inter-process communication request includes: obtaining the inter-process communication request through inter-process communication, and in response to the obtained inter-process communication request, determining the request path of the inter-process communication request, wherein the request path includes parameters for obtaining memory information, the memory information being used to represent the running state of the virtual machine; and determining the interface corresponding to the request path.

[0101] In this implementation, inter-process communication (IPC) is implemented through an interface provided by the main process. Once the main process receives an IPC request, it can determine the request path. This request path indicates the HTTP protocol followed by the interface corresponding to the IPC request. The request path includes parameters for obtaining memory information, which includes information about the virtual machine runtime, such as a process list, detailed information about a specific process, and the virtual memory of that process.

[0102] Optionally, if the inter-process communication request requests a list of processes associated with the detection items in the memory to be detected, then the request path of the inter-process communication request can be determined to include the virtual machine ID. Based on the virtual machine ID, the memory to be detected can be located, thereby obtaining the list of processes in the memory to be detected.

[0103] Optionally, if the information requested by the inter-process communication request to be associated with the detection item in the memory to be detected is detailed information of a certain process, then it can be determined that the request path of the inter-process communication request includes the ID of the virtual machine and the ID of the target process. Then, the memory to be detected can be located according to the ID of the virtual machine, and the ID of the target process can be located according to the ID of each process in the process list in the memory to be detected.

[0104] Optionally, after determining the request path, the interface corresponding to the request path can be determined. For example, if the request path includes the ID of the virtual machine whose memory is to be inspected, then the interface corresponding to the request path can be determined to be the interface for obtaining the process list. If the request path includes both the ID of the virtual machine whose memory is to be inspected and the ID of the target process, then the interface corresponding to the request path can be determined to be the interface for obtaining detailed information about a specific process.

[0105] As an optional implementation, the parsing results are transmitted to the detection process through inter-process communication between the main process and the detection process, including: transmitting memory information to the detection process through an interface via inter-process communication.

[0106] In this embodiment, after the main process performs memory parsing on the memory to be detected through the memory parser and obtains the parsing result, it can transmit the parsing result to the detection process through inter-process communication between the main process and the detection process.

[0107] Optionally, if the memory information included in the parsing result is a process list, the detection process can call the memory parsing interface provided by the main process (e.g., the interface for obtaining the process list) to obtain the process list for detection. The process list may include basic information such as process name, process ID, parent process ID, and executable file path.

[0108] Optionally, if the memory information included in the parsing result is detailed information about a certain process, the detection process can call the interface provided by the main process to obtain detailed information about the process. The detailed information about the process can include basic information such as process name, process ID, parent process ID, file path, and startup parameters, as well as memory segment information of the process. The memory field information of the process can include the start and end virtual addresses of each segment, access permissions, etc.

[0109] Optionally, if the memory information included in the parsing result is the virtual memory of a certain process, the detection process can call the interface provided by the main process to obtain the virtual memory of the process, thereby obtaining the virtual memory of the transmission process. The virtual memory of the process may include: a raw binary memory data segment (buffer), the memory and length of which are equal to the address and length of the virtual memory specified in the parameters.

[0110] As an optional implementation, step S402 involves parsing the memory to be tested according to the detection items to obtain the parsing results, including: obtaining a reference address from the data structure of the memory to be tested according to the detection items, wherein the reference address is used to represent the starting address of the operating system kernel in the memory to be tested; and determining the parsing results based on the reference address.

[0111] In this embodiment, the data structure of the memory to be inspected can be regarded as a raw bit array. During memory parsing, to extract meaningful information, it is necessary to reconstruct higher-level semantic information at the virtual machine operating system level from the memory to be inspected. This includes data structures such as PCB, page tables, kernel function addresses, and network connections. This reconstruction process is called memory parsing or semantic reconstruction. Memory parsing is a prerequisite for memory security testing of the memory to be inspected. Only after obtaining the higher-level semantics through parsing can various security checks be performed on the virtual machine's memory to be inspected, such as checking whether the virtual machine contains malicious processes or whether any processes have loaded dynamic link libraries containing malicious code.

[0112] Optionally, the reference address is used to indicate the starting address of the kernel image. As described above, the starting address of the kernel image is used to characterize the starting address of the virtual machine operating system image loaded into the memory to be detected.

[0113] Optionally, after determining the reference address in the memory to be detected, other key data structures can be located based on the reference address and the offset of other key data structures relative to the kernel image's starting address. Then, the process control block on the operating system can be reconstructed using the located key data structures.

[0114] As an optional implementation, the resolution result is determined based on the reference address, including: offsetting the reference address to obtain the address of at least one key data structure of the memory to be detected; using the key data structure to reconstruct the process control block on the operating system; and determining the memory information that satisfies the data structure corresponding to the process control block.

[0115] In this embodiment, the key data structure can be used to indicate the kernel page table and process list. This is merely an example and does not limit the key data structure. The offset between the key data structure address and the reference address can be determined according to the definition of the data structure of different operating systems. That is, as long as the version of the operating system is determined, the offset can be determined according to the definition of its key kernel data structure.

[0116] Optionally, after determining the offset of the key data structure address relative to the reference address, the reference address can be offset according to the offset to obtain the address of the key data structure in the memory to be detected.

[0117] Optionally, after determining the address of the key data structure in the memory to be tested, the PCB on the operating system is reconstructed using the key data structure. The PCB is a structure that stores process runtime information in the operating system. After reconstructing the PCB, the values ​​of each field in the PCB can be determined.

[0118] Alternatively, assuming the key data structure is a process list, since the process list links the PCBs of all active processes on the current operating system, based on this, all processes currently existing in the virtual machine can be read by traversing the process list, and the PCBs of each process can be reconstructed.

[0119] Optionally, after reconstructing the PCB of each process, the memory information that satisfies the data structure corresponding to the PCB can be further determined. For example, details such as the process name, process ID, executable file path, and startup parameters can be extracted from the process PCB. In mainstream operating systems, the memory segments of a process are usually organized in the form of a binary tree. By obtaining the starting address of the binary tree from the PCB and traversing the binary tree of the memory segments, information such as the start and end addresses and permissions of each memory segment in a process's virtual memory space can be obtained. For address segments with mapped files, information such as the file path can also be obtained.

[0120] As an optional implementation method, the virtual machine memory detection method also includes: obtaining detection items from the server; and loading the detection items into the detection process.

[0121] In this embodiment, after the memory detection task begins, the main process first retrieves the detection items from the server. These detection items can be scripts or binary files. Then, the retrieved detection items are loaded into the detection process.

[0122] Optionally, the number of detection items is variable, with one detection item corresponding to one dedicated detection process. Since the interface provided by the main process follows the HTTP protocol, which is widely supported by major programming languages, this makes the implementation of detection items more flexible; they can be Python scripts, binary executables, etc.

[0123] Optionally, after loading the detection item into the detection process, the detection process can generate an inter-process communication request based on the detection item, and then transmit the inter-process communication request to the main process to request information associated with the detection item from the main process.

[0124] As an optional implementation, the virtual machine memory detection method further includes: reloading the detection item to the detection process or deleting the detection item from the detection process in response to the detection item being in an abnormal state.

[0125] In this embodiment, the abnormal state of the detection item is used to indicate that the detection process has timed out during the detection of the detection item based on memory information. That is, the detection process has not completed the detection of the detection item within a predetermined time period, or the detection process has encountered an error when detecting the detection item. In both of these cases, the detection item is determined to be in an abnormal state.

[0126] Optionally, if a detection item is in an abnormal state, the detection item can be reloaded into the detection process, or the detection item can be removed from the detection process to release the detection process.

[0127] For example, by monitoring the running status of detection items, the system can release relevant resources in a timely manner when a detection item times out or encounters an error. For instance, if a detection item times out for some reason, the system can automatically terminate the detection item, releasing the CPU time, memory, and other resources it occupies, avoiding resource waste and ensuring the effective utilization of system resources.

[0128] In this step, the abnormal state monitoring mechanism of the detection items helps to enhance the robustness and stability of the system. When an error occurs in a detection item, the system can quickly identify it and take measures (such as reloading or deleting the detection item) to prevent the error from spreading, avoid the crash of the entire system or major processes, and ensure the continuous operation of the system.

[0129] As an optional implementation method, the virtual machine memory detection method further includes: obtaining the memory detection result corresponding to the parsing result through inter-process communication.

[0130] In this embodiment, after obtaining the memory detection result, the detection process can transmit the memory detection result to the main process through inter-process communication, so that the main process can obtain the memory detection result corresponding to the parsing result.

[0131] For example, as described above, the main process also provides an interface for reporting memory detection results. Based on this, after obtaining the memory detection results, the detection process can call the interface in the main process to report the memory detection results and send the memory detection results back to the main process.

[0132] In this step, once the detection process completes the memory detection, it can immediately transmit the memory detection results to the main process via IPC without waiting for the entire system detection process to complete, which makes the feedback of the detection results more real-time.

[0133] Under the aforementioned operating environment, this application provides the following: Figure 5 The virtual machine memory detection method shown is applied to a memory detection system, which runs a detection process to execute the following methods:

[0134] Step S501: Transmit an inter-process communication request to the main process through inter-process communication between the detection process and the main process of the memory detection system.

[0135] In the technical solution provided in step S501 of this application, inter-process communication between the detection process and the main process is achieved through a calling interface provided by the main process to the detection process. The inter-process communication request is used to request information associated with the detection items in the memory to be detected. These detection items may include, but are not limited to, the following: malware (e.g., rootkits), Trojan programs, ransomware, etc. This is merely an example and does not limit the specific content of the detection items. The information associated with the detection items in the inter-process communication request may include, but is not limited to, the following: a list of processes in the memory to be detected, detailed information about a specific process, and the virtual address of the process.

[0136] In this embodiment, the main process provides multiple calling interfaces to the detection process. These multiple calling interfaces may include: an interface for obtaining a process list, an interface for obtaining detailed information of a process, an interface for obtaining the virtual memory of a process, and an interface for reporting memory detection results, etc. This is only an example, and the calling interfaces provided by the main process can be extended.

[0137] Optionally, after generating an inter-process communication request, the memory detection system can select the interface to be called in the main process based on the information related to the detection item requested in the inter-process communication request, and then transmit the inter-process communication request to the main process.

[0138] For example, if the information requested in the inter-process communication request is the list of processes running in the virtual machine's memory to be detected, then it can be determined that the interface to be called in the main process is the interface for obtaining the process list, and then the interface for obtaining the process list in the main process is called to transmit the inter-process communication request.

[0139] Optionally, after receiving an inter-process communication request, the main process can parse the virtual machine's memory to be detected based on the information requested in the inter-process communication request that is associated with the detection item, and then obtain the parsing result, wherein the parsing result includes the memory information of the memory to be detected under the operating system where the virtual machine is located.

[0140] In this step, the security detection of the memory to be tested is divided into different detection items. Each detection item focuses on a specific security threat, such as rootkits, Trojans, ransomware, etc. This modular design makes the system easy to expand. New detection items can be easily added to deal with new security threats without modifying the logic of the main process or restarting the entire system, which greatly improves the system's flexibility and response speed.

[0141] Step S502: Obtain the parsing result from the main process through inter-process communication.

[0142] In the technical solution provided by step S502 of this application, as described in step S501, after receiving the inter-process communication request from the detection process, the main process can parse the inter-process communication request and obtain the parsing result. Since the inter-process communication between the main process and the detection process can realize bidirectional data transmission, based on this, after obtaining the parsing result, the main process can feed back the parsing result to the detection process through the interface for receiving inter-process communication requests.

[0143] Optionally, the detection process can receive the parsing results fed back by the main process.

[0144] In this step, inter-process communication (IPC) is used to separate the memory parsing logic (main process) from the security detection logic (detection process), allowing the two parts to be developed, tested, and updated independently. After the main process obtains the parsing results, it can transmit them to the detection process via IPC. This modular design improves the maintainability and scalability of the system.

[0145] Step S503: Detect the parsing results according to the detection items to obtain the memory detection results.

[0146] In the technical solution provided in step S503 of this application, a detection process is used to perform security detection on the memory to be detected according to a detection item. That is, one detection process corresponds to one memory detection result, whereby the memory detection result is used to indicate the security level of the memory to be detected under the detection item. As described above, the detection items may include, but are not limited to, the following: malicious software (e.g., rootkit), Trojan programs, ransomware, etc. In other words, the memory detection result can be used to indicate whether malicious software exists in the memory to be detected, or the memory detection result can be used to indicate whether Trojan programs exist in the memory to be detected. This is only an example.

[0147] In this embodiment, after receiving the parsing result, the detection process can perform detection on the parsing result according to the detection items to obtain the memory detection result. Based on this, if the detection item to be detected by the detection process is a Trojan program, the detection process can perform Trojan detection on the memory information process of the memory to be detected in the operating system of the virtual machine included in the parsing result to determine whether there is a Trojan program in the memory to be detected.

[0148] In this step, after receiving the parsing results, the detection process can perform detection on the parsing results according to the detection items. One detection process corresponds to one detection item, and multiple detection processes are independent of each other and execute in parallel. Even if one detection process has a problem, it will not affect other detection processes, thus improving the stability of memory detection.

[0149] Step S504: Transmit the memory detection results to the main process through inter-process communication.

[0150] In the technical solution provided in step S504 of this application, after the detection process obtains the memory detection result, it can transmit the memory detection result to the main process through inter-process communication between the main process and the detection process.

[0151] In steps S501 to S504 above, the memory parsing logic and the memory detection logic are decoupled through inter-process communication between the detection process and the main process of the memory detection system. This allows the memory detection logic to be updated independently and hot-updated, increasing the system's scalability, stability, and performance. Furthermore, since the memory parsing logic and the memory detection logic are decoupled, errors in the detection logic will not affect the main process, which increases the stability of the operating system. Moreover, the detection processes are independent of each other and can be executed in parallel, which also improves the efficiency of security detection of the memory to be detected.

[0152] As an optional implementation, the memory detection method further includes updating the detection item in response to an update instruction for the detection item.

[0153] In this embodiment, the update instruction for the detection item can be sent by the management service, which is responsible for managing the detection items. Before each detection begins, the main process requests the detection items and detection configuration from the management service. The management service then sends an update instruction for the detection items to the main process based on their update and release status. This update instruction may include the latest detection item, which exists in file format. After receiving the update instruction, the main process can update the detection item.

[0154] Optionally, each detection item can be independent, executed in parallel, dynamically loaded, and updated independently. This design improves the system's scalability and robustness.

[0155] Under the aforementioned operating environment, this application provides the following: Figure 6 The virtual machine memory detection system 600 shown includes: a memory detection end 601 and a memory parsing end 602. The memory detection end runs at least one detection process, and the memory parsing end runs a main process.

[0156] The memory detection terminal 601 is used to transmit an inter-process communication request to the main process through inter-process communication between the detection process and the main process. The inter-process communication request is used to request information associated with the detection items of the virtual machine's memory to be detected.

[0157] The memory parsing end 602 is used to respond to inter-process communication requests, determine the memory to be tested, perform memory parsing on the memory to be tested according to the detection items, and obtain the parsing results. The parsing results include the memory information of the memory to be tested under the operating system of the virtual machine. The memory detection end is used to obtain the parsing results from the main process through inter-process communication; and to detect the parsing results according to the detection items to obtain the memory detection results. The memory detection results are used to indicate the security level of the memory to be tested under the detection items.

[0158] In this embodiment, inter-process communication (IPC) between the detection process and the main process is implemented through a calling interface provided by the main process to the detection process. The IPC request is used to request information associated with the detection items in the memory to be detected. These detection items may include, but are not limited to, the following: malware (e.g., rootkits), Trojans, ransomware, etc. This is merely an example and does not limit the specific content of the detection items. The information associated with the detection items in the IPC request may include, but is not limited to, the following: a list of processes in the memory to be detected, detailed information about a specific process, and the virtual address of the process.

[0159] Optionally, the main process provides multiple calling interfaces to the detection process. These interfaces may include: an interface for obtaining a process list, an interface for obtaining detailed information about a specific process, an interface for obtaining the virtual memory of a specific process, and an interface for reporting memory detection results, etc. This is merely an example; the calling interfaces provided by the main process can be extended. After generating an inter-process communication request, the memory detection end can select the interface to be called in the main process based on the information related to the detection item requested in the inter-process communication request, and then transmit the inter-process communication request to the main process.

[0160] Optionally, after receiving an inter-process communication request, the memory parsing end can perform memory parsing on the memory to be tested according to the detection items contained in the inter-process communication request, and then obtain the parsing result.

[0161] Optionally, the memory detection client runs multiple detection processes, each of which performs a security check on the memory to be tested according to a specific detection item. After the main process obtains the parsing results, the memory detection client can obtain the parsing results from the main process through inter-process communication between the detection processes and the main process, and then perform the tests according to its own corresponding detection items to obtain the memory detection results.

[0162] Optionally, after obtaining the memory detection results, the memory detection end can transmit the memory detection results to the main process through inter-process communication.

[0163] In the aforementioned virtual machine memory detection system, the memory detection end sends an inter-process communication (IPC) request to the memory parsing end via IPC between the detection process and the main process. Upon receiving the IPC request, the memory parsing end parses the memory to be detected according to the request, obtaining the parsing result. After obtaining the parsing result, the memory parsing end transmits the parsing result to the memory detection end via IPC, which then performs memory detection according to the detection items, obtaining the memory detection result. After obtaining the memory detection result, it transmits the memory detection result back to the main process via IPC. In other words, by using IPC, the memory parsing process and the memory detection process are decoupled, allowing the memory detection logic to be updated independently and hot-updated, increasing the system's scalability, stability, and performance. Furthermore, because the memory parsing logic and the memory detection logic are decoupled, errors in the detection logic will not affect the main process, increasing the stability of the operating system. Moreover, the detection processes are independent of each other and can execute in parallel, which also improves the efficiency of security detection of the memory to be detected.

[0164] As an optional implementation, the memory parsing module includes an inter-process communication module and a memory parsing module. The inter-process communication module is used to respond to an inter-process communication request, determine the interface corresponding to the inter-process communication request, and use the interface to trigger the memory parsing module to call the virtual machine manager to read the memory to be detected. The memory parsing module is used to perform memory parsing on the read memory to be detected according to the detection items to obtain the parsing result.

[0165] In this embodiment, the Inter-Process Communication Server (IPC Server) is a specially designed server component that acts as a communication intermediary, handling and coordinating inter-process communication between the main process and the detection process. The IPC Server is implemented based on UDS and follows the semantics of the HTTP protocol, providing a standardized interface that enables the detection process to exchange data efficiently and reliably with the main process through a method similar to HTTP requests.

[0166] Optionally, the interfaces provided by the IPC Server may include: an interface for obtaining a list of processes, an interface for obtaining detailed information about a specific process, an interface for obtaining the virtual memory of a specific process, and an interface for reporting memory detection results. Since the information associated with the detection item in the inter-process communication request may include, but is not limited to, the following: a list of processes in the memory to be detected, detailed information about a specific process, and the virtual address of the process, based on this, after responding to the inter-process communication request of the detected process, the interface corresponding to the inter-process communication request can be determined according to the information associated with the detection item requested in the inter-process communication request.

[0167] Optionally, after determining the interface corresponding to the inter-process communication request, the inter-process communication request can be transmitted to the memory parsing module in the main process through the interface. After receiving the inter-process communication request, the memory parsing module can call the virtual machine manager to read the memory to be tested, and then perform memory parsing on the read memory to be tested according to the test items to obtain the parsing result.

[0168] As an optional implementation, the inter-process communication module is used to obtain an inter-process communication request through inter-process communication, and in response to the obtained inter-process communication request, determine the request path of the inter-process communication request, wherein the request path includes parameters for obtaining memory information, the memory information being used to represent the running state of the virtual machine; and determine the interface corresponding to the request path.

[0169] In this embodiment, inter-process communication (IPC) is implemented through an interface provided by the IPC Server. Once the IPC module receives an IPC request, it can determine the request path, which indicates the HTTP protocol followed by the interface corresponding to the IPC request. The request path includes parameters for obtaining memory information, which may include: a process list, detailed information about a specific process, and the virtual memory of a specific process.

[0170] Optionally, after determining the request path, the interface corresponding to the request path can be determined. For example, if the request path includes the ID of the virtual machine whose memory is to be inspected, then the interface corresponding to the request path can be determined to be the interface for obtaining the process list. If the request path includes both the ID of the virtual machine whose memory is to be inspected and the ID of the target process, then the interface corresponding to the request path can be determined to be the interface for obtaining detailed information about a specific process.

[0171] As an optional implementation, the inter-process communication module is used to transmit memory information to the detection process via an interface through inter-process communication.

[0172] In this embodiment, after obtaining the memory information of the memory to be detected, the inter-process communication module can use the interface provided by the main process to transmit the memory information to the detection process.

[0173] As an optional implementation, the memory parsing module is used to obtain a reference address from the data structure of the memory to be tested according to the detection item, wherein the reference address is used to represent the starting address of the operating system kernel in the memory to be tested; and the parsing result is determined based on the reference address.

[0174] In this embodiment, the reference address is used to indicate the starting address of the kernel image, which is located at the beginning of the memory to be detected.

[0175] Optionally, after determining the reference address in the memory to be detected, other key data structures can be located based on the reference address and the offset of other key data structures relative to the kernel image's starting address. Then, the process control block on the operating system can be reconstructed using the located key data structures.

[0176] As an optional implementation, the memory parsing module is used to offset the reference address to obtain the address of at least one key data structure of the memory to be detected; using the key data structure, the process control block on the operating system is reconstructed; and the memory information that satisfies the data structure corresponding to the process control block is determined.

[0177] In this embodiment, the key data structure can be used to indicate the kernel page table and the process list. The offset between the key data structure address and the reference address can be determined according to the definition of the data structure of different operating systems. That is, as long as the version of the operating system is determined, the offset can be determined according to the definition of its key kernel data structure.

[0178] Optionally, after determining the offset of the key data structure address relative to the reference address, the reference address can be offset according to the offset to obtain the address of the key data structure in the memory to be detected.

[0179] Optionally, after determining the address of the key data structure in the memory to be tested, the process control block (PCB) on the operating system can be reconstructed using the key data structure. The PCB is a structure in the operating system that stores runtime information about a process. The process of reconstructing the PCB using the key data structure can be found in the preceding description and will not be repeated here.

[0180] Optionally, after reconstructing the process control block on the operating system, process information can be extracted from it, such as process name, ID, executable file path, startup parameters, etc., without specific restrictions here.

[0181] As an optional implementation, the virtual machine memory detection system further includes: a server, and the memory parsing end further includes: a main control module. The memory detection end is used to transmit the memory detection results to the inter-process communication module through inter-process communication; the main control module is used to report the memory detection results from the inter-process communication module to the server; and the server is used to send the memory detection results to the client.

[0182] In this embodiment, the server is used to manage and control the detection items. For example, based on the update and release status of each detection item, it sends the latest detection items to the main process in the form of files. The server can also be referred to as a management and control service. The main control module is used to instruct the service management module (Master) in the main process.

[0183] Optionally, the memory detection end is used to transmit memory detection results to the inter-process communication module in the main process through inter-process communication between the detection process and the main process. After receiving the memory detection results, the inter-process communication module in the main process can report the memory detection results to the main control module.

[0184] Optionally, after receiving the memory detection results, the main control module can report the memory detection results to the server, which will then send the memory detection results to the device used by the customer so that the customer can understand whether there are any security risks in the virtual machine.

[0185] As an optional implementation, the main control module is used to obtain detection items from the server and load the detection items into the detection process.

[0186] In this embodiment, the main control module requests detection items and configurations from the server. The server, based on the update and release status of each detection item, sends the latest detection items to the main control module in the form of files. The main control module loads the detection items into the detection process, so that the detection process can detect the detection items in the memory to be detected. After the detection is completed, the memory detection results corresponding to each detection item are forwarded back to the server.

[0187] As an optional implementation, the main control module is used to start the inter-process communication module in response to inter-process communication requests.

[0188] In this embodiment, the main control module is used to start the inter-process communication module in the main process to respond to the inter-process communication request from the detection process and perform memory parsing according to the inter-process communication request.

[0189] As an optional implementation, the main control module is used to reload the detection item into the detection process or delete the detection item from the detection process in response to the detection item being in an abnormal state.

[0190] In this embodiment, the abnormal state of the detection item is used to indicate that the detection process has timed out when detecting the detection item based on memory information, or that an error occurred when the detection process detected the detection item. In both cases, it can be determined that the detection item is in an abnormal state.

[0191] Optionally, when a detection item is in an abnormal state, the detection item can be reloaded into the detection process, or the detection item can be deleted from the detection process to release the detection process.

[0192] As an optional implementation method, the multiple detection processes corresponding to multiple detection items are independent of each other.

[0193] In this embodiment, the number of detection items is variable. One detection item can correspond to one detection process. That is, one detection process is used to detect one detection item in the memory to be detected. Different detection processes can be independent of each other, can be executed in parallel, dynamically loaded, and independently updated to improve the scalability and robustness of the operating system.

[0194] The technical solutions of the embodiments of the present invention will be illustrated below with reference to preferred embodiments.

[0195] Currently, cloud host security widely adopts the same agent-based approach as traditional IT systems. This involves injecting a process into the virtual machine for information gathering and security countermeasures. Agent-based solutions consume user machine resources (CPU time, memory, etc.) and can be bypassed by malware. For example, in more extreme scenarios, if an attacker gains root access to the user machine, they can hijack system calls, preventing the agent from obtaining accurate information.

[0196] Agent-less memory detection products in related technologies are also based on VMI technology. They obtain the physical memory of the guest virtual machine (GVM) through a hypervisor, parse out information such as the process list and CPU usage of each process, and calculate information such as memory page hash values. This information is then sent to a rule analysis engine, which matches this information with specific security rules to identify various threats such as mining programs, Trojans, and rootkits. However, in this rule-based memory detection product, all detection logic is fixed in the rules. Due to the limited expressive power of the rules, it is difficult to implement complex detection logic like general-purpose programming languages.

[0197] However, this application proposes a scalable agentless memory detection method for virtual machines. This method involves setting up one or more detection processes outside the virtual machine. These detection processes communicate with the main process via IPC to request and obtain necessary memory information, CPU usage, disk activity, and other data. Based on this reconstructed information, the detection processes dynamically execute detection logic to determine whether security threats, such as rootkits, Trojans, or ransomware, exist in the memory. In other words, in this embodiment, detection items can be implemented as independent processes, can be executed in parallel, and have high scalability and robustness. Furthermore, it eliminates the need to inject processes into the virtual machine, saving virtual machine resources and avoiding the problem of malware bypassing detection. The communication between the detection processes and the main process via IPC decouples memory parsing and memory detection. Errors in the detection logic do not affect the main process, increasing system stability. The independent and parallel execution of detection items also improves detection performance, achieving the technical effect of effectively detecting cloud host memory security.

[0198] The agentless memory detection method for virtual machines in this application embodiment will be further described below.

[0199] This application utilizes the Virtual Machine Introspection (VMI) interface provided by the Hypervisor to obtain the physical memory of the virtual machine and perform security checks on it. Physical memory can be viewed as a raw bit array; to extract meaningful information from it, it is necessary to reconstruct higher-level semantic information at the operating system level from the physical memory. This includes data structures such as the Process Control Block (PCB), page tables, kernel function addresses, and network connections. This reconstruction process is referred to as memory resolution or semantic reconstruction.

[0200] Semantic reconstruction is a prerequisite for memory safety testing. Only by reconstructing high-level semantics can various security checks be performed on the virtual machine's memory. For example, checking for the presence of malicious processes within the virtual machine, or whether any process has loaded dynamic link libraries containing malicious code.

[0201] This application decouples semantic reconstruction from security detection logic, implementing the two in different processes and interacting through inter-process communication. This allows memory security detection to be dynamically loaded and independently updated as a plugin, improving the system's scalability and robustness.

[0202] Figure 7 This is a schematic diagram of the structure of a agentless memory detection system according to an embodiment of this application, such as... Figure 7As shown, the agentless memory detection system 700 includes a main process 701, a detection item process group 702, and a management service 703. The detection item process group 702 can contain multiple detection item processes depending on the number of specific detection items. The main process 701 is responsible for semantic reconstruction. The detection item processes call the semantic reconstruction capabilities provided by the main process on demand via IPC and perform security threat detection. The management service 703 is responsible for managing changes to detection items, distributing detection configurations, receiving detection results, and displaying the results to the client.

[0203] The following is a brief introduction to the main process 701 in the agentless memory detection system.

[0204] The main process is responsible for semantic reconstruction and the dynamic loading and management of detection item processes. The main process exposes the reconstructed results to the detection item processes via IPC and forwards the memory detection results reported by the detection item processes via IPC to the management service. For example... Figure 7 As shown, the main process consists of three logical modules: the memory parsing module (Parser), the inter-process communication module (IPC Server), and the service management module (Master).

[0205] The memory parsing module (Parser) will be introduced in more detail next.

[0206] The memory resolution module reads the physical memory of a specified virtual machine through the VMI interface provided by the virtual machine manager and performs semantic reconstruction. The specified virtual machine can be... Figure 7 Any one of the following: virtual machine 1, virtual machine 2, virtual machine 3, and virtual machine 4.

[0207] Optionally, the main process can first locate the kernel image's starting address in the virtual machine's physical memory. Then, based on the offsets of each key data structure in physical memory relative to the kernel image's starting address, it can locate the addresses of various key data structures. For example, the kernel page table and the process list's starting address. The process list links the Process Control Blocks (PCBs) of all active processes on the current operating system and is a data structure used by mainstream operating systems (Linux / Windows) to manage process runtime information. After determining the kernel page table, the kernel virtual addresses can be translated, allowing traversal of the process list and reconstruction of the PCBs of all processes.

[0208] Optionally, after obtaining the kernel page table and process list, the main process can further parse the kernel page table and process list to obtain detailed memory information of the virtual machine. This includes, for example, a list of processes running in the virtual machine's physical memory, detailed information about each process, and information about each memory segment of the process.

[0209] For example, by traversing the process list, all processes currently existing within GVM can be read. During this traversal, the Process Control Block (PCB) of each process can be reconstructed, allowing further access to details such as process name, ID, executable file path, and startup parameters. In mainstream operating systems, process memory segments are typically organized as binary trees. By obtaining the starting address of the binary tree from the PCB and traversing the memory segment binary tree, information such as the start and end addresses and permissions of each memory segment within a process's virtual memory space can be obtained. For address segments with mapped files, information such as the file path can also be obtained.

[0210] The inter-process communication module (IPC Server) will be introduced in more detail next.

[0211] The inter-process communication module is responsible for responding to semantic inter-process communication requests from the detection item processes. Based on the capabilities provided by the Parser, the IPC Server can return richer GVM runtime information for the detection items. For example, it can provide, but is not limited to, the following interfaces: an interface for obtaining a process list, an interface for obtaining detailed information about a specific process, an interface for reading the virtual address of a process, and an interface for reporting detection results. The interface for obtaining a process list returns a list of processes, including the following basic information: process name, process ID, parent process ID, executable file path, and startup parameters. The interface for obtaining detailed information about a specific process returns the specified process ID, basic process information, memory segment addresses and permissions, and the mapped file path of the memory segment. The interface for reading the virtual address of a process returns a raw binary buffer of the corresponding length based on the specified process ID, memory address, and read length. The interface for reporting detection results is used to report memory detection results.

[0212] Optionally, the inter-process communication module follows the HTTP protocol, routing requests to different interfaces based on their paths. These interfaces then call a combination of functions provided by the Parser to perform semantic reconstruction in response to the request. For ease of understanding and use, the IPCServer interface design follows the practices of REST (Representative State Transfer) APIs, employing a resource-oriented approach and organizing resources in a hierarchical structure. The resource hierarchy is "GVM - Virtual Machine Resources - Sub-resources".

[0213] Figure 8 This is a schematic diagram illustrating an interface organized hierarchically according to an embodiment of this application. For example... Figure 8As shown, suppose we want to read the IPC request URL for virtual memory with virtual address XXXXX and a length of 24 bytes under process number 4 on a virtual machine with ID XXXX. The resource hierarchy is "virtual machine - virtual machine resources - process sub-resources". This resource-oriented, hierarchical design makes the interface highly scalable. For example, to provide an interface for querying files opened by a specific process, we can add a sub-resource type named "opened-files" under that process; to provide an interface for querying all network connections on a GVM, we can add a resource type named "net-connections" under the virtual machine.

[0214] The following are examples of the interfaces provided by the inter-process communication module and the corresponding requests of the interfaces provided in the embodiments of this application.

[0215] Optionally, assuming a request is made to call the process list interface, the virtual machine's ID (vm-id) needs to be specified when sending the request. The server will return a list containing information about multiple processes, each including the process name, ID, parent process ID, executable file path, and other basic information. Through this interface, users can view detailed information about all processes running on the virtual machine, helping to monitor and manage the virtual machine's running status. This request can be represented as: GET / vms / vm-id / processes.

[0216] Optionally, assuming a request is made to call an interface describing detailed process information, the virtual machine ID and the target process ID must be provided in the request path. The returned information includes basic process information (such as process name, process ID, parent process ID, file path, and startup parameters) and memory segment information (such as the start and end virtual addresses of each segment, access permissions, etc.). This interface provides memory information to the detection process for a security check of the virtual machine's memory.

[0217] Optionally, assuming the interface requests the virtual memory of the calling process, the request path needs to specify the virtual machine ID and the target process ID, while the path parameter specifies the starting address and length of the virtual memory to be read. This interface returns a raw binary buffer with the same content and length as the virtual address and length specified in the parameters.

[0218] Optionally, assuming a request is made to call the interface for reporting detection results, the unique ID identifying this detection task and the name of the detection item should be specified in the request path. The detection results will be reported to the management service via the Master module of the main process.

[0219] Optionally, the above only shows the definitions of some interfaces. Depending on the resource hierarchy, interfaces such as "get all network connections on a specified GVM" and "get files opened by a specific process" can also be implemented. This can be achieved by simply adding new resource types to the corresponding resource directories. Since mainstream operating systems follow similar abstractions (processes, virtual memory, etc.), the IPC Server's interfaces are operating system neutral. Furthermore, unlike traditional HTTP, the IPC Server uses UDS instead of TCP as the transport protocol. The advantage of using UDS is that it eliminates the need for a complete TCP protocol stack, resulting in higher performance.

[0220] The service management module (Master) will be introduced in more detail next.

[0221] The Master module in the main process is the logic module on the main process, used for the dynamic loading, starting and scheduling of detection tasks, as well as the reporting of detection results.

[0222] Figure 9 This is a schematic diagram of a memory detection process according to an embodiment of this application. Figure 9 As shown, after the detection task begins, the main program first pulls detection items from the server. These items can be scripts or binary files. Then, the Master starts the IPC Server to prepare to respond to IPC requests from the detection items. Next, the Master schedules and manages each detection item, such as cleaning up or retrying timed-out or error-prone items. During operation, the detection process requests semantic information from the main process as needed via IPC. When the IPC Server responds to a semantic information request, it calls the Parser to reconstruct the specified semantic information. After each detection task is completed, the detection results are reported via IPC, forwarded by the IPC Server to the Master module for final reporting to the server. Different detection items can be implemented as different detection processes and can be executed in parallel, such as... Figure 7 The document displays three detection items: rootkit detection, Trojan detection, and ransomware detection.

[0223] The following section will further introduce the detection process group 702 in the agentless memory detection system.

[0224] The detection item process group 702 includes multiple detection item processes, the number of which is variable; one detection item can correspond to one dedicated detection process. Because the interface provided by the IPC Server follows the HTTP protocol, it is widely supported by various mainstream programming languages.

[0225] Optionally, Figure 10This is a flowchart illustrating a detection method for checking whether a Java process has loaded a malicious dynamically loaded library, according to an embodiment of this application. Figure 10 As shown, the detection process includes the following steps during execution:

[0226] Step S1001: Call the interface of the process list to obtain the current process list.

[0227] In this embodiment, after calling the interface of the process list to obtain the process list, the obtained process list can be traversed to find the ID of the Java process.

[0228] Step S1002: Call the interface describing process details to obtain the memory segment information of the Java process.

[0229] Step S1003: Traverse each memory segment of the Java process and check if there is a mapped file in each memory segment.

[0230] In this embodiment, mapped files are a technique used by the operating system to achieve efficient file reading and writing, memory sharing, and other goals. The principle is to map files into virtual memory, allowing processes to read and write files in user space by accessing virtual memory. Dynamic link libraries are typically loaded into memory as mapped files. For memory segments with mapped files, the file path is checked to determine if they are suspected malicious dynamic libraries.

[0231] Step S1004: For memory segments loaded with suspected malicious dynamic libraries, call the interface for reading virtual memory to detect whether there is malicious code in the memory.

[0232] Step S1005: Call the interface for reporting results and report the detection results.

[0233] In steps S1001 to S1005 above, each detection item is independent of the others and can be executed in parallel, dynamically loaded, and updated independently. This design improves the scalability and robustness of the system.

[0234] The following section will provide a further introduction to the management service 703 in the agentless memory detection system.

[0235] The management service is responsible for managing the detection items. Before each detection begins, the Master module of the main process requests the detection items and configuration from the management service. The management service then distributes the latest detection items to the main process in the form of files, based on the update and release status of each detection item. The main process starts the detection items into different processes and forwards the detection results reported by each detection item via IPC back to the management service after the detection is completed.

[0236] Optionally, the management service is also used to receive the detection results reported by the Master module of the main process, and to process the results and notify the user in the form of alarms, reports, etc.

[0237] Optionally, this application also provides an agentless memory detection method based on a rule engine, which mainly decouples memory security detection and memory parsing capabilities, allowing the two to be updated independently, and enabling the memory security detection logic to be updated dynamically. Figure 11 This is a schematic diagram illustrating the decoupling of detection logic and semantic reconstruction logic through a rule engine, according to this application. Figure 11 As shown, by defining detection items as a set of rules, a rule engine is added to the main process. After semantic reconstruction, the parser inputs system status information (such as process lists, network connections, etc.) into the rule engine, which then schedules and executes rule matching to detect security threats. Rules are typically declarative, such as YARA rules. The rules define the characteristics and judgment conditions of different threats. This rule engine solution achieves a similar effect to the IPC solution in decoupling detection logic from semantic reconstruction. However, its main drawback compared to the IPC solution is the limited expressive power of the rules. Its expressive power cannot compare with general-purpose programming languages, thus making it unable to implement some complex detection logic.

[0238] The key to this application lies in its use of IPC to completely decouple the memory security detection logic from the memory parsing logic. This allows the security detection logic to be updated independently and hot-updated, increasing the scalability, stability, and robustness of the operating system. Compared to agentless memory detection methods based on rule engines, the memory detection logic in this application can be implemented using a general-purpose programming language, without being limited by the expressive power of declarative rules, thus enabling the implementation of more complex detection logic.

[0239] The IPC in this application is compatible with the standard HTTP protocol, which makes the implementation of the memory parsing logic more flexible and allows for the use of various technology stacks. For example, it can be implemented using scripting languages ​​such as Python, or distributed as a binary executable file compiled from C / C++. This not only makes the system more adaptable to multi-team development, but also reduces the cost and makes adding new detection items more agile. In addition, since the detection logic is isolated from the main process, errors in the detection logic will not affect the main process, which increases the stability of the system; and since the detection items are independent of each other, they can be executed in parallel, which also improves the detection performance.

[0240] This application utilizes Virtual Machine Introspection (VMI) technology to access the physical memory of virtual machines on a cloud host in real time and perform security checks on the physical memory. Each check task is implemented as an independent process, meaning errors in one check task will not affect the main process, thus improving its stability. Furthermore, each check task interacts with a standardized, HTTP-compliant IPC interface during execution, dynamically calling IPC-provided interfaces for memory resolution and result reporting. This allows check items to be dynamically loaded and updated independently on demand.

[0241] For clients, on-demand detection can be implemented, running only the specified detection items, which can shorten detection time. For developers, detection items can be implemented in different programming languages ​​than the main process. For example, the main process can be implemented in higher-performance system-level programming languages ​​such as C++ / Rust, while detection items can be implemented in more flexible scripting languages ​​such as Python, thereby improving development efficiency, shortening change cycles, and reducing change costs.

[0242] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0243] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0244] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0245] According to an embodiment of this application, a memory detection device for a virtual machine that implements the above-described virtual machine memory detection method is also provided, such as... Figure 12 As shown, the memory detection device 1200 of the virtual machine includes: a determination module 1201, a parsing module 1202, and a first transmission module 1203.

[0246] The determination module 1201 is used to determine the memory to be detected in a virtual machine in response to an inter-process communication request from at least one detection process, wherein the inter-process communication request is used to request information associated with the detection items of the memory to be detected.

[0247] The parsing module 1202 is used to perform memory parsing on the memory to be tested according to the detection items and obtain the parsing results, including the memory information of the memory to be tested under the operating system of the virtual machine.

[0248] The first transmission module 1203 is used to transmit the parsing result to the detection process through inter-process communication between the main process and the detection process. The parsing result is used to perform detection according to the detection item in the detection process to obtain the memory detection result. The memory detection result is used to indicate the safety level of the memory to be detected under the detection item.

[0249] It should be noted that the aforementioned determining module 1201, parsing module 1202, and first transmission module 1203 correspond to steps S401 to S403 in the above embodiments. The three modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the aforementioned modules or units may be hardware or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The aforementioned modules may also be part of a device and run in the computer terminal 10 provided in the above embodiments.

[0250] It should be noted that the preferred embodiments involved in the above embodiments of this application are the same as the solutions, application scenarios and implementation processes provided in the above embodiments, but are not limited to the solutions provided in the above embodiments.

[0251] According to an embodiment of this application, a memory detection device for a virtual machine that implements the above-described virtual machine memory detection method is also provided, such as... Figure 13 As shown, the memory detection device 1300 of the virtual machine includes: a second transmission module 1301, a first acquisition module 1302, a detection module 1303, and a third transmission module 1304.

[0252] The second transmission module 1301 is used to transmit an inter-process communication request to the main process through inter-process communication between the detection process and the main process of the memory detection system. The inter-process communication request is used to request information associated with the detection items of the memory to be detected in the virtual machine. The inter-process communication request is used to enable the memory detection system to determine the memory to be detected in the main process. The memory to be detected is used to enable the memory detection system to perform memory parsing according to the detection items in the main process and obtain the parsing result. The parsing result includes the memory information of the memory to be detected under the operating system of the virtual machine.

[0253] The first acquisition module 1302 is used to acquire the parsing results from the main process through inter-process communication.

[0254] The detection module 1303 is used to detect the parsing results according to the detection items to obtain the memory detection results, wherein the memory detection results are used to indicate the safety level of the memory to be detected under the detection items.

[0255] The third transmission module 1304 is used to transmit the parsing results to the main process through inter-process communication.

[0256] It should be noted that the second transmission module 1301, the first acquisition module 1302, the detection module 1303, and the third transmission module 1304 mentioned above correspond to steps S501 to S504 in the above embodiments. The four modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and run in the computer terminal 10 provided in the above embodiments.

[0257] It should be noted that the preferred embodiments involved in the above embodiments of this application are the same as the solutions, application scenarios and implementation processes provided in the above embodiments, but are not limited to the solutions provided in the above embodiments.

[0258] Embodiments of this application may provide an electronic device, which may be any one of a group of electronic devices. Optionally, in this embodiment, the aforementioned electronic device may also be replaced by a terminal device such as a computer terminal.

[0259] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0260] In this embodiment, the computer terminal described above can execute the program code in the method.

[0261] Optionally, Figure 14 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 14 As shown, the electronic device A may include: one or more (only one is shown in the figure) processors 1402, memory 1404, memory controller, and peripheral interfaces, wherein the peripheral interfaces are connected to the radio frequency module, the audio module, and the display.

[0262] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to electronic device A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0263] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: responding to inter-process communication requests from at least one detection process, determining the virtual machine's memory to be detected, wherein the inter-process communication request is used to request information associated with detection items of the memory to be detected; performing memory parsing on the memory to be detected according to the detection items to obtain parsing results, wherein the parsing results include memory information of the memory to be detected under the operating system of the virtual machine; transmitting the parsing results to the detection process via inter-process communication between the main process and the detection process, wherein the parsing results are used to perform detection according to the detection items in the detection process to obtain memory detection results, wherein the memory detection results are used to indicate the security level of the memory to be detected under the detection items.

[0264] Optionally, the processor may also execute program code that performs the following steps: in response to an inter-process communication request, determines the interface corresponding to the inter-process communication request; and uses the interface to call the virtual machine manager to read the memory to be tested.

[0265] Optionally, the processor may also execute program code that performs the following steps: obtains an inter-process communication request through inter-process communication, and in response to the obtained inter-process communication request, determines the request path of the inter-process communication request, wherein the request path includes parameters for obtaining memory information, the memory information being used to represent the running state of the virtual machine; and determines the interface corresponding to the request path.

[0266] Optionally, the processor may also execute program code that performs the following steps: transmitting memory information to the detection process via an interface through inter-process communication.

[0267] Optionally, the processor may also execute program code that performs the following steps: obtaining a reference address from the data structure of the memory to be tested according to the detection item, wherein the reference address is used to represent the starting address of the operating system kernel in the memory to be tested; and determining the parsing result based on the reference address.

[0268] Optionally, the processor may also execute program code that performs the following steps: offsetting the reference address to obtain the address of at least one key data structure of the memory to be detected; using the key data structure to reconstruct the process control block on the operating system; and determining the memory information that satisfies the data structure corresponding to the process control block.

[0269] Optionally, the processor may also execute program code that reports the memory detection results to the server.

[0270] Optionally, the processor may also execute program code that performs the following steps: retrieves detection items from the server; loads the detection items into the detection process.

[0271] Optionally, the processor may also execute program code that performs the following steps: in response to an item being in an abnormal state, reloads the item into the detection process, or deletes the item from the detection process.

[0272] Optionally, the processor may also execute program code that performs the following steps: obtaining the memory detection result corresponding to the parsing result through inter-process communication.

[0273] This application provides a memory detection scheme for virtual machines. An inter-process communication (IPC) connection is established between the detection process and the virtual machine. The detection process can obtain memory information under the operating system of the virtual machine through IPC requests, and then detect the memory information under the operating system of the virtual machine to obtain memory detection results. The memory detection results are then transmitted to the main process through IPC between the detection process and the main process. That is, through IPC, the memory parsing logic and the security detection logic are decoupled. When detecting memory information under the operating system of the virtual machine, multiple detection processes run in parallel. If any one of the detection processes encounters an error or exception, it will not affect the normal operation of the main process or other detection processes, thus improving the stability (robustness) of the memory detection system. Moreover, there is no need to install agent software in the virtual machine for information collection and security countermeasures, which greatly reduces the resource consumption of the virtual machine and avoids the potential performance overhead and the risk of being exploited or bypassed by malware. It achieves the goal of effectively detecting the memory security of the virtual machine, improves the memory detection efficiency of the virtual machine, and enhances the stability and scalability of the virtual machine memory detection system. In turn, it solves the technical problem of poor scalability and stability of memory detection systems that rely on agent software to detect the memory of the virtual machine.

[0274] It will be understood by those skilled in the art that the structure shown in the figure is merely illustrative, and the electronic device may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal device. This figure does not limit the structure of the aforementioned electronic device. For example, electronic device A may include more or fewer components (such as a network interface, a display device, etc.) than shown in the figure, or may have a different configuration than shown in the figure.

[0275] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0276] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store program code executed by the method provided in the above embodiments.

[0277] Optionally, in this embodiment, the storage medium may be located in any one of the electronic devices in the group of electronic devices in the computer network, or in any one of the computer terminals in the group of computer terminals.

[0278] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: determining the virtual machine's memory to be tested in response to inter-process communication requests from at least one detection process, wherein the inter-process communication request is used to request information associated with detection items of the memory to be tested; performing memory parsing on the memory to be tested according to the detection items to obtain parsing results, wherein the parsing results include memory information of the memory to be tested under the operating system of the virtual machine; transmitting the parsing results to the detection process through inter-process communication between the main process and the detection process, wherein the parsing results are used to perform detection according to the detection items in the detection process to obtain memory detection results, and the memory detection results are used to indicate the security level of the memory to be tested under the detection items.

[0279] Optionally, the computer-readable storage medium is further configured to store program code for performing the following steps: in response to an inter-process communication request, determining the interface corresponding to the inter-process communication request; and using the interface, invoking the virtual machine manager to read the memory to be detected.

[0280] Optionally, the computer-readable storage medium is further configured to store program code for performing the following steps: obtaining an inter-process communication request via inter-process communication, and in response to the obtained inter-process communication request, determining a request path for the inter-process communication request, wherein the request path includes parameters for obtaining memory information, the memory information being used to represent the running state of the virtual machine; and determining an interface corresponding to the request path.

[0281] Optionally, the computer-readable storage medium is also configured to store program code for performing the following steps: transmitting memory information to the detection process via an interface through inter-process communication.

[0282] Optionally, the computer-readable storage medium is further configured to store program code for performing the following steps: obtaining a reference address from a data structure of the memory to be tested according to the test item, wherein the reference address is used to represent the starting address of the operating system kernel in the memory to be tested; and determining the parsing result based on the reference address.

[0283] Optionally, the computer-readable storage medium is further configured to store program code for performing the following steps: offsetting a reference address to obtain the address of at least one key data structure of the memory to be detected; using the key data structure to reconstruct the process control block on the operating system; and determining memory information that satisfies the data structure corresponding to the process control block.

[0284] Optionally, the computer-readable storage medium is also configured to store program code for performing the following steps: reporting memory detection results to the server.

[0285] Optionally, the computer-readable storage medium is also configured to store program code for performing the following steps: obtaining detection items from the server; loading the detection items into the detection process.

[0286] Optionally, the computer-readable storage medium is also configured to store program code for performing the following steps: reloading the detection item to the detection process in response to the detection item being in an abnormal state, or deleting the detection item from the detection process.

[0287] Optionally, the computer-readable storage medium is also configured to store program code for performing the following steps: obtaining memory detection results corresponding to the parsing results through inter-process communication.

[0288] Embodiments of this application also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the methods provided in the embodiments described above.

[0289] Embodiments of this application also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which can be used to store a computer program that, when executed by a processor, implements the method provided in the above embodiments.

[0290] Embodiments of this application also provide a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it implements the method provided in the above embodiments.

[0291] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0292] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0293] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0294] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0295] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0296] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for detecting memory in a virtual machine, characterized in that, This is applied to a memory detection system, which runs a main process to perform the following methods: Responding to an inter-process communication request from at least one detection process, the virtual machine's memory to be detected is determined, wherein the inter-process communication request is used to request information associated with the detection items of the memory to be detected; The memory to be tested is parsed according to the detection items to obtain the parsing result, wherein the parsing result includes the memory information of the memory to be tested under the operating system of the virtual machine; The parsing result is transmitted to the detection process through inter-process communication between the main process and the detection process. The parsing result is used to perform detection according to the detection item in the detection process to obtain a memory detection result. The memory detection result is used to indicate the security level of the memory to be detected under the detection item.

2. The method according to claim 1, characterized in that, In response to inter-process communication requests from at least one detection process, determine the virtual machine's memory to be detected, including: In response to the inter-process communication request, determine the interface corresponding to the inter-process communication request; Using the aforementioned interface, the virtual machine manager is invoked to read the memory to be detected.

3. The method according to claim 2, characterized in that, In response to the inter-process communication request, determining the interface corresponding to the inter-process communication request includes: The process obtains the inter-process communication request through the inter-process communication, and in response to the obtained inter-process communication request, determines the request path of the inter-process communication request, wherein the request path includes parameters for obtaining the memory information, and the memory information is used to represent the running state of the virtual machine; Determine the interface corresponding to the request path.

4. The method according to claim 3, characterized in that, The parsing result is transmitted to the detection process via inter-process communication between the main process and the detection process, including: The memory information is transmitted to the detection process via the inter-process communication interface.

5. The method according to claim 1, characterized in that, The memory to be tested is parsed according to the aforementioned detection items to obtain the parsing results, including: According to the detection item, a reference address is obtained from the data structure of the memory to be detected, wherein the reference address is used to represent the starting address of the kernel of the operating system in the memory to be detected; The resolution result is determined based on the reference address.

6. The method according to claim 5, characterized in that, Based on the reference address, the resolution result is determined, including: Offset the reference address to obtain the address of at least one key data structure of the memory to be detected; Using the aforementioned key data structure, the process control block on the operating system can be reconstructed; Determine the memory information that satisfies the data structure corresponding to the process control block.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The memory detection results are reported to the server.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The detection items are obtained from the server. The detection items are loaded into the detection process.

9. The method according to any one of claims 1 to 6, characterized in that, The method further includes: In response to the detection item being in an abnormal state, the detection item is either reloaded into the detection process or deleted from the detection process.

10. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The memory detection result corresponding to the parsing result is obtained through the inter-process communication.

11. A method for detecting memory in a virtual machine, characterized in that, This is applied to a memory detection system, which runs a detection process to perform the following methods: Through inter-process communication between the detection process and the main process of the memory detection system, an inter-process communication request is transmitted to the main process. The inter-process communication request is used to request information associated with the detection items of the memory to be detected in the virtual machine. The inter-process communication request is used to enable the memory detection system to determine the memory to be detected in the main process. The memory to be detected is used to enable the memory detection system to perform memory parsing in the main process according to the detection items to obtain a parsing result. The parsing result includes the memory information of the memory to be detected under the operating system of the virtual machine. The parsing result from the main process is obtained through the inter-process communication. The parsing results are tested according to the test items to obtain memory test results, wherein the memory test results are used to indicate the security level of the memory to be tested under the test items; The memory detection results are transmitted to the main process through the inter-process communication.

12. A memory detection system for a virtual machine, characterized in that, include: The system comprises a memory detection module and a memory parsing module. The memory detection module runs at least one detection process, while the memory parsing module runs a main process. The memory detection terminal is used to transmit an inter-process communication request to the main process through inter-process communication between the detection process and the main process, wherein the inter-process communication request is used to request information associated with the detection items of the virtual machine's memory to be detected; The memory parsing end is used to respond to the inter-process communication request, determine the memory to be detected, perform memory parsing on the memory to be detected according to the detection items, and obtain a parsing result, wherein the parsing result includes the memory information of the memory to be detected under the operating system of the virtual machine; The memory detection terminal is used to obtain the parsing result from the main process through the inter-process communication; and to detect the parsing result according to the detection items to obtain the memory detection result, wherein the memory detection result is used to indicate the security level of the memory to be detected under the detection items.

13. The system according to claim 12, characterized in that, The memory parsing module includes an inter-process communication module and a memory parsing module, wherein... The inter-process communication module is used to respond to the inter-process communication request, determine the interface corresponding to the inter-process communication request, and use the interface to trigger the memory parsing module to call the virtual machine manager to read the memory to be detected. The memory parsing module is used to perform memory parsing on the read memory to be tested according to the detection items, and obtain the parsing result.

14. The system according to claim 13, characterized in that, The inter-process communication module is used to obtain the inter-process communication request through the inter-process communication, and in response to the obtained inter-process communication request, determine the request path of the inter-process communication request, wherein the request path includes parameters for obtaining the memory information, the memory information being used to represent the running state of the virtual machine; and determine the interface corresponding to the request path.

15. The system according to claim 14, characterized in that, The inter-process communication module is used to transmit the memory information to the detection process through the interface via the inter-process communication.

16. The system according to claim 13, characterized in that, The memory parsing module is used to obtain a reference address from the data structure of the memory to be tested according to the detection item, wherein the reference address is used to represent the starting address of the kernel of the operating system in the memory to be tested; and to determine the parsing result based on the reference address.

17. The system according to claim 16, characterized in that, The memory parsing module is used to offset the reference address to obtain the address of at least one key data structure of the memory to be detected; to reconstruct the process control block on the operating system using the key data structure; and to determine the memory information that satisfies the data structure corresponding to the process control block.

18. The system according to claim 13, characterized in that, The system also includes a server, and the memory parsing terminal further includes a main control module, wherein... The memory detection terminal is used to transmit the memory detection result to the inter-process communication module through the inter-process communication. The main control module is used to report the memory detection results from the inter-process communication module to the server. The server is used to send the memory detection results to the client; The main control module is used to obtain the detection items from the server; load the detection items into the detection process; and / or, The main control module is used to start the inter-process communication module in response to the inter-process communication request.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 11.

20. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 11.