Dariusc123456 wrote:Why cant someone make a homebrew program that will capture the process and find any holes while its running/debugging sony programs
Because its not that easy?
There are still a lot of functions undefined in the SDK as the devs don't know or can't be bothered ;) finding what they do. That is by miles much more important than allowing rampant noobs coming to the scene and asking "WHERE IS MY PS2 EMULATOR" then they release some LUA shell clone.
Wally
Listen, im not here to argue about the past. If we want the to get cfw for the newest psp, we have to work together.
q.q , like a f4m1ly ... LMAO... who's that guy???.
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?)
kralyk wrote: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?)
The encryption is symmetric. We just have to use the same decryption key to encrypt. But we don't exactly know the key, we just ask the PSP to give us the data after decryption.
On top of that the signature is also checked which can't be cracked.
kralyk wrote: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?)
The encryption is symmetric. We just have to use the same decryption key to encrypt. But we don't exactly know the key, we just ask the PSP to give us the data after decryption.
On top of that the signature is also checked which can't be cracked.
It is actually asymmetric, else we would have the key to encrypt things (if we also had the algorithm). Unfortunately, we only have the public key, which is stored in the eboot to let the decryption hardware decrypt the stuff, but there's neither an encryption engine, nor the private key to do so.
Once and for all: If you (directed at the lot of people out there having ideas on cracking PSP) want to help provide homebrew support for the next PSP generation, then keep away from any ideas about "breaking the encryption". It's not worth any further discussion. It can't be done in a human lifespan and not even in finite time unless we know the exact algorithm(s) involved. Full stop.
Raphael wrote:
Once and for all: If you (directed at the lot of people out there having ideas on cracking PSP) want to help provide homebrew support for the next PSP generation, then keep away from any ideas about "breaking the encryption". It's not worth any further discussion. It can't be done in a human lifespan and not even in finite time unless we know the exact algorithm(s) involved. Full stop.
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.
Dariusc123456 wrote:Why cant someone make a homebrew program that will capture the process and find any holes while its running/debugging sony programs
Because its not that easy?
There are still a lot of functions undefined in the SDK as the devs don't know or can't be bothered ;) finding what they do. That is by miles much more important than allowing rampant noobs coming to the scene and asking "WHERE IS MY PS2 EMULATOR" then they release some LUA shell clone.
Wally
Listen, im not here to argue about the past. If we want the to get cfw for the newest psp, we have to work together.
moonlight wrote: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.
In that case you are right, it is not really asymmetric but symmetric. It's still not really a public key, as that would mean it were openly accessible :)
Even if it were, we couldn't do much with it unless we find out the algorithm.
Anyway, that still doesn't make a difference to the point: trying to break the encryption is pointless ;)
moonlight wrote: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.
In that case you are right, it is not really asymmetric but symmetric. It's still not really a public key, as that would mean it were openly accessible :)
Even if it were, we couldn't do much with it unless we find out the algorithm.
Anyway, that still doesn't make a difference to the point: trying to break the encryption is pointless ;)
it would, if it would be symmetric and you'd get the key, there wouldn't be anything you'd need to break.
I'd assume they use asymmetric encryption to save a symmetric key which they then use to check the binary's signature.... that's just a guess, but a common way ;)
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.
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.
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?
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.
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.
Dariusc123456 wrote: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.
I guess we'll have to wait for the PSP-3000 to find out :P
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.
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).
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: ...
This is a good new: at school they teached me that encryption strength is never dependant upon algorithm secrecy. So the idea of a distributed brute force attack is not useless at all. I mean: HMAC must be always the same....Let's distribute a small app that:
1 generate small random data (or sequential one, but this way there is the need of a webservice distributing different jobs)
2 encrypt data with kirk functions related to HMAC
3 tries to obtain the encrypted data from unencrypted data without kirk, using guessed AES variants and a random key
The more users, the faster result....how about key length?
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.
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.
If it was asymmetric i would agree, but with symmetric...i think it has not to be that hard...the problem that requires more competence is the algorithm variation...
