First introduce the basic principles of Windows 7 system
After Windows7 Winlogon process is dynamic, a user login will create a Winlogon process, so there may be multiple login processes in the system, the Winlogon process will also end after logout.
Windbg break NtCreateUserProcess observed Windows7 start the process:
my finishing basic process tree as follows:
smss.exe autochk.exe
smss.exe 00000000 0000003c //session 0
Csrss.exe
Wininit.exe
Services.exe
Power-on self-starting service process
Lsass.exe
Lsm.exe
smss.exe 00000001 0000003c //session 1
Csrss.exe
Winlogon.exe
LogonUI.exe
LogonUI.exe is responsible for the user authentication interface. Windows7 will not use msgina.dll anymore, but use multiple processes to complete the user authentication process. The approximate process is 1. Winlogon starts LogonUI and waits for the user to input the voucher. 2. Winlogon notifies the Lsass user to log in through ALPC. 3. Lsass sequentially queries the authentication module [local authentication MSV1_0.dll] 4. Lsass returns the authentication result. The block diagram is as follows
Windows 7 debugging process
must be spit out, windows7 windbg kernel debugging application often breaks, killing me a lot of effort ~ ~ now summed up a stable and reliable way: Br>1, !process 0 0 View the basic situation of the target process, mainly Cid.
2, bp nt!KiFastCallEntry "j poi(@$teb+20) = 0x1a0"";"gc"" Replace 1a0 with the actual Cid.
3, after the breakpoint hit, bp winlogon!XXXXX
4, .reload /user, bl Look, make sure the function resolves to the 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 introduction of "Windows Internals5", winlogon is through the ALPC thing with Lsass Communication, but LogonUI didn't say much, I guess 80% is the same, it should be the RPC call.
RPC calls the server and client, the client finally RPCRT4!NdrClientCall2 executes the call, and the server will eventually execute
RPCRT4!Invoke to execute the specific function.
We breakpoint winlogon!NdrClientCall2 observe [here bp RPCRT4!NdrClientCall2 is mainly to avoid interference from other processes, because RPC is called frequently in the system], just enter a password, hit:
here we It is found that winlogon does use RPC calls to perform process interaction. Note that the function name is WluiDisplayStatus. In fact, it is clear to tell us winlogonUIDisplayStatus, then where is the RPC finally executed? Obviously, the breakpoint RPCRT4!Invoke under authui.dll Hit, then step through, as shown in the figure:
Directly from the IDA inside the authui.dll registration RPC service
Directly put all the RPC interface functions DUMP comes out, as follows:
WluirRequestCredentials is very interesting, the corresponding winlogon!WluirRequestCredentials function is as follows:
Winlogon with the logonUI authui.dll through the one-to-one corresponding RPC function to complete the interface call The following is a call to the wrong password test process, followed by the call:
serial number function name description
1
win Logn!WluiRequestCredentials asks the user to enter credentials. Note: This function is a blocking function and will wait until the user confirms the login.
2
winlogon!WluiDisplayStatus shows the status? Not studied.
3
winlogon!WluiReportResult report results.
4
winlogon!WluiDisplayRequestCredentialsError displays a login error prompt.
We found that basically the LogonUI process didn't work, so the actions are driven by Winlogon's WluiXXXXXX interface message.
IDA will find a lot of DirectUI interface code.
Winlogon uses the state machine to maintain various situations during the entire login process. The status switch is completed by Winlogon!StateMachineSetSignal
. The whole state defines DUMP as follows [not cut]:
For example: Breakpoint Winlogon!StateMachineSetSignal Click on the login interface disabled person button, hit as follows:
Note that the parameter 2 corresponds to the state, check the status 9 corresponds to g_xWinsrv_AccessNotify_Signal, winlogon and LogonUI interaction basic flow Basically clear, let's focus on the details of winlogon and lsass process to complete password authentication.
Winlogon also uses RPC calls to complete the interaction with lsass. The difference is that Windows encapsulates these RPC calls into DLLs, which are SspiCli client and SspiSrv server respectively. Finally, the RPCRT4 function is called. The evidence is as follows:
Directly from the IDA DUMP out SSPISRV RPC call interface is as follows:
Winlogon call SspiCli! LsaLogonUser to complete the login, the function finally calls Lsass::SspiSrv!SspirLogonUser
The AuthenticationInformation parameter contains the information required for login. The specific structure is as follows:
Windbg shows that the password is encrypted here, haha, the memory write breakpoint, the hit stack is as follows:
Winlogon The code corresponding to !WLGeneric_Request_Logon_Credz_Execute is as follows:
The function first requests the login credentials through the RequestCredentials function. If it is the local login mode, the function will eventually call the WluiRequestCredentials function to execute the RPC service function authui!WluiRequestCredentials of the LogonUI process, requesting user input. Login credentials.
Final authui!CRequestCredentialsCallbackData::GetCredential Get the user login credentials, the data structure is _CRED_PROV_CREDENTIAL* Unfortunately, there is no data structure definition.
Input “qqqqqqqq” Debugging shows DUMP as follows:
Under memory breakpoint: Ba w1 0027e5c8+3e, hit stack is as follows:
The function shown by windbg function CRequestCredentialsCallbackData :: GetShutdownChoice + 0x63 is wrong, actually sub_7483CBE7 function:
look at the data memory, as follows:
source address is 0027e510, length is 000000b0:
Ba w1 0027e510+3e, hit view source address 238df78: continue to track memory Ba w1 238df78+3e
View memory as follows:
The function KerbInteractiveUnlockLogonPack is a function that can be googled. well. !
02 024df8fc 024df924 024df928 authui KerbInteractiveUnlockLogonPack + 0x90
break point ba w1 023888b8 hit stack
CredProtect MSDN function as follows:
View the second parameter of the stack, it is clear text password:
Corresponding decryption function CredUnprotect
The content is actually decrypted in the lsass process, breakpoint The ADVAPI32!CredUnprotectW hit stack is as follows:
The final password authentication is done by the popular msv1_0!LsaApLogonUserEx2, as follows:
The above is the record of the picture!