Xbox 360虚拟机监控器漏洞利用获优化，执行时间缩短至数秒

运行 Bad Update 漏洞利用文件的《摇滚乐队：闪击》。

Hypervisor 竞态条件优化

在发现 RBB 入口点后不久，我收到了来自“Máté”的 pull request，他对漏洞利用中的 hypervisor 竞态条件部分做了一些改进。这些改进包括：用哈希表预计算并存储恶意密文值、更好的缓存刷新原语，以及改进 XKE payload 线程与密文覆写线程之间的线程调度。这些改进组合起来把执行时间缩短到了几秒钟，竞态条件的成功率也高了很多。

在第 2 部分中，我谈到过通过使用 hypervisor API 在预定内存地址创建加密内存分配，并使用两条不同的内存路径来捕获某些选定明文数据对应的密文，从而攻击加密内存。利用这个原语，我既能构造密文数据来获得内核态代码执行，也能构造用于攻击 bootloader 更新 XKE payload 中 LZX 解压代码的密文数据。

内存加密方案中使用的 whitening 值有 12 位，因此对于给定的明文数据，共有 1024 种不同的密文组合。然而，在我最初的 PoC 中，我只为 1024 个可能 whitening 值中的一个生成密文，原因是我这边有两处失误。最初为密文攻击做原型时，我确实尝试过为密文组合使用查找表，但没能让它跑通。

第一个问题是我当时使用的是一份非常古老的、大约 2011 年时代的 hypervisor/内核构建（它只是我所有旧研究的基础）。在这个版本中，负责建立内存加密的 hypervisor 函数会对加密的 VA 范围执行 TLB flush。在后来的 hypervisor 构建中，这个 TLB flush 被移除了，因为这个 hypervisor 函数的内核包装函数已经会对该 VA 范围执行 TLB flush。然而，我是直接调用 hypervisor syscall 的（跳过了执行 TLB flush 的内核包装代码），而由于 TLB 是惰性加载的，whitening 位会变陈旧，从内存读出的密文也就无效了。

旧版 hypervisor（左）与缺少 TLB flush 的新版 hypervisor（右）

在 17559（最新）版 hypervisor 上测试漏洞利用时，查找表引发了问题，而我没有去调查，而是决定以后再修，然后继续推进。等到我把漏洞利用做到尾声时，我已经被追逐 CPU 缓存问题的隧道视野蒙蔽得太深，以至于说服自己查找表根本行不通。我大概应该做的（除了在查找表问题出现时就去调查之外）是把项目搁置几周，带着清醒的头脑再回来。唉，教训啊……

进入哈希表的实现细节：我们用预期会在内存中看到的密文的前 N 位作为索引，访问两个数组。第一个数组包含 oracle 密文的前 64 位，用于在哈希表发生碰撞时进行校验。第二个数组存储我们想要写入内存的恶意密文。