A few months ago we released a small, hidden channel called “DVDX” which essentially allowed homebrew to read DVDs on any Wii console without requiring hardware modifications. Since that release some things that you are probably all aware of have happened: Nintendo released an update that blocks the installation of fake-signed titles like The Homebrew Channel or said DVDX installer and we published a workaround for the Homebrew Channel one day later.

However, we did neither have the time nor the intention to release a similar workaround for the DVDX installer since there certainly are better solutions to this problem and because we thought we would be able to release BootMii very soon. This was apparently not the case because we are still working on BootMii today. The only solution to get DVDX installed was to use questionable methods that are normally only used by pirates and definitely not recommended by us or, given that you were lucky, to use comex’ installer while it still worked.

There still seems to be a demand for a working installer though and I therefore decided to port our method of installing The Homebrew Channel to the DVDX installer. While doing this the “advanced” and the “patchmii” installation method had to be removed. They wouldn’t be of any use anyways since there is no sane possibility to install a hacked IOS on an updated Wii. You can therefore only use this installer if you have a Wii without hardware modifications because it will force libdi to always use the so-called DVD video mode which is not supported by many modchips. I’m afraid that you’ll have to wait for BootMii if you have a modchip without DVD support and want homebrew to be able to read your DVDs and if you did not install a hacked IOS and DVDX previously.
Please note that this only is a temporary solution that was only released due to the high demand. It will be replaced with a better solution once BootMii is available.

Just download dvdx34.zip and extract it to your SD card. You should then be able to launch the installer from the Homebrew Channel.

From the checker statistics, we’re seeing about 10% of Wiis with the new boot1 (all newer ones). What will happen to those new Wiis that have it?

At first, BootMii will not be compatible with those Wiis. A modified boot2 will not run on them, period. However, there is a way of accomplishing some of BootMii’s goals on those Wiis, by installing BootMii as the System Menu’s IOS, or as an entirely separate IOS, for example. There are pros and cons to these options, and they’re not as good as installing BootMii as boot2, but they are possibilities worth exploring. We won’t support them when BootMii first comes out (lest we delay it even further), but one or more of them might come in the future.


Since people seem to love to compare Preloader to BootMii, I’m going to throw it in the comparison as well. Here’s a table comparing the following attributes of the four solutions:

Brick resistance: chances of it helping you if you brick your Wii
Update resistance: chances of surviving a Nintendo update
Update safety: chances of causing a brick when the Wii is updated in the future
Code execution: what kinds of code you can actually run with it
Complexity: how many things can go wrong while using it
Low-level install: how easy it is to install using a hardware programmer
Compatible with return: does “Return to Wii Menu” run it?
Note that the metrics on the table are mostly relative to one another. “Low” doesn’t mean crap, it means lower than “Medium” or “High”.

BootMii as (separate) IOS is a special case. It would be useful for people who want to use software designed to run under BootMii (that is, using custom ARM code, not IOS) starting from code under IOS, without regard for having it run on boot or brick-safety. This is basically a completely safe option, but also the least powerful one.

Brick resistance: BootMii as boot2 has high brick resistance because it _only_ relies on boot1 and boot2, which are in a reserved area of NAND. BootMii-boot2 will run even if your entire NAND Filesystem is hosed, and only requires the first megabyte or so of NAND to be intact (containing boot1 and boot2). BootMii as IOS does quite a bit worse, because it does require a sane NAND Filesystem, and also a sane enough structure that the original boot2 won’t choke on it. However, it doesn’t require any PPC code to run, nor does it run any additional drivers (for example, WC24), so some failure modes related to system files are eliminated. Preloader also depends on the System Menu IOS and runs on the PPC side, so it only saves you from brick problems that affect the System Menu (although these are pretty popular, so it’s still significant) - it won’t help for anything affecting IOS. Of note is that BootMii-boot2 doesn’t require anything on NAND that is dependent on your NAND keys, so the parts of NAND that are required are exactly the same (at least among Wiis with the same boot1 version).

Update resistance: BootMii as boot2 is likely to survive updates, because it’ll only be overwritten if boot2 is updated. Nintendo has never done that so far. BootMii as IOS would be overwritten with a System Menu IOS update, and Preloader would be overwritten with a System Menu update, both of which happen often and are pretty likely. Interestingly, BootMii as a regular IOS is more likely to survive, simply because it would be installed alongside existing software and won’t be overwritten by any update. None of the options will survive a targeted attack - this is just a measure of how likely a “normal” update will remove them.

Update safety: BootMii as boot2 is essentially 100% safe. This is because boot1 can’t be changed, so the only thing that will affect it is a boot2 update. This would remove it, but that wouldn’t cause a brick. The only way an update could brick a Wii with BootMii as boot2 would be due to a deliberate sabotage attempt by Nintendo (”if we detect bootmii, deliberately brick that Wii”), which won’t happen because they would likely be held legally liable for the damage. BootMii as an IOS, on the other hand, could cause a bad brick if boot2 is updated to check the signature of the installed System Menu IOS. Boot2 hasn’t been updated yet, so this gives BootMii as SysMenu IOS a slightly better chance than Preloader, which would suffer from the same issue if either the System Menu IOS or boot2 are updated to perform this check. Since BootMii as a separate IOS doesn’t participate in the boot process, it is obviously 100% safe (unless Nintendo does something stupid like crash if any unsigned software is found, but that’s not going to happen because it would cause legal trouble as well).

Code execution: This is pretty simple. BootMii lets you run ARM (Starlet) code, which gives you full control (including the possibility of running PPC code). Preloader just lets you run PPC code under IOS.

Complexity: BootMii-boot2 is very simple. It only depends (obviously) on boot1 and