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 ​

 

Can we write a different Firmware version to the syscon now? I have a syscon bricked 3K console. Syscon and NOR firmware are different. I need to change the syscon firmware equal to NOR firmware.

On later syscons (used on CECHL/VER-001) you can always write a different firmware if you have one, but you're probably not talking about the firmware but the data section. Currently not possible, as stated multiple times in this thread.

thanks!
I can't start the console (SEM-001) in "internal" mode. error:

[SSM] cannot clear fatal error state because of unrecoverable error.

can help
>trace print
.........
SSM 02 4000 0000
SSM 00
SSM 02 4000 0000
SSM 00
SSM 02 1100 0000

"external" mode works well.
What should I do?

Is the eeprom checksum at 0x39FE correct? Can be checked by eepcsum.

 

Hope someone will be interrested in it =)

at least to restore the Original Clock of it, since the RSX is underclocked

Will it not cause over heat?

 

Will it not cause over heat?

since we have fan control..... no

 

Is the eeprom checksum at 0x39FE correct? Can be checked by eepcsum.

Ok, THANKS!
I want to test RSX VRAM. (Does not display image).

> rrsxc 00 01
+0 +4 +8 +C
-----------------------------------
[SSM] RSX Interrupt : Detected !
RSX SY_IES register (0x0008) = 0x2
[SSM] state: 0400 -> 0700
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] Shutdown mode : syspm_stat=00000000/00000000
00000000
[mullion]$ [ERROR]: 0xa0801802
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
(YLOD)

RSX VRAM DEAD? How can I test RSX?

 

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 .
You can change these either using the dedicated ("internal") UART commands (https://pastebin.com/zEznkQiq) or by using the external read/write UART commands (https://pastebin.com/5sTdsVMZ).
This Python 2 script can be used for easy access: https://pastebin.com/4ymiFQbi .
To be able to change these regions from the CELL via the Device Access Service (0x03), the Syscon firmware needs to be patched: https://pastebin.com/6C1SJ8pM .

Epic

So... for a standard user without programmers and without need to open the PS3, the first thing we should do is to apply a patch in syscon ? (i guess with a normal firmware installer containing a "fake" syscon patch using a bigger version than the one already installed)
And this enables access to the Device Access Service (0x03) and since that point we can customize the fan table (and other stuffs inside syscon)

Do you have some sample of the data inside the fan table ?
Im just asking for curiosity sake, and because this table

By looking at the struct names i dont get it, i guess the most importants are the duty, tempu (when temperature goes up), and tempd (when goes down)

Did you figured how it works ?... some successful tests increasing the speed values a bit ?

 

Ok, THANKS!
I want to test RSX VRAM. (Does not display image).

> rrsxc 00 01
+0 +4 +8 +C
-----------------------------------
[SSM] RSX Interrupt : Detected !
RSX SY_IES register (0x0008) = 0x2
[SSM] state: 0400 -> 0700
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] Shutdown mode : syspm_stat=00000000/00000000
00000000
[mullion]$ [ERROR]: 0xa0801802
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
(YLOD)

RSX VRAM DEAD? How can I test RSX?

Sadly the retail syscon firmware doesn't contain the necessary diag code. So you can only debug the problem using the errlog and maybe trace command.

So... for a standard user without programmers and without need to open the PS3, the first thing we should do is to apply a patch in syscon ? (i guess with a normal firmware installer containing a "fake" syscon patch using a bigger version than the one already installed)
And this enables access to the Device Access Service (0x03) and since that point we can customize the fan table (and other stuffs inside syscon)

That's right, the firmware can be installed by using a modified PUP or the SC Manager (via linux or lv1call).

Do you have some sample of the data inside the fan table ?
Im just asking for curiosity sake, and because this table

Yes, I'll provide the factory fan table for each console with CXR syscon until the end of the week.

By looking at the struct names i dont get it, i guess the most importants are the duty, tempu (when temperature goes up), and tempd (when goes down)

I'll document the valid values and the meanings of the important struct members later this week.
I have no way of testing these because I only have (working) consoles which use the prototype format.

 

That's right, the firmware can be installed by using a modified PUP or the SC Manager (via linux or lv1call

That lv1 syscall is available in CEX CFW ?

Im trying to imagine how could be the procedure to change the fan table if at some point is released some "noob friendly" program for that task. Installing a handcrafted PS3UDAT.PUP looks good enought, but that lv1syscall looks even easyer

So it would be either
Install a pup, then run some program to update the fantable or...
Just run a program and it will do all the tasks
Both are posibles in a CEX CFW ?



Edit:
And... can we install a custom syscon patch in a .pup containing both, the patch to enable the Device Access Service, and the new values of the fantable ?
You know... the "2 birds in a shoot" strategy

 

That lv1 syscall is available in CEX CFW ?

Im trying to imagine how could be the procedure to change the fan table if at some point is released some "noob friendly" program for that task. Installing a handcrafted PS3UDAT.PUP looks good enought, but that lv1syscall looks even easyer

On GameOS you'd need to use the dispatcher manager to contact sc manager for the sc binary patch. It's very similar to the already used sc manager eeprom read/write (NVS) functions.
The actual fan table would then be written using the fallback eeprom read/write (SDA) functions.

