[JoostinOnline]

I've always had trouble understanding just how AHBPROT works and what it allows you to do (everybody just says "direct hardware access", but that's hardly a detailed description). I've done lots of searching but I can't find that much info on it. This post gave me some info on AHBPROT, but not in comparison to a cIOS.

Up until now my stupid pride has prevented me from asking this.

• Can enabling AHBPROT let you do things that you can't with a cIOS?
  
• Does AHBPROT have all the benefits of a cIOS?
  
• Do you have to write code for specific "cIOS patch equivalents" (nand, trucha, es_identify, etc.), or do you get all the benefits once you enable AHBPROT?

Edit: I forgot to mention that I'm not counting backup loading or USB2.0 in this comparison.

Edited by JoostinOnline, 31 January 2012 - 06:48 PM.

[Cyan]

I think there are some differences.
For example, the AHBPROT flags in USBLoaderGX allow access to the NAND to retrieve the installed channel's names.
Without the <no_ios_reload/> in the meta, the channels don't have any names and are just listed with the ASCII path. (for example 554e454f instead of the channel's name " USB loader GX Forwarder").


I have a question too:
Is it a single flag, or does each letter correspond to a security flag?
For example, is A = USB access, H = Nand access, etc.?

Or is "HW_AHBPROT" just the name of the single bit?

[SifJar]

HW_AHBPROT refers one bit in the TMD of a title, that when it is set, syscall 56 (i think it's 56. maybe 54. something like that anyway) is called during the loading of said title. This syscall sets a register called HW_AHBPROT, which then allows PPC code to access any/all hardware. Usually, IOS is all that has access to hardware. But IOS also has security (hence, IOS patches to defeat said security). This means that IOS can be bypassed entirely, but would mean that drivers for all hardware would have to be written for PPC [I think this is accurate]. Instead, that hardware access is generally used to disable the protection on MEM2 (which is were the currently loaded IOS is found). This means that PPC code can then directly patch the current IOS, in memory (rather than permanently patching the IOS on NAND). So then security features of IOS are disabled by memory patches, and IOS can be used to access hardware as normal, but without having to worry about the security features of IOS.

As for in comparison to cIOS - you won't get it loading extra modules or switching out modules for ones of a different size. i.e. the stuff needed for warez/"backups".

[WiiBricker]

From what I understand AHBPROT unlike cIOS doesn't have the necessary modules for backup loading. So if you are using cIOS for backup loading purposes you might as well stick to it entirely.

[JoostinOnline]

One thing that made me wonder is that I've been unable to install some cIOS wads via Sharpii (with AHBPROT enabled), but I could if I switched to using cIOS249[38]d2x v7. Is that because of Sharpii, or a limitation of AHBPROT?

[SifJar]

JoostinOnline, on 31 January 2012 - 06:47 PM, said:

One thing that made me wonder is that I've been unable to install some cIOS wads via Sharpii (with AHBPROT enabled), but I could if I switched to using cIOS249[38]d2x v7. Is that because of Sharpii, or a limitation of AHBPROT?

It's not a limitation of AHBPROT, but it could very well be of the the installer. If you're trying to overwrite an existing IOS, you probably need NAND permissions patch or something like that, whereas the Sharpii WAD installer is based on (I think) an installer for custom channels, which wouldn't need NAND permissions, just fakesigning patch, so it probably just doesn't have the NAND permissions patch. If that patch was added to the installer, it would probably work via Sharpii.

EDIT: Had a look, it does seem to have NAND permissions patch. Probably some other patch it's missing though.

Edited by SifJar, 31 January 2012 - 07:05 PM.

[obcd]

The HW_AHBPROT is one of the starlet registers. it controls if the ppc has direct access to the hardware or not.
It's offical use is somewhere in gamecube mode to allow cube games to control the dvd drive.
Other bit's of that register allow access to other hardware.