随着文章接近尾声,我还没有详细说明这个系统是如何被_荒谬地_保护的。 这台游戏机有着令人难以置信的漫长和多元的历史,涉及有趣的发现、意想不到的漏洞利用方法以及激烈的报复形式。 最重要的是,这段传奇导致了大量第三方文档的诞生,详细介绍了游戏机硬件的构造和软件的奇特之处。 因此,可以说,如果没有许多黑客团体投入无数小时进行研究并将他们的发现记录下来,这篇文章的一半内容都不可能存在——这项任务并不一定是为了促进盗版。
主要目标
首先,我要介绍两个主要的目标。 首先,我要介绍两个主要的目标。一旦Xbox 360到达商店,微软发现自己要防守两个大战线:
- 管理程序,它控制着CPU并强制执行签名可执行文件,如果想要实现自制软件(Homebrew)或者启动另一个操作系统(例如 Linux)的话,这两个方面都必须被攻克。
- 由此延伸,这也影响用户数据(即存储在硬盘和/或内存单元上的个人资料),但它们实现了额外的安全层。 这些在这里没有提到,以便我们可以专注于主要目标。
- DVD光驱,它执行复制保护系统并防止刻录的光盘被作为游戏执行。 DVD价格低廉,那个时代的大多数PC都配备了DVD RW驱动器,因此破解看起来非常有吸引力。 然而,这只会导致盗版,而不会促进自制软件(因为代码仍然是签名的)。 也就是说,除非有人发现了一个依赖于DVD光驱的漏洞,一旦"触发",就能执行自制软件......我们拭目以待!
- 有趣的是,管理程序和操作系统的其余部分对复制保护的状态没有意识,这部分任务被委派给了光盘驱动器,它在接受插入的光盘作为有效的Xbox 360游戏方面拥有决定权。
管理程序战线
我们现在将了解管理程序是如何被保护的,以及它如何保护系统的其余部分。
一个隐藏的加密系统
还记得Xenon中的L2子系统有多复杂吗? 嗯,还有一件事需要解释,那就是在其中包含了一个隐藏的加密块。 我之所以称它为"隐藏",是因为微软和IBM都没有对其进行过任何文档记录。 我是通过一个由Free60小组(由Michael Steil和Felix Domke领导,前者还做过'The ultimate Game Boy talk'!)名为"Xbox 360安全系统及其弱点"的极具洞察力的演讲 以及Mathieu Renard的"安全攻击与防御策略"了解到它的,我在这里描述的大部分信息都依赖于这两次演讲。

