Introduction to system service distribution and distribution

Introduction to system service distribution and distribution

Welcome to reprint, reprint please indicate the source: http://www.cnblogs.com/uAreKongqi/p/6597701.html

0x00. above

As far as we know, the trap processor in the Windows operating system kernel distributes interruptions, exceptions, and system service calls. Here we will give a brief explanation of the system service distribution.

 

0x01. Look at different processors for system calling

(1 ). on the x86 processor before PentiumII, Windows uses the int2e command to generate a trap. As a result, the execution thread switches to the kernel mode and enters the system service distributor. eax saves the system service number, edx points to the parameter list. Finally, the user mode is returned through the iret command;

Check the 2e Member of the IDT and find that the address saved by the member is the address of the system call distributor. Then, after u checks the KiSystemService, you will find that after the status of the Register is saved, he went to the KiFastCallEntry! (Test in Win7 x86)

　　　　　　

(2 ). on the x86Pentium II processor, Windows uses the sysenter command. The address of the kernel's system service distributor routine is stored in a MSR associated with the command, eax, edx stores the same content as int2e. Finally, the user mode is returned through the sysexit command;

Read 0x176 of MSR, which contains the address of the System Service distributor. It is found that KiFastCallEntry is actually called )! (Test in Win7 x86)

　　　　　　

(3 ). in the x64 architecture, Windows uses the syscall command to save the system call number in eax. The first four parameters are placed in the register (rcx/rdx/r8/r9, the remaining parameters are in the stack.

The 64-bit platform reads the MSR 0xC00000082, which stores the 64-bit syscall. When we run this URL, we found that this is the x64 System Call Distribution portal KiSystemCall64 (tested in Win7 x64)

Ps: The SSDT and SSSDT addresses can be obtained through hardcoding through the KiSystemCall64 address.

......

 

We found that in 32-Bit mode, the system call distribution operation will go to the KiFastCallEntry, while in 64-Bit mode, the system call distribution operation will go to KiSystemCall64, and then complete the corresponding system service call. So we have a question: How did the system access these system calls?

 

0x02. For example, how to view system calls

Here, we use ntopenprocesson windows x86 platform as an example, and switch it to a process (for example, explorer.exe) and u to NtOpenProcess. Here we show the NtOpenProcess disassembly in ntdll:

　　

We have two gains: one is that the system service number is put in eax, the other is that it calls an address, and the call command will execute the system service distribution Code established by the kernel, this address is saved in ntdll! _ KUSER_SHARED_DATA + 0x300. Let's look at this address:

　　

We seem to have a little bit of eye-catching. The system call occurs in ntdll. That is to say, the switch from ring3 to ring0 is completed in ntdll, where eax saves the service number, saves the first address of the parameter list in edx. The service number can be used to locate the target service routine in SSDT.

Each member of the 32-bit KeServiceDescriptorTable is the absolute address of the target system service. The actual address of the 64-bit target system service is the offset saved by each member of the KeServiceDescriptorTable (four digits after the right shift) + KeServiceDescriptorTable base address;

The address of the system service table in the starting line refers to the SSDT table in ntoskrnl.exe. However, when a USER or GDI service is called, the service table address is changed to the system service table in win32k. sys.

 

0x03. Complete call process from user layer to kernel layer

(1) When a Windows application calls OpenProcess in Kernel32.dll, it imports and calls the NtOpenProcess function in the API-MS-Win-Core-File-L1-1-0.dll (A MinWin redirect Dll;

(2) The above NtOpenProcess function will call the OpenProcess function in KernelBase. dll. Here is the real implementation of the function, and it will check the parameters related to the subsystem;

(3). Then KernelBase! OpenProcess will call the NtOpenProcess function in ntdll. dll, and the system call will be triggered here (ntdll! KiFastSystemCall) to pass the system service number and parameter list of NtOpenProcess;

(4). the KiSystemService function in the System Service distributor (ntoskrnl.exe) calls the real NtOpenProcess function to process the I/O Request.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0x04. system distribution in kernel mode

In system calls, if the original mode is user mode, when the parameters passed to the system service point to the user space buffer, the kernel mode code checks whether the buffer can be accessed before operating the buffer. When the original mode is kernel mode, the default parameter is valid, and the parameter is not checked. Now that the kernel mode is in use, you do not need operations such as int2e interruption or sysenter. However, if you directly call system service functions such as NtOpenProcess by calling APIs, the original mode value stored by the kernel is still the user mode (the user mode is of course before the kernel is imported ~), However, it is detected that the passed address is a kernel mode address (called in the current kernel mode), which causes the call to fail (STATUS_ACCESS_VIOLATION ).

Here we will introduce the kernel's Zw series functions. They are not only the alias or packaging of functions of the Nt version, but also the revision corresponding to the calls of the Nt series systems, using the same system call distribution mechanism. They will create a fake interrupt stack (the stack generated after the CPU is interrupted) and directly call the KiSystemService routine. This process is simulating CPU interruptions, as if the call comes from the user mode, after detecting the actual privilege level of the call, change the original mode to the kernel mode, which also saves the parameter verification and successfully calls NtOpenProcess!

　　

 

 0x05. Summary

Ring3 ---> Ring0 System Call: Kernel32.dll (API) ---> ntdll. dll (Nt/Zw) ---> convert user mode to Kernel Mode ---> Ntoskrnl.exe (Nt) ---> complete the I/O Request (original return)

Ring0 ---> Ring0 System Call: Ntoskrnl.exe (Zw) ---> Ntoskrnl.exe (Nt)

For the above understanding, refer to Chapter 3 of "in-depth analysis of Windows OS 6". If there are any errors, please point out that I will humbly ask for advice!