I managed to bypass the md5 check within the update and modify the update's param.sfo , I changed the "UPDATE_VER" string from 2.00 (I used a 2.00 update) to 9.99
I thought that the updater checked the param.sfo file to get the version information and compare it to the flash0's index.dat but I was wrong
The version information is located within the data.psar file ! (probably in the data0.bin) so calculating the MD5 alone would be useless ! You would still need to create your own psar ! (and the psar is encrypted :/)
Sony did the hell of a job with their updater's securities :/
Here I'll sum up what I know about it:
-The vsh will only run an update if: - the data.psp is encrypted
- the param.sfo matches a higher version
-The updater will run and check: - If the eboot md5 matches the one in the end of the eboot (the last 16 bytes) (it will calculate the md5 from the eboot and then compare it with the md5 in the end of the update)
- If the data.psar file matches the data.psp (I don't know how it perfroms that check but if you try to swap a data.psar form another update it will tell you that the update is corrupted EVEN if you manage to bypass the md5 check)
- If the AC is plugged in
- If the Battery is at least 54% charged
- If the param.sfo file is valid (I don't know why it does that check as it performs a md5 check before)
- If the version in the data.psar file is higher than the one in index.dat
- If the version in the param.sfo is higher then in the index.dat (from flash0)
By the way in case you don't know there is an overflow in the 1.52 data.psp allowing to run another update (the md5 has to be a correct value) by swapping the MS right after the white "PSP" screen but if the index.dat in your psp isn't lower then the targeted updater it wont let you update. (This was found by Yoshihiro)
PSP updater's protections
PSP updater's protections
Last edited by Mathieulh on Thu Apr 06, 2006 7:50 pm, edited 1 time in total.
16 last bytes
Ill tried that on the 2.00 US upadter and 2.00 JAP updater but the md5 of the hole eboot.pbp din not match any of the last bytes of the eboot file. I unpacked both EBOOT files with pbp unpacker and found that the 16 last bytes of data.psar was diffrent from the us and jap update. They did not match any md5 check on any of the files or eboot.pbp. I was wondering is the md5 you found encrypted in the end of the file ??-The updater will run and check: - If the eboot md5 matches the one in the end of the eboot (the last 16 bytes) (it will calculate the md5 from the eboot and then compare it with the md5 in the end of the update)
unlike what I thought the md5 is NOT a protection but really just a way to ensure that the eboot you downloaded isn't corrupted, that's why the MD5 check isn't peformed while running the update from an UMD
The real protection lies in the psar, it cannot be tempered to another, you cannot create your own psar cause it's encrypted using sony's key, and finally the version information is located within the psar So sony think their psar format is safe. It was done especially as Sony probably plans to open their UMD format to the public (by selling UMD writters) and then as you can't even modify the psar you can't create a downgrader from an UMD
About the md5 it's not really a md5 but a special sony checksum algorithm, the psp calculates the eboots md5 each time an update is run and compares it to the md5 located in the 16 last bytes of the eboot.
Thus you can know how the psp performs the md5 calculation by logging an update. (you don't need to perform the update, just to run it up to the "start" screen)
The problem is that it wont enable anything as modifying the param.sfo wont let the updater do its job :/
We'd need to find a way to create your own psar and then we are screwed :/
The MD5 isn't encrypted or isn't based on any key, we call it md5 because we have no other name for it, it's just a propertary checksum algorithm from Sony however the psp is capable of calculating it.
The real protection lies in the psar, it cannot be tempered to another, you cannot create your own psar cause it's encrypted using sony's key, and finally the version information is located within the psar So sony think their psar format is safe. It was done especially as Sony probably plans to open their UMD format to the public (by selling UMD writters) and then as you can't even modify the psar you can't create a downgrader from an UMD
About the md5 it's not really a md5 but a special sony checksum algorithm, the psp calculates the eboots md5 each time an update is run and compares it to the md5 located in the 16 last bytes of the eboot.
Thus you can know how the psp performs the md5 calculation by logging an update. (you don't need to perform the update, just to run it up to the "start" screen)
The problem is that it wont enable anything as modifying the param.sfo wont let the updater do its job :/
We'd need to find a way to create your own psar and then we are screwed :/
The MD5 isn't encrypted or isn't based on any key, we call it md5 because we have no other name for it, it's just a propertary checksum algorithm from Sony however the psp is capable of calculating it.
the updater is, however the Md5 used to state the eboot as valid (not corrupted) is not based on any key, it's just a special algo from Sony
What's encrypted are the updater's data.psp (elf) and the updater's data.psar
beside I don't see how the public keys stored in flash0:/data/cert can indicate how the updater is encrypted in any way especially as those keys are not used in the psp elf decryption process (the keys used are stored in the iplplayload (located in the IPL) and in the mesg_led.prx file)
Beside to know wether an elf is encrypted or not just use an hex editor, if the header is ~PSP then it's an encrypted ELF, otherwise if the header is ELF then the elf is decrypted. (I suspect that you know about that, but some newcomers might be browsering those pages and find this intel interesting....)
Finally all the psar are encrypted and using the header PSAR (at least the retail ones)
The rest of the eboot is not encrypted (the png, and the param.sfo) and thus can be modified easely but you will still need to calculate the MD5 in order to the updater to recognise your eboot as valid (the checking process is embebed within the updater's elf.)
Beside even if you know that the encryption cypher is based on AES, and that the encryption is symetric, don't forget that the elf/prx encryption follow a pattern we don't know anything about.
Otherwise we could simply decrypt the prx and any other psp files using a computer and the requiered keys instead of using a psp.
Cheers ;)
What's encrypted are the updater's data.psp (elf) and the updater's data.psar
beside I don't see how the public keys stored in flash0:/data/cert can indicate how the updater is encrypted in any way especially as those keys are not used in the psp elf decryption process (the keys used are stored in the iplplayload (located in the IPL) and in the mesg_led.prx file)
Beside to know wether an elf is encrypted or not just use an hex editor, if the header is ~PSP then it's an encrypted ELF, otherwise if the header is ELF then the elf is decrypted. (I suspect that you know about that, but some newcomers might be browsering those pages and find this intel interesting....)
Finally all the psar are encrypted and using the header PSAR (at least the retail ones)
The rest of the eboot is not encrypted (the png, and the param.sfo) and thus can be modified easely but you will still need to calculate the MD5 in order to the updater to recognise your eboot as valid (the checking process is embebed within the updater's elf.)
Beside even if you know that the encryption cypher is based on AES, and that the encryption is symetric, don't forget that the elf/prx encryption follow a pattern we don't know anything about.
Otherwise we could simply decrypt the prx and any other psp files using a computer and the requiered keys instead of using a psp.
Cheers ;)
Oh, really? I had no idea. That does complicate things a bit. Of course, knowing Sony, they probably did something ridiculous like use a 37-bit key composed entirely of 0xA-0xF. Never before have I seen a company with such insane file formats.Mathieulh wrote:the updater is, however the Md5 used to state the eboot as valid (not corrupted) is not based on any key, it's just a special algo from Sony...(the keys used are stored in the iplplayload (located in the IPL) and in the mesg_led.prx file)
Neither did I xDFreePlay wrote:Never before have I seen a company with such insane file formats.
I suspect sony to use AES128+RSA(1024?/2048?) (AES is symetric and only using AES would be a major security flaw, however RSA decryption process is slow (unlike AES) so they would just encrypt the AES key using RSA (that is asymetric) and then use the hardware embebed AES decryption feature to decrypt the rest.
anyway that's just a suspision I don't know much in the encryption cypher matters, we would need some advices from people that know more in that matter.
pls make sure you understand what is AES encryption before you "SURE" anything.
AES is not a public/private key encryption , only one key is used for encrypt/decrypt.
If you want to learn more about it , pls click the link below.
http://en.wikipedia.org/wiki/Advanced_E ... n_Standard
AES is not a public/private key encryption , only one key is used for encrypt/decrypt.
If you want to learn more about it , pls click the link below.
http://en.wikipedia.org/wiki/Advanced_E ... n_Standard
FreePlay wrote:I'm pretty sure that the updates are encrypted using the AES Rijndael standard. There are public keys stored in flash0:/data/cert that may indicate this.