Xenon内部安全组件概览。 它们被策略性地放置,使得PPE不需要知道它们的存在,也不需要进行任何手动操作。
接下来,加密子系统被划分为执行独特功能的独立区域:
随机数单元
随机数生成器单元(或简称"rand")产生不暴露可预测模式的随机数集,至少它试图这样做。 这对于向加密例程提供额外的参数非常有用,使得它们难以被追踪,从而防止逆向工程或复制。
你可能会问"为什么不能通过软件来完成这件事?"好吧,在传统计算世界中,没有所谓的"纯随机性"。 计算机只能使用可能被追踪的参数生成伪随机数。 因此,拥有一个专用的单元来执行这项任务可以进一步混淆其逆向工程,并保护CPU免受可能的窥探(因为这块单元隐藏在CPU内部,而不是散布在主板上)。
我猜最理想的解决方案可能是将CPU连接到量子计算机,但我们的科技还没有到达那一步! (尽管有些接近了)
存储扩展
此外,这个子系统还提供了两个额外的内存块。
首先,有32KB的ROM,它与Cell中的安全ROM相同。 它用于存储CPU可以读取的未加密数据,而不用担心被第三方暴露或追踪。 正如你之前所看到的,这是第一阶段引导所在的位置。
其次,提供了64KB的SRAM作为快速通用内存,CPU可以使用它来执行合理的操作(很可能是与加密相关的),而不用担心被_监视_。
电子熔丝
说到存储,Xenon内部还有一种特殊的介质叫做"电子熔丝"(eFuse)。 电子熔丝是微小的开关,CPU可以将其读取为0或1,就像任何晶体管一样。 eFuses的独特之处在于,一旦它们被切换到1,它们的状态就是不可更改的(因为写入1会烧断电子熔丝,就像传统的保险丝一样)。 这使微软能够编码永久计数器或存储加密密钥,一旦游戏机离开工厂,这些计数器或密钥就无法更改。 好吧,只有0值可能会被更改,但每个游戏机的序列是不同的。 此外,一旦密钥被第三方更改,游戏机就无法再解密其数据了!
总共有768个单独的电子熔丝被安装,每个都被CPU视为一个"位",其中0表示"激活",1表示"烧断"。 这个块被分组为12个"熔丝组",每个组包含64个电子熔丝。
当读取或写入电子熔丝时,它们是以8个电子熔丝为一组进行的(类似于8位/十六进制值),而不是单独进行的。 尽管如此,有时信息只以二进制值(0和1)的形式编码,而不是十六进制格式(从0x0到0xF)。 在这些情况下,整个8位字会一次性烧断,并被视为一个单一的二进制值。
加解密单元
在L2缓存旁边,微软和IBM增加了一些硬连线逻辑,以便在完全不依赖CPU的情况下执行AES-128加密和散列函数。 利用之前提到的64 KB SRAM,L2块在数据进入或离开Xenon时自动进行解密或加密。
L2块还可以在内存页被写入主RAM的过程中对其进行散列,将散列值存储在SRAM上,然后在从RAM中检索页面时将其与新计算的散列值进行比较。 如果检查失败,系统将锁定。
所有这些操作都是为了防止对内存总线进行任何有意义的数据分析(通过加密)并确保RAM没有被篡改(通过散列)。
为了防止重放攻击(这种攻击依赖于复制旧但有效的数据块来伪造真实性),随机数单元每次游戏机启动时都会生成一个不可预测的值。 然后,L2块将其与加密逻辑混合。
安全系统实现
让我们看看微软是如何构思这些组件的用途的。
信任链
您之前阅读的复杂启动过程是为了实现一个精密的信任链而设计的。 这确保了一旦管理程序准备好执行用户空间代码,后者总是被加密并由微软以外的人签名。
为了有效地混淆启动过程,该系统采用了多种类型的密码。 例如,第二个引导加载程序(2BL/CB)使用RC4(一种快速算法)进行解密,其解密密钥在运行时使用HMAC-SHA构建。 然后,使用SHA1和ROT对解密后的代码进行哈希处理。 最后,为了检查2BL是否被篡改,计算出的哈希值会与使用微软私钥(使用RSA)预先签名的存储哈希值进行比较。
为了提高保护级别,每台游戏机都嵌入了一个独特的CPU密钥,在游戏机离开工厂前刚刚印在电子熔丝上。 在运行时,CPU密钥与其他参数混合,以生成引导加载程序密钥的一部分。 总的来说,这意味着破解一个CPU密钥不会影响其他游戏机。
一旦管理程序加载到主内存中,信任链就位,没有管理程序的许可,就不会执行任何代码,尤其是后者具有W^X能力。
不可逆且唯一的数字
为了进一步保护信任链并防止外部篡改,启动阶段还会查询768个电子熔丝集群以获取以下信息:
- 前面提到的CPU密钥,用于加密存储在游戏机中的其他密钥。
- 一个标志,表明游戏机是零售模型还是开发套件,这会影响主板上的许多调试引脚的可用性(即 JTAG口).
- 两个更新计数器(一个用于2BL/CB的更新,另一个用于管理程序和内核的更新)。 每当微软发布一个"系统更新"并且用户安装它时,更新程序会熔断一个电子熔丝。 在启动过程中,CPU将电子熔丝的值与应用的补丁进行比较,如果值不匹配,您会得到著名的"死亡红灯"。 这阻止了用户降级到系统的漏洞可用版本。
- 为更新计数器预留了5个熔丝组。 计数器以二进制形式编码,因此每次更新后都会熔断八个熔丝,这意味着Xbox 360在其生命周期内可以承受多达80次更新。 相反,微软在
2.0.4548.0更新发布后才开始熔断电子熔丝。 - 此外,还有16个电子熔丝可用于CB的更新。
- 为更新计数器预留了5个熔丝组。 计数器以二进制形式编码,因此每次更新后都会熔断八个熔丝,这意味着Xbox 360在其生命周期内可以承受多达80次更新。 相反,微软在
安全通信
Xenon拥有一个64位的地址总线,然而,只有512MB的RAM(以及一部分I/O)需要被寻址,这意味着使用64位寻址可能会显得有些浪费。 因此,一半的地址空间被用于一个更实用的目的:加密标志。
本质上,程序只使用32位的虚拟地址。 然后,内存管理单元(MMU)使用一个页表将虚拟地址转换为64位地址,其中低32位编码虚拟地址,上半部分存储标志,这些标志表示所选内存地址是否(或需要)被加密和/或散列。
这些标志由L2缓存块自动读取,然后根据需要执行加密/散列操作。
由于只有64KB的SRAM用于存储页表和哈希值,所以所有主RAM都可以被加密,但只有管理程序被散列。 这意味着CPU与RAM之间的通信始终受到保护,但L2缓存块只能验证虚拟机监控器的完整性。 这似乎是一个不错的折中方案,对吧?......我们来看看结果如何!
管理程序的职责
一旦管理程序以1级权限完全运行,它将深入Xenon的内部SRAM以提供以下功能:
- 充当内存管理单元(MMU),通过处理其私有的虚拟内存页表,其中它跟踪每个程序的内存边界以及它们是否可执行。 这可以保护硬件不受产生缓冲区溢出的充满漏洞的软件的影响。
- 与L2块合作,确保所有可执行代码在存储到RAM时都是加密的。
为了执行任何用户空间应用程序,内核将(未加密的)代码复制到内存中,然后管理程序检查它是否使用微软的私钥RSA签名。 如果签名有效,管理程序继续在内存中复制可执行代码,在此过程中L2块会自动对其进行加密。 最后,管理程序将相应的内存页标记为"可执行",其余的就成为历史。
保护DVD光驱
由于选择了高度流行且价格合理的游戏分发介质,关于盗版的担忧在微软总部引起了共鸣。 反盗版系统成为了微软及其供应商的联合项目,其效果因DVD光驱的制造商而异。
第一方安全措施
在微软的控制下,DVD光驱使用唯一的DVD密钥与系统进行认证,该密钥必须与虚拟化管理器处理的内部密钥相匹配。 DVD密钥来源于CPU密钥。 如果检查失败,光驱仍然可以工作,但将无法启动Xbox 360的游戏。
此外,为了防止被传统DVD光驱读取并排除精确复制,游戏使用了新的Xbox游戏光盘2 (XGD2) 数据格式进行制作,该格式刻录了一些反盗版技巧:
- 一个误导性的目录表,欺骗传统DVD光驱加载一个静态视频,这个视频会要求用户将光盘插入Xbox 360游戏机。
- 在文件系统内,存储了一个数据库,其中包含多个称为挑战或"安全扇区"的检查,驱动程序执行这些检查以确认当前光盘是有效的。 当提到DVD光驱时,这些挑战就只是列举在制作过程中故意制作的故障扇区,驱动器需要找到这些扇区。 由于传统刻录机没有考虑到这些扇区,因此复制品永远不会通过验证过程。
- 光盘的外部区域暴露了一个冲切区,尽管它似乎并不包含用于复制保护的有意义数据。
最后,还要加上这样一个事实,即管理程序只启动用微软私钥签名的可执行文件。
第二方安全措施
实际上,负责实施微软复制保护协议的实体不是微软,而是DVD光驱的制造商。 在大多数情况下,制造商只是改变了他们现成硬件的固件,以遵守微软的要求。 无论如何,管理程序在检测哪个光盘是正品,哪个不是时,会盲目地信任光驱。
由于复制保护子系统随后被委托给第三方,因此它出现了多个问题。 例如,光驱仍然使用标准的ATA命令进行通信,因此它们必须找到方法来混淆敏感数据交换。 此外,光驱必须准备好覆盖其固件,以防微软修订新的复制保护机制。 所有这些,同时防止未经授权的各方访问此功能。
虽然探讨每个制造商的每个安全措施超出了本文的范围,但重要的是要指出,在最终出现的猫捉老鼠游戏中,微软对这些保护措施以及随后的补丁控制力有限,这一明显的漏洞使得公司早期遭遇了盗版分发的浪潮。
后备技术
现在很明显,反盗版措施只能保护一段时间。 Xbox 360被设计成一个大部分可覆盖的操作系统。 只要使用了正确的加密密钥(微软是唯一的拥有者),除了启动ROM之外的任何东西都可以更新。
因此,在整个游戏机的生命周期中,公司发布了软件更新,修补了CB(第二阶段引导加载程序)、内核、管理程序和DVD光驱的固件。 你很快就会看到这些区域的每一个背后的逻辑。
此外,微软通过只允许运行最新系统的游戏机访问Xbox Live,来推广(或者实际上是强制)这些更新。 这阻止了用户保留旧版本,结合了防止降级的电子熔丝,减少了有漏洞的游戏机的可用性,哪怕是为了研究目的。
最后,在修改过的游戏机访问Xbox Live服务的情况下,微软在幕后实施了多种保护措施,以将破解的游戏机和/或作弊者排除在其网络之外,包括使用"电话回家"程序来帮助微软检测"特殊"游戏机;随后通过游戏机黑名单实施"永久封禁"。
击败
如果你多年来一直关注Xbox 360的场景,你现在可能知道这款游戏机享受了其时代最具创造性的漏洞利用之一。 最初开始的简单任意执行技术(尽管它们并不特别_简单_),很快就有了为了这些目的而销售的商业硬件。
我将尝试现在给出一个适当的事件摘要,但如果你在最后感到还想要更多,知名黑客"15432"撰写了一个非常信息丰富的三部分文章,深入探讨了直到2020年的每一个突破 。
DVD光驱传奇
历史似乎告诉我们,每当一款游戏机包含了像CD或DVD这样的广泛采用的介质时,那个区域被破解只是时间问题。 尤其是由于盗版比自制软件更容易传播。
在2006年5月(PlayStation 3上市之前),用户"commodore4eva"发布了Xtreme Firmware,这是一款用于早期捆绑了东芝-三星驱动器的Xbox 360的替代DVD光驱固件。 新固件指示驱动器寻找硬编码的安全区块,而盗版副本则会重新定位这些区块。
固件是通过使用ATA命令来烧录的,但它需要一个带有备用SATA插槽的计算机和特殊的烧录软件。 因此,用户需要打开游戏机并将SATA数据线连接到他们的计算机上,在游戏机为光驱供电时运行烧录器,然后重新组装一切。 烧录操作源于光驱固件中发现的隐藏的"维护模式",这个模式随后被逆向工程并重新启用。 如果过程成功完成,Xbox 360现在就可以像读取任何正版游戏一样读取盗版游戏。

