forums.ps2dev.org

[PosX100]

[kralyk]

Just a though: If we can use PSP's hardware to decrypt stuff, can we use it to encrypt it back as well? If so, could we produce a piece of hombru, encrypt it using CFW PSP and then run it on OFW?

(Yeah I know it probably cant be done because if it could it would already have been done :D why?)
_________________
...sorry for my english...

[Torch]

[Raphael]

[Torch]

[moonlight]

Well, if the algorithm is AES128 based like the certificate verify opcode, and the "private key" is in the hardware, encryption is symetric, because the "private key" is not really private, it is public, it is there in hardware. Another different matter is that it cannot be retrieved easily.

[Wally]

[Raphael]

[rapso]

[jube]

i agree, right now the most productive avenue is to replicate what was achieved with pandora, and discover what sony did to block the process.
I have been spending time running round the net trying to collect the info and dev tools that were used to create the first pandora, in order to make as many of them public as possible and thus encourage "young blood" onto the subject. The problem is that the CFW scene is VERY secretive, and although T's presentation stated the pandora code was leaked, damned if i can find any of it ( yet !!! ).
Am still on the project while waiting for parts for PSPZ to arrive, will post any stuff i find.

[TyRaNiD]

For the IPL at least the key is in the clear, it is at the start of the block. It was noted that by adjusted the first 32 bytes certain parts of the output decrypted differently.

Of course we don't a) know what algorithm they chose, or at least if we can guess (say AES) then they probably have some sort of extra key permutation. And b) having the key isn't important as you cannot regenerate the hashes (so the theory went :P).

Now of course it will be interesting to see if the new hardware's IPLs are differently encrypted to the ones in the old PSPs causes if they are not we can still brute force the hashes, though without the pre-ipl flaws it probably won't matter.

And as for "pandora code" I am not sure what you are trying to find. The code to brute force hashes etc. was never made public, the rest of it (the custom IPL itself) could be reversed relatively easily even if there is no actual source code for it out there. What got leaked in the sense was ultimately the binary results of pandora (I am sure source went with as well) but that all that was required.

[jube]

ahhh, so thats why cant find it :) :),
Yep once realised how difficult the subject was just assumed could dig up all the associated code and method, ESPECIALLY the method of brute forcing the hashes :) , but been thinking about it some more and im proberbly trying to run before i can walk, i think i need to become fluent in mipps assembler first, then study 3.0OE which has the source, THEN should be in position to start staring at blocks of code in a hex editor and obtain something usefull.
T.... Can you suggest reading material? Am i near with my study plan?

[Torch]

How many brute forced blocks would you require to make useful code that can jump into whatever you want? (Though even getting the remaining blocks containing target code to be loaded poses a problem without the pre-IPL flaws).

Also, speculatively, they could have drastically changed the IPL verification process on the PSP3000 and future firmware after it ships with could install different formatted IPLs to the NAND depending on the PSP.

[Dariusc123456]

Do anyone know where the pre-ipl maped at? And if we Brute Force the hashes, what will happen if it dont work? We might just need to poison the hashes to get the information we need. And on the psp 3000, it might have more ram space , and it could have different pre-ipl mapped in different location of the psp.

[Wally]

[Dariusc123456]

Well, the psp 3000 might be ether TA-88v4 or TA-90. If we get to the pre-ipl on the ta-88v3 we can get more information on the new psp. While sony is making more harder encryptions keys, the psp scene isnt getting anywhere. We cant just give up and let sony win. From the begining of psp, til now, no hacker have gave up, nor will it happen this day. I know that no one will give up, and I know im off topic, but it will happen.

[jojojoris]

can't someone disamble a psp and analyse all of its parts? Or just get the data from some hardware parts?

[Torch]

[jojojoris]

[Torch]

[J.F.]

You need to take a few years on digital electronics, jojo. You clearly don't understand, and this isn't the place to teach you.

[angelo]

Won't everything be in binary anyway?

010000010110111001100111011001010110110001101111 = Angelo

Imagine lines of code!

Let's just wait till we cross that bridge, the PSP isn't impossible to crack and there will always be exploits!

Angelo

[Dariusc123456]

Hmm.... The psp io data. But where other than the flash and MS.

[Art]

[Torch]

The Cyrix M CPUs come to mind.

[SilverSpring]

Just to clear up some things.

The security relies on both encryption and a signature. The code needs to be both encrypted then signed for it to work. The block cipher it uses for the encryption portion is almost certainly AES (though how the block cipher is being used is unknown).

The base operations that KIRK is capable of:

1) 128bit block cipher (almost certainly AES)
2) SHA1 hash
3) random number generator

There are multiple commands you can issue to KIRK (18 commands in total) and all operations are made up of either or a combination of the above algorithms. The main command, the one resposible for decrypting prxs, eboots, ipl blocks etc. is command 1.

The signature portion is not a 'digital signature' in the traditional sense but more like an HMAC. The fact that KIRK is capable of SHA1 and the fact that SCE uses a standard SHA1-HMAC algorithm in numerous places, the 'signature' portion of command 1 almost certainly involves the SHA1-HMAC algorithm. So the 'private key' needed for all of this to work is actually just the secret key for the HMAC (hidden embedded somewhere inside KIRK).

For the encryption portion, it almost certainly involves the AES algo (other KIRK cmds have been confirmed to use the AES algorithm plus standard Sony media literature always mention the fact that the PSP has AES capabilities). The key for this portion seems to be provided with the encrypted data to be decrypted (in the header). So there is no hidden embedded 'private key' for this portion of the encryption, you supply your own key. There are other KIRK commands that just do a block cipher encrypt/decrypt, for those there is an embedded hidden key but this is not needed for command 1 (they are used for general purpose encrypt/decrypt operations). There are also multiple "sig" type KIRK commands that use the AES algo heavily which also use a hidden embedded 'private key' but again is not needed for this purpose (used for multiple things like idstorage keys, adhoc communications, etc). For this purpose ("encryption" of prxs, eboots, etc) the key is supplied with the data.

So the PSP's "encryption" is symmetric. So then what is needed to be able to 'sign' our own code the way Sony does is:

1) figure out how the AES algo is being used for the "encryption" part (to encrypt our code).
2) figure out how the SHA1-HMAC algo is being used for the "signature" part (to sign our encrypted data).
3) find the secret key for the HMAC (so our encrypted data appears to be "signed" by Sony) <--- this is what their entire security is relying on essentially (keeping this key secret)

All 3 are as equally difficult as each other so I wish anyone attempting to crack their security much luck.

Also note that while for every KIRK command there is an inverse command to do the opposite. Ie. for every "encrypt" command there is a corresponding "decrypt" command, this is not the case for the above. So we cannot just rely on KIRK hardware to "sign/encrypt" our eboots, we have to figure out the algorithms and implement them in software (which is most certainly how Sony "sign/encrypt" their code).

[Torch]

So from a theoretical point of view, their protection is completely insecure. Its not even a protection to begin with.

All they are relying on is the fact that the chip cannot be reversed.

Wonder if the PS3 is also like this or if they use a public key cryptosystem.

[jean]

[kralyk]

I bet the random number generator sucks terribly. These pseudo-random number generators usually do. Not that it would help us, I dont think so.

jean: I dont think that would get us anywhere, they could have so easily made the key long enough to prevent even world's most powerful distributed systems from bute forcing it.
_________________
...sorry for my english...

[jean]