Curiosity about downgrading

Interesting learning about IOSes. Reading the forum and the main page, I came across something called "IOS reload". Some applications reference this. What does it mean? If you load an IOS, why would you load it again?

Reloading IOS means loading another IOS. The function call IOS_ReloadIOS(35) would load IOS35.

Oh, it means another IOS. I thought it would be the same IOS. But why the option "block IOS reload" in some apps? What's the problem with an IOS reloading in the process?

Quote
Aobx
Oh, it means another IOS. I thought it would be the same IOS. But why the option "block IOS reload" in some apps? What's the problem with an IOS reloading in the process?

Only time I've seen this is in "backup" launchers, because IOS reloads in games cause problems for them. I haven't seen anything supported here with any mention of blocking IOS reloading. If you have, please point me to it. But it should be mentioned, there would be no point in having a program "blocking IOS reloading", because the program controls whether to reload the IOS or not...

In fact, I ask these things by browsing tutorials and seeing the advices like "never downgrade", "Priiloader doesn't solve full brick", "Block IOS reload"... I don't have any specific app in mind. It's just a matter of curiosity. I would like to know why reload even reload an IOS. Don't you have everything you need in a single IOS, like trucha bug and ES_DiVerify? I thought "IOS reload" was some kind of defect that made the IOS reload when you didn't want to, making the app stop working, so you would try to block it. But it doesn't seem that way.

Anyway, I found out by sysCheck there are some other patches, like flash access, nand access and boot2 access. What do they do? Isn't ES_DiVerify already a kind of "nand access", since it can write and erase titles?

You would reload an IOS to get the specific features of a different IOS. For example, the early IOS, like IOS9 and stuff have fewer features than newer ones like IOS57 or whatever. Different IOS are used by different games etc. officially, and for homebrew purposes, IOS reloading is used because its highly possible that the IOS loaded by default won't contain the bugs you need. For example, a particular app may require, say IOS37 (Riivolution does for example I think), but all apps are loaded with IOS36 by default, so it'll reload to the required IOS.

As for the other patches: NAND access patch (aka NAND Permisssions Patch) gives FULL NAND access, allowing you to read, write and delete ANY file, whereas with ES_DiVerify, you can only do what the System Menu can do AFAIK. I think flash access is the same as NAND access (?). As for boot2 access...no idea. Perhaps it means the IOS can be used to update boot2?

BTW, I'm not 100% sure about all these patches, I'm not a developer, so I don't fully know what is needed to do what.



Edited 1 time(s). Last edit at 06/06/2010 11:24PM by SifJar.

Thanks again, SifJar. Finally, I understand a reason to use IOS reload. The other patches really caught my attention, since I've never found an app that required one of those three. Even Bootmii doesn't mention anything about "IOS with boot2 access". I hope some developer will bother giving some explanations, sometime.

One situation where reloading IOS is a bad thing is Preloader. If Preloader reloades the IOS before launching the system menu (which it always does), the system menu can't load unless its IOS has ES_Identify. However, if the system menu IOS is not reloaded, the bug is not necessary. This is why Priiloader does not require ES_Identify unless it is set to reload the IOS.

As for Bootmii, Team Twiizers probably figured out a way to make it work that nobody else knows about.

Thanks for giving another example, jbc. But I thought Preloader was set by default to use the system IOS, not reloading another one. Guess only Priiloader does this?

Also, about Priiloader and the bricks, I read this in Wiibrew Wiki about what the app can do: "Save wii from banner & other kind of bricks that aren't ios/boot2/nand corruption related". Does that "ios corruption" means any IOS? I think the only IOS that cannot be corrupted is the one used by Priiloader to boot itself. From all that stuff we talked about, Priiloader need its booting IOS to start the Power PC and then function properly. So, if I corrupted a non-related IOS, like IOS15, for example. Would it prevent Priiloader in any way? Better yet, it would even cause a brick? Or the error checking from Wii doesn't check titles that are not currently being used or shown in any way?

Preloader does by default launch the system menu on its usual IOS; however, it always reloades this IOS before launching the system menu. By default, Priiloader does not reload the IOS; however, you can set it to reload any IOS, including the system menu IOS.

Priiloader can only protect from banner bricks and the like. If you install themes or custom channels and it bricks the wii, Priiloader will still work, but is absolutely useless in recovering from any other kind of brick, including IOS issues.

A wii can not be bricked by an IOS issue that does not affect the system menu IOS. Missing or damaged IOSes other than the system menu IOS can cause other issues, but they can always be fixed. If the system menu IOS is missing or corrupted, the wii fill fully brick. Aside from Bootmii installed as boot2, there is no application that can protect from this sort of brick.

Pretty curious Preloader reloading the system menu IOS, since Priiloader doesn't need to do that to fully work. I guess the Preloader code wasn't honed enough? Or maybe there's a benifit in this. Anyway, I don't know if I've understood perfectly, but you say Preloader needs an IOS with ES_DiVerify even if it's the system menu IOS? In that case, why would the system IOS need the patch for higher privilegies if it's the one which originally handles the system menu boot?

