|
July 10th, 2008, 23:52 Posted By: wraggster
News from the great wii hacker Bushing:
The past few weeks has seen increased interest in hacking IOS, the “firmware” of the Wii — I think many people are under the mistaken assumption that I disapprove of this. On the contrary — I think it’s an exciting direction, but I want to make sure people have realistic expectations.
Limitations: IOS is responsible for most of the things you *don’t* see when using your Wii. It can’t do graphics and probably cannot do sound. We do not yet know if it’s possible to read the GameCube pads or the front buttons (power, reset). Currently, all we have is eight GPIO pins that the thing uses for bootup diagnostics. Marcan has done some great work in this area, including mounting an LCD to 6 of those pins, and most recently he was able to patch IOS to redirect its (sparse) debug output over USBGecko — if you don’t already have one, now would be a good time to go out and get one if you’re interested in participating.
Capabilities: IOS currently manages all of the hardware that is unique to the Wii (as compared to the GameCube) — so, NAND Flash, SD card slot, WiFi, USB (at a low level — think libusb). It has a full-fledged virtual machine that is capable of running a simple, JavaScript-like language and carrying on HTTP, SSL and SMTP communications — this is WiiConnect24, and it’s barely used by Nintendo.
Shared resources: Both the PPC and Starlet (ARM core) share both areas of memory; IOS could probably be used to patch PPC code (if someone sat down and wrote the code to make that happen). Both can control the EXI bus. They share the USB busses (IOS has drivers for USB HID devices and the USB Ethernet adapter; the PPC has the Bluetooth module driver).
Requirements: IOS does a tremendous amount of poking at management registers to make the Wii work; replacing it entirely (while still playing games) is probably infeasible and not really worth the effort. Instead, we’ll probably be patching it, extending it, and occasionally writing special-purpose replacements for limited, specific purposes (like brick recovery)
Piracy: We are not making a soft-mod or an isoloader. Most of the anti-DVDR protection on the Wii is done in hardware; assuming Nintendo designed it correctly, we will not be able to bypass this in software. Homebrew has always been our goal, and we have no intention of actively pursuing anything that would violate the DMCA. (That having been said, I no longer believe that Nintendo can tell the difference between what we do and what pirates can do; also, Nintendo and BroadOn have already made some pretty horrible mistakes which made VC piracy much easier to pull off.)
Safety: This is a big, poorly-understood one. There are some very specific ways you can **** yourself over by hacking on IOS:
Disrupt the boot path. If you modify 1-2, 1-30 or boot2, you can easily get into a situation that will prevent you from recovering without hardware access to the NAND flash.
Corrupt support files needed by the system menu. When it starts up, it looks at the other titles installed in NAND to build the main Channel display; this has been responsible for several bricks as people have experimented with banners. These mishaps are sometimes easier to recover from than actual code bugs.
Tamper with the unknown. We don’t fully understand BC; it many ways, it is similar to boot1. It loads boot2. It seems to be run by the System Menu when you run a GameCube game. I’m guessing that the System Menu runs BC which runs boot2 which runs MIOS which runs your GameCube game; if this is correct, then modifying boot2 could prevent BC from loading it. If BC is used elsewhere, this could have bad consequences. Be Careful, or better yet — figure it out kthx
Corrupt the filesystem. IOS is the driver that maintains the NAND filesystem; if it discovers problems, its first reaction seems to be to completely wipe it and start over, and there’s no recovery from that.
Redundancy: Now that I’m done scaring you, there is some good news. The Wii can hold about 200+ different versions of IOS, and it will only load a version of IOS when required to by a TMD or an explicit ES call from a homebrew app. This means that it is possible — and mostly safe! — to experiment with a nonexistant version of IOS — say, IOS5 or IOS16. You can even patch existing versions of IOS, as long as you make sure you have a way to execute code if that IOS breaks. This also produces a unique challenge — anything that requires fundamental changes to the way that state is kept on the system means that you will have to modify every single version of IOS to get it to work — the best example of this would be adding in support for bigger NAND flash chips. There is not yet a safe way to do this, because we do not yet have a way to recover from a mishap if you make a mistake in patching all versions of IOS.
Expect to see more on this in the future; Marcan has already written a great article about our near-term plans, if you can read Spanish. I will be releasing some code in the near future to make it easier to experiment with IOS, but be warned that this would be a very poor choice for a first programming project.
Please try to keep all discussion at a technical level; I’m not in the mood for arguments, but I will try to answer any thoughtful questions you may have.
http://hackmii.com/2008/07/ios-hax/
For more information and downloads, click here!
 There are 2 comments - Join In and Discuss Here
|
|
