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

Discussion in 'THE FEED (Submit/View News)' started by STLcardsWS, Sep 2, 2019.

By STLcardsWS on Sep 2, 2019 at 5:37 PM
  1. 9,314

    STLcardsWS Administrator

    Sep 18, 2014
    Likes Received:
    Trophy Points:
    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,. .


    • 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.

      What can developer's do with this key?

      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:

    Thanks to @NathanHale for the news alert
    Last edited: Sep 10, 2019
    ntodek, smikk, Louis Garry and 16 others like this.


Discussion in 'THE FEED (Submit/View News)' started by STLcardsWS, Sep 2, 2019.

    1. M4j0r
      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
      BD Primary
      BD Secondary
      Air Intake
      inside chasis
      XIO trace
      IOIF0 trace
      IOIF1 trace
      1st HDD
      2nd HDD
      Also, here's the fan table of the refurbished CECHA:
      Last edited: Feb 13, 2020
      pinky likes this.
    2. sandungas
      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 ? o_O

      That related syscall are still a bit unknown, im going to copypaste them from webman source
      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", "", and "" from the struct

      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 ?
      Last edited: Feb 13, 2020
    3. M4j0r
      DECR-1000 can also group sensors and fans into regions.
      6 for COK-001 and COK-002, 3 for later models.
      0: Full
      1: Auto (default)
      2: Manual
      FF: Ram default
      else: Rom default (default)
      0: Remove
      FF: Use (default)
      I don't know how Syscon decides on which fan table to use.
      sandungas likes this.
    4. sandungas
      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)

      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)
    5. sandungas
      Ok, so the "zone2" and "zone4" are either one of those individually.... or a group composed with several of those
      Got you :)

      This one with the official RSX hack ? --->
      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 ?
    6. M4j0r
      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.

      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.

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

Share This Page