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 ​

 

The new structure im suggesting to use should be like this (all them are located in the "special_section" area)
https://pastebin.com/aYAERwug

Let me explain this a bit better because my comments in the struct could be confusing (there is not much room for them anyway), in the examples im going to show in this post should be the result when using the new struct with my changes

Spoiler

But before looking at the examples im going to post... rewind back to this other post written by @M4j0r
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-12#post-227226

Active
0: Remove
FF: Use (default)

So... 0xFF is enabled... and 0x00 is disabled (think in it as 0 = nothing)

In COK-001 and COK-002 motherboards we have:

fan_table_old.0.active = FF <--- used by CELL
fan_table_old.1.active = FF <--- used by RSX
fan_table_old.2.active = 00
fan_table_old.3.active = FF <--- used by BEVR
fan_table_old.4.active = 00
fan_table_old.5.active = FF <--- this is a mistake, because the values for "tempD", "tempU", and "duty" are invalid

special_section.unk_cell_activity_1 = FF
special_section.unk_rsx_activity_1 = FF
special_section.unk_zone2_activity_1 = 00
special_section.unk_bevr_activity_1 = FF
special_section.unk_zone4_activity_1 = 00

special_section.unk_cell_activity_2 = FF
special_section.unk_rsx_activity_2 = FF
special_section.unk_zone2_activity_2 = FF
special_section.unk_bevr_activity_2 = FF
special_section.unk_zone4_activity_2 = FF

In SEM-001 motherboard we have:

fan_table_new.0.active = FF <--- used by CELL
fan_table_new.1.active = FF <--- used by RSX
fan_table_new.2.active = FF <--- used by BEVR

special_section.unk_cell_activity_1 = FF
special_section.unk_rsx_activity_1 = FF
special_section.unk_zone2_activity_1 = 00
special_section.unk_bevr_activity_1 = FF
special_section.unk_zone4_activity_1 = 00

special_section.unk_cell_activity_2 = FF
special_section.unk_rsx_activity_2 = FF
special_section.unk_zone2_activity_2 = FF
special_section.unk_bevr_activity_2 = FF
special_section.unk_zone4_activity_2 = FF

As you can see the values i named with the suffix "activity_1" are identical to the other "active" values that are located inside each "fan_table_old" (or "fan_table_new"), in some way it looks like has been copyed... but they also can be used to deduce the state and/or presence (and the order) of the "fan_table_old" (or "fan_table_new") areas

In few words, for SEM-001 we have 2 values with the suffix "activity_1" = 0x00 (disabled for zone2, and zone4) because the fantbl for them doesnt exists
SEM-001 only allows to store 3 fantbl's, and are used by cell, rsx, bevr (in that order)

 

In DIA-001 motherboard we have:

fan_table_new.0.active = FF <--- used by CELL
fan_table_new.1.active = FF <--- used by RSX
fan_table_new.2.active = 00

special_section.unk_cell_activity_1 = 81
special_section.unk_rsx_activity_1 = FF
special_section.unk_zone2_activity_1 = 00
special_section.unk_bevr_activity_1 = 00
special_section.unk_zone4_activity_1 = 00

special_section.unk_cell_activity_2 = 81
special_section.unk_rsx_activity_2 = FF
special_section.unk_zone2_activity_2 = FF
special_section.unk_bevr_activity_2 = FF
special_section.unk_zone4_activity_2 = FF

Here can be seen how the BEVR thermal control has been disabled in 2 different places
fan_table_new.2.active = 00 <--- this is located inside the table itself
special_section.unk_bevr_activity_1 = 00 <--- and this is located in a common area

So again... it seems the value has been copyed from one to the other (probably not copyed directly, but is obvious there is a direct or indirect relationship in between them)

Anyway... the point is DIA-001 motherboards only allows to store 3 fantables, and one of them (for bevr) is disabled

Spoiler

But in the way how is stored the all this config data it looks like is posible to re-enable BEVR... and probably is the same for all other newest PS3 models

The value 0x81 i named "special_section.unk_cell_activity_1" is identical to "special_section.unk_cell_activity_2"
I cant imagine what it does but there seems to be a relationship in between the 5 values i named "activity_1" and the other 5 for "activity_2"

