forums.ps2dev.org

Mangus · Joined: 17 Jun 2005 Posts: 33

Concerning a possible exploit I may have discovered using the DRIVER_PATH category in PARAM.SFO files:

This hack would be similar to the SWAPLOIT setup, except with one MS, one eboot.psp that contains only PARAM.sfo and icon, one DATA.PSP (elf)file that has been converted to appear to be a .prx driver file, my theoritical process is explained below.

well i believe the second file that the DRIVER_PATH designates must be a .PRX and the elf bootable must be adjusted in it's header to appear to be one (more info on this can be found at http://forums.ps2dev.org/viewtopic.php?t=1463&postdays=0&postorder=asc&highlight=psp+research+thread&start=30 and the post is by steddy and is located 2/3 down scroll bar length. I beleive if you were to take a .psp file, elf or not, and make its header so it meets these requirements: is a .prx file, is claimed to be compressed (although it really isn't), and it is classified as a driver/service.

In all good will this would cause the psp to appear to be a real .prx file and DRIVER_PATH would then run the execuatble. The fake .prx file could be located anywhere on the memstick as long as DRIVER_PATH's path is correct (say the FILE.prx file is loacted under the same folder as the eboot.psp with DRIVER_PATH, here is the data that should appear under the data field "ms0://PSP/GAME/DPHACK/FILE.PRX" (dp stands for driver path), from the test i have run i beleive it will work. I have yet to alter the psp file to a "true" prx by a hex/binary editor in the way that link and steddy's research says.

I hope this helps!
Thanx to PSP-DEV for inspiration,
Thanx to the creator of PBPUNPACKER for showing DRIVER_PATH possibility,
Thanx to steddy, MelGibson, Gorim, and Mrbrown for your prior research,
Thanx to everyone here at PS2DEV for help and info in advanced!

Good luck hacking!
Mangus_the_Shadow

Just to let flamers and mods know this was posted in order for this to have it's own topic and it does exist in other threads because of my other post. Thank you for reading! ^_^ PS please don't lock or delete, i see real possibilities here.

Fluff · Joined: 22 Apr 2005 Posts: 35

sounds ominous but i dont have anything else to do for the next 4 hours, i'll give it a go

Fluff · Joined: 22 Apr 2005 Posts: 35

header from encrypted prx = crash on psp logo
entire encrypted prx as data.psp = crash on psp logo

header from unencrypted prx = normal cant-launch error
entire unencrypted prx = normal cant-launch error

it seems unlikely, after playing around with it, that the program will load up the prx data without first launching the program that needs them, and given that we are trying to launch that program, it does sort of end up like a dog trying to bite it's own tail.

Mangus · Joined: 17 Jun 2005 Posts: 33

i realize the same thing now after trying around 48 different header combinations, thanx fluff

hey one thing about header can't be exact copy the only thing i can think would work is if the header were setup like this:

POS: 0 1 2 3 4 5 6 7 8 9
DATA: 7f 45 4c 46 07 10 00 00 01 01

the first 4 offsets are same as elf type data.psp (choose to remain as elf due to the fact it alters much of the latter code and that the possible reason why the Swaploit works is that the unsigned code begins in offset 0 rather than in the middle of the pbp file). the next tells the file type to be a driver file, the next tells the sub type to be a kernel module (this might need to be changed to 00 for a user module, not sure how much this affects file type, the next says this file is uncompressed to prevent the psp from decompressing the file, the next declares there is no file padding, and the last two offsets tell a part of the uncompressed name to set up fo the following file data.[/quote]

gotxp · Joined: 19 Jun 2005 Posts: 11

if the UPDATE folder skips the prx check... perhaps there is a folder for debugging that skips the encryption check...
_________________
See The Future... Feel The Future...

TRF-Yu-Ki · Joined: 08 Jun 2005 Posts: 15

Hmm,

If the PSP thinks the PRX files are compressed... wouldn't it try to decompress it? Thus, some kind of sceDecompressMyPRX() routine would fail? And PSP will think the PRX is corrupt?
_________________
Learning to hack is not bad in itself; it's what you do with your abilities that count. - a.k.a. Shadow-Me-Twice of ddrfreak.com

zigzag · Joined: 26 Jan 2005 Posts: 129

gotxp: That's what I'm thinking too. But the chances of finding it?...

MindWall · Joined: 10 May 2005 Posts: 70

.. slim to non, if it's not \BOOT or \EBOOT