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 ​

 

Status update: wildcard managed to grab the latest syscon firmware from psvita (psvita slims with mini usb) and M4j0r managed to grab TA-082 syscon firmware from a psp board (psp phats)

 

some tools:

ChipWhisperer Lite
Teensy 4.0
DSLogic Scope and Logic Analyzer (forgot which)

Besides the usual hot air station and soldering iron for removing resistors/capacitors

thank you

 

Is there any way to enter Internal mode without soft-bricking the machine?
If i set 3961 to 00 then it 3beeps and blinks after powering on with the test pin pulled, enters the Internal mode but no longer able to start up:
bringup - Do nothing. (FatalOff State)
devpm <any> on - *** Unknown Error11 ***
/power-button/ - [SSM] cannot clear fatal error state because of unrecoverable error

Even on an otherwise perfectly(?) working CECHC machine. (at least boots into GameOS fine)

3960 seemingly does nothing (default is 02)

(also the eepcsum is the same as in the not working one and seems it changes the csum if i change the values -- like if i set 3961 back to FF the csum changes from 0038 to 0138)
----
Can you share some info about what the LabStation mode is and what can it do?

thanks

 

You may have more luck in this thread where ongoing research is being done by a few of our members. Or try our @(devs or users name here) mention system.

https://www.psx-place.com/threads/f...-and-error-reporting.30100/page-2#post-248258

 

Is there any way to enter Internal mode without soft-bricking the machine?
If i set 3961 to 00 then it 3beeps and blinks after powering on with the test pin pulled, enters the Internal mode but no longer able to start up:
bringup - Do nothing. (FatalOff State)
devpm <any> on - *** Unknown Error11 ***
/power-button/ - [SSM] cannot clear fatal error state because of unrecoverable error

Even on an otherwise perfectly(?) working CECHC machine. (at least boots into GameOS fine)

3960 seemingly does nothing (default is 02)

(also the eepcsum is the same as in the not working one and seems it changes the csum if i change the values -- like if i set 3961 back to FF the csum changes from 0038 to 0138)
----
Can you share some info about what the LabStation mode is and what can it do?

thanks

Fix the checksum

 

Technically talking... all the custom fancontrol softwares running in CFW and HEN cant change the fantable
What they does is to send "orders" to the syscon chip on runtime to "force it" to use an specific speed

There are some problematic consequences of that custom fan speed management:
-Is not efficient because all that communications in between the firmware and syscon chip are made using a big amount of syscalls that have a hit in the performance of the whole system
-Is a lot less safe because the custom code could stop working as a consequence of unexpected problems
-Only works under specific enviroments (doesnt works in PS2 mode, OtherOS, or other special PS3 boot modes)
-The syscon fan speed adjustments are more precise, failproof, and doesnt causes any performance hit

In plain words... if at some point is released a tool to customize the fantable values inside syscon is going to make obsolete all the other custom fancontrol softwares

Have you tried the 'fantbl setini' command? It's the same as the set, but stores the table in the EEP
(just some help from the syscon:

fantbl - Fan Table set/get command
Usage: fantbl set fanconNo pNo tempD tempU duty
ex. fantbl set 0 p1 0x1400 0x1E40 0xC0
ex. fantbl set 0 p1 20.0 30.25 75
Usage: fantbl get fanconNo
ex. fantbl get 1
)

after that you have to manually fix the csum of the eep:
eepcsum gives you the Calculated values you could then w or w16(?) into 34FE.
(when using w swap the bytes, for ex:
Addr:0x000034fe should be 0x122e
>w 34fe 2e 12 )

 

Have you tried the 'fantbl setini' command? It's the same as the set, but stores the table in the EEP
(just some help from the syscon:

fantbl - Fan Table set/get command
Usage: fantbl set fanconNo pNo tempD tempU duty
ex. fantbl set 0 p1 0x1400 0x1E40 0xC0
ex. fantbl set 0 p1 20.0 30.25 75
Usage: fantbl get fanconNo
ex. fantbl get 1
)

after that you have to manually fix the csum of the eep:
eepcsum gives you the Calculated values you could then w or w16(?) into 34FE.
(when using w swap the bytes, for ex:
Addr:0x000034fe should be 0x122e
>w 34fe 2e 12 )

