PSP's FLIRT

Griever · Post by **Griever** » Sat Jun 20, 2009 10:25 pm

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 · Post by **kralyk** » Sun Jun 21, 2009 12:19 am

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

Griever · Post by **Griever** » Mon Jun 22, 2009 12:12 am

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

kralyk · Post by **kralyk** » Mon Jun 22, 2009 3:25 am

That's not a conception of dissassembly or anything,
it's a documentation of exports/imports and NIDs of firmware modules =)

Griever · Post by **Griever** » Mon Jun 22, 2009 5:41 pm

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 · Post by **hlide** » Mon Jun 22, 2009 7:41 pm

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 · Post by **Griever** » Mon Jun 22, 2009 9:37 pm

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 · Post by **cory1492** » Tue Jun 23, 2009 12:34 pm

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.

Code: Select all

pspdecompiler.exe -n psplibdoc.xml -c your.prx

Will name functions just fine provided the xml has the right NIDs.

And of course, I could have missed the point of where this thread is going/has been, too.

kralyk · Post by **kralyk** » Wed Jun 24, 2009 12:37 am

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)

Which is what firmware? 5.50?

cory1492 · Post by **cory1492** » Wed Jun 24, 2009 10:58 am

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.)