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,416

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

      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

      Attached Files:

      Last edited by a moderator: Mar 30, 2020 at 2:45 PM
    8. TheMadPolarBear
      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.
    9. zecoxao
      Yes, but we're still looking for the remaining fws
      M4j0r and TheMadPolarBear like this.
    10. zecoxao
      Here's the debugger dump from our research

      Attached Files:

      M4j0r likes this.
    11. TheMadPolarBear
      Great! Thank you for the clarification.
    12. zecoxao
      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


      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
      Last edited: Mar 30, 2020 at 2:21 PM
      Anthonyy817, Algol and M4j0r like this.
    13. M4j0r
      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.
      zecoxao likes this.
    14. sandungas
      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

      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
      Last edited: Mar 30, 2020 at 3:26 PM

Share This Page