forums.ps2dev.org

[pspmanly]

http://www.psphacker.com/2005/05/mustupdate.html

This may be worth noting about this post:

Magnus the shadow sent this in: The MustUpdate file can run on PSP v1.5 and it is possible to alter it through PSP Unpacker for .pbp files and an ELF2PBP converter. It will be possible for an experienced programmer to create a new .sfo file using the MustUpdate\'s .sfo as the core. Once the .sfo is altered it can be used to run Homebrew apps on a PSP v1.5. Just run the .pbp from the Game\\MS area twice: the first time it will be declred corrupt, the second it will run the app. Best of luck with this

[F9zDark]

Well unless I screwed up, it doesn't work on 1.51. I am really hoping that I screwed up, because I'd really like to play some homebrew tetris on here. :(

I'll try tinkering around some more with it.

EDIT:

Still no go. Dammit do I wish I did not update. >:-|

[Thanhda]

nope you didnt screw up. unless we are supose to do more then just place the file the psp. you didnt do anything wrong. and the program doesnt start. it says needs to be updated. can someone with 1.0 please confirm if it does the same thing.
_________________
There are 10 types of people in the world: Those who understand binary, and those who don't...

[F9zDark]

No no no... See with mine it just says "Corrupted Data" and wont even run.

If you got the "Must Update" thing then you got further off than I did. Try it again, just turn off the WiFi so it cannot access Sony's sites and update wrongly, if it does.

[DrainBamage]

That's because you placed the file in the "update" folder. Make a new one and name it whatever you want and place the EBOOT.PBP there.

It does work for 1.51

[n1ckn4m3]

All I get is 'To start you must update the system software'. Doesn't matter how many times I try and start it... I get the expected behavior. My modifications to the PARAM.SFO evidently must either be incorrect or must not work in general.

Can anyone point me to a forum post or other link for information regarding the PARAM.SFO? I concatenated the file I've got now from diddling about with the existing PARAM.SFO from SNES9X and the MustUpdate -- but evidently I did something wrong. Regardless of how many times I run it, on my 1.5 PSP, it shows a japanese name and tells me I need to update to a newer firmware..

Can anyone confirm this? If so, can they explain in better detail what must be done in order to use the MustUpdate to launch homebrew on the 1.5 PSP?

EDIT: Evidently in my idiocy, I did not edit the required verson of firmware. Duh. Now that it's set at 1.5, the game 'boots' and plays the PSP splash screen, but all I get is the "The game could not be started (80020001)" error. This being the standard error and assuming that this hack actually works,, I'm guessing that my PARAM.SFO hack is not properly completed... Just FYI.

EDIT: More playing with directories and whatnot have lead me to another point... If I am correct in assuming we should be attempting to run this as an update, I'm failing again -- in the PSP\GAME\UPDATE folder it only shows the 'Corrupted Data', as the previous poster suggested.

I am unable to get the corrupt/run results the poster explains above... Is there more information on this hack?

UPDATE: (Don't know if this matters or helps) http://www.psphacker.com/2005/05/modified-version-must-update-file.html

[senas8]

UPDATE:

Quote:

Magnus the Shadow sent us a version of the Must Update file that he worked on.

HACKEDEBOOT.PBP is a version that proves the buffer overload method.

1.0EBOOT.PBP is a version that can be run an any PSP.

Just put this on your PSP (PSP ver 1.0/1.5, unsure of 1.51)
under "PSP\GAME\HACK" and rename the .pbp as eboot.

Go to GAME on the PSP Menu and then go down to MEMORY STICK
Execute the file, you will receive the error message of it being corrupted. Ignore that by pressing "O" and then
press "X" again it will bring up the "you must update the ver." window.

[BiMP]

I'm going to post the same thing I wrote in the comments on the PSPHacker site.

[Sonikku_a]

Erm, so whats the deal here exactly? if all we get is the update error, is it actually running code? Im not getting this. Was this app homemade? If not then of course it would run if sony signed it.... ?

*confused*

[BiMP]

[SchmuckofNI]

So thats where someone with knowledge of elf scripting comes in..

[BiMP]

[senas8]

well what is interesting is that it gives you an error, but after pressing the O and X boots you in......buffer overflow?

"Execute the file, you will (receive the error message of it being corrupted). (Ignore that by pressing "O" and then
press "X" again it will bring up the "you must update the ver)"

[SchmuckofNI]

Hmm. Well at least with this we are 1 step closer to running homebrewn. If elf scripting was anything remotely close to C I think I could help out.

[Sonikku_a]

Ah, just the daily " get excited for 5 minutes then figure out its got jack to do with shiat and you still aint got no homebrew " PSP mind fark :P

Carry on then lads. :-)

[F9zDark]

Well I am trying my best to recompile another program with this SFO file to see how it works. I do not have a PBP packer and cannot seem to find one.

[n1ckn4m3]

Results of my simplistic tests:

1.0EBOOT.PBP results in an error: The game could not be started (80020130). -- (0 length executable)

Extracting the PBP and dropping in the DATA.PSP from SNES9x results in an error: The game could not be started (80020001). -- (Standard unsigned code error)

The bizarre thing is that once in every 4 or 5 times I attempt to run the SNES9x/EBOOT hybrid, the screen fades out as though it's a PSP game... Most of the time it goes from the white PSP logo straight to black, and then to the error message... This seems to happen most frequently when it is the first program run on the boot.

Does this help at all?

To clarify, I did NOT expect SNES9x to run, I just wanted to see if I got a different error attempting to run unsigned code than normal... It didn't, but it DID exhibit the strange fading behavior.

It seems to me that all this does is get us back to where we started from, but it is making us have to start the program 3 times before it boots. Unless it's possible to construct a perfect buffer overflow to launch a loader here, I don't see how this helps. Secondarily, if we COULD construct a perfect buffer over flow here --- I don't see why we'd need this EBOOT.PBP at all, as theorhetically the buffer overflow could be run by itself without use of this 'hacked' .SFO.

Then again, I'm not a great developer. My experience in the field is almost 20 years old now. I'm not hip with the new stuff :).