在YouTube上找到的DVD光驱烧录教程示例。在这里,Xbox 360的光驱通过SATA连接到电脑,同时游戏机仍然提供电源(因为电源连接器是专有的)。
这就是DVD光驱被破解的大致过程。 随着时间的推移,技术不断进化,但基本思想保持不变(烧录自定义固件)。 后续的光驱增加了安全性以封堵后门,微软通过将DVD光驱固件捆绑在其软件更新中来帮助撤销用户所做的任何未经授权的工作。 在后来的年份里,光驱的级别提升到了用户必须钻透驱动器的系统芯片才能启用刷新的程度。
微软总部设计了一种名为XGD3的新光盘格式,以改善挑战集合。 此外,XGD3通过扩展写入限制超过标准区域(在这个过程中阻碍了复制)来增加了数据容量。
管理程序传奇
管理程序的基本原理一开始可能看起来无懈可击,然而,它下面隐藏着一个技术上的妥协:外部组件(南桥、GPU等)也需要访问主内存。 然而,它们不理解管理程序的加密机制(因为这是CPU和主内存之间的事情)。 那么,I/O如何使用内存呢? 简单,通过直接访问(DMA)和非加密数据。 这本身并不是一个安全漏洞,因为管理程序仍然对其可执行的CPU页面执行安全措施。

