PSP Flash Chip Facts: The Good, the Bad and the Ugly

zshadow · Post by **zshadow** » Wed Apr 05, 2006 7:30 am

Mathieulh wrote:In fact I don't think that the decryption keys changed either (I might be wrong tough) , at least I can decrypt my prx modules from my 2.60 games using the 2.00 key....

Otherwise if the key indeed changed you can get it form the mesg_led.prx file (that's probably how psppet retrived the other keys) but you need to extract the 2.60 psar first

If you did manage to get the 2.60 psar files from the data.psar file then you only need to retrieve the prx keys from the mesg_led.prx file

they arent using the updated keys in 2.6 games yet, but the core 2.6 modules can only be decrypted by using the new (3) keys.

yes i did extract the 2.6 psar however the key for decrypting mesg_led.prx is in the IPL. since psardump gives an incomplete dump of 2.6 ipl I am not sure if it got the required keys for decrypting mesg_led. (I've read nem's posts but don't really understand how to find the keys in the IPL).

Mathieulh · Post by **Mathieulh** » Wed Apr 05, 2006 8:12 am

You need the 3rd part called iplplayload
The best would be to set psardumper to extract the files without the use of the ipl decryption routine to get the encrypted ipl as psp_ipl.bin
Then use another app using the ipl decryption routine (you can get it either from psardumper or from Nem's infos) and decrypt the psp_ipl.bin with those.

Then retrieve the keys that should be located in psp_ipl part 3

Then you can either use the keys embebed within the IPL or dump the remaining keys from mesg_led.prx (the decrypted one)

P.S. What changes did you performed in psardumper so that it extract the 2.60 data.psar ?

Mathieulh · Post by **Mathieulh** » Wed Apr 05, 2006 8:21 am

harleyg wrote:yes. lets
however, just because i mentioned a runumd mod or whatever doesnt mean i support piracy. i buy my games, back them up and run the runumd mods, im not gunna wait for any updates to play games ive payed money on.
also, if Yoshihiro created the 1st proof of concept games on the ms example, its because of him umd emulator, fastloader, devhook, hookboot etc was created.
cant argue with that.

I agree about devhook and hookboot whitch are based on the wab loader (from yoshihiro) however umdemulator and fastloader (whitch use the same core) use undocumented VSH calls and APIs all from SCEI ! (Humma Kavula probably worked for Sony or was in contact with someone who knew all of the vsh functions) it also uses the very same code used on the DEM-100 (that still use special VSH functions) to mount the iso as a UMD device witch is used on the DEM-100 to perform UMD emulation directly from the USB (the iso is streamed from the USB and artifitially mounted on the DEM-100 unit using software embebed in the fw itself)
Humma Kavula was probably in violation of the NDA with Sony, that's probably why he stopped his involvments with the fastloader and umdemulator projects (he was probably afraid of beeing caught (or he was caught)

There was no way for a single person to perform that much reverse engeneering fast enough to come up with a UMD mounting software using the debug functions within the psp unless this very person worked for sony and had access to every piece of knowledge he needed.

And the Wab loader was only a proof of concept it has never been as close as running all the games devhook or umdemulator/fastloader ever ran.

P.S. I agree I don't like to update my psp to play games I paid for either, I didn't speak about you when I meant people doing piracy

zshadow · Post by **zshadow** » Wed Apr 05, 2006 8:21 am

Mathieulh wrote:You need the 3rd part called iplplayload
The best would be to set psardumper to extract the files without the use of the ipl decryption routine to get the encrypted ipl as psp_ipl.bin
Then use another app using the ipl decryption routine (you can get it either from psardumper or from Nem's infos) and decrypt the psp_ipl.bin with those.

Then retrieve the keys that should be located in psp_ipl part 3

Then you can either use the keys embebed within the IPL or dump the remaining keys from mesg_led.prx (the decrypted one)

P.S. What changes did you performed in psardumper so that it extract the 2.60 data.psar ?

ok, I'll give this a shot.

really simple to extract the 2.6 psar heres what i did:

open up psardump02 source and delete line

Code: Select all

#define DONT_EMIT_RAW_IF_ENCRYPTED

change line

Code: Select all

u8 g_dataPSAR&#91;13200000&#93; __attribute__&#40;&#40;aligned&#40;64&#41;&#41;&#41;;

to

Code: Select all

u8 g_dataPSAR&#91;15000000&#93; __attribute__&#40;&#40;aligned&#40;64&#41;&#41;&#41;;

now it will extract the psar

Mathieulh · Post by **Mathieulh** » Wed Apr 05, 2006 8:23 am

Thanks I'll try that ;)

I thought that psardumper might not be able to extract the 2.60 psar because it was too big for it to handle, looks like I was right after all :)
(I just didn't spend time in checking that theory)

That's also good to know that the psar format didn't change, the only thing that we miss are the keys required to decrypt the prx.

I am still waiting the 3.00 tough ;)

harleyg · Post by **harleyg** » Wed Apr 05, 2006 9:31 am

sorry for still being off topic:

(Humma Kavula probably worked for Sony or was in contact with someone who knew all of the vsh functions)

shame he didnt put the knowledge to better use......

ok now seriously, back on topic! :)

Mathieulh · Post by **Mathieulh** » Thu Apr 06, 2006 12:16 am

I agree it's really a shame :/

Just a little comment out of the topic:

If anyone know (or has the slightest idea on) how to extract the psp.arch files please PM me, I am VERY interested.

P.S. For those who don't know what a *.arch file is, don't even bother to ask, you don't need to know and you probably wont be able to help me to extract those. (And I can't tell you what it is or share a file either Sorry :/)

Post by **TyRaNiD** » Thu Apr 06, 2006 2:28 am

You cannot decrypt the 2.6 3rd stage part of the IPL as it decodes it before the usual decryption and the decode key is based on what is in ram at powerup which we have been unable to determine (cause it is long gone before we get our hands on it). Might be something to put aside for the hardware hackers.

As for umd emu/fast loader do you have any hard facts to back up your assertations that it uses undocumented vsh stuff? The devkit's disc emulation will invariably be a hardware bridge between a dvd rom drive and the ATA interface of the UMD drive just like it has been on pretty much any disc based console with similar features (there has the be a reason the devkit is so large). And due to the structure of the psp's filing system a simple IO drive is almost all that is required to emulate a UMD from an applications perspective.

At any rate the VSH is long gone by the time any games boot (it would need to be, you are left with like 3Mb of RAM once the whole VSH is loaded). I would expect most devs would use the host filing system for development purposes, only resorting to disc emulation to try out builds on a slower medium when they get around to it (there is little benefit emulating a UMD drive unless it works at the speed of a UMD drive which I am guessing umd emu does not). If there were special hooks in there it would be obvious in the UMD driver itself which on my limited inspection there isn't. Not withstanding the fact that it makes little sense to have them in there in the first place, at least on a commercial unit.

From what I have seen of umd emu it is just a straight patch the kernel affair like all warez loaders with some clever trickery to survive LoadExec (which is the special part as that is why it can show your warez in the VSH), not rocket science. If he had that much knowledge then why isn't there a version for the 1.0 firmware? You would have to be pretty deep in Sony to have access to information like that, which would mean finding them would be incredibly easy. I am not saying he didn't have access to Sony info, but probably no more than any official developer has access to.

Mathieulh · Post by **Mathieulh** » Thu Apr 06, 2006 3:22 am

Well you can find several of the vsh functions meant to mount an UMD device hidden within the vsh_bridge.prx (at least in the retail 2.00 version where most debug functions weren't removed from retail fws I don't know why tough) by performing a brute force using a dictionnary.
That's mostly what I base my asserations on.
I could be wrong tough and all the umdemulator does is to patch the kernel but I doubt it.
Beside the disc emlation can be slowered by software on the server side (that runs on a PC or on a Devkit) or even on the client side to render the UMD as precisely as possible.

Well I might be wrong in all that tough as I said earlier those are guesses and are far from beeing 100% facts, howeever it is my actual beliefs for now until I find something else suggesting me otherwise.

About the 2.60 IPL it seems like Sony did a great job in securing their new update, I bet they will use the same security on the 3.00 fw.

I think that hardware hacks will be required to decrypt the newer IPLs from now on. that's a shame tough :/

hopefuly the older IPLs can still be decrypted by software means (probably because sony didn't expect people to find out about the IPL and its decryption) (the newer IPL security also suggest that some people working at SCE probably browse the ps2dev forums quite often :))
The older IPLs still are the ones containing the most interesting flaws (the 1.00 IPL is pretty interesting ;) As well as are any DEM-100 IPLs hidden within some UMD modules :) )

