Hacking Multiple mios slots, is it possible?

[Zero]

I had these theory today. I wanted to have Dios Mios, WiiPower CMIOS, and Quadforce installed all at the same time. Obviously you can only have one installed. My idea is, can you install MIOS in the unused IOS slots? Assuming the loader you're using has the option to use that particular MIOS, this would be possible, right? Or am I missing something?

 

[ddetkowski]

MIOS runs Gamecube on its own slot, or mode, which is one and nothing else......IOS's can use multiple slots, thats why Wii games can use different IOS'es.
Cannot be done Gamecube-wise.
Dont confuse MIOS with IOS, they are not the same, would be great if they were, though....

 

[Zero]

I know this, but couldn't you just redirect a loader to load MIOS from somewhere else?

 

[zerofalcon]

Newest rev of sneek+di has an option for booting DM, DML or Quadforce:

*SNEEK now automatically boots DM, DML or QF depending on where the game is
installed or if it is a QF game
Simply install all three versions to these locations:
/sneek/diosmios.bin
/sneek/diosmioslite.bin
/sneek/quadforce.bin

That way Wiigator CMIOS can be installed on real NAND and DM (L) and Quadforce in emunand, well thats my setup, I know the idea of this topic is to boot and install different CMIOS on real nand but I dont know if it's possible.

 

[Zero]

Yeah, I would use Sneek but I personally think it's not polished enough to be fully useful. NAND emulation still has a long way to go before I'll switch over completely.

 

[LinkFan16]

In theory it really should be possible to change the slot number of MIOS / DIOS MIOS / another custom MIOS and redirect Loaders to use a specific slot for different kinds of MIOS. However, this feature needs to be implemented in the loader first but then it should be no problem. I'm no expert on this stage so I could be wrong.

 

[damysteryman]

I too have actually thought about this a few times before. Now it should be technically possible for multiple MIOS to be installed into different slots, however, when launching into GC mode, it is BC that gets launched, not MIOS. BC then handles a few things before launching MIOS itself, meaning that it would only recognize a MIOS installed into the default slot. (1-257, or 0000000100000101). So it is because of this, that we cannot just tell a loader to launch GC mode from a different slot.

My ideas would be, maybe someone could grab all the different binaries of all the custom MIOSes (along with the original MIOS binary .app), and then put them all into one MIOS wad, including modifying the tmd to add info for the new binaries, added as extra .app files. And then, once that is done, add code to existing loaders to check the tmd of said Multi MIOS wad to see which .app is currently set as the Boot Content (found at offset 0x1E0 in the tmd), and patch that value in the MIOS tmd to set it to the "right" .app in the wad that you would want to use before going into GC mode. This should work fine, and allow easy "switching" of different MIOS types, but it of course requires that the loader edit the tmd of the installed MIOS every time it has to "change" to a different MIOS. Also, this would require that the loader has access to said file on the NAND (they should do, since most loaders either use a cIOS with file permission patch, or AHBPROT, or both).
I personally do not like the idea of having the loader modify the NAND (when modifying the MIOS tmd) like that, but then again, if something bad happens to MIOS on NAND, it can always be reinstalled fine, so it should not be too much of a worry though.

The other option I could think of would be to modify BC to get it to launch MIOS from a different slot depending on which MIOS or slot you wanted to use.

...maybe one of these two methods could be implemented, and then standardized for all loaders?

 

[Cyan]

The tmd store the .app filename to be launched? I thought it was always the same .app which were launched.
But I don't like the idea of editing the NAND each time either.

I also thought about a modified BC, but I don't know how/if it can be done. maybe it would have already been done if possible.

