Win 7 System Password logon process debugging method

First, introduce the fundamentals of Windows 7 systems

Windows7 after the Winlogon process is dynamic, a user login creates a Winlogon process, so there may be more than one login process in the system, and the Winlogon process will end after logging off.

Windbg Breakpoint Ntcreateuserprocess Observe Windows7 START process:

I sorted the basic process tree as follows:

Smss.exe Autochk.exe

Smss.exe 00000000 0000003c//session 0

Csrss.exe

Wininit.exe

Services.exe

Power-on Self-starter service process

Lsass.exe

Lsm.exe

Smss.exe 00000001 0000003c//session 1

Csrss.exe

Winlogon.exe

LogonUI.exe

LogonUI.exe is responsible for user authentication interface, Windows7 no longer use Msgina.dll, but using a number of processes, complete the user authentication process, the general process of 

1, Winlogon start LogonUI waiting for user input voucher 

2, Winlogon through A LPC Notification Lsass User Login 

3, Lsass in order to query the authentication module "Local certification Msv1_0.dll" 

4, Lsass return certification results. The block diagram is as follows

Windows 7 Debugging process

You have to spit, Windows7. windbg kernel debugging applications often broken down, I wasted a lot of Kungfu ~ ~ Now summed up a reliable way:

1,!process 0 0 View the basic situation of the target process, mainly Cid.

2, BP nt! Kifastcallentry "J Poi (@ $teb +20) = 0x1a0"; GC ' "Replaces the 1a0 with the actual Cid.

3, after the breakpoint hit, BP winlogon! Xxxxx

4. Reload/user, BL Look, make sure the function resolves to address.

First look at the interaction between Winlogon and LogonUI, LogonUI.exe is a shell, similar to svchost, the real function is done through the Authui.dll module, from the Windows Internals5, Winlogon is through ALPC things with Lsass communication, but LogonUI not how to say, I estimate 80% is the same, should be RPC call.

RPC calls the service-side and the client, the client eventually rpcrt4! NDRCLIENTCALL2 executes the call, and the server ends up executing the

rpcrt4! Invoke executes a specific function.

We break the winlogon! NdrClientCall2 observed, "This is not BP rpcrt4! NdrClientCall2 is mainly to avoid other process interference, because RPC is called very frequently in the system ", randomly enter a password, hit:

Here we find that Winlogon did use RPC calls to perform process interaction, noting that the function name is Wluidisplaystatus, and in fact it tells us exactly where the winlogonuidisplaystatus is, so where is the RPC ultimately executed? It's obviously a breakpoint under the Authui.dll rpcrt4! Invoke hit, and then one step run, as shown:

and flipped it right out of IDA. Authui.dll Registered RPC Service

From

Dump all RPC interface functions directly, as follows:

Among them wluirrequestcredentials is very attractive, corresponding winlogon! The Wluirrequestcredentials function is as follows:

Winlogon the interface call through the one by one corresponding RPC function in the authui.dll of LogonUI, and the following is the invocation that was hit when the error-Password test procedure was followed:

Ordinal function Name Description

1

winlogon! Wluirequestcredentials requests the user to enter a voucher, note: The function is a blocking function and waits until the user confirms the login before returning.

2

winlogon! Wluidisplaystatus display status?

3

winlogon! Wluireportresult the results of the bulletin.

4

winlogon! WLUIDISPLAYREQUESTCREDENTIALSERROR Displays the login error prompt.

We found that basically the LogonUI process didn't work, so the action was Winlogon wluixxxxxx interface message driven,

IDA will find a lot of Directui interface code.

Winlogon uses a state machine to maintain a variety of situations throughout the login process, through winlogon! Statemachinesetsignal

To complete the status switch, the entire status definition DUMP follows "not truncated":

For example: Breakpoint winlogon! Statemachinesetsignal Click on the Disabled User button, hit the following:

Note that the two corresponding to the parameters of the state, check the state 9 corresponds to the G_xwinsrv_accessnotify_signal,winlogon and LogonUI interaction is basically more clear, the following we focus on Winlogon with LSASS Process to complete some of the details of password authentication.

Winlogon also uses RPC calls to complete the interaction with LSASS, unlike Windows, which encapsulates these RPC calls into DLLs, SSPICLI clients and Sspisrv server, and eventually invokes the RPCRT4 function, as evidenced by the following:

The RPC call interfaces that DUMP Sspisrv directly from IDA are as follows:

Winlogon Call sspicli! LsaLogonUser completes the login, which is eventually invoked via RPC lsass::sspisrv! Sspirlogonuse

The Authenticationinformation parameter contains the information required for login, and the structure is as follows:

Windbg display here password is encrypted, haha, down memory write breakpoint, hit stack as follows:

winlogon! Wlgeneric_request_logon_credz_execute corresponds to the following code:

The function first requests login credentials through the Requestcredentials function, and if it is a local logon mode, the function eventually calls the Wluirequestcredentials function to perform the RPC service function of the LogonUI process authui! Wluirequestcredentials, request the user to enter the login credentials.

Final authui! Crequestcredentialscallbackdata::getcredential Get user login credentials, data structure for _cred_prov_credential* Unfortunately no data structure definition.

Enter the "QQQQQQQQ" debug display DUMP.

Down memory breakpoint: Ba W1 0027e5c8+3e, hit stack.

Here the WinDbg function shows the function crequestcredentialscallbackdata::getshutdownchoice+0x63 is wrong, actually is the Sub_7483cbe7 function:

Check out the memory data.

The source address is 0027e510 and the length is 000000b0.

BA W1 0027e510+3e, hit View Source address 238df78: Continue tracking Memory Ba W1 238DF78+3E

View memory .

function Kerbinteractiveunlocklogonpack is a function that can be Google to, very good.

024DF8FC 024df924 024df928 authui! Kerbinteractiveunlocklogonpack+0x90

Breakpoint BA W1 023888b8 hit stack

The Credprotect function MSDN is as follows:

To view the second parameter of the stack, it is clear text password.

The corresponding decryption function credunprotect

These contents are actually decrypted in the LSASS process, breakpoints advapi32! The credunprotectw hit stack is as follows:

The final password certification or through the popular msv1_0! LsaApLogonUserEx2 to complete, as follows:

The above is the record of the picture Oh!