XeLL-Reloaded,一个Linux和自制软件的启动器。 将这个程序加载到Xbox 360将成为任何修改者的首要目标。
尽管如此,早期的入侵就是专注于这一点。 换句话说,我们能否将未签名的代码注入主内存,然后诱使管理程序执行它? 嗯,在2007年2月,一位匿名黑客发布了一个依赖于2005年游戏《金刚》的权限提升漏洞利用。 在报告中,概述了一个聪明的事件链,以在管理程序级别(意味着完全硬件访问)获得任意代码执行。 这个过程并不容易解释,但我会尽力。让我们看看...... 让我们来看看......
比较缺陷
为了组织所有可用的例程,管理程序在主内存中存储了一个系统调用表,以及一个遍历该表的句柄。
当一个程序调用系统调用时,句柄首先确保请求的系统调用号码是有效的。 这是通过检查其值是否小于0x61(意味着最多有96个系统调用可用)来完成的。 最后,句柄将系统调用号码转换为内存中的虚拟地址(在那里找到例程),然后CPU继续在那里执行。
另一个需要记住的概念是,管理程序以加密形式存储在RAM中,因此,所有系统调用例程也都是加密的。 因此,指向例程的虚拟地址具有设置的加密标志。 因此,L2块在将数据交给CPU之前,无缝地解密从RAM中获取的数据。
考虑到这一点,黑客们查看了系统调用句柄的汇编代码,并发现了一个重大缺陷。 本质上,系统调用号码是通过寄存器传递的。 Xenon中的寄存器是64位长的,但有效性检查是使用cmplwi指令实现的(用于无符号的32位值)。 这意味着如果一个程序(之前由管理程序授权)请求一个系统调用,其值大于0xFFFFFFFF,比如0x20000000.0000002A,管理程序将只验证0x0000002A,这将通过检查。
那么,我要表达的是什么意思呢? 嗯,如果你记得,64位虚拟地址上的高32位用作标志,指示L2块加密/解密或散列内存值,如果标志都是零,L2将解释数据为未加密并直接传递。 也就是说,如果_通过某种外部手段_在RAM中插入了一块未加密的代码,可能会有一种方法通过有缺陷的系统调用句柄来执行它......
新的系统调用
之前的发现看起来很有希望,但仍然有许多未解决的问题。 例如,我们仍然需要一种方法来构建一个不会被L2的解密块破坏的任意系统调用。
长话短说,发现了一个关键点:当系统调用句柄将系统调用号码转换为虚拟地址时,如果结果虚拟地址的最高位不是0,那么转换器就不会添加加密标志。 因此,L2块不会破坏获取的系统调用函数,无论它是否加密。
这是缺失的拼图,它将允许黑客执行一个精心构建且未加密的系统调用号码,从而导致任意代码执行。 但这还没有结束,因为我们还需要:
- 一个入口点,允许将任意系统调用例程注入主内存。
- 另一个入口点,用于请求构建的系统调用号码,以便执行任意例程。
这就是我们现在将要讨论的内容。
《金刚》漏洞
接下来是著名的《金刚》游戏。 像任何其他典型游戏一样,它的光盘存储了顶点和像素着色器文件,这些文件在游戏过程中某个时刻被加载。 然而,出于某种未知的原因,这些文件以完全明文(未加密)和未受保护的形式存在。
如果你将这个事实与DVD光驱可以被修改以加载复制品的事实结合起来,你现在可以使其加载带有修改后着色器的《金刚》游戏。 这有什么价值呢? 嗯,你还记得我在"图形"部分提到的"内存导出"功能吗? 着色器可以通过DMA直接写入主内存! 哦吼!
我猜你已经知道我要说什么了,如果你制作了一个带有自定义着色器的《金刚》特殊副本,并将其插入一个烧录过光驱的Xbox 360中,你可以开始用任意值填充主内存。 因此,你可以将自定义系统调用注入主内存。
这解决了填充主内存的第一个任务,但我们仍然需要一种方法来调用自定义系统调用......
提权
回忆一下,Xbox 360的内核提供了一个调度器来处理多线程。 这个机制负责将虚拟线程分派到CPU核心,并将空闲线程保存到内存中以备后用。 嗯,出于另一个未解释的原因,调度器将线程状态以未加密的数据形式存储在RAM中!
结合所有已解释的内容,现在可以制作一个着色器,该着色器会篡改内存中的空闲线程,一旦该线程被恢复,它将继续以自定义参数执行。 这个过程会持续进行,直到所有的参数最终都处于黑客的控制之下,这样执行就可以被重定向到系统调用处理程序,并结合使用计算出的参数,最终跳转到精心制作(且未加密)的系统调用。
基本上,这就是管理程序如何被任意代码劫持的方式。 与此过程捆绑在一起的常见有效载荷包括一个Linux启动器,因为使用具有完全硬件权限的Linux允许用户从他们的游戏机中提取敏感信息,如CPU密钥(这在未来可能会有用,你很快就会看到)。
保护金刚
金刚漏洞利用对于自制软件场景来说是一大步。 我不确定你有没有注意到,但在这个过程中根本不需要任何加密密钥(所以,原本强大的安全系统又如何呢......)。
尽管如此,微软已经注意到了这个漏洞,并在2007年1月(报告发布前一个月)进行了修复。 尽管如此,黑客们继续寻找类似漏洞,以用于更新后的游戏机。 此外,黑客现在可以获得一个过时的游戏机,并利用金刚漏洞来扩展他们的研究。
因此,在金刚事件发生的同年(2007年),又有新的发现:
隐藏维护模式
一旦CB,也就是第二阶段引导加载程序被逆向工程,一个新的后门就要被发现了。 CB执行的一个检查是将存储在CB头部的一个字符串与NAND中的校验和进行比较。 嗯,如果那个字符串(称为"配对信息")全是零,那么这个检查就会被跳过,启动过程会继续,同时忽略CPU密钥。 唯一的缺点是没有应用更新包,而内核最终启动的是一个名为MfgBootLauncher的替代应用程序(推测在制造过程中使用),而不是仪表板。
最初,这个发现并没有引起人们的注意,因为它似乎并没有导致任何有趣的发展。 然而,这种情况在微软注意到MfgBootLauncher的提及并随后发布了一个新的系统更新后发生了变化,这个更新最终吸引了_太多的注意力_,甚至到了这种特殊的"制造模式"成为家庭自制软件的一个机会!
在我们继续这个故事之前,还需要解释一个黑客攻击...
时序攻击

