| View previous topic :: View next topic |
| Author |
Message |
Gh0st-UPMS
Joined: 17 Feb 2008
Posts: 23
|
 Posted: Sat Mar 22, 2008 10:13 am Post subject: PSP Slim & Mac Address |
 |
|
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: |
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 |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Sat Mar 22, 2008 10:49 am Post subject: |
|
|
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(). |
|
| Back to top |
|
|
Gh0st-UPMS
Joined: 17 Feb 2008
Posts: 23
|
| Posted: Sat Mar 22, 2008 7:27 pm Post subject: |
|
|
| J.F. wrote: | 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 |
|
| Back to top |
|
|
moonlight
Joined: 26 Oct 2005
Posts: 567
|
| Posted: Sat Mar 22, 2008 9:04 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Gh0st-UPMS
Joined: 17 Feb 2008
Posts: 23
|
| Posted: Sat Mar 22, 2008 11:52 pm Post subject: |
|
|
| moonlight wrote: | 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. |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Sun Mar 23, 2008 4:35 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Gh0st-UPMS
Joined: 17 Feb 2008
Posts: 23
|
| Posted: Sun Mar 23, 2008 11:51 pm Post subject: |
|
|
| J.F. wrote: | | 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:) |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
