It's excellent, it'll be interesting to see what difference the progress on the ps3 hardware acceleration under linux and the ability to run homebrew on the wii makes.
I think I'll wait. They claim to have captured keys from ram, but those would be decryption keys. Did nintendo use an algorithm that used the same key for encrypting and decrypting or one that could be derived easily? Or is there something more... I'm sure Nintendo will block access to any exploit as soon as it's released anyway.
I think I have read that the disc images are encrypted (in addition to the scrambling) with an (until now?) unidentified algorithm and that the executables are signed with RSA. I can not confirm this. I would however not be surprised if the executables in the disc image are encrypted (symmetrically) with session keys as well. So, yeah, the disc images and/or binaries are probably encrypted using symmetric crypto. Which is different from the asymmetric RSA crypto used for code authentication (signing). I can imagine that they could identify some of the crypto algorithms used by peeking in memory (128bit AES in CBC mode and/or RC4 maybe?), as well as symmetric keys. With the right key(s) one could patch the i.e. the Lego Star Wars disc image, and it would still decrypt right. This however doesn't by itself bypass any RSA signing checks, so I am kind of wondering how they did that. My guess is that they didn't patch any signed code at all, but exploited some other weakness to do this. This is just speculation of course. Maybe the Wii has some file format vulnerabilties, like those exploited in the libTIFF exploits for the PSP, that could be used to run arbitrary code... but they still needed to figure out the disc image encryption to patch i.e. the Lego Star Wars disc with such code... Exciting times indeed, and, yeah, on the PS3 too
we just have to wait if they release some SDK to start massive homebrew for the wii, or at least the moethod to run homebrew, and let's hope that can not be patched through any firmware update...
the official Wii SDK isn't too technically different from the GC SDK at all - with the exception of using the Wii remote API and the Wifi , the Wii specific bits in general. CPU, GPU and audio are all the same.
He's right about that, but I meant the wii exlucisve things that gc does not have, such as wii bios stuff(accesing the bios while a program just like in the games when pressing home button, etc), wifi, and wiimote. the GPU should differ a bit from the gamecube due to its hollywood, but they are quite the same architecture right?
the home key is not a bios thing. It's just something implemented in all games . GPU and CPU are all a bit upgraded, but the major difference lies in the fact that there is a fat "IO bridge" which handles communication with USB, Wifi, (partially) bluetooth, DVD and some minor stuff. It also handles encryption. It can be seen as some kind of hypervisor. It's actually an ARM processor, running in the DDR-memory space in an area where the CPU cannot access it (neither in GC nor in WII mode). However, due do the "tweezer"-attack, it's possible to dump that memory, including the static decryption keys. Yes, some keys (NAND, private) are unique, but the DVD keys (for example) of course are not. That alone doesn't make the console insecure - stuff is signed, after all. If there would be ...
Wow, didn't know that you are a member on assemblergames. I'll take the chance and shout out a big "Thank You" for your work on the Wii/Gamecube/Xbox etc. I really enjoyed your CCC congress presentations and learned a lot from them. Do you plan to release some documentation about the Wii's inner workings in the near future?
ConsoleFun: your speculations are mostly correct. I must really say that I mostly watched the show, so I cannot really decide anything for the "project". Some members want to work on an exploit which isn't possible to patch so easily that we still want more time. I'm sorry that I can't discuss details of the exploit so far. It was neither my finding, nor my decision on how to keep on with releasing details. I can definitely understand them though, as the current hole could be closed without major effort from Nintendo's side, whereas possible future exploit could not. And there is still a lot of things we haven't understood yet. It's just not ready for a release. That doesn't mean you couldn't start hacking today; the most important thing would be doing the memory dump exploit on your wii, to extract your personal keys and the firmware (=arm code). Then go hunting for bugs in it. The whole disc image is hashed in a multi-level hash tree, btw. This is a console's first (not sure about PS3, though), and is remarkable.
so you guys found two exploits? The first and the current could be patched easily and the "future one" not? Man we look forward to know any more details about it, also if you need help, testing or w/e count on me for feedback
Thx tmbinc, I appreciate your feedback. Sorry for this late reply btw - I have been out of the loop for a week.... The top hash is stored encrypted (symmetrically) on the disc too then (?), and decrypted by the wii before it verifies the integrity of the tree (?). Thinking about it, I can see how RSA could be used to sign the hash too, like i.e. the 360's 2BL, but then I am puzzled how your mates managed to patch the image.... Cheers! CF
hi, and what about firmware (512MB) encryption ? is it also AES 128 CBC ?and if it is, can it be decrypted with released AES key ? and a last question, which interets me since a long time; what contains Macronix chip (1bl?) ? thank's have a nice day
zeewox: The macronix chip contains just the gamecube compatibility font. The "1bl" is called (ok, we call it) "boot0", and resides probably somewhere in the hollywood. the nand flash is encrypted with the "nand key", which is different for each console. However, not all code is encrypted with that, just the filesystem contents. boot1 and boot2 are not; boot1 is encrypted with the boot0 key, and boot2 is encrypted with the common-key. Both of them are static.