First a huge thanks to Gusha for his huge support donating a lot of time for testing stuff on his TA-88v3, cheers mate! This post I’ll describe what I have found out so far with the TA-88v3 and provide a model representing the security and operation of the TA-88v3 pre-IPL. Unfortunately, the hash has not been broken but this could be some useful information.
First, lets recap what we know already. The IPL is the “Initial Program Loader” bla bla, it is stored on the NAND or on the service mode memory stick and is divided into chunks of 0x1000, the size of the buffer used at 0xBFD00000 where they are decrypted. The IPL blocks are a standard KIRK cmd 1 block and passed directly for KIRK for decryption.
Now, Prometheus team broke this using a timing attack to calculate the CMAC hashes. Sony had to counter this and this is what Dark_AleX described it as:
The security of kirk hashes was destroyed by a timing attack, and the IPL became unprotected.
What has Sony added to fix this?
The answer may lie in the ipl’s of PSP Slims with firmware 4.0. Decreased body size encryption 0xF40 to leave 0x20 bytes at the end of each block (exit 0xFE0)
As discussed above, these remaining bytes were ignored … in pre-ipl’s of pre-TA88v3 PSP, and in fact can be randomized and ipl will still boot in those psp’s. In newest pre-ipl’s, these 0x20 bytes have a meaning.
The first 0x10 bytes is a hitherto unknown hash calculated from the decrypted block. It is deduced that is calculated from the decrypted block and not the ciphered as 4.01 and 4.05 have a lot of ipl blocks in common, which, when decrypted, are similar, but they are totally different in its encrypted. In these two ipl’s, the hash is the same, as you can see in the image
Then followed these two images to illustrate this idea:
He then continued to summarize:
The second 0x10 bytes seem to be equally dependent decrypted body (maybe dependent of the previous 0x10 bytes too?)
In the picture you can see they are different in 4.01 and 4.05, but can be interchanged, you can move those 0x10 bytes from the same block in 4.05 ipl to the 4.01, and will continue to charge, but however, this change can not be random.
This protection also destroys any possibility of downgrading below 4.00, as these new CPU’s will not be able to boot previous firmwares ipl’s with those.
Summary: basically, all security of newest psp cpu’s is based on the calculation of those 0x20 bytes.
If pre-ipl could be dumped in some way, that security would fall COMPLETELY.
All in all, pretty accurate. This second “pseudo-random” block of 0x10 bytes however confused a lot of people. People had strange and completely incorrect ideas such as “Brokencodes” promoting the IDEA algorithm for this application. Infact, people went to depth to try to re-create Brokencode’s calculation with clear failure. This second “psuedo-random” block was a nightmare people thinking it was digital signatures and such when in fact it could be much easier.
Imagine that “[block 1]” is a block of 0x10 bytes and “[block 2]” is also 0x10 bytes. In memory they look like:
[block 1][block 2]
This is our hash buffer, it stores 0x20 bytes as we expect. Now, lets look at the pre-IPL: it’s 4kB not a lot of space and it needs to do everything it does in the SLIM pre-IPL for backward compatibility. What resources does it have available? It has KIRK which provides a SHA-1 algorithm interface so surely SHA-1 is a good choice?
A SHA-1 hash is 0x14 bytes in size. So it will fill all of [block 1] and 4 bytes of [block 2].
Lets propose SCE do this.
We look at the 4.01 and 4.05 ipl which are identical when decrypted (at least for the first ipl block).
[4.01 hash block 1] [4.05 hash block 1] [4.01 hash block 2] [4.05 hash block 2] [4.01 hash block 1] and [4.05 hash block 1] are identical and the other blocks are not but they can be interchanged. So, what is this? It’s probably encrypted maybe? Think about it, if Sony could store 0x14 bytes instead of 0x20 they would. AES operates on blocks of 0x10 so the SHA-1 hash would need to be padded out 0x20 bytes. Lets assume that they use a random meaningless padding. It means that the second block, although containing 4 bytes of a SHA-1 sum contains 12 bytes of random data, which will make the encrypted block look random!
Assuming this idea, it would be silly for Sony to use anything other than KIRK 7 for the decryption (since there is no inverse). Initially I tried this and got no matching 0x14 bytes for any seed… but Proxima kindly pointed out that I wasn’t testing all the KIRK 7 seeds, (doh!). So yeah, guess what happened? KIRK 7 seed 0x6C resulted in the decrypted IPL hashes to match for 0x14 bytes! yaaaay!
This is sad story though. It wasn’t the SHA-1 value that it resulted in. I haven’t done a lot of analysis but it is probably some sort of permutation of the SHA-1, probably HMAC-SHA1 if Sony has any sense.
As for the pre-IPL, it does no checks on the encrypted data besides determining if it’s an ECDSA block or no. ECDSA blocks are determined by loading block + 0x64 and checking msb for 1. If it is true, it is an ECDSA block and it copies 0x28 bytes from block + 0xA0 in addition to the standard procedure of copying the 0x20 hash from 0xFE0. This copying is fixed and not calculated from the end of the data. So if your block only fills upto 0x100 of the IPL block, the hash will still have to be at 0xFE0.
The pre-IPL then goes on to decrypt the kirk data. Then all the hashing is done on the decrypted data. Everything after that is fuzzy and hard to gain information from but I suspect the TA-88v3 pre-IPL does a check for ECDSA block and then the jump address.