由于制造原因,主板暴露了许多执行(未记录的)功能的针脚,其中一些功能被逆向工程,以利于黑客操作。
在2007年8月,XboxHacker用户"Arnezami"发布了用于将任何游戏机降级到易受King Kong攻击的固件版本的时序攻击方法。
这次攻击(双关语)要求用户提取NAND的内容(也就是制作一个转储),并使用一个自动化脚本,将转储中的游戏机唯一信息与系统2.0.1888的通用镜像(操作系统的第一个修订版)合并。
为了绕过第二阶段引导加载程序检查(它会将电子熔丝中的更新计数器与已安装的更新进行比较),定制的固件需要与eFuses计数器的值相匹配。 然而,调整这个计数器并不简单,因为NAND中的计数器是使用CPU密钥(带有HMAC)签名的,如果Xbox 360运行的是打了补丁的固件,那么CPU密钥是无法提取的......
幸运的是,出于制造目的,主板暴露了串行外围接口(SPI)引脚,用于写入和读取NAND;以及输出不同值代表启动过程当前状态的POST引脚。 恰好在这个过程中,电子熔丝验证(使用C语言的memcmp()实现)时,比较是按字节进行的。 最重要的是,在每次比较过程中,成功的匹配总是需要0.22毫秒来完成,而失败的匹配则需要0.21毫秒。
结合所有这些信息,可以自动化一个试错猜测器,直到整个签名被暴力破解。 这就是时序攻击的实质。 一旦提取了秘密代码,它可以应用于修改后的2.0.1888镜像,一旦这个镜像被刷入游戏机的NAND,游戏机就会认为它是有效的。 从那时起,用户可以更新到一个易受King Kong攻击的版本。
最终,微软在2008年初通过一个新的软件更新修复了这个漏洞,该更新略微改变了CB中的memcmp()函数。
对CB的更多研究

