Heh, I finally figured out where the development discussions went (board was split into two...), but it seems that even here there has been to discussion about disecting the new EBOOT.PBP (with real firmware content this time) that is now available. (Or did I just miss it?)
Since we now have two PBPs, some comparative studying would be in order.
First of all, the PSF metadata of the new PBP has some keys we haven't seen before: UPDATER_VER and TITLE_n. The latter is just localized versions of the TITLE key (see http://mc.pp.se/psp/psf.xhtml for a list), but the former is a bit more interresting. After having actually installed the firmware upgrade, it is no longer possible to start the updater; a sign saying that there is no need to update appears instead. So it seems that the firmware will check this key against its own version before starting the binary. So in order to reinstall an older version of the firmware (becase a newer one has has plugged a useful security hole, say :), patching this key will probably be necessary.
Moving on to the "PSP" file, the first 40 bytes are identical to the old updater:
000000 7e 50 53 50 00 08 00 00 01 01 75 70 64 61 74 65
000010 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000020 00 00 00 00 00 00 01 02
After that, they differ. The old, phony update:
000028 a0 ae 33 00 f0 af 33 00 ac 1f 00 00 a8 16 0f 00
000038 74 5f 03 00
The new, real update:
000028 e0 07 39 00 30 09 39 00 d4 2f 00 00 88 41 0f 00
000038 b4 5f 03 00
The first two 32bit words have both increased by 350528, which as it happens is exactly the difference in size between the old and new PSP file.
The following 3 32bit words have increased by 4136, 10976 and 64, respectively. I'm guessing that these are sizes and/or offsets of subparts of the file, such as text and data section. Note that 4136+10976+64=15176 < 350528, so if they are sizes there must be some part not accounted here which has also grown. If they are offsets, the discrepancy could be caused simply by the majority of the new data being in the last part (the end of which is marked by the end of the file offset, already discovered above).
After this comes another identical part:
00003c 40 00 40 00 00 00 00 00 00 00 00 00
Then more differences. Fake update:
000048 40 16 10 00 00 00 00 00 00 00 00 00 10 16 10 00
000058 c0 ec 21 00
Real update:
000048 00 48 10 00 00 00 00 00 00 00 00 00 00 48 10 00
000058 d0 f5 26 00
If we again assume a series of 32bit integers, the differences are 12736, 0, 0, 12784, 330000. If we add these to what we have before, we get a total of 370696. However, this is larger than 350528, so all these numbers can not be sizes of non-overlapping sections of the file.
Following this, more identical data (mostly zeroes):
00005c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00006c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00007c 0c 00 00 00
Then comes a portion of diffing data which does not seem to be 32bit words. Fake update:
000080 2d 62 19 ff e7 13 a3 e3 27 eb 64 29 46 9a d1 c2
000090 71 f1 5b 00 a3 4c d4 cf 82 bd 60 df 87 5e cd a1
0000a0 a0 1d 0d f0 e5 7b e7 27 28 05 39 1e 35 0d 2d de
0000b0 a0 ae 33 00
Real update:
000080 37 bd 42 1e 46 76 12 e3 b6 51 a7 91 e1 84 a0 8f
000090 e4 81 22 d6 8c 0e 79 02 f5 bc 52 75 13 88 e8 11
0000a0 a9 46 c5 6e 69 cd e5 ca cc 8f ed a6 4a df 39 96
0000b0 e0 07 39 00
The four last bytes in each dump is the total size of the file minus 336 (0x150), but the rest of the data has no immediate interpretation. Maybe an encryption key (384 bits)?
Back to identical data:
0000b4 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000c4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0b
and after this I can't seem to spot any common data, so maybe this is where the actual compressed/encrypted part starts.
Fake update:
0000d4 48 11 5f c2 50 eb 84 63 a5 54 27 78 94 16 ee f1
0000e4 d2 07 13 23 07 aa 50 b4 d5 36 41 07 9e ca 4a 88
0000f4 b6 ba 92 5b 82 81 a5 a4 83 86 9e 57 ae 39 f2 14
[...]
Real update:
0000d4 01 01 39 43 4c d3 03 54 b1 41 12 02 76 7d 99 ab
0000e4 63 e7 72 33 ae 45 f9 2a 63 16 fb af 3a 30 fd ae
0000f4 3a fb 77 3d 9d 14 f7 66 72 52 13 4b 34 51 56 67
[...]
I guess I'll compare the PSAR files tomorrow, right now I think I need some sleep... :-)
Firmware 1.50 comparative study
Firmware 1.50 comparative study
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
That's reassuring. :-)
First glance at the PSAR files did not give very much. The first 16 bytes of the file from the phony update are:
000000 50 53 41 52 01 00 00 00 60 a4 aa 00 01 00 00 00
and for the real update:
000000 50 53 41 52 02 00 00 00 20 de 9a 00 01 00 00 00
After this the data is completely different and looks encrypted/whatever.
So what can be seen from this header is:
* Second 32bit word has changed from 1 to 2.
* Third 32bit word is total file size - 16 for the old file, and total file size - 32 for the new file
This is a bit interresting, since for the old file the 3rd word exactly matches the size of the encrypted data (clear header is 16 bytes, as shown above), but in the new file there are 16 bytes unaccounted for. The change of word 2 from 1 to 2 is probably significant here. Neither the 16 bytes following the header or the last 16 bytes stand out in any particular way, so exactly where these 16 bytes appear is anybodys guess...
First glance at the PSAR files did not give very much. The first 16 bytes of the file from the phony update are:
000000 50 53 41 52 01 00 00 00 60 a4 aa 00 01 00 00 00
and for the real update:
000000 50 53 41 52 02 00 00 00 20 de 9a 00 01 00 00 00
After this the data is completely different and looks encrypted/whatever.
So what can be seen from this header is:
* Second 32bit word has changed from 1 to 2.
* Third 32bit word is total file size - 16 for the old file, and total file size - 32 for the new file
This is a bit interresting, since for the old file the 3rd word exactly matches the size of the encrypted data (clear header is 16 bytes, as shown above), but in the new file there are 16 bytes unaccounted for. The change of word 2 from 1 to 2 is probably significant here. Neither the 16 bytes following the header or the last 16 bytes stand out in any particular way, so exactly where these 16 bytes appear is anybodys guess...
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
Re: Firmware 1.50 comparative study
Might be helpful... or maybe not:mc wrote:...
After that, they differ. The old, phony update:
000028 a0 ae 33 00 f0 af 33 00 ac 1f 00 00 a8 16 0f 00
000038 74 5f 03 00
The new, real update:
000028 e0 07 39 00 30 09 39 00 d4 2f 00 00 88 41 0f 00
000038 b4 5f 03 00
...
000028 a0 ae 33 00 f0 af 33 00 ac 1f 00 00 a8 16 0f 00
Is exactly the size of data.psp in the old, phony one: 3387376 bytes
000028 e0 07 39 00 30 09 39 00 d4 2f 00 00 88 41 0f 00
This is the size of data.psp in the recent, real update: 3737904 bytes
You can read about the 1.50 update in this thread:
http://forums.ps2dev.org/viewtopic.php?t=1201
Specifically, it points to this url for the file:
http://dj01.psp.update.playstation.org/ ... /EBOOT.PBP
http://forums.ps2dev.org/viewtopic.php?t=1201
Specifically, it points to this url for the file:
http://dj01.psp.update.playstation.org/ ... /EBOOT.PBP
Somehow these "offsets" are not getting out of my head....
new file:
000030 | D4 2F 00 00 88 41 0F 00 B4 5F 03 00 40 00 40 00
old phoney file
000030 | AC 1F 00 00 A8 16 0F 00 74 5F 03 00 40 00 40 00
just look at the similarities between the 2 lines.... they might be just coincidence, but somehow i doubt it...
Recently i begin to think, that what is persumed to be offsets right now are not really offsets...
Interpreted as 3 x int and 2 x short we would get:
New file:
12244, 999816, 221108, 64, 64
old file:
8108, 988840, 221044, 64, 64
In fact i would think real offsets to be numerically sorted... so 12244, 221108, 999816... so that i know that e.g. data1 is from offset 12244 up to offset 221107 , data2 from 221108 up to 999815, data3 from 999816 till eof....
But in this weird ordering i think offsets don't make sense....
Especially the 3rd "offset" being like 2/3 similar in old and new file.....
It's a little late here and i don't have a clue right now what these numbers are but i doubt them being offsets right now....
new file:
000030 | D4 2F 00 00 88 41 0F 00 B4 5F 03 00 40 00 40 00
old phoney file
000030 | AC 1F 00 00 A8 16 0F 00 74 5F 03 00 40 00 40 00
just look at the similarities between the 2 lines.... they might be just coincidence, but somehow i doubt it...
Recently i begin to think, that what is persumed to be offsets right now are not really offsets...
Interpreted as 3 x int and 2 x short we would get:
New file:
12244, 999816, 221108, 64, 64
old file:
8108, 988840, 221044, 64, 64
In fact i would think real offsets to be numerically sorted... so 12244, 221108, 999816... so that i know that e.g. data1 is from offset 12244 up to offset 221107 , data2 from 221108 up to 999815, data3 from 999816 till eof....
But in this weird ordering i think offsets don't make sense....
Especially the 3rd "offset" being like 2/3 similar in old and new file.....
It's a little late here and i don't have a clue right now what these numbers are but i doubt them being offsets right now....
There's nothing to say that the numbers in this particular sequence are necessarily of the same "kind", we could very well have one offset, one length, one load address, or whatever. It doesn't look like all can be sizes though. And they don't look like checksums.
Speaking of checksums, I had an idea regarding the "random" data at 0x80-0xaf. This is 3*128 bits. An AES key is 128 bits. But so is an MD5. We assume that the binary is cryptographically signed somehow, and a pretty good scheme to do that would be the following (do not get confused by my use of words like "is"; this is purely speculative):
The block 0x80-0xaf is RSA encrypted with Sony's private key, the public part of which is embedded in the PSP. This means that a tamperer will not be able to put arbitrary data here, without access to the secret key. However, he would be able to inspect the actual data (if he extracts the public key) and adapt the rest of the binary to fit it (i.e. use the same AES key). Therefore, the signed data must contain more than the AES key; it must also contain an hash of the data, so that it can't be simply replaced by someone who happens to know the AES key.
Therefore we have three parts of 128 bits each: The AES key of course (128 bits), an MD5 of the encrypted data (128 bits), and an MD5 of the decrypted data (128 bits). After RSA-decrypting, the PSP can check the decrypted first MD5 against the actual MD5 of the file, and if they don't match it doesn't even have to try AES decrypting the data, because someone is obviously trying something funny. If it does match, it can use the obtained AES key to decrypt the data, and then MD5 it again. If this matches the second MD5 in the signature portion, then everything is hunky-dory.
A scheme like this would be very difficult to trick, and matches the observed amount of seemingly-random data in the header, but again it's really just speculating wildly...
Speaking of checksums, I had an idea regarding the "random" data at 0x80-0xaf. This is 3*128 bits. An AES key is 128 bits. But so is an MD5. We assume that the binary is cryptographically signed somehow, and a pretty good scheme to do that would be the following (do not get confused by my use of words like "is"; this is purely speculative):
The block 0x80-0xaf is RSA encrypted with Sony's private key, the public part of which is embedded in the PSP. This means that a tamperer will not be able to put arbitrary data here, without access to the secret key. However, he would be able to inspect the actual data (if he extracts the public key) and adapt the rest of the binary to fit it (i.e. use the same AES key). Therefore, the signed data must contain more than the AES key; it must also contain an hash of the data, so that it can't be simply replaced by someone who happens to know the AES key.
Therefore we have three parts of 128 bits each: The AES key of course (128 bits), an MD5 of the encrypted data (128 bits), and an MD5 of the decrypted data (128 bits). After RSA-decrypting, the PSP can check the decrypted first MD5 against the actual MD5 of the file, and if they don't match it doesn't even have to try AES decrypting the data, because someone is obviously trying something funny. If it does match, it can use the obtained AES key to decrypt the data, and then MD5 it again. If this matches the second MD5 in the signature portion, then everything is hunky-dory.
A scheme like this would be very difficult to trick, and matches the observed amount of seemingly-random data in the header, but again it's really just speculating wildly...
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
Having the courage
Getting over crisis
I rescue the people
Hi,
I Up this subject as we are searching about a MD5 in the 1.50 firmware.
I explain, someone notice that the 1.50 Upgrader from a UMD was missing the last 128 Bits in comparaison to a downloaded upgrader 1.50 and we made the assumption that it could be a MD5 Checksum.
As anybody got information on that?
The purpose would be to find out wich data is related to the MD5 and modified this upgrade into a downgrade by modifying the version and calculate the correct MD5.
Thanks
ChrisCC
I Up this subject as we are searching about a MD5 in the 1.50 firmware.
I explain, someone notice that the 1.50 Upgrader from a UMD was missing the last 128 Bits in comparaison to a downloaded upgrader 1.50 and we made the assumption that it could be a MD5 Checksum.
As anybody got information on that?
The purpose would be to find out wich data is related to the MD5 and modified this upgrade into a downgrade by modifying the version and calculate the correct MD5.
Thanks
ChrisCC