Cracking the PSP OFW without pandora

jube · Post by **jube** » Thu Aug 14, 2008 11:49 pm

as is all over the news sony has finally got round to blocking acess to the OFW through pandora on recent motherboards, and as is postulated on the psp3000. So thinking into the future i think we need to start working on another way in!

I have a few ideas involving the sio, i believe the sio ( original ) has the facility to detect plug-in "debug " boxes thus theoretically has the potential to put psp into a mode that might alow a CFW to be loaded. I intend to continue work posted for the phat in this area, by brute force attack combined with insight to find the sio "key" ie set of serial data that would initialise the debug unit. If anyone else has ideas on this please post, unless we want to see an eventual end to homebrew i think this must be worked on.

Post by **TyRaNiD** » Fri Aug 15, 2008 3:08 am

No it didn't :)

jube · Post by **jube** » Fri Aug 15, 2008 3:19 am

bugger!! , ok thanks saved me a deal of work !

Are there any other avenues left unexplored, does the original Lumines or GTA crack still work?

KickinAezz · Post by **KickinAezz** » Fri Aug 15, 2008 4:23 am

jube wrote:bugger!! , ok thanks saved me a deal of work !

Are there any other avenues left unexplored, does the original Lumines or GTA crack still work?

BMX is a good game to look into for such exploits...

The gameplay in the game is so awful... I wonder if they really took security into consideration. :D

Post by **TyRaNiD** » Fri Aug 15, 2008 6:48 am

There is certainly undisclosed exploits :)

KickinAezz · Post by **KickinAezz** » Fri Aug 15, 2008 11:38 am

TyRaNiD wrote:There is certainly undisclosed exploits :)

In hold for 0 day release?

jube · Post by **jube** » Fri Aug 15, 2008 3:00 pm

cool.. will start looking in the exploit department, am still very new to the psp, so dont expect progress soon :) :)

Torch · Post by **Torch** » Fri Aug 15, 2008 6:58 pm

TyRaNiD wrote:No it didn't :)

What? You mean the pre-IPL is still exploitable? Or are you talking about software exploits that have not been used?

Hellcat · Post by **Hellcat** » Fri Aug 15, 2008 7:51 pm

Most certainly software exploits.... but a small hole in the PreIPL would be sweet as sugar :D

jube · Post by **jube** » Sat Aug 16, 2008 1:28 am

is there anything else in the hardware that can be attacked? what happens if system detects corrupt memory/memory area, thats a good way in on a lot of systems, is there any real-time-clock? , how about a WDT reset? Anything that prevents a clean boot could be interesting

kralyk · Post by **kralyk** » Sat Aug 16, 2008 7:03 am

How about wifi - adhoc game sharing? On a pc with wifi, we could make an app that would "share a game" with the psp, and the "game" would actually be some usedul code, cfw installation for example...
that would be pretty cool.

Is psp's game sharing algorythm known?

ne0h · Post by **ne0h** » Sat Aug 16, 2008 7:23 am

I've already think to intercept the data while is sharing, and replace it with a different code (or send it from a modified(with CF) psp), but (I think) the data sended is sign-checked before run it, so is not a good idea...

kralyk · Post by **kralyk** » Sat Aug 16, 2008 7:26 am

And what about not intercepting the data, but sending a "game" to OFW psp from CFW psp?

jube · Post by **jube** » Sat Aug 16, 2008 8:59 am

as i understand it once OFW is booted it will only run code that passes the sony security cypher. So again as i understand there are 3 options

1) stopt the CFW booting ( ie pandora)

2) crack the sony cypher

3) find a piece of code that is already secured but that allows CFW to be loaded ( ie lumins exploit )

is this correct ?

jube · Post by **jube** » Sat Aug 16, 2008 4:56 pm

ok asked some engineer friends that specialise in reverse engineering.

The obvious answer is to JTAG the CFW onto the system E2PROM, this is an infallible solution since the processors are not clocking at all during a JTAG session. Problem, is that its not for everybody, and i would have to find the jtag points on the motherboard, and you need a JTAG box.

Would it be of any use to anyone to dump the system non-voilitile mem to a hex dump?

Apparently the phat circuit diagram exists, been reverse engineered by a company that specialise in these jobs ( $2000 , you give em the device , they give you the circuit ! , pity the FW doesnt come with that :) ) But its $60 a copy !

Post by **TyRaNiD** » Sat Aug 16, 2008 5:08 pm

Shame in all likely hood they have cut the JTAG wires going to the CPU :)

jube · Post by **jube** » Sat Aug 16, 2008 6:38 pm

doubt it, they will need JTAG access for production testing, so thats either to test points on pcb picked up with a pin array grid on a production test machine, or a micro-connector somewhere. ( some clever bastards even have stuck the jtag through short range rf link to onboard jtag micro, so you just test by passing wand over, trick eh !! )

If the design engineers run to form its prob on a jtag chain, including the memory arrays and any FPGA config memories, prob got their own format to recover individual units.

If they have no jtag cant think how they would do the hardware test algorithms, but have to confess not current on design for test, so just speculating.