一旦你成功启动了Linux(在这种情况下是Gentoo,得益于Free60小组的努力),你就可以窥视Xbox内存中的特权区域,比如电子熔丝(那里存有CPU密钥)。 截图由提供。
有一天,微软发布了一个新的CB更新(版本1920),旨在解决当时无害的制造模式的发现。
为了混淆视听,微软决定将CPU密钥作为一个参数添加到用于加密/解密4BL(负责加载和更新内核和管理程序的阶段)的过程中,使得逆向工程变得不可能。 然而,得益于时序攻击,CPU密钥最终可以被提取。 因此,黑客能够解密4BL并继续在其中寻找新的漏洞。 幸运的是,他们在"制造模式"中发现了一个重大变化:如果更新数据包的配对信息也被清零,那么更新程序将应用它们。
所有这些都导致了一个非常重要的里程碑:现在可以在不知道CPU密钥的情况下启动任意版本的系统。 然而,这一点直到很久以后才被利用,这就把我们带到了下一个故事......
还以金刚自由
随着自制软件开发不断进步,《金刚》破解法变得过于繁琐,人们的注意力转向寻找新的技术来自动化利用管理程序,结果至少可以说是惊人的。
一个可疑的更新
在《金刚》漏洞公布两年后,即2009年8月,微软发布了一个意外的软件更新2.0.8498,该更新再次覆盖了CB(第二阶段引导加载程序)并增加了相应的电子熔丝计数器。 不仅这次更新出人意料地覆盖了系统的关键部分(有可能导致系统不可修复的损坏),也引起了众多黑客的关注,他们想要弄清楚微软试图修复的是什么。
Free60小组在持续努力将Linux移植到Xbox 360的过程中,建议用户保持当前系统不变,不要屈服于这次更新。 在幕后,他们已经知道了这个隐含的漏洞,并正在准备发布一项新技术,供公众利用。
JTAG/SMC破解
在2009年11月,Free60小组发布了一份技术报告,后来被称为SMC/JTAG破解。 这使得Xbox黑客社区意识到了两个重大发现。
第一个揭露了零配对漏洞,允许启动任何系统版本,这就是我在几段前解释的内容。 第二个描述了如何自动触发管理程序漏洞并在运行易受《金刚》攻击系统版本的游戏机中注入有效载荷,这意味着不再需要保留修改后的《金刚》副本和烧录过的光驱。
因为我已经解释了第一个漏洞,让我来谈谈第二个,因为它相当不可思议。 还记得系统管理控制器(SMC)吗? 那个位于南桥内部运行的小型英特尔8051,负责处理I/O任务? 好吧,在启动过程中,SMC从NAND加载其固件,这就是Free60利用来接管SMC的地方。
由于主板暴露了来自SMC的GPIO引脚和来自CPU和GPU的JTAG引脚,黑客们发现他们可以执行以下技术:
- 使用NAND读取器制作NAND内容的镜像。
- 使用零配对后门,修改镜像以仅应用导向含《金刚》漏洞管理程序的更新。
- 修改NAND镜像中的SMC固件区域,以便在启动时,SMC命令GPU通过DMA传输《金刚》光盘上使用的同一块代码。
- 使用硬件NAND写入器将修改后的NAND镜像烧录到游戏机。
- 在SMC的GPIO和GPU的JTAG之间焊接带有开关二极管的两根线。
- 打开游戏机并等待有效载荷出现。
这样,就获得了一个永久性的自动自制软件启动器! (只要你没有更新到2.0.8498)。
自制软件的曙光
尽管上述发现被微软的更新所超越,但自制软件社区依然保持着势头,新的应用程序不断涌现,成为任何改装爱好者的"必备品":
- XeLL(即Xenon Linux Loader),后来演变为XeLL-Reloaded,是使用管理程序漏洞的实际有效载荷。 它作为一个第二阶段引导加载器,其功能之丰富类似于侦察版维氏瑞士军刀。 XeLL能够启动Linux或者使用libxenon编写的ELF可执行文件,libxenon是一个用于自制软件开发设计的替代SDK。 此外,在加载时,其文本界面会自动显示电子熔丝数据和其他底层信息在屏幕上,以便用户如果需要可以记录下来。 如果这还不够,它自托管的HTTP站点提供了额外的控制功能,可以即时转储电子熔丝和NAND的内容。
- freeBOOT是官方操作系统的修改版,它禁用了管理程序的签名验证并移除了微软设定的硬编码限制(例如防止使用第三方硬盘的安全区域检查),以及其他一些功能。 freeBOOT通过XeLL加载,然后像任何其他未修改的游戏机一样启动官方系统,不同之处在于现在可以从仪表板启动非签名的可执行文件。 在撰写本文时,应用Freeboot仍然是大多数自制用户的主要目标。
- 要制作一个"freeBOOTed"镜像(最终烧录到NAND中),需要游戏机的CPU密钥。 这意味着游戏机需要首先加载XeLL(使用之前的漏洞),以便可以提取密钥。 然后,可以生成带有Freeboot补丁的新NAND镜像。
- FreeStyle Dashboard和Aurora是两个替代原始仪表板的程序,它们提供了执行自制软件、加载游戏转储和调整底层设置(例如风扇速度)的增强控制。 虽然它们的目的是取代官方仪表板,但它们仍然像其他XEX可执行文件一样被加载。
- XeX Loader和XeX Menu是可以从官方仪表板运行的自制启动器。
- Dashlaunch是一个为官方系统提供一系列补丁的程序,不同之处在于它们在运行时加载(避免了烧录NAND的需要)。 Dashlaunch的功能之一包括在仪表板启动后自动加载一个可执行文件,这通常用于快速加载对自制软件友好的替代仪表板FreeStyle Dashboard或Aurora。