So it would be either
Install a pup, then run some program to update the fantable or...
Just run a program and it will do all the tasks
Both are posibles in a CEX CFW ?

Yes

Edit:
And... can we install a custom syscon patch in a .pup containing both, the patch to enable the Device Access Service, and the new values of the fantable ?
You know... the "2 birds in a shoot" strategy

Theoretically yes, altough this would be very complicated. Sony designed the patch only to patch the rom region and it can only patch 4 offsets. We're already using 3 of them.



Here're the promised factory fan table examples: https://workupload.com/file/rHcbgYhk .

Also this output should explain the fan table a bit more, these are the main values. I think the other important values should be self explanatory (min_duty, max_duty, active, shutdown_temp_x).

 

The dumps and that screenshot are really interesting, they helped me to understand a couple of important details i was wondering since years ago, thanks a lot

The screenshot you posted doesnt belongs to any of the dumps, right ? (or im blind)
From the values in the dumps the one i understand better is the fantable for SEM-001

 

The screenshot you posted doesnt belongs to any of the dumps, right ? (or im blind)

That's right, I simulated the output on a DECR-1000 based on a modified DIA-001 fan table.

 

That's right, I simulated the output on a DECR-1000 based on a modified DIA-001 fan table.

Thanks a lot for the effort in showing an example to me, it was good enought

Im not hurry (and i know im at the end of the queue with the CECH-25xx's), but now that you opened the can of worms im confident that we are going to have control of the fantable and "user friendly" tools soon of later

 

If anyone is interested, that's the current status regarding the CXR Syscon firmware dumps: https://pastebin.com/LhR6s9rp

 

That's right, I simulated the output on a DECR-1000 based on a modified DIA-001 fan table.

 

I realized about how it works an effect that i been mentioning a couple of times in the forum, i always thought this was some kind of error but is made on purpose

Im going to use as example the fantbl of a DIA-001 (and the names from this structs https://pastebin.com/Wtc7NcJ4)
It have 3 "fan_table_new" but only 2 of them contains valid values
The "fan_table_new.minduty" is 0x33 (20% fan speed)... it seems all the PS3 models starts with this fan speed

But... the value "special_section.initial_fan_duty" is 0x4D (30% fan speed ?)
And... the value "special_section.initial_fan_time" is 0x14 (20 seconds ?)

--------------
What happens is in the first 20 seconds the PS3 uses a fan speed a bit higher than the minimal, and after that 20 seconds it goes down to the minimal fan speed

In my PS3 is very notable because i have an small hardware mod that increases that speeds (so the noise generated by this initial "boost" is more notable than any other PS3)

------------
To be honest, i always thought that could be nice to disable that initial boost (i hate it a bit), but at this point im completly sure is a "feature" and is made on purpose by the engineers
Probably is because inmediatly when you power on a processor there is a high temperature peak (i was aware about it since lot of tme ago, when i burned my finger with a pentium 4 to check it by myself btw)

The point is... from factory is starting at 0x4D and then after 20 seconds goes down to 0x33
But... if you start in 0x4D and keep that 0x4D all along the first fan step... then i guess is not needed the initial boost

 

I think @sandungas is a little bit of a Fan of this discovery of the Fan Table within the SYSCON

 

Im just having some fan with it
Im learning lot of things and i have many questions to do, but at this point there is something that is shocking me a lot.. using the DIA-001 as example...

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

Spoiler

zone2 and zone4 doesnt exists in DIA-001

The shocking thing is the "special_section.shutdown_temp_bevr" have a value = 0x7D (125ºC)
This temperature is really high... the only place where i guess it could reach that temperature are all the components related with power lines (at the other side of the TOKINS)

But anyway.... it also means that the motherboard have an additional thermal sensor located in there... and it also means syscon have a pin connected to that sensor (hmm, or maybe that additional sensor is connected in cascade to the I2c bus of the thermal monitors chips)

 

Im just having some fan with it

Well enjoy your fanfare....

bevr <--- dafuq is this ?... Cell BE voltage regulators ?

Looking at the abv > bevr, this could be a logical conclusion, it could also mean beverage time/conditions after all that lazy work its doing, or NOT doing.

The shocking thing is the "special_section.shutdown_temp_bevr" have a value = 0x7D (125ºC)
This temperature is really high... the only place where i guess it could reach that temperature are all the components related with power lines (at the other side of the TOKINS)

But anyway.... it also means that the motherboard have an additional thermal sensor located in there... and it also means syscon have a pin connected to that sensor

That is just a tad bit toasty of a temp to get to, but what the hell on the MB could reach that temp, more to the point what on the MB is rated to that temp before it must be shutdown, the only things would be to do with power, anything else would most likely be fried long before it reaches anywhere near that.

 

lol, that's when you use the ps3 for kindling.

 

lol, that's when you use the ps3 for kindling.

Would make an excellent BBQ lighter replacement or the full BBQ, just stick a grill over the top and your sorted.

 

that's actually what I was thinking, 'cause a lot of people thought that the phat looked like a grill.