zshadow · Post by **zshadow** » Thu Apr 06, 2006 7:52 am

ah, thanks for the info TyRaNiD, guess I should leave that to the hardware devs ;)

Mathieulh wrote: I think that hardware hacks will be required to decrypt the newer IPLs from now on. that's a shame tough :/

most likely :(

groepaz · Post by **groepaz** » Thu Apr 06, 2006 8:31 am

I agree about devhook and hookboot whitch are based on the wab loader (from yoshihiro) however umdemulator and fastloader (whitch use the same core) use undocumented VSH calls and APIs all from SCEI ! (Humma Kavula probably worked for Sony or was in contact with someone who knew all of the vsh functions) it also uses the very same code used on the DEM-100 (that still use special VSH functions) to mount the iso as a UMD device witch is used on the DEM-100 to perform UMD emulation directly from the USB (the iso is streamed from the USB and artifitially mounted on the DEM-100 unit using software embebed in the fw itself)
Humma Kavula was probably in violation of the NDA with Sony, that's probably why he stopped his involvments with the fastloader and umdemulator projects (he was probably afraid of beeing caught (or he was caught)

There was no way for a single person to perform that much reverse engeneering fast enough to come up with a UMD mounting software using the debug functions within the psp unless this very person worked for sony and had access to every piece of knowledge he needed.

oh boy, what a lot of uninformed ****.

listen to tyranid:

From what I have seen of umd emu it is just a straight patch the kernel affair like all warez loaders with some clever trickery to survive LoadExec (which is the special part as that is why it can show your warez in the VSH), not rocket science. If he had that much knowledge then why isn't there a version for the 1.0 firmware? You would have to be pretty deep in Sony to have access to information like that, which would mean finding them would be incredibly easy. I am not saying he didn't have access to Sony info, but probably no more than any official developer has access to.

its not rocket science. every selfrespected hacker who'd wanted to replicate what UMD emulator does could just use a disassembler on it, read and then do the same. infact a lot of people probably wouldnt even need to bother to do that (IF they wanted to create such a loader that is) and simply code the damn thing up at a weekend or two. because it is not rocket science.

so let me tell you what it does:

a) patch loadexec cleverly so some patches can be applied after returning to the vsh
b) patch into a few lowlevel functions of the umd driver (basically so all block access to umd are redirected to a file on memorystick)