Im wondering if this motherboard was refurbished or was used for previous experiments... whatever that 0x81 means seems to be related with a "rarity" of CELL

Edit:
The syscon dump of the DEB-001 motherboard (from a DECR-1400 PS3 model) is also using value 0x81 in "special_section.unk_cell_activity_1" and "special_section.unk_cell_activity_2"

 

And this is probably the most interesting dump uploaded by @M4j0r
Is a COK motherboard, but the fantable was updated to the new format (originally it had 6 fantables, but after the refurbishement there are only 3... like in the new PS3 models)

In COK-001 REFURBISHED

fan_table_new.0.active = FF <--- used by CELL
fan_table_new.1.active = FF <--- used by RSX
fan_table_new.2.active = FF <--- used by BEVR

special_section.unk_cell_activity_1 = FF
special_section.unk_rsx_activity_1 = 8B
special_section.unk_zone2_activity_1 = 00
special_section.unk_bevr_activity_1 = FF
special_section.unk_zone4_activity_1 = 00

special_section.unk_cell_activity_2 = FF
special_section.unk_rsx_activity_2 = 8B
special_section.unk_zone2_activity_2 = FF
special_section.unk_bevr_activity_2 = FF
special_section.unk_zone4_activity_2 = FF

See where is located the value 0x8B ?, im wondering if this motherboard had a RSX replacement when it was refurbished

In the previous example of a DIA-001 we had "special_section.unk_cell_activity_1" = "special_section.unk_cell_activity_2" = 0x081
And in this COK-001 refurbished we have "special_section.unk_rsx_activity_1" = "special_section.unk_rsx_activity_2" = 0x08B

Spoiler

There is a difference of 0xA (10 units in decimal) in between 0x81 and 0x8B btw, perhaps this could make someone ring some bells, it could be a hint
I cant imagine what this values means though

Anyway... this is the final proof of the relationship in between all this values im talking about, previously was labeled as "unknowns" in the code struct
I cant give them a better name because im not able to identify them completly... but well... i think is better to add them in the code struct, just as an initial aproach to try to understand how they works

 

I just had an idea of how could work the values i named "activity_1", is a feature that could be handy for the engineers when they was doing experiments with PS3 prototypes

The idea is... the "activity_1" values could be used as some kind of "sensitivity" adjustment that modifyes all the values of "TempD" and "TempU" (and maybe also the "duty") of a specific fantable. And they works this way:

0xFF = load the raw values from the fantable
0x80 = apply a 100% scale factor to the values of the fantable (so the result is the same than 0xFF)
0x81 (or bigger) = apply a 102% scale factor (or bigger) to the values of the fantable
0x7F (or smaller) = apply a 98% scale factor (or smaller) to the values of the fantable
0x00 = dont load the values from the fantable

-----------------
This allows to modify "on the fly" all the values for "TempD", "TempU" (and maybe also "duty") of a specific fantable just by modifying a single byte
You know... is like having a single slider and when you move it you are modifying tenths of settings

The retail motherboards should not use it, is just they kept it for some of them

-----------------
I guess is going to be tricky to get any proof to see if this theory is right (or either debunk it incase is not correct), but if this is true then it means:

The DIA-001 using the value 0x081 for CELL is an increment (a bit over 0x80), Maybe there was an engineer that thought "im going to increase this a bit"... and only increased it in 1 unit

And for the refurbished COK using 0x8B for RSX it could happen the same, but it had 2 increments 1 unit + 10 units in decimal (0x80 + 0x01 + 0x0A = 0x8B)

 

Fan control
So I reversed how the fan table and the other temperature control stuff works (on retail units).
The fan table and other information are stored in a special region of the syscon EEPROM: https://pbs.twimg.com/media/ENs1zGGXUAIwnZl.png:large .
I documented the area in the tmp_ctrl struct: https://pastebin.com/Wtc7NcJ4

