Analysis of Windows service calling Mechanism

I. Preface

Windows System Service calling is a key interface in Windows systems, which is often called System Call, sysem service call, or system service dispatching. Here we call it a Windows system service call, it provides the function of switching from user to kernel in the operating system environment. Although there are many discussions about Windows System Service calling in foreign countries, we seldom see more detailed Chinese documents, I hope this article will provide some help to my friends who are just interested in the bottom layer of windows as I did. The article will take a kernel-level process monitoring/hiding tool T-procmon as an example to discuss in detail the technical details of Windows system service calls. Note that the technology discussed in this article is only applicable to Windows NT kernel-based operating systems, and Windows 2000 is used as an example.

Ii. Windows 2000 System Architecture

Microsoft Windows 2000 is an operating system mainly designed for network servers. Therefore, it is very different from Windows 9x, which we were familiar with before. However, it does not have much value for discussing a personal desktop operating system due to business strategies. So we will mainly introduce some details about the internal structure of the NT System. In the process of achieving its own goals, we need to explain some of its features.

1. extensibility)

Windows 2000 is a future-oriented system, so it pays great attention to its own scalability, in the future, some components of the current operating system may have to be added or deleted due to many reasons such as the market. This requires strong scalability of the operating system. To meet various expansion/deletion requirements, Windows 2000 provides an important design concept: subsystem ). We can add some operating system functions to Windows 2000 as a sub-system, just like OS/2 and POSIX. Of course, another feature is that we can add hooks for system service calls to modify system behaviors, which provides us with an opportunity to understand the system and expand system functions.

2. Reliability and robust)

The most basic requirement of a system is its stability. Without a stable environment, no satisfactory products can be created. To meet this requirement, Windows 2000 proposes object-based access control permissions. Most modern microprocessors support two modes: user mode (user/normal) and kernel mode (kernel/privileged ). Operating system components and key system components are in kernel mode, while general user-mode programs can only access private address space and execute commands of non-privileged levels. If you want to call the functions of some kernel components, you must call the system service.

3. Compatibility)

An important factor that intel and Microsoft can do today is their support for compatibility with existing systems. This is critical. No one is willing to change the system in three days. Of course, few people have this economic strength. To achieve compatibility with other systems, such as DOS and 16-bit windows, Windows 2000 has an Environment Subsystem. In Windows 2000, The Environment Subsystem that must exist is Win32, which is the basis of other subsystems. other subsystems are some surface interfaces, but actually call the interfaces provided by Win32, win32 eventually connects to the kernel through system service calls. Although the operating system provides different dynamic link libraries for various environment subsystems, the API function names are often different, however, this function is eventually implemented by entering the kernel through the same system service call.
4. Easy to maintain (maintainability)

 

As a large project, Windows 2000 maintenance has become a large project. Such a huge project cannot be developed without good maintainability. To this end, Windows 2000 uses a layered approach, which is also an operating system architecture model. System service calls isolate the system's kernel-mode code from the user-mode code. The subsystem uses system service calls to provide users with application programming interfaces (APIS ), the system service calls down the execution body to implement various functions.

As we mentioned above, the operating system has two modes, which are built on the basis of the processor. Generally, the processor can provide four processor modes from ring0 to ring3, but they must provide at least two, namely ring0 and ring3. Some special processor commands can only be executed in kernel mode, while some address spaces can be accessed only in kernel mode. Windows 2000 uses this feature to protect the operating system and other key components. It can only be accessed and executed in kernel mode, while general user programs can only be executed in user mode, in this way, we can avoid the destruction of the operating system code by some user programs, that is, the main reason why Windows 2000 is much more stable than Windows 9X. The architecture of Windows 2000 is shown below:

The system supports processes, service processes, applications, and environment subsystems. Application Programming Interface Local System Service Based on NTDLL. dll (User Mode) ----------------------------------------- System Service call (Kernel Mode) Execution body System kernel, Device Driver Hardware Abstraction Layer

　　Iii. Windows 2000 native API)

Windows 2000 local system service is also known as the Windows Local application programming interface. It is a system service set provided by the executive for programs in user mode and kernel mode. It contains two types of functions: system service scheduling placeholder program for Windows system services, subsystem DLL, and internal support functions used by other local images.

You can call the local system service in user mode through NTDLL. dll. On the surface, Win32 functions provide programmers with many interfaces to implement the functions we want. However, these Win32 functions are just a package of the native application programming interfaces, they encapsulate local APIs and call local system services to implement user-desired functions. That is to say, NTDLL. dll is only a shell of the System Service Calling Interface in user mode. For more information about Windows Local system services in user mode, see my previous article "detecting windows 2 k/XP/2003 Local System Information".

Which provides two types of functions: zwxxx and ntxxx. It should be noted that the system service calling in the Windows system runtime architecture we introduced above exists in ntoskrnl.exe(ntkrnlmp.exe in multiple processors) and is hierarchical.

