cBoot2

WARNING: You need to make a NAND backup with Bootmii before using this tool.
This is required to recover from fatal errors.

cBoot2 is a patched Boot2. You should be able to install a patched IOS if Bootmii is installed at boot2 location. You need to remove the GC memory card from slot 2 if you run this.

Note: This package is only needed for people, who have updated without return and lost all downgrade capabilities. You will need a boot1 with a sign bug to use it.

Purpose: Start patched IOS without installing using Bootmii loader. The
original Bootmii doesn't support to modify the file system. With this
package you get around this problem.

The description is included in the file.

Edit: Link to new version, which will work if Bootmii is installed as IOS and fix SD card problems.
Download cBoot2 v16

I am not sure if this will work on all systems. Please give me some response, if this is working.

It is configured for PAL. It should changed the mode when boot.dol is started.

Comments

cBoot2 needs only a method to start. After installing Bootmii on Boot2 or as IOS, you don't need any Bootmii file on the SD card. For installation you need only the files from Nintendo and the sdroot directory in the cBoot2 archive. So you need one of the following WAD files and the 2 downloaded files from Nintendo server.

1. BOOT2-v2-64.wad.out.wad
SHA1 sum: 92f16979b3e10e58da8f1052f3f7fc01ddb5b8fb

/00000001/00000001/v2/00000000.app
SHA1 sum: bd0f4fc7dfe0d8f137549eb36fbfd56b3dae84ee

/00000001/00000001/v2/tmd.2
SHA1 sum: 932ee88b8a63c6ac0856b222ae06acec77dc33ae

/00000001/00000001/v2/cetk
SHA1 sum: ace0f15d2a851c383fe4657afc3840d6ffe30ad0

2. BOOT2-64-v2.wad
SHA1 sum: 85c08539369f96a177615963c4e03c29b12c9df1

/00000001/00000001/v2/00000000.app
SHA1 sum: bd0f4fc7dfe0d8f137549eb36fbfd56b3dae84ee

/00000001/00000001/v2/tmd.2
SHA1 sum: 932ee88b8a63c6ac0856b222ae06acec77dc33ae

/00000001/00000001/v2/cetk
SHA1 sum: ace0f15d2a851c383fe4657afc3840d6ffe30ad0

Note: The wad files are different, but the extracted files have the same SHA1 sum.
 
[quote name='WiiGator' post='2034263' date='Jun 7 2009, 06:42 PM']cBoot2 needs only a method to start. After installing Bootmii on Boot2 or as IOS, you don't need any Bootmii file on the SD card. For installation you need only the files from Nintendo and the sdroot directory in the cBoot2 archive. So you need one of the following WAD files and the 2 downloaded files from Nintendo server.

1. BOOT2-v2-64.wad.out.wad
SHA1 sum: 92f16979b3e10e58da8f1052f3f7fc01ddb5b8fb

/00000001/00000001/v2/00000000.app
SHA1 sum: bd0f4fc7dfe0d8f137549eb36fbfd56b3dae84ee

/00000001/00000001/v2/tmd.2
SHA1 sum: 932ee88b8a63c6ac0856b222ae06acec77dc33ae

/00000001/00000001/v2/cetk
SHA1 sum: ace0f15d2a851c383fe4657afc3840d6ffe30ad0

2. BOOT2-64-v2.wad
SHA1 sum: 85c08539369f96a177615963c4e03c29b12c9df1

/00000001/00000001/v2/00000000.app
SHA1 sum: bd0f4fc7dfe0d8f137549eb36fbfd56b3dae84ee

/00000001/00000001/v2/tmd.2
SHA1 sum: 932ee88b8a63c6ac0856b222ae06acec77dc33ae

/00000001/00000001/v2/cetk
SHA1 sum: ace0f15d2a851c383fe4657afc3840d6ffe30ad0

Note: The wad files are different, but the extracted files have the same SHA1 sum.[/quote]

