An interesting discovery... will help 1.5

[steddy]

I just made an interesting discovery that proves the 1.5 PSP can run unencrypted ELF files.

The JAP Metal Gear Acid game contains these two files which are pretty standard:

/PSP_GAME/SYSDIR/BOOT.BIN
/PSP_GAME/SYSDIR/EBOOT.BIN

However, it also contains:-

/PSP_GAME/USRDIR/PROGRAM.PRX

This PRX file is actually exactly the same file as BOOT.BIN in the SYSDIR directory. It also contains 43 other PRX files in the /PSP_GAME/USERDIR/STAGE/xxx directories which are not modules but standard ELF executables. There is even a simple 16k one which creates the save game files!

So what does this prove. It proves that the 1.5 PSP does not require all ELF files to be encrypted. We already knew this for PRX files as modules, but not PRX files as standalone programs.

So my question now is how to we get a PSP to initiate the load of a PRX other than referencing it as a module?

This all leads me to believe the code that changed between 1.0 and 1.5 was in the XMB only. It must have been coded so that when uncompressing a PBP file it checks the included .PSP file is a ~PSP encrypted file. It wasn't changed lower down in the kernel.

Thoughts?

[TyRaNiD]

Not sure what this actually is proving ? As far as I have seen there is no difference between a main executable prx and library prx, except for the odd flag here and there, so the fact that off a UMD you can load unecnrypted prxes should come as absolutely no surprise.

Now I have yet to see proof that an unencrypted prx is bootable from the MS at all (doesn't mean it can't be done of course) the elf files which we can currently load are not proper prxes so it might just be that Sony left in some devkit code which should have been removed.

Personally I think the code change happened in the core (loadcore/modulemgr/loadexec or all three) and has little to do with the XMB as the XMB does not say they are invalid executables. It seems more likely the XMB hands it off to a bootloader which fails and returns status info (i.e. the error code) back to the XMB which displays said error.

[Danj]

There is even a simple 16k one which creates the save game files!

Does it say what function(s) are used for encrypting/decrypting save game data? I would very much like to be able to access the information in my MGA save games.

[Soir]

Now that you mention this about PRX, I did some tests before with the UPDATE-folder.

1:
Original v.1.51 EBOOT.PBP inserted into folder 'X:/PSP/GAME/Update' - Error msg: 80020148 (PRX type unsupported)

2:
Original v.1.51 EBOOT.PBP inserted into folder ''X:/PSP/GAME/UPDATE' - Hmm... It works... It would appear that the PSP skips the PRX type-check and boots the EBOOT.PBP when the update is inserted into Update-folder with uppercase letters.

X: is your PSP MS-drive.

Could this maybe help?

Edit: Old tests, did 'em about a month or so ago...

[laichung]

Your test is a really a old news.

Now that you mention this about PRX, I did some tests before with the UPDATE-folder.

1:
Original v.1.51 EBOOT.PBP inserted into folder 'X:/PSP/GAME/Update' - Error msg: 80020148 (PRX type unsupported)

2:
Original v.1.51 EBOOT.PBP inserted into folder ''X:/PSP/GAME/UPDATE' - Hmm... It works... It would appear that the PSP skips the PRX type-check and boots the EBOOT.PBP when the update is inserted into Update-folder with uppercase letters.

X: is your PSP MS-drive.

Could this maybe help?

[steddy]

Personally I think the code change happened in the core (loadcore/modulemgr/loadexec or all three) and has little to do with the XMB as the XMB does not say they are invalid executables. It seems more likely the XMB hands it off to a bootloader which fails and returns status info (i.e. the error code) back to the XMB which displays said error.

If thats the case, what do you think that code looks like in the core? Does it have a list of all possible names for the UMD device and it has an IF statement to check for the file loading from the UMD? These modules will be loaded by something like sceKernelLoadModule, so that would need to be the function that checks them all. Remember that the UMD can be mounted to different device names using sceUmdActivate.

I couldn't spot the XMB in memory from the kernel dump. Is this flushed out of memory prior to running the kernel dumper? If not, does anybody have an idea where the XMB interface loads into memory?

Steddy