Hacking Multiple mios slots, is it possible?

[Maxternal]

hmm, oh well.

If you just install a MIOS WAD as a BC directly I'm sure it would, at best, just result in extra speed and garbled sound like in the video I linked to above.
I'm sure it technically is possible in a more workable fashion but it seems like it'd need some creative patching somewhere to get it to work.

EDIT : Or even add another step to the process, putting a forwarder of sorts in the MIOS slot that would reload the right title depending on what instructions were left for it in memory.
I'll dub my idea PriiMIOS

 

[damysteryman]

Yeah, it would, but in that case you may as well just install MIOS into another slot and get the loader to boot it directly instead of overwriting BC, and then the game play would not be enjoyable anyway until we get the loader to set all the GC mode stuff correctly.

 

[Maxternal]

Referring to my above PriiMIOS idea, just wondering if anyone knows:

I was reading through this previously linked thread :
http://forum.wiibrew.org/read.php?27,8960,8977
and it suggests the MIOS contains both ARM and PPC code?

I'm not really clear if the call to reload an IOS (or call BC or MIOS) is something the PPC does by itself or asks the IOS to do for it.
- If I were, for instance, to make a small app that would just reload another title and run it as GC homebrew (through a cMIOS) would that work by itself or would it need to make a system call in the IOS (which wouldn't be there) in order to actually perform a reload?
- In that case, would it be possible to install an IOS into the MIOS slot and somehow ask it to perform another reload once in GameCube mode?

(I know this would be so much easier if I had code for the HackMii installer. I know it uses Boot2 to reload different IOS without changing NAND, patching it while it's being loaded. I'd think the same thing could be done in GC mode having the other IOS actually be a MIOS instead but that's too hard for me to do without someone else's code to work off of.)



By all means if anyone who knows how to get something like this done wants to go ahead an do it themselves, be my guest. For me it'd be the first thing I'd ever program for a Wii and so a rather big first step but I do really want it to be done. Don't really care who does it.

 

[Maxternal]

Okay, I haven't really had ANY time to even look at this but another little idea just occurred to me so I thought I'd add it here.
It's installing the BootMii IOS into the MIOS slot and have the loader place the correct DM(L) ELF file in the bootmii folder to be laoded ... or maybe a modified version of the MINI that would use a different folder for it's ELF files ... gotta try some of these things out and see what happens.

 

[Maxternal]

Okay, digging this old thread up because I had all but forgotten about it.

I was finally looking over the code for the mini for something else today and noticed that when it detects it's run in GC mode just runs the MIOS directly. (or patches boot2 to do it.)

This is what happens with those who have BootMii@boot2 so for them it could very well be possible and pretty simple to mod the mini for BootMii@boot2 users to have it load the MIOS from a different slot.

My Wii only has it as an IOS so that's not something I can personally test but it seems VERY possible.
For people like me, there's still hope, though. I'm gonna see if placing the BootMii IOS in the MIOS slot will let me load that same modded mini in GC mode anyhow.


basically, looks like PriiMIOS IS possible. Stay tuned.




EDIT : a more user friendly approach would be to inject the mini-mod into a MIOS like you would when compiling DM(L) ... but I'll jump that hurtle when I get to it.

@anyone who knows :
you think it would be safe to put the config for which "MIOS slot" to run in memory right before the config for DM(L)? I don't want it to overwrite or get overwritten by anything important. (I guess I'll find out soon enough.)

Also, anyone know of a good tutorial for editing WAD's to install with different title ID's ?
I haven't looked into that yet either and I need to be able to make a DM, DML, and QuadForce WAD for other locations. (possibly also some DVD-R and homebrew compatible cMIOS's ... but I know I can't distribute those.)

 

[scooby74029]

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.

if you look at the code for neek the wii actually loads boot2 as neek so i think this is why neek gets away with only the call to bc

best way to edit a wad is to use showmiiwads it has option to change slot #

 