This is really freaky. I used wwpacker v1.80 to extract wads from 3 different sources. The tmd.2 and cetk always ends up with different SHA1 values as compared to yours (however, it's identical from all 3 wads) but the 00000000.app is always correct. All 3 "BOOT2-v2-64.wad.out.wad" have the correct SHA1 as you mentioned.

Mine's :

/00000001/00000001/v2/tmd.2 [file size : 523 bytes]
SHA1 sum : A3690053C5E1ADB72959F78BEFA0F6A4A558E79C

/00000001/00000001/v2/cetk [file size : 676 bytes]
SHA1 sum : FAA4AFE4116B3BA762E9C3741E1E31DDE6D7AAFE


However, I can't find the "BOOT2-64-v2.wad" at all from the 3 ISOs. I used wiiscrubber 1.4 to open them... what am I doing wrong? :hateit:
 
Could the IOS that is loaded from MEM2 be also patched wth all the current features (ie "hacked" modules) but also patched to prevent any PPC code from loading a new IOS (through IOS_Reload) ?

That's way, instead of loading a boot dol, the System Menu could be run as usual, over this custom IOS so as any games/channels later when loaded.
And, since the same custom IOS will always run on Starlet, this would allow for all interesting features (signature bug, backups through disc channel, custom modules for backup loader, "downgrading" patches, etc) without insane NAND patching of all IOS or multiplications of installed cIOS (221,222;249,etc)

if this is possible (ie preventing an IOS to load another IOS over himself), this would be the best hacking solution, having only a modified Boot2 but still a fully-featured custom IOS patched (in memory) on each startup and staying on Starlet forever. The most intersting part being you will only need to update the ARM binary when you want to modify or add cIOS patches...
 
[quote name='Jacobeian' post='2036928' date='Jun 8 2009, 04:32 PM']Could the IOS that is loaded from MEM2 be also patched wth all the current features (ie "hacked" modules) but also patched to prevent any PPC code from loading a new IOS (through IOS_Reload) ?

That's way, instead of loading a boot dol, the System Menu could be run as usual, over this custom IOS so as any games/channels later when loaded.
And, since the same custom IOS will always run on Starlet, this would allow for all interesting features (signature bug, backups through disc channel, custom modules for backup loader, "downgrading" patches, etc) without insane NAND patching of all IOS or multiplications of installed cIOS (221,222;249,etc)

if this is possible (ie preventing an IOS to load another IOS over himself), this would be the best hacking solution, having only a modified Boot2 but still a fully-featured custom IOS patched (in memory) on each startup and staying on Starlet forever. The most intersting part being you will only need to update the ARM binary when you want to modify or add cIOS patches...[/quote]

To block IOS reloads should be possible with a cIOS. As far as i know somebody is working at it, but said it's pretty difficult to do. This IOS reload would be a general cIOS feature, not just only for cIOS started via cBoot2.
 
Some time ago I've written a cIOS patch, that replaced the wanted IOS number by the cIOS number on reload. After this change it was nearly impossible to escape cIOS. I needed to turn off the Wii to be able to get back to a normal IOS (Maybe reset button at the console was also working, but I don't remember). The cIOS was still active when I've selected to go back to system menu from a game. I was able to play Red Steel and Sam & Max without patching the disc and only IOS249.
I didn't released it, because I hadn't got the time and there was no good way to escape cIOS.
This patch can't be used for cIOS loaded by cBoot2. But it is possible to write a working patch for cBoot2, if SD access is not disturbed by the game or system menu.

The newer IOS consist of one kernel file and serveral module files. The older IOS consist of one file which include the modules. In general the module files are loaded from NAND flash. So for a newer IOS the module files need to be patched in NAND flash. Older IOS can be loaded completely from SD.
 
Some time ago I've written a cIOS patch, that replaced the wanted IOS number by the cIOS number on reload. After this change it was nearly impossible to escape cIOS. I needed to turn off the Wii to be able to get back to a normal IOS (Maybe reset button at the console was also working, but I don't remember). The cIOS was still active when I've selected to go back to system menu from a game. I was able to play Red Steel and Sam & Max without patching the disc and only IOS249.
I didn't released it, because I hadn't got the time and there was no good way to escape cIOS.
This patch can't be used for cIOS loaded by cBoot2. But it is possible to write a working patch for cBoot2, if SD access is not disturbed by the game or system menu.

Well, you could for example make the cIOS always load himself except when the number is a particular number (any unused IOS) in what case it reloads the system menu IOS... or maybe create a new ioctl ?

Anyway, I 'm not really aware about the limits of IOS customizing (is that feasible to completely recode a whole module or the main module as you want then recompile using available IOS tools ? Or was it only done by binary ASM patching ?) but it's definitevely very interesting, especially with BootMii being out.

The newer IOS consist of one kernel file and serveral module files. The older IOS consist of one file which include the modules. In general the module files are loaded from NAND flash. So for a newer IOS the module files need to be patched in NAND flash. Older IOS can be loaded completely from SD.

What about patching one of these *new* IOS to load his modules from SD instead of NAND ?
Again for the sole purpose of leaving the NAND as "virgin" as possible. The main feature of bootmii being to load & run on Starlet a customized IOS (or even something totally revamped like Mini) from SD, it really gives unlimited ideas for secured & easy upgradable hacking solutions
 
[quote name='WiiGator' post='2017106' date='May 31 2009, 10:31 PM'][quote name='TheCrach' post='2013244' date='May 30 2009, 06:35 AM']Hi WiiGator !
I've got a tiny problem ...
I don't find the file system.c in my libogc folder !?
Where I can find it ?
Could you upload your libogc folder or anyone else ? Because I want to create my custom Wad Manager for cBoot2.
And : How to use .patch file please ?
Thank's in advance ;)[/quote]

You need to recompile the source code. You don't have the source code of libogc.

http://sourceforge.net/project/showfiles.p...lease_id=663541

The file libogc-src-1.7.1a.tar.bz2 includes the source code. To apply the patch, you need to change to the directory libogc and run in Linux, CygWin or MSYS console:
patch -p1 </path/to/libogc.patch

You need to replace the path. The patch just removes "__IOS_LoadStartupIOS();" from the code.

@modshroom128: You didn't copied the IOS36 files (/00000001/00000024/v1042), which are mentioned before in this thread.
[/quote]

Thank's a lot but after I have edited the source and compile it with Programmer's notepad, what I have to do ?

EDIT : A friend have said me that I've to copy libogc.a, is it exact ?
 
[quote name='WiiGator' post='2037806' date='Jun 9 2009, 06:08 AM']Some time ago I've written a cIOS patch, that replaced the wanted IOS number by the cIOS number on reload. After this change it was nearly impossible to escape cIOS. I needed to turn off the Wii to be able to get back to a normal IOS (Maybe reset button at the console was also working, but I don't remember). The cIOS was still active when I've selected to go back to system menu from a game. I was able to play Red Steel and Sam & Max without patching the disc and only IOS249.
I didn't released it, because I hadn't got the time and there was no good way to escape cIOS.
This patch can't be used for cIOS loaded by cBoot2. But it is possible to write a working patch for cBoot2, if SD access is not disturbed by the game or system menu.

The newer IOS consist of one kernel file and serveral module files. The older IOS consist of one file which include the modules. In general the module files are loaded from NAND flash. So for a newer IOS the module files need to be patched in NAND flash. Older IOS can be loaded completely from SD.[/quote]

How about some help from my reply above? Is it possible to just upload the correct cetk and tmd.2 and let me know via PM?
 
Hi WiiGator !
The source of dolloader won't compile correctly ...
Have you got the libraries ?
Or could you compile an other startup.elf with a different name as : boot.dol in hack.dol ?
Thank's in advance for your help !
 
For the file name change you can use a hex editor, as long as the string length and the file size stay the same.

I assume it doesn't compile, because I used arm-eabi-gcc by mistake to detect a header file path. powerpc-gekko-gcc need to be used or just remove "-nostdinc" and "GCC_INSTALL_DIR".
 
WiiGator are you still working at cBoot2?

FSToolbox r46+ is able to run off the cIOS from cBoot2, but it can't access all folders. Some patch that is inside the regular cIOS is missing in yours. Could you please add it? cBoot2 would become an even better app to fix bricks(when BootMii is installed as boot2) by this as it already is.

And i think just adding this dummy function:
Code:
s32 __IOS_LoadStartupIOS&#40;&#41;
{
	return 0;
}

is the easiest soltution to make a project cBoot2 compatible.
 
I didn't see that __IOS_LoadStartupIOS() was linked as a weak symbol, so your solution is much easier, because you don't need to recompile the libogc.

I am currently working at something else, but I will later come back to cBoot2. FSToolbox uses the SU ticket. As far as I know this is working with an old normal IOS. Do you have a newer IOS36 installed? I read somewhere that SU stuff is removed in newer IOS versions. cIOS is based on the older IOS36.
 