About the brick protection, it's like I suspected. A nice tool, just to give a little more security, though not for relying if you are going to mess around with your Wii. Thanks for confirming.

Quote
Aobx
Pretty curious Preloader reloading the system menu IOS, since Priiloader doesn't need to do that to fully work. I guess the Preloader code wasn't honed enough? Or maybe there's a benifit in this. Anyway, I don't know if I've understood perfectly, but you say Preloader needs an IOS with ES_DiVerify even if it's the system menu IOS? In that case, why would the system IOS need the patch for higher privilegies if it's the one which originally handles the system menu boot?

About the brick protection, it's like I suspected. A nice tool, just to give a little more security, though not for relying if you are going to mess around with your Wii. Thanks for confirming.

I think crediar made it reload the IOS by default before loading SM in case you had changed it to another IOS, whereas Daco (main priiloader dev) decided to detect whether System Menu IOS was being used or not before reloading.

As for it needing ES_DiVerify, I believe its probably something to do with the fact that when the IOS is loaded by boot2 (last stage in boot process), its probably given System Menu privileges without needing to identify, whereas once it is reloaded, that is lost and must be regained via ES_DiVerify. However, this is a COMPLETE guess, it could be way off, but it sounds believable :P

The BootMii installation might have to do with write-enabling (and enabling) /dev/flash, AHBPROT changing, or ImportBoot with fakesigned stuff; I don't know which.

Quote
SifJar
Its probably something to do with the fact that when the IOS is loaded by boot2 (last stage in boot process), its probably given System Menu privileges without needing to identify, whereas once it is reloaded, that is lost and must be regained via ES_DiVerify. However, this is a COMPLETE guess, it could be way off, but it sounds believable :P

It's quite plausible though. Pretty hard figuring it otherwise. If there's a need for ES_DiVerify after reload, something happened that didn't give higher privilegies to the sm IOS, so it's logical that a former process is responsible for this. I hope someone will shine a light on this, later.

Was just reading up on stuff at the Wiibrew wiki, and it looks like boot2 can't be downgraded on any Wii. I said on the previous page I guessed it probably could, but as it says on [wiibrew.org], :

Quote

boot1 will detect an attempt to downgrade boot2, comparing the version number of the TMD in flash against a value store in the serial EEPROM; if the value in flash is less than that in EEPROM, it will fail to boot with error 10.

So EEPROM contains newest version of boot2 installed, and if the boot2 installed is lower, it won't boot.

Interesting. But as we talked before, nothing great comes from downgrading or upgrading boot2, since the vulnerabilities we'd like to find would be in the boot1. Nice having a confirmation though.

Yeah just figured as I found it I'd post it.

I was trying to find stuff about boot2, so I could work out if it does load the System Menu IOS with higher permissions, but it appears there isn't a WiiBrew page on boot2, only boot0 and boot1 for some reason.

I was thinking as well, if boot2 gives the IOS higher permissions, and these permissions are lost when e.g. loading a game, but regained when exiting back to System Menu, does this mean boot2 is loaded when you exit back to System Menu? (Aimed at someone other than you Aobx, no offence :P)

In that case, someone should be able to modify the value in EEPROM to allow boot2 to be downgraded. Of course, downgrading boot2 remains a bad idea.

If I'm not mistaken, boot2 is not loaded when returning to the system menu after running a wii game. However, boot2 does appear to be loaded when powering off the wii after running a gamecube game, as when Bootmii is installed as boot2, it loades at that time. I believe I remember reading that when returning to the system menu from a game, the game's IOS loades the system menu IOS, which then loades the system menu. Unfortunately, after a brief search I was unable to find anything discussing this.

Just thinking, you cannot modify the boot1 EEPROM, since it would be detected by the boot0 hash check and the system would halt. But why can't you modify boot0, since nothing checks it? Is boot0 stored in a kind of memory that isn't erasable?

Anyway, wouldn't be the best way to create a vulnerability. Seems not easy to erase and rewrite in a EEPROM. Not the kind of thing everyone can do.

Quote
jbc007
In that case, someone should be able to modify the value in EEPROM to allow boot2 to be downgraded. Of course, downgrading boot2 remains a bad idea.

If I'm not mistaken, boot2 is not loaded when returning to the system menu after running a wii game. However, boot2 does appear to be loaded when powering off the wii after running a gamecube game, as when Bootmii is installed as boot2, it loades at that time. I believe I remember reading that when returning to the system menu from a game, the game's IOS loades the system menu IOS, which then loades the system menu. Unfortunately, after a brief search I was unable to find anything discussing this.

Well, I thought that too, but that doesn't explain how System Menu permissions are regained. ES_DiVerify is broken in all current IOS, so they cannot obtain System Menu permissions...My guess is it has to be given somehow when returning from a game, boot2 was a guess. Games can't identify as System Menu, so unless System Menu has some way of doing it without ES_DiVerify, I don't see how its done. And if it can, what was the point in ES_DiVerify in the first place? In fact, what was it there for anyway, as obviously it was unnecessary as they could break it without stopping other things working...