I never tryed to communicate with syscon in a PS3, i have a PS3 fat collecting dust (i dont even remember the model right now), and two CECH-25xx (but the fact is one of them was intended to be used as replacement parts)... all them works, but i only use one of the CECH-25xx
As far i remember... the last time i was reading about the fan table stuff in psdevwiki the related commands (fanconpolicy, and fantbl ?) only had the "get" versions documented, but not the "set" ones... not sure if has been added latelly or i missed them, but yeah... is very interesting

In my last posts in this thread i got the idea that we can overwrite the fantable by installing a syscon patch PKG (and thats good enought, is a milestone in itself)... but being able to modify it with JTAG could be convenient

What is the EEP btw ?... is some kind of "volatile" storage ? (returns to defaults when power is removed from syscon)... or is permanent ?

 

What is the EEP btw ?... is some kind of "volatile" storage ? (returns to defaults when power is removed from syscon)... or is permanent ?

eeprom -- non-volatile (that's why you have to fix the checksum)
The internal mode also no longer needed after, even power off/on and the table is active. (well, if you setini the table 0 that is)
Or you can use the normal 'set' command for session/RAM tables but only active while the syscon is powered.
This howto come directly from the syscon terminal with slightly(?) misformed command -- that is weird as usually just reply *** Invalid Argument *** but sometimes gives these verbose descriptions.

It's not JTAG, but serial
I'm pretty sure there is a way to access these eeprom tables from PKG but I'm not too deep into PS3 coding to do it myself.

 

https://www.psdevwiki.com/ps3/Keys#DYN-001_body_key

DYN-001 syscon patch keys dumped

The structure is not yet very well understood but once it is we should be able to produce a patch that just dumps the whole rom via UART

 

DYN-001 body key ?, nice progress

 

DYN-001 body key ?, nice progress

We also got the mac key to forge the cmac hashes of the syscon patch (the key below on the wiki)

Edit: You can check out progress of dump here:
https://github.com/zecoxao/sherwood/blob/master/mapping/mapping_BB_rom_only.bin

 

We also got the mac key to forge the cmac hashes of the syscon patch (the key below on the wiki)

Edit: You can check out progress of dump here:
https://github.com/zecoxao/sherwood/blob/master/mapping/mapping_BB_rom_only.bin

I guess this means the syscons from other PS3 Slim motherboards are going to be vulnerables too, or we cant count with it yet ?

Btw, just incase someone didnt realized... the DYN-001 is the motherboard of the first PS3 Slim model. And the other PS3 Slim models uses a syscon chip that is either identical to the one used in DYN-001 or compatible with it (syscon SW2-30x series)

Spoiler

Some of the CECH-30xx PS3 models have an updated syscon SW3-30x series though

In plain words... this seems to be good news for PS3 Slim owners

 

I guess this means the syscons from other PS3 Slim motherboards are going to be vulnerables too, or we cant count with it yet ?

Btw, just incase someone didnt realized... the DYN-001 is the motherboard of the first PS3 Slim model. And the other PS3 Slim models uses a syscon chip that is either identical to the one used in DYN-001 or compatible with it (syscon SW2-30x series)

Spoiler

Some of the CECH-30xx PS3 models have an updated syscon SW3-30x series though

In plain words... this seems to be good news for PS3 Slim owners

The "vulnerability" (if we want to call it that) is that we can glitch all 64 4 byte checksums of a 0x100 block, leak bytes from those specific positions and then use said bytes to bruteforce in 4 byte verify each of the 64 4 byte blocks. The rate this is going is extremely slow (usually it takes about 8 hours to dump a full 0x100 byte block, and the SW2 and SW3 syscons have a total of 3072 blocks) but it is indeed possible to dump all blocks of the syscon rom. it does however take months to do it. The good thing about this is that ALL SYSCONS from nec or renesas are vulnerable to this method, which goes from psp, ps3 to psvita, ps4.

In theory anyone can grab the code and do a dump of all psp syscons except the really old ones with mask rom and of all psvita syscons and of all new ps3 syscons. Having one person only doing this will take a while.

The benefits of dumping the psp syscon are obtaining the Pandora Battery JigKick Keys
The benefits of dumping the psvita syscon are obtaining the Keyset 0x01 Keys and the Keyset 0x00 (should anyone possess a DEM) Keys
It is unclear which benefits will be from dumping the ps3 syscons.

 

If you want to check on the code (it's still WIP) you can do so at Wildcard's github repo:

https://github.com/VV1LD/78K0R_Flash_Leaker

 

hi !
I replaced CELL in my SEM-001 motherboard, but, i lost nand dump
Can i restore(rebuild) bootldr & metldr without dump? i know, bootloader crypted in factory.... is it possible, having full access Syscon ?

 

hi !
I replaced CELL in my SEM-001 motherboard, but, i lost nand dump
Can i restore(rebuild) bootldr & metldr without dump? i know, bootloader crypted in factory.... is it possible, having full access Syscon ?

CELL doesn't trust SysCon, even if Syscon is supposedly the MASTER and CELL the SLAVE, so you can't do anything.

 

CELL doesn't trust SysCon, even if Syscon is supposedly the MASTER and CELL the SLAVE, so you can't do anything.

i get CID and ECID over SYSCON
> ECID GET
00000000 01C51801050C470E1306144000000000
> CID GET
00000000 000200AC8DDD
is this information from SYSCON/NAND or directly from new CELL?
(I want to search for my dumps, maybe, lucky find old dump )

 

i get CID and ECID over SYSCON
> ECID GET
00000000 01C51801050C470E1306144000000000
> CID GET
00000000 000200AC8DDD
is this information from SYSCON/NAND or directly from new CELL?
(I want to search for my dumps, maybe, lucky find old dump )

Directly from CELL, but the NAND has the same numbers

 

Progress update: using the same trick we were able to find two sets of syscon keys:
The keys for the PSTV Syscon
The keys for 99% of Prototype PSVitas and Some PHAT PSVitas

We are currently checking on psp syscon and also a SW3 (ps3 superslim and slim 3000) chip

 

@M4j0r or @zecoxao have you updated this structs since it was posted here in the forum ?
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-10#post-223893
https://pastebin.com/Wtc7NcJ4

The other day i was making some graphics
https://www.psx-place.com/threads/custom-syscon-fan-profile.30873/page-2#post-257656
And i was taking a better look at the syscon fantbl region dumps uploaded:
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-11#post-225349
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-12#post-227210

And i think i identifyed (only partially) 10 new unknowns of a single byte each, is a bit long to explain why im saying this but it can be seen how they changes in the different dumps uploaded by @M4j0r
The new structure im suggesting to use should be like this (all them are located in the "special_section" area)
https://pastebin.com/aYAERwug

-------------
But... first things first... not sure if it was mentioned before and i missed it, but while doing the graphics i realized every fantbl belongs to a hardware component... or better said... every fantbl belongs to a thermal sensor in this order cell, rsx, zone2, bevr, zone4 (same order than the shutdown values inside the "special_section" area)

In the PS3 models that uses the "fan_table_new" structure (with only 3 fantbl's) the first is cell, second is rsx, and third is bevr
In previous PS3 models that uses the "fan_table_old" structure (with 6 fantbl's) there are only 3 active and with valid data (again... cell, rsx, bevr), 2 of the others unused are for zone2, and zone4... and the last one unused i cant imagine (but there are other places of the structure where it looks the total is 6 instead of the 5 we know... that last fantbl is a mistery)

Also, i realized the COK and SEM motherboards are monitoring 3 sensors (cell,rsx, bevr)... and since DIA motherboard only 2 (cell,rsx), so probably all the other newer PS3 models monitors only 2 (cell/rsx)
And i guess the "get" syscalls related with fan and temperatures are able to output the bevr thermal info in COK and SEM motherboards with the factory config
The problem is we need to use ID3 for bevr (not ID2, because ID2 is zone2 and doesnt exists), is like this:
ID0 = CELL
ID1 = RSX
ID2 = ZONE2
ID3 = BEVR
ID4 = ZONE4

If we use the syscalls with ID2 is not going to work, but it should work with ID3 (only in COK and SEM motherboards)