先简要梳理一下Windows登录验证流程中的几个关键环节。
通常情况下，winlogon进程通过gina.dll获取用户输入的用户名和密码，随后通过LPC将这些信息传递给lsass进程。lsass进程继而调用默认的认证包msv1_0.dll，由该模块负责核对密码是否正确。而msv1_0.dll会从SAM数据库中提取用户信息，其中包含了密码的哈希值。
要构建一个后门，关键在于沿着这一调用链条，定位到最底层的函数，并在该处实施修改。
经过分析，这个最底层的函数位于lsass进程的msv1_0.dll模块中。lsass调用的核心函数是：
msv1_0!LsaApLogonUserEx2
思路非常明确——对lsass进程进行调试，并在该函数上设置断点。
当时采用Windbg配合VMware，通过dbgsrv进行远程的用户态调试。Spat在其博客中详细介绍了使用dbgsrv调试LSA的方法，具体操作如下：
在虚拟机（被调试端）运行：
dbgsrv.exe -t tcp:port=1234,password=spat
然后在调试端运行：
windbg.exe -premote tcp:server=192.168.1.102,port=1234,password=spat
不过有一个小问题：如果登录之后才启动dbgsrv，它会随着登录进程被关闭。因此，这里采用了一个任务计划，让dbgsrv在开机时自动运行。
虚拟机启动后，dbgsrv即可就位，然后用Windbg连接并附加到lsass进程。在msv1_0!LsaApLogonUserEx2处设置断点，让lsass继续执行。随后进行登录操作，Windbg果然成功中断。
这里不得不提Windbg中一个非常强大的命令——wt。它可以一路追踪函数调用关系，直至返回。用法在Windbg帮助文档中有详细说明。不过wt是单步执行，因此运行速度较慢。
wt输出的文本量很大，阅读起来比较困难，于是编写了一个Python脚本，将其转换为TreeCtrl视图以便浏览。注意鼠标点击的那个函数：ntdll!RtlCompareMemory。
经过反复调试，可以确定该函数正是我们要找的那个“最底层的函数”。
SIZE_T RtlCompareMemory(IN CONST VOID *Source1, IN CONST VOID *Source2, IN SIZE_T Length);
更为关键的是，在这个过程中我们弄清楚了验证密码时该函数的调用细节：
- Source1：从SAM中取出的用户密码的Unicode形式MD4哈希。
- Source2：用户输入密码的Unicode形式MD4哈希。
- Length：始终为16，因为MD4哈希正好是16字节。
明确了这些信息，实现一个替代函数就水到渠成了：
int WINAPI MyRtlCompareMemory(void *a, void *b, int len) { if (len == 16 && pRtlCompareMemory(PASSWD_HASH, b, len) == 16) return 16; return pRtlCompareMemory(a, b, len); }
这里的pRtlCompareMemory是一个全局变量，存储了真正RtlCompareMemory的地址；PASSWD_HASH则是预设通用密码的哈希值。使用MyRtlCompareMemory去hook掉原始函数，即可实现预期效果：只要比较的是16字节的数据，且第二段内存恰好匹配我们的哈希，就直接返回成功，无论第一段内存的内容是什么。
可能有人会担心：hook了msv1_0模块中所有调用RtlCompareMemory的地方，会不会引发问题？实际上大可放心，恰好同时满足比较16字节且第二段内存与我们的哈希完全一致的概率极低。
实现hook的方法有很多，这里选择了最便捷的一种——IAT hook结合DLL注入。
为此编写了一个小工具InjectDll.exe来完成注入操作。
注入的passdoor.dll会在其DllMain中完成IAT hook。该技术已经非常成熟，网上有大量现成的实现代码，这里不再赘述。
此外还编写了一个pdconfig.exe小工具，用于直接修改passdoor.dll中的预设哈希值。这样更换密码时无需重新编译dll，大大简化了操作。
使用方式：
- 注入：
InjectDll.exe -i pid_of_lsass full_path_of_passdoor.dll - 卸载：
InjectDll.exe -U pid_of_lsass full_path_of_passdoor.dll
以上就是整个后门实现的核心思路。代码本身并不复杂，关键在于找到最合适的hook点，并深入理解整个认证流程的底层细节。