[duffmmann]

I have a question: would it be possible to program a usb loader (such as cfg usb loader) so that when you start a gc or quadforce game, it matches the id of the game to a list, where essentially if the Game ID is any one of the 4 Quadforce games that works, it quickly checks the mios installed, if it recognizes it as that for quadforce, it boots the game as normal, if however it recognizes it as Dios Mios (or anything else), it quickly installs the quadforce .wad from a defined location. and then boots the game from normal, this seems like something that could be done quickly, so you wouldn't have to see anything but the usb loader and then the game. Likewise, if the title id is recognized as anything but the 4 Game IDs that match for quadforce, it does the opposite check, where it recognizes whether the installed mios is dios mios or quadforce/anything else, if it recognizes dios mios, it boots the game as normal, if anything else, it installs the dios mios .wad from a defined location and then boots the game as normal.

 

[Maxternal]

I have a question: would it be possible to program a usb loader (such as cfg usb loader) so that when you start a gc or quadforce game, it matches the id of the game to a list, where essentially if the Game ID is any one of the 4 Quadforce games that works, it quickly checks the mios installed, if it recognizes it as that for quadforce, it boots the game as normal, if however it recognizes it as Dios Mios (or anything else), it quickly installs the quadforce .wad from a defined location. and then boots the game from normal, this seems like something that could be done quickly, so you wouldn't have to see anything but the usb loader and then the game. Likewise, if the title id is recognized as anything but the 4 Game IDs that match for quadforce, it does the opposite check, where it recognizes whether the installed mios is dios mios or quadforce/anything else, if it recognizes dios mios, it boots the game as normal, if anything else, it installs the dios mios .wad from a defined location and then boots the game as normal.

Definitely possible. I think the idea was mentioned earlier on. The trouble is that people get kinda scared when something's getting repeatedly installed on NAND so no one's really wanted to do it.

 

[duffmmann]

Definitely possible. I think the idea was mentioned earlier on. The trouble is that people get kinda scared when something's getting repeatedly installed on NAND so no one's really wanted to do it.

While thats understandable, the only thing I think could possibly become corrupted through this method would be the MIOS slot, so I don't think it could possibly brick your Wii, and were it corrupted, you could just reinstall to the MIOS slot.

 

[Maxternal]

While thats understandable, the only thing I think could possibly become corrupted through this method would be the MIOS slot, so I don't think it could possibly brick your Wii, and were it corrupted, you could just reinstall to the MIOS slot.

I think you're right and the NAND has a file system so even if the blocks where the MIOS resides get corrupted it just means they get marked bad and it uses another one for that "file"
I'm not sure if it has like a FAT, or something keeping track of all the used blocks. It's even less likely but if there is one that's one part you wouldn't want to be corrupted.

Probably not an issue but it's the kind of thing people tend to complain about.

 

[duffmmann]

Well if I knew programming, I'd gladly be the guinea pig for such a usb loader. If someone actually knows how to do this but is afraid to try it, I'll legitimately try it and take the risk if there really is one.

 

[Maxternal]

I've been trying to mod a WAD manager for a while now (YAWMM) but just can't get it to compile. Maybe another, more experienced homebrew programmer would be able to try this for you.

Anyway, I think my PriiMIOS ideas is probably simpler to put together so I'll see if I can get that done soon.

 

[CheatFreak47]

As long as the loader being used to quickly install the wads is stable at its critical points (like USB Loader GX for example) when loading games or whatever it SHOULD be safe to edit the NAND. It's more or less an issue of stability.

It might be safer to make a tiny STABLE wad manager that accepts arguments, have the USB loader save what game it was to boot to a file, and then launch the tiny wad manager with the proper argument for installing the necessary wad, and then have the wad manager boot another app that would load the data from the file the loader saved and launch the game.

It might be convoluted but if its NAND safety everyone is concerned about---this would be a possible solution/workaround.

