如何修复 Win7系统口令登录过程调试的修复教程

　win7系统兼容性好，使用者多；在日常安装使用过程中，你就会碰到win7系统口令登录过程调试的操作问题。当我们遇到了win7系统口令登录过程调试的情况要怎么操作呢？相信大部分人面对win7系统口令登录过程调试的时候，会无从下手。这里有两个妙招，帮你轻松搞定。　　1、!process 0 0 查看目标进程的基本情况，主要是 Cid。  2、bp nt!KiFastCallEntry "j poi(@$teb+20) = 0x1a0'';'gc'" 把 1a0 替换成实际的 Cid 即可。就可以了。如果没太懂，请看下面win7系统口令登录过程调试的操作方法，不妨瞧瞧小编接下来给大家的分享。

　首先介绍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来完成，如下：

以上是图片的记录哦！