In no way do I mean to frown upon whomever's work this is, just noting my experience and opinion.

Thanks guys!

Also: F9zDark, check out PBPUnpacker in the files section of PSPHacker.com -- it also makes .PBP files as well as extracts them.

Good luck!
_________________
... anyone up for some l33th4x?

;)

[F9zDark]

I used the SFO file from the 1.51 update, changing the entries to say PSP Pong where-ever PSP Updater - 'in other languages' appears.

I packed this SFO file and the PONG - EBOOT.PBP files (minus the SFO) into another PBP file and put that on my PSP.

I goto run the Pong game, which isn't shown as corrupted or anything. It loads the happy PSP white screen, which is normal for games, then goes black. Then the an error occurs:

"The game cannot be started (80020001)"

I assume this is normal for all homebrew code on the PSP for 1.5 and 1.51.

Apparently the signing/encryption methods are not stored in the SFO file(I bet many people already knew that.). I think DATA.PSP is where the needed information is displayed. I will scour the one that came with the update to see if there is anything that can be found.

UPDATE:

I included the DATA.PSAR file from the Updater. I got a different error code:

"The game could not be started. (80020148)"

[n1ckn4m3]

From what I understand, the .SFO isn't hacked to allow the DATA.PSP to run -- it is a proof of concept to show a buffer overflow in action, caused by the .SFO. From what little I can pick up, in order to run homebrew using this someone will have to write a loader that is immediately run after the buffer overflow -- FROM the .SFO file... As the buffer overflow is in that file, it would execute the code directly after that.....

I'm not quite sure though.
_________________
... anyone up for some l33th4x?

;)

[Thanhda]

[F9zDark]

This is what I did after I found out that PBPUnpacker was a packer as well:

I edited the SFO file and added in the DATA.PSP file and other files from the Pong Portable game's PBP file into a new PBP file. I got Region Code errors(I originally edited the SFO file that is the '1.5 homebrew launcher'). Then I incorporated the SFO from the 1.51 updater PBP, and changed the title to PSP Pong, made a PBP and put it on the PSP.

It launched flawlessly, until it went to run the code and deemed it unsuitable for the PSP and returned the error: "The game cannot be started."

From this bit of testing I(n00bishly deduce) that an SFO file is just a link to inside the PBP file that the PSP uses for the OS. Hence why all of the information encoded in the SFO appears in the Information screen in the GUI.

It is evident that the SFO is the first step towards any working program(since shoddy-written SFOs, will produce errors, for example the Region code error I recieved...).

But is this the giant leap to homebrew on the PSP? I do not think so. We still need the biggest pieces of the puzzle to run code on 1.5 and Up firmware: Encryption and Signing methods.

Perhaps there is something in the SFO that can spurn the launch of another program, that bypasses completely the encryption/signing check. I thought that perhaps if I included the Pong code, before the Updater code in the DATA.PSP for the EBOOT.PBP I packed, that maybe, by some chance, it would execute the game and then just run the updater later, which can obviously be aborted, but seemingly the PSP isn't so simple to crack.

Maybe its just that I am the simple one. Who knows. Time will tell if this really does work for Homebrew or not.

[Pikoro]

I dont' see how this is a buffer overflow at all. All it does is check the firmware version number. After that, nothing executes. Big deal. no matter what you put inside, it won't run.

I dont' see how this does anything for homebrew on 1.5+ except it gives us one more error code to add to the list...

Cheers

[piercer]

Another problem you might all be encountering is the fingerprint hash!

A known example of this is in DATA2.BIN and is an SHA-1 digest (I think, need to go over java code again to make sure) of the data in the file. I personally believe some of the unknown data is sfo file is a hash of this sort and so If you change the contents of a PBP I believe you will have to upgrade this 'fingerprint' as well.

Good luck.

[steddy]

The only thing this is proving is how the system checks the version in the SFO. Since the SFO is packed in a PBP which is an archive it makes sense that a part of the container tells the system what firmware is required for the entire application.

This is not a buffer overflow attack, all you are doing is setting the same Flags that Sony will update to force a firmware upgrade.

The BEST thing about this is the SFO is NOT signed. We know this because we can change it without reporting errors. That means if we want to run a PBP from Sony which has this Update Required flag set, we can just edit the SFO and reduce the version number down so it will still run on 1.0 PSP's.

Steddy

[DrainBamage]

[Drakonite]

[Guest]

[modrobert]

"The doors of Durin, Lord of Moria. Speak friend and enter."

[boomint]

"Mellon"

Is that the ELF scripting we need to open the psp doors too then?

As an aside, here's DIY ELF script

http://www.psxdev.com/ElfScript1_0.zip
_________________
--( someone stole my sig! )--

[F9zDark]