Hi,
I've been loitering around here for a while now and figured it was about time I registered. :) Apoligies in advanced if my thoughts here have been covered elsewhere, I did look and couldn't see anything along these lines.
Anyway, it's nice to see that the 1.5 exploit works but I'm more than a little curious... HOW exactly does this work?
Like most people I had assumed that with 1.5 firmware the ability to run code off the memory stick had been restricted to officially encrypted and signed executables but this exploit has shown that it's not the case. When I first read about this technique I assumed that at the very least a valid firmware update PBP file would need to be present on the first memory stick (this method was even suggested a while ago by somebody and laughed off as crazy talk) but no, this actually works only with files already available in existing homebrew releases.
Based on todays revelations, we can make the following observations:
1. Firmware 1.50 does NOT require executables to be encrypted, regardless of any "security" checks that may be done beforehand, once the elf is loaded off the 2nd memory stick it executes just fine.
2. Simply having a PBP file with a valid SFO and icon file is enough for the PSP (even 1.50) to consider it a bootable application which it DOES attempt to execute.
The question is, what exactly happens after selecting a PBP file that runs on 1.0 that causes 1.50 to drop back to the OS with an error? And why does swapping the memory stick with one that simply has an elf in place of the PBP then allow it to work?
Thinking about what's actually happening with the swap trick, the PBP file on the first memory stick doesn't actually have an elf file at all so presumably the elf (.psp file) offset in the PBP header is zero, which could explain why the 2nd "fake" PBP file works since it's actually just the elf itself (and therefore is present at offset zero in the file).
Then again, this doesn't tell us why the normal PBP can't be run, it has all the correct offsets in it, yet it tries to run it and it fails... why?
There is another possibility here, what if when the memory stick is swapped the new PBP file is re-read once again from scratch? The PBP header won't make much sense because it's actually the beginning of an elf file, however if I understand correctly, the position of the elf offset in the PBP header actually corresponds to the program header in an elf file. What if 1.5 was simply changed so that the "program" part of a PBP package no longer points to the start of an elf file as it used to but maybe a stripped down elf file, another part of the elf or even to the launch point of the code itself? It could just be a massive coincidence that this swap-trick works at all.
I remember seeing a post a while ago by somebody who claimed that when they replaced an elf in a PBP file with some un-linked object code it actually crashed their 1.50 PSP rather than returning to the OS with an error message. At the time I thought nothing of it, but now... makes you think, doesn't it? :)
Admittedly it's still possible that there is a security check going on which swapping the memory stick somehow avoids but what kind of security check would return a successful result if it can't find the file it's supposed to be checking? I find this extremely unlikely.
Also, if it was purely the process of swapping that makes this trick work, you'd just be able to use a normal PBP file (that works on 1.0) and then remove / re-instert the same memory stick. Assuming of course that doesn't work, the key here MUST be the fact that the PBP file on the 2nd memory stick is actually the elf... the question again is, why? :)
Sorry that this post contains more questions than answers, I have a 1.0 PSP myself but this swap thing really did get me thinking, and for the first time I now honestly believe direct booting homebrew on 1.50 (without swap) could be possible.
Discuss... :P
1.5 "swaploit" observations, clues for no-swap boo
Hello Minagi,
Yes, it's bugging the hell outta me too! For my analysis I took an InfoNES EBOOT.PBP file, and created the MS1 and MS2 files, and noticed that the MS2 started with the elf data 7F 45 4C 46. I can only assume a few things.
The only thing I can remotely imagine is that the process of swapping the memory card causes a mis-read in data, forcing data to be read from the beginning, or "rebooting" the card. But perhaps since the initial PBP header info was already read on the first card, the PSP might not have required that type of info again, and reading the ELF data might have been acceptable at this time??? I have never studied these file types before, nor have I tried the memory card swap, I've noticed how incredibly simple this stunt was and I'm inclined to learn more.
Thanks,
flipfl0p
Yes, it's bugging the hell outta me too! For my analysis I took an InfoNES EBOOT.PBP file, and created the MS1 and MS2 files, and noticed that the MS2 started with the elf data 7F 45 4C 46. I can only assume a few things.
The only thing I can remotely imagine is that the process of swapping the memory card causes a mis-read in data, forcing data to be read from the beginning, or "rebooting" the card. But perhaps since the initial PBP header info was already read on the first card, the PSP might not have required that type of info again, and reading the ELF data might have been acceptable at this time??? I have never studied these file types before, nor have I tried the memory card swap, I've noticed how incredibly simple this stunt was and I'm inclined to learn more.
Thanks,
flipfl0p
When you press the game-loader the system checks for validity of the file, and the data.psp. In 1.50 if there's no data.psar the eboot.pbp get's "OK"ed, modules are loaded while the flash intro is showing, you switch the memory cards and when the PSP is ready and looks for the file it executes the unsigned data.psar (which is renamed to eboot.pbp).
In versions 1.51 and 1.52 the system probably checks if data.psar exists at all, and this is way the exploit is not working... there's a good chance that if you use eboot.pbp (original version, say 1.0 update to 1.5) as a boot eboot.pbp after the swap you will be able to execute the homebrew too.
So if you have ver 1.5x try using the "Real" eboot.pbp (from 1.0 update to 1.5) on 1.51 or 1.52 to "boot" and then swap as before a homebrew eboot.pbp
maybe in a similar way and any luck the boot.bin could be started in a similar way? (reneame boot.bin to eboot.pbp for the swap)
but I guess we have to guess the filestructure the PSP will look for...
but in any case to bypass the data.psar sign-check we need to start off with (more or less) legally signed eboot.pbp and I cannot see a way to have swapless exploit unless you downgrade at least some of the firmware files to ver 1.0
=/
In versions 1.51 and 1.52 the system probably checks if data.psar exists at all, and this is way the exploit is not working... there's a good chance that if you use eboot.pbp (original version, say 1.0 update to 1.5) as a boot eboot.pbp after the swap you will be able to execute the homebrew too.
So if you have ver 1.5x try using the "Real" eboot.pbp (from 1.0 update to 1.5) on 1.51 or 1.52 to "boot" and then swap as before a homebrew eboot.pbp
maybe in a similar way and any luck the boot.bin could be started in a similar way? (reneame boot.bin to eboot.pbp for the swap)
but I guess we have to guess the filestructure the PSP will look for...
but in any case to bypass the data.psar sign-check we need to start off with (more or less) legally signed eboot.pbp and I cannot see a way to have swapless exploit unless you downgrade at least some of the firmware files to ver 1.0
=/
Last edited by MindWall on Thu Jun 16, 2005 3:13 pm, edited 1 time in total.
Well.. as many of you... I'm in the same boat. I was chillin' in #ps2ownz, and when it came out....and it actually worked.... I was like "what the?" Not needing a legit eboot.pbp is mind-blowing enough, but the 2nd Memstick just took a data.psp and renamed it to eboot.pbp ....and THAT WORKED?!?!?! What the FlyingFigNetwon is that? I almost died when I saw "No rom header" show up on my PSP; knowing that's the SNES saying I had no rom files. I was like, "It ran?!!!! WHAT?!" I think that if 1.50 is flexible enough for this madness to actually work... then there must be a file-structure that will allow this without swapping.
I'm gonna try renaming Helloworld EBOOT.PBP to DATA.PSP and jamming that into the USA 1.52 update EBOOT.PBP... and all sorts of crazy variations of renaming, recursive packing, binary-appending madness. I think somewhere in this kind of activities, we'll get a mad-crazy super-misconfigured EBOOT.PBP that'll work without swapping.
Give it a try, I'm doing this right now....
I'm gonna try renaming Helloworld EBOOT.PBP to DATA.PSP and jamming that into the USA 1.52 update EBOOT.PBP... and all sorts of crazy variations of renaming, recursive packing, binary-appending madness. I think somewhere in this kind of activities, we'll get a mad-crazy super-misconfigured EBOOT.PBP that'll work without swapping.
Give it a try, I'm doing this right now....
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
-
TerryMathews
- Posts: 19
- Joined: Thu Mar 31, 2005 5:35 am
Re: 1.5 "swaploit" observations, clues for no-swap
I believe the header in the PBP of the loader file points to the end of the file ( where the elf would normally be present ) vs pointing to 0.Minagi wrote:
Thinking about what's actually happening with the swap trick, the PBP file on the first memory stick doesn't actually have an elf file at all so presumably the elf (.psp file) offset in the PBP header is zero, which could explain why the 2nd "fake" PBP file works since it's actually just the elf itself (and therefore is present at offset zero in the file).
Perhaps the psp tries to read the elf, its not present and it attempts to read the elf/file X # of times without reading the header location each attempt thus swapping works.
However, if you keep the ELF in the PBP file on MS1 and proceed with the swap, it still works. So perhaps it re-reads the ELF from scratch, i.e. the ELF program header as Minagi mentioned.
What I'm wondering is why the PSP doesn't show the file as being "Corrupted Data" when it doesn't even have an ELF!
What I'm wondering is why the PSP doesn't show the file as being "Corrupted Data" when it doesn't even have an ELF!
Probably because the shell processes the PARAM.SFO and icon in the preswap PBP and finding them to be vaild, outputs its presence to the menu not even checking if there is an executable within. Then when the user wants to run the program, the shell calls KernelLoadExec with the path of the PBP. The kernel then loads the file and finds a vaild ELF binary after then swap and proceeds to run it. Note, this is speculation and I have no knowledge if it is true.What I'm wondering is why the PSP doesn't show the file as being "Corrupted Data" when it doesn't even have an ELF!
I don't know much about code security, but I've read some basic mechanism somewhere.
Pbp on ms 1 packs a sfo and a icon, no code but indicates the pbp as bootable. Pbp 2 has a unsigned elf faked itself as a pbp package.
It seems likely(only likely, don't know if it is) the pbp's sfo on ms1 causes some buffer overflow, makes the psp jump over code decryption and directly load the unsigned elf from the ms.
They pad many bytes in the sfo file, maybe some of them are the parameters passed to the 'loadUnsignedElf'(assumed name) function. These parameters leads the function to load elf from the beginning of the fake pbp file(ms 2).
Perhaps they will refine the swap method to enable direct boot from just one ms later.
Pbp on ms 1 packs a sfo and a icon, no code but indicates the pbp as bootable. Pbp 2 has a unsigned elf faked itself as a pbp package.
It seems likely(only likely, don't know if it is) the pbp's sfo on ms1 causes some buffer overflow, makes the psp jump over code decryption and directly load the unsigned elf from the ms.
They pad many bytes in the sfo file, maybe some of them are the parameters passed to the 'loadUnsignedElf'(assumed name) function. These parameters leads the function to load elf from the beginning of the fake pbp file(ms 2).
Perhaps they will refine the swap method to enable direct boot from just one ms later.
Well as i do almost daily i went snooping in PARAM.sfo files agian, seeing as well this seems to be the next possible place to find any exploit in my opinion, and found a category called DRIVER_PATH. i'm guessing many of you have noticed it, but to my knowledge no sfo uses this.
i have been looking into it and thought prehaps using this DRIVER_PATH we can send it to the memory stick and to what ever folder the file we want to run is contained in and boot load it through this, i think the file would have to be a modified data.psp and the header should be changed so that it matches being a prx file and claims it is encypted with the know flag (this all explained under the ~PSP topic)
this will probably seem like a bunch of noob talk, but can't think of how to explain it, i hope someone gets this, P.S. Sorry if an idea like this has been posted this place seemed appropriate to discuss this. >.<
i have been looking into it and thought prehaps using this DRIVER_PATH we can send it to the memory stick and to what ever folder the file we want to run is contained in and boot load it through this, i think the file would have to be a modified data.psp and the header should be changed so that it matches being a prx file and claims it is encypted with the know flag (this all explained under the ~PSP topic)
this will probably seem like a bunch of noob talk, but can't think of how to explain it, i hope someone gets this, P.S. Sorry if an idea like this has been posted this place seemed appropriate to discuss this. >.<
I don't think so as you can use any param.sfo that works on a 1.0. I've been using the helloworld one.konfig wrote: It seems likely(only likely, don't know if it is) the pbp's sfo on ms1 causes some buffer overflow, makes the psp jump over code decryption and directly load the unsigned elf from the ms.
Just curious, what's stopping us from completely replacing the 1.50 firmware files with those of 1.00? Does the code we run not have write access? I could understand apprehension too. I'm not willing to take the risk of rendering my PSP useless. I couldn't afford a new one. Or has this actually been attempted and failed miserably?
EDIT: Nevermind, I just read how a guy destroyed 5 PSP in the dev forum, thanks.
EDIT: Nevermind, I just read how a guy destroyed 5 PSP in the dev forum, thanks.
It's time to chew ass and kick bubble gum... and I'm all out of ass!
I have been away for a while so I have missed on alot of the 'news' flying about. I figured this would be the best place to ask this. But what exactly is this swaploit? And since people do say that it works, what has been run with it?
Does it run an EBOOT.PBP file similar to the on that the MustUpdate 'exploit' was so hyped or does it actually run homebrew code? And if it does actually run homebrew code, which programs have been executed in this fashion?
Do not mind my disbelief or lack of knowledge, I haven't been around in a week or so.
Does it run an EBOOT.PBP file similar to the on that the MustUpdate 'exploit' was so hyped or does it actually run homebrew code? And if it does actually run homebrew code, which programs have been executed in this fashion?
Do not mind my disbelief or lack of knowledge, I haven't been around in a week or so.