首先介紹Windows 7系統基本原理

　　Windows7 以后 Winlogon 進程是動態的，有用戶登錄就會創建一個 Winlogon 進程，因此系統中完全 可能存在多個登錄進程，注銷后 Winlogon 進程也會隨之結束。

　　Windbg 斷點 NtCreateUserProcess 觀察 Windows7 啟動流程：

　　我整理的基本進程樹如下：

　　smss.exe autochk.exe

　　smss.exe 00000000 0000003c //session 0

　　Csrss.exe

　　Wininit.exe

　　Services.exe

　　開機自啟動服務進程

　　Lsass.exe

　　Lsm.exe

　　smss.exe 00000001 0000003c //session 1

　　Csrss.exe

　　Winlogon.exe

　　LogonUI.exe

　　LogonUI.exe 負責用戶認證界面，Windows7 以后不再使用 msgina.dll，而是使用多個進程配合，完成用戶 認證過程，大致過程為 1、Winlogon 啟動 LogonUI 等待用戶輸入憑證 2、Winlogon 通過 ALPC 通知 Lsass用戶登錄 3、Lsass 依次查詢認證模塊【本地認證 MSV1_0.dll】4、Lsass 返回認證結果。框圖如下

 

　　Windows 7調試過程

　　必須要吐槽下，windows7 下 windbg 內核調試應用程序經常斷不下了，害我浪費了很多功夫~~現總結 了一個穩當可靠的辦法：

　　1、!process 0 0 查看目標進程的基本情況，主要是 Cid。

　　2、bp nt!KiFastCallEntry "j poi(@$teb+20) = 0x1a0'';'gc'" 把 1a0 替換成實際的 Cid 即可。

　　3、等斷點命中后，bp winlogon!XXXXX

　　4、.reload /user 下，bl 看一下，確保函數解析成地址。

　　首先看 Winlogon 和 LogonUI 之間的交互，LogonUI.exe 就是一個殼，類似 svchost，真正的功能是通 過 authui.dll模塊完成的，從《Windows Internals5》介紹，winlogon 是通過 ALPC 的東西同 Lsass 通信的，但是 LogonUI 沒怎么講，我估計八成也是一樣的，應該就是 RPC 調用。

　　RPC 調用分服務端和客戶端，客戶端最終 RPCRT4!NdrClientCall2 執行調用，而服務端最終會執行

　　RPCRT4!Invoke執行具體的函數。

　　我們斷點 winlogon!NdrClientCall2觀察下【這里不 bp RPCRT4!NdrClientCall2主要是避免其他進程干 擾，因為 RPC 在系統中調用很頻繁】，隨便輸入個密碼，命中：

　　這里我們發現 winlogon 的確使用了 RPC 調用來執行進程交互，注意這個函數名是 WluiDisplayStatus，其 實很明確的告訴我們 winlogonUIDisplayStatus，那么該 RPC 最終在哪里被執行呢?很顯然是在 authui.dll 下斷點 RPCRT4!Invoke 命中，而后單步跑一下，如圖：

　　直接從 IDA 里面翻了下 authui.dll注冊 RPC 服務

　　從

　　直接把所有的 RPC 接口函數 DUMP 出來，如下：

　　其中 WluirRequestCredentials很惹人關注，對應的 winlogon!WluirRequestCredentials函數如下：

　　Winlogon 同 logonUI 的 authui.dll 中通過一一對應的 RPC 函數完成接口調用，下面是一次錯誤密碼測 試過程時，依次命中的調用情況：

　　序號函數名描述

　　1

　　winlogon!WluiRequestCredentials請求用戶輸入憑證，注：該函數是阻塞函數，會一直等待直到用戶確認登錄才返回。

　　2

　　winlogon!WluiDisplayStatus顯示狀態?未細究。

　　3

　　winlogon!WluiReportResult通報結果。

　　4

　　winlogon!WluiDisplayRequestCredentialsError顯示登錄錯誤提示。

　　我們發現基本上 LogonUI 進程沒干啥活，所以的動作都是 winlogon 的 WluiXXXXXX 接口消息驅動的，

　　IDA 里面會發現大量的 DirectUI 界面代碼。

　　Winlogon 使用狀態機來維護整個登錄過程中的各種情況處理，通過 Winlogon!StateMachineSetSignal

　　來完成狀態切換，整個狀態定義 DUMP 如下【未截全】：

　　例如：斷點 Winlogon!StateMachineSetSignal點擊登錄界面殘障人士按鈕，命中如下：

　　注意其中的參數二對應的是狀態，查下狀態 9 對應的正是 g_xWinsrv_AccessNotify_Signal，winlogon和 LogonUI 的交互基本上流程基本比較清晰了，下面我們重點研究下 winlogon 同 lsass 進程完成密碼認證的一些細節。

　　Winlogon 同樣使用 RPC 調用完成同 lsass 的交互，不同的是 windows 把這幾個 RPC 調用封裝成了 DLL形式，分別是 SspiCli 客戶端和 SspiSrv 服務端，最終還是調用了 RPCRT4 函數，證據如下：

　　直接從 IDA 中 DUMP 出 SSPISRV 的 RPC 調用接口如下：

　　Winlogon 調用 SspiCli!LsaLogonUser完成登錄，該函數最終通過RPC 調用 Lsass::SspiSrv!SspirLogonUser

　　其中 AuthenticationInformation 參數里面包含了登錄所需的信息，具體結構如下：

　　Windbg 顯示這里密碼被加密了，哈哈，下內存寫斷點，命中堆棧如下：

　　Winlogon!WLGeneric_Request_Logon_Credz_Execute 對應的代碼如下：

　　該函數首先通過 RequestCredentials 函數請求登錄憑證，如果是本地登錄模式，該函數最終會調用 WluiRequestCredentials函數執行 LogonUI 進程的 RPC 服務函數 authui!WluiRequestCredentials，請求用戶輸入登錄憑證。

　　最終 authui!CRequestCredentialsCallbackData::GetCredential獲取用戶登錄憑證，數據結構為_CRED_PROV_CREDENTIAL* 可惜沒有數據結構定義。

　　輸入“qqqqqqqq”調試顯示 DUMP 如下：

　　下內存斷點：Ba w1 0027e5c8+3e，命中堆棧如下：

　　這里 windbg 函數顯示的函數 CRequestCredentialsCallbackData::GetShutdownChoice+0x63是錯誤的，實際 是 sub_7483CBE7 函數：

　　查看一下內存數據，如下：

　　源地址是 0027e510，長度是 000000b0 ：

　　Ba w1 0027e510+3e，命中 查看源地址 238df78： 繼續跟蹤內存 Ba w1 238df78+3e

　　查看內存如下：

　　函數 KerbInteractiveUnlockLogonPack是一個可以 google 到的函數，很好。

　　02 024df8fc 024df924 024df928 authui!KerbInteractiveUnlockLogonPack+0x90

　　斷點 ba w1 023888b8 命中堆棧

　　CredProtect 函數 MSDN 如下：

　　查看堆棧第二個參數，果然是明文密碼：

　　對應的解密函數 CredUnprotect

　　這些內容實際在 lsass 進程里面解密，斷點 ADVAPI32!CredUnprotectW命中堆棧如下：

　　最終的密碼認證還是通過群眾喜聞樂見的 msv1_0!LsaApLogonUserEx2來完成，如下：

以上是圖片的記錄哦！