PS3 SYSCON Firmware key is now public (release by zecoxao) - What does it mean?

Developer @zecoxao has recently released something that the dev has been working on obtaining for 10 years now and that obstacle that has now been cleared is the SYSCON Firmware Key and zecoxao has now released it to the public. First off we must erase some misconceptions as this is not going to directly lead us to a CFW on nonCFW PS3's anytime soon. As the dev stated on twitter "needless and pointless to say that the confusion being created around these keys that they will be useful for cfw on ps3 3k and superslim is a very farfetched idea. unless we have access to the TSOP 78K0R models, we will not be able to obtain anything else" and then when @kozarovv provided a follow-up question about 3k models here the developer responded with "don't expect miracles, is all i'm saying ". Now the question (which was asked by @DeViL303) "So what can we do with this as of now, what is possible with just this key alone and current knowledge? Then @zecoxao provides an explanation seen in this post (and also seen below). So this is a great feat that has been made, but its still being investigated and something that will need to be explored in the weeks to come to fully understand what we can be uncovered,. .

​

Release

• 
  
  i got the syscon firmware key, a dream i've been pursuing for the past 10 years. now that i have it i feel like i've acomplished my goal. the rest will follow naturally.
  - https://twitter.com/notzecoxao/status/1168954036541935616​
  
  What can developer's do with this key?
  

  So what can we do with this as of now, what is possible with just this key alone and current knowledge? Custom fan speed profiles? Multiple boot sequences depending on flags or something, or does everything need more work?

  
  via @zecoxao : With this key the following has happened:
  
  14 syscon firmwares for the BGA models (CXR) were decrypted.
  from them, keys for PATCHES and FULL FW signing and encryption, as well as decryption and validation were found. we can now sign our own patches and fws for the following models:
  
  
  • TMU-510
  • COK-001
  • COK-002
  • SEM-001
  • DIA-001
  • DIA-002 or DEB-001 (same soft id)
  
  Additionally we found the initialization key for eid1 as well as the process of initializing it from factory
  We also found 7 extra keys (we still don't know what they do)
  Finally, we found out there is a secret keyslot function that generates keys for
  
  • SNVS
  • AUTH1/AUTH2
  • Regions of EEPROM
  • PATCH keys xoring (to generate the final keys)
  • Relationship with the other 7 Keys
  
  What still has to be done:
  
  • Hack the 78K0R chips (the TSOP ones found in later models)
  • Dump the firmware of those chips
  • Get the DYN-001 patch keys
  • Find an exploit on arm firmware that works in 78k0r firmware
  
  Edit: and yes, you can do all that fun kinky shit of fan boosting at max speeds, led disco panic attack, and star wars theme ON A DECR-1000! THIS is a devkit, so THIS is the ONLY device that supports FULL FUCKING FIRMWARES! DO NOT CONFUSE IT with a DECR-1400, that is a HALF devkit!
  
  

Release Source: twitter.com/notzecoxao
Discussion: psx-place.com

Thanks to @NathanHale for the news alert ​

 

Command table is now properly wikified on ps3 wiki. you'll notice it has striking resemblance with the EMC command table on ps4 from fail0verflow blog posts

 

Hoping one day to rewrite fan tables in SYSCON to be more efficient than webman

 

More news:
AUTH1 and AUTH2 don't require any extra steps in comparisson with the old chips. however, there is a new command that requires to be used with these two called SETCMDLONG to make AUTH1 and AUTH2 work and we haven't figured out what it does

 

More news:
AUTH1 and AUTH2 don't require any extra steps in comparisson with the old chips. however, there is a new command that requires to be used with these two called SETCMDLONG to make AUTH1 and AUTH2 work and we haven't figured out what it does

Just thinking loud, but... it could be used to configure the lenght of the command packages ?
What i understand is every "stream" of data sent by UART started with 3 bytes, then it goes the command
https://www.psdevwiki.com/ps3/Syscon_Hardware#Syscon_UART_packets

If this theory is right, it means is an improvement that allows to send bigger packages... maybe the goal was to speed up the motherboard programming in the manufaturing plants
Or it could be related with some of the new commands, dunno, maye there is some new command that have to deal with big amounts of data... in that case the goal would be the same, to speed up the data transfer

 

Just thinking loud, but... it could be used to configure the lenght of the command packages ?
What i understand is every "stream" of data sent by UART started with 3 bytes, then it goes the command
https://www.psdevwiki.com/ps3/Syscon_Hardware#Syscon_UART_packets

If this theory is right, it means is an improvement that allows to send bigger packages... maybe the goal was to speed up the motherboard programming in the manufaturing plants
Or it could be related with some of the new commands, dunno, maye there is some new command that have to deal with big amounts of data... in that case the goal would be the same, to speed up the data transfer

No, the actual command format changed and they also merged the external and internal mode into one. They just use this command to overcome the weird UART buffering which happens on the 78K0R in hardware. Both the PS3 (CXR) and PS4 (C0L) models use a straightforward system, the 78K0R needs some more reversing. Like for the CXR, it will be released once it has been tested on different models and firmwares.

 

No, the actual command format changed and they also merged the external and internal mode into one

Hmmm, now i got why there is not a "diag mode" pin in the 3rd generation service connectors
I was getting worried about it, but it seems the reason why doesnt exists is because we dont need it, nice

They just use this command to overcome the weird UART buffering which happens on the 78K0R in hardware. Both the PS3 (CXR) and PS4 (C0L) models use a straightforward system

In my previous post i could not explain well what i had in mind, not that it matters much at this point, but it was related with the "short int" and "long int" data types that could depend of the processor architecture, and i dont know the lenght of each in the syscon, but i was thinking "short" could be 4 bytes, and "long" 8
The old UART syscon protocol used 3 bytes (header) + 1 byte (that indicates an stream).. total 4
And the new protocol could be using 7 bytes (header) + 1 byte (that indicates an stream)... total 8
Never minds, it was just a brainstorming that i thought could help, but doesnt looks like

the 78K0R needs some more reversing. Like for the CXR, it will be released once it has been tested on different models and firmwares.

Thanks, is great to read about your progress

 

more news. got all 3 dumps: AA, BB, CC (SW, SW2 and SW3)
AA snvs has an extra layer of crypto, while BB and CC do not
AA snvs is located at 0x70000 (nvs is located at 0x60000)
BB and CC snvs is located at 0xB0000 (nvs is located at 0xA0000)
BB and CC layers have the same format as CXR eeprom (size is 0x3000) but with one difference: AUTH1 session 1 to 6 keyseeds are missing. Session 0 and session 7 AUTH1 keyseeds do exist on the decrypted eid1 however.

I'll upload the dumped snvs's briefly.
Edit: done

 

more news:
the SherWood models have several regions where they keep the snvs data. they're displayed like this:


BB
0xB0000 <- uninitialized
0xB8000 <- initialized
0xBB000 <- initialized


CC
0xB0000 <- uninitialized
0xBB000 <- initialized
0xBE000 <- initialized

what i shared was the uninitialized snvs of all 3, it contains factory eid1, encrypted initialization status (01 for uninitialized) and never used snvs, as well as some configurations for clock correction, for instance.

 

Is SW dyn001 coded in Chinese? This is how I see it. Not same situation for SW2/3.

 

Is SW dyn001 coded in Chinese? This is how I see it. Not same situation for SW2/3.

what i shared was nvs and snvs, not the actual full rom, full rom has english strings

 

progress update: wildcard dumped the street psp syscon (E-1000), people are already in the process of reversing the code in order to bring back Pandora to PSP newer models. Wish us luck, everyone

 

progress update: here is the dump (it turns out it belonged to a psp 3000 syscon, not a E1000 like we originally thought)
Unfortunately, since everything that is important (including rom build id and date, as well as the necessary keys for interaction with the battery) is in the boot block (the very first 0x400 bytes), we need another TA-093 motherboard to get the final 0x400 bytes and thus the complete rom.
However, the good news is that, once we do, we can program any TA-093 motherboard syscon this way (we're setting up a public repo since the method is known for a while)

 

fun fact about keys being reused: sony was so lazy, but SO LAZY, that they reused ALL the ps3 CXR keys, EVEN the full firmware update keys. so if wildcard and @M4j0r and myself got this firmware BEFORE CXR, we'd have ALL of the keys either way. and the full update feature doesn't seem to even be used! talk about lazyness!

 

Is "on chip debugging - enable" on any of these ic? Will we be able to swap /remarry another cpu from same model of another motherboard. Have here few boards received from some services and they switched cpu without syscon/blu-ray ic, /nor . Looking inside nors dumps they are good. I have swapped 3 gpu, all working on another motherboard. Seen flux under cpu but didn't thought they swapped cpu like that. Jtp, jsd, kte boards.
Looking to to understand how flash is being used inside microcontroller we understand that P40 and P41 are for programming with FLMD0 and RESET. We are afraid glitch will corrupt data in flash so I may wait for release from your side.

 

Is "on chip debugging - enable" on any of these ic? Will we be able to swap /remarry another cpu from same model of another motherboard. Have here few boards received from some services and they switched cpu without syscon/blu-ray ic, /nor . Looking inside nors dumps they are good. I have swapped 3 gpu, all working on another motherboard. Seen flux under cpu but didn't thought they swapped cpu like that. Jtp, jsd, kte boards.
Looking to to understand how flash is being used inside microcontroller we understand that P40 and P41 are for programming with FLMD0 and RESET. We are afraid glitch will corrupt data in flash so I may wait for release from your side.

There won't be a release of the method, but there will be a release of the ROMs. we're however waiting for some ps3s to arrive in order to dump the boot block and get full rom.

 

so guys, i have a question, when the entire PSP syscon has been explored, does that mean we can create pandora batteries with batteries that were not compatible? or else what can we do differently?

 

so guys, i have a question, when the entire PSP syscon has been explored, does that mean we can create pandora batteries with batteries that were not compatible? or else what can we do differently?

You'll likely not even need a battery to estabilish the communication in order to trigger Service Mode. We're still missing the boot block from a TA-093 syscon chip and it's the christmas week, so only monday or tuesday we should get something for it.

 

Im going to hung a sock in here just incase it falls something inside it

 

You'll likely not even need a battery to estabilish the communication in order to trigger Service Mode. We're still missing the boot block from a TA-093 syscon chip and it's the christmas week, so only monday or tuesday we should get something for it.

Did you mean that only one USB cable connected to the PC will be enough to establish communication?

 

Did you mean that only one USB cable connected to the PC will be enough to establish communication?

could even be with the microphone serial port that was used in the old days