FreeStyleDash在我的改装游戏机上运行,提供了许多官方仪表板上找不到的控制和指示器。 对于那些资深的Xbox 360用户来说,你会注意到它的界面与标志性的NXE时代非常相似!
为了简化使用XeLL和/或Freeboot构建NAND镜像的过程,社区开发了许多Windows程序,如XeBuild、J-Runner和AutoGG,以尽可能自动化这个过程。
超越微软的优势
尽管之前的事件看起来可能令人兴奋,但恐怕我要说的是,SMC/JTAG破解的发布仅仅是在微软修补了漏洞之后! 如果你好奇的话,软件更新拉黑了带《金刚》漏洞的管理程序,这样它们就无法在CB阶段被加载。 此外,新的CB还触发了一个新的电子熔丝计数器,因此反击变得不可能......除非发布了一个新的难以想象的黑客技术......
故障注入器
在最后一次重大突破后长达两年的闲置期后,2011年8月,用户"GliGli"提交了一份技术报告,概述了发现的复位故障破解(Reset Glitch Hack,RGH)。 这种新技术允许任何类型的Xbox 360(无论安装了什么更新)运行任意版本的管理程序,就像SMC/JTAG破解一样,不同之处在于现在需要焊接一个外部芯片。
简而言之,RGH利用了CPU电路中的一个基本缺陷:如果CPU在其RESET线上接收到一个短脉冲(长度为4到60纳秒),CPU将不会复位,而是继续以损坏的状态执行。 换句话说,如果故障发生时CPU正在执行一个mr(移动寄存器)指令,目标值将变为0,而不是源寄存器的内容。 如果CPU在执行某些关键操作(如验证引导加载程序)时发生这种情况,这可以对黑客有利。 此外,用户"cjak"发现,通过锁存主板上的一个特殊线路,称为CPU_PLL_BYPASS,可以将CPU的速度降低到大约25 MHz,从而为故障创造了空间。
借此,GliGli和一群黑客拿了一个通用但快速的CPLD板(类似于FPGA),将其焊接到主板上的许多有用点上,并编程它执行以下操作:
- 跟踪Xbox的POST信号,以知道何时何地锁存总线。
- 在CB即将验证CD的哈希值时减慢CPU速度。
- 当CB在
memcmp()函数(与哈希值验证相关)中间时锁存RESET线。 - 恢复CPU的原始速度,希望
memcmp()奇迹般地成功。 - 如果过程成功,将执行自定义有效载荷。
这样,一个编程用于使Xbox 360的CPU出现故障的板被称为故障注入器。
由于这个过程依赖于正确的时序(来自POST输入和硬编码计时器的组合)和非常精确的信号,成功不再是确定的。 尽管为了自动化这个过程,SMC的固件被修改为在启动阶段失败时不断重启游戏机。
有了这个,自制软件社区获得了一个无法修复的漏洞来加载自制软件。
微软的反击

虽然新的"Trinity"主板带来了许多期待已久的改进,例如将CPU和GPU统一到一个封装中以减少热量, 但它也复杂化了黑客的努力。
尽管RGH破解在早期阶段就攻击了CPU的基本构造(从而使它不可能通过软件更新来解决),微软从未表现出任何弱点,并发布了CB(第二阶段引导加载程序)的进一步更新和新主板版本,试图扰乱故障注入过程。
例如,2010年发布的新款薄型机(讽刺的是,这是在RGH发布前一年),代号Trinity,将CPU_PLL_BYPASS点移动到了黑客无法找到(当时)的位置。 与此同时,RGH团队发现他们可以通过I²C调整视频编码芯片的PLL信号,这将影响CPU的速度。 不幸的是,视频编码器只能将其减速到一定程度(大约3倍),因此精度和成功率有所降低。 尽管如此,这仍然是一个巨大的成就。
此外,薄型机将CB阶段分为了CB_A和CB_B,其中CB_B进一步使用RC4算法加密,并依赖于CPU密钥。 为了加剧绝望,零配对后门被完全移除。 最终,所有这些更改将很快扩展到旧型号,因为微软发布了更多的软件更新。 尽管如此,黑客们从未放弃,并发现他们可以在加密形式下修改CB_B。 得益于RC4中的一个数学缺陷,加密信息可以通过应用与未加密的差异补丁进行XOR操作来更改,从而允许在不知道CPU密钥的情况下禁用CB_B上的加密例程!
销售RGH

