Hector Martin

People love to get all excited about leaks of official SDKs or code... but really, rarely are they all that amazing. Early on in development of homebrew for a console, they can help make things move much faster, but at the expense of legally tainting everything they touch.

This late in the game, though? Some of my reverse engineered documentation is *more accurate* than the official docs. Because I document what the hardware *does*, not what they *intended* it to do.

So for example, the leaked docs talk about registers existing in certain memory windows, but don't document all the mirrors that I discovered back when I did an exhaustive analysis of the Starlet 32-bit address space.

Now, certainly, leaks like this do clarify a lot of the long tail of things. "Oooh, so *that's* what that register did!". But those things we didn't know are largely because they weren't important. If they were, we would have figured them out.

And it's always fun to see the official names for things. Remember the STM release exploit? That bug is in the leaked code. The real code has the same structure as my decompiled version, and the bug is exactly what I thought (missing return statement), but the names differ.

And yes, the RSA sigcheck really was a strncmp call. But anyway, what is actually useful in a leak like this? Not much, really. Nevermind that you can't legally use any of it, it's not really adding much practical information.

The only thing that comes to mind is that having the PLL register documentation (which is always one of the most nigh impossible things to reverse engineer black box) might allow someone to try to overclock a Wii. Maybe. Not sure if it's possible.

Really, these leaks are mostly just fun because you get to *see* what they were thinking, and also things that got dropped. Did you know that the Wii was supposed to support using Wiimotes with GameCube software? There is supposedly a hardware SI emulator in the Hollywood.