　　Iv. Windows 2000 system service calling Mechanism

Trap dispatching in Windows 2000 includes interrupt, deferred procedure call, and asynchronous procedure call ), exception dispatching and system service calling. In Intel x86 Windows 2000, the processor executes the int 0x2e command to activate service calls in windows; in Intel x86 Windows XP, the processor executes the sysenter command to bring the system into the system service calling program. In amd Windows XP, The syscall command is used to implement the same function. We will use Windows 2000 on x86 as an example. First, we will provide a model for system service calling:

MoV eax, serviceid Lea edX, parametertable Int 2EH RET paramtablebytes

Serviceid clearly describes the system service number that is passed to the system service call. The kernel uses this identifier to find the corresponding system service information in the system service dispath table. Each item in the system service scheduling table contains a pointer to the system service program. When we hook this pointer, we modify it to point it to the address of our custom system service. Parametertable is a passed parameter. The system service caller kisystemservice must strictly verify each passed parameter and copy the parameter from the thread's user stack to the system's core stack for use. Because executing the int command will cause a trap, 0x2e In the interrupt description table (IDT = Interrupt Descriptor Table) in Windows 2000 points to the system service calling program. The returned paramtablebytes is about the number of parameters.

Now we can see that the system service call is just an interface, which provides the ability to forward requests in user mode to the Windows 2000 kernel, and triggers a processor mode switch. In the user's opinion, the system service calling interface is an interface for implementing the functions of the Windows kernel component. The system service calling interface defines a large number of services provided by the Windows kernel.

　　V. Windows 2000 system service call type

 

By default, two system service scheduling tables exist in Windows 2000, which correspond to two different types of system services. The two system service scheduling tables are: keservicedescriptortable and keservicedescriptortableshadow.

The Windows 2000 executable program service corresponds to the system service call provided by NTDLL. DLL for us. Subsystems call the function interfaces in Ntdll. DLL to implement the functions they need. The system service scheduling table keservicedescriptortabledefines the system services implemented in ntoskrln.exe. Generally, the function interfaces provided in kernel32.dll/advapi32.dll are called in this system service scheduling table.

At the same time, win32user and GDI functions implemented in win32k. sys exist in the Windows 2000 operating system. They belong to another type of system service calls. The corresponding system service scheduling table is keservicedescriptortableshadow, which provides the user and GDI services in kernel mode. The keaddsystemservicetable function allows win32.sys and other device drivers to add system service tables. In addition to the win32k. sys service table, the service table added with keaddsystemservicetable will be copied to both the keservicedescriptortable and the keservicedescriptortableshadow.

We can see the difference between the two types of functions in service scheduling: Win32 kernel API enters NTDLL through kernel32.dll/advapi32.dll. after the DLL is run, the int 0x2eis used to break the inner core, and the real function call is implemented in ntoskrnl.exe. Win32 user/gdi api directly enters the kernel through user32.dll/gdi32.dll, but finally in win32k. sys implements real function calls. Here we will only discuss functions related to NTDLL. dll, that is, the functions processed in our example.

　　Vi. Functions of hook system service calls

Hooking is a common mechanism for intercepting/listening information about executable code during execution. It makes it possible for us to understand the internal structure, operating mechanism, and even the idea of modifying system behavior. In a world like M $, we cannot know a lot of internal information about windows, Because windows is not Linux, but it does not mean we give up! As long as you start your brain, many things will become possible.

1. Event tracking

Do you want to know when Windows will open a process? Do you want to know which functions are called by obtaining process-related information in Windows Task Manager? We can all use the hook technology to implement the information you want. We can track the execution of zwopenprocess and the execution of zwqueryinformationprocess, including the passed parameters and returned results. As you can see, the related program t-procmon in this article is a process monitoring tool that tracks various process-related information in the system. When some of our expected events occur, the program will notify the user of what happened, which is also the expected result.

2. Modify system behavior

The operating system provides some common functions for us, such as Querying System Process Information zwquerysysteminformation (systeminformationclass = 5). It returns information about all processes/threads in the system. What should we do if we want to hide some special processes? That is, to modify the system service call, that is, to modify zwquerysysteminformation. The worker process exists in the system.

3. Study the internal mechanism of the system

The Windows operating system provided by Microsoft is a "closed" system and many internal documents are not published. We can use the hook technology to detect the internal data structure and operating mechanism of the system, learn the operating methods inside the operating system. The hook-based Windows kernel hacker technology (kernel hacking) is very popular and effective. Some of our detection systems are not publicly available, hooks can be used for non-documented technical details.

4. Miscellaneous

For example, if we want to debug a very troublesome program, we can use the Hook Technology to better help us track system actions and better understand the internal execution process of the program. Similarly, to obtain some special performance data of the system, we can also use the Hook Technology under specific circumstances.

