News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: PSP Memory organization  (Read 9773 times)

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
PSP Memory organization
« on: April 21, 2013, 06:35:27 pm »
Hi,

I'm new to PSP hacking, but I did some on PS2 and I was told it is quite similar.

Nonetheless, something bugs me.

I use JPCSP emulator and if I go to debug/Memory viewer, I can see the main executable (that is, the BOOT.BIN file) starting at $8804000.

But if I save the RAM dump to disk and open it with an hex editor, I can't find any tracks of the main executable.

Worse, the dump file (32 Mb large, which seems correct) contains data I can't locate in the JPCSP/debug/Memory viewer (but since there's no search function in the viewer, and it seems impossible to save the whole dump to file, it's really difficult to find anything).

Can someone tell me where in the Memory is the main executable loaded, and more generally how is the PSP memory organized ? Or at least, provide documents on the subject ?

Thanks in advance :)

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: PSP Memory organization
« Reply #1 on: April 22, 2013, 02:59:46 am »
Unfortunately (or fortunately?) this has nothing to do with how the PSP's memory is organized, it's a bug in the memory dumping code of the emulator. Every non-ASCII character (or so) gets replaced by '?' (0x3f). It's aggravating as hell, but it should be easy to fix as JPCPS' Java code is pretty readable and well-structured - for example, I once augmented the debugger with a rudimentary rendering list viewer.

Otherwise it's just as you would expect - a linear 32MB memory region reaching from 0x8000000 to 0xa000000.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: PSP Memory organization
« Reply #2 on: April 23, 2013, 09:28:43 am »
Thanks for the info, I could have searched for a long time :)

Thanks to you, I found the data I was looking for.

But many things bug me.

For example, the main code section in the BOOT.BIN file should start, according to the ELF program header, at $20a210 ; according to the ELF section header, it should be at $000000.

But when looking in the RAM dump, it's at $08804000 !
Even worse, the code lying there is not exactly the same as the one in the BOOT.BIN : instructions are the same, but address prameters not. I first thought I was looking the wrong section in the BOOT.BIN, but I couldn't find the exact code that I read in the memory dump.

So now I think I definetely missed something. Is the BOOT.BIN the true file loaded in memory ? In addition of this one, there are 2 EBOOT.BIN (one in SYSDIR, the other in SYSDIR/UPDATE, which is oddly older). What are their use ?

I read EBOOT was an Encrypted version of BOOT.BIN. Once decrypted, is it the very same file ? If yes, why ?

Don't hesitate to point me interesting documents on PSP hacking (there are not any in the site database)

April 23, 2013, 06:51:53 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I got it : it's not an ELF file, it's a PRX. So everything is relocatable. prxtools helped me convert it to an ELF, I have now to find out how to achieve the opposite.
« Last Edit: April 23, 2013, 06:51:53 pm by tryphon »

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: PSP Memory organization
« Reply #3 on: April 24, 2013, 02:15:01 am »
If you're still wondering, EBOOT.BIN is indeed an encrypted BOOT.BIN. The newer firmwares ignore BOOT.BIN and load only the EBOOT.BIN. That's why the BOOT.BIN often is just a dummy file in newer games. However, if it contains valid data is should be identical to the decrypted EBOOT.BIN.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: PSP Memory organization
« Reply #4 on: April 24, 2013, 03:43:50 am »
I was still wondering, since my ELF was valid (but was a PRX). So if I want to hack some routines in the game, I have to modify the EBOOT.BIN. Is there a tool to encrypt a ELF/PRX ? (I saw JPCSP can decrypt, so I probably can figure out the reverse, but it'd spare me some time).

But why in hell would someone want to have an encrypted version next to a decrypted one ?  :P

Oh, and thanks again :)

RetroHelix

  • Full Member
  • ***
  • Posts: 148
    • View Profile
