First of all, I'd like to make clear that I'm not attempting downgrading, I'm just curious about the process and its risks.

When system menu 4.2 first came off, when people were still having trouble with it because of their homebrews, there were some sollutions that pointed to downgrading back to system menu 4.1. Regardless of not being a good method for keeping your homebrews safe, I want to know where does its risks come from.

If you want to downgrade, it must be fakesigned, right? So you would go with Dop-Mii and installing system menu 4.1 back. I've never understood what was inside a system menu update. Of course, it comes with the specific version of it, and its IOS (IOS 60 in case of system menu 4.1), but does it come with anything else? Or anything else pertinent to an official upgrade procedure (like a boot2 upgrade) must be gotten separetely?

I was thinking, sm 4.2 have a higher version of IOS60 (as a stub). Installing sm 4.1 from Dop-Mii would overwrite the stub with former working revision, despite having a lower version number? Also, would it attempt to downgrade boot2 v4 that comes with sm 4.2, causing a brick for (newer) boot1 not tolerating fakesigned boot2?

Last question: an older boot1 (with the trucha bug still present) would accept a boot2 downgrade or it would brick like it does with the newer boot1? I know there's no reason to downgrade boot2, even Bootmii doesn't do that, I'm just curious about the way the console handles that.

Sorry for that zany questions. I just lack the proper protection and knowledge to test it all myself. Thanks in advance for any friend that help me out with these.

There is no tool available to downgrade boot2, but in theory it could be done with old boot1 by fakesigning the older version of boot2. It would only result in a brick with new boot1.

All that is needed for a particular System Menu to work is that the System Menu and its IOS are in full working condition (i.e. IOS is not stubbed, and neither are corrupted or missing).

The risk of downgrading comes from the fact that if something fails, your Wii is permanently bricked. The main reason downgrading is discouraged is because it is pointless and has a risk. However, if it was actually beneficial, the risk would be negated by the benefit, and downgrading would probably be encouraged. It is because it is pointless that it is discouraged AFAIK, more so than the danger (although it does also play a part).

Sorry if this doesn't answer your questions very well, but basically: Downgrading is completely idiotic. Don't do it ;)

Quote
Aobx
When system menu 4.2 first came off, when people were still having trouble with it because of their homebrews, there were some sollutions that pointed to downgrading back to system menu 4.1. Regardless of not being a good method for keeping your homebrews safe, I want to know where does its risks come from.

The risk of downgrading is as good as non existent, as long as the correct system menu IOS is installed and no higher system menu IOSes are left stubbed. The problem is that most people don't know that. Furthermore, "LU64+" wiis have new hardware, which is incapable of running old (pre October 23, 2008) IOSes. If an "LU64+" wii is downgraded to a system menu which uses an old IOS (3.3 and earlier), it will not be able to run the system menu IOS, and will therefore brick. Installing a newer IOS, such as IOS 60, in place of the the old system menu IOS would prevent this, but there is no reason to do so.

Aside from downgrading "LU64+" wiis, the most common issue with downgrading is leaving behind a stub system menu IOS. For example, if you downgrade from 4.0 or later to 3.2 (the "best" system menu for homebrew) IOS 50, which is used by system menu 3.4, will still be stubbed. If this downgraded wii is later updated with a game that has 3.4, it will brick. Although the stub IOS 50 could be deleted when downgrading, thereby preventing the problem, most people don't realize the need to do this.

Quote
Aobx
If you want to downgrade, it must be fakesigned, right? So you would go with Dop-Mii and installing system menu 4.1 back. I've never understood what was inside a system menu update. Of course, it comes with the specific version of it, and its IOS (IOS 60 in case of system menu 4.1), but does it come with anything else? Or anything else pertinent to an official upgrade procedure (like a boot2 upgrade) must be gotten separetely?

