基于Windows的操作系统不再是移动环境中的默认和主要选择。安卓的开源性吸引了很多OEM的粉丝，所以现在用Windows的手机越来越少了。但是，如果你属于日常生活中继续使用Windows设备的人，你会发现一些新闻。是好是坏，取决于你的立场和对这个新闻用例的解读。
据Ars Technica和TheRegister报道，这个消息来自网站，可能会让你头疼(别开玩笑了)。一些开发人员(@never_released和@ the pack 0 Lian)发现，微软为调试而创建的后门已经打开了在Windows设备上禁用安全启动的可能性。
安全起步，这是什么？
第一次启动Windows设备时，启动过程一般按照以下顺序：UEFI(统一可扩展固件接口，是BIOS的替代品)-Boot Manager-Boot Loader-Windows。UEFI是有安全启动功能的地方。顾名思义，它与安全引导结合使用，通过在后续步骤中要求数字签名来提高安全性。本质上，如果引导加载程序没有使用UEFI期望使用的密钥进行签名，则引导设备的过程将不会完成。
安全引导是一项可选功能，但微软已强制启用该功能，以便从Windows 8及更高版本获得Windows认证。原因是安全启动使得恶意软件作者很难在启动期间插入代码。但是，安全引导的一个副作用是，它让Windows机器上的双引导有点复杂，因为第二个操作系统及其所有必要的组件也需要数字签名，否则，需要禁用安全引导。还有很多其他的问题，有经验的双首发知道的比我一段话能解释的还要多。
现在，即使用户想禁用安全引导，一些设备也不能禁用。在这个领域，我们的话题已经从所有的Windows设备(包括台式机)急剧减少到特定的Windows设备，比如Windows Phone设备、Windows RT设备、一些Surface设备甚至HoloLens。这些最终用户设备已经锁定了安全引导，这意味着最终用户不能修改或禁用与安全引导相关的方面，并且通过扩展，他们不能以未经授权的方式访问微软的最终用户操作系统。
但是，出于正在进行的官方开发的目的，安全启动需要放松一点。锁定的设备上有一个安全引导策略，它可以帮助授权开发，而无需禁用安全引导。正如研究用户提到的，这个安全启动策略文件是在Windows启动期间由启动管理器加载的。策略文件还可以包含注册表规则，而注册表规则又可以包含策略本身的配置。同样，策略文件必须经过签名，并且存在其他适当的设置，以确保只有Microsoft可以设置这些更改。
签名元素还依赖于应用程序中使用的所谓的设备标识。我就让博文在这里解释一下，因为有些部分我不太清楚：
另外，还有一个东西叫DeviceID。这是一些UEFI PRNG输出的加盐SHA-256散列的第一个64位。在Windows Phone和Windows RT上应用策略时使用它(mobilestaRTup在Phone上设置它，在RT上首次启动时在SecureBootDebug.efi上设置它)。
在电话上，策略必须位于EFIESP分区上的特定位置，其文件名包括十六进制形式的DeviceID。(对于红石，它已被更改为UnlockID，由bootmgr设置，并且只有原始的UEFI PRNG输出)。
基本上，bootmgr在加载时会检查策略，如果它包含的DeviceID与运行bootmgr的设备的DeviceID不匹配，则无法加载策略。任何允许启用测试签名的策略(微软称之为“零售设备解锁/RDU策略”并安装为解锁设备)都应锁定为设备标识(在红石和更高版本上解锁)。的确，我有几个类似的政策(由Windows Phone生产证书签名)，唯一的区别就是包含了DeviceID和签名。如果没有安装有效的策略，bootmgr将使用位于其资源中的默认策略。此策略是使用BCD规则来防止启用测试签名等的策略。
这是事情有趣的部分。在Windows 10 v1607的开发过程中，微软出于内部测试和调试的目的，创造了一种新的安全启动策略(以下简称SBP)。这个策略本质上是“互补”的，没有DeviceID，会导致其设置合并到现有的启动策略中。引导管理器加载旧的SBP，验证其签名和真实性，然后加载这些辅助引导策略。这里的问题是，补充政策本身并没有得到进一步的验证。此外，早于Windows 10 v1511的启动管理器不知道这些策略的互补性是否存在，因此它们的反应就像加载了完全有效和签名的策略一样。同样，这种行为很可能是内部开发的结果，所以开发人员不必做每一个操作
作系统版本都进行签名，而不必在设备上进行小的更改。此SBP被称为“金钥匙”，因为它基本上使签名检查的目的无效。尽管此SBP处于停用状态，但无意中将其运输到零售设备上。开发人员找到了此SBP，并告知了他们的发现。现在，可以在Internet上找到 SBP 了，该特定的zip用于在Windows RT设备上安装SBP。
这是什么意思?
如果加载了补充SBP，则可以为Windows启用测试签名，以允许您加载未签名的驱动程序。此外，由于这些策略在引导过程的引导管理器阶段之前起作用，因此您可以损害整个订单的安全性并运行未经授权的(读取自签名)代码。这给打算修改授权范围以外的Windows部分的用户以及恶意软件创建者都提供了很多可能性。
这一发现的作者集中于整个惨败的讽刺。Microsoft锁定了某些设备上的安全启动，以防止未经授权的更改，但是它内置了一个后门，可以让它们继续进行开发和调试。但是，这种后门为在所有运行Windows的设备上禁用安全启动铺平了道路，使整个过程变得毫无意义。
现在，不愿意的用户不仅可以在仅Windows的平板电脑和手机上安装Linux发行版(甚至可以在Android上)，不愿意的用户还可以通过破坏对设备的物理访问来安装恶意的引导程序。尽管前者是我们可以跃跃欲试的事情，但后者并没有真正灌输很多信心。这是双向的，它向我们展示了为什么安全是一把双刃剑。此外，SBP本质上是通用的，无论其体系结构如何，都可以在任何设备上使用。对于可以轻松关闭安全启动的台式机来说，它并不是特别有用，但是对于您不能随意使用安全启动的设备来说，它的作用范围很大。
那么，解决方法是什么?
微软确实发布了一些补丁，但开发人员坚持认为该问题尚未完全解决。您可以检出这些修补程序(MS16-094和MS16-100)，然后在博客文章本身上阅读它们为什么不能解决问题的信息。如果它们是正确的，则此问题尚无解决方法或修补程序，尽管这不会阻止Microsoft尝试在路上设置更多的障碍。
接下来是什么?
有很多可能性，其中一些正在我们的Windows论坛上酝酿。您可以查看有关Windows Phone 8开发和黑客的论坛以及有关Windows 8，Windows RT和Surface开发和黑客的论坛。您还可以在其他用户正在讨论的某些设备上找到指令线程。
此调试后门的存在和SBP的泄漏不仅对于锁定Windows设备的第三方开发很重要，而且还向我们显示了一个严峻的提示：如果留有故意的后门会发生什么。最近对安全的关注已转向调查机构，要求存在此类后门以协助其合法调查目的。但是这些方法迟早会落入错误的手中。原本打算用作打击和司法协助的工具，后来有一天将成为本身的工具。