After the "special_section.unknown1" appears several values in groups of 3, are like the "def con one" shutdown settings, seems to be "component" specific (in other words, are temperature sensors specific from every component), in this order:
cell <--- exists in all retail PS3 models
rsx <--- exists in all retail PS3 models
zone2
bevr <--- dafuq is this ?... Cell BE voltage regulators ?
zone4

Yes, the cell voltage regulator section.

The full list list temp sections is:

1st BE Primary
RSX Primary
XDR Primary
BE VR
RSX VR
GDDR3 VR
XDR VR
AC/DC
BD Primary
BD Secondary
Air Intake
inside chasis
XIO trace
IOIF0 trace
IOIF1 trace
GbE
USB
misc
1st HDD
2nd HDD
SB
EE+GS

Look at this "concidence". It seems the last digit of the "thermal error" codes matches with the component ID

It looks like ID 4 (a.k.a. zone4) is SB, and at some point there was a ID 5 (a.k.a. zone5) for EE+GS
And the "struct special_section {};" you made doesnt have room for "ini_trp_zone5", "shutdown_temp_zone5" and "ini_hyst_zone5" (because this data doesnt exists in the retail syscons)

Is just the thermal config for PS3 retail models doesnt contains valid data in the fantables located at positions: third, fifth, and sixth
Maybe what is happenning is the fourth table, and his associated settings (actually labeled as BEVR) belongs to SB (in other words, the thermal config for ID 2 doesnt exists in retail PS3 models)
This would result in the first 5 fantables used this way:
First = BE <---------used in retail
Second = RSX <---------used in retail
Third = BEVR <---------not used in retail
Fourth = SB <---------used in retail (COK motherboards only)
Fifth = EE+GS <---------not used in retail

Spoiler

And the sixth fantable is not really a fantable, is padding completly filled with 0xFF's

Im wondering about this because this graphs i made
https://www.psx-place.com/threads/syscon-fan-settings-coordinate-graphs.31188/

In the hexeditor view shown in this image it can be seen there is room for 6 fantables, following your code im labeling the fourth one (using green colors) as BEVR, but im wondering if is SouthBridge

 

In few words, i think this structs:

I documented the area in the tmp_ctrl struct: https://pastebin.com/Wtc7NcJ4

Could be updated this way ---> https://pastebin.com/x49KmpAv
I dont have any solid argument or proof why im saying this, but it looks a bit like that... im just throwing the idea incase it helps some of you working with this
If someone finds a way to verify this theory (or debunk it), i will be glad to read about it

 

@M4jor @zecoxao,

Can the "Hidden' Leds be activated? i mean the one in the left corner of the power board.

 

Progress update: we got all the keys from ps3 syscon, including sherwood ones (now on ps3 wiki). Missing a keyset from psvita syscon and a couple from psp syscon. PS4 EMC (Southbridge) 0x20 key was obtained on 30th September 2020. Can use it to decrypt indexes 0x20 (and also the body of 0x2A) southbridge IPLs. fuse key partially obtained. missing constants.
@LuanTeles no idea. the answer can only be obtained when you reverse engineer the firmware

 

Guys ... so what is all that useful for after all?
Only for fan and led control?
Any hope for CFW on Super Slims at least?

Gesendet von meinem Mi MIX 2S mit Tapatalk

 

@M4jor @zecoxao,

Can the "Hidden' Leds be activated? i mean the one in the left corner of the power board.

Nice question
Im pretty sure syscon can do it because phisically there are connections in between that leds and syscon... is just the syscon doesnt send the signal at any time (in any operation mode, any special boot modes, and neither in non-retail PS3 models)

But we dont even know how the syscon (software) uses that leds, incase there is some "flag" somewhere to switch it ON/OFF eventually some of the peolple reverse engineering syscon firmware could find it

A different matter is if we could "repurpose" that leds for other stuff... you know, if the syscon firmware only enables the leds under very rare circunstances (a rare boot mode or other weird things) enabling it is going to be pointless because we are not going to boot in that special mode ever

The nice thing would be to repurpose it for other stuff (something related with temperature or fan speeds would be an awesome way to repurpose it)

Progress update: we got all the keys from ps3 syscon, including sherwood ones (now on ps3 wiki)

