Hacking cboot2: Installing IOS254 without downgrades nor wads

matsurisan

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
I've gathered this information so far:
- New wiis (mine) do not allow for installing IOSses without reverting IOS first.
- Reverting
 

FenrirWolf

Well-Known Member
Member
Joined
Nov 19, 2008
Messages
4,347
Trophies
1
Location
Sandy, UT
XP
615
Country
United States
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

Well-Known Member
Member
Joined
Dec 31, 2008
Messages
728
Trophies
1
XP
1,003
Country
United States
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

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
s3phir0th115 said:
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

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
Somebody would have to rebuild the cios installer adding the following:
Code:
s32 __IOS_LoadStartupIOS()
{
ÂÂÂÂreturn 0;
}
 

tueidj

I R Expert
Member
Joined
Jan 8, 2009
Messages
2,569
Trophies
0
Website
Visit site
XP
999
Country
matsurisan said:
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

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
tueidj said:
matsurisan said:
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

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
6,659
Trophies
2
XP
5,927
Country
United Kingdom
matsurisan said:
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

Well-Known Member
Member
Joined
Dec 31, 2008
Messages
728
Trophies
1
XP
1,003
Country
United States
matsurisan said:
s3phir0th115 said:
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

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
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
wink.gif

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
smile.gif
.
 

s3phir0th115

Well-Known Member
Member
Joined
Dec 31, 2008
Messages
728
Trophies
1
XP
1,003
Country
United States
WiiCrazy said:
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

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
WiiCrazy said:
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

Be water my friend!
Member
Joined
May 8, 2008
Messages
2,395
Trophies
0
Location
Istanbul
Website
www.tepetaklak.com
XP
387
Country
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

I R Expert
Member
Joined
Jan 8, 2009
Messages
2,569
Trophies
0
Website
Visit site
XP
999
Country
matsurisan said:
Somebody would have to rebuild the cios installer adding the following:
Code:
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

Active Member
OP
Newcomer
Joined
Aug 18, 2009
Messages
33
Trophies
0
XP
74
Country
WiiCrazy said:
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.
 

WiiCrazy

Be water my friend!
Member
Joined
May 8, 2008
Messages
2,395
Trophies
0
Location
Istanbul
Website
www.tepetaklak.com
XP
387
Country
matsurisan said:
WiiCrazy said:
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.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    AncientBoi @ AncientBoi: For @Flame