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? ... d&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.
DRIVER_PATH Exploit POSSIBILITY!
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.
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.
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]
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]
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?
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