Wii Fail: Console Hacking 2008 - The Definitive Review
Why you should really give a shit about console security
1Annually, between Christmas and New Year, the German hacker collective Chaos Computer Club2 holds its conference, the Chaos Computer Congress3. A general tradition is that it has a talk on console hacking, this being a thorough overview of which gaming hardware manufacturer has failed (yet again) to adequately secure their hardware. For example, this year’s subject was hacking the Nintendo DSi4. Sometimes the talks are extremely technical, demanding familiarity with hardware design, low-level software coding and cryptographic practice, but sometimes they’re relatively understandable for ‘ordinary’ people. Perhaps the best of these is 2008’s console talk, which dealt with the Nintendo Wii. It offered a complete hack just two years after the system’s release. The talk is superb, beginning with the specifications of the Wii’s security design, then detailing the history of the hacks and ending with, as is tradition, a live demo of taking an unmolested retail unit from stock console to Linux box.
WHY LINUX THO?
Linux is central to the cracking effort, as getting it to boot on consoles has been carried out with extraordinary zeal, tenaciousness and repeated success for over 20 years. In terms of hacker prowess, it shows two key flexes: arbitrary code execution and free access to storage. The modern paradigm is obscenely cryptographic and hugely paranoid, hence much more kudos is afforded to hacks that are broad, universal and (perhaps most importantly) easy for non-technical people to execute. This all starts with the Microsoft Xbox, wherein offering a mid-range PC in a compact box for $299 at launch was a tantalising prospect for hardware hackers. While the idea of ‘sticking it to the man’ has never been officially stated and, in some cases, flatly denied by Linux libertines and console cracking groups, it has to be noted that the idea of letting Microsoft pay you $100+ (or whatever loss-leader cost it was) to have a PC of their choice, and then cracking it to run an open-source OS, certainly plays to a counter-cultural hacker sensibility and sense of humour. Especially given the wider legal battles Microsoft was fighting at the time, namely accusations of anti-trust monopolisation from governmental agencies in the US, EU and Asia, plus its long-standing history of corporate dastardliness. It would be quite a few years before hackers had such an obvious big-business baddie to humiliate.
BUT HOW CAN YOU CROWBAR A 6502 REFERENCE INTO THIS?
Chaos Computer Club luminary and 6502 fan Michael Steil gave the defining talk for console hacking in 2005, which dealt with the Xbox’s security system and its seventeen flaws5. Not bad for a hardware debut. The Xbox hack generally revolves around Andrew Huang, who going by the handle ‘Bunnie’ was able to extract the Xbox’s hidden boot ROM6 by literally reading all 512 bytes of it from the circuit board as they moved around the system. One of those seventeen flaws was “don’t send your crypto crown jewels across traces that can be easily probed”. The presumption on Microsoft’s part was that the transfer speed would be too fast to be sniffed, which is one of the cardinal sins in good security practice - relying on security through obscurity. The wisdom is: hackers will always find it if it’s able to be found. And in finding that first-stage boot ROM, they were able to inspect the hardware to bypass it, which lead to modchips7 that got down to just 9 wires, plus eventually leading to dashboard softmod hacks8 and ultimately the discovery of savegame vulnerabilities9 that are used to this day. But, I digress. I’m trying to promote the failings of the Wii’s security rather than the Xbox, even though oddly similar mistakes are made.
MISTAKES WERE MADE?10
The Wii presentation by Bushing (RIP) and Marcan is beautifully illustrative of the hardware cracking tradition. There are hardware and software components to breaking the machine’s security, but the key thing to bear in mind is that while Bushing and Marcan are experts, their hack is ultimately the work of hobbyists, albeit extremely tenacious and highly skilled ones. None of the tools they used were particularly obscure or difficult to acquire and one, infamously, can be bought at just about every supermarket: a set of metal tweezers. The team begins by describing, in precise detail, the security architecture of the Nintendo Wii. Now, being Nintendo’s first home console with an online store, there was a clear compliance requirement in terms of securing sensitive customer details. While it can be argued that vast amounts of hardware and software DRM is there to benefit the platform holder, an online store brings with it a deeper responsibility to protect the clients using that platform. And thus, we find out that the Wii uses encryption all over the place. In Wii mode, RAM is fully encrypted so therefore everything passing through the CPU has had to be decrypted before execution, meaning that running arbitrary code is virtually impossible without knowing the encryption algorithm and associated keys. It’s a colossal challenge to even get the code into RAM, let alone execute something to bypass the security system. However, with forensic detail it’s revealed that the Wii’s security is reliant on a secret11 ARM CPU running a completely bespoke security OS that runs underneath the Wii’s menu app. This security OS (amusingly dubbed ‘IOS’ in 2008) arbitrates just about everything the Wii does. All the RAM accesses, including all the data coming off cards and the DVD drive and so on. And this CPU and OS is completely undocumented! It was kept a complete secret, with the CPU and its OS ROM tucked away in the ATI-based GPU, codenamed ‘Hollywood’ and amusingly, Bushing and Marcan named the security CPU ‘Starlet’. So how did they find all this out?
IS THIS HACKING LIKE THE ROCKSTAR ONE?
Unlike the recent Rockstar hack, which was about getting some user’s credentials and then using a Fire Stick in a hotel room to spam two-factor-authentication requests until the user approves accidentally or to just get their phone to shut up, the Wii’s security was exposed by its own shortcomings and, to be particularly critical, a failure to apply basic security concepts. The chink in the armour is Wii’s backward compatibility with the Gamecube. As it turns out, it’s a bit more than backwardly compatible - it’s close to natively compatible given a suitably adapted Gamecube boot rom. You see, the Wii can be thought of as a doubled-up Gamecube with loads more RAM. Both the CPU and GPU are code-compatible with the Gamecube, meaning Gamecube content just runs on the metal with no abstraction layers in between to manage hardware differences. Only this doesn’t apply to the system’s RAM. Now recall that under Wii mode, the ‘Starlet’ security chip encrypts everything that goes into RAM and it checks executables, like the system menu or game programs, are correctly signed to verify they haven’t been fucked with. The Gamecube does none of this, so to ensure smooth operation Nintendo opted to turn off Starlet while the Gamecube mode is running. The Wii also clears the bottom 16 megabytes of RAM, which forms a sandboxed memory area for Gamecube games to use. What’s fascinating here is that the Gamecube mode is so native that pre-existing Gamecube exploits still work!12 This means Gamecube homebrew can be run.
SURE BUT WHAT ABOUT THE TWEEZERS?
So that sandbox of 16 megabytes for the Gamecube sits inside a single memory chip that holds the Wii’s total 64 megabytes. What Bushing and Marcan found was that by connecting two pins on the chip together, you could move the 16 megabyte window upwards through the rest of RAM - and Gamecube mode was able to see it! Can you guess what metal object could be used to connect those two pins?13 With help from another hardware hacker, they found a way to export whatever was in this RAM by a pretty unique method. The talk mentions soldering some wires but I remember at the time, commenters thought they must have piggy-backed data output pins on the RAM chip and connected them to a Gamecube controller port’s rumble data line, allowing a bodged connection to a PC serial port to capture the RAM contents as a stream raw binary, allowing them to build 48 megabyte datasets.
WHAT WAS IN ALL THE LATEST MEGABYTES?14
Wii data. Lots of it. In a magnificent turn of poor data hygiene and, of course, direct contravention of security best practices, the Wii and the Starlet security chip didn’t zero the entire RAM when entering Gamecube mode. Which meant that shitloads of really important stuff was there. Wii menu code and the security OS code for example, and all the system keys. Yep, all of them15. Now as far as I’m aware, for keys to be used for encrypting or decrypting, they cannot be encrypted themselves and that’s what was found. Naked keys in cleartext16. What this meant was the team could now observe the machine in action. They could enter Gamecube mode from the Wii menu under different conditions and see what changed. This incredibly simple oversight of not clearing the whole of RAM grants full exposure of Starlet, its security OS and the entire security system for the Wii. It was eventually found that the security OS had a remarkably simple flaw. At a critical part in decryption and validation, the security OS has to compare a result with a stored checksum, only it uses a C function that halts if it sees 00 in the data it’s working on17.
WHAT’S UP WITH DOUBLE ZERO?
The problem is the Starlet passes the data as validated if the function halts, so all you have to do is make sure there’s 00 at the start of the data and it’ll always pass. As the team knew the algorithms in use and had the keys, it was trivial to pad data with extra characters to ensure a 00 in the first two two bytes, the upshot being it was pretty much trivial to make fake signatures to get arbitrary code approved by the security OS. And, I think, this was also the path towards a custom boot ROM that would enable a homebrew channel on the Wii’s system menu and, of course, bootable Linux. Bushing and Marcan eventually get the whole process packaged into a tight payload contained within a game save, meaning all you needed was Zelda: Twilight Princess, a doctored save file and you could install a custom boot image for all that delicious extra functionality. Of course, Nintendo patched that particular exploit in time but the system’s security fundamentals were simply too exposed, leading to modern day exploits that run off the SD card or via the Internet Browser.
BUT WAS 2008, HAVEN’T THEY LEARNT BY NOW?
With the news from late 2023 of an Everdrive multicart arriving for the Switch, it seems faintly unbelievable that Nintendo is incapable of securing any of its hardware. The same goes for Sony, given that every single PlayStation has been hacked, not to mention its actual PSN infrastructure and the infamous compromising of 77 million accounts, with PSN taken offline18 for two months19. And if you think the Wii’s mistakes were bad, consider that it was found that the PlayStation 3’s impressively advanced elliptic curve algorithm (ECDSA) was fundamentally, irreparably broken20. It was also used to sign and verify all executables, and perhaps the internal discovery of this caused that sudden removal of Other OS. And what of the Xbox 360? That was hacked really early, right?
WAS IT THAT JTAG THING?
Well yes, it was that and there are JTAG exploits that sort of work today if you’re into heavy modchip soldering. But the early hack was done in a brilliant way21. The DVD firmware was hacked too, allowing DVDRs to be used to play copied games. But these were aggressively patched. You see, Microsoft had learned in a way that Sony and Nintendo had not; the Xbox 360 used a software hypervisor to abandon the then-traditional ‘chain of trust’ procedures. With a common approach being a tiny boot ROM that verifies a larger secondary ROM to assure trust, the old paradigm would not normally verify things again until a game was presented to security, in which case it would simply verify the game’s credentials and carry on trusting the system. The Wii actually encrypted its game discs and used elaborate tables to speed up verification but for the most part, trust is generally constant until challenged. This means getting in early with a hacked boot ROM means you can hijack that chain of trust and ride it through to your objective. However the Xbox 360 hypervisor trusts absolutely nothing under its purview, which means all RAM accesses and all CPU code and checksumming the whole way. If you try to terminate the hypervisor it just restarts, after verifying itself! This hypervisor is beautifully interleaved with dashboard and/or game processes, running on the CPU with no noticeable lag or overhead. It’s a really quite elegant solution and in tandem with E-Fuses22 on the CPU die, proved far superior than Nintendo and Sony’s security efforts to this day. In fact, despite being nearly 20 years old, the Xbox 360 still demands soldering stuff to the board to modify it23. As for its follow-up, the Xbox One? Well.
WELL? WELL? WHAT?
It’s never been fully hacked. There’s been middling progress. A mild exploit in an early firmware, a dumped NAND flash that’s brutally encrypted, but no unsigned arbitrary code execution. And that’s for its entire lifetime as the Xbox flagship. It’s the first console ever to have survived an entire generation which, as we can obviously see, is a spectacular achievement. This isn’t for the want of trying - the kudos for breaking the Xbox One security would be immense. It seems to use a massively improved version of the Xbox 360’s hypervisor in combination with other new features and approaches. Really, it’s a triumph. It’s interesting to note which corporate giants seems to never suffer mega-hacks or expose terrifying numbers of user details. And there’s a good reason for that - they genuinely take security seriously.
BUT HACKERS ALWAYS WIN!!!!
No, actually they don’t. The Xbox One is almost proof that there are cases where security, done correctly, is too difficult for hobbyists or small groups. We can never rule out the capabilities of nation states or wealthy organised crime, but it seems that there are some systems that defy the hacker myth. But that narrative is all too easy to succumb to. Victim corporations and companies, which have mega-million revenues and can post astronomical profits, would rather have consumers believe that malign hackers have ruined everything for everyone but the reality is the security just isn’t good enough. These corporations, with their billions of dollars, ask us to trust them with our credentials. Our bank cards. Our identities. And yet, nearly all of them fail to adequately secure the hardware they want our information to pass through. If the Chaos Computer Congress archive tells us anything, it’s that security has constantly been botched through poor implementation and poor practices. In some ways, it underlines the hacker claim that all encryption should be public and transparent, that external parties should be allowed to audit these incredibly private security regimes. And the history of home console security absolutely proves why this is probably a good idea. Much is made about the danger that hackers cause by publicly disclosing security vulnerabilities and releasing software to exploit them, but it’s the only way to actually force change. The problem isn’t the hacking. It’s the poor security. You won’t hear the corporate victims talk about the private approaches and disclosures that are standard practice in the console Linux community before going public, nor how they were so often ignored or batted away with hollow legal threats. Interestingly, after Michael Steil gave his first Xbox talk at the Chaos Computer Congress in 2003, he was invited to give the lecture to Microsoft teams, which undoubtedly helped with the Xbox 360 security design. It’s a pity they’ll never allow Linux, though.
[21]
Please note, if you see any technical errors at all in the following piece, feel absolutely free to abuse and correct me in the comments.
Founded in 1981, if you must know.
First congress was in 1986. Back off, Defcon with your 1993 latecomings.
Readers may recall that I have hacked my DSi, which lead to spectacular benefits.
As noted in the talk, it's not seventeen single mistakes, but seventeen flaws repeated multiple times.
In common practice for chain-of-trust security designs, the Xbox has a tiny first-stage boot rom that does some basic initialisations and then verifies a much larger and capable second-stage boot rom that's stored elsewhere. This is often on some form of flash memory so it can be modified via software updates to fix bugs, update security etc. The chain of trust utterly relies on that initial verification.
The Xbox modchips contain a modified boot flash that opens up the system, adding all that glorious extra functionality. Knowing the original 512 bytes allows the modified flash to be parsed as original.
Xbox security completely ignored system fonts. With the dashboard and boot animation stored on the HDD, the only unencrypted entities were two system fonts that were trusted to such a ludicrous extent that (I think) even their file lengths weren't checked. It was fairly trivial to hook an Xbox HDD up to a PC, modify the fonts and then put it back in the Xbox and be off to the races, thanks to additional vulnerabilities in the Xbox's font handler.
007: Agent Under Fire has a buffer overflow vulnerability as it doesn't checksum savegame filenames. The overflow allows the user to load arbitrary code into the CPU's stack, so can JMP to re-flash the boot rom etc etc etc. The game was picked because it was literally the first game on the fucking list. Turns out lots of Xbox games have savegame vulnerabilities. To be honest, it's not even Xbox. Simply put lots of games, irrespective of system, have savegame vulnerabilities. Super common in Nintendo hacks.
Apologies to MVG.
La la la - security through what?
Crazier still is the Matsushita DVD drives in both machines are so similar that Gamecube modchips could be installed on the Wii motherboard to run copied Gamecube discs.
I recall that the tweezers worked because the natural gap when the tweezers were at rest was the precise distance needed to touch the two necessary pins.
Apologies to Mr Tan.
What's particularly bonkers is that Nintendo opted to to create a unique per-system ID number for each console as a kind of master key for all decryption on the machine and they did this by burning as ROM into the GPU die at console assembly, not at chip fabrication. The hacking team speculates this would have required extremely expensive equipment, so to copy that key out into system RAM and leave it there seems remarkably reckless in hindsight.
I believe the methodology here is that you have 48 megabytes of encrypted data, which might have an unencrypted key sitting in it. With a suitably capable bit of code, you can treat a standard key-length number of bits of that data as a potential key and then try to decrypt the rest of the dataset with it. As the possibility space is only 48 megabytes, it's fairly trivial to brute-force the dataset by sequentially trying key-length values of bits as a key. You can set the code to try different key lengths and even different encryption algorithms but because the dataset is so finite, if the keys are there, the data will be decrypted eventually. Turns out the Wii used 2048-bit keys with RSA for signing executables and encrypting RAM data.
For people more technical than me, the security OS uses a string compare rather than binary compare function. Apparently binary compare wouldn't have this problem.
Sony has never explained why it took the nuclear option of taking PSN offline, nor did it every adequately explain why it removed 'Other OS' Linux support. The removal sparked the Linux advocates to attack the system, with George Hotz infamously bypassing the PS3's hardware hypervisor and extracting private encryption keys. The PS3 was cracked within about a year of the Other OS removal, showing why it's not a good idea to give Linux people what they want and then take it away.
We can freely speculate that to shut down your entire online services for two months must have meant the risk of keeping it up was probably Quite A Big Deal. Some speculate user credentials were at risk, but I prefer the far wilder idea that the infrastructure was so compromised, a virus could have been spread that could permanently brick every PS3 on it.
Where key generation requires some private key mixed with a generated random number derived from calculations done on mathematical object called an elliptic curve, it's helpful to make sure the random number isn’t always the same random number.
In a similar oversight to the Xbox font exploit, Felix Domke used 24-bit shaders for the GPU to load payload data into RAM because the X360 hypervisor only cared about code and treated shaders as data. In a 64 bit system, each 24-bit shader has 40 bits free to smuggle in extra code, provided your game doesn't bother to checksum its shaders. And King Kong made that mistake. A hacked ISO allowed code to be infiltrated and a savegame overflow exploit wrote initial payload data into the only RAM the hypervisor didn't protect: the hypervisor itself . Fucking bonkers, but very easily patched out.
These are features on the silicon of the CPU that can be permanently and irreversibly burnt with software commands to signify particular boundaries, such as verifying how many updates a system has had. It had two main uses in the X360: to prevent downgrading of firmware to older versions to exploit vulnerabilities and, because there were so many of them on the silicon, to etch in a unique system key (according to Felix Domke).
Modern X360 modchips and hacks use high voltage glitching to trick the CPU into leaping between instructions by firing a rapid burst of unexpected current into the chip with microsecond timing. This was also used by George Hotz to bamboozle the PS3’s hypervisor and, interestingly enough, was used to crack the DSi boot sequence.