Mario Kart Wii Gecko Codes, Cheats, & Hacks

Full Version: Can Never Connect Online [mdmwii]
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Can Never Connect Online [mdmwii]

You will be attempting to connect online forever.

C21D0DB0 00000003
3A6000FC 9A640005
3A600000 3800FFFF
60000000 00000000

C21D0E50 00000003
3A6000FC 9A640005
3A600000 3800FFFF
60000000 00000000

C21D0D70 00000003
3A6000FC 9A640005
3A600000 3800FFFF
60000000 00000000

C21D11AC 00000003
3A6000FC 9A640005
3A600000 3800FFFF
60000000 00000000

Code created by: mdmwii
I tried the code several times and it always froze me. But if you change "stb r19, 5(r4)" to "stw r19, 4(r4)", then it works fine.
Was this on a clean ISO or patched one? When I've tested this code ages ago, it has always worked fine. (clean ISO using USB Loader GX settings and Wii settings to connect to ALTWFC)
I have tested the PAL code on the console, no other codes activated, to connect to Wiimmfi and NewWFC, both times it froze when trying to connect.
This source is very odd... lol...

li r19,252 #Set some random byte value, why 0xFC???
stb r19,5(r4) #Store it to the last byte slot of where the MAC resides in memory (MAC Address is 6 bytes in length)
li r19,0 #Reset r19 to null
li r0,-1 #Set r0 to -1

As an fyi: This code was originally claimed by the user Darkflare, but this person in the past way back in the day was known for simply lying about making codes, and he (at the time) had 0 knowledge of PPC ASM. So by default, credits were given to mdmwii.

Let's look around the code's hook address and see what's going on...
All address's are PAL btw.

Go to address 801D0DC4.

The game opens up /dev/net/ncd/manage with IOS permissions of 0 (typical for any /dev open)

The game is oepning up this module (via IOS/Starlet) to get the MAC Address from the Wifi Module. (as a side note, I wonder what hardware register is the location of the Wifi module, so we can just grab it directly w/o going thru IOS. Theres 0 documentation of this anywhere on the web...)

At address 801D0DF8 the vector table is configured for IOS_Iotclv, The output buffer (pointer) to where the MAC will be dumped at is set by the instruction at that address (lwz r8, -0x5F74 (r13)). r13 is a global variable, remains constant, always.

The game executes IOS_Ioctlv, thus IOS/Starlet dumps the MAC to the pointer that's at r13-0x5F74.

At address 801D0E48, the game loads the pointer of where the MAC is in memory, And sets up the rest of the args for a typical memcpy function call. r5 is set to 6 because the MAC is 6 bytes long ofc.

So the code is hooked at the address of the 'li r5, 6' instruction (amount of bytes for the memcpy function).

1st the code doesn't include the default/hook instruction at all, so its possible r5 value's will now be in a dynamic state, this could make the memcpy function copy over a SHIT TON of bytes by chance.

2nd, the code is only replacing the last byte of the MAC to this 0xFC value (won't effect how the game connects, this only changes the MAC value, you can set the MAC to w/e you want and the game shouldn't stall on connect; back in the ALTWFC days I've done all sorts of MAC combos with no issue)

3rd, the code is modifying r0 even though r0 gets overwritten and used as a temp register for the memcpy transfer. Aka its a useless instruction in the source/code.


So your suggestion to change the stb instruction to "stw r19, 4(r4) is overwriting something that's right after the MAC address in memory, which imo is causing the game to stall at the connect.

I doubt the memcpy r5 screwup is the 'cause' of the stall.

Try only using you stw instruction and add in the 'li r5, 6' so the memcpy works as intended. So the code is now just 2 instructions.
Thank you for the detailed description. I will test it as soon as I have time.