Native PBP Unpacking Method?

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
Pikoro
Posts: 56
Joined: Thu Jan 13, 2005 9:57 am

Native PBP Unpacking Method?

Post by Pikoro »

Not sure if anyone has tried this yet, I haven't seen any mention on the forums:

What about a psp program that reads and unpacks the pbp from a firmware update and, using the on-board prx files from the flash, decrypts the raw image and then dumps it to the memory stick?

Basically, the method i'm thinking goes like this:

1. Copy the firmware update to the PSP.
2. Execute another program (the unpacker) and have it dump the extracted files to another folder on the MS.
3. Use in-flash .prx utilities to access or decrypt the encrypted flash image.
4. Decrypt the flash image using in-flash .prx
5. Dump resulting un-encrypted rom image back to the memory stick

Possible? Does it even make sense?
Kysen
Posts: 6
Joined: Thu May 05, 2005 4:17 am

Post by Kysen »

i think that you would want the v1 firmware to stay encrypted because it would only run on v1.5 this way
Pikoro
Posts: 56
Joined: Thu Jan 13, 2005 9:57 am

Post by Pikoro »

What I mean this for is to get access to the part of the flash rom that we cannot access with any of the pspdump type programs.

This would give us a "Clean" image. And instead of trying to reverse the signing or encryption, make the psp work FOR us. It already has the information in the firmware to decode/decrypt the firmware. I think all we need to do is find it.

Just a thought anyways.
pyrosama
Posts: 66
Joined: Fri May 13, 2005 1:08 pm

Post by pyrosama »

Ok so with that same concept in hand... If there is an encryption function (IE saved games are encrypted... firmware or umd function?) you could then encrypt the v1 dump for 1.5/1.51 systems.

Likely a bit more to it. You would likely need to examine 1.5 and or 1.51 to be able to create a flasher. But who needs the v1 then? Just write a varient of it that will allow any home brew to run.

P.Sama
steddy
Posts: 139
Joined: Mon Apr 04, 2005 3:53 am

Post by steddy »

No pyrosama, I think that Pikoro is onto something here.

There are no functions in the firmware which will encrypt / sign an executable with the Sony private key. Thats why developers have to sent it to Sony to be done and why there is both a BOOT.BIN and EBOOT.BIN on retail UMD's.

However, we know the function to decrypt the firmware exists because thats what happens when you run it on the device.

I would only be useful for looking at the file though. There would be no way to reflash it to a 1.5 device without an exploit of some form, since the 1.5 device will require that both the ROM and Flash executable are both encrypted/signed.

Out of interest, has anyone with a 1.0 PSP tried changing a file in the Flash which isn't encrypted (there are some, look for .PRX files which don't start ~PSP). Even just changing one byte of text? It would be interesting to learn if unencrypted files are still signed.

Steddy
pokesomi
Posts: 14
Joined: Wed May 11, 2005 11:27 am
Contact:

So why cant this be done

Post by pokesomi »

I think we are looking at this the wrong way. Why not capture the data after the decyrption and upacking are finished, like spyware only the capture happpends after everything is decoded?
pyrosama
Posts: 66
Joined: Fri May 13, 2005 1:08 pm

Post by pyrosama »

But if it decypts as it needs that file (IE doesnt decryped the entire file) The eboot contains the data file and if it is an archive file of some sort rather than just an executable then it wouldnt decrypt every thing at once it would decypt as needed so it decrypts say file a in folder 1 to be placed in flash1 then you would have to install the update to capture all of the files as they are installed - Just my thought.


PyroSama
Post Reply