I'm not requesting anything in regard to this, but I am just wondering if it would be possible to use HW_AHBPROT (http://www.hackmii.com/2009/08/of-tmds-and-hardware/) for the Rebooter function of GeckoOS, and eliminate the need to patch IOS36? If this could be done, it could create a more universal method of loading the Rebooter on all System Menu versions.
As of right now, there are different methods for each user. Currently, someone on 3.2 (or perhaps 3.3?) and lower can simply load the Rebooter without any problems. Someone on 3.4 (or perhaps 3.3?) to 4.2 need to downgrade IOS15 and then patch IOS36 from there, and IOS41 is not required. Someone on 4.3 U/E/J needs to install IOS41, which is a Korean IOS, to downgrade IOS15, and then patch IOS36 (reverse is true for a Korean user).
I'm pointing this out, as I have little doubt that Nintendo will stub those Korean IOS files in a future update, likewise with NTSC/PAL/JAP IOS files on Korean Wii consoles. Therefore, it might become very difficult to keep that function working on future System Menu versions. In addition, Wiibrew has recently started to remove homebrew applications that can install "custom IOS" titles to the console, so many of the current programs that have been used in order to do this may no longer provide this feature.
I apologize if this is the wrong board for this.
I'm interested in this, too. I'm pretty sure we'll need brkirch to chime in on this.
I'm fortunate enough to be still on System Menu v3.1 and using rebooter requires no additional work.
I remember having a bit of a struggle making sure that I can keep the use of rebooter if I ever need to update a specific IOS from a new game.
Having the ability to use the rebooter on every menu version would be ideal!
http://ftpii.googlecode.com/svn/iospatch/
I won't do it, somebody else has to do it if it's really wanted. Also sven_p meant that method is unstable and it should use at least read32/write32 to access the memory(i don't know if there are more problems with that code). And i say you should find the patch offset once and use it directly instead of searching. That would require people to install the latest IOS36, but with HW_AHBPROT that's not a problem anymore.
I'm looking into the possibility of using the HW_AHBPROT feature but don't expect too much. So far the only way that I have found to use HW_AHBPROT for channel loading is patching the IOS which is currently loaded in memory but unfortunately that isn't very reliable because the Broadway and Starlet CPUs don't share the same memory caches. The code that WiiPower linked to is an example of how it could be done, although there are several problems with that code that make it very unlikely I will use it (I've already tried directly patching ES_DiVerify in IOS58 but it results in an immediate crash, probably because the I-cache on the Starlet processor isn't updated).
FYI, I could see recently that wiixplorer starting from version r198 (http://code.google.com/p/wiixplorer/source/detail?r=198 (http://code.google.com/p/wiixplorer/source/detail?r=198)) has been able to use this AHBPROT feature to allow users of this application without patched IOS to access channels (just need ordinary IOS58). It looks like that they use magic_patcher.o binary file in their code (cannot see the real thing, at least with my limited knowledge).
Have you tried your ES_DiVerify in a regular IOS patcher? As far as i know the only IOS it's confirmed to work with are IOS36 and IOS38, and IOS37 and 57 seem to reject it.
Sven_p from TT also has several complains about this method of patching, and not only because "it only helps pirates". I think he was talking about stopping IOS manually, and then load a new IOS kernel from nand. Or something in that direction, this is outside my skill set. Maybe if you ask him nicely at #wiidev @efnet he helps you(or somebody else there).
I thought the point of HW_AHBPROT is that once this bit is set, the PPC has full access to everything, so we won't need IOS hacks anymore.
If this is the case....why does it look like you're using it to patch the IOS in memory? Can't you just do what the IOS used to do for you?
GeckoOS would still need to do some magic to identify as the channel that it is trying to play. this will allow the channel to access all its content files and use proper permissions when writing save data. since it doesnt matter if you have AHBPROT or not, the channel is still going to be using IOS to access the nand, you need to leave the IOS in the proper state that the channel expects it to be before giving control over to the channel.
the only ways i can think of to do this is to either patch the IOS in memory to allow ES_Identify() to work, or to overwrite the memory that the IOS is keeping the current TID, permissions, uid, and/or whatever else. either method can lead to breaking something if done incorrectly.