简短的回答

有三个独立的问题声称“安全桌面”的名称：

• Windows 内置函数，如 GINA 和Credential Provider Model。
• 以同一用户身份运行的特权与非特权应用程序的分离（名义上防止特权升级），这可能与也可能不相关：
• SwitchDesktop()，这是 KeePass 正在使用的，可能会或可能不会（我不确定）对 DLL 注入有抵抗力。

详细解答

作为如何构建 Windows GUI 的快速入门，基本上所有内容都通过一个名为CreateWindow()（我的意思是所有内容、每个按钮、每个菜单、所有内容）的函数运行，并被赋予一个hWnd或窗口句柄。修改这些窗口是通过另一个函数完成的，SendMessage().

这就是问题所在。作为用户模式应用程序，通过正确的 API 调用，我可以相当轻松地将消息发送到其他 Windows。让按钮从其他人的表单中消失是相当简单的。执行 DLL 注入和挂钩接收消息的消息循环（操作系统在发生事情时发送 Windows 消息）有点困难，但没有那么难。如果我可以挂钩这些事件，我可以自动提交您的“是/否”表格。或者，我可以将标签从ReallyDodgyVirus.exeto更改为explorer.exe您不会更聪明。

插入：一篇非常好的文章，介绍了将代码放入正在运行的进程的地址空间的各种技术。

现在，KeePass 在做什么？

对源代码的简短阅读显示他们正在使用CreateDesktop()，SwitchDesktop()并CloseDesktop()创建第二个桌面连接到您正在使用的物理查看设备。在英语中，他们要求内核为他们创建一个独立的桌面，其hWnd对象超出任何其他应用程序的SendMessage().

我应该指出，SwitchDesktop暂停更新默认桌面的 UI。我不确定消息循环是否也被冻结 - 我怀疑不是因为桌面是作为新线程创建的。

在这种情况下，KeePass正在绘制 UI，所以按照我的理解，执行不是NT AUTHORITY/SYSTEM. 相反，新桌面的创建基本上与当前桌面的其余部分隔离开来，从而保护它。我很乐意对此进行纠正。但是，请参阅SwitchDesktop 的 MSDN：

如果桌面属于不可见的窗口站，则 SwitchDesktop 功能将失败。从与安全桌面（如 WinLogon 和 ScreenSaver 桌面）关联的进程调用 SwitchDesktop 时，也会失败。与受保护桌面关联的进程包括自定义 UserInit 进程。此类调用通常会因“拒绝访问”错误而失败。

我相信这意味着这些对话框（屏幕保护程序、Windows 登录）更深入地构建到 Windows 中，以便它们始终执行，NT AUTHORITY\SYSTEM并且UserInit进程在所需权限级别的有效身份验证上创建子进程。

我提出这个的原因是因为我认为有两个问题：不同的桌面和权限分离。来自 Mark Russinovich对 Secure Desktop 主题的讨论：

Windows 完整性机制和 UIPI 旨在为提升的应用程序创建保护屏障。其最初的目标之一是防止软件开发人员走捷径并利用已经提升的应用程序来完成管理任务。以标准用户权限运行的应用程序不能将合成的鼠标或键盘输入发送到提升的应用程序以使其执行投标或将代码注入提升的应用程序以执行管理操作。

正如 SteveS 所说，UAC 运行一个单独的桌面进程作为NT AUTHORITY/SYSTEM. 如果您可以通过流程资源管理器捕获正在运行的 UAC ( consent.exe)，它看起来像这样：

将权限提升为进程我没有具体细节，但我认为我理解的是：我相信 Windows API 中的权限提升过程会导致进程运行为NT AUTHORITY/SYSTEM（因此能够以任何权限执行新进程它想要，在这种情况下是管理员）。当应用程序请求更高权限时，会在本地新桌面上向您询问该问题，您的任何应用程序都无法获得桌面句柄或任何 GUI 元素句柄。当您同意时，consent.exe以特权用户身份创建进程。因此，运行的进程NT AUTHORITY\SYSTEM是需要创建新的特权进程的结果，而不是创建安全桌面的方法。桌面与默认桌面不同的事实在这两种情况下都增加了安全性。

