FW 5.0.0 has wrong OSDynLoad_Acquire address correct one is 0x01029F70

[z0mb3]

libwiiu/src/coreinit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libwiiu/src/coreinit.h b/libwiiu/src/coreinit.h
index 5753a21..a6bde0c 100755
--- a/libwiiu/src/coreinit.h
+++ b/libwiiu/src/coreinit.h
@@ -24,7 +24,7 @@
#define OSFatal ((void ()(char msg))0x0102D01C)
#define __os_snprintf ((int()(char s, int n, const char * format, ... ))0x0102b9ac)
#elif VER==500
-#define OSDynLoad_Acquire ((void ()(char rpl, unsigned int handle))0x01029CD8)
+#define OSDynLoad_Acquire ((void ()(char* rpl, unsigned int handle))0x01029F70)
#define OSDynLoad_FindExport ((void ()(unsigned int handle, int isdata, char symbol, void *address))0x0102B3E4)
#define OSFatal ((void ()(char* msg))0x01030ECC)
#define __os_snprintf ((int()(char s, int n, const char * format, ... ))0x0102ECE0)

[Relys]

I was stuck on 5.0.0 initially when the exploit was developed. I observed Chadderz blindly find new ROP gadgets for 5.0.0 using an information disclosure via a side channel attack (1 bit in length if system crashed or not). 0x01029CD8 is the correct address for FW 5.0.0 for US models. Please provide more proof if otherwise and I'll gladly fix. I'll keep this issue open for further comments in the mean time. Thanks.

[z0mb3]

This is from coreinit.rpl

.text:0200DF70 # =============== S U B R O U T I N E =======================================
.text:0200DF70
.text:0200DF70
.text:0200DF70                 .globl OSDynLoad_Acquire
.text:0200DF70 OSDynLoad_Acquire:                      # CODE XREF: .text:02028320�p
.text:0200DF70                                         # DATA XREF: .fexports:C00014D8�o
.text:0200DF70
.text:0200DF70 .set var_30, -0x30
.text:0200DF70 .set var_2C, -0x2C
.text:0200DF70 .set var_28, -0x28
.text:0200DF70 .set var_20, -0x20
.text:0200DF70 .set arg_4,  4
.text:0200DF70
.text:0200DF70 # FUNCTION CHUNK AT .text:0200DCD8 SIZE 00000298 BYTES
.text:0200DF70
.text:0200DF70                 li        r5, 0
.text:0200DF74                 b         loc_200DCD8
.text:0200DF74 # End of function OSDynLoad_Acquire
.text:0200DF74

loc_200DCD8 is just a sub

[Relys]

Ah, so does the subroutine at 0x200DCD8 end up branching to OSDynLoad_Acquire at 0x01029F70 at some point? Else, why does 0x200DCD8 work? Once we solve that mystery, I can go ahead and submit a pull request. Thanks again for your help! :)

[z0mb3]

0x01029F70 branches to 0x01029CD8 (==loc_200DCD8) after some argument handling

Actually taking only 0x01029CD8 the OSDynLoad_Acquire seems like it is working, but it is behaving different to the other OS defined OSDynLoad_Acquire.

For example the defined function address in libwiiu always loads sndcore2 with result -1
0x01029F70 loads the real requested snd_core and works.
I tested this on my 5.0.0 wii u and taking the defined value from libwiiu made problems on my port of loadiine_gx2. All problems are solved with the new address and the function behaves like the ones defined on other FWs.

[Relys]

Exactly the explanation I was looking for. Very nice. Thanks for your help. :)