no magic vsh functions, and no rocket science.

next time use the force^H^H^H^H^Hdisassembler. good luck.

Marco_N · Post by **Marco_N** » Thu Apr 06, 2006 1:11 pm

Though it's an interesting discourse, I hope it's the last bit we've seen here about the inner workings of said programs, because the mods here are very touchy on this subject.

This is a great thread about the flashability of the PSP's nand and it would be a shame if it would get locked. Thanks guys.

Mathieulh · Post by **Mathieulh** » Thu Apr 06, 2006 5:46 pm

My mistake groepaz and Tyranid are both right, I disassembled umdemulator and all it does is patching a few kernel functions (inclueding loadexec)
You're right groepaz I should have used my disassembler, I'll be more careful next time.
However that also means that some vsh debug functions meant to mount UMD devices (and perform other nice stuff such as getting the region infos etc etc) are still in the retail versions and that no one knew (or talked) about those before !

Perform a brute force on vsh_bridge.prx and check it out ;)

Finally I agree with Marco_N we have been a bit out of topic, let's get back to nand flashing shall we ? :)

BTW about the 2.60 I think Nem is the closest to finding the 2.60 IPL key thanks to his "lunar base" he should give it a go whenever he has time to spend on it :)

Alcahest · Post by **Alcahest** » Wed Jul 05, 2006 7:32 am

Besides hookboot and devhook are absolutely not based off yoshihiro's ms loader either. 2 cents.
Later,

Alcahest

groepaz · Post by **groepaz** » Wed Jul 05, 2006 2:17 pm

no ofcourse they arent, no doubt about that :)