System updates include updates to the system channels, IOSes, and the system menu itself. Boot2, the EULA and anything else that is normally on a wii can be included as well. From a homebrew perspective, the only thing that matters at this time are the IOSes (at least if you don't care about the anti-Homebrew Channel thing and such).

Although anything except boot2 can be downgraded, usually only the system menu and some or all of the IOSes are downgraded (you don't want an old, unusable shop channel, do you?). To perform a downgrade, all contents to be downgraded must be installed individually. Most importantly, the system menu IOS must be installed before the system menu, or else the wii will brick. AnyRegion Changer can install system menu 3.2 and all appropriate IOSes automatically; however, it will not remove stub system menu IOSes. Unless you use AnyRegion Changer, downgrades should only be done manually (or better yet, not at all). Yes, Wankynono has released a downgrader application; however, you should only use it if you are in need of building materials.

Quote
Aobx
I was thinking, sm 4.2 have a higher version of IOS60 (as a stub). Installing sm 4.1 from Dop-Mii would overwrite the stub with former working revision, despite having a lower version number? Also, would it attempt to downgrade boot2 v4 that comes with sm 4.2, causing a brick for (newer) boot1 not tolerating fakesigned boot2?

Installing system menu 4.1 will not automatically install IOS 60; it must be done manually. Still, it can be done. Boot2 can not be downgraded.

Quote
Aobx
Last question: an older boot1 (with the trucha bug still present) would accept a boot2 downgrade or it would brick like it does with the newer boot1? I know there's no reason to downgrade boot2, even Bootmii doesn't do that, I'm just curious about the way the console handles that.

I think it would still brick. I remember reading on Hackmii that downgrading boot2 would definitely cause a brick, but perhaps there is a way to do it. Though even if it could be done, it would be a very risky process.

Thanks a lot for the answers. I'm really learning here. I think I know the risks envolving downgrading now.

Just one more question, please. I have Bootmii/boot2, and have learned it uses mini to do all its functions. However, when I boot HBC through Bootmii/boot2, my wiimote begins to function. Doesn't the bluetooth module have to do with IOSes? So, I suppose HBC through Bootmii isn't just starlet code, but power pc code too? In affirmative case, is that why Priiloader can do nothing when the system menu IOS is missing/corrupted/stubbed, since ppc can't start through the boot process and therefore hbc can't boot?

When the HBC is booted from BootMii, it loads IOS first

HBC is PPC code, it uses IOS, and MINI simply loads the correct one before loading HBC AFAIK.

Priiloader cannot function without System Menu IOS because it is also PPC code, and therefore needs IOS. It uses the System Menu IOS because it takes the place of the System Menu, and when during the Wii boot process, the System Menu's TMD is checked to find the IOS it requires, and that IOS is loaded. So because Priiloader is the first PPC code loaded (I think), it loads on the first IOS loaded (the System Menu IOS read from System Menu's TMD). Priiloader is not reliant on HBC in any way.

Thanks again for all your answers. I'm getting it now. So, without the system IOS, ppc is screwed up and a fix attempt can only be made by starlet code only, like mini.

Edit: Oh, I forgot to ask something related to the topic. Sorry if I'm asking too many questions. But I've come across a tutorial that says a official upgrade procedure to system menu 4.2 can be much less risky if you install boot2v4 separetely first. Then, you just upgrade normally through the "Wii System Update" in "Wii Settings". What's up with this procedure? Why boot2v4 installed first means less risk in the upgrade?



Edited 1 time(s). Last edit at 06/04/2010 05:58PM by Aobx.

lol, where did you read that? I'd say its complete crap. On hackmii, bushing said there was no reason to believe Team Twiizers boot2 update code (the only non-Ninty boot2 update code available, used in dop-Mii and for installing BootMii) was any safer than Nintys. According to him, the only real reason Ninty's code caused more bricks is because more people used it, so by laws of probability, more got bricked.

In saying that, once boot2v4 is installed, the update is fairly risk free (still potential for a brick, but less likely), but it isn't too risky to begin with. Perhaps there is some truth in it, but the only reason for it would be that TT's boot2 install code may be better than Ninty's, as Ninty probably never intended to update boot2 until BootMii came along and they decided to annoy people (nothing more really, doesn't prevent reinstalls or anything), so probably didn't test it too thoroughly, whereas TT DID test their code thoroughly, as it was going to be used for BootMii.

But overall, I'd say there really isn't a difference worth mentioning.

When searching for the risks of upgrading to system menu 4.2, I came across this tutorial: [gwht.wikidot.com]

That's where I saw the thing about boot2v4. I was curious to know why boot2v4 installed first by dop-mii would be better, since Nintendo would update with the same version of boot2, anyway. Thanks for clarifying that for me.

So, that brick thing is random (can happen by no apparent reason) or it involves something like power outage during update process?

I believe there must be a power outage at the wrong moment for it to occur, I don't think it can happen if there isn't a power outage. So provided you don't do it during a storm, you should be grand ;)

Thanks a lot, SifJar (and all the others who helped). My curiosity is satisfied for now! Very nice of you to share your knowledge with me.

