wololo.net/talk

Hi everyone,

I just updated/Edited the psplibdoc.xml based on some interesting strings i found from the PSP Vita 660 kernel dump that was posted here on wololo blog. This May not be useful to everyone but it may help some people.

All credit goes to http://silverspring.lan.st/ and everyone that helped/developed in the PSP scene. I only just changed some function name based on what i found on the prx.

Here are some of the functions i found there name for [Total of 10 functions]:
I don't know about anyone else but I like the names i see

By the Way, Before anyone ask how i know these name are correct, I not sure my self. I just based it on how these string appear inside the exported function the same way it appears in some of the function that we Already know there name from. Also that they seem to print out this name as a debug string like some of us developer do when we want to make sure a function is called.

Example of this is : As you can see, they have reference to those name inside there exported function. If anyone has a link of a tool like nidattack for mac lion, i willing to try to test out to see if it is the correct name for those functions.

Since i really do not know that much about the firmware... please dont be harsh

The odd numbers and letters are an adress of in the memory?

If yes..

Is the memory map of the psp firmware encapsulated from the one of the vita?`

If no..

Can we assume that we "know" the memory map position of the psp firmware?

thx in advance..

Thx, thecobra!

this sounds very interesting thnx for the info thecobra.

poettlr wrote:Since i really do not know that much about the firmware... please dont be harsh

The odd numbers and letters are an adress of in the memory?

Yes, In the first one where i post the 10 functions name that i found. The first hex numbers are the NID of the function, The second hex number is the offset of the function from where the prx is loaded in memory [prx memory location + offset = Function]

poettlr wrote: If yes..

Is the memory map of the psp firmware encapsulated from the one of the vita?`

I don't think i quite understand your question here. Are you asking if the address above are from the PSP Emulator in side the PSP Vita? if so, Then yes and no. They are based on the prx loaded from psp emulator on the vita but they aren't the complete address/the correct location in memory. Like i said above, they just offset inside the prx which is loaded into memory by the firmware.

poettlr wrote: If no..

Can we assume that we "know" the memory map position of the psp firmware?

thx in advance..

This one is also a yes and no answer, knowing the offset, we can somewhat know where in memory we can find the "rest" of the prx since we can map the address we get of the prx in memory with the address we get from the decompiler prx. No because, the PRX on the vita are a bit different than the one on the normal PSP. So they may be located at a different location than the ones on the normal PSP. We can do a search in memory to find where they loaded but we need a kernel exploit for that since most of the "Good" prx are loaded in kernel land.

Someone more experience than me can correct me if i am wrong.

thecobra wrote:

Code: Select all

0x1196472E [0x00005538] - sceKernelLoadModuleBufferMs
0x24EC0641 [0x00005638] - sceKernelLoadModuleBufferApp
0x1CF0B794 [0x00005CCC] - sceKernelLoadModuleBufferBootInitBtcnf
0x253AA17C [0x00005B40] - sceKernelLoadModuleBufferForExitVSHKernel
0x2F3F9B6A [0x00005724] - sceKernelLoadModuleBufferForLoadExecBufferVSHUsbWlan
0x4E38EA1D [0x00005C00] - sceKernelLoadModuleBufferForRebootKernel
0x4E62C48A [0x00005A68] - sceKernelLoadModuleBufferForKernel
0x61E3EC69 [0x00005478] - sceKernelLoadModuleBufferForExitGame
0x9236B422 [0x000059A8] - sceKernelLoadModuleBufferForExitVSHVSH
0xC13E2DE5 [0x000057F0] - sceKernelLoadModuleBufferForLoadExecBufferVSHUsbWlanDebug

Apparently like freddy just published, the NIDs are just the first 32 bits (little-endian) of the SHA1 of the function names
but here with your functions and their NIDs, this rule doesn't work so maybe you haven't the correct NIDs

wth wrote:

thecobra wrote:

Code: Select all

0x1196472E [0x00005538] - sceKernelLoadModuleBufferMs
0x24EC0641 [0x00005638] - sceKernelLoadModuleBufferApp
0x1CF0B794 [0x00005CCC] - sceKernelLoadModuleBufferBootInitBtcnf
0x253AA17C [0x00005B40] - sceKernelLoadModuleBufferForExitVSHKernel
0x2F3F9B6A [0x00005724] - sceKernelLoadModuleBufferForLoadExecBufferVSHUsbWlan
0x4E38EA1D [0x00005C00] - sceKernelLoadModuleBufferForRebootKernel
0x4E62C48A [0x00005A68] - sceKernelLoadModuleBufferForKernel
0x61E3EC69 [0x00005478] - sceKernelLoadModuleBufferForExitGame
0x9236B422 [0x000059A8] - sceKernelLoadModuleBufferForExitVSHVSH
0xC13E2DE5 [0x000057F0] - sceKernelLoadModuleBufferForLoadExecBufferVSHUsbWlanDebug

Apparently like freddy just published, the NIDs are just the first 32 bits (little-endian) of the SHA1 of the function names
but here with your functions and their NIDs, this rule doesn't work so maybe you haven't the correct NIDs

That doesn't apply to kernel nids in newer firmwares, kernel nids are random (I thought I explained they change?)

FrEdDy wrote:That doesn't apply to kernel nids in newer firmwares, kernel nids are random (I thought I explained they change?)

yeah you did I just only tested with user syscalls I guess lol
but I figured if kernel NIDs were changing, maybe that just meant they had been renamed ? xD

wth wrote:

FrEdDy wrote:That doesn't apply to kernel nids in newer firmwares, kernel nids are random (I thought I explained they change?)

yeah you did I just only tested with user syscalls I guess lol
but I figured if kernel NIDs were changing, maybe that just meant they had been renamed ? xD

Nah they are not renamed, I don't know how they are calculated anyways