PSP Slim & Mac Address

[Gh0st-UPMS]

Is there a different function to retrieve the Ethernet Address of a Slim compared to the Fat.

The following code from the samples works on a Fat but displays 000000000000 on a Slim.

Code: Select all

void getEthernetAddress(void)
{
	u8 sVal[8];
	int retVal;
	
	memset(sVal, 0, 7);
	retVal = sceWlanGetEtherAddr(sVal);
	
	if (retVal == 0)
    		printf("Wlan Ethernet Addr: %02X:%02X:%02X:%02X:%02X:%02X\n", sVal[0], sVal[1], sVal[2], sVal[3], sVal[4], sVal[5]);
    	else
    		printf("Error getting Wlan Ethernet Address (0x%08X)\n", retVal);
}

The code getting returned is of missing key value, so I'm gathering that this function accesses IDStorage if so what key contains it in the Slim.

Thanks

[J.F.]

The MAC address is key 0x44. That is NOT used by the psp for the MAC address, just for showing in the system info.

You should check the MacFixer source. The function it uses is sceNetGetLocalEtherAddr().

[Gh0st-UPMS]

The MAC address is key 0x44. That is NOT used by the psp for the MAC address, just for showing in the system info.

You should check the MacFixer source. The function it uses is sceNetGetLocalEtherAddr().

Thanks for the response J.F, I forgot to mention I'm running in service mode on my Slim TA-085v1, I checked the source out and the function still returns 00:00:00:00:00:00 on the slim.

Even trying to read key 0x44 to gain the Mac works 100% on my fat, but still displays 00:00:00:00:00:00 on the slim.

All operations are run in Service Mode with a kernel mode prx

Thanks

[moonlight]

The idstorage of slim is encrypted, and the idstorage.prx of the recovery 1.5/3.40 kernel is the one of 1.5 that cannot decrypt it, this is because I couldn't use the one of 3.40 because it was using some thread mutex functions that were introduced in 2.71 threadman.

This issue is already fixed in timemachine 1.5/3.40 mix by "emulating" those thread functions, and will be probably moved to next recovery firmware.

[Gh0st-UPMS]

The idstorage of slim is encrypted, and the idstorage.prx of the recovery 1.5/3.40 kernel is the one of 1.5 that cannot decrypt it, this is because I couldn't use the one of 3.40 because it was using some thread mutex functions that were introduced in 2.71 threadman.

This issue is already fixed in timemachine 1.5/3.40 mix by "emulating" those thread functions, and will be probably moved to next recovery firmware.

Thanks moonlight, I forgot about the encrypted IDStore on Slims, Cory just reminded me of that.

[J.F.]

Yeah, for low-level (service mode) access to the keys on a slim, look at cory's code as he did handle that decrypting. It's a big pain, but not much you can do about Sony doing these things.

[Gh0st-UPMS]

Yeah, for low-level (service mode) access to the keys on a slim, look at cory's code as he did handle that decrypting. It's a big pain, but not much you can do about Sony doing these things.

I don't have cory's code so I can't look at it. Your correct not much we can do about Sony making these changes:)