Wii U hack detailed by Fail0verflow (and lessons learned for Vita hacking)
Over the Christmas holiday I had the opportunity to watch fail0verflow’s presentation on how they hacked the Wii U in 30 days (I didn’t have a working internet connection while I was away, but had managed to download a copy of their video before leaving). The video of their presentation (below) is interesting in itself, and I strongly recommend you watch it (and the accompanying blog post) if you have an interest in hacking in general, and console hacking in particular.
But you’ve probably read everything there is to know about Fail0verflow’s presentation by now, especially if you’re in the Wii U scene. After all, their presentation was 2 weeks ago, that’s aeons ago in the hacking community. But I’d like to discuss some of the points they made, that I think can easily relate to Vita hacking.
0. That was fast!
It is of course impressive that a “next gen” console was hacked so fast: the Vita has been out for more than 2 years and is still majorly undefeated, the PS3 was out for more than 4 years before it got seriously hacked, and more recently, both the PS4 and the XBox One have been out for several months, and there are no signs of them being even scratched (ok, there was a NAND dump of the PS4, and we have a few instructions on how to play with a proxy on the PS4 to tinker with the PSN, but that’s basically it).
A fairly old but detailed timeline of consoles hacking can be found below, extracted from this 2010 blog post. As you can see, a hack within a month is on the “fast end” of the spectrum.
1. Knowledge of the previous consoles was critical for the Wii U hack.
the fail0verflow team emphasizes how the Wii U is nothing more than a hardware upgrade of the Wii, itself an upgrade of the Gamecube. Their knowledge of the Wii and them having some undisclosed exploits for the Wii were extremely valuable entry points into hacking the Wii U. They were even able to reuse some of their Wii hardware toolkits on the Wii U eventually.
The PS Vita is *not* an upgrade of the PSP, it is a totally new device. And even though the knowledge of the PSP has let us essentially control everything in the PSP emulator on the Vita, that doesn’t give us much flexibility into going any further down the Vita itself. Kermit seems to be the only communication bridge between the PSP emulator and the Vita, while the Wii mode on the Wii U seemed to be more connected to the Wii itself.
2. Hardware knowledge was useful to hack/dump/observe the Wii U behavior
I’ve stated it countless times, but treating the Vita as a black box from only a software point of view is extremely difficult, given that we have close to no entry point. We can’t analyze a crash easily, etc… Fail0verflow explain how some of their first steps involved being able to come up with a system that could read/write to the Wii U. It is interesting/sad that we don’t have that much attention from hardware hackers on the vita (besides Yifan Lu’s recent work), but the fail0verflow presentation confirms that a good console hack involves both Hardware and software work.
3. NX and ASLR
Modern operating systems and CPUs have good hacking mitigation techniques. For those of you familiar with PSP hacking, implementing a PSP usermode exploit is usually 3 “simple” steps: find a bug, find a position to write our code, and jump to it. Typically with our buffer overflow exploits, we’d write our code in a game’s savedata, find where it gets loaded in the RAM (that position, on the PSP, is always the same, on all devices, and only depends on the game), and jump there. NX (No execute) prevents the CPU from loading code that would be in the “data” section of the memory, while ASLR (Address Space Layout randomization) makes the position of our payload (and the libraries it might want to call) impossible to predict.
These two mitigation techniques are implemented on the Vita (they did not exist on the PSP). There exist methods to bypass them, but that would require exploits as well. In other word, a single exploit on the Vita would require not only the initial exploit (our typical “buffer overflow” on the PSP), but also 2 additional exploits/bugs to bypass NX and ASLR.
What was different on the Wii U? First, it doesn’t seem to implement ASLR at all (a big mistake on any modern computer system), and the Fail0verflow team found a limitation in the NX implementation, that I will describe below.
4. Go for the browser
This might be the most essential point we can relate to in the Vita hacking scene: The browser today is likely to be one of the most vulnerable parts of the PS Vita. It is webkit-based, which means there exists a huge and documented database of critical bugs for it, and that the source can be accessed. It could be “reasonably” easy to find crashes in the browser. As far as analyzing them is concerned though, I think here again, nobody would go very far without a (hardware?) way to read the contents of the Ram real-time.
Another interesting point made by Fail0verflow is how, on the Wii U, the NX bit was disabled for the browser! There’s a possibility this is true on the Vita as well, who knows… That would be one less obstacle to bypass in order to get an exploit running.
5. Is homebrew still relevant?
As a conclusion to their presentation, the Fail0Verflow team re-stated that to them, the interest for Homebrew on consoles in 2013 (now 2014) is not the same as it was back when the Wii, PSP, etc… were the latest big thing. Today, if you’re a tinkerer, a gamer, or a developer, there exist plenty of ways for you to code your own game, or to play any emulator, or mod anything you want, on devices that are way more open, and sometimes more powerful than these consoles. You can plug any Android box (Ouya, etc…) to your TV, and any decent phone today let’s you run fanmade games or emulators on the go. Sure, few of them have the awesome screen and controls of the Vita, but that’s another story.
They also emphasize that given today’s consoles complexity, developing an entire SDK for homebrew from scratch would be quite complex, while in comparison enabling piracy once an exploit is made public, would be much easier (patch a few things in Ram here and there). Which raised concerns around the outcome of releasing their hack…
The above is something they had already stated back in May this year