Thank you, Datel, for all your precious hacker tools. You call them “videogame enhancement products”, which is probably as what most people see them, but I call them “hacker tools”, and that’s a compliment. You managed what few other people managed - you cloned optical media copy protections, produced innovative hard- and software, for a usually very fair amount of money. Your development guys are smart, sometimes maybe even too smart, and even while none of your tools are directly related to piracy, the big companies are less than amused by your products (which, again, is a compliment).
Sometimes your tools have been helpful in understanding a new platform, sometimes they are even “homebrew enable devices”. It is always good if a large diversity of products exists in this otherwise very mainstream-oriented mass market.
Now I totally understand that you are constantly searching for new opportunities in this very fast paced market. Now, hacking isn’t easy, even for such a clever company like you. Hacking also is always combined with the process of sharing knowledge, and working on top of other people’s findings. That’s part of the game.
The Wii has tight security. It features complete disc encryption, hashing and provides a “magical” security layer, which nobody understands. Thus it’s perfectly understandable that no solutions for “unlocking” a Wii exist, next to some irrelevant piracy-related hacks. That’s probably also the reason why there is no “Freeloader” for the Wii yet, as good things need their time to be developed, even for clever companies like you certainly are.
They don’t exist? Oh, well, what I’ve said somehow became obsolete by the developments of the last few months, where hacker teams not only started to understand the security schemes, but also found a lot of exploitable bugs in it. Now there is a brand new product from you. It is called “Wii FreeLoader“, and exploits a security problem which shouldn’t exist. Basically, Nintendo screwed up the RSA signature verification badly. RSA is a well-known algorithm, hasn’t been broken yet, and basically there is just one thing you can do wrong: Not comparing the complete result (after a RSA public decrypt). And Nintendo did both things wrong. They screwed this up so hard that you need to count it twice. Here is the deal: Of the 4k or 2k result of the RSA decrypted hash block, they don’t check the padding at all. They just compare the SHA1-hash. Now, C is a hard language, especially when dealing with strings and blocks of memory, and there are so many functions with different names, so it’s almost impossible to not get confused. (This was a joke, if you haven’t got it.) Even more a joke is to compare binary blocks of data using a string compare (namely strncmp) instead of a binary compare (like memcmp). Yes, you have read correctly: For verifiying the hash (which is the only thing they verify in the signature), they have chosen to use a function which stops on the first nullbyte - with a positive result. Out of the 160 bits of the SHA1-hash, up to 152 bits are thrown away. Hooray.
Exploiting that hole, once found, is easy: just modify your content until it’s hash matches with the hash stored in the signature. Instead of a 160bit brute force attack, things get considerably easier, depending on what the decrypted hash look like it - the sooner it has a zero, the less you need to brute force in your data’s hash.
But given the other problem (not comparing any other properties of the resulting hash block, like the ASN.1-padding, which is actually present), it’s even easier: You can change the encrypted signature until it’s decrypted version results into a hash which has a zero byte somewhere at the beginning. Then you don’t rely on any real signature. And it’s even easier: Thanks to RSA’s mathematical structure, an input of all-zero produce an output of all-zero. So, by just overwriting the complete signature with zeros, you gain a hash value which is also all-zero. Then it’s just a matter of modifying your payload until that hash starts with a zero, which is a 8bit (slightly more, as segher explained me once - probability calculus FTW) brute force. Doable, easily. That’s what the hack bushing presented on 24C3 was based on.
The bug can be fixed very easily, without any side effects - no official software relies on it. That was the reason why we (read: segher) decided that we don’t want to release an exploit based on that bug. It would be fixed, leaving us in a very ugly situation. Instead, we (read: segher and bushing) worked hard on providing an exploit which can not be fixed so easily, like a game exploit. They succeeded, providing you the “Twilight Hack”. We often explained our reasons for not disclosing the original bug, sometimes with success, often without.
In the meantime, xt5 re-found the bug, and released his “Trucha Signer“; a tool to re-sign discs with modified content. So far, while Nintendo probably was annoyed that “those hackers” again circumvented their security, they were probably not much worried about it - except for some homebrewers, there wasn’t much an impact. The hack didn’t helped piracy, and piracy was possible before because of their weak and (in older versions) backdoor’ed drive security.
But then there was the Wii Freeloader announcement. I’m sure that Datel, in spite of their otherwise very close relationship to the homebrew scene, did not depend on things being hacked there; they probably invented the hack separately in the past year, and the initial announcement date (2008-02-28) just coincides with the release of the trucha signer (2008-02-26) - after being silent on such a product before, probably because they were working so hard on hacking the Wii.
However, the Freeloader, which has been shown to use that exact hole, will likely provoke a reaction from Nintendo soon. They already fixed the bug on 2008-03-21, but only in the newest, not yet used kernel, or IOS (every application runs with a fixed IOS version, for backward compatibility). So far, no application uses the new IOS37, where the bug is fixed, but it shows that they are aware of this issue and fixed their code. They can of course still patch the old IOSs as well, they just need to retain compatibility. My guess is that their next update will contain such an update, making the Freeloader (and besides, our RSA-signature-based homebrew hacks, like a homebrew channel) unusable. (To make this clear, the Twilight Hack won’t be affected.)
Now, it’s of course uncertain if it was really the commercial Freeloader release which triggered the “fix” action, or if it was the release of the homebrew applications. Anyway, back to Datel. I know that you understand the implications of your devices very good. Your Freeloader disc contains the notice that they might not work with newer firmwares. Now, the question: Did you really thought that Nintendo won’t fix this issue soon, as soon as it is commercially exploited? Sure, $19.90 isn’t much for a Freeloader. But $19.90 is a lot for an unusable disc, which relied on a hack which was patches quicker than the actual delivery of the Freeloader discs. Was this how you expected things to work out? If not, what was? Gamers need to update their firmware, sooner or later, otherwise new games will refuse to run. Sure, there are ways to work around a permanent update, but do you really think it’s so unrealistic that new updates fail with those workarounds?
To make this clear: There is nothing against exploiting a vulnerability, if you can support that morally and legally. But this is, and that’s obvious, a vulnerability which WILL BE FIXED more or less immediately, leaving users with something which doesn’t work anymore. And while nobody can look into the future, I don’t think that a Nintendo patch is really such an inplausible reaction.
A lot of blackhat modchip makers were critized for bringing devices to the market and not supporting them in the long term. Not only that 2 weeks (or how long it will take for Nintendo to deliver an update) is not even “short term” - Datel, you are not a blackhat company. At least you didn’t used to.
![[Truth]](/data/avatars/l/37/37733.jpg?1351072321){kind=avatar}
