PRX: Difference between revisions
Jump to navigation
Jump to search
Roothorick (talk | contribs) No edit summary |
Roothorick (talk | contribs) (Correcting what I had. Total overhaul.) |
||
Line 1: | Line 1: | ||
scetool can decrypt SPRX's, producing an ELF... or is it? Not really. It has an ELF header but... | scetool can decrypt SPRX's, producing an ELF... or is it? Not really. It has an ELF header but... | ||
First LOAD | First LOAD segment, paddr points to the descriptor for the "dependency table" or "deptable" for short: | ||
NOTE: All addresses inside the file assume the ELF header isn't there (basically add 0xE0 to all addresses.) | NOTE: All addresses inside the file assume the ELF header isn't there (basically add 0xE0 to all addresses.) | ||
Line 13: | Line 11: | ||
| +0 | | +0 | ||
| long | | long | ||
| | | Always(?) 0x101 | ||
|- | |- | ||
| +4 | | +4 | ||
| char[ | | char[28] | ||
| Name of the | | Name of this PRX, padded out with zeroes. Doesn't necessarily match the file name(why?) | ||
|- | |- | ||
| + | | +32 | ||
| long | | long | ||
| | | A unique module ID? Gets used a lot later... | ||
|- | |- | ||
| + | | +36 | ||
| long | | long | ||
| Points to | | Points to the deptable header | ||
|- | |- | ||
| + | | +40 | ||
| long | | long | ||
| Points to | | Points to the END of the deptable header | ||
|- | |- | ||
| + | | +44 | ||
| long | | long | ||
| Points to start of first | | Points to the start of first deptable entry | ||
|- | |- | ||
| + | | +48 | ||
| long | | long | ||
| points to end of | | points to the end of the LAST deptable entry | ||
|} | |} | ||
Deptable header: | |||
{| class="wikitable" | {| class="wikitable" | ||
! Offset | ! Offset | ||
Line 47: | Line 45: | ||
|- | |- | ||
| +0 | | +0 | ||
| long[ | | long[5] | ||
| ? | | Always(?) 0x1C000000, 0x80000002, 0x10000, 0, 0 | ||
|- | |- | ||
| + | | +20 | ||
| | | long | ||
| | | Points to three longs of... something. The start of the mystery table. | ||
|- | |- | ||
| +24 | | +24 | ||
| long | | long | ||
| . | | Points to three pointers in the mystery table. Two go to pointers to subroutines in the funcpointer table, the third goes back to the deptable descriptor. | ||
|} | |} | ||
Entry in the deptable: | |||
{| class="wikitable" | {| class="wikitable" | ||
! Offset | ! Offset | ||
Line 66: | Line 64: | ||
|- | |- | ||
| +0 | | +0 | ||
| | | short[2] | ||
| Always | | Always(?) 0x2C00, 1 | ||
|- | |||
| +4 | |||
| short | |||
| Flags? 0x1 is always set, 0x8 often, 0x2000 seems to indicate a non-PRX library (like "stdc" or "allocator") that comes from somewhere else (LV2?) | |||
|- | |||
| +6 | |||
| short | |||
| The number of functions the depending PRX needs from the depended PRX. There's this many entries in the Mystery Table for that PRX, and there is this many function pointers in the stubtable (see below). | |||
|- | |- | ||
| +8 | | +8 | ||
| | | short | ||
| | | Usually 0, but "paf" gets sometimes 5, sometimes 6. More flags maybe? | ||
|- | |- | ||
| + | | +10 | ||
| | | short[3] | ||
| ? | | Always(?) 0. Probably for alignment. | ||
|- | |- | ||
| +16 | | +16 | ||
| long | | long | ||
| | | Pointer to the ASCII string of the depended PRX's name. These don't seem to consistently map with the PRX's file name in dev_flash. | ||
|- | |- | ||
| +20 | | +20 | ||
| long | | long | ||
| Pointer to this | | Pointer to this library's entries in the mystery table. | ||
|- | |- | ||
| + | | +24 | ||
| long | | long | ||
| Pointer to the | | Pointer to the the pointers to function stubs for this library in the stubtable. | ||
|- | |- | ||
| + | | +28 | ||
| long[2] | | long[2] | ||
| | | 0, 0 for every PRX except paf, which gets two more sets in the mystery table, pointed to by these. I suspect that +8 is somehow connected to this. | ||
|} | |} | ||
Second LOAD segment is all the relocation and symbol data, save for the names (as ASCII strings) of the exposed functions (which are in the first LOAD segment along with all the other strings the PRX uses). | |||
Revision as of 10:12, 23 June 2013
scetool can decrypt SPRX's, producing an ELF... or is it? Not really. It has an ELF header but...
First LOAD segment, paddr points to the descriptor for the "dependency table" or "deptable" for short:
NOTE: All addresses inside the file assume the ELF header isn't there (basically add 0xE0 to all addresses.)
Offset | Type | Description |
---|---|---|
+0 | long | Always(?) 0x101 |
+4 | char[28] | Name of this PRX, padded out with zeroes. Doesn't necessarily match the file name(why?) |
+32 | long | A unique module ID? Gets used a lot later... |
+36 | long | Points to the deptable header |
+40 | long | Points to the END of the deptable header |
+44 | long | Points to the start of first deptable entry |
+48 | long | points to the end of the LAST deptable entry |
Deptable header:
Offset | Type | Description |
---|---|---|
+0 | long[5] | Always(?) 0x1C000000, 0x80000002, 0x10000, 0, 0 |
+20 | long | Points to three longs of... something. The start of the mystery table. |
+24 | long | Points to three pointers in the mystery table. Two go to pointers to subroutines in the funcpointer table, the third goes back to the deptable descriptor. |
Entry in the deptable:
Offset | Type | Description |
---|---|---|
+0 | short[2] | Always(?) 0x2C00, 1 |
+4 | short | Flags? 0x1 is always set, 0x8 often, 0x2000 seems to indicate a non-PRX library (like "stdc" or "allocator") that comes from somewhere else (LV2?) |
+6 | short | The number of functions the depending PRX needs from the depended PRX. There's this many entries in the Mystery Table for that PRX, and there is this many function pointers in the stubtable (see below). |
+8 | short | Usually 0, but "paf" gets sometimes 5, sometimes 6. More flags maybe? |
+10 | short[3] | Always(?) 0. Probably for alignment. |
+16 | long | Pointer to the ASCII string of the depended PRX's name. These don't seem to consistently map with the PRX's file name in dev_flash. |
+20 | long | Pointer to this library's entries in the mystery table. |
+24 | long | Pointer to the the pointers to function stubs for this library in the stubtable. |
+28 | long[2] | 0, 0 for every PRX except paf, which gets two more sets in the mystery table, pointed to by these. I suspect that +8 is somehow connected to this. |
Second LOAD segment is all the relocation and symbol data, save for the names (as ASCII strings) of the exposed functions (which are in the first LOAD segment along with all the other strings the PRX uses).