[quote name='WiiGator' post='2069420' date='Jun 22 2009, 08:32 AM']I didn't see that __IOS_LoadStartupIOS() was linked as a weak symbol, so your solution is much easier, because you don't need to recompile the libogc.

I am currently working at something else, but I will later come back to cBoot2. FSToolbox uses the SU ticket. As far as I know this is working with an old normal IOS. Do you have a newer IOS36 installed? I read somewhere that SU stuff is removed in newer IOS versions. cIOS is based on the older IOS36.[/quote]

FSToolbox works as expected with cIOSrev13a, so i guessed it's possible to change the temorary IOS to have the same features. With IOS36v1042 you are still lacking some permissions or whatever, you can't do everything with it you can with the cIOS.

I hope the "something else" is something else great for Wii, but i wouldn't be disappointed if not, there's already pretty much everthing somebody could need/want.
 
Can cBoot2 be used to reinstall corrupted system menu and ios files for a bricked wii?
 
[quote name='c039' post='2071969' date='Jun 22 2009, 10:57 PM']Can cBoot2 be used to reinstall corrupted system menu and ios files for a bricked wii?[/quote]

I don't see any reason why not...good alternative if no proper NAND backup is available and you're able to access BootMii
 
So even if the entire wii file system is wiped out,
you can still go into bootmii menu,
fire up cboot2 and wad manager,
reinstall system menu and ios file,
and bring a dead wii like mine to life again?
If so, that would be very very cool.
Is there anyone "with a nand backup" willing to try and verify that?
 
[quote name='sfjuocekr' post='2075269' date='Jun 24 2009, 06:36 PM']How do I patch a DOL to not use any other IOS?

For example cIOS38_revXXX-Installer?[/quote]

Without the source you can't. Install a cIOS with a wad and then use IOS249 in the installer.
 
[quote name='Bloodlust' post='2033898' date='Jun 6 2009, 11:22 PM']Wiigator, I need some help. You mentioned that the BOOT2-64-v2.wad with a SHA1 : 92F16979B3E10E58DA8F1052F3F7FC01DDB5B8FB
is the correct one. Could you let me know the SHA1 values for :

1) 0000000100000001.tik (to be renamed to cetk)
2) 0000000100000001.tmd (to be renamed to tmd.2)

I have tried 3x BOOT2-64-v2.wads, and all have the above SHA1 I mentioned, but you only filled us in on the one with the wad you obtained from zelda which I don't have with me.[/quote]

I had this problem too, couldn't seem to find a 0000000100000001.tik that had the same checksum as posted in this thread.

I then tried a SHA1SUM on 0000000100000001.cert, the value is the same as listed above for cetk:
Code:
ace0f15d2a851c383fe4657afc3840d6ffe30ad0 *0000000100000001.cert

Someone please correct me if I'm wrong, but I think you're supposed to rename 0000000100000001.cert (not .tik) to cetk, and 0000000100000001.tmd to tmd.2. Then the checksums will match per WiiGator's post:
Code:
ace0f15d2a851c383fe4657afc3840d6ffe30ad0 *cetk
932ee88b8a63c6ac0856b222ae06acec77dc33ae *tmd.2

Thanks WiiGator for this excellent utility!
 
WiiGator,

maybe you can help me with this tool

the full explanation of the problem I am facing is here

but to try to make it short.
a friend has a wii.
4.1e
boot2v3 (so no bootmii on boot2, but as IOS)
HBC running

he downloaded through NUS IOS36-64-v3094
he downloaded wwpacker 1.84
ran freethebug on the WAD....
and installed it through wad-manager (HBC)

since then his wii is acting up.
I only had him on the phone but he can't seem to be able to run any wad-manager to reinstall the ios36.
I thought that maybe your tool could help so I walked him through launching it.
but it gets stuck at
cBoot2 DOL Loader v16

IOS Version 36 v7 0x00240010
IOS sucessfully loaded

from the explanation on your TXT I had the feeling that your app was able to pick an IOS starting from ios36 down to 3 until it finds one.
would it be possible to skip ios36 ? maybe if he can start it with another IOS it would do the trick.

or maybe I am having a prob because of wad manager and he need one which runs on another IOS...

I hope you can help.
Cheers,
R
 

Blog entry information

Author
WiiGator
Views
485
Comments
214
Last update

More entries in Personal Blogs

More entries from WiiGator

General chit-chat
Help Users
    AncientBoi @ AncientBoi: Brain? whats that?