http://www.blogcn.com/user8/flier_lu/index.html?id=1618917
In the first two articles in this series, a brief introduction to the relevant knowledge of the user state debugger structure and commissioning incident in the Win32 debug interface
Analysis of Win32 Debug Interface Design and Implementation [1] User Status Detector Structure Forward Win32 Debug Interface Design and Implementation [2] Debugging Events
In this section, the creation process of the debug subsystem that provides support for the above function will be further expanded in the core of the NT system.
From the previous two sections, we can learn that the Win32 debug interface is actually completed by the majority of work through a debug interface port "dbguiapipiPort". The user status is completed by this port to receive and receive debug events. Therefore, the analysis of the trial subsystem will also start from this port.
First take a look at the invoice subsystem and the creation process of debugging interfaces and debugging service ports.
In Chapter IV of "Windows 2000 Internal Reverse", Solomon introduces the entire process of NT system startup. Where SMSS (session manager) is the first native application (NTLDR) that starts program NTLDR loads (not using the API of the Win32 subsystem), which is trusted as part of the operating system to complete the system initialization. Win32 Subsystem CSRSS (Client-Server Runtime Subsystem) and System Logging Process Winlogon is loaded after the SMSS initialization work is performed, and the work accepts the user's login run. Where the SMSS system initialization includes initialization of the tester. A start-up process tree is as follows:
The following is quoted:
SYSTEM (4)
SMSS.exe (388)
CSRSS.EXE (436)
Winlogon.exe (460)
Services.exe (504)
Lsass.exe (516)
SMSS.exe's entry function (SMSERVERSMSS.C: 28) first check for debug parameters in parameters incorporated from NTLDR through the command line, if there is, put the SMPDebug global variable (SMSERVERSMSRVP.H: 82) The Smpinit function is then called (SMSERVERSMINIT.C: 683) to initialize the Session Manager. SmpInit function at the completion of initialization, configuration SMSS service port "SmApiPort" and two processing threads for sending a service request to the SMSS after, calls SmpLoadDataFromRegistry function (smserversminit.c: 934) loaded Session keys from the registry HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Manager The relevant parameters of Manager. Session Manager Configuration Registry Key The needed, Optional, and Kmode three keys, which define the subsystem type supported by the system. Typically, Required includes debug and windows subsystems; Optional includes an optional POSIX subsystem; kmode defines the core subsystem Windows in the core state implementation Win32k.sys. The subsystem name further points to the executable file image that implements the subsystem. A typical setting is as follows:
The following is quoted:
HKEY_LOCAL_MACHINESYSTEMCURRENTCONTROLSETCONTROLSession ManagerSubsystems
Required = "debug windows" optional = "pOSIX"
KMode = "% systemroot% system32win32k.sys" debug = ""
Windows = "% SystemRoot% system32csrss.exe ObjectDirectory = Windows SharedSection = 1024,3072,512 Windows = On SubSystemType = Windows ServerDll = basesrv, 1 ServerDll = winsrv: UserServerDllInitialization, 3 ServerDll = winsrv: ConServerDllInitialization, 2 ProfileControl = Off MaxRequestThreads = 16 "
POSIX = "% systemroot% system32psxss.exe"
Subsystem included in Required, SMSS will automatically load and initialize. It is worth noting that DEBUG in the subsystems sub-key is different from other subsystems such as Windows, POSIX, and does not point to the actual executable. Because the trial subsystem is determined by the SMPLOADDATAFROMREGISTRY function according to the subsystem name is Debug, it is determined whether the SMPEXECUTECOMMAND function (SMSERVERSMINIT.C: 3235) is called to execute the sub-system command (SMSERVERSMINIT.C: 3235), indicating that the currently needed is debugging. Subsystem. Once the SMPEXECUTECMMAND function entry is discovered that the flag parameter contains the SMP_DEBUG_FLAG flag, the SMPLOADBGSS function immediately calls the SMPLOADBGSS function (SMSERVERSMDBG.C: 108) actually loads the tuning subsystem and returns directly, no longer resolving and executes commands.
Complete initialization tuning subsystem function call flow is as follows:
The following is quoted:
Main (smserversms.c: 28)
Smpinit (smserversminit.c: 683)
SMPLoadDataFromregistry (smserversminit.c: 934)
SmpexecuteCommand (smserversminit.c: 3235)
SMPLOADDBGSS (SMSERVERSMDBG.C: 108)
Some code loaded by the Sub-system load in Win2003 is placed in a separate SMPLoadSystemsFormUsession function, while the Debug subsystem is changed to load in each session. That is, the SMP_DEBUG_FLAG flag of incoming SMPEXECUTECOMMAND function can cause this function to exit directly.
In the SMPLOADBGSS function, the user and the core state debug-time response port and the processing thread in the tester and the core state debugging time are initialized. The pseudo code is as follows:
The following is quoted:
NTSTATUS SMPLOADDBGSS (In Punicode_String DbgssName)
{
NTSTATUS ST = dbgpinit (); // Initialize the user status debugger environment
IF (! NT_Success (ST)) Return ST;
ST = dbgssinitialize (...); // Initializing the core state debugger environment
SMPDBGSSLOADED = true; // debug subsystem has been successfully loaded
Return status_success;}
The DBGINIT function (smserverdbginit.c: 26) first completes the initialization of the application threaded Hash table; then constructs a security descriptor with all access rights; use this security descriptor to create two LPC port object "DBGSSAPIPORT" and "DBGUIAPIPORT ", Are used by the user status debugger to connect debugging services and debug interfaces; finally create two threads to handle debug events on both ports, threads by DBGPSSAPILOP functions (SMSERVERDBGLOOP.C: 123) and DBGPUIAPIOP.c : 288) Complete the actual event processing work. DBGSSINIALIZE functions (NTOSDLLDLLSSTB.C: 429) first establish links to the debugging service port of the user status debugger; then initialize the global variable of the core state debugger debugging service; finally create the user thread uses the DBGSSPSRVAPILOP function (NTOSDLDLLLSSTB.C: 737) Handling the core debug event. This section is not involved in this section, and the principle of the core state debugger is discussed later in this section.
In the next section, the event handling thread workflow for debugging the service port and the debug interface port of the debugging interface and how to cooperate with the user status called completion of the debugging work.