ne0h · Post by **ne0h** » Sat Aug 16, 2008 8:11 pm

I don't know very well how the sce signature works, but It's really impossible to crack it?

Post by **TyRaNiD** » Sat Aug 16, 2008 9:32 pm

If I was doing it I would have fuses in the CPU die which could blow to take out the jtag, do your hardware test then at final test time you take them out, certainly i have heard rumours of the test pins being identified but them not actually doing anything.

jube · Post by **jube** » Sun Aug 17, 2008 1:49 am

damn it twice !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Sounds just like the thing they would do.

Post by **TyRaNiD** » Sun Aug 17, 2008 3:27 am

Well because it is a closed architecture (and it needs to be to support their business model) it is imperative to prevent against just adding a modchip :)

jube · Post by **jube** » Sun Aug 17, 2008 4:15 am

yea, seems IP protection stratagies are maturing, there are a bunch of companies doing just that. Used to be able to figure a lot out ( not direct ref to psp ) from dumping FPGA config memories, but now its popular to encrypt even that.

The sig check is only run once on module load time, ( is that tru ? ) what if you could dynamically ( within the acceptable mem clocking/caching params ) change the contents of memstick addresses ( by simulating a memstick with micro then putting custom data in dynamically ), could it be theoretically possible to have standard module call + run sig check, but then the contents fetched and loaded would be what we chose?

Hellcat · Post by **Hellcat** » Sun Aug 17, 2008 4:20 am

Isn't the signcheck performed when the module is already completely loaded into memory?
If so, what good would altering the MS data do after the signcheck has been done?

Dariusc123456 · Post by **Dariusc123456** » Sun Aug 17, 2008 4:47 am

ne0h wrote:I don't know very well how the sce signature works, but It's really impossible to crack it?

Its possible to crack the sony sign-code and get it, but its hard. Plus if we do, I think that sony will have the right to sue that person (i think) but who cares about what sony think??? They mess around with the wrong hackers, lol...

Dariusc123456 · Post by **Dariusc123456** » Sun Aug 17, 2008 4:53 am

Hellcat wrote:Isn't the signcheck performed when the module is already completely loaded into memory?
If so, what good would altering the MS data do after the signcheck has been done?

Well, I know it will not work, but what happen if we can try to react thw Swaploit? Like we run the unsigned program, and if it load onto the memory, we switch Memory sticks with one that have sony official coding (sign code), or am I saying the wrong way??? Its like performing the Magic Swap on a ps2, but we are not using disc, we using memory stick.

I wonder....

Do anyone know if I use an unpacker and unpack a eboot.pbp from sony code, is it possible that it will keep it sign-code after unpacking so that we can add our data to it?

ne0h · Post by **ne0h** » Sun Aug 17, 2008 5:10 am

I think that all the data has to be "signed", or not?
OT
DAX have relased a ~PSP packer but he say that the signature are not added, so the sce signature are a special number of bytes crypted by a private key that depends by?by all the file?
/OT
Thanks...

Post by **TyRaNiD** » Sun Aug 17, 2008 7:29 am

For a start, psppacker (DA's hack of the ~PSP stuff) is dependant on the the CFW stuff. Breaking the crypto is none-trivial, it could take millions of years, pandora only works because they fucked up, badly...

jube · Post by **jube** » Sun Aug 17, 2008 8:37 am

thats kind of why was looking for a hardware way in ( appart from being a hardware bloke and always looking for a hardware solution ! too many hours near a emc chamber fried brain :), if they missed pandora what else did they miss? Although so far its not looking good.
Obviously as we get into softer-ware im useless ,aside from provoking thought, cos not experienced with the psp os enough; but if anyone needs anything building to help, just post.

Dariusc123456 · Post by **Dariusc123456** » Sun Aug 17, 2008 11:35 am

I wonder.. Is it possible to reverse the signing possess by using the pack-pbp or unpack-pbp? Just asking...

But if we find out the sign code, will sony change it within the next firmware?

EDIT:

Sony didnt completly block pandora, but they just block unsigned ipl.

jube, pm me. i think I got something that might help you. If sony receive it, then they can block it easily. lol

jean · Post by **jean** » Sun Aug 17, 2008 8:10 pm

Just brainstorming:
-a signcheck needs the following to be performed:
long-long-long-long-... math lib usually done in slow software, hash computer and the public key to check against.
I don't think newer chips mount a whole alu dedicated to signchecking, so it has to be the main CPU that handles this. So:
-Program checking signature is a program itself, and hence it boots (too bad it does not reside on MS, but we can still try to attack here).
-The public key to check against is -well- public, it should come in plain near the verifier program.
-It's not a good idea to try to find the private key: it could never be done in human lapses of time and would be pointless: if i lose my home's key i would replace key and keyholes.
-We could replace the public key with the public part of a newly generated couple (or is it engraved on PSP's MoBo?? lol) whose private side we obviously know. That's only for ipl stuff, originals would still work because in a CFW signcheck on executables is not performed at all. (btw...is it the same key on IPL and on executables??)

hope this can help someone having a revelation....

jean