Windows System Background Knowledge Learning notes

Objective

For us to do reverse engineering tasks on the Windows platform on a daily basis, it is always good to have a little understanding of the underlying mechanisms and implementation principles of the system and to use these background knowledge to arm yourself.

debugger, Disassembler, add-on, unpack, virtual machine, and so on, no one is running on Windows system,

Even the use of tools such as the kernel debugger, such as softice,windbg, requires an insider's knowledge of some systems.

Recently took the time to read the "Deep analysis of the Windows operating system 6th edition of the book," so the focus of the reverse software related to the summary, some of the content with a personal understanding to polish, not out of context, but chaff.

Notes are not updated regularly, and for some authors ' opinions, try to join their own experimental process to verify.

********************************

In the Windows system architecture, there are 4 basic types of processes running in user mode, each with its own private process address space:

1. Fixed (or rigidly specified) "System support processes", such as logon processes, Session Manager sessions, which are not Windows services, that is, they are not by the Service Control Manager

To start the. The login process is named Winlogon.exe, which means "Windows logon application", so it is running in user mode. The session Manager process is named Smss.exe, and all user-mode processes are in Sysinternal's process browser

, its "Private Bytes" column shows the number of bytes used, whereas the kernel-mode component or service has no data in its private bytes column, and the Service Control Manager is one of the user-mode processes with a process named Services.exe

2. Service process, the service process is a host of Windows services that can be viewed by running services.msc. Windows services often require that they run independently of the user's login (before the user logs on, and when the user does not log on,

Must run) Svchost.exe is the service process, running in user mode

3. User applications

4. Environment Subsystem Service Process

Note that the service process and the user application do not directly invoke the native Windows operating system service, but instead call a function in one or more subsystem DLLs (dynamic-link libraries) first.

Called by A to the corresponding B function in Ntdll.dll, b then calls the native Windows operating system service, which runs in kernel mode.

This shows that the subsystem DLL is running in user mode, and it plays the role of using a documented Windows API function in the subsystem DLL to eventually invoke the native system service, which is usually not documented.

(Note that the system services here are two different things from the Windows services mentioned earlier)

Supplemental note, about "supporting DLLs for Subsystem DLLs": Ntdll.dll

Ntdll.dll is a special system support library, which is mainly used by other subsystem DLLs. The application calls the Windows API functions in a subsystem DLL, which then calls the corresponding functions in ntdll.dll, such as NtCreateFile,

Ntsetevent and so on. Although these functions that start with NT are still running in user mode, the code inside these functions contains the processor privileged mode switch instruction associated with the processor architecture, which can be switched to kernel mode.

This invokes the system service distribution (scheduler) in kernel mode. After checking the legitimacy of some parameters, the system service dispatcher calls the true kernel-mode system service, which includes the actual code inside the Ntoskrnl.exe.

That is, the conversion point from user mode to kernel mode is inside a function in Ntdll.dll.

********************************

This article is from the "free, equal, sharing, mutual help" blog, please be sure to keep this source http://shayi1983.blog.51cto.com/4681835/1617979

Windows System Background Knowledge Learning notes