欢迎来到本文的最后一节(并感谢你走到这一步！). 在这里，我们将分析Wii U对黑客的抵御能力如何。 公平地说，没有一款游戏机(在这篇文章系列中) 曾经达到100%的成功率。 然而，游戏机保持 "不可破解"的时间和所需的努力将在某种程度上影响游戏工作室是否会投资于该平台。
说了这么多，让我们继续分析吧!
主要目标
任天堂不得不用各种手段来保证下面三个部件不被破解:
- 光驱具有读取游戏光盘的能力。
- IOSU(在Starbuck上运行)，具有访问大部分I/O和内存的独有能力；并控制Espresso。
- Cafe OS (在Espresso上运行)，这是游戏运行的基础。
实施保护
首先是：光盘驱动器。
...... 嗯，到目前为止，光驱还没有被公开破解。 有报道称，已经开发出名为'WiiKeyU'的驱动器模拟器，该模拟器可以加载光盘镜像，但是没有任何产品进入市场。
考虑到蓝光驱动器在整个Wii U的生命周期中的低采用率，我推测没有足够的热情来破解驱动器 和/或 深入研究其新的保护方法。 对于好奇的人来说，Wii U的主板现在以类似于Xbox 360驱动器的方式与驱动器进行身份验证，并且从那里开始，所有的通信都是加密的。
这让我们剩下两个目标(IOSU和Cafe OS)，而且，这一次，我们做了大量的研究。
专用硬件
一般来说，IBM 和任天堂采用了许多方法来高效、经济地保护这款游戏机。
首先是关注点分离模型，用于限制 Espresso 和Starbucks之间的硬件访问。 这确保了如果主CPU(Espresso) 被劫持，I/O仍然受到某种保护。 此外，两个CPU都包含一个内存管理单元，可以根据需要伪装物理内存映射.
其次，正如我之前提到的，Espresso和Starbuck都捆绑了自己隐藏的Boot ROMs(分别有16KB和4KB)，所以它们在伸向容易被篡改的外部区域之前，总是准备好一定程度的保护(RSA和AES加密)。 这样一来，所有后续处理的代码都必须加密，而且只能由任天堂编写。
第三，Starbuck在 Latte 中分配了大量内存 以启动其操作系统 (IOSU)，而无需使用外部内存。 这又增加了一层防篡改的保护。
接下来，Starbucks 在其硬件上嵌入了SHA-1和AES-128运算器，能够在不影响性能的情况下对数据进行散列、加密和解密。
让我们继续，虽然Starbuck在技术上是一个过时的ARM9 CPU，但任天堂用一个定制的eXecute Never(XN) 控制器对它进行了增强，该控制器限制了Starbuck 可以在哪些内存位置执行代码。 XN单元履行了NX bit的作用。
最后，加密密钥和证书存储在 Latte 内部的OTP 内存 中，Espresso 和 Starbuck 都可以在完成每个条目后立即密封访问。
信任链
与任何涉及签名和加密的软件一样，签名必须有可靠的等级。
从Espresso方面来看，主核心总是在空白状态下启动，但只要它执行完Boot ROM，它就只运行Ancast images(fail0overflow的命名法) 形式的二进制文件。 Ancast images包含一个由任天堂使用RSA-2048私钥(只有任天堂知道) 签名的头，其有效载荷 (实际程序) 是用AES-128密钥签名。 OTP单元为Espresso提供了解密Cafe OS内核的AES密钥(Espresso在Wii U模式下的起点). 之后，由 Cafe OS 执行安全模型。
另一方面，Starbuck在Boot ROM之后的引导程序阶段使用Ancast image格式。 在IOSU加载并运行后，它的一个名为IOS-MCP的内核模块负责验证和解密AES密钥。 之后，加密的Ancast image和AES密钥被上传到MEM2，以便Espresso完成解密，最后执行有效载荷。
Wii 模式下的应用程序具有相同的性质，Espresso 提供了一个单独的密钥来解密Wii 系统菜单 或NAND 启动程序 ，从而使 Espresso 能够在不降低其安全性的情况下执行 Wii 应用程序。 Starbuck还在OTP中提供了两个额外的密钥，分别用于解密cafe2wii(Ancast格式) 和Wii系统更新(作为Wii U更新的一部分安装)
操作系统保护
为了进一步补充信任链，每个操作系统都在其基础上增加了额外的层次。
首先，Cafe OS实现了进程隔离，因此Espresso下的程序不能篡改其它进程的内存空间。
此外，对Cafe OS应用程序的操作是一个复杂的过程，涉及两个CPU和不同的安全机制。 长话短说，为了安装 和/或 启动应用程序，IOS-MCP内核模块负责所有必要的工作。 在安装之前，应用程序的签名(在其头中找到) 与存储在OTP中的相应证书进行核对，从而确保该应用程序已被任天堂批准 (因为他们是证书私钥的唯一拥有者). 之后，应用程序的 title key 使用 OTP 存储的 Wii Common key 解密，这允许 Espresso 稍后执行二进制文件(因为实际程序代码仍然是加密的). 最后，只要应用程序在任何时候被启动，Cafe OS的加载器就会被用来准备执行和链接二进制文件。 尽管如此，IOSU在将签名转移到Espresso之前会再次检查签名。
最后，IOSU知道Espresso的应用程序，并且只根据应用程序的权限授予某些I/O权限。 这意味着像网络浏览器这样的特定应用程序将永远无法访问SD卡。
缺陷
乍一看，Wii U的安全模式看起来更加灵活，并且解决了其前身的许多不足之处。 然而，它并非没有明显的缺陷：
- Espresso的核心是一个现成的CPU，只能理解未加密的代码，而且，与Xbox 360的Xenon 及其隐藏的加密逻辑不同，Espresso在解密后将不得不把未加密的数据储存在某处。 实际上，该数据暴露在 MEM2 上，这意味着它容易受到外部篡改。
- 每台主机的OTP缺少独有的加密密钥(与Xbox 360和PS3有很大区别)，这意味着如果它们在一台主机中被提取，它们将在任何其他主机中解密。
- Boot ROM是安全介质，但代码本身可能含有漏洞。 另外，信任链的构建方式使得启动代码成为单点故障。
- 数据加密/解密依赖于AES-128，一个对称的加密系统。 虽然AES比非对称的RSA更快，但如果AES的密钥被提取出来，所有的加密就会失效。
- 预装的应用程序之一是一个网络浏览器。 它的渲染引擎是WebKit和JavaScriptCore的一个fork。 WebKit项目提供了一份不断被发现和修复的安全漏洞公开报告 (正如任何负责任的大型开源项目所期望的那样). 然而，这也使得它成为一个有吸引力的起点，具有许多潜在的攻击面。 更糟糕的是，JavaScript引擎往往绕过内存执行保护，因为引擎需要即时编译JavaScript代码流(值得强调的是，这是来自任意网络服务器的代码).
- Cafe OS缺乏地址空间随机化 (ASLR)，使得基于面向返回的编程(ROP) 的漏洞成为可能。
- Wii已经被提前完全攻破了，这让我们认为vWii模式将会面临同样的命运(并有可能蔓延到接管Wii U模式).
但当然，其中大部分并不是立即发现的 (尤其是在发布当天). 因此，我们现在就来看看不同的安全研究人员和自制软件开发者是如何破解这台主机的。
攻破
攻破Wii U的安全模式是一个缓慢的过程。 然而，它最终成功了，从而为许多类型的自制应用打开了大门。 这场征途充满了长时间的静默, 超级重大的发现, 专注盗版的开发, 不必要的闹剧以及_黄金年代_.
让我们从头开始。
提取密钥
只要设备采用了像AES这样的对称加密模式，黑客设法提取密钥就是一个时间问题。 如果wii出现了这种情况，看，Wii U也跟着发生了。 请记住，一旦你有了密钥，你就可以像任天堂那样对内容进行加密，这样就取消了一层保护。
fail0overflow(Sven，Marcan和Comex) 在第30届混沌通信大会(2013年) 上展示他们的发现。
2013年，在第30届混沌通信大会(Chaos Communication Congress) 期间，fail0overflow发表了大量的发现，不久之后，为其他研究人员和开发人员启动了一个连锁反应。 为了给出一个概述，fail0verflow 指出：
- Wii时代的老Broadway和Starlet漏洞仍然在vWii模式下工作。 这使研究人员获得了对 Starbuck的控制权，然后可以利用它来篡改内存 和/或 攻击Espresso。 换句话说，内部存在一个glitcher与snooper。
- 一旦Boot ROM完成了对Ancast image的解密，没有任何东西可以验证未加密的数据是否被第三方更改。 因此，通过改变解密的内存(在vWii模式下使用被劫持的Starbuck)，Espresso最终将执行任意代码。 但只是提取了Boot ROM便到此为止了............
- 这是fail0verflow的一个起点，它使该小组能够提取系统代码 (目前只在vWii模式下) 用于研究目的。 但这为新发现铺平了道路。 虽然，这并不包括Boot ROM和OTP密钥，因为在任意代码执行之前，访问是被禁用的。
- 在 Starbuck 的控制下，在 Espresso 执行其 Boot ROM 时锁定
SREST（软重置）行会导致它陷入无限循环（因为 Boot ROM 在 Espresso 的重置向量中添加了陷阱）。 然而，如果Espresso在Boot ROM执行的最后阶段被软复位 (特别是在刷新缓存之后)，复位向量会指向MEM2中的一个可写位置。 因此，这使得在 Boot ROM 仍然可见的情况下允许执行任意代码。- 因此，Boot ROM最终被提取出来(并随后进行研究)。
- 仍然和Starbuck有关，如果在比预期更短的脉冲宽度下锁定
HREST(硬重置) ，可能会导致Espresso处于不稳定/不可预测的状态，但这可能对黑客有利，因为 Espresso可能会忽略隐藏OTP存储器的指令(其中密钥驻留) 。 此外，在自定义代码的帮助下，这可以转储加密密钥。- 有了这个，fail0overflow 设法提取了 Espresso 用来解密二进制文件的 AES 密钥。
- Starbuck的Boot ROM (
boot0) 在CPU更新寄存器后被隐藏。 但寄存器仍然可以在vWii模式下重新启用。- ...这允许 fail0verflow 轻松提取Starbuck的Boot ROM。
- Wii U 网络浏览器的源代码是公开的(根据 WebKit 的 LGPL 许可)。 那么，项目的提交历史暴露了历史漏洞。 其中一个能够产生堆溢出，导致任意代码执行。
- 复现这一漏洞使该小组能够在Wii U模式下执行代码，并随后提取Cafe OS用于研究。 此外，这个漏洞环境也与IOSU互动，这导致了下一个发现......
- 该团队最终发现了IOSU的一个漏洞，这导致在Wii U模式下以Starbuck的内核权限执行代码。
- ...... 导致Starbuck的加密密钥被提取。
新的可能性
考虑到这是关于Wii U的第一次安全相关演示，所展示的巨大工作量和成就令人惊讶。 有了这个，自制软件开发者现在可以开始尝试对vWii的入口点进行调试。
尽管如此，仍存有一些难点有待解决。 由于Wii U的可执行文件仍然需要有效的RSA签名，因此原生自制仍然是不可能的。 另外，还有系统代码 (即boot2) 有待提取和解密。
无论如何，fail0verflow并没有立即发布他们对Wii U的攻击，因为他们担心这会在自制软件或Linux支持之前导致盗版开发。 然而，他们确实发布了一份编写Wii U代码的指南(包括引入Linux的可能性)。 尽管它提供了在Espresso上重新启用多核的说明，他们的平台仍然依赖vWii，无法访问Cafe OS或整个MEM2。
征服Cafe OS
在fail0verflow的发现之后，全球Wii U黑客领域开始慢慢出现进展，首先是网络浏览器上的漏洞，导致在Cafe OS下以用户权限 (当前) 执行任意代码。
Relys展示他的新Pong游戏在Cafe OS上运行的情况 。
2015年3月 (差不多两年后)，用户Relys发布了第一个在Wii U模式下运行的原生Homebrew应用程序，pong乒乓球游戏的复刻版。 它从一个网络浏览器漏洞启动，接管了UI线程并获得对帧缓冲区的控制。 这个游戏的实现还成功地调用了本地系统例程来绘制屏幕。
反应到总部后，任天堂也开始频繁地进行系统更新，以修补用户的漏洞，使用现在著名的"进一步提高整体系统稳定性"的更新目标。 猫鼠游戏开始了。
以下是一个专门设计用于在Wii U上触发漏洞链的网站示例。该链可能会捆绑一个有效负载以执行一些有用的操作。
此后不久，网页浏览器漏洞下的homebrew开发成了事实上的标准。 在同一个月里，为了便于开发，一个新的开发小组发布了 libwiiu , 一个专为网络浏览器漏洞的工具包。 libwiiu 依靠devKitPro 编译套件并提供额外的 CafeOS 头文件来访问系统功能(只有那些在网页浏览器的用户界面下可用的系统功能)。 最后，他们的工具链自动嵌入了一个带有必要漏洞的有效载荷，并将所有东西打包成随时可以托管的HTML文件。
2015年8月达到了一个新的里程碑：libwiiu团队发布了一个内核漏洞。 这个新发现利用了多线程的竞争条件，在内核锁定一个名为OSDriver的结构之前改变其内容。 这允许相邻的核心能够用数据填满它，并最终上传到内核的内存。 因此，可以在无需强制执行权限的情况下将任意内核调用添加到读取和写入内存。
尽管有了这一切，任天堂却已经在系统版本5.5.0中修补了 OSDriver的漏洞(仅在该内核漏洞公开发表的两天前发布)。 此外，IOSU仍然无法控制(意味着没有任意I/O可使用)。
欺骗 IOSU
对于那些没有更新过5.3.2版本的人(因为5.4.0版本修补了最后一个用户区网络漏洞，5.5.0版本则修复了内核漏洞)，仍有更多的功能需要解锁。 尽管IOSU仍然未被攻克，但三核处理器Espresso现在已经处于用户的控制之下。 因此，通过一些变通的方式，可以让IOSU认为自己正在执行一个应用程序，从而授予更高的权限。
Golden45展示了他的新自制应用程序，使用户能够从SD卡中启动游戏备份 。
在2015年10月，开发者Golden45和Dimok发布了Loadiine 。 该应用程序依赖于Espresso内核漏洞，可以从SD卡中运行盗版Wii U游戏。 为了运行Loadiine，它需要从Web浏览器中启动，并使用内核特权来启动官方应用程序。 紧接着，Loadiine 就会进行实时内存篡改，以将程序执行重定向到存储在 SD 卡上的游戏。 最初，只有《任天堂明星大乱斗》可以使用这个方法，之后 Mii 制作也可使用。 无论如何，所有这些内存操作都是为了让 IOSU 认为它仍在运行相同的官方程序，从而授予足够的特权使得盗版游戏可以正常运行。 这种方法不能完全依赖于网络浏览器，因为 IOSU 未赋予其对SD 卡的访问权利。
你现在可能认为，在Loadiine带来与盗版有关的进展后，对自制程序的进一步渴望完全黯然失色了。 然而，在2016年2月，Dimok发布了Homebrew Launcher ，这是另一个网页浏览器负载，这一次可以从SD卡启动ELF二进制文件。 在向 Team Twiizers/fail0verflow 的经典自制软件频道致敬的同时，Homebrew Launcher 列出了存储在SD卡上的ELF应用程序，并允许用户按照自己的意愿启动任何应用程序。 这是一个离开了嵌入程序到 HTML 文件的做法，类似于 Loadiine，Homebrew Launcher 通过劫持 Mii Maker来实现。
Homebrew Launcher正在运行中。
现在，对于那些更新到 5.5.0的人，将有一些好消息（在最后）:
- 自2015年11月以来，在浏览器上发现了新的突破口，从而恢复了 userland 的执行。 新的漏洞依赖于从精心设计的PHP服务器中提取MP4文件后引起的缓冲区溢出。
- 似乎一个与最新固件兼容的新内核漏洞正在一个私人团体中进行测试。 就是说，直到2016年5月，它的一个测试者才泄露了这种漏洞。 这个新的漏洞依赖于 GPU7 对 MEM2 的直接访问，而 MEM2 本身就允许它覆盖内核堆的一部分。 黑客们利用这一发现重建了利用
OSDriver的老把戏。
总之，5.5.0上的用户现在能够享受最新的自制程序。 事实上，这些漏洞到今天还没有修复。
达到半固化
一旦 homebrew 达到一定的成熟度，总有一个人问......有没有一种方法可以让这一切变得更加简单易懂？ 换句话说，我们能否摆脱对网络浏览器的需求？
嗯，这是一个具有挑战性的任务，因为IOSU仍然在系统菜单上运行任何应用程序之前强制执行代码签名（因此，需要使用网络浏览器和劫持 Mii Maker）。 总而言之，如果没有一个安装非签名频道并能够启动它们的方法，就会回到鸡生蛋 蛋生鸡的问题。
让我们来到2016年， 这对于独立的安全研究是 "有趣的" 一年 （以及不必要的戏剧性 ...）:
- 黑客yellows8、smea和WulfyStylez发现，某些应用程序没有经过正常的安全检查，允许第三方与其他携带潜在漏洞的程序交换。 然而，要改变这些包，人们需要一个 IOSU 漏洞，使 Espresso 能够在没有特殊权限的情况下将数据移入和移出NAND。
- 新的 IOSU 漏洞，具有用户区和内核权限，由两个独立的黑客组织（一方是 plutoo 和 naehrwert，另一方是Hykem）独立开发。 这些发现了IOSU的系统调用中的许多漏洞，随后允许在 Starbuck 上以高权限运行任意代码（意味着对 I/O 的无限制访问）。
总之，这两个发现直到那年年底才公开发布。 主要原因是大多数作者计划一旦他们制定了合适的最终用户解决方案，就会发布这些发现。为此，他们需要时间来制定解决方案。
关于游戏资源漏洞，smea 还发现与任天堂 DS 游戏在 eShop 上销售的模拟器捆绑在一起 (称为"hachihachi") 具有动态代码执行权限，而且最重要的是，它的 ROM 解析器容易受到任意代码执行的攻击。 这意味着，通过 IOSU 内核漏洞的帮助，一个人可以修改已购买的 DS 虚拟控制器游戏的资源，这样一旦游戏启动，就可以提供任意代码执行 (就像浏览器被用于那样)。 好吧，这个漏洞利用方法最终在2016年11月发布，名字叫 haxchi。
不久之后，开发者 FIX94 fork 了 haxchi，并把它修改为能使用_脑锻炼_的 PAL 版本，并在随后的几天又添加了更多游戏。 此外， FIX94实现了一个直截了当的 "安装程序"，将一个DS游戏自动转换为 "haxchi launcher"（为普通用户部署haxchi 提供便利）。 安装程序还依赖于由 Hykem 发现的 IOSU userland 漏洞。
如果还不够的话。 这里是另一个发现：Cafe OS的配置文件也可以被改变为启动任何已安装的频道而不是系统菜单。 幸好，DS 游戏也是频道，所以一旦Wii U启动，就可以自动启动haxchi (运行Homebrew)。 所以你看, 这些就被打包为了 冷启动破解。 然而，与 Homebrew 应用不同的是，这将引起一些人的恐慌，因为永久改变 Cafe OS 的启动配置可能导致破坏性的结果！
有趣的是，Haxchi 成了主流的破解方法后，可以看到 脑锻炼 上了 eShop 的销量排行榜，是有趣巧合？
解锁IOSU
现在用户可以在不依赖浏览器的情况下运行自制程序，是否还漏掉什么东西呢？ 好吧，签名检查还是要执行的，因此Starbuck可能还需要调整一下。
在这里， 自定义固件(CFW) 这个古老的术语出现了。 现在我们已经有了IOSU的内核漏洞和所有必需的加密密钥了，现在我们可以强迫Starbuck从SD卡启动一个替代的系统镜像(fw.img)。 这个新的系统可以移除许多'烦人的东西'，诸如授权和签名检查。 好了，以上就是Wii U自制场景中所谓的'CFW'。
尽管如此，CFW仍然需要一个启动器，例如一个(带有一套IOSU漏洞的) 自制程序来把Starbuck重启到我们的任意镜像当中去。 这项任务由Dimok和他在2016年10月发布的CFW 启动器 工具来处理。
现在，关于实际使用的CFW，黑客们比如sema发布了一套名为 IOSUHAX 的工具，方便编写定制的 IOSU 固件镜像。
IOSUHAX包含一个著名的工具 '重定向NAND' (redNAND)。 这使得用户可以将NAND中的内容转存为一个镜像文件并存储在SD卡中，然后使Espresso和Starbuck都改为从那里启动。 这个环境的主要优点在于，任何在IOSU或Cafe OS中的改动均不会对NAND中的主系统造成永久的影响。 因此，任何在redNAND中的意外损坏均不会损害主机，这意味着黑客和开发者们可以使用redNAND对系统文件进行随意修改而不必担心会对主机造成不可逆的损伤。 这恰好是另一个能让安全研究人员的生活更轻松一点的工具。
因此，CFW（fw.img形式的文件）在网上陆续出现，每个都提供了不同类型的定制功能，包含移除签名检查甚至增加新的系统调用（与IOSU内核模块互动）以供自制程序使用。 总而言之，它们允许在系统菜单上以'官方'通道来安装和运行自制程序。
调整Cafe OS
由于运行一个CFW很快变为了破解任意Wii U的首选方法，随后的几年的重点是简化这个过程所需的步骤。
2016年12月，我们看到CFW的开发不再需要fw.img了。 相反，漏洞改变了正在运行中的IOSU和Cafe OS，还禁用了签名检查并增加了新的系统调用。 FIX94的对Haxchi的分支以及Dimok的Mocha自定义固件 就是很好的例子。
此外，在2017年之交，复杂的Wii U homebrew 应用井喷。 举几个例子：
- SwapDRC 允许将TV的帧缓冲和音频与GamePad 的实时交换。 这对于不提供镜像功能的游戏特别有用。
- Nintendont (另一个 FIX94的作者) 通过映射支持旧的 Wiis (或vWii 模式) 硬件，所以GameCube 游戏可以在不使用任何类型的模拟 的情况下运行。 除了被当做Wi-应用程序， Nintendont也可以被打包为GameCube游戏，并安装为Wii U频道(意味着它将利用Wii U的本机存储)。 然后，GameCube游戏将在 vWii 模式下运行，但需要额外的GamePad支持 (就像其他的vWii游戏)。
- Homebrew App Store 提供了数以百计的并且可以直接从Wii U 下载的免费自制程序目录，(然后从Homebrew Launcher启动) 。
- WUP Installer 可以在Wii U的系统菜单上安装频道 .
晚些时候（到了2021年）， 开发者"Maschell"发布了一套新的工具，最终将haxchi 套装作为攻击wii的默认工具。 在此期间， Maschell 创建了Mocha CFW的另外一个版本，现在可以从"健康与安全"应用中启动(使用了一种新的方式去篡改游戏资源)， 因此不再需要购买脑锻炼或其他的DS游戏。 新的 CFW 套件还发布了一套集成的 API 来帮助开发者执行Cafe OS的插件。 这被包装在一个新的套装/环境下称为 Tiramisu 。
新的环境加载器(Tiramisu的一部分) 允许用户在启动系统菜单(或任何其他选择的应用程序) 之前选择特定的补丁和插件集。
现在是故事结束的时候了。 当任天堂显然不再有兴趣继续更新的时候，画面仍在向前推进。 Nintendo Switch已在2017年发布，wiiu已经不值得继续维护了。