Recently a tool has been released to decrypt and encrypt CP updates. I don't know if its allowed to discuss these kind of things here, so i won't provide a link yet. I'm pretty sure though that it might be interesting for the resident reftool owners to have a look or modify their CP binaries, perl-scripts, config files, etc. please let me know if its ok to post a link.
Not OK to post a link, it's against the rules. Have people PM you for a private link to where-ever you've uploaded the files. Which I will do.
You don't need a tool to do this, I have posted a couple of months ago the whole algo + keys on the wiki (I was the one who actually exploited the Communication Processor in the first place) here : http://www.ps3devwiki.com/wiki/Communication_Processor As you can see you just need to use openssl and common sense. Here is the actual syntax to decrypt binaries: I've been messing with the CP updates and the Tool's syscon for a while now, feel free to ask any questions.
ah, interesting. i wasn't aware of this. but getting a properly decrypted file and encrypting takes a little bit more then just openssl aes-256-cbc...
How so ? The CP updates are just gzipped tarballs encrypted with AES256CBC with the hash and iv added before the encrypted data. Once you know about this and have the key, it's hardly rocket science to get it done. Just make sure to use linux/unix/bsd while you modify the tarball so you can keep the sym links intacts. (Windows doesn't like these too much.) I have modified a CP update this way and it ran just fine on my unit. (although I like to keep it untouched and use the exploit to enable telnet in inetd.conf instead, since it runs from a ram drive, restoring it to default so long as you do not overwrite the nand with an update or nandsync is a simple matter of using the power switch.) On a side note, the PSP Development Tool Communication Processor is the same as the one on the Playstation 3 but it's directly implemented in the Tool's main board, it also features a lot less physical memory because unlike the playstation 3 CP, the operating system runs from the NAND drive rather than the RAM drive (on the ps3 Reference Tool the NAND content is copied to ram at boot and started from there, only some files such as /etc/passwd are directly linked to the nand and changed physically) The CP's Bootloader (which is a little harder to dump software wise) is also different on the PSP Tool compared to the ps3 one (the PS3 Reftool version is newer and has specific hidden commands). The main interest of messing with the CP firmware is mostly to "talk" to syscon, what's interesting is you can "talk" to it even while the unit is off or powering up and no matter what command/packet is issued, syscon requires no auth (although it does know and answers to auth commands, those are optional), this is possible because on the Reference Tool, the CP acts as a proxy between the System Controller and the main Tool (PS3) board, this means it can act as the ps3 and talk to syscon at every step of the boot process. Other than that, the CP seems pretty boring. Although in theory it could also talk to the southbridge, none of the CP firmware binaries do so, which means that figuring out how it's done is the same as looking for a needle in a haystack.
well, if you just decrypt and re-encrypt the update using openssl without any modifications it may work. your method is missing something important. the size of cp updates is always a multiple of 0x10 while tarballs don't care about that no offense, but someone that has had a deeper look into the toolupdatedec binary could have noticed that there is one specific byte he has to worry about other then encrypting + md5sum.
None taken (about the offence). Keep in mind that while I posted the algo/keys about 2 months ago, I had this done for over a year, since then I've always used to exploit (I am not sure if you've found it yet, it's an easy one but I rather not hint to it at this point, just in case yet another update shows up) at runtime to get things done, this is mostly why I totally forgot about the 0x10 part, I have only modified the actual update package once or twice around the time I finished reversing the toolupdatedec binary, while I did so, every modification was done by hand, I haven't written a single tool to make my life easier since I didn't have much to modify in the first place. (I just wanted to enable telnet + ftp on a more permanant basis without risking using nandsync) Even though I am not too focussed at the ps3 anymore, I am glad that someone else has taken an interest into the Communication Processor. If you figure out how to talk to the southbridge (hardware addresses or the such) I would be interested to take a look, otherwise, to be honest, not so much. If you have enough time on your hands, syscon can be overflowed with a packet (the Tool version is exploitable early enough in the boot chain and runs ARM instructions, due to the nature of the exploit however, it cannot be reproduced on consumer units or in fact any other units than DECR-1000/DECR-1000A. There maybe another/few other exploits that I don't know about though.) Cheers
about the southbridge: i don't have a decr to play around with so there is no interest to look into the pif5/gpio drivers from my side.
Likewise, sadly I don't have a firmware/PUP for those units. I have the Tekken 6 HDD but the game doesn't contain an update. Some later games have system update that install as you first try to run those the first time. I suspect the update is either in the HDD or the dongle. Considering the HDD key for Arcade is static (if the target is 0xA0 lv1ldr calculates a static key for ATA) it can be decrypted without actually using the system. I suspect the dongle crypto is in /dev_flash or the game itself (which means that the security must not be too high as user processes cannot access/issue usb raw commands thus it is likely to assume that a dongle can be "cloned" simply by copying over the content of the FAT partition, of course I can't actually verify this since I don't own an Arcade unit. For all we know, a syscall may have been added in lv2 for that purpose) Did you happen to stumble upon any System 357/369 Updater ? (I don't think sys369 ones exist since only a very few games have been released but the systems must be similar anyway) The nice thing about system 357 is that all the updaters released should be exploitable (as it's been a very long while since the last game/update for it has been built)
if the System 357 come with Tekken 6 , that mean it a early Firmware , because once 357 send out service support update it to support other game, Tekken 6 is can not play any more.