　　VII. Implementation of hook system service calling

 

Here we will discuss that the hook object is limited to system service calls provided by ntoskrnl.exe of Windows 2000. In Windows 2000, the system service calling is in kernel mode. Therefore, we must write a device driver to access the system service scheduling table. If you are not familiar with the writing of the driver for the basic device in Windows 2000, read related books and do not describe it here. Let's first review the implementation process of the Win32 kernel API.

 

Windows 2000 system service calls provide packaged user-mode function interfaces (provided by NTDLL. dll) to users ). When the function in kernel32.dll/advapi32.dll is executed, NTDLL is called first. after checking the parameters, run the int 0x2e command to enter the kernel mode and pass the related service number and parameter list. In ntoskrnl.exe, two tables are maintained: System Service dispath table and System Service parameter table ), the Int 0x2e command is used to query the system service program pointer in ssdt. Now we know that each system service call corresponds to a service number and a service program address! If we modify the entry address of a system service program in ssdt to point to our custom function address, and then execute the code at the original system service address after executing our code, does this enable the hook for system service calls?

For us, locating the system service scheduling table is the key to implementing the hook. In Windows, there is an undisclosed unit exported by ntoskrnl.exe: keservicedescriptortable, which can be used to access and modify ssdt. Keservicedescriptortable corresponds to a data structure, which is defined as follows:

Typedef struct systemservicedescriptortable { Uint * servicetablebase; Uint * servicecountertablebase; Uint numberofservice; Uchar * parametertablebase; } Systemservicedescriptortable, * psystemservicedescriptortable;

Servicetablebase points to the address of the System Service Program, and parametertablebase points to the parameter address in sspt. They all contain such multiple units as numberofservice. We can modify the servicetablebase parameter of keservicedescriptortable to hook the system service call!

　　8. T-ProcMon-1.0 key source code analysis
　　
1. Cui-Based User Mode Control Program

Since I have already made a detailed introduction to Win32 system services before, I will not talk much about it now. If you have any questions, please refer to my previous article, you can go to the home page of fz5fz (http://www.fz5fz.org) to read the relevant articles, or download the relevant source code.

2. device-driven hook code

Command code that defines the communication between the user mode and the Kernel Mode Program:

# Define procmon_monitor (ulong) ctl_code (file_device_procmon, 0x01, method_buffered, file_any_access) # Define procmon_hidden (ulong) ctl_code (file_device_procmon, 0x02, method_buffered, file_any_access) # Define procmon_hook (ulong) ctl_code (file_device_procmon, 0x03, method_buffered, file_any_access) # Define procmon_unhook (ulong) ctl_code (file_device_procmon, 0x04, method_buffered, file_any_access)

Associate the keservicedescriptortable with the relevant data structure and define the system call:

_ Declspec (dllimport) servicedescriptortableentry keservicedescriptortable; # Define syscall (_ function) keservicedescriptortable. servicetablebase [* (Pulong) (puchar) _ FUNCTION + 1)]

Define various undisclosed functions, such as zwquerysysteminformation:

Typedef Ntstatus (* Zwquerysysteminformation )( In ulong systeminformationclass, In out pvoid systeminformation, In ulong systeminformaitonlength, Out Pulong returnlength optional );

Modify the system service call, save the original entry address, and change it to our custom program entry address, such as zwquerysysteminformation:

Oldzwquerysysteminformation = (zwquerysysteminformation) (syscall (zwquerysysteminformation )); _ ASM CLI (Zwquerysysteminformation) (syscall (zwquerysysteminformation) = newzwquerysysteminformation; _ ASM STI

Remove the hook and restore the system service call:

_ ASM CLI (Zwquerysysteminformation) (syscall (zwquerysysteminformation) = oldzwquerysysteminformation; _ ASM STI

Call the original system service program code:

Ntstatus = (oldzwquerysysteminformation) (Systeminformationclass, Systeminformation, Systeminformaitonlength, Returnlength );

A hidden process is used to modify the offset of related items in the data queue returned by the system to point to the next unit of the process to be hidden, that is, to skip the unit of the process to be hidden:

If (rtlcompareunicodestring (& pcurrentnk-> name, & proccur-> processname, true) = 0) { Rtlunicodestringtoansistring (& procnamea, & pcurrentnk-> name, true ); Dbuplint ("hidden process name: % Sn", procnamea. buffer ); If (procpre! = NULL) { If (proccur-> nextentrydelta! = 0) { Procpre-> nextentrydelta + = proccur-> nextentrydelta; } Else { Procpre-> nextentrydelta = 0; } } Else { If (proccur-> nextentrydelta! = 0) { Systeminformation = (psystem_processes) (ptstr) proccur + proccur-> nextentrydelta ); } Else { Systeminformation = NULL; } } Break; }