
- #Bootmii as boot2 or ios install#
- #Bootmii as boot2 or ios drivers#
- #Bootmii as boot2 or ios update#
- #Bootmii as boot2 or ios software#
#Bootmii as boot2 or ios software#
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).Ĭode execution: This is pretty simple. 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. 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.
#Bootmii as boot2 or ios update#
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. This would remove it, but that wouldn’t cause a brick. This is because boot1 can’t be changed, so the only thing that will affect it is a boot2 update. Update safety: BootMii as boot2 is essentially 100% safe. None of the options will survive a targeted attack – this is just a measure of how likely a “normal” update will remove them. 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. 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. Update resistance: BootMii as boot2 is likely to survive updates, because it’ll only be overwritten if boot2 is updated. 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). 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.
#Bootmii as boot2 or ios drivers#
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. 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. 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). This is basically a completely safe option, but also the least powerful one.īrick resistance: BootMii as boot2 has high brick resistance because it _only_ relies on boot1 and boot2, which are in a reserved area of NAND. 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. “Low” doesn’t mean crap, it means lower than “Medium” or “High”.īootMii as (separate) IOS is a special case. Note that the metrics on the table are mostly relative to one another. Compatible with return: does “Return to Wii Menu” run it?.
#Bootmii as boot2 or ios install#