Awesome, now we can steal all robin hood SCEcrets
If at some point some of you dump the "thermal config" area from some slim or superslim motherboards please share them and i will make some graphs

Guys ... so what is all that useful for after all?
Only for fan and led control?
Any hope for CFW on Super Slims at least?

Gesendet von meinem Mi MIX 2S mit Tapatalk

There are a few things in the PS3 that never was hacked before:
-syscon software
-bootldr (inside flash chip, encrypted with a unique key located inside CELL procesor)
-metldr (inside flash chip, encrypted with a unique key located inside CELL procesor)

The CFW's doesnt modify any of that, is 100% official data in all the PS3 that exists
Now with syscon security defeated there are some research paths that worths to be explored... maybe this will lead to something bigger but by now is hard to tell because there is a lot of unknown data inside syscon, we dont know how many things can be made with it but is promising

 

As not much documents are about 78kor (sw-301) found some documents for some models *dataflash_read_asm* on renesas and maybe someone can find any pinout.

 

As not much documents are about 78kor (sw-301) found some documents for some models *dataflash_read_asm* on renesas and maybe someone can find any pinout.

SW-301 is just a 78K0R-KH3 with 128 pin rectangle layout

Edit:
Uploaded some manuals

 

Thank you for dircttion. Though I can use Tnm5000 programmer to read it. This is not on my list of ic supported. Any documentation is really appreciated.
I will check with motherboard in few days, now just reading not in workshop.
Is this pdf right for pinout? View attachment 29143
Ok thank you. I will try to compare datasheet attached from you also I will attach my programmer pdf to check if see any match. http://cloud.tapatalk.com/s/5fd411b9859e8/TNM-CAR (2).pdf

 

Thank you for dircttion. Though I can use Tnm5000 programmer to read it. This is not on my list of ic supported. Any documentation is really appreciated.

You can't read it, since it has no read function (security feature). You need to glitch it to get access to the content and no, it's not possible yet.

 

Thank you for advice @M4j0r.
Update :
Today got the final results on my research and I will stop for a while. May be a bit more complicated than I thought.

 

Thank you for advice @M4j0r.
Update :
Today got the final results on my research and I will stop for a while. May be a bit more complicated than I thought.

As @M4j0r said you need to glitch it to read it. there are several attacks published on IACR for this.
I'll upload them.
https://github.com/janvdherrewegen/bootl-attacks (works on 78K0 but can also work on 78K0R)

 

small progress update (@sandungas will like this one):
obtained almost full ROM of a BB and CC chip (aka SW2 and SW3 chips), dumps will be shared once the full ROM is obtained. my friend wild is planning on obtaining AA tomorrow, but we'll see. for now, i'll just fill the wiki with commandlist (this was planned but was enjoying late night watching a movie next to fireplace and with family)

 

small progress update (@sandungas will like this one):
obtained almost full ROM of a BB and CC chip (aka SW2 and SW3 chips), dumps will be shared once the full ROM is obtained. my friend wild is planning on obtaining AA tomorrow, but we'll see. for now, i'll just fill the wiki with commandlist (this was planned but was enjoying late night watching a movie next to fireplace and with family)

Nice, i want to take a look at his fantables
Btw, im taking a look at the sw2 internal commands you posted in wiki today and it looks like sw2 allows to use some new commands that was not availables in previous syscon models, as example:

buzzduty
Based in his name... this seems to be used to configure the volume of the buzzer, right ?
Im guessing there is going to be lot of people interested in reducing it

 

I may ask the way is done? I'm interested in this because I want to know how sistem works on ps3 in order to understand and fix ps4 as well. I see many dead APU and really don't understand how they sell from China without rest of ic and people saying that they work. Didn't buy for testing but I will this week. Probably after 3 months I will have spear part.
Is this glitch similar?

 

I may ask the way is done? I'm interested in this because I want to know how sistem works on ps3 in order to understand and fix ps4 as well. I see many dead APU and really don't understand how they sell from China without rest of ic and people saying that they work. Didn't buy for testing but I will this week. Probably after 3 months I will have spear part.
Is this glitch similar?

The setup is similar. The glitch part isnt