Re: PSP Memory organization
« Reply #5 on: April 24, 2013, 05:07:48 am »
I have to modify the EBOOT.BIN. Is there a tool to encrypt a ELF/PRX ? (I saw JPCSP can decrypt, so I probably can figure out the reverse, but it'd spare me some time).
I would recommend you ask/search at http://wololo.net/ (http://www.google.com/cse?cx=partner-pub-7101223807014632%3A2956191155&ie=UTF-8&q=prx+encrypt&sa=Search&siteurl=wololo.net%2Ftalk%2Fviewtopic.php%3Ff%3D2%26t%3D8129&ref=www.google.de%2F&ss=24j576j2#gsc.tab=0&gsc.q=prx%20encrypt&gsc.page=1) since PSPhacking isn't that popular here.

And maybe this is useful: http://hitmen.c02.at/files/yapspd/psp_doc/chap26.html (chapter 26.2.5 )

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: PSP Memory organization
« Reply #6 on: April 25, 2013, 08:57:31 am »
I was still wondering, since my ELF was valid (but was a PRX). So if I want to hack some routines in the game, I have to modify the EBOOT.BIN. Is there a tool to encrypt a ELF/PRX ? (I saw JPCSP can decrypt, so I probably can figure out the reverse, but it'd spare me some time).

But why in hell would someone want to have an encrypted version next to a decrypted one ?  :P

Oh, and thanks again :)

You don't actually need BOOT.BIN, but my guess is that some developers left it in out of laziness/carelessness. I haven't tried myself yet (I as well am still pretty new to PSP hacking), but I've read you can just relink a decrypted BOOT.BIN to EBOOT.BIN and the game would work. Seemingly the firmware knows from the header whether it needs to decrypt EBOOT.BIN.

And yes, JPCSP can decrypt. You have to start the game and you can find the decrypted file in one of the emulator's sub-folders (maybe you have to turn on some option first; I forgot if that pertained only to other decrypted files or EBOOT.BIN as well).

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: PSP Memory organization
« Reply #7 on: April 27, 2013, 06:49:30 am »
Thanks, dummying BOOT.BIN and write a decrypted EBOOT.BIN works :)

I'm still wondering how to deal with 'dynamic addresses references' but at least, I can modify instructions.

A last question (sorry) : I have not found complete PSP Processor (CXD2962GG) Instruction Set.

I mean : no problem for the standard MIPS instructions set, and the second link privided by RetroHelix is really useful for coprocessors instructions set.

But PS2's Emotion Engine had some supplementary instructions, like "enhanced" multiplications or add-and-multiply instructions. Do you know if PSP have them too ? (I'll try to figure it out browsing jpcsp code).

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: PSP Memory organization
« Reply #8 on: April 27, 2013, 01:22:01 pm »
Only those listed under Allegrex instructions on that PSP documentation site as far as I know. I don't have that much experience, but I actually haven't encountered anything that isn't a standard MIPS instruction or coprocessor instruction so far.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: PSP Memory organization
« Reply #9 on: April 27, 2013, 04:57:48 pm »
Browsing jpcsp sources, I found Multiply-and-add. But I didn't find the 'mult r0, r1, r2' there was in EE (it does r0 = r1*r2, whereas standard 'mult r1, r2' statement stores the result in hi/lo). !not a big deal though.

Thanks for all your help. I may have some question in the future (on relocatable code), but I'll try to figure it out by myself first.

May 01, 2013, 08:15:27 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Unfortunately (or fortunately?) this has nothing to do with how the PSP's memory is organized, it's a bug in the memory dumping code of the emulator. Every non-ASCII character (or so) gets replaced by '?' (0x3f).

Just a stupid workaround : make a snapshot seems to do exactly the same thing (dumping 32 Mb of RAM), without replacing non-ASCII characters by '?'.
« Last Edit: May 01, 2013, 08:15:27 am by tryphon »

LostTemplar

  • Hero Member
  • *****
  • Posts: 906
    • View Profile
    • au-ro-ra.net
Re: PSP Memory organization
« Reply #10 on: May 03, 2013, 03:56:58 pm »
Today I noticed that there has been a new PSP emulator around for quite a few months, namely PPSSPP. I tried it and it's a dimension faster than JPCSP; I can't say how their compatibility rates compare, though. However, the one game I'm playing around with currently is so far running perfectly.

PPSSPP's debugging features are still(?) very rudimentary, but they're there. Three things that are missing that JPCSP supports are: file I/O logging (very useful), image viewer (very user-unfriendly in JPCSP though) and memory breakpoints (very sketchy in JPCSP).

I'm going through the code of PPSSPP at the moment - maybe some of the features can be easily implemented. I feel more confident in C++ than Java so if I find some time I'd like to give it a try! Things I'd love to have:
  • a good image/texture viewer
  • render list viewer
  • reliable memory breakpoints
  • good memory viewer and, even more important, editor
The views should be relatively easy to implement (probably annoying, though). I'm not sure yet how difficult the implementation of memory breakpoints would be, but I'd guess the JIT compiler needs to be turned off.

