Talk:PRX: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 15: Line 15:


try the idc scripts from [[IDA pro disassembler and debugger]], they might give you some additional information --[[User:Nas plugi|Nas plugi]] 15:20, 23 June 2013 (MSK)
try the idc scripts from [[IDA pro disassembler and debugger]], they might give you some additional information --[[User:Nas plugi|Nas plugi]] 15:20, 23 June 2013 (MSK)
So as of now is it not possible to get function addresses using the FNID? Right now I can hook functions but only for a normal game(e.g. using .lib.stub to parse all entries and then I use library name+fnid and I get a pointer that points to the normal stub entry in the ELF, eg the one with the bctr instruction) However I would like to also hook VSH calls to prxs and sadly vsh uses some VERY strange method to load and call prxs. So what I would like to do is get the VA of the PRX function itself(the value in ctr). Of course this can too be done be automatically disassembling the stub jumper(bctr) as it's just a hardcoded jump address ORIS R12,R12,hi lwz r12, lo(r12) and then r12 is a pointer to the func entry address; but alas this too applies only for normal game ELFs. We can get the PRX image in RAM so how the hell are NIDs used??

Revision as of 16:33, 25 June 2013

This is all wrong atm. The actual symbol table is later in the second LOAD section.

Just jotting some things down quick before I forget.

Second LOAD section:

  • First: Big list of pointers to all functions?
  • Second: ????? Possibly something to do with symbol mapping. Seems to mostly always point somewhere in the magical Table 6.
  • Third: Here we go. Long pointer to function name, long pointer to pointer to function, and a zero.
  • Fourth: Fuck if I know. More mapping stuff? More pointing to Table 6.
  • Fifth: Appears to be... data? Some strings, some floats, some other nonsense. Lots of 0x9EC? Or is that just the PRX I'm looking at? This goes on for a good long time, there might actually be two tables here.
  • Sixth: Where the magic happens. Starts off with a bunch of pointers into itself (some kind of initialization hint?). Speaking of pointers to pointers, this is where those pointers being pointed to are. Each one is paired with a long next to it, which is almost always the same number across the PRX. Possibly a unique module ID? It shows up in the dep table (what I thought was the symbol table) too.

3 and 6 are the fun ones, and together let you map code blocks to function names. There's still a lot of mysteries to be found though.Roothorick 03:40, 23 June 2013 (MSK)

try the idc scripts from IDA pro disassembler and debugger, they might give you some additional information --Nas plugi 15:20, 23 June 2013 (MSK)

So as of now is it not possible to get function addresses using the FNID? Right now I can hook functions but only for a normal game(e.g. using .lib.stub to parse all entries and then I use library name+fnid and I get a pointer that points to the normal stub entry in the ELF, eg the one with the bctr instruction) However I would like to also hook VSH calls to prxs and sadly vsh uses some VERY strange method to load and call prxs. So what I would like to do is get the VA of the PRX function itself(the value in ctr). Of course this can too be done be automatically disassembling the stub jumper(bctr) as it's just a hardcoded jump address ORIS R12,R12,hi lwz r12, lo(r12) and then r12 is a pointer to the func entry address; but alas this too applies only for normal game ELFs. We can get the PRX image in RAM so how the hell are NIDs used??