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 ​

 

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

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

Also, here's the fan table of the refurbished CECHA: https://workupload.com/file/md3zdNS2

 

The full list list temp sections is

You mean the full list of temperature sensors, right ?

The unexpected thing for me was to see that syscon have a connection with a sensor named "bevr" (either direct, or in cascade in the I2C bus with the other main thermal sensors for CELL and RSX)
Incase of being connected to the I2C bus... it means it should have a complementary "thermal monitor" chip
So... we are missing 2 important chips since lot of time ago

Also, an interesting detail is the fan speeds are not affected by the temperature of the "bevr" sensor... but the fact that there is a shutdown temperature value for it means syscon is monitoring that sensor at all times

Is just the syscall we use to display the temperatures doesnt allows to display that temperature of the "bevr".... or it does ?

That related syscall are still a bit unknown, im going to copypaste them from webman source https://github.com/aldostools/webMAN-MOD/blob/master/include/fancontrol.h

static void sys_sm_set_fan_policy(u8 unknown , u8 fan_mode, u8 fan_speed)
	// syscon mode: 0, 1, 0x0
	// manual mode: 0, 2, fan_speed (0x33 - 0xFF)

static void sys_sm_get_fan_policy(u8 id, u8 *st, u8 *mode, u8 *speed, u8 *unknown)

static void get_temperature(u32 _dev, u8 *temp)

Btw, right now i dont get the concept of "fan_table_new.policy", "fan_table_new.select", and "fan_table_new.active" from the struct https://pastebin.com/Wtc7NcJ4

Inside the fantbl there are actually 3 tables (not sure if you are naming them "fancon") for all the PS3 models (and 6 for COK-001), right ?

How can be selected ?, the only way i see is incase the "policy" is working like an id ?... and using the sys_sm_set_fan_policy ?

The "active" looks more straightforward... is mostly like an "available"... value 0x00 means is good... and 0xFF means it cant be used, right ?

 

You mean the full list of temperature sensors, right ?

Yes.
DECR-1000 can also group sensors and fans into regions.

Inside the fantbl there are actually 3 tables (not sure if you are naming them "fancon") for all the PS3 models (and 6 for COK-001), right ?

6 for COK-001 and COK-002, 3 for later models.

Btw, right now i dont get the concept of "fan_table_new.policy", "fan_table_new.select", and "fan_table_new.active" from the struct

Policy
0: Full
1: Auto (default)
2: Manual

Select
FF: Ram default
else: Rom default (default)

Active
0: Remove
FF: Use (default)

I don't know how Syscon decides on which fan table to use.

 

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)

Im taking another look at this, i used question marks in the value conversions because i was not sure if i converted them right

The mistery is... which unit is used to count the time ?, from the known values there are only 2 where are stored times (and i guess both should use the same time meassure units). The "initial_fan_time", and "thermal_shutdown_time"

In all the syscon fantable dumps uploaded by M4j0r the "initial_fan_time" is 0x14, and when converted to decimal thats 20

When i turn on my CECH-25xx that initial "speed boost" ony last for 4 seconds (5 as much), then the speed goes down gradually (it takes like 2 seconds to go down or so... not sure)

So... right now i think the time is meassured in deciseconds (where 1 decisecond = 0.1 seconds)
http://www.kylesconverter.com/time/deciseconds-to-seconds

So... the "special_section.initial_fan_time" = 0x14 ... (20 in decimal) seems to be 2 seconds


Can someone meassure this "initial fan boost" time in other PS3 models ? (in some of the PS3 fats if posible)... i think exists in all PS3 models but im not sure, and i never kept attention to messure his lenght



------------------------------------
Btw M4j0r, what means the "thermal_shutdown_time" ?
I mean... when is used that time ?

Incase you dont know... i been thinking that it could be a time delay applyed everytime the PS3 triggers one of the shutdowns

