Hacking cIOS installer future

  • Thread starter Thread starter WiiPower
  • Start date Start date
  • Views Views 13,479
  • Replies Replies 59
I never used the app SciiFii but iirc it was something like this was it not and maybe open source ?

btw, I don't think it did need a bump the devs concerned with it have most likely agreed in pm or irc about how to go forward now but why not keep it alive and maybe someone will surprise us all with some new ideas .
 
Dragbe will come with a new idea for the identification method
smile.gif
 
Just a small idea...

Would it be possible to make it automatically detect the cIOS installed and ask if it should update these to latest version with the possibility to use beta version or not? That would be nice.
 
WiiPower said:
The loader can see which IOS a game wants, so it can decide which cIOS is the best and just load it automatically.
So, self-aware loaders that knows which IOS is required for a certain game, then loads the appropriate cIOS (if it's present) needed for the game to work correctly? Neat.

QUOTE(MarcusIronfist @ May 29 2011, 10:56 AM) There are many different choices/options of cIOS setups (base IOS, base IOS version, mod author, and mod version) that people can use, leading to a situation where essentially no two Wii's would ever be 100% alike unless a "universal standard" was agreed upon by the cIOS authors and the devs of the loader apps. That's why there has been discussion of "searching" which cIOS combinations are installed to which slots, so that the loader app can then auto-select the best cIOS to play a specific game.
Bingo. There needs to be a standard here for the self-aware loader to work correctly, I'm thinking. What would be the ideal bases required for the majority of games and in what slots should they be installed in? I think it's about time to abandon the whole slot 249 thing as the default slot. Why not start at 240 or 230 and go up?
 
I wonder why installing a cIOS is still necessary now that we've got ahbprot. Just patch it in memory, Riivolution-style
tongue.gif
 
snikerz said:
I wonder why installing a cIOS is still necessary now that we've got ahbprot. Just patch it in memory, Riivolution-style
tongue.gif

cIOS is more than patching in memory. In order to play backup games, it's more required than a patched IOS.
cIOS = patched IOS (fakesign, nand access, es_diverify) + dip module + ffs module + ?? + ?? ..
You cannot patch an IOS on-the-fly with those additional modules (I think).
 
Riivolution can replace files from a game, and the files it uses can be on a usb/sd/smb.

In theory you could replace every single file in a game (I'm not 100% sure of this, sure someone will know) and it wouldn't require a cIOS. However you would need the original disc in the drive, and would need to swap this to load another game
tongue.gif
 
snikerz said:
WiiBricker said:
You cannot patch an IOS on-the-fly with those additional modules (I think).
Explain why.

The current available patches for AHBPROT that are available are either just simple patches that change a few bytes with a fixed pattern. Or they are specialised to be used with a certain IOS base, or does Riivolution support other bases than IOS37 now?

Oh and it would mean that you need to have exactly the correct IOS installed, no cioscorp, no trucha patch on them, no nothing. Well supporting those patches would be possible, but it would complicate stuff even further.

All in all, it's not impossible, Riivolution proves that, but it's difficult and/or a lot of work to do. It's comparable to the situation of playing IOS Reloading games from usb, when uneek+di was able to do that already. I have no interest in writing this, and i don't think you'll find somebody to do it. Also, if this was worked on, then more important matters, like the 4K sector support(>2TB HDDs), or fixing the last 2-3(are there that many?) not 100% working games, would be delayed a lot.
 
If patching in memory is too complicated, maybe loading a cIOS from SD is an option? Just like cBoot2 does it, just implemented on the PPC side to make things easier.

IMHO, not that we've got ahbprot and IOS reload block, installing a cIOS is an unnecessary step.
smile.gif
 
IOS Reload blocking would be difficult again with a cIOS that doesn't need to be installed. You can't just not execute an IOS Reload request from the game, it's more complicated, and the current solution doesn't even work with modules loaded with mload.
 
I think you guys should definately include the info in the TMD and also MAX the ver. numbers. Also i think the way this should be done is by making a cIOS of every required game IOS (even down to IOS 9!) then auto-check the games required IOS and make it to it's cIOS with its cIOS base so if u pop in LoZ Twilight princess which uses 9, it would look for IOS2##[09] and nsmb which riquires 55 will look for IOS2$$[55]. BTW i wish D2X would include all of Hermes fixes so we can make his IOSs obselete they are based off of really old versions of IOSs anyway. That way we onlly need D2X and we will have a cIOS for every base we need and auto matching. If you guys are gonna even attempt to do it right, lets do it right the first time. i hate having to have hermes ios, wanin, and d2x and havin to remember which is which. and damnit i wish CFG would at least support down to 240, but i wish it went down to 200, and didnt have 222,223,224 reserved for hermes, and with this new ident method it wouldnt need to, cuz it can ident them in any slot. D2X ROCKS good look. OH plz include build support for 36, 60,61, and 80 in next installer, and maybe even lower than 36... at least to the first modular IOS which was (28?)..
 
RussianBostwick said:
I think you guys should definately include the info in the TMD and also MAX the ver. numbers. Also i think the way this should be done is by making a cIOS of every required game IOS (even down to IOS 9!) then auto-check the games required IOS and make it to it's cIOS with its cIOS base so if u pop in LoZ Twilight princess which uses 9, it would look for IOS2##[09] and nsmb which riquires 55 will look for IOS2$$[55]. BTW i wish D2X would include all of Hermes fixes so we can make his IOSs obselete they are based off of really old versions of IOSs anyway. That way we onlly need D2X and we will have a cIOS for every base we need and auto matching. If you guys are gonna even attempt to do it right, lets do it right the first time. i hate having to have hermes ios, wanin, and d2x and havin to remember which is which. and damnit i wish CFG would at least support down to 240, but i wish it went down to 200, and didnt have 222,223,224 reserved for hermes, and with this new ident method it wouldnt need to, cuz it can ident them in any slot. D2X ROCKS good look. OH plz include build support for 36, 60,61, and 80 in next installer, and maybe even lower than 36... at least to the first modular IOS which was (28?)..

Why should it be necessary to make cIOSes with each one of the IOS as base? Compatibility is almost 100% already! Also I believe this discussion belongs to the D2X thread since it has nothing to do with a possible future installer!
 
Ahem...I was hoping to stay out of this thread because the technical details are over my head (yeah, I know my shortcomings). I thought about adding something like "you guys: it would be nice if there was a nice, short, standardized way to refer to these cIOS things", but with all the technical stuff going on, I figured you might want to prefer listening to someone who actually knows how to code.

But wiipower's reply in this thread convinced me to state that point anyhow. Or rather: to state the importance of elegance.

In that thread, Wiipower is certainly right that there is no such thing as "cIOS236". Or IOS249*. Or something like that. But why do all those damn end users come here, crying that their games don't work, even though they have "cIOS249"?

It's because the name is short. Sure, you can cram your guide with all the needed technical mumbo jumbo that explains everything. But if you're lucky, your end user will just understand and remember things just long enough to follow the guide to the end without missing a step. If you're unlucky, he just ignores your guide for it being "too complicated" and decides that a youtube video is a better choice (I'll just do exactly what he does!).


It isn't a pleasant truth, but a truth nonetheless: end users are noobs. Which is basically the same as 'morons', except that it's more politically correct.


So my request for a cIOS installer would be based on that: make it more idiot proof. I want to take modmii as an example: it's a good interface, clean and gets you what you need. It's idiot proof. The results: you get bigger idiots. Can you even blame them? modmii allows to download all cIOS you need and even a whole bunch you don't. And it even allows you to pick your own slot and version numbers. The program has more features than my girlfriend!
biggrin.gif


Unfortunately, for the average user, all these features are just obstacles that stand between him and playing his games.



So my proposition is this: an all inclusive package of all the cIOS you need for USB loading. With standardized places, base IOS'es and a fancy name that end users may actually remember. And if this sounds awefully similar to cioscorp/darkcorp...that's no coincidence. I'm aware of the flaws of that program, but it has strenghts as well. For one: it is fucking simple to use. You click, let it install a bunch of stuff, plug in your backup disc, done. You're ready to play.
Is it so hard to strive toward the same thing with just a handfull of cIOS'es? I haven't followed all the progression on d2x, but by the sounds of it, those cIOS'es are almost enough by themselves to get to 100% of the games on USB loader. In fact, are there games (or wiiware, VC, homebrew or anything else) for which you need to fall back to another cIOS?

So without further ado...I present "the d2x atom package"**:

-in slot 246: d2x v4 base 56
-in slot 247: d2x v4 base 57
-in slot 248: d2x v4 base 58
-in slot 249: Waninkoko rev17

That way, end users can complain all they want. As long as they can say that they have installed the 'd2x atom package' we'll know what the fuck they HAVE on their wii.

I'd even go as far that loaders could be updated to check for the availability of the pack, they can default the standard to be used cIOS to not 222 or 249 but to what a database says (something "if atom package is detected and the game is black ops, then set the default to be used cIOS to 247"). But that's more a nice to have than something important.
smile.gif





*unless we want to take nintendo's official stub into account. We don't.
**important: the name and the included cIOS'es are rough drafts here. They're NOT meant to be final (the authors of the cIOS are entitled to make a name, and rev17 is for over 99% outclassed by the d2x cIOS'es) but to give an idea what I mean
 
WiiPower said:
The current available patches for AHBPROT that are available are either just simple patches that change a few bytes with a fixed pattern. Or they are specialised to be used with a certain IOS base, or does Riivolution support other bases than IOS37 now?
Riivolution can work with any IOS, it's only limited to using IOS37 so people don't bitch about needing to have all their IOSes clean. It doesn't rely on AHBPROT either.
 
snikerz said:
WiiBricker said:
You cannot patch an IOS on-the-fly with those additional modules (I think).
Explain why.
AFAIK, if an entire module is replaced with a custom version, it requires the IOS to be reloaded to do any good, and seeing as they are patched in memory, reloading it will remove said patches. I think this is right, I believe tueidj told me this when AHBPROT was first added to HBC and I suggested that meant cIOS was no longer necessary for USB 2.0, which with any IOS other than 58 required an additional module. (USB 2.0 is now possible without a cIOS because IOS58 natively supports it)

EDIT: Here is what he said: http://gbatemp.net/t242636-hackmii-install...t&p=3012642 - basically the custom modules would have to be loaded before the other modules, which in the case of on-the-fly patching they are already loaded, and some modules are larger, and when the IOS is already running, replacing a module with a larger one would case problems with using more than the already allocated memory, overflowing into the next module or whatever.
 
tueidj said:
WiiPower said:
The current available patches for AHBPROT that are available are either just simple patches that change a few bytes with a fixed pattern. Or they are specialised to be used with a certain IOS base, or does Riivolution support other bases than IOS37 now?
Riivolution can work with any IOS, it's only limited to using IOS37 so people don't bitch about needing to have all their IOSes clean. It doesn't rely on AHBPROT either.

Hmm i was under the impression that Riivolution uses the same exploit* as HBC to get AHBPROT if it's not available directly. Are you sure it doesn't use AHBPROT internally somewhere for the IOS patching process?

*Oh well, or one that's similar
 
What about the gbatemp universal cIOS installer project ?
NOTE: Although Waninkoko was already using the 64 bytes content to store some information, create a new content (located at the end of tmd) from cIOS identification information would be potentially a more flexible solution. It's just an observation, no need to change the current strategy about it.
 
dragbe said:
What about the gbatemp universal cIOS installer project ?
NOTE: Although Waninkoko was already using the 64 bytes content to store some information, create a new content (located at the end of tmd) from cIOS identification information would be potentially a more flexible solution. It's just an observation, no need to change the current strategy about it.
I think it's dead
wink.gif

Your installer works pretty good for the current needs.
 
WiiPower said:
tueidj said:
WiiPower said:
The current available patches for AHBPROT that are available are either just simple patches that change a few bytes with a fixed pattern. Or they are specialised to be used with a certain IOS base, or does Riivolution support other bases than IOS37 now?
Riivolution can work with any IOS, it's only limited to using IOS37 so people don't bitch about needing to have all their IOSes clean. It doesn't rely on AHBPROT either.

Hmm i was under the impression that Riivolution uses the same exploit* as HBC to get AHBPROT if it's not available directly. Are you sure it doesn't use AHBPROT internally somewhere for the IOS patching process?

*Oh well, or one that's similar
HBC doesn't use an exploit to get AHBPROT. It just has a flag set in its TMD and System Menu willing gives it AHBPROT. Seeing as Riivolution doesn't have to be installed as a channel, and IIRC was released before HBC 1.0.6 (when AHBPROT support was added), there is no way it could use AHBPROT.
 

Site & Scene News

Popular threads in this forum