cBoot2

[Bloodlust]

This what i get at the moment

IOS Version: 00240c16
from SD: from SD: Downloading IOS1 metadata: ..from SD ..Tmd ..from SD ..t
icket..title ID: 0000020000000100
Number of parts 0. Total size: 0k
Downloading contents:

The whole thing takes about five seconds before it returns to HBC.

The file /00000001/00000001/v2/tmd.2 is not correct. The tool which extracted the file is either not working or you renamed the wrong file to tmd.2. Please check the SHA1 checksum. First check if the WAD file has the correct checksum, then check if the extracted files have the correct checksum. If the WAD file is not correct, you need a different game disc.

On a next step you should check if the downloaded files are not HTML files (no ".html" extension, no readable text).

@n01a
Maybe your SD card can't be read anymore by Bootmii or you deinstalled the Bootmii loader in the NAND.

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.

Lastly, I am still a bit confused about this... does the cboot2installer during compilation create an "armboot.bin" file in the process or does it only patch it (Requiring this file to be already present)

 

[WiiGator]

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.

 

[Bloodlust]

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.

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?

 

[Jacobeian]

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

 

[WiiPower]

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

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.

 

[WiiGator]

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.

 

[Jacobeian]

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.

QUOTEThe 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

 

[TheCrach]

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

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

 

[Bloodlust]

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.

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?

 

[TheCrach]

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 !

 

[WiiGator]

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".

 

[WiiPower]

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:

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

is the easiest soltution to make a project cBoot2 compatible.

 

[WiiGator]

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.

 

[WiiPower]

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.

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.

 

[c039]

Can cBoot2 be used to reinstall corrupted system menu and ios files for a bricked wii?

 

[mtb-bfh]

Can cBoot2 be used to reinstall corrupted system menu and ios files for a bricked wii?

I don't see any reason why not...good alternative if no proper NAND backup is available and you're able to access BootMii

 

[c039]

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?

 

[sfjuocekr]

How do I patch a DOL to not use any other IOS?

For example cIOS38_revXXX-Installer?

 

[WiiPower]

How do I patch a DOL to not use any other IOS?

For example cIOS38_revXXX-Installer?

Without the source you can't. Install a cIOS with a wad and then use IOS249 in the installer.

 

[Dteyn]

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.

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:

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:
CODEace0f15d2a851c383fe4657afc3840d6ffe30ad0 *cetk
932ee88b8a63c6ac0856b222ae06acec77dc33ae *tmd.2

Thanks WiiGator for this excellent utility!