| View previous topic :: View next topic |
| Author |
Message |
ne0h
Joined: 21 Feb 2008
Posts: 386
|
 Posted: Sat Jun 27, 2009 12:37 am Post subject: Some troubles with sceLed lib and nidresolver |
 |
|
Some days ago I've completely reversed the led.prx, the code works but when I've tried to run it the W-LAN led stay on and won't get off, now I've found the problem!
There's some functions from syscon_driver and InterruptManager that have changed they NID's from the previous fw version, but I've thinked that it want be a problem because of Nidresolver, but it apparently won't work and then I've tried to compile the prx with the nid's of it's fw and now it works!
My question is why nidresolver won't handle this nids?
Because are not being loaded or because this calls are not important and then where not "added" to nidresolver ( probable )?
If is possible I want only a explanation, only to understand, nothing esle...
Thanks,
ne0h
_________________
Get Xplora! |
|
| Back to top |
|
 |
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Sat Jun 27, 2009 9:43 am Post subject: |
|
|
| Lot of rare kernel NIDs are not handled by the NIDs Resolver. |
|
| Back to top |
|
|
Davee
Joined: 22 Jun 2009
Posts: 59
|
| Posted: Sun Jun 28, 2009 10:52 pm Post subject: |
|
|
| Can you post the nids? |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Sun Jun 28, 2009 11:16 pm Post subject: |
|
|
Of the imports? They've on SilverSpring's site.
From 4.05/5.00/5.01
I'm guessing the InterruptManagerForKernel ones are the same <3.5x functions, just randomized.
0x668A0FF9 InterruptManagerForKernel_668A0FF9
0xCFFA1857 InterruptManagerForKernel_CFFA1857
Theres an additional unknown import from sceSyscon_driver. Guessing the other two are the same <3.5x ones.
0x42E443D6 sceSyscon_driver_42E443D6
0x4B8F3502 sceSyscon_driver_4B8F3502
0x8A65C819 sceSyscon_driver_8A65C819
Are these unresolved? |
|
| Back to top |
|
|
phobox
Joined: 24 Mar 2008
Posts: 140
|
| Posted: Tue Jun 30, 2009 12:59 am Post subject: |
|
|
but why not updatng the pspsdk with the feature to resolve the nid at compile time? specifying the fw version in the makefile...
_________________
Ciao! from Italy |
|
| Back to top |
|
|
Dariusc123456
Joined: 12 Aug 2008
Posts: 394
|
| Posted: Tue Jun 30, 2009 3:57 am Post subject: |
|
|
If sony randomize the nids, what limit us using those commands?
_________________
PSHN - Playstation Hacking Network
PSX/PS1 - HACK - Game Shark
PS2 - HACK - Swap
PSP - HACK - Pandora
PS3 - ? |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Tue Jun 30, 2009 5:40 am Post subject: |
|
|
| phobox wrote: | | but why not updatng the pspsdk with the feature to resolve the nid at compile time? specifying the fw version in the makefile... |
So you are saying every PSP developer (new or not) should release multiple binaries for all possible firmware versions, test each one on all versions for release, as well as provide future updates for new versions - rather than have to reverse to find a couple missed NIDs occasionally and keep overall backwards compatibility? As well as having the makefile/toolchain process that much more complex and needing updates that much more often? (I'd think most would just settle happily for 5.50 psar dumper at this point let alone fully resolved stubs... while 5.51 is already out)
Consider: in a couple weeks time with multiple people contributing in a thread here only a percentage of the NIDs that m33 resolves were done and not in any real usable form... I think it would be more work than required to add all that to the SDK. There was an abandoned pc program that did something similar to what the resolver does.
| Dariusc123456 wrote: | | If sony randomize the nids, what limit us using those commands? |
Finding the correct NID "by hand" and resolving it yourself in your program per version, possibly requesting it be added to the resolver for the future. Not big limits, really, just time consuming. Thank m33 for not exposing more asm illiterates to that painfully slow process. |
|
| Back to top |
|
|
phobox
Joined: 24 Mar 2008
Posts: 140
|
| Posted: Tue Jun 30, 2009 6:12 am Post subject: |
|
|
cory you are definetly right! didn't tought about that...nidresolver is much much better
_________________
Ciao! from Italy |
|
| Back to top |
|
|
Davee
Joined: 22 Jun 2009
Posts: 59
|
| Posted: Tue Jun 30, 2009 9:24 am Post subject: |
|
|
| Torch wrote: | Of the imports? They've on SilverSpring's site.
From 4.05/5.00/5.01
I'm guessing the InterruptManagerForKernel ones are the same <3.5x functions, just randomized.
0x668A0FF9 InterruptManagerForKernel_668A0FF9
0xCFFA1857 InterruptManagerForKernel_CFFA1857
Theres an additional unknown import from sceSyscon_driver. Guessing the other two are the same <3.5x ones.
0x42E443D6 sceSyscon_driver_42E443D6
0x4B8F3502 sceSyscon_driver_4B8F3502
0x8A65C819 sceSyscon_driver_8A65C819
Are these unresolved? |
InterruptManagerForKernel_668A0FF9 = resolved (0x8A389411)
InterruptManagerForKernel_CFFA1857 = resolved (0xCA04A2B9)
sceSyscon_driver_42E443D6 = resolved (0xEC37C549)
sceSyscon_driver_4B8F3502 = resolved (0x8EDF1AD7)
sceSyscon_driver_8A65C819 = resolved (0xE00BFC9E) |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Tue Jun 30, 2009 9:27 am Post subject: |
|
|
| Whats wrong with his code then? |
|
| Back to top |
|
|
Davee
Joined: 22 Jun 2009
Posts: 59
|
| Posted: Tue Jun 30, 2009 9:28 am Post subject: |
|
|
| Torch wrote: | | Whats wrong with his code then? |
Perhaps loaded before nid resolver is active? I dunno. |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Tue Jun 30, 2009 9:31 am Post subject: |
|
|
| Davee wrote: | | Torch wrote: | | Whats wrong with his code then? |
Perhaps loaded before nid resolver is active? I dunno. |
He hasn't mentioned what he's doing with it. Maybe hes fully rewritten it and replaced the original one in flash0 :S
After which point is the resolver active?
How does the resolver work BTW, is it manually entered for each firmware or is it dynamically built based on analyzing the code? |
|
| Back to top |
|
|
Davee
Joined: 22 Jun 2009
Posts: 59
|
| Posted: Tue Jun 30, 2009 9:39 am Post subject: |
|
|
| Torch wrote: | | Davee wrote: | | Torch wrote: | | Whats wrong with his code then? |
Perhaps loaded before nid resolver is active? I dunno. |
He hasn't mentioned what he's doing with it. Maybe hes fully rewritten it and replaced the original one in flash0 :S
After which point is the resolver active?
How does the resolver work BTW, is it manually entered for each firmware or is it dynamically built based on analyzing the code? |
During the systemctrl is loading. I cannot remember when led.prx is loaded as it hasn't been really much of a "core" module.
It hooks the import linking and basically searches through an onboard structure for nid matches and resolves to the 3.52 nid (or oldest). |
|
| Back to top |
|
|
Dariusc123456
Joined: 12 Aug 2008
Posts: 394
|
| Posted: Tue Jun 30, 2009 11:56 am Post subject: |
|
|
Is it possible to patch the prx nid table with the current nids they should be and not use the nid resolver? Or are they both the same?
_________________
PSHN - Playstation Hacking Network
PSX/PS1 - HACK - Game Shark
PS2 - HACK - Swap
PSP - HACK - Pandora
PS3 - ? |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Tue Jun 30, 2009 6:08 pm Post subject: |
|
|
| Dariusc123456 wrote: | | Is it possible to patch the prx nid table with the current nids they should be and not use the nid resolver? Or are they both the same? |
... Thats exactly what it does in memory when the PRX is loaded.
| Davee wrote: | | It hooks the import linking and basically searches through an onboard structure for nid matches and resolves to the 3.52 nid (or oldest). |
What I wanted to know is whether this structure/table is manually updated with the new nids for each firmware or the nidsresolver builds the table at boot by comparing the code to identify the functions, or whether moonlight just uses an automated tool once to build the table first and puts that table in the nidsresolver for that firmware.
Last edited by Torch on Tue Jun 30, 2009 6:26 pm; edited 1 time in total |
|
| Back to top |
|
|
Dariusc123456
Joined: 12 Aug 2008
Posts: 394
|
| Posted: Tue Jun 30, 2009 6:15 pm Post subject: |
|
|
| Torch wrote: | | Dariusc123456 wrote: | | Is it possible to patch the prx nid table with the current nids they should be and not use the nid resolver? Or are they both the same? |
... Thats exactly what it does in memory when the PRX is loaded.
| Dariusc123456 wrote: | | It hooks the import linking and basically searches through an onboard structure for nid matches and resolves to the 3.52 nid (or oldest). |
What I wanted to know is whether this structure/table is manually updated with the new nids for each firmware or the nidsresolver builds the table at boot by comparing the code to identify the functions, or whether moonlight just uses an automated tool once to build the table first and puts that table in the nidsresolver for that firmware. |
But if the nids are just "randomize", then how come everyone having problems loading the prx modules?
Torch, look at what you put. When did I say "It hooks the import linking and basically searches through an onboard structure for nid matches and resolves to the 3.52 nid (or oldest)."?
_________________
PSHN - Playstation Hacking Network
PSX/PS1 - HACK - Game Shark
PS2 - HACK - Swap
PSP - HACK - Pandora
PS3 - ? |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Tue Jun 30, 2009 6:29 pm Post subject: |
|
|
| Dariusc123456 wrote: | | But if the nids are just "randomize", then how come everyone having problems loading the prx modules? |
Because in the flash0: modules there are many functions and when the NIDs are randomized we don't know which function is the same old function from 3.52 unless we manually compare all the functions to check if its the same. If its the same, then we know that the new NID is a randomized version of the corresponding 3.52 NID. |
|
| Back to top |
|
|
Dariusc123456
Joined: 12 Aug 2008
Posts: 394
|
| Posted: Tue Jun 30, 2009 7:17 pm Post subject: |
|
|
Even though we dont know which function goto what nid, how come we cant just change the nids in the imports so tat it will work on that firmware?
_________________
PSHN - Playstation Hacking Network
PSX/PS1 - HACK - Game Shark
PS2 - HACK - Swap
PSP - HACK - Pandora
PS3 - ? |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Tue Jun 30, 2009 8:45 pm Post subject: |
|
|
| Dariusc123456 wrote: | | Even though we dont know which function goto what nid, how come we cant just change the nids in the imports so tat it will work on that firmware? |
You can edit the file and put the new NIDs. But your app will work ONLY on that firmware version. See cory's post. |
|
| Back to top |
|
|
Davee
Joined: 22 Jun 2009
Posts: 59
|
| Posted: Wed Jul 01, 2009 2:51 am Post subject: |
|
|
| I have no idea if Alex uses an automatic nid updater thing. I'd imagine I'd be a mix of both manual checking and tools. I ripped it out of systemctrl myself. |
|
| Back to top |
|
|
ne0h
Joined: 21 Feb 2008
Posts: 386
|
| Posted: Wed Jul 01, 2009 4:33 am Post subject: |
|
|
Sorry, I've seen the post now...
This is the nid's (of 4.01 ):
| Code: |
sceSyscon_driver_363EF26A
sceSyscon_driver_2B476F99
InterruptManagerForKernel_B940A5BF
InterruptManagerForKernel_169FC5A3 |
_________________
Get Xplora! |
|
| Back to top |
|
|
Davee
Joined: 22 Jun 2009
Posts: 59
|
| Posted: Wed Jul 01, 2009 9:06 am Post subject: |
|
|
| ne0h wrote: | Sorry, I've seen the post now...
This is the nid's (of 4.01 ):
| Code: |
sceSyscon_driver_363EF26A
sceSyscon_driver_2B476F99
InterruptManagerForKernel_B940A5BF
InterruptManagerForKernel_169FC5A3 |
|
Yes that would be your problem. Use the 3.52 nids ;) |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Wed Jul 01, 2009 6:21 pm Post subject: |
|
|
prxtool has some of what is needed to resolve many NIDs, as the user exports (used by 'legacy' built UMD games) aren't ever going to be randomized but still correspond to the randomized kernel exports linked to the same binary function. Doesn't cover them all, but it would hit a good many of those in the sdk.
| Torch wrote: | | You can edit the file and put the new NIDs. But your app will work ONLY on that firmware version. See cory's post. |
Well, it's pretty simple to set up a function pointer, use sceGetVersion and then resolve function address onto the pointer using the correct NID for the version you are using rather than rely solely on internal stub resolution. Still requires updating on each new randomization if it's not added to the resolver, but at least we aren't also updating every single randomized NID that is used.
It is also a good argument to try to stick to usermode homebrew, as I said, these NID randomizations shouldn't break those. |
|
| Back to top |
|
|
ne0h
Joined: 21 Feb 2008
Posts: 386
|
| Posted: Thu Jul 02, 2009 3:59 am Post subject: |
|
|
| Davee wrote: | | ne0h wrote: | Sorry, I've seen the post now...
This is the nid's (of 4.01 ):
| Code: |
sceSyscon_driver_363EF26A
sceSyscon_driver_2B476F99
InterruptManagerForKernel_B940A5BF
InterruptManagerForKernel_169FC5A3 |
|
Yes that would be your problem. Use the 3.52 nids ;) |
I've already resolved, and the problem is that I've used 3.52 nid's on 4.01 then to resolve I've used the 4.01 nid's!
Anyway thanks!!
_________________
Get Xplora! |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
