forums.ps2dev.org

Griever · Joined: 20 Jun 2009 Posts: 6

Speaking of executables disassembly, FLIRT technology helps a lot with, for example, PSX hacking/translation/development: you just do not need dig into the lowest procedures and code becomes more or less high-level, which is essential for code understanding. That became possible on PSX cause official PsyQ IDE used it's own c compiler with it's libraries. The only hard part here was to calculate proper checksums of each library procedure and voila - clear and understandable code from scratch.

And now for our favourite psp: I've disassembled few prx'es and eboots with tyranid's tool and with IDA - that's just a mess. I mean, pretty clear that code reads and writes somewhere, but what's the idea behind every subroutine - that's a true puzzle.

In our situation: when no debugging emulators are available, it's not possible to actually debug code and disassemblers becomes one and the only real tool to understand the code. Do psp has Sony's native IDE? (pretty sure it does, but does anybody have an idea of native library functions and their's checksums?)
Is there any way to make disassembled code more understandable, than FLIRT. Maybe I missed something in Tyranid's prxtool?

kralyk · Posted: Sun Jun 21, 2009 12:19 am Post subject:

You might want to have a look at this: http://forums.ps2dev.org/viewtopic.php?t=11985
_________________
...sorry for my english...

Griever · Joined: 20 Jun 2009 Posts: 6

Nah, I think more like here - that's an interesting conception.

kralyk · Posted: Mon Jun 22, 2009 3:25 am Post subject:

That's not a conception of dissassembly or anything,
it's a documentation of exports/imports and NIDs of firmware modules =)
_________________
...sorry for my english...

Griever · Joined: 20 Jun 2009 Posts: 6

Yup, kinda unusual comparing to other platforms, but the final result looks like flirt stuff: libraries are all in different library prx'es and all xrefs to these library functions will be in IDA base after sertain exercises with tyranid's prxtool and NID tables.
Actual decompilation into c is not my point of interest: as far as I understood hnaves's decompiler (impressive thing indeed) does not reveal library names or something - just makes high level code out of low level for easier understanding of code flow, but not the program itself...

hlide · Joined: 10 Sep 2006 Posts: 750

what is interesting you is probably psplibdoc. It is a an XML file which contains NID and names of functions. PRXTOOLS can produce IDA map file and can resolve names and reference with psplibdoc.

Griever · Joined: 20 Jun 2009 Posts: 6

That's what I meant by "certain exercises with tyranid's prxtool and NID tables". Thanks a lot.
I'm just surprised how much new code uses common psp eboot.bin... PSX's executables uses at least one library function in one inner procedure, so you can always aproximately tell what is this function about. Looks like that's not about PSP.

cory1492 · Joined: 10 Dec 2004 Posts: 216

hnaves's decompiler can use psplibdoc xml files directly too. Of course, psplibdoc doesn't work on firmware prx's where the NIDs have been randomized (or sodomized, whatever you call what they have been doing) - but that's pretty much the same case for prxtool too.

kralyk · Posted: Wed Jun 24, 2009 12:37 am Post subject:

cory1492 · Joined: 10 Dec 2004 Posts: 216

After 3.50 (if memory serves) they started randomizing certain kernel NIDs, identical user NID exports in the same prx don't change like this as games sort of... need them to work. m33 since then has had a resolver in it to use many/most old NIDs for toolchain/homebrew compatibility (though I'm not sure if the conversion has trickled down into later firmware libdoc's from silverspring, last I needed to check they hadn't.)