CN113176926B - API dynamic monitoring method and system based on virtual machine introspection technology - Google Patents
API dynamic monitoring method and system based on virtual machine introspection technology Download PDFInfo
- Publication number
- CN113176926B CN113176926B CN202110367511.7A CN202110367511A CN113176926B CN 113176926 B CN113176926 B CN 113176926B CN 202110367511 A CN202110367511 A CN 202110367511A CN 113176926 B CN113176926 B CN 113176926B
- Authority
- CN
- China
- Prior art keywords
- address
- monitored
- monitoring
- api
- dll
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses an API dynamic monitoring method and system based on virtual machine introspection technology. The method comprises the following steps: 1) Reading and analyzing a set monitoring strategy configuration file, and acquiring an API to be monitored and a dynamic link library DLL to which the API belongs; 2) Traversing a dynamic link library loaded into a system memory, and monitoring an API which is loaded into the memory and needs to be monitored; monitoring a dynamic link library which is not loaded into a system memory, and after the dynamic link library is loaded into the system, determining whether the dynamic link library is the dynamic link library which needs to be monitored, if so, monitoring an API function which needs to be monitored in the dynamic link library; 3) When the API function to be monitored is triggered, the current operating system memory is analyzed, the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the information of the dynamic link library are extracted, and the information is written into a log.
Description
Technical Field
The invention belongs to the technical field of network security, relates to a virtualization monitoring method, and in particular relates to an API dynamic monitoring method and system based on a virtual machine introspection technology.
Background
The virtualization technology is that a software layer called a virtual machine manager (Virtual Machine Monitor, abbreviated as VMM) is added on a computer hardware layer through hardware level virtualization in a drawing method, and the software layer is also called a hypervisor. The VMM performs necessary hardware resource virtualization for each virtual machine, and the virtual machines can install different operating systems according to own requirements and access required hardware physical resources under the monitoring and management of the VMM. Intuitively, virtualization technology, i.e., multiplexing hardware resources, allows multiple virtual machines, i.e., multiple guest operating systems, to run simultaneously. On a hardware platform where the VMM is installed, the VMM isolates the operating system from the hardware by coordinating the guest operating system to issue instructions, and current virtualization techniques are classified into full-virtualization and half-virtualization.
Virtual Machine Introspection (VMI) is to analyze the internal state of a virtual machine by analyzing the internal system state (software and hardware) of the virtual machine. Because the virtual machine manager has good isolation of a host-based intrusion detection framework (host-based intrusion detection system, short for HIDS), the virtual machine introspection can monitor the virtual machine by means of a Virtual Machine Manager (VMM). The virtual machine manager is typically an independent and trusted virtual machine with very good security isolation since the virtual machine is independent of the monitored client. The virtual machine manager can read the memory page, the register and the interrupt event of the virtual machine outside the monitored virtual machine, and a user can analyze low-level events such as the memory page, the register and the interrupt by using the technology, so that information such as a virtual machine process, a kernel module and a system call is finally obtained.
Current virtual machine monitoring techniques are divided into two categories, virtual machine internal monitoring (In-VM) and virtual machine external monitoring (Out-of-VM). The internal monitoring of the virtual machine refers to obtaining information of behaviors, events and the like occurring in the virtual machine through loading a module and a plug-in the internal of the target virtual machine. The internal monitoring has the advantages that the event which occurs in the intermediary or the system of the target virtual machine obtains the information with the semantics of the operating system, semantic reconstruction is not needed, and the cost on performance is reduced. However, this approach requires running agents in the target system, which can have an impact on system performance. In addition, the acquired information is easily deceived by the kernel-mode Rookit, and the real system information cannot be acquired. With the development of information technology, the novel Trojan has the capability of anti-sandbox detection and strong self-destruction and anti-evidence-taking capability, and when the Trojan detects that the virus Trojan detection tool runs, the attack behavior is immediately interrupted, and the attack trace is self-destroyed and erased.
External monitoring of a virtual machine refers to detecting events occurring inside the virtual machine outside the virtual machine by using a virtual machine introspection mechanism (Virtual Machine Introspection, VMI). The acquired information is the bottom information of the host system. The problem of how to restore it to a sequence of characters or a data structure with semantics is called the semantic gap (semantic gap) problem. It is very difficult to obtain information of the virtual machine without any a priori knowledge of the host and the virtual machine. At present, the semantic gap problem is mainly solved by adopting methods such as manual analysis, debugger auxiliary analysis, compiler auxiliary analysis and binary analysis. Xenaccess is a class library for monitoring memory and disk information in Xen environment; virttuoso monitors system operating state information by extracting binary generated VMI code. On the basis of Libvmi, watson et al also propose a virtual machine process information detection scheme based on VMM assistance. The external monitoring technology of the virtual machine monitors the APIs, and when the program runs, the corresponding APIs are loaded in the memory, or the read-write and mapping of the files are monitored, so that the system performance loss is extremely serious.
Disclosure of Invention
The invention aims to provide an API dynamic monitoring method and system based on virtual machine introspection technology. The invention analyzes the bottom information such as the memory, the register and the like obtained by the virtual machine monitoring technology on the basis of the virtual machine monitoring technology, monitors the process of loading the API by the system by utilizing the memory introspection technology, and dynamically monitors the related API of the system when the system just loads the API, thereby realizing the API dynamic monitoring technology based on the virtual machine introspection technology on the basis of reducing the performance loss of the operating system. Compared with the disclosed method, the method has the following advantages:
(1) Out-of-band monitoring, in-band failure to detect
The invention relates to a virtual machine external monitoring system based on a virtual machine introspection technology. The system is installed on a host machine and monitors a virtual machine (monitored host machine). Both sides have very good isolation. Therefore, the monitored host cannot find out the fact that the monitored host is monitored, and the anti-detection and anti-debugging capability of the Trojan cannot play a role.
(2) User layer host intercept analysis
Most of the current external monitoring systems of the virtual machine adopt the memory mapping behavior of the monitoring files, which results in a large number of false triggering events. By analyzing the process starting process, the method analyzes the process after the user layer loads all dynamic link libraries on the process, analyzes all loaded dynamic libraries at one time, and also eliminates a large number of false touch operations caused by the memory mapping behavior of the monitoring file.
(3) Dynamic monitoring DLL and internal functions
The invention can dynamically monitor DLL (dynamic link library ), monitors the API mapped to the memory in the current operating system according to the configuration file, and continuously monitors the memory for the API which is not mapped to the memory, and monitors the API at the first time when the API is mapped to the memory.
(4) Efficient interception mechanism
The invention can self-define the information of API name, number, affiliated DLL and the like which need to be intercepted, not only can intercept the system DLL, but also can intercept the APIs in the user and third party DLLs.
The invention discloses a virtual machine behavior monitoring system, which is shown in fig. 1, and comprises a strategy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module. The policy loading module is responsible for reading user monitoring policies (information of processes to be monitored, function types and functions to be monitored, modules to be monitored and the like), analyzing the policies, converting the policies into user policy structure body information which can be identified by a program, wherein the user policy structure body information comprises the functions to be monitored, the modules to be monitored and the processes to be monitored, and judging the states of the policies. The monitoring setting module is responsible for setting the monitoring module, traversing the user policy structure body, searching the virtual address, converting the virtual address and the physical address and setting the trap of the API to be monitored. The dynamic monitoring module is responsible for monitoring the DLL mapped to the memory of the operating system, and after confirming that the functions in the DLL need to be monitored, the monitoring setting module is called to monitor the functions in the DLL which need to be monitored. The semantic conversion module is responsible for processing extraction and analysis of system information when the monitored function is executed, and finally converting the underlying machine language into high-level semantic information which can be identified by a user.
The specific operation mode of the system is as follows:
1: the system reads the user monitoring policy configuration file, and the policy loading module analyzes the configuration file to analyze the API which the user needs to analyze and the DLL (dynamic link library) to which the API belongs. And then traversing the dynamic link library loaded into the memory, and calling a monitoring setting module to monitor the API which is loaded into the memory and needs to be monitored.
2: for the dynamic link library which is not loaded into the memory of the operating system, the system monitors the LdrpInitizeProcess and the LdrpLoadDll, thereby acquiring the dynamic link library loaded into the memory in real time. After the dynamic link library loaded into the memory is obtained, the dynamic monitoring module can deliver the dynamic link library to the policy loading module to judge whether the dynamic link library is a module needing to be monitored (the dynamic link library is called a module after being loaded into the memory). If yes, the monitoring setting module is called to monitor the API to be monitored in the dynamic link library, so that all functions to be monitored can be ensured to be monitored.
3: when the monitored function is triggered, the semantic conversion module analyzes the current operation system memory, overcomes the semantic gap, extracts the information of the current process, the process ID, the current thread, the thread ID, the current process name, the called API, the dynamic link library, the calling parameter and the like from the memory, and writes the information into the log.
The virtual machine introspection technology refers to a function of monitoring the running of a running virtual machine, including monitoring various kinds of monitoring such as a cpu\memory. The functions mentioned in the present invention are all implemented by virtual machine introspection technology.
The technical scheme of the invention is as follows:
an API dynamic monitoring method based on virtual machine introspection technology comprises the following steps:
1) The strategy loading module reads and analyzes the set monitoring strategy configuration file, and acquires an API to be monitored and a dynamic link library DLL to which the API belongs;
2) Traversing a dynamic link library loaded into a system memory, and calling a monitoring setting module to monitor an API which is loaded into the memory and needs to be monitored; monitoring a dynamic link library which is not loaded into a system memory, and after the dynamic link library is loaded into the system, the dynamic monitoring module judging the dynamic link library by the strategy loading module to confirm whether the dynamic link library is the dynamic link library to be monitored, and if so, calling the monitoring setting module to monitor an API function to be monitored in the dynamic link library;
3) After the API function to be monitored is triggered, the semantic conversion module analyzes the memory of the current operating system, extracts the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the information of the dynamic link library, and writes the information into a log.
Further, the method for reading and analyzing the set monitoring policy configuration file by the policy loading module comprises the following steps:
1-1) reading a monitoring strategy configuration file, and acquiring an API (application program interface) to be monitored and a dynamic link library DLL (dynamic link library) to which the API to be monitored belongs;
1-2) initializing a first hash table of an API to be monitored and the address and the state thereof, and initializing a second hash table of a dynamic link library DLL to which the API to be monitored and the API to be monitored belong;
1-3) acquiring a head node address of an operating system process chain according to a program database file PDB corresponding to a current operating system kernel file ntoskrnl.exe, wherein each node of the process chain corresponds to one EPROCESS structure body, each EPROCESS structure body corresponds to one process in the operating system, and the process ID, the process page directory table base address, the process name and the disk file storage position information of the process are contained in the EPROCESS structure body;
1-4) searching PEB structure bodies of corresponding processes of the EPROCESS structure bodies according to the EPROCESS member offset of the monitored operating system in the EPROCESS structure bodies;
1-5) finding a PEB_LDR_DATA structure for the process from the PEB structure for the process according to the monitored operating system PEB member offset;
1-6) traversing the PEB_LDR_DATA doubly linked list, and taking out the virtual base address mapped to each DLL in the current process;
1-7) inquiring the second hash table for the DLL mapped into the memory of the operating system to find the API function to be monitored, and then acquiring the offset of the API function relative to the base address of the DLL according to the program database file PDB; adding the offset to the virtual base address of the DLL to which the API function belongs to obtain the virtual address of the API function to be monitored and monitor the API function;
1-8) if the monitoring is successful, updating the state and address of the API function; if not, the original state is kept unchanged.
Further, the method for monitoring the API to be monitored by the monitoring setting module comprises the following steps:
2-1) obtaining the virtual address of the API function to be monitored and the EPROCESS structure address of the current process;
2-2) fetching the page directory table base address of the current process from the EPROCESS fabric address according to the EPROCESS member offset of the monitored operating system;
2-3) finding a page directory table of the process according to the page directory table base address of the process, sequentially searching a multi-stage page table according to the virtual address, and finding a physical address corresponding to the virtual address;
2-4) if the physical address is not found, loading the CR2 register into the virtual address, triggering a system page-changing mechanism, and changing the corresponding memory page into the memory again;
2-5) repeating the step 2-3), and searching the physical address corresponding to the virtual address again to find the physical address corresponding to the virtual address;
2-6) monitoring the physical address corresponding to the virtual address, storing the machine code of the corresponding position, generating an interrupt event and returning to the monitoring setting state.
Further, the method for analyzing the memory of the current operating system by the semantic conversion module comprises the following steps:
3-1) fetching an interrupt event while suspending the monitored operating system;
3-2) searching a first hash table according to the physical address of the triggering event stored in the interrupt event, and determining a corresponding API;
3-3) acquiring calling parameters of the API and restoring the calling parameters to obtain original parameters and storing the original parameters in a buffer area;
3-4) analyzing the PDB file of the kernel module of the monitored operating system, obtaining the KPCR structure address of the operating system, finding out the corresponding KPRCB structure, and finding out the KTHREAD structure of the current running thread from the KPRCB structure according to the KPRCB structure offset; then reading the related information of the process and thread triggering the interrupt event from the KTHREAD structure body and the EPROCESS structure body;
3-5) writing the information obtained in the steps 3-3) and 3-4) into a database, and recovering the operation of the virtual machine.
Further, the method for monitoring the dynamic link library which is not loaded into the system memory by the dynamic monitoring module comprises the following steps:
21 Selecting a non-system kernel process from the operating system process chain, and searching the virtual base address of each DLL mapped into the currently selected process;
22 Dynamically loading the base address of the DLL library by the process and statically loading the base address of the DLL library by the process according to the offset search process of the operating system;
23 Setting and monitoring a process dynamic loading DLL library and a process static loading DLL library;
24 Reading the address of the ESP/RSP register of the current process for the callback triggered by the process static loading DLL library, setting the monitoring to the address, and then canceling the monitoring to the process static loading DLL library; turning to step 26);
25 For a callback triggered by a process dynamic loading DLL library, reading the address of a process ESP/RSP register, and setting and monitoring the address; then the virtual address of the DLL loaded into the memory is obtained from the eax/rax register; then traversing the process DLL chain to obtain the address of the newly loaded DLL;
26 Verifying the newly loaded DLL and monitoring the functions that need to be monitored but not.
The API dynamic monitoring system based on the virtual machine introspection technology is characterized by comprising a strategy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module; wherein the method comprises the steps of
The strategy loading module is used for reading and analyzing the set monitoring strategy configuration file, and acquiring an API (application program interface) to be monitored and a Dynamic Link Library (DLL) to which the API belongs;
the monitoring setting module is used for monitoring the API which is loaded into the memory and needs to be monitored;
the dynamic monitoring module is used for monitoring the dynamic link library which is not loaded into the system memory, and when the dynamic link library is loaded into the system, the dynamic link library is submitted to the strategy loading module for judgment to confirm whether the dynamic link library is the dynamic link library to be monitored, if so, the monitoring setting module is called to monitor the API function to be monitored in the dynamic link library;
the semantic conversion module is used for analyzing the current operating system memory after the API function to be monitored is triggered, extracting the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the information of the dynamic link library, and writing the information into the log.
Compared with the prior art, the invention has the following advantages:
the invention discloses an API dynamic monitoring system based on virtual machine introspection technology, which reads the monitoring requirement of a user on the behavior of a host, monitors a dynamic link library which is not loaded into a memory through the process of loading the dynamic link library by the monitoring system and the program running flow, and monitors related functions at the moment of loading the dynamic link library into the memory. Compared with the disclosed method, the method has the following advantages: 1) The isolation is excellent, and the monitoring party and the monitored party have very good isolation. The virtualization technology has the characteristic of excellent isolation, and the monitored host cannot find the fact that the monitored host is monitored, so that the anti-detection and anti-debugging capability of Trojan cannot play a role. 2) The user layer host intercepts and analyzes, and ensures that the false touch rate is reduced under all the interception conditions. By analyzing the process starting process, the process is analyzed after the user layer loads all dynamic link libraries on the process, all loaded dynamic libraries are analyzed at one time, and a large number of false touch operations caused by memory mapping behaviors of the monitoring file are avoided. 3) Dynamic monitoring, functions that are not loaded into the system can be monitored. The invention continuously monitors the memory and monitors the memory at the first time when the API is mapped into the memory. 4) The interception is efficient and free, and information such as the name, the number and the DLL (delay locked loop) of the API to be intercepted can be customized, so that the system DLL can be intercepted, and the APIs in the user and the third-party DLL can be intercepted.
Drawings
FIG. 1 is a framework diagram of an API dynamic monitoring system based on virtual machine introspection technology;
FIG. 2 is a flow chart of GAP addressing;
FIG. 3 is a flowchart of a policy update method;
FIG. 4 is a flow chart of ring event buffer storage;
FIG. 5 is a flow chart of a behavior analysis method.
Detailed Description
Preferred examples of the present invention will be described in detail below with reference to the accompanying drawings.
The invention discloses an API dynamic monitoring system based on virtual machine introspection technology, which mainly comprises a strategy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module.
FIG. 2 shows a workflow diagram of the policy loading module, the workflow comprising the following specific steps:
(1) And reading and analyzing the user strategy to obtain the API which the user wants to monitor and the dynamic link library which the user belongs to.
(2) And initializing hash tables of the API to be monitored, the address and the state and hash tables of the DLL and the API to be monitored, so that the inquiry is facilitated.
(3) And acquiring the head node address of the operating system process chain from the derived variable PsInitialSystemProcess according to the pdb (program database file) corresponding to the current operating system kernel file ntoskrnl.exe, wherein each node of the process chain is an EPROCESS structure body. Each EPROCESS structure corresponds to a process of the operating system, and the structure internally contains process related information such as a process ID of the process, a process page directory table base address, a process name, a disk file storage position and the like. Traversing the EPROCESS chain, analyzing (4) - (8) for each EPROCESS structure.
(4) And finding the PEB structure of the corresponding process of the EPROCESS structure according to the EPROCESS member offset of the monitored operating system from each EPROCESS structure. One process for each EPROCESS structure.
(5) The PEB structure of this process finds the PEB_LDR_DATA structure of this process according to the member offset of the monitored operating system PEB structure. The PEB LDR DATA structure is a node of the PEB LDR DATA doubly linked list, and each node of the doubly linked list stores therein one piece of DLL information mapped to the process space, including information of DLL name, module name, DLL base address, etc. Each PEB corresponds to a process and the PEB LDR DATA stores the address of a process in the entire linked list.
(6) The PEB_LDR_DATA doubly linked list is traversed and the virtual base address mapped to each DLL in the process is fetched.
(7) And for the DLL mapped into the memory, searching the DLL and the API hash table to find out the function needing to be monitored inside. The offset of the function relative to the DLL base address is then obtained based on an analysis of the DLL corresponding PDB or function derivation table. And adding the offset to the virtual base address of the DLL to which the function belongs to obtain the virtual address of the API to be monitored. The function is monitored by passing in the process EPROCESS base address and the virtual address of the API to be monitored.
(8) If the monitoring is successful, the state and address of the API are updated. If not, the original state is kept unchanged.
Fig. 3 shows a workflow diagram of the monitoring and setting module, the workflow comprising the following specific steps:
(1) The virtual address and the EPROCESS structure address of the required monitoring API are obtained.
(2) The address of the directyTableBase is fetched from the EPROCESS structure address according to the monitored operating system EPROCESS member offset, i.e., the page directory table base address of the process.
(3) And finding a page directory table of the process according to the page directory table base address of the process, sequentially searching the multi-stage page table according to the virtual address, and finding a physical address corresponding to the virtual address.
(4) If the physical address is not found, the process is informed that the memory page where the physical address is located is not in the memory. At this time, the virtual address is loaded into the CR2 register, the system page-changing mechanism is triggered, and the memory page where the physical address is located is changed into the memory again. Only one address, and the last address to trigger a page-change interrupt, can be stored in the CR2 register (i.e., the page fault linear address register). The operating system triggers a page change mechanism based on the address therein.
(5) Repeating the operation in the step (3), and searching the physical address corresponding to the virtual address again to find the physical address.
(6) Setting monitoring, reading a physical address, storing a machine code at a corresponding position, and writing an int3 instruction. The int3 instruction is one of the operating system interrupt instructions, and when the operating system executes the int3 instruction, an interrupt No. 3 is triggered to generate an interrupt event.
(7) And returning the monitoring setting state to the calling module.
Fig. 4 shows a workflow diagram of the dynamic monitoring module, the workflow comprising the following specific steps:
(1) And (3) selecting a process except a process number 4 (the process ID of the system process is 4 and is a system kernel process) from a process chain, repeating the steps of the strategy loading modules (4) - (6), and searching the base address of the NTDLL module according to the DLL name (the NTDLL module is a module after the NTDLL dynamic library of the system is mapped into the system, wherein the module provides interaction between the system layer 0 and the system layer 3, and is loaded into a memory during normal use of the system).
(2) The base addresses of the LdrpLoadDll function and the LdrpInitialzeProcess function are found from the ntdll module based on the operating system offset (which may be derived from the pdb or function derivation table).
(3) And calling a monitoring setting module to set monitoring on LdrpLoadDll (process dynamic loading DLL library) and LdrpINTIAzeProcess (process static loading DLL library).
(4) For the callback triggered by the LdrpINTilialzeProcess function, the address of the current process ESP/RSP register is read, and monitoring is set for this address, and then monitoring of the LdrpINitialzeProcess is canceled. When the new setup monitor is triggered again, the DLL chain is found by repeating the policy loading modules (4) - (6) steps from the current process EPROCESS. And then goes to step 6.
(5) For the callback triggered by the LdrpLoadDll function, the address of the process ESP/RSP register is read and monitored. When a callback is triggered, the last pointer of the current DLL linked list is transferred. The virtual address of the dynamic link library after being loaded into the memory is obtained from the eax/rax register. The process DLL chain is traversed to obtain the address of the newly loaded DLL (preventing LdrpLoadDll nested calls).
(6) The newly loaded DLL is validated and functions that need to be monitored but not.
Fig. 5 shows a workflow diagram of the semantic conversion module, the workflow comprising the following specific steps:
(1) An interrupt event (referred to as an interrupt event triggered by the operating system executing int 3) is fetched while the monitored virtual machine is suspended.
(2) The interrupt event stores the physical address of the trigger event and the CPU ID number of the trigger event, and matches the hash table according to the physical address to obtain which API is called;
(3) According to the field values of registers RIP, RCX and the like, the current API call parameters are taken out, a libvmi library is called to complete the restoration of original parameters, and a buffer area is opened to store the original parameters;
(4) The KPCR structure body address of the operating system can be obtained by analyzing the PDB file of the kernel module of the monitored operating system. The KPRCB structure is found from the KPCR structure according to the KPCR structure offset, the KTHREAD structure of the current running thread is found from the KPRCB structure according to the KPRCB structure offset, and the KTHREAD stores information such as the ID of the current thread, the EPROCESS base address of the process, the stack address and the like. And reading the process and thread related information of the current process from the KTHREAD structure and the EPROCESS structure. The current process is the process of the trigger event and is also the process of calling the monitored API;
(5) And writing the parameters acquired by the parameter information, the API triggering the callback, the process ID, the thread ID and the like into a database. And resume virtual machine operation.
The foregoing is merely a preferred embodiment of the present invention and it should be noted that modifications and enhancements can be made to the present invention by those of ordinary skill in the art without departing from the principles of the present invention, and that various substitutions, alterations and modifications are possible without departing from the spirit and scope of the present invention. The invention should not be limited to the embodiments of the present description and the disclosure of the drawings, but the scope of the invention is defined by the claims.
Claims (7)
1. An API dynamic monitoring method based on virtual machine introspection technology comprises the following steps:
1) The strategy loading module reads and analyzes the set monitoring strategy configuration file, and acquires an API to be monitored and a dynamic link library DLL to which the API belongs; the method for reading and analyzing the set monitoring policy configuration file by the policy loading module comprises the following steps:
1-1) reading a monitoring strategy configuration file, and acquiring an API (application program interface) to be monitored and a dynamic link library DLL (dynamic link library) to which the API to be monitored belongs;
1-2) initializing a first hash table of an API to be monitored and the address and the state thereof, and initializing a second hash table of a dynamic link library DLL to which the API to be monitored and the API to be monitored belong;
1-3) acquiring a head node address of an operating system process chain according to a program database file PDB corresponding to a current operating system kernel file ntoskrnl.exe, wherein each node of the process chain corresponds to one EPROCESS structure body, each EPROCESS structure body corresponds to one process in the operating system, and the process ID, the process page directory table base address, the process name and the disk file storage position information of the process are contained in the EPROCESS structure body;
1-4) searching PEB structure bodies of corresponding processes of the EPROCESS structure bodies according to the EPROCESS member offset of the monitored operating system in the EPROCESS structure bodies;
1-5) finding a PEB_LDR_DATA structure for the process from the PEB structure for the process according to the monitored operating system PEB member offset;
1-6) traversing the PEB_LDR_DATA doubly linked list, and taking out the virtual base address mapped to each DLL in the current process;
1-7) inquiring the second hash table for the DLL mapped into the memory of the operating system to find the API function to be monitored, and then acquiring the offset of the API function relative to the base address of the DLL according to the program database file PDB; adding the offset to the virtual base address of the DLL to which the API function belongs to obtain the virtual address of the API function to be monitored and monitor the API function;
1-8) if the monitoring is successful, updating the state and address of the API function; if not, the original state is kept unchanged;
2) Traversing a dynamic link library loaded into a system memory, and calling a monitoring setting module to monitor an API which is loaded into the memory and needs to be monitored; monitoring a dynamic link library which is not loaded into a system memory, and after the dynamic link library is loaded into the system, the dynamic monitoring module judging the dynamic link library by the strategy loading module to confirm whether the dynamic link library is the dynamic link library to be monitored, and if so, calling the monitoring setting module to monitor an API function to be monitored in the dynamic link library;
3) After the API function to be monitored is triggered, the semantic conversion module analyzes the memory of the current operating system, extracts the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the information of the dynamic link library, and writes the information into a log.
2. The method of claim 1, wherein the monitoring setting module monitors the API to be monitored by:
2-1) obtaining the virtual address of the API function to be monitored and the EPROCESS structure address of the current process;
2-2) fetching the page directory table base address of the current process from the EPROCESS fabric address according to the EPROCESS member offset of the monitored operating system;
2-3) finding a page directory table of the process according to the page directory table base address of the process, sequentially searching a multi-stage page table according to the virtual address, and finding a physical address corresponding to the virtual address;
2-4) if the physical address is not found, loading the CR2 register into the virtual address, triggering a system page-changing mechanism, and changing the corresponding memory page into the memory again;
2-5) repeating the step 2-3), and searching the physical address corresponding to the virtual address again to find the physical address corresponding to the virtual address;
2-6) monitoring the physical address corresponding to the virtual address, storing the machine code of the corresponding position, generating an interrupt event and returning to the monitoring setting state.
3. The method of claim 2, wherein the method for parsing the current operating system memory by the semantic conversion module is:
3-1) fetching an interrupt event while suspending the monitored operating system;
3-2) searching a first hash table according to the physical address of the triggering event stored in the interrupt event, and determining a corresponding API;
3-3) acquiring calling parameters of the API and restoring the calling parameters to obtain original parameters and storing the original parameters in a buffer area;
3-4) analyzing the PDB file of the kernel module of the monitored operating system, obtaining the KPCR structure address of the operating system, finding out the corresponding KPRCB structure, and finding out the KTHREAD structure of the current running thread from the KPRCB structure according to the KPRCB structure offset; then reading the related information of the process and thread triggering the interrupt event from the KTHREAD structure body and the EPROCESS structure body;
3-5) writing the information obtained in the steps 3-3) and 3-4) into a database, and recovering the operation of the virtual machine.
4. The method of claim 1, wherein the method for the dynamic monitoring module to monitor the dynamic link library that is not loaded into the system memory comprises:
21 Selecting a non-system kernel process from the operating system process chain, and searching the virtual base address of each DLL mapped into the currently selected process;
22 Dynamically loading the base address of the DLL library by the process and statically loading the base address of the DLL library by the process according to the offset search process of the operating system;
23 Setting and monitoring a process dynamic loading DLL library and a process static loading DLL library;
24 Reading the address of the ESP/RSP register of the current process for the callback triggered by the process static loading DLL library, setting the monitoring to the address, and then canceling the monitoring to the process static loading DLL library; turning to step 26);
25 For a callback triggered by a process dynamic loading DLL library, reading the address of a process ESP/RSP register, and setting and monitoring the address; then the virtual address of the DLL loaded into the memory is obtained from the eax/rax register; then traversing the process DLL chain to obtain the address of the newly loaded DLL;
26 Verifying the newly loaded DLL and monitoring the functions that need to be monitored but not.
5. The API dynamic monitoring system based on the virtual machine introspection technology is characterized by comprising a strategy loading module, a monitoring setting module, a dynamic monitoring module and a semantic conversion module; wherein the method comprises the steps of
The strategy loading module is used for reading and analyzing the set monitoring strategy configuration file, and acquiring an API (application program interface) to be monitored and a Dynamic Link Library (DLL) to which the API belongs; the method for reading and analyzing the set monitoring policy configuration file by the policy loading module comprises the following steps: 1) Reading a monitoring strategy configuration file, and acquiring an API to be monitored and a dynamic link library DLL to which the API to be monitored belongs; 2) Initializing a first hash table of the API to be monitored and the address and state thereof, and initializing a second hash table of the API to be monitored and a dynamic link library DLL to which the API to be monitored belongs; 3) Acquiring a head node address of a process chain of an operating system according to a program database file PDB corresponding to a kernel file ntoskrnl.exe of the current operating system, wherein each node of the process chain corresponds to one EPROCESS structure body, each EPROCESS structure body corresponds to one process in the operating system, and the interior of the EPROCESS structure body comprises a process ID, a process page directory table base address, a process name and disc file storage position information of the process; 4) Finding a PEB structure of the process from the EPROCESS structure according to the monitored operating system EPROCESS member offset; 5) Finding a PEB_LDR_DATA structure of the process from the PEB structure of the process according to the monitored operating system PEB member offset; 6) Traversing the PEB_LDR_DATA doubly linked list, and taking out the virtual base address mapped to each DLL in the current process; 7) Inquiring the second hash table for the DLL mapped into the memory of the operating system to find the API function to be monitored, and then acquiring the offset of the API function relative to the base address of the DLL according to the program database file PDB; adding the offset to the virtual base address of the DLL to which the API function belongs to obtain the virtual address of the API function to be monitored and monitor the API function; 8) If the monitoring is successful, updating the state and the address of the API function; if not, the original state is kept unchanged;
the monitoring setting module is used for monitoring the API which is loaded into the memory and needs to be monitored;
the dynamic monitoring module is used for monitoring the dynamic link library which is not loaded into the system memory, and when the dynamic link library is loaded into the system, the dynamic link library is submitted to the strategy loading module for judgment to confirm whether the dynamic link library is the dynamic link library to be monitored, if so, the monitoring setting module is called to monitor the API function to be monitored in the dynamic link library;
the semantic conversion module is used for analyzing the current operating system memory after the API function to be monitored is triggered, extracting the current process, the process ID, the current thread, the thread ID, the current process name, the called API and the information of the dynamic link library, and writing the information into the log.
6. The system of claim 5, wherein the monitoring setting module monitors the API to be monitored by: 21 Obtaining the virtual address of the API function to be monitored and the EPROCESS structure address of the current process;
22 Fetching the page directory table base address of the current process from the EPROCESS fabric address according to the EPROCESS member offset of the monitored operating system; 23 Finding a page directory table of the process according to the page directory table base address of the process, sequentially searching a multi-level page table according to the virtual address, and finding a physical address corresponding to the virtual address; 24 If the physical address is not found, loading the CR2 register into the virtual address, triggering a system page-changing mechanism, and changing the corresponding memory page into the memory again; 25 Repeating the step 23), and searching the physical address corresponding to the virtual address again to find the physical address corresponding to the virtual address;
26 Monitoring the physical address corresponding to the virtual address, storing the machine code of the corresponding position, generating an interrupt event and returning to the monitoring setting state.
7. The system of claim 5, wherein the method for the dynamic monitoring module to monitor the dynamic link library that is not loaded into the system memory comprises: 31 Selecting a non-system kernel process from the operating system process chain, and searching the virtual base address of each DLL mapped into the currently selected process; 32 Dynamically loading the base address of the DLL library by the process and statically loading the base address of the DLL library by the process according to the offset search process of the operating system; 33 Setting and monitoring a process dynamic loading DLL library and a process static loading DLL library; 34 Reading the address of the ESP/RSP register of the current process for the callback triggered by the process static loading DLL library, setting the monitoring to the address, and then canceling the monitoring to the process static loading DLL library; turning to step 36); 35 For a callback triggered by a process dynamic loading DLL library, reading the address of a process ESP/RSP register, and setting and monitoring the address; then the virtual address of the DLL loaded into the memory is obtained from the eax/rax register; then traversing the process DLL chain to obtain the address of the newly loaded DLL; 36 Verifying the newly loaded DLL and monitoring the functions that need to be monitored but not.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110367511.7A CN113176926B (en) | 2021-04-06 | 2021-04-06 | API dynamic monitoring method and system based on virtual machine introspection technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110367511.7A CN113176926B (en) | 2021-04-06 | 2021-04-06 | API dynamic monitoring method and system based on virtual machine introspection technology |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113176926A CN113176926A (en) | 2021-07-27 |
| CN113176926B true CN113176926B (en) | 2023-09-05 |
Family
ID=76923068
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110367511.7A Active CN113176926B (en) | 2021-04-06 | 2021-04-06 | API dynamic monitoring method and system based on virtual machine introspection technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113176926B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114629711B (en) * | 2022-03-21 | 2024-02-06 | 广东云智安信科技有限公司 | Method and system for detecting special Trojan horse on Windows platform |
| CN117573292B (en) * | 2024-01-15 | 2024-04-09 | 麒麟软件有限公司 | Method for Xen running general RTOS virtual machine |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014012504A1 (en) * | 2012-07-20 | 2014-01-23 | Tencent Technology (Shenzhen) Company Limited | Method, device, and mobile terminal for api interception |
| CN105740046A (en) * | 2016-01-26 | 2016-07-06 | 华中科技大学 | Virtual machine process behavior monitoring method and system based on dynamic library |
| CN108920253A (en) * | 2018-06-20 | 2018-11-30 | 成都虫洞奇迹科技有限公司 | A kind of the virtual machine monitoring system and monitoring method of no agency |
-
2021
- 2021-04-06 CN CN202110367511.7A patent/CN113176926B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014012504A1 (en) * | 2012-07-20 | 2014-01-23 | Tencent Technology (Shenzhen) Company Limited | Method, device, and mobile terminal for api interception |
| CN105740046A (en) * | 2016-01-26 | 2016-07-06 | 华中科技大学 | Virtual machine process behavior monitoring method and system based on dynamic library |
| CN108920253A (en) * | 2018-06-20 | 2018-11-30 | 成都虫洞奇迹科技有限公司 | A kind of the virtual machine monitoring system and monitoring method of no agency |
Non-Patent Citations (1)
| Title |
|---|
| ShadowMonitor: An Effective In-VM Monitoring Framework with Hardware-Enforced Isolation;Bin Shi et al.;《Springer Nature Switzerland AG 2018》;第670–690页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113176926A (en) | 2021-07-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2679175C1 (en) | Method of behavioral detection of malicious programs using a virtual interpreter machine | |
| US8117660B2 (en) | Secure control flows by monitoring control transfers | |
| US10284591B2 (en) | Detecting and preventing execution of software exploits | |
| US10698668B1 (en) | Custom code transformations during compilation process | |
| US8479174B2 (en) | Method, computer program and computer for analyzing an executable computer file | |
| CA2856268C (en) | Methods of detection of software exploitation | |
| EP2237186B1 (en) | Method for accelerating hardware emulator used for malware detection and analysis | |
| EP3175386B1 (en) | Transparent detection and extraction of return-oriented-programming attacks | |
| US20050108562A1 (en) | Technique for detecting executable malicious code using a combination of static and dynamic analyses | |
| CN109074450B (en) | Threat defense techniques | |
| US20140259169A1 (en) | Virtual machines | |
| KR101740604B1 (en) | Generic unpacking of applications for malware detection | |
| US9900324B1 (en) | System to discover and analyze evasive malware | |
| CN113176926B (en) | API dynamic monitoring method and system based on virtual machine introspection technology | |
| US8407787B1 (en) | Computer apparatus and method for non-intrusive inspection of program behavior | |
| Uroz et al. | Characteristics and detectability of Windows auto-start extensibility points in memory forensics | |
| JP2004303114A (en) | Interpreter and native code execution method | |
| CN109857520B (en) | Semantic reconstruction improvement method and system in virtual machine introspection | |
| CN111444504A (en) | Method and device for automatically identifying malicious codes during software running | |
| More et al. | Dynamic malware detection and recording using virtual machine introspection | |
| US11914711B2 (en) | Systems and methods for automatically generating malware countermeasures | |
| Aboughadareh et al. | Mixed-mode malware and its analysis | |
| Zaidenberg et al. | Hypervisor memory introspection and hypervisor based malware honeypot | |
| EP4310707A1 (en) | System and method for detecting malicious code by an interpreter in a computing device | |
| US11314855B2 (en) | Detecting stack pivots using stack artifact verification |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |