Is there a map of all the kernel memory usage corresponding to all the known STUBs ? Showing how much has been found at this time ?
Has anybody disassembled some of the kernel functions ? Does it teaches anything on the PSP hardware ?
STUBs Map
-
AudioMonster
- Posts: 37
- Joined: Wed Sep 07, 2005 3:41 am
- Contact:
> Is there a map of all the kernel memory usage corresponding to all the known STUBs ?
The STUBs are the short (8 byte) entries that are linked to the end of your program. They are used to bind to system entries (usually though a system trap to go from user to kernel mode)
The interesting part is looking at the system entries. Each of the system PRX files contains a number of public entry points. Look at the database for many of the commonly useful ones:
http://pspdev.ofcode.com/api.php?type=0
[contains user entries, some system and driver entries - but not all of them -- the interfaces within the system components themselves are more complicated]
----
Entries are named by a 32 bit number, called a "NID". It turns out this number is a 32-bit SHA1 hash of the function name. Check the archives for a brute-force dictionary search that found many of the names.
> Showing how much has been found at this time ?
All of the kernel memory dump/layout is known (ie. nothing hidden in the kernel space that isn't also in the PRX files)
There is a tool that will find the memory location for the NID named system entries.
There are two ways of disassembling the kernel components. Either take a kernel (and maybe a user) memory dump, find the entry points by matching the NIDs, and look at the whole system in a disassembler.
The other way is to look at the individual PRX modules (after being decrypted and expanded). The export tables give you a smaller view of one part of the system. You can also figure out the system dependencies easier.
---
> Has anybody disassembled some of the kernel functions ?
Yes, that's how many of the system functions have been figured out. It can be easier to figure things out by finding a caller of the function (eg: disassemble a game)
> Does it teaches anything on the PSP hardware ?
You bet, but it can be very complicated.
The STUBs are the short (8 byte) entries that are linked to the end of your program. They are used to bind to system entries (usually though a system trap to go from user to kernel mode)
The interesting part is looking at the system entries. Each of the system PRX files contains a number of public entry points. Look at the database for many of the commonly useful ones:
http://pspdev.ofcode.com/api.php?type=0
[contains user entries, some system and driver entries - but not all of them -- the interfaces within the system components themselves are more complicated]
----
Entries are named by a 32 bit number, called a "NID". It turns out this number is a 32-bit SHA1 hash of the function name. Check the archives for a brute-force dictionary search that found many of the names.
> Showing how much has been found at this time ?
All of the kernel memory dump/layout is known (ie. nothing hidden in the kernel space that isn't also in the PRX files)
There is a tool that will find the memory location for the NID named system entries.
There are two ways of disassembling the kernel components. Either take a kernel (and maybe a user) memory dump, find the entry points by matching the NIDs, and look at the whole system in a disassembler.
The other way is to look at the individual PRX modules (after being decrypted and expanded). The export tables give you a smaller view of one part of the system. You can also figure out the system dependencies easier.
---
> Has anybody disassembled some of the kernel functions ?
Yes, that's how many of the system functions have been figured out. It can be easier to figure things out by finding a caller of the function (eg: disassemble a game)
> Does it teaches anything on the PSP hardware ?
You bet, but it can be very complicated.
-
AudioMonster
- Posts: 37
- Joined: Wed Sep 07, 2005 3:41 am
- Contact:
I am still confused about the STUBs and have a few other questions.
> The STUBs are the short (8 byte) entries that are linked to the end of your program. They are used to bind to system entries (usually though a system trap to go from user to kernel mode)
So what kind of information do those 8 bytes contain ?
> There is a tool that will find the memory location for the NID named system entries.
Would you know where i can find that tool ?
If i take for example pspsdk-1.0+beta/sdk/audio/audio.S
STUB_START "sceAudio",0x40010000,0x00090005
STUB_FUNC 0x136CAF51,sceAudioOutputBlocking
STUB_FUNC 0xE2D56B2D,sceAudioOutputPanned
STUB_FUNC 0x13F592BC,sceAudioOutputPannedBlocking
STUB_FUNC 0x5EC81C55,sceAudioChReserve
STUB_FUNC 0x6FC46853,sceAudioChRelease
STUB_FUNC 0xE9D97901,sceAudioGetChannelRestLen
STUB_FUNC 0xCB2E439E,sceAudioSetChannelDataLen
STUB_FUNC 0x95FD0C2D,sceAudioChangeChannelConfig
STUB_FUNC 0xB7E1D8E7,sceAudioChangeChannelVolume
STUB_END
So i guess the STUB here is 0x4001000000090005 ?
Then follow the NIDs for each STUB function ? Is it SONY that calculated those 32-bit SHA1 hash from their own function names ( i guess? ) or is it a PSPSDK thing ? How did you find the actual function names ? Does it appear in "clear" in the Firmware or PRX files ?
How does it work to call -let's say- sceAudioSetChannelDataLen knowing the STUB 8bytes value and its NID ?
If i understood correctly the actual code for that function is either in the Firmware or in a PRX file, in that last case, how can PSPSDK provide the code from that particular prx file ?
Sorry for so many confused questions, i would really like to understand all that !
> The STUBs are the short (8 byte) entries that are linked to the end of your program. They are used to bind to system entries (usually though a system trap to go from user to kernel mode)
So what kind of information do those 8 bytes contain ?
> There is a tool that will find the memory location for the NID named system entries.
Would you know where i can find that tool ?
If i take for example pspsdk-1.0+beta/sdk/audio/audio.S
STUB_START "sceAudio",0x40010000,0x00090005
STUB_FUNC 0x136CAF51,sceAudioOutputBlocking
STUB_FUNC 0xE2D56B2D,sceAudioOutputPanned
STUB_FUNC 0x13F592BC,sceAudioOutputPannedBlocking
STUB_FUNC 0x5EC81C55,sceAudioChReserve
STUB_FUNC 0x6FC46853,sceAudioChRelease
STUB_FUNC 0xE9D97901,sceAudioGetChannelRestLen
STUB_FUNC 0xCB2E439E,sceAudioSetChannelDataLen
STUB_FUNC 0x95FD0C2D,sceAudioChangeChannelConfig
STUB_FUNC 0xB7E1D8E7,sceAudioChangeChannelVolume
STUB_END
So i guess the STUB here is 0x4001000000090005 ?
Then follow the NIDs for each STUB function ? Is it SONY that calculated those 32-bit SHA1 hash from their own function names ( i guess? ) or is it a PSPSDK thing ? How did you find the actual function names ? Does it appear in "clear" in the Firmware or PRX files ?
How does it work to call -let's say- sceAudioSetChannelDataLen knowing the STUB 8bytes value and its NID ?
If i understood correctly the actual code for that function is either in the Firmware or in a PRX file, in that last case, how can PSPSDK provide the code from that particular prx file ?
Sorry for so many confused questions, i would really like to understand all that !
i would be more interisted if anyone actually documented some of the hardware.... i'm in the (slow) process of doing that, and if someone has already done the one or the other thing in that area it would be a waste of time to duplicate their work.> Does it teaches anything on the PSP hardware ?
You bet, but it can be very complicated.
big endian
PSP is big endian so it is not 4001000000090005 in memory but 0000104005000900.
So be aware to search in reverse form in dumps.
There are no plain text reference of function names in the kernel.
As told, NID is 4 firsts bytes of the SHA-1 of the name of the function.
The only way to know the name is to brute force the NID via a dictionnary attack.
Is is already done at about 80%.
So be aware to search in reverse form in dumps.
There are no plain text reference of function names in the kernel.
As told, NID is 4 firsts bytes of the SHA-1 of the name of the function.
The only way to know the name is to brute force the NID via a dictionnary attack.
Is is already done at about 80%.
Re: big endian
The PSP is little endian.pspkrazy wrote:PSP is big endian so it is not 4001000000090005 in memory but 0000104005000900.
> I am still confused about the STUBs and have a few other questions.
> So what kind of information do those 8 bytes contain ?
For each entry there is one 8 byte "STUB" and one 4 byte "NID". They are stored in two separate tables.
The 0x40010000 and 0x00090005 values in STUB_START are module linkage flags (0x40010000 = user), a count (0x0009 entries) and a subversion (0x0005). The PSP is little-endian.
> Would you know where i can find that tool ?
Check the archives (it was released a long time ago, shortly after the kernel dump-er). It is probably obsolete by now. I haven't followed the current state of public disassembler tools.
> Does (the "sce" names for NID) appear in "clear" in the Firmware or PRX files ?
Some were found that way - few in the kernel files, more from games (and most done brute force with similar words) http://forums.ps2dev.org/viewtopic.php?t=1952
> How does it work to call -let's say- sceAudioSetChannelDataLen knowing the STUB 8bytes value and its NID ?
> If i understood correctly the actual code for that function is either in the Firmware or in a PRX file...
The system walks the import tables of your app (NIDs and STUBs).
The system PRXs *are* the firmware. The PRX files have a different set of tables for the exported entries.
> Sorry for so many confused questions, i would really like to understand all that !
This is now a detail of the PSPSDK. Look at how the SDK builds the tables.
Take a look at the 'pspstub.s' and "pspmoduleinfo.h" include files - everything is there.
----
> would be more interisted if anyone actually documented some of the hardware....
IMHO: that's less interesting. Most of the system functions hide the hardware details. See my consumer IR sample (part of the program parties directly on the hardware, the other part uses the system functions). At best you could hope to document the hardware to the extent the existing firmware uses it - not a general description.
> So what kind of information do those 8 bytes contain ?
For each entry there is one 8 byte "STUB" and one 4 byte "NID". They are stored in two separate tables.
The 0x40010000 and 0x00090005 values in STUB_START are module linkage flags (0x40010000 = user), a count (0x0009 entries) and a subversion (0x0005). The PSP is little-endian.
> Would you know where i can find that tool ?
Check the archives (it was released a long time ago, shortly after the kernel dump-er). It is probably obsolete by now. I haven't followed the current state of public disassembler tools.
> Does (the "sce" names for NID) appear in "clear" in the Firmware or PRX files ?
Some were found that way - few in the kernel files, more from games (and most done brute force with similar words) http://forums.ps2dev.org/viewtopic.php?t=1952
> How does it work to call -let's say- sceAudioSetChannelDataLen knowing the STUB 8bytes value and its NID ?
> If i understood correctly the actual code for that function is either in the Firmware or in a PRX file...
The system walks the import tables of your app (NIDs and STUBs).
The system PRXs *are* the firmware. The PRX files have a different set of tables for the exported entries.
> Sorry for so many confused questions, i would really like to understand all that !
This is now a detail of the PSPSDK. Look at how the SDK builds the tables.
Take a look at the 'pspstub.s' and "pspmoduleinfo.h" include files - everything is there.
----
> would be more interisted if anyone actually documented some of the hardware....
IMHO: that's less interesting. Most of the system functions hide the hardware details. See my consumer IR sample (part of the program parties directly on the hardware, the other part uses the system functions). At best you could hope to document the hardware to the extent the existing firmware uses it - not a general description.
-
AudioMonster
- Posts: 37
- Joined: Wed Sep 07, 2005 3:41 am
- Contact: