Did anyone ever tried reproducing brokencode's hack? Here are my observation..
Starting in the first 4 KB block of Nand flash (OFW 4.05)...
16 byte data at 0x0FE0 is a IV (initialization vector). This is used with SHA1 to produce a Hash whose first eight byte form the first part of the signature (16 bytes at 0x0FF0)...
I tried doing this, first with HMAC-SHA1 using 16 bytes IV as key and 3904 (0xf40) bytes of IPL which failed to match with first eight bytes of signature at 0x0FF0. Second I tried simple SHA1 with initialization vector as 16 bytes + 4 zeros to make it 160 bits (20 bytes), again failed. Also tried combining IPL and IV, extra 16 bytes above IPL, IPL and IV, again failed. Did anyone ever tried this and got some match? Atleast for the first part of signature?
Reproducing brokencode's hack
Yeah, it would help a lot, if you could provide more information about this "hack" then we could possible assist you further.
Code: Select all
.øOº'ºOø.
'ºOo.oOº'-
willow :--)
- Posts: 107
- Joined: Sat Jan 13, 2007 11:50 am
A while ago a guy (nicknamed brokencodes) popped up on Dark Alex's forum and posted some code. (I googled for it and found this link: http://de.pastebin.ca/1325234 ).
Later Alek said on his blog this was a huge help in breaking whatever security is on the "unbreakable" motherboards (Pre IPL decryption I believe), although not sufficient.
Then nothing more was announced on the subject.
I assume the code in the link I posted above is what FriedChicken is talking about.
Later Alek said on his blog this was a huge help in breaking whatever security is on the "unbreakable" motherboards (Pre IPL decryption I believe), although not sufficient.
Then nothing more was announced on the subject.
I assume the code in the link I posted above is what FriedChicken is talking about.
-
FriedChicken
- Posts: 3
- Joined: Sat Oct 17, 2009 5:38 pm
Sorry, I think this topic requires a bit of explaination on my part. First I will like to invite folks to look at DA's explaination on why TA88v3 cannt be hacked by a pandora. Here is the link
http://pspslimhacks.com/dark_alex-expla ... be-hacked/
Notice that he talks about "2 Hashes". Also take a look at the pic showing those two hashes in OFW v4.01 and v4.05.
Now I will like to draw your attention to the post made by brokencodes (someone from DA forums). Here is that post..
http://de.pastebin.ca/1325234
All the numbers in the first part are nothing but the encrypted 1st block of v4.05 OFW. Pre-IPL shall pass this block through the KIRK hardware to decrypt it. At the end brokencodes briefly mentions about the two hashes. notice that the values from DA's original post and the ones in this are same. He mentions that, out of two hashes first one, stored at 0x0FE0, is actually an initialization vector (IV) to generate a hash. Such type of hashes are generally called HMAC (http://en.wikipedia.org/wiki/HMAC). First eight bytes form the first part of the actual signature stored at oxFF0. He says that the algo is HMAC-SHA1 with IV as Above IV. Another possibility is using the IV as initialization vector in a standard SHA1 (which is 0x67452301 0xEFCDAB89 0x98BADCFE 0x10325476 0xC3D2E1F0 in standard SHA1 algo).
I tried both the possibilites with a number of variants
1. IPL block encrypted with both the above mentioned schemes.
2. IPL block decrypted with both the above mentioned schemes.
3. Including IV in the hash calculation with both the schemes.
none of them seem to generate the first eight bytes of the hash stored at 0x0FF0. Hence I posted this thread asking people if anyone tried some other possibilities or any other ideas. Best if anyone ever reproduced the first eight bytes if the signature.
Few more observation...
First block of 4.01 and 4.05 are SAME (when decrypted), they are just encrypted using different KIRK keys hence their encypted body look different. However another interesting point is that their 2nd hashes are totally different, their first hash (or IV) are same. Second block have different bodies across version, yet their first hashes are same. This points to the HMAC/IV theory..
http://pspslimhacks.com/dark_alex-expla ... be-hacked/
Notice that he talks about "2 Hashes". Also take a look at the pic showing those two hashes in OFW v4.01 and v4.05.
Now I will like to draw your attention to the post made by brokencodes (someone from DA forums). Here is that post..
http://de.pastebin.ca/1325234
All the numbers in the first part are nothing but the encrypted 1st block of v4.05 OFW. Pre-IPL shall pass this block through the KIRK hardware to decrypt it. At the end brokencodes briefly mentions about the two hashes. notice that the values from DA's original post and the ones in this are same. He mentions that, out of two hashes first one, stored at 0x0FE0, is actually an initialization vector (IV) to generate a hash. Such type of hashes are generally called HMAC (http://en.wikipedia.org/wiki/HMAC). First eight bytes form the first part of the actual signature stored at oxFF0. He says that the algo is HMAC-SHA1 with IV as Above IV. Another possibility is using the IV as initialization vector in a standard SHA1 (which is 0x67452301 0xEFCDAB89 0x98BADCFE 0x10325476 0xC3D2E1F0 in standard SHA1 algo).
I tried both the possibilites with a number of variants
1. IPL block encrypted with both the above mentioned schemes.
2. IPL block decrypted with both the above mentioned schemes.
3. Including IV in the hash calculation with both the schemes.
none of them seem to generate the first eight bytes of the hash stored at 0x0FF0. Hence I posted this thread asking people if anyone tried some other possibilities or any other ideas. Best if anyone ever reproduced the first eight bytes if the signature.
Few more observation...
First block of 4.01 and 4.05 are SAME (when decrypted), they are just encrypted using different KIRK keys hence their encypted body look different. However another interesting point is that their 2nd hashes are totally different, their first hash (or IV) are same. Second block have different bodies across version, yet their first hashes are same. This points to the HMAC/IV theory..
In brokencode's explanation he mentions the IDEA (International Data Encryption Algorithm) in line 266, at least he calls the function "EnKeyIdea" and in line 269 "CipherIdea8B".
I googled a long time and found this: idea.pp. It's an unit for Pascal-based programs. I tried rewriting it for C/C++: here.
The first of both hashes depends on the unencrypted data block. The comparison between 4.01 and 4.05 shows it here. Both unencrypted data blocks are equal, so is the hash.
The first part of the second hash is the SHA-1 checksum with the first hash as IV. The second part is the result of the Signature-function. I assume that the vkey is the IV, sig are the first 8 byte of the SHA-1 with the IV from the data block, msg is the data block and len equals to the length of the data block.
This is how I understood it. I think there are some mistakes in my translated functions. Maybe someone wants to have a look at it. I wasn't able to find the functions for C/C++, even Google didn't find it for me. Also Koders wasn't able to show me the C/C++ functions.
So... anyone? :D
I googled a long time and found this: idea.pp. It's an unit for Pascal-based programs. I tried rewriting it for C/C++: here.
The first of both hashes depends on the unencrypted data block. The comparison between 4.01 and 4.05 shows it here. Both unencrypted data blocks are equal, so is the hash.
The first part of the second hash is the SHA-1 checksum with the first hash as IV. The second part is the result of the Signature-function. I assume that the vkey is the IV, sig are the first 8 byte of the SHA-1 with the IV from the data block, msg is the data block and len equals to the length of the data block.
This is how I understood it. I think there are some mistakes in my translated functions. Maybe someone wants to have a look at it. I wasn't able to find the functions for C/C++, even Google didn't find it for me. Also Koders wasn't able to show me the C/C++ functions.
So... anyone? :D
I'm no cryptologist but I simply don't understand what is being done here. All we have to work with is two hashes and the input used to calculate them.
How can you partially crack a hash? How can you even test whether what you have done is right or not since nothing in between is known; just the input data and hashes.
You could randomly try various combinations of algorithms (with some intelligent exclusions since I guess we assume its pure software and thus must entirely fit in the pre-IPL, or it can only make use of whatever hardware encryption algorithms are at its disposal) but Sony would have anticipated that people would try these combinations.
Just a small change in the algorithm (or trivial transformation of data between successive algorithms) would render any human attempt to crack it completely futile without looking at the pre-IPL.
What if aside from this, the decryption process has been modified to be secure and the forged block is useless? However if this was the case they needn't have the additional hashes...
How can you partially crack a hash? How can you even test whether what you have done is right or not since nothing in between is known; just the input data and hashes.
You could randomly try various combinations of algorithms (with some intelligent exclusions since I guess we assume its pure software and thus must entirely fit in the pre-IPL, or it can only make use of whatever hardware encryption algorithms are at its disposal) but Sony would have anticipated that people would try these combinations.
Just a small change in the algorithm (or trivial transformation of data between successive algorithms) would render any human attempt to crack it completely futile without looking at the pre-IPL.
What if aside from this, the decryption process has been modified to be secure and the forged block is useless? However if this was the case they needn't have the additional hashes...
-
FriedChicken
- Posts: 3
- Joined: Sat Oct 17, 2009 5:38 pm
Actually it is not the case that the decryption process has been changed, we can still decrypt the IPL. I think even using the older PSPs (like decrypting PSP 3000 IPL in Phat PSP). Only issue here is IPL block signatures. From what I gather these are HMACs of somesort. I deny the possibility of completely software implementation as that means substential amount of code in pre-ipl. size of pre-ipl is very limited plus you dont have lots of RAM available during that time, DRAM hasnt yet been initialized. From what I guess it is some HMAC.
You've misunderstood. The decryption algorithm will remain the same, meaning the IPLs can be decrypted on any PSP. The implementation alone needs to be changed to render the forged block useless. Like simply ignoring the entry address in the first block. Or not decrypting it in-place.FriedChicken wrote:Actually it is not the case that the decryption process has been changed, we can still decrypt the IPL. I think even using the older PSPs (like decrypting PSP 3000 IPL in Phat PSP). Only issue here is IPL block signatures.