破解 Xbox 360 Hypervisor 第 3 部分：糟糕的更新改进

欢迎来到破解 Xbox 360 管理程序博客系列的第 3 部分。在这一部分中，我将回顾在发布错误更新的 PoC 后发生的事情，以及它是如何从花费约 20 分钟、成功率约 30% 到几乎瞬时完成、成功率接近 100% 的。如果您还没有阅读（或至少浏览）第 1 部分和第 2 部分，我强烈建议您阅读，因为这篇文章将引用其中讨论的大量材料。这一部分会很短，但会赶上您的第四部分，该部分涵盖了同侪压力利用，并将很快发布。 Rock Band Blitz 在 Bad Update v1.0 发布后的几个月里，其他人对其进行了两项重大改进。第一个由“ihatecompvir”和“InvoxiPlayGames”开发的项目是 Rock Band Blitz (RBB) 演示版中的一个新游戏保存入口点，名为 DaTArrest。 RBB 的演示版本是一个包文件，通常可以从 Xbox Live 商店免费下载并保存到主机的 HDD 或内存单元中。当 Xbox 360 支持使用 USB 记忆棒作为存储设备时，所有签名为从 HDD 或内存单元启动的软件包都被继承为也从 USB 存储设备启动。这意味着 RBB 演示包可以作为普通文件复制到 U 盘，并在支持它的软件版本的任何控制台上启动。通过利用游戏 DLC 解析代码中的一些内存损坏漏洞，他们能够制作一个游戏保存文件，该文件在加载时将引导错误更新第 2 阶段 ROP 链并启动虚拟机管理程序漏洞利用链。使用 RBB 作为切入点，我们不再需要 Tony Hawk American Wasteland 游戏光盘。运行 Bad Update 漏洞现在就像将一些文件复制到 U 盘、将其插入控制台并从仪表板启动 Rock Band Blitz 一样简单。 Rock Band Blitz 运行 Bad Update 漏洞文件。虚拟机管理程序竞争条件优化 在 RBB 入口点被发现后不久，我收到了来自“Máté”的拉取请求，他对漏洞利用的虚拟机管理程序竞争条件部分进行了一些改进。这些改进包括用于预计算和存储恶意密文值的哈希表、更好的缓存刷新原语以及改进的 XKE 有效负载线程和密文覆盖线程之间的线程调度。这些改进的结合将执行时间减少到几秒钟，并且竞争条件的成功率更高。密文哈希表 在第 2 部分中，我讨论了通过使用虚拟机管理程序 API 在预定内存地址创建加密内存分配来攻击加密内存，并使用两种不同的内存路径来捕获某些选定的明文数据的密文。使用这个原语，我能够制作密文数据来获取内核模式代码执行，以及用于攻击引导加载程序更新 XKE 有效负载中的 LZX 解压缩代码的密文数据。内存加密方案中使用的白化值是 12 位大，它为某些给定的明文数据提供 1024 个唯一的密文组合。然而，在我最初的 PoC 中，我只为 1024 个可能的白化值之一生成密文，其原因是我这边出现了两部分失败。当我最初设计密文攻击原型时，我实际上尝试使用密文组合的查找表，但我无法让它发挥作用。第一个问题是我使用了一个非常古老的 ~2011 时代的虚拟机管理程序/内核构建（这正是我所有旧研究的基础），它正在对设置内存加密的虚拟机管理程序功能中的加密 VA 范围进行 TLB 刷新。在后来的虚拟机管理程序构建中，TLB 刷新被删除，因为该虚拟机管理程序功能的内核包装函数已经对 VA 范围执行了 TLB 刷新。但是，我直接调用虚拟机管理程序系统调用（跳过执行 TLB 刷新的内核包装器代码），并且由于 TLB 是延迟加载的，因此白化位将变得过时，并且从内存中读取的结果密文无效。较旧的虚拟机管理程序（左）与缺少 TLB 刷新的较新的虚拟机管理程序（右）在 17559（最新）版本虚拟机管理程序上测试漏洞时，查找表导致了问题，我决定稍后修复它并继续前进，而不是进行调查。当我完成漏洞利用时，我已经被 CPU 缓存问题的隧道视野所蒙蔽，以至于我说服自己查找表不起作用。我可能应该做的（除了在查找表问题出现时进行调查之外）是将这个项目搁置几周，然后以清晰的心态回来。哦，好吧，吸取教训......进入哈希表的实现细节，我们使用我们期望在内存中看到的密文的前 N ​​位作为两个数组的索引。第一个数组包含 oracle 密文的前 64 位，用于验证哈希表中是否存在冲突。这些