You know... instead of doing an instant shutdown... by using that value maybe is posible to delay the shutdown a bit (kind of thing to advise the user that the device is going to shutdown, and giving him time to "save his/her work" and all that
I know... this is a console and there is not much "work to save" (unless otherOS)... but this is like a courtesy to the user, instead of shuting down the device aburptly is posible to delay it a bit

Anyway... this value (thermal_shutdown_time) is always 0xFFFF in all your dumps (so is like default, or disabed, because 0xFFFF is not really a time meassurement)
And the value that comes after it (unknown0) could be related with it

I mean... incase of using a valid time in "thermal_shutdown_time" then the "unknown0" becomes something useful
Otherway... with the "thermal_shutdown_time" = 0xFFFF (disabled, or default) the "unknown0" is ignored (always 0)


All this theory is incase the "thermal_shutdown_time" is related with the "unknown0"... but this is completly speculative, the only reason why i started thinking in it is because both values are consecutive (and the first one is always disabled/default=0xFFFF and second never used=0)

 

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

Ok, so the "zone2" and "zone4" are either one of those individually.... or a group composed with several of those
Got you

Also, here's the fan table of the refurbished CECHA: https://workupload.com/file/md3zdNS2

This one with the official RSX hack ? ---> https://www.psx-place.com/threads/frankenstein-phat-ps3-cecha-with-40nm-rsx.28069/
All the previous samples you uploaded have a total lenght of 0x200 but this one is 0x200 + 0x100

The first 0x200 follows the standards (with a few bytes used in the unknown areas btw)... but the next 0x100 should be considered part of the fantable or can i delete/ignore them ?

 

Btw M4j0r, what means the "thermal_shutdown_time" ?
I mean... when is used that time ?

I think of it as the duration of which the shutdown temp has to be there. And if it's 0xFFFF the console will directly shutdown after the shutdown temp occurs. Maybe to ignore temp spikes. But it needs more reversing.

And the value that comes after it (unknown0) could be related with it

The unknown values are not used by any of the fan or temp control commands, so they're only changed using raw read and writes commands, they might be only related to the fan/sensor hardware config.

This one with the official RSX hack ? ---> https://www.psx-place.com/threads/frankenstein-phat-ps3-cecha-with-40nm-rsx.28069/
All the previous samples you uploaded have a total lenght of 0x200 but this one is 0x200 + 0x100

Yes, just ignore the last 0x100, I included them by accident.

 

Some small update into the research:

We decided to go into glitching, since DPA is causing us a lot of headaches.

We managed to retrieve the 78K0R SherWood SYSCON FLASH ROM, which is currently being hosted at https://github.com/zecoxao/sherwood.

For keepsake i'll also host the files here.

Additionally, the flash programming lib will also be hosted here, for keep sake aswell.

List of commands can be found around 0xEE01A

00 20 22 13 14 32 40 9A C0 C5 B0 A0 10

Edit: What we're interested is in cmd 0x14 right now

Edit2: Uploading the debugger dump as well

 

So to my understanding (I apologize I haven't had time to read through the whole thread recently), am I right in assuming that because we have access to the fan table from Syscon, this may pave the way to setting our own custom fanspeeds? I know CFW can do this but it's still an interesting topic.

 

So to my understanding (I apologize I haven't had time to read through the whole thread recently), am I right in assuming that because we have access to the fan table from Syscon, this may pave the way to setting our own custom fanspeeds? I know CFW can do this but it's still an interesting topic.

Yes, but we're still looking for the remaining fws

 

Here's the debugger dump from our research

 

Yes, but we're still looking for the remaining fws

Great! Thank you for the clarification.

 

another update. we found out where the flash rom structure is located, and made a table with each command, address and permissions
the command table can be found at the wiki and is as follows

Code	Offset	Permissions
00	0xEE3DC	10
20	0xEEA68	10
22	0xEEAE2	10
13	0xEE9BE	10
14	0xEEA42	02
32	0xEED8C	10
40	0xEEE79	10
9A	0xEE3E2	02
C0	0xEF0D9	05
C5	0xEE41C	05
B0	0xEF062	11
A0	0xEF16E	11

with the structure define from the start of 0xEE000 as follows

u16 firmware_version
u16 function_address[0xC]
u8  function_code[0xC]
u8  permissions[0xC]

note that the function address gets 0xE0000 for the real address

Edit: So this means that Functions 0xA0 (Security Set) and 0xB0 (Checksum) have 0x11 flag of permissions, 00 (Reset) 20 (Chip Erase) 22 (Block Erase) 13 (Verify) 32 (Blank Block Check) and 40 (Programming) have 0x10 flag perms, C0 (Silicon Signature) and C5 (Version Get) have 0x05 permissions and finally unknown command 0x14 (likely OCD related) and 9A (Baud Rate Set) have 0x02 perms

 

So for everybody who's wondering why the 78K0R (PS3) is harder to attack than the RL78 (PS4):
1.) Power Analysis: Higher overall noise floor, reset needed to acquire trace.
2.) Glitching: Glitch protection through voltage supervisor with low voltage detection, masked firmware (= flash rom, NEC code, not Sony code).

I was able to dump the 78K0R flash rom by using the same method which was used to dump the bootcode and backup bank of the CXRF syscon. Masking is nothing more than obfuscation and you'll always find the deobfuscation code in the plain code section, it's just writing magic values to some undocumented registers.

 

So to my understanding (I apologize I haven't had time to read through the whole thread recently), am I right in assuming that because we have access to the fan table from Syscon, this may pave the way to setting our own custom fanspeeds? I know CFW can do this but it's still an interesting topic.

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




Edit:
Well, to be fair... the custom fancontrol softwares would still be useful to make some tests with the purpose of finding the better settings for your PS3 in a safe way (without needed to write any data in syscon)... and after that when you have the optimal values you should "write" them in syscon and dont use the fancontrol softwares anymore

But my guess is... for most of the PS3 owners interested in this is not going to be needed to make much tests because at some point some other people would start publishing his settings (for every PS3 model)... and you can just copy that values

Every PS3 unit have his owns problems and differences in the thermal performance, but there is a general rule that can be applyed to all the PS3's of the world, what we need is pretty much to increase the factory speeds up to +20% or so
This is an initial rought calculation, but i think is the minimal requirement, and a modification like this +20% im suggesting should cover all PS3 models

 

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

I think I have a problem with that (and others too):

> eepcsum
eepcsum
Addr:0x000032fe should be 0x528c
Addr:0x000034fe should be 0x7115
sum:0x0100
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff

Is there a way to reset or recover the EEP? (COK-002 board CokB10 / v1.1.3_k1)

 

Is there a way to reset or recover the EEP? (COK-002 board CokB10 / v1.1.3_k1)

As long as the PS3 wasn't refurbished, the EEPROM content is always the same (excluding the perconsole region (0x0-0x2800) and maybe the qa flag), so it's safe to use another dump from the same motherboard/syscon for offsets 0x2800-0x8000.
If the 0x0-0x2800 area is messed up, the syscon might need to be remarried to the CELL, but it can solve most of the problems by itself.


The checksums are just based on simple uint16 additions:

Checksum@       Area covered
0x32FE          0x3100 - 0x32FD
0x34FE          0x3300 - 0x34FD
0x39FE          0x3900 - 0x39FD
0x3DFE          0x3C00 - 0x3DFD
0x3FFE          0x3E00 - 0x3FFD

Example python script:

import sys
import struct

with open(sys.argv[1], 'rb') as f:
  data = f.read()
  checksum = 0
  for i in xrange(0, len(data), 2):
    checksum = (checksum + struct.unpack('<H', data[i:i+2])[0]) & 0xFFFF
  print hex(0x100FF - struct.unpack("<H", struct.pack(">H", checksum))[0])

 

It seems common (problem?) among COK-002 boards as both of mine and the one in your twitter has the same cksum mismatch.
Is the EEP INIT or eeprominit working on CEX somehow? (what kind of [id] needed?)
In internal mode i can only access the range 2C00-73FF

And from Twitter: could you please elaborate how to switch off the RSX and get a bootlog out of the SB?

 

It seems common (problem?) among COK-002 boards as both of mine and the one in your twitter has the same cksum mismatch.

The checksum generation always worked for me and I tested it on COK-001, DIA-001 and DIA-002. If it fails, you can still dump the complete area and calculate it manually to fix the issue. I don't know why this might only happen on the COK-002. The algorithm is straightfoward so I don't think the implementation is wrong.

Is the EEP INIT or eeprominit working on CEX somehow? (what kind of [id] needed?)

EEP INIT will just overwrite everything with FF which would brick your console.

In internal mode i can only access the range 2C00-73FF

Yes, the other areas are blocked and need a special firmware patch.

how to switch off the RSX

Either using the devpm (DECR) or powerstate command or the 0x3032 flag (DECR). It depends on where it fails, in most cases just patching sysctl.txt also works. There are also other ways, which I don't remember atm, but the PS3 won't boot to lv2 without a working RSX.

and get a bootlog out of the SB?

That's controlled by the 0x48C02 flag, setting it to 0x02 will allow you to get the lv0+ log via the SB Uart. You can also activate more lv0ldr debug messages by setting 0x48C11 to 0x03.

 

so guys, could someone tell me what are all the tools used in relation to syscon exploration / testing, what are you using?

 

so guys, could someone tell me what are all the tools used in relation to syscon exploration / testing, what are you using?

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