Hacking cboot2: Installing IOS254 without downgrades nor wads

[matsurisan]

I've gathered this information so far:
- New wiis (mine) do not allow for installing IOSses without reverting IOS first.
- Reverting

 

[FenrirWolf]

Try using the wad manager that came bundled with cboot2. Or you could use Wad Manager 1.5 since it has the option to not reload IOS.

Or you could use the Trucha Bug Restorer since it's a bit easier.

 

[s3phir0th115]

The installer for cIOS rev 14 and above should support what you're asking for. You just need to make sure you tell it to not reload the IOS, and it should work for you.

 

[matsurisan]

The installer for cIOS rev 14 and above should support what you're asking for. You just need to make sure you tell it to not reload the IOS, and it should work for you.

Sadly, latest version found in http://gbatemp.net/index.php?showtopic=190786

Does fail with -1053, which means even if I do not choose to reload IOS, it still has reloaded it during libogc init, effectivelly screwing the job cboot2 done.

 

[matsurisan]

Somebody would have to rebuild the cios installer adding the following:

s32 __IOS_LoadStartupIOS()
{
ÂÂÂÂreturn 0;
}

 

[matsurisan]

Since r15 doesn't work, I tried r14.

-1035 too.

Needs to be rebuilt with the patch I did paste earlier.

 

[tueidj]

Basically, the IOS installer has to:
- Not automatically load an IOS on startup (as that overwrites the nice work cboot2 done to load it adding bugs on the fly)
- Be able to select target IOS id (so that I can write 254 and only 254)
- Be nicely patches-based using the original IOSs as sources, not needing me to provide an illegal-to-redistribute pre-made IOS with ninty code inside of it.

Why exactly do you want to install a cIOS to IOS 254? If it's just for homebrew purposes that's fine, but you might want to pick a different number if you want to use it to play games...

 

[matsurisan]

Basically, the IOS installer has to:
- Not automatically load an IOS on startup (as that overwrites the nice work cboot2 done to load it adding bugs on the fly)
- Be able to select target IOS id (so that I can write 254 and only 254)
- Be nicely patches-based using the original IOSs as sources, not needing me to provide an illegal-to-redistribute pre-made IOS with ninty code inside of it.

Why exactly do you want to install a cIOS to IOS 254? If it's just for homebrew purposes that's fine, but you might want to pick a different number if you want to use it to play games...

Let's just say I meant >200 and my short term memory is too bad to say a correct number :/

I ended up using Trucha Bug Restorer. That program does _not_ reload IOS on startup, so it can be used from cboot2 just fine, and then the TARGET IOS # is clearly selectable.

 

[smf]

The question here is: What IOS >200 installer can I use which will work when chained from cboot2?
Basically, the IOS installer has to:
- Not automatically load an IOS on startup (as that overwrites the nice work cboot2 done to load it adding bugs on the fly)
- Be able to select target IOS id (so that I can write 254 and only 254)
- Be nicely patches-based using the original IOSs as sources, not needing me to provide an illegal-to-redistribute pre-made IOS with ninty code inside of it.

You can use any title deleter. Just don't delete the wrong IOS.
I'm intrigued why you want to distribute anything.

You can't legally distribute cboot2 or bootmii, the output from cboot2 installer includes nintendo code & the installer requires a nintendo wad to run. HBC/bootmii can't be distributed by anyone but bootmii.org

 

[s3phir0th115]

The installer for cIOS rev 14 and above should support what you're asking for. You just need to make sure you tell it to not reload the IOS, and it should work for you.

Sadly, latest version found in http://gbatemp.net/index.php?showtopic=190786

Does fail with -1053, which means even if I do not choose to reload IOS, it still has reloaded it during libogc init, effectivelly screwing the job cboot2 done.

Ahh. Well, if that's the case, I would try getting making an IOS wad with NUSD, then trucha patching it with wwpacker, and use that IOS once installed to install the custom IOS.

 

[matsurisan]

Ended up making it work (loading a backup!)