"X360 Squirt 1.2"是针对Trinity主板的设置。 这是市场上众多可用于破解Xbox 360的商业故障注入器之一。
在接下来的三年里,RGH破解的韧性成功地抵抗了微软所有试图减轻其影响的工作。 与此同时,剩下的就是一场经典的猫捉老鼠游戏,微软试图使这项任务变得不可行。 因此,面对不断到来的软件更新浪潮,许多论坛上散布了RGH的新变体。 这些变体共享RGH破解的基本原理,但每个变体都使用不同的程序作为故障注入器,并修改SMC镜像以提高成功率。
最初,作为故障注入器的程序,RGH破解分化为两个不同的变体:依赖于PLL线的RGH1,以及依赖于视频编码器的RGH2。 后者可以被任何主板版本使用,并不断修复以应对微软试图破坏它的尝试;而RGH1虽然无法离开旧硬件(Trinity)和软件(2.0.14699更新),但它享有更高的可靠性。
无论如何,RGH的成功引发了一波商业故障注入器和安装套件的浪潮。 这些套件承诺,在更高的价格点上,将提供更简单的安装过程和更高的成功率。 我认为Team Xecuter是充分利用RGH狂热浪潮的最佳例子之一。 该公司销售定制的Xilinx的"CoolRunner"开发板版本,以与其他可编程故障注入器市场竞争。 最值得注意的是,Team Xecuter的板子要么是预编程的,要么支持他们新的RGH变体:
- 由于微软试图通过
2.0.15572更新修复XOR漏洞,2012年12月,Team Xecuter推出了一块名为DGX(双重故障破解)的新板子,专注于提取CPU密钥,然后像其他任何RGH方法一样继续操作。 这样,微软的更新通过烧录旧的未加密引导加载程序,然后使用DGX让引导过程发生两次故障来绕过修改后的CB_B的比较和验证,从而得到了解决。- 后来发现,Team Xecuter的方法更像是暴力攻击。 一个更可靠的过程只需要在CB_A准备从NAND复制数据时进行故障处理。
- 非薄型机的R-JTAG故障注入器。 这种方法于2013年5月发布,是一种针对更新版主机的全新方法,试图接近RGH1的旧成功率。 基本上,R-JTAG故障处理CPU以加载易受JTAG/SMC漏洞攻击的旧版管理程序,然后像后者一样进行操作。
- 随着他们新的旗舰产品'CR4 XL'故障注入器的推出,RGH2+被提出作为一种新模式,以改进经典的RGH2。 这次,CPU减速过程被委托给了SMC。
由于某种原因,Team Xecuter没有提供任何文档来在其他设备上复制这些新技术。 因此,用户们亲自上手,以提供更便宜和/或更好的替代方案:
- 首先,"DrSchottky"成功创建了一个名为R-JTOP的R-JTAG开源实现,供任何故障注入器使用。
- 其次,开发者"blaKCat"在他的刷新工具中捆绑了双重故障例程,因此任何板子都可以编程,而无需依赖昂贵的DGX。
- 第三,2014年12月,黑客"15432"发布了"Speedy RGH"(S-RGH),作为CR4专有RGH模式的替代方案。 S-RGH通过减少故障注入过程中的减速周期,甚至实现了更快的速度。
- 后来,2015年4月,15432再次发布了一种名为RGH 1.2的新方法,结合了RGH2和CPU的PLL线的使用,达到了与RGH1相似的成功率。
- 最后,2021年8月,工程师Josh Davidson成功地将RGH 1.2移植到Slim主机上,通过在新主板上找到缺失的PLL线,从而产生了名为RGH 1.2 V2的新变体。
终局
随着Xbox 360后继产品的临近,微软最后一次发力,推出了一个重新设计的游戏机版本,名为'E',在其中,又有一个名为Winchester的主板修订版。 在零售机型中,Winchester最终禁用了POST和PLL信号,并过滤了CPU RESET线的_外部干扰_。 这使得自RGH黑客技术发现三年后,该技术变得过时。
然而,对于兼容的主板(仍然非常普遍), 除了提到的RGH变体之外,还有一项黄金般的发现等待揭开。 快进到2021年11月,15432再次让社区感到惊讶,发布了RGH 3.0,这是一个统治一切的通用RGH变体。 在幕后,这项新技术是RGH 1.2 V2的进化版,不再需要故障注入器。 这是通过将故障阶段实现到SMC中来完成的,现在只需要在主板上焊接两根线(特别是新定位的CPU_DBG1_POST1和CPU_PLL_BYPASS)来执行黑客攻击。
