This source is very odd... lol...
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) http://www.wiibrew.org/wiki//dev/net/ncd/manage
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.
Code:
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
nopAs 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) http://www.wiibrew.org/wiki//dev/net/ncd/manage
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.