The super-clean (cleanest to my knownledge) procedure to get a 4.2 new wii to work with backups/undubs/etc:
1. install bootmii/hbc
2. use bootmii to backup NAND (can never be too safe). Remove the SD and copy that backup to computer/safe place.
3. use cboot2 (first installer, then loading it) to boot latest trucha bug restorer
4. tell trucha bug NOT TO RELOAD IOS (as it'd destroy the nice work cboot2 did). Truchabug overrides startup libogc loading of IOS, so we're fine. ios36 menu. Change target to 236 (this way we don't overwrite anything at all). NAND permissions patch YES WE WANT! (as the IOS we created will be used solely for hacking

5. http://wiibrew.org/wiki/AnyTitle_Deleter/A...tle_Deleter_MOD version 6b from homebrew menu. Load IOS 236. Delete from system stuff the IOS249 (nintendo put a stub there in 4.2 to sabotage homebrew. It's just a stub.). Ignore stupid errors/warnings from the program and proceed (it scared me here too, but worked).
6. use the latest cios installer, loading IOS 236 on startup too.
7. boot a game with your favourite loader
8. make another NAND backup just in case

.

 

[WiiCrazy]

I don't think you need cboot2 to run TBR... so why? To reduce the steps in TBR?

 

[s3phir0th115]

I don't think you need cboot2 to run TBR... so why? To reduce the steps in TBR?

Probably to reduce the steps. Otherwise you have to install a patched IOS15 and then use that. With cboot2 you can just have it put on an IOS straight away.

 

[matsurisan]

I don't think you need cboot2 to run TBR... so why? To reduce the steps in TBR?

You're right (in my case).

Newer WIIs/systemsoftware do not have the IOS bugs IOS installers need. I understand IOS can only be overwritten and not installed as new ones if the bug isn't available.

cboot2 patches the bugs back in ram while loading the IOS. This minimizes risks/ugliness, as no ninty IOSs need to be overwritten and patched IOS is installed in an unused #.

However, if using system 4.2, there's the ninty stubs over 222,223,249,250. Perhaps It'd make sense to run TBR directly and overwrite one of those since there's no escape from overwriting those (positions used by backup loader IOSs), for the 4.2 case at least.

 

[WiiCrazy]

Patching an unused ios and especially non system menu ios is not a risk I think or is it?
On newer systems only downgrading back to 3.2 and so on causes a risk I guess since old ios is not compatible with new boot2 versions. (because of the timing issue bushing mentioned in his blog post.)

 

[tueidj]

Somebody would have to rebuild the cios installer adding the following:

s32 __IOS_LoadStartupIOS()
{
ÂÂÂÂreturn 0;
}

Just for the record, libogc was patched over a month ago to not reload IOS on program startup. If it is up-to-date there's no reason to implement that function yourself.

 

[matsurisan]

Patching an unused ios and especially non system menu ios is not a risk I think or is it?
On newer systems only downgrading back to 3.2 and so on causes a risk I guess since old ios is not compatible with new boot2 versions. (because of the timing issue bushing mentioned in his blog post.)

Touching the NAND at all is a risk. Overwriting anything from ninty is a higher risk.

It's best to be as clean as possible when it comes to the NAND, specially on non-vuln-boot1 devices, as recovery might be impossible without ripping the wii open, soldering stuff and using a NAND flasher when the convenient bootmii on boot2 is not available.

 

[wes11ph]

installing IOS254 w/o downgrade nor wads

is IOS254 related to backuploading? and all of this things that you ask is for backup loading only?

 

[WiiCrazy]

Patching an unused ios and especially non system menu ios is not a risk I think or is it?
On newer systems only downgrading back to 3.2 and so on causes a risk I guess since old ios is not compatible with new boot2 versions. (because of the timing issue bushing mentioned in his blog post.)

Touching the NAND at all is a risk. Overwriting anything from ninty is a higher risk.

It's best to be as clean as possible when it comes to the NAND, specially on non-vuln-boot1 devices, as recovery might be impossible without ripping the wii open, soldering stuff and using a NAND flasher when the convenient bootmii on boot2 is not available.

Ok, by the time you power up your wii, nand is accessed with read write access... while your wii stays in standby mode nand is accessed and certain files are updated...

The best brick protection (bootmii) works by overwriting the fundamental part of the wii's boot process boot2.

Patching & Messing with anything in the boot chain (boot2, menu ios, menu itself, resources used by menu) is risky but both IOS 15 & IOS 36 doesn't play any role in the wii's boot process. So messing with them is not risky at all.