If you have more questions don't hesitate to ask. We may be able to answer some of them :)

whats pretty funny i had a 4.2 wii till i downgradeed to 3.2 i am not encouarging but if you want to go to www.youtube.com and search wii 4.2 downgrades i screw up a couple time but it did not brick my wii ps i was probly lucky so do at your own risk i do not take responsible for your wii bricking

If you haven't already, delete IOS 50 and IOS 60 immediately. If you don't and later update with a game that has 3.4, 4.0, or 4.1, your wii will fully brick. This is when the bricks most frequently happen, not when actually downgrading.

Quote
supermegamanxl
whats pretty funny i had a 4.2 wii till i downgradeed to 3.2 i am not encouarging but if you want to go to www.youtube.com and search wii 4.2 downgrades i screw up a couple time but it did not brick my wii ps i was probly lucky so do at your own risk i do not take responsible for your wii bricking

You're an idiot IMO.
1. Never follow YouTube videos for Wii-related stuff.
2. Downgrading is idiotic and pointless.

Do not encourage downgrading or following Wii YouTube video "tutorials".

What SifJar said.

Since you're talking about tutorials, may I ask something about Priiloader? The official website points that you just need a trucha signed and ES_identify patched IOS36. However, I came across a tutorial telling to also trucha sign the system IOS for 4.0 ~ 4.2. It even recommended upgrading to at least system menu 4.0, if you want to installer Priiloader. Does any of this make sense? Why would Priiloader need trucha on the system IOS? To run fakesigned codes?

Also, since Trucha Bug Restorer can handle all these patches on IOS36, I'm curious how the process is done. TBR relies on the downgrade of IOS15 to an official former version which had the trucha bug by default. Understandable, but how TBR can downgrade IOS15 without using a IOS with fakesigning?

Priiloader no longer needs Trucha Bug on System Menu IOS. In fact, it never needed Trucha Bug afaik. It used to need ES_Identify (actually called ES_DiVerify, but commonly referred to as either) because to load System Menu it identified as System Menu, making use of ES_DiVerify to do so. But now I believe it works without any patch on System Menu IOS.

However, if you wish to change the System Menu IOS (which priiloader allows you to do), the IOS you choose to use instead must have ES_DiVerify. The true System Menu IOS never needs it though AFAIK.

EDIT: As for your question on TBR, I'm not completely sure, but I think its something like this: When you are installing a new title (IOS, channel, System Menu, whatever), a temporary folder is created with its contents in it. However, this folder is completely unprotected and you can freely write to the folder without any exploit. So TBR starts installing the newest IOS15, overwrites the contents with the older revision of IOS15 and the old version gets installed.

This probably isn't the best explanation, I'll try and find WiiPower's (dev of TBR) explanation, which is much better.

EDIT: OK, couldn't find the exact explanation I was looking for, but looking at the source explained it fairly well.

Here's what happens:

1. It starts to install the newer revision of IOS15 (which can be the same as the installed revision, and the system will allow it)
2. System moves contents of title (IOS15) to a folder on NAND called "/tmp", after it passes Signature checks
3. Without any exploit, PPC code has full access to this folder. So TBR deletes the TMD from that folder
4. TBR makes a new TMD in the same folder with the revision "0"
5. System completes installation, installing the modified TMD, as Signature is not checked again once files are copied to "/tmp"
6. IOS15 is now at revision 0 as far as system is concerned, so TBR is "allowed" to install an older revision of IOS15 without any exploit

This is a fairly old bug (it was used in a DVDX installation workaround as far back as System Menu 3.4), and Nintendo still haven't fixed it. Apparently there are about half a dozen things they could do to stop it working.



Edited 2 time(s). Last edit at 06/05/2010 08:14PM by SifJar.

Don't worry about not finding the exact explanation, SifJar. I could understand from the one you found. Thanks a lot.

So, Priiloader just need IOS36 with trucha and ES_DiVerify enabled, but as requisites for its installation, not for it to function, right? In theory, could be another IOS with the same patches, too? I can't see why IOS36 specifically is the one for Priiloader.

Yeah any IOS could be used, IOS36 is just the default one used for most homebrew. Or 249 (i.e. cIOS), which is also an option in Priiloader installer. But once the installer is finished, you can install an unpatched version of IOS36 if you desire and have NO patched IOS, and Priiloader will work fine, and I think that is actually the recommendation from the devs.