Subevil

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: PSP Memory organization
« Reply #11 on: May 03, 2013, 05:13:55 pm »
Today I noticed that there has been a new PSP emulator around for quite a few months, namely PPSSPP. I tried it and it's a dimension faster than JPCSP; I can't say how their compatibility rates compare, though. However, the one game I'm playing around with currently is so far running perfectly.

Yeah, PPSSPP is significantly faster, upwards of 3-4x faster than what JPCSP does. Compatibility seems good, but not quite as good as JPCSP. But to be fair, it's not been around nearly as long as JPCSP.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: PSP Memory organization
« Reply #12 on: May 04, 2013, 03:51:02 pm »
Downloaded PPSSPP.
Installed.
Ran it.
Crash, with no error messages  :D

For the moment, JPCSP is sufficient, but I'll have a deeper look at PPSSPP.

Subevil

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: PSP Memory organization
« Reply #13 on: May 04, 2013, 09:24:07 pm »
Downloaded PPSSPP.
Installed.
Ran it.
Crash, with no error messages  :D

For the moment, JPCSP is sufficient, but I'll have a deeper look at PPSSPP.

I'd recommend trying the latest PPSSPP Git, I always download it from here:
http://www.emucr.com/search/label/PSP?&max-results=12

[Unknown]

  • Guest
Re: PSP Memory organization
« Reply #14 on: June 07, 2013, 04:27:27 pm »
I'm still wondering how to deal with 'dynamic addresses references' but at least, I can modify instructions.

Sorry to bring up an older topic, but saw this and wanted to answer.  They're relocated, which just means adding.  If you're changing the memory position, just change the relative address by that much, and you'll be good.  For example, consider:

lui a0, 0x0000
addiu a0, a0, 0x0020

If this is part of the relocation table, it'll be combined (note that addiu is signed), relocated, and then split and written back.  So, if you want to make it read something 0x1000 higher, just change the addiu to 0x1020, and you'll be fine.

If you need it to be a fixed address (e.g. something you're allocating somewhere else), you'll need to remove it from the relocation table, or relocate some dummy instructions somewhere else.  That's not super hard, but it's definitely easier to just use a relative address.

If you do need to change it, there are several kinds of relocations.  The one I described above is a HI16/LO16 relocation (which relocates based on a pair of instructions.)  There's also 26-bit (for jumps) and 32-bit (static address values) and a few other uncommon ones.

But PS2's Emotion Engine had some supplementary instructions, like "enhanced" multiplications or add-and-multiply instructions. Do you know if PSP have them too ? (I'll try to figure it out browsing jpcsp code).

That's probably the easiest way.  There aren't a ton, it's mostly just MIPS.

PPSSPP's debugging features are still(?) very rudimentary, but they're there.

I agree - pull requests welcome.  It has really crappy memory breakpoints though, but no real UI for them yet...

Downloaded PPSSPP.
Installed.
Ran it.
Crash, with no error messages  :D

For the moment, JPCSP is sufficient, but I'll have a deeper look at PPSSPP.

You should post about this at http://forums.ppsspp.org/ if it's still not working.

-[Unknown]

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: PSP Memory organization
« Reply #15 on: June 08, 2013, 06:05:38 pm »
Thanks for the answer !
Sorry to bring up an older topic, but saw this and wanted to answer.  They're relocated, which just means adding.  If you're changing the memory position, just change the relative address by that much, and you'll be good.  For example, consider:

lui a0, 0x0000
addiu a0, a0, 0x0020

If this is part of the relocation table, it'll be combined (note that addiu is signed), relocated, and then split and written back.  So, if you want to make it read something 0x1000 higher, just change the addiu to 0x1020, and you'll be fine.

If you need it to be a fixed address (e.g. something you're allocating somewhere else), you'll need to remove it from the relocation table, or relocate some dummy instructions somewhere else.  That's not super hard, but it's definitely easier to just use a relative address.

I figured this out. I do need fixed address (to put some custom routines). So I wrote a Python script that does the insertion, and recompute the allocation table. I've learnt a bit about ELF this way.

Quote
I agree - pull requests welcome.  It has really crappy memory breakpoints though, but no real UI for them yet...

You should post about this at http://forums.ppsspp.org/ if it's still not working.

-[Unknown]

Yes, I'll do that. My computer went down though, so I changed it and I didn't check if it works now.