20 comments posted · 70 followers · following 0
The Wii is the middle step. It got lucky, because we had libogc from the GC days, and it still didn't have enough RAM to run Linux comfortably, though popular homebrew based on Linux does exist. It also didn't really have an OS either, just a built-in launcher.
The Wii U changes that. It uses bog standard hardware that *already* has Linux drivers. It has a truckload of RAM. And its native apps already use an OS that qualifies as a modern multitasking, protected memory OS. Running Linux on it will actually improve things (e.g. you get access to more RAM, since normally the system reserves half!)
Think of Linux as a homebrew SDK, nothing more. Just one that happens to have APIs that make porting existing games and apps way easier than it ever has been on any other console. Nobody's suggesting that we throw Ubuntu on people's consoles, just that the Homebrew Channel for Wii U might as well run a Linux kernel behind the scenes. Homebrew developers don't *actually* want to learn yet another proprietary graphics API when they can just use OpenGL. Make it easier to write homebrew without needing to use specific skills and undocumented APIs, and you'll get better homebrew.
We haven't looked into non-browser exploits. There probably are quite a few around though, subject to possible entry points (i.e. things the Wii U will do with storage - which seem to be fewer than the Wii!).
They probably could've avoided the SRESET race conditions (I won't detail how to avoid giving them any ideas, just in case they really think this is worth fixing), but they'd need to spin new silicon for that, which is extremely unlikely - they'll only do it if they're doing a new silicon revision for some other reason.
2) Meh, it was mostly an evolution of the Wii's. The Wii had a pretty decent (but simplistic) security design and a crappy/buggy implementation. The Wii U seems to be more of the same, though with some nonsense thrown in (the Espresso bootrom) and some obvious features added (verification on launch and hash trees for NAND titles). On the other hand, they finally have drive to console authentication, which was sorely needed (otherwise there would've been drive emulator piracy a month after the console's release). I suspect that bit was high priority for them.
It's cool that we can do these things, and messing with and reverse engineering the system is fun, but as an application development platform? No, sorry, console homebrew SDKs are a joke compared to something like Android (or Linux + the usual libraries, or OSX, or Windows + DirectX), as much as you may dislike it. Console homebrew is a niche market with niche tools.
OTOH, this is why, if there's interest, I still think the obvious direction for Wii U homebrew is to use Linux. At least then you'll get a mature set of development tools and a sane graphics API (OpenGL) plus all the usual libraries like libSDL. It'll still take a lot of effort to port, but at least it won't take as much effort to actually write apps once it's done.
Now, you may argue that the Android ecosystem is more annoying for users, but there are plenty of free, ad-free, useful Android apps. It's just that, because it's a much more successful platform, and it has legitimacy that console homebrew doesn't have, they're buried under all of the ad-supported crap. On the other hand, I personally have absolutely *no* problem paying a couple bucks for a polished, functional Android app that doesn't go overboard requesting permissions. I want to support application authors like that.
As for device locking, I've never bought an Android device that required an exploit. Oh, sure, there are plenty of locked devices out there, but there are many unlocked ones too. Pretty much all of the Chinese sticks come pre-rooted. All my portable Android devices are from the Nexus line with unlocked bootloaders. Ouya comes with an unlocked bootloader. Even on locked devices, the development effort is typically minimal compared to console homebrew: just find an exploit that lets you run code as root, throw /bin/su on there, and you're set. Yesterday I fixed the Japanese fonts on my phone and tablet by editing an .xml file - how is that not an open platform?
As a hacker, I find reverse engineering security systems interesting, but when it comes to app development, I stick to what makes sense. The last two big application projects that I've worked on have been developed to run on Linux systems (though mostly portable to OSX). One of them is designed to run as set-top-box type appliance. Could I have used a Wii U? Sure, it's actually an almost ideal system from a hardware perspective - I needed a touchscreen remote. But I went with a hacked chromebox running Ubuntu and a <$100 chinese android tablet as a remote. The development effort required to get all of this to run smoothly on a Wii U (i.e. porting Linux including all of the reverse engineering required) would've been astronomical compared to the ~4000 lines of application code involved. Total price - $450 compared to $300 for a Wii U. Well worth the extra $150 for having an open system (nevermind that the Chromebox CPU is quite a bit faster). With a bit of effort it could be optimized to run on something cheaper like the Ouya.
As I said, 31 people (many of them experienced homebrewers from the Wii community) have the info so far, yet nobody has started working on this. In order for homebrew to be successful on a console, there needs to be a critical mass of interested, experienced developers to bootstrap it. I don't see that critical mass being there for the Wii U.
I don't care about whether piracy happens - if the WiiKeyU guys work it out, so be it, that's for Nintendo to deal with. I care whether it happens in association with my work. Honestly, most of the time I hear from random people using HBC, it's to run some warez launcher, and that's depressing. I don't want to end up in the situation where we have warez kiddies running pirated games using a Wii U mode exploit a year before a homebrew SDK finally becomes useful.
Doing it as a totally separate sandbox is kind of annoying for users, but from a security standpoint, it makes perfect sense.