Do any wad managers already accept arguments?

 

[Maxternal]

Do any wad managers already accept arguments?

Nope, that's what I was trying to mod, actually, to use it for a wiiflow plugin

 

[Cyan]

installing the wad on the fly is possible (user could set three paths to three wads (DM/L/QF) that the loader will use (as there are different version, you need to put the desired version on your SD or USB first).
The problem is not the software side, but the user side, like for example placing a random/bad wads to be installed instead of DM/L/QF ?
If the user do something stupid when installing the wad, they will criticize the loader/dev team.

They already did once against USBloaderGX, a group of people told that the loader bricked a lot of Wiis while it didn't even write anything to the NAND. Only one user with a bricked Wii was reported though, and no proof it was the loader.
It could have been a game crashing on startup, Wii shutting down when creating the save file, etc.
Now USBloaderGX only write a temporary file on the NAND/tmp/ if the user choose to log play time. It's the only file written by the loader.

 

[CheatFreak47]

installing the wad on the fly is possible (user could set three paths to three wads (DM/L/QF) that the loader will use (as there are different version, you need to put the desired version on your SD or USB first).
The problem is not the software side, but the user side, like for example placing a random/bad wads to be installed instead of DM/L/QF ?
If the user do something stupid when installing the wad, they will criticize the loader/dev team.

They already did once against USBloaderGX, a group of people told that the loader bricked a lot of Wiis while it didn't even write anything to the NAND. Only one user with a bricked Wii was reported though, and no proof it was the loader.
It could have been a game crashing on startup, Wii shutting down when creating the save file, etc.
Now USBloaderGX only write a temporary file on the NAND/tmp/ if the user choose to log play time. It's the only file written by the loader.

Have the loader itself glance at the wad before installing? Put several warnings in the software when enabling the feature like WiiXplorer does with its NAND write access. (Except still allow you to save the setting, thats annoying in WiiXplorer)
Things like "This feature writes to the the Wii's NAND system memory. Please only proceed if you understand the risks involved. Should anything happen due to the use this feature, the Dev team holds no responsibility."

 

[Magnus87]

is not possible to create a cMIOS then load a cIOS?

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

6. cMios calls the cIOS

 

[Maxternal]

is not possible to create a cMIOS then load a cIOS?


6. cMios calls the cIOS

a MIOS doesn't have the built in code to reload a title that a IOS does. That's why my idea of replacing the MIOS with a BootMii IOS (in this case BootMii IOS = cMIOS of sorts) which CAN reload a title

and then, hopefully, we'd be able to perform your step 6 there

 

[emmanu888]

Maybe not related but, wouldn't it be easier to have a loader that installs the correct MIOS before running the game ? If its a Gamecube game, then DIOS MIOS is installed before running the game. If it's a Triforce game, then Quadforce gets installed before running the game

 

[Maxternal]

Maybe not related but, wouldn't it be easier to have a loader that installs the correct MIOS before running the game ? If its a Gamecube game, then DIOS MIOS is installed before running the game. If it's a Triforce game, then Quadforce gets installed before running the game

Easier to get your head around, maybe

In practice, though, the dev of the loader would have to add all the code for a WAD manager to their code and then adjust it to fit into their existing code but with the PriiMIOS idea all they have to do is add a few lines of code to put a number into memory to tell PriiMIOS which "MIOS slot" to use.

Changing the mini into "PriiMIOS" just took a couple lines of code to change (I've already coded it, in fact) I just need to have some FREE TIME while I happen to be near a computer with a compiler AND have that source code with me in order to compile it.


For the user, the initial setup for either one is pretty easy. For PriiMIOS you install some WAD's and put the file on your SD card. For the other idea, you put the WAD files wherever the loader wants them and name them right.

The PriiMIOS idea also probably would run faster since there's no WAD installation time when when you click on a game you don't have the right MIOS installed for.