Applying AHBPROT to Banana Saves

I'm trying to get Banana Saves working without a cIOS using AHBPROT. Banana Patcher was only a simple modification of another application. However, I'm a noob when it comes to using the SU identification Wii methods, TMDs, etc, so this can be a good way to learn how it really works.


You can get the original code in the Banana Saves page at Wiibrew.
I only modified the main to ignore the IOS Reload and to apply AHBPROT patches (either running from wiiload or from SD with the patches are applied correctly). I got the famous iospatch.c file from ftpii. AHBPROT seems to work perfectly (I tested it and I can mount ISFS, read files, etc).


Then the problem comes here in Sysmenu_Identify at sysmenu.c:

/* Retrieve TMD */
ret = ES_GetStoredTMD(SYSMENU_TITLEID, p_tmd, tmd_len);
if (ret < 0)
	goto out;

/* Identify as system menu */
ret = ES_Identify(p_certs, certs_len, p_tmd, tmd_len, p_tik, tik_len, NULL);

ES_Identify returns -1017.

I guess that identifying with a different TMD is breaking AHBPROT somehow (maybe I'm wrong?).

So I tried to comment the ES_Identify. Then when trying to load the System Menu executable into memory before applying the copy protected savegames patch, it fails at:

ret = ((tmd *)SIGNATURE_PAYLOAD(p_tmd))->boot_index;

It doesn't get the System Menu executable index correctly (and later it's unable to load the executable into memory due to an incorrect index).


I guess that using AHBPROT will make Banana Saves less complex, but as I don't understand all identification functions it's hard for me. Anyone can help me?

Sorry if I can't explain it better, but english isn't my main language.



Edited 2 time(s). Last edit at 01/24/2011 11:47PM by marc_max.

Reply Quote

why are you trying to identify as the super user?
what do you think the iospatch.c has done for you?

basically what the ios patcher.c s doing is useless for you. the patches it is applying are not the ones you are needing. it is patching signature checking, unencrypted disc read limit, & FS permissions. The IOS running still does not let you use ES_Identify(), SetUID(), or anything that will let you assume the role of system menu.

Quote
giantpune
why are you trying to identify as the super user?
what do you think the iospatch.c has done for you?

basically what the ios patcher.c s doing is useless for you. the patches it is applying are not the ones you are needing. it is patching signature checking, unencrypted disc read limit, & FS permissions. The IOS running still does not let you use ES_Identify(), SetUID(), or anything that will let you assume the role of system menu.

I have these patches:

static const u8 setuid_old[] = { 0xD1, 0x2A, 0x1C, 0x39 };
static const u8 setuid_patch[] = { 0x46, 0xC0 };
const u8 es_identify_old[] = { 0x28, 0x03, 0xD1, 0x23 };
const u8 es_identify_patch[] = { 0x00, 0x00 };

I assume that ES_Identify & SetUID are patched. The patches are applied correctly, or at least the apply_patch function returns true.

from your first post, it is clear that either the ES_Identify patch is not applied (correctly), or does not work like you think it does. -1017 means it isnt working.

Or more likely your app has inherited HBC's ident (since IOS wasn't reloaded), IOS knows better than to let you identify as something else if it's already been done once.

As far as i know the IOS patch for ES_Identify which allows you to use ES_Identify only works with certain IOS. I don't think that any 5x or higher is compatible. If you manage to load IOS36 with AHBPROT, then i guess the patch might work.

But why the complicated way? Don't you have the source code for a nand permissions patch? With that you just have full read/write access to the whole nand. And ES_Identify, if you get it to work, should only work once per IOS Reload anyways.

	u8 old_table[] = {0x42, 0x8B, 0xD0, 0x01, 0x25, 0x66};
	u8 new_table[] = {0x42, 0x8B, 0xE0, 0x01, 0x25, 0x66};

Quote
WiiPower
As far as i know the IOS patch for ES_Identify which allows you to use ES_Identify only works with certain IOS. I don't think that any 5x or higher is compatible.

Thank you, I didn't know that.

Quote
WiiPower
But why the complicated way? Don't you have the source code for a nand permissions patch? With that you just have full read/write access to the whole nand.

	u8 old_table[] = {0x42, 0x8B, 0xD0, 0x01, 0x25, 0x66};
	u8 new_table[] = {0x42, 0x8B, 0xE0, 0x01, 0x25, 0x66};

I already had that patch, of course. As I said on my first post I can read files using the ISFS functions (the only patch that seemed to fail was ES_Identify).

The problem is that the original code reads the contents with ES_OpenContent, ES_ReadContent, etc. And I guess that the NAND permissions patch doesn't patch these functions. It should open the content that has the System Menu executable (the file index was previously got correctly), but I guess the problem is it's not identified as System Menu and then it tries to open a content from HBC.
I tried to change the ES functions for ISFS equivalents with no luck. The contents are read correctly, but when it jumps to the executable I get a garbled screen stack dump.

You need 32 bytes aligned buffers, you know that?

Maybe there's a problem with the content numbers? I'm not sure if the content numbers match the file names on nand. Did you check that you try to load files that exist?

Also what do you mean exaxtly with "when it jumps to the executable"?

Quote
WiiPower
You need 32 bytes aligned buffers, you know that?

Maybe there's a problem with the content numbers? I'm not sure if the content numbers match the file names on nand. Did you check that you try to load files that exist?

Also what do you mean exaxtly with "when it jumps to the executable"?

Yes, I use memalign(32... instead of a simple malloc.

The content numbers don't match with the file names on NAND. The content index is 8 (4.2E) but that's not the content ID (which is 0000008b).

Anyway... I found the problem: I was reading the wrong file. I got it to work somehow...
...but it still doesn't work correctly.

Now it boots System Menu finally but it gives an error message: "The data is corrupted." and you can't do anything but power off.
Curiously, if I use the cIOS+ES_Identify combo it works (the only change are the ES commands that were replaced by the ISFS ones). I thought it was an IOS/permissions problem so I tried to reload IOS70 after applying all patches, but I still get the same error.

Any ideas?

Booting a NAND title when you're not identified as that title isn't going to end well.

Quote
tueidj
Booting a NAND title when you're not identified as that title isn't going to end well.

It seems that I'm going to need ES_Identify after all.
If the IOS patch for ES_Identify only works for IOS36... Is there any way to reload IOS and keep AHBPROT?
Or maybe there is an ES_Identify patch for newer IOS somewhere?

There is a way to reload IOS and keep AHBPROT, but I have never seen any source code for doing so.