我相信 Mark 上面的意思是，除了这些安全桌面之外，还有两件事正在发生：

• 您的默认管理员桌面实际上是在无特权运行的，这与 Windows XP 和更早版本相反，并且
• 非特权和特权应用程序现在存在于不同的桌面上（免责声明：可能只是内存中对象的 ACL，我不确定），确保非特权代码无法访问特权对象。

Windows 登录 UI 在 Vista/7 中再次不同。

显然，这些方法都不会保护您免受内核模式 rootkit 的攻击，但它们确实可以通过隔离特权应用程序或在 KeePass 的情况下，敏感对话框来防止特权升级和 UI 完整性损害。

编辑

在仔细查看 KeePass 代码后，我看到了这段方便的 C#：

Bitmap bmpBack = UIUtil.CreateScreenshot();
if(bmpBack != null) UIUtil.DimImage(bmpBack);
/* ... */

SecureThreadParams stp = new SecureThreadParams();
stp.BackgroundBitmap = bmpBack;
stp.ThreadDesktop = pNewDesktop;

从这里你可以看到，实际上为了模仿许可.exe，KeePass 对背景进行了截图，将其调暗并使用旧桌面的背景创建新桌面。因此，我怀疑旧桌面即使没有被渲染也会继续运行。我认为这证实了 KeePass 和（我怀疑许可程序在 UI 方面做同样的事情，它只是在 的上下文中启动）NT AUTHORITY\SYSTEM都没有发生任何神奇的动作。consent.exeNT AUTHORITY\SYSTEM

编辑 2

当我说 DLL 注入时，我特别想到 DLL 注入来破坏 UI。DLL 注入在 KeePass 上仍然可以作为一个进程，我只是不确定它是否可以用来影响安全的 UI。但是，它可以用于访问进程及其线程的内存，从而获取输入的密码预加密。很难，但我认为可能。如果有人知道，我将不胜感激。

“安全桌面”是只能由系统本身运行的桌面。这听起来有点奇怪，可能并不能解释太多。

在 Windows 中，桌面是允许您与进程交互的视图。当您登录 Windows（登录提示）时，您就在桌面上。当您登录并查看开始菜单时，您将位于一个单独的桌面上。当你锁定你的电脑时，你又在另一个桌面上。当 UAC 弹出时，您在另一个桌面上。Windows中有很多不同的桌面。

安全桌面是超出其他应用程序可访问性范围的桌面。登录桌面是安全桌面（由 winlogon.exe 创建），UAC 桌面也是如此。没有其他进程可以与桌面交互，因此没有其他进程可以执行诸如激活按钮或读取文本框内容之类的操作。这就是 UAC（理论上）有用的原因。

第三方应用程序可以创建一个安全桌面来请求信息（例如主密码），然后将其传递给相关应用程序。这样，理论上没有其他进程可以窥探密码。

这篇关于 UAC 如何在安全桌面上工作的文章的前半部分是安全桌面的一个很好的入门：http: //blogs.msdn.com/uac/archive/2006/05/03/589561.aspx。

安全桌面在本地系统帐户下运行，除 OSK、Narrator 等之外没有其他进程可以与之交互，它由 winlogon.exe 启动，您可以在注册表 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 中通过更改禁用它PromptOnSecureDesktop 的值从 1 到 0 如果您在系统帐户下运行 cmd.exe，它仍然不会与安全桌面交互，并且当您在 UAC 提示下单击以管理员身份运行时看到的暗淡桌面是安全桌面并且当您按下 ctrl+ Alt+Del 和您看到的带有锁定此计算机等选项的天蓝色屏幕也是安全桌面，Windows 默认具有三个桌面 1 winlogon 2 屏幕保护程序 3 userdesktop