Some troubles with sceLed lib and nidresolver

ne0h · Post by **ne0h** » Sat Jun 27, 2009 12:37 am

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

Torch · Post by **Torch** » Sat Jun 27, 2009 9:43 am

Lot of rare kernel NIDs are not handled by the NIDs Resolver.

Davee · Post by **Davee** » Sun Jun 28, 2009 10:52 pm

Can you post the nids?

Torch · Post by **Torch** » Sun Jun 28, 2009 11:16 pm

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?

phobox · Post by **phobox** » Tue Jun 30, 2009 12:59 am

but why not updatng the pspsdk with the feature to resolve the nid at compile time? specifying the fw version in the makefile...

Dariusc123456 · Post by **Dariusc123456** » Tue Jun 30, 2009 3:57 am

If sony randomize the nids, what limit us using those commands?

cory1492 · Post by **cory1492** » Tue Jun 30, 2009 5:40 am

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.

phobox · Post by **phobox** » Tue Jun 30, 2009 6:12 am

cory you are definetly right! didn't tought about that...nidresolver is much much better

Davee · Post by **Davee** » Tue Jun 30, 2009 9:24 am

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)

Torch · Post by **Torch** » Tue Jun 30, 2009 9:27 am

Whats wrong with his code then?

Davee · Post by **Davee** » Tue Jun 30, 2009 9:28 am

Torch wrote:Whats wrong with his code then?

Perhaps loaded before nid resolver is active? I dunno.

Torch · Post by **Torch** » Tue Jun 30, 2009 9:31 am

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?

Davee · Post by **Davee** » Tue Jun 30, 2009 9:39 am

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).

Dariusc123456 · Post by **Dariusc123456** » Tue Jun 30, 2009 11:56 am

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?

Torch · Post by **Torch** » Tue Jun 30, 2009 6:08 pm

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.

Dariusc123456 · Post by **Dariusc123456** » Tue Jun 30, 2009 6:15 pm

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)."?

Torch · Post by **Torch** » Tue Jun 30, 2009 6:29 pm

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.

Dariusc123456 · Post by **Dariusc123456** » Tue Jun 30, 2009 7:17 pm

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?

Torch · Post by **Torch** » Tue Jun 30, 2009 8:45 pm

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.

Davee · Post by **Davee** » Wed Jul 01, 2009 2:51 am

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.

ne0h · Post by **ne0h** » Wed Jul 01, 2009 4:33 am

Sorry, I've seen the post now...
This is the nid's (of 4.01 ):

Code: Select all

sceSyscon_driver_363EF26A
sceSyscon_driver_2B476F99
InterruptManagerForKernel_B940A5BF
InterruptManagerForKernel_169FC5A3

Davee · Post by **Davee** » Wed Jul 01, 2009 9:06 am

ne0h wrote:Sorry, I've seen the post now...
This is the nid's (of 4.01 ):
Code: Select all
sceSyscon_driver_363EF26A
sceSyscon_driver_2B476F99
InterruptManagerForKernel_B940A5BF
InterruptManagerForKernel_169FC5A3

Yes that would be your problem. Use the 3.52 nids ;)

cory1492 · Post by **cory1492** » Wed Jul 01, 2009 6:21 pm

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.

ne0h · Post by **ne0h** » Thu Jul 02, 2009 3:59 am

Davee wrote:
ne0h wrote:Sorry, I've seen the post now...
This is the nid's (of 4.01 ):
Code: Select all
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!!