Another solution would be to emulate the BC?
We can launch MIOS directly and bypass the clock speed adjustment (there is a video showing a racing game if I remember, but I couldn't find it), can't we set the clock speed and all hardware manually in the loader and launch the MIOS from a different slot?

 

[Zero]

That video you mentioned
[yt]GlzVpo5IPdM[/yt]

Also, if we can't install MIOS to different slots, can we do the same for BC? Myabe edit each BC to correspond to different installations of MIOS?

 

[techboy]

Also, if we can't install MIOS to different slots, can we do the same for BC? Myabe edit each BC to correspond to different installations of MIOS?

That'd make the most sense to me. We'd end up with a pile of BCs installed, but BC is tiny anyway. As mentioned above, can BC be modified to load MIOS from elsewhere?

If so, you can distribute the MIOS and needed BC together. People just install both.

Loaders would need to know what BC is for what, but that can be accomplished a number of ways (assign slots for each program, have loader identify the BCs and figure it out, ask user...)

 

[Maxternal]

This is the way it was explained to me when I mentioned an idea similar to yours:

It works like this.
1. The BC get's called.
2. The BC makes all the changes, setting the Wii into GameCube mode.
3. The BC calls Boot2.
4. Boot2 checks and notices that everything's in GameCube mode.
5. Boot2 calls the MIOS.

I also understand that it's possible to call the MIOS directly but everything goes really fast because the BC hasn't been called.

When you installed DM(L) or QuadForce in SNEEK, UNEEK, neek2o, etc, what you're actually modifying is the BC so I think in that case the BC is the MIOS and that's how they avoid the BC calling Boot2 and pulling the Wii out of xNEEK.

If THAT is how it works in xNEEK, where DM(L) and QuadForce are actually cBC and not cMIOS, it seems to me that something like that could be possible in real NAND, too. I'm not sure if anyone's tried packing a DM(L) .app file in with the rest of the clean BC .app files into a .wad file and see what happens. If it works that way, I would think a standalone cBC file like that could be installed into and work from any slot you wanted.

/snip

/snip

The truth is, if we weren't so worried about modifying NAND, a loader could just have all the WAD files in a folder and install the one it needs before running the game.

Anyway, if a modified BC could be made to call the MIOS directly instead of Boot2 (I don't know if that would even work) I would think it could also be made to load the title that was passed to it from a parameter.

 

[Cyan]

I forgot BC called Boot2 and that's Boot2 which load the MIOS.
and Boot2 can't be edited on newer Wii without the Boot1 vulnerability.

But why couldn't the loader set the console in GameCube mode and launch MIOS directly?
I didn't try to install MIOS in a IOS slot and calling it directly. it's just a different folder name, right?

 

[damysteryman]

Yeah, just did a bit more research on all of this, and yeah, forgot about the part where BC is launching boot2...

According to this, it seems that is the way it is all booted up.
http://forum.wiibrew.org/read.php?27,8960,8977

Which means that we would have to modify boot2, not BC, in order to change the slot used for MIOS...
I would rather patch the MIOS tmd every time than do that

As for the xNEEK method, that is true, it is installed over BC, but I do not know what else xNEEK would do to actually make that compatible and function correctly. I assume that xNEEK itself would control the clock speed before launching BC?

And as for the tmd patching method, it does not store the filename as such, but it does store a value that tells which content .app no. to boot when that Title (in this case MIOS) is loaded. So, perhaps adding extra .app files form other MIOS types to one wad, and then installing, then telling the loader to patch the tmd to change which content No. is the one to boot should work.

However, I wonder what would happen if we got a loader to manually change this register here...
http://wiibrew.org/wiki/Hardware/Hollywood_Registers#HW_CLOCKS
...to set it to GC speed, and then try to launch MIOS directly, skipping everything else after setting the correct clock speed ourselves?

EDIT: @Cyan, yeah that is what I was thinking. AFAIK, it is just another slot, so we should launch it fine from other slots we install it at. We just have to try to set it to GC mode first.

 

[Maxternal]

I forgot BC called Boot2 and that's Boot2 which load the MIOS.
and Boot2 can't be edited on newer Wii without the Boot1 vulnerability.

But why couldn't the loader set the console in GameCube mode and launch MIOS directly?
I didn't try to install MIOS in a IOS slot and calling it directly. it's just a different folder name, right?

Yeah, I'd assume it's just another folder name kinda like an IOS folder / slot. I know DOP-Mii can install a IOS .wad in a different IOS slot but I've never tried using a MIOS .wad for that.

Also, I know you can't INSTALL an edited Boot2 on a newer Wii but I DO understand that the HackMii installer patches Boot2 when loading it into memory in order to load the different IOS when it first starts up.
Do you think it would be possible to do the same thing with the BC ... leave the BC on the NAND and just patch it when loading it so it will load the MIOS instead of Boot2? (kinda like how a loader patches cheats into a game?)

 

[Maxternal]

As for the xNEEK method, that is true, it is installed over BC, but I do not know what else xNEEK would do to actually make that compatible and function correctly. I assume that xNEEK itself would control the clock speed before launching BC?

However, I wonder what would happen if we got a loader to manually change this register here...
http://wiibrew.org/wiki/Hardware/Hollywood_Registers#HW_CLOCKS
...to set it to GC speed, and then try to launch MIOS directly, skipping everything else after setting the correct clock speed ourselves?

I always thought it was the other .app files that DM(L) didn't replace that did the change to GameCube mode and when they get to the code in the modified .app for DM(L) they just start running it and the code for the call to Boot2 was replaced by the code for DM(L) itself.

EDIT : Also, couldn't someone just decompile the BC or step through it's assembly code and find out which system call actually changes the clock speeds and just copy it?

It might have to be an instruction that's included into a cIOS or something, though, since I'm guessing the BC runs on ARM and it's not something the loader could do itself. I might be wrong, though.

 

[damysteryman]

You mean the other .app file in the BC title folder?
IIRC both BC and MIOS have only two .app files each, one is the actual code that gets booted, the other is just a 64 byte metadata, mainly with a sort of filename/description and build date, nothing more.

 

[Maxternal]

You mean the other .app file in the BC title folder?
IIRC both BC and MIOS have only two .app files each, one is the actual code that gets booted, the other is just a 64 byte metadata, mainly with a sort of filename/description and build date, nothing more.

Okay, makes sense. That was just the impression I had, that there were multiple parts and DM(L) was only replacing part and letting the original part to it's own job.

Maybe the DM(L) / QuadForce .app files include the clock speed system calls themselves. I'm not near my Wii at the moment and would need to do a little research as to how to do it but it'd be interesting to try to install the xNEEK version of DM(L) to real NAND and see if it works. Have you heard of anyone trying that before?

 

[damysteryman]

Not sure actually. That could be the case, but I currently remain doubtful at this time.

Downloading both versions of DM 2.4 right now, and I will see what happens when I try to put the xNEEK version into BC on real NAND.

It just makes me wonder though, if they DO do that themselves, then why would crediar need to make two versions of DM?

 

[VashTS]

Not sure actually. That could be the case, but I currently remain doubtful at this time.

Downloading both versions of DM 2.4 right now, and I will see what happens when I try to put the xNEEK version into BC on real NAND.

It just makes me wonder though, if they DO do that themselves, then why would crediar need to make two versions of DM?

heheheheheh you said do do. i always chuckle when people do do that. lol. just one "do" will do.

anyway on topic. keep up the work fellas, sounds like you are getting some ideas here, i sadly have no time to help, but id love it if you produce something!

 

[damysteryman]

Ok back now.

Well, popped up both the .app from the DM2.4 wad, and the BC-replacing .app into a hex editor, and found that the Real NAND version binary was 532 bytes larger than the xNEEK version. So, there is a difference between the two, I just do not know what that difference is.

Anyways, I decided to use FS Toolbox to replace my BC Real NAND 00000008.app with the one form the xNEEK DM 2.4, and...
I broke it.
It broke GC mode. Tried to load a GC disc via system menu, and Wii powers off, probably due to DM being coded to tell the Wii to power off when it encounters an error.