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 ​

 

@vyktormvmpay25 just dumped one of the last missing pieces of the puzzle, the SEM-001 SYSCON dump. he'll post it here soon enough

 

I'm sharing full tests as storege will ask to protect with password compresed files
http://s.go.ro/m4pu2t8w

 

with this we're only one firmware away from the complete phat syscon collection.
i'll mirror it here, in case the link is lost

 

Just another link with all tests during the week, from what I've tested mine dia002 syscon did not worked well (had one pad distroyed because of stencil stuck on ic with 0.6mm balls, used 0.55 mm after was fine) so had only dia001 boards and done test with that.
There are some videos testing wired fan speed accelerated, on second patch fan is fine. Still we can't do to much without CXR713F120 or 714120-303/304 syscon models which are rare to find, at least for me. If I ever reach one this tests will be continued.
http://s.go.ro/wrytedr2
This is an cok002 board with 65nm rsx and patches were tested with and only error left is 3034. Only working with modchip attached which use CLK, CS, DATA imput from Rsx port of syscon.

 

new dump thanks to wildcard. uploading...
SW3-301
@sandungas @mysis @3141card @bguerville @Joonie

 

New dump.
@sandungas @3141card @bguerville @mysis @Joonie
edit:
@vyktormvmpay25

 

I really hope one day this method of dumping will be released. I still believe last super slim ps3 method of bdrom paired with board is same as ps4 phat models and probably further.

 

I still believe last super slim ps3 method of bdrom paired with board is same as ps4 phat models and probably further.

Yes, all the renesas bd chips work the same.

 

If that so I wonder why cobra odd did not work for ps4, well one reason is that Microsemi (smartfusion 2 fpga used by cobra) probably quated producer after 3 years of free license, about 1400 dollars for one year.At least that they asked me for 1 year license in order to reuse that fpga. So that money were about to be lost if that wasn't about to work.

Spoiler

 

New dump.
@sandungas @3141card @bguerville @mysis @Joonie
edit:
@vyktormvmpay25

Thx
I guess this dump belongs to a CECH-40xx but im wondering if the motherboard is a MSX-001 or a MPX-001 ?... and the flash type was NOR or eMMC ?
Im asking because in wiki we are missing the platform ID of CECH-40xx -> MPX-001 (NOR)
Maybe we are lucky and this dump is from a MPX-001 (NOR) ? (in other words... maybe is the dodgy CokM40)
https://www.psdevwiki.com/ps3/Platform_ID

Hmmm, actually... at offset 0xA0000 in the dump is mentioned CokM10

@M4j0r ^

 

Thx
I guess this dump belongs to a CECH-40xx but im wondering if the motherboard is a MSX-001 or a MPX-001 ?... and the flash type was NOR or eMMC ?
Im asking because in wiki we are missing the platform ID of CECH-40xx -> MPX-001 (NOR)

We only have the chips :/

 

We only have the chips :/

Shame, is one of the platform ID's missing, btw this is a confirmation that the platform ID of that dump is CokM10 and that is "hardcoded"

Hmmm, actually... at offset 0xA0000 in the dump is mentioned CokM10

I mean... in the list you made at top of the page here the CokM10 is listed as "hardcoded - speculation" but i guess is not an speculation anymore, right ?, that dump is the proof that is "hardcoded"

And btw, have you noticed in the list of platform ID's at offset 0x2A35A posted here the CokN10 is repeated twice ?
I cant imagine why they did that repetition, is so weird that looks like a mistake, im wondering if they modifyed that list later in the next syscon firmwares for SW3-303 or SW3-304 (and they kept only one apparence of the name CokN10 instead of repeating it twice)

 

Shame, is one of the platform ID's missing, btw this is a confirmation that the platform ID of that dump is CokM10 and that is "hardcoded"

I mean... in the list you made at top of the page here the CokM10 is listed as "hardcoded - speculation" but i guess is not an speculation anymore, right ?, that dump is the proof that is "hardcoded"

Yes, that confirms it.
I think we can also say that for the super slim CokX10 or CokX20 means NOR and CokX30 or CokX40 means eMMC. CokX10 and CokX30 is board A and CokX20 and CokX40 is board B per series.
I wonder if we'll ever find a CokM40 or CokN20/CokN40.

And btw, have you noticed in the list of platform ID's at offset 0x2A35A posted here the CokN10 is repeated twice ?
I cant imagine why they did that repetition, is so weird that looks like a mistake, im wondering if they modifyed that list later in the next syscon firmwares for SW3-303 or SW3-304 (and they kept only one apparence of the name CokN10 instead of repeating it twice)

That's just due to the matching algorithm they use, could also be caused by the compiler.

 

Yes, that confirms it.

Nice, i will update that list later incase you dont do it first, and also cleanup some of my brainstormings in the talk page

I think we can also say that for the super slim CokX10 or CokX20 means NOR and CokX30 or CokX40 means eMMC. CokX10 and CokX30 is board A and CokX20 and CokX40 is board B per series.

Yesterday after writing my post i was thinking in it and updating wiki, yeah i agree, in superslims the last 2 digits of the platform ID seems to mean 10 & 20 = NOR. And 30 & 40 = eMMC
What lighted my spark yesterday is when looking at the platform IDs we have for superslim with the letter "M"
CokM10 = Used in the last syscon dump posted in this thread (sadly, unknown motherboard and unknown flash type)
CokM20 = MSX-001 (NOR)... confirmed by vyktormvmpay25
CokM30 = MPX-001 (eMMC)... confirmed by vyktormvmpay25 and littlebalup
CokM40 = Never found

The logic i followed is... we know that exists a MPX-001 (NOR) because we found a photo of it (unknown platform ID but is either the CokM10 or CokM40)
The fact that we found a photo of it so easily means that was produced for retail. I dont know where you found the syscon chip which dump was posted here using CokM10... but if i had to bet i would say it was taken from a retail motherboard
So... if the CokM10 belongs to retail, and there is a retail MPX-001 (NOR) asking for it... it seems is a match

Also, we have other reports of platform IDs where the suffix 10 & 20 was used in other superslim motherboards with NOR flash, and 30 & 40 for eMMC... the table was ordered a bit weird but after reordering it matches much better
Btw... it seems we should ignore the motherboard serial numbers when ordering them in the table for platform ID... for some reason the motherboard serial number is not directly related with the the order of the platform IDs. Probably is because the platform ID is given by sony at any time (they have freedom to choose the timing), but the serial number is given after the motherboard passes all kind of regulations by country (FCC, whatever)... or something like that... anyway, it seems at some point we will have to reorder that table ignoring the motherboard serial numbers

Also, it makes sense that they starts numbering them starting with the NOR first... because the process they was doing to validate them (stress tests, review of the anti-hacking protections, etc...) is easyer than eMMC
I mean... the jump to eMMC was not so easy, there are some anti-hacking features related with the SATA bus, when they swapped the SATA by eMMC probably they had to review a lot of "features"... just to be sure they was not doing any mistake or breaking something

Long story short... the platform IDs for superslims with suffix 10 & 20 was "engineered" first (safe production)... and the other variants with the suffix 30 & 40 was "engineered" after (risky production)

I wonder if we'll ever find a CokM40 or CokN20/CokN40.

Well, the CokM40 seems to belong to MSX-001 (eMMC), i thought it never was manufactured, but im changing my mind because it matches very well with the other samples we have. To be fair, the only reason why we are thinking about it as an easter egg is because we never found any report about this combination of a MSX-001 with a eMMC flash.. but maybe is just a coincidence and eventually someone if going to give a proof that exists and was produced for retail... it would not surprise much if that happens

The CokN20/CokN40 are the real easter egg, a funny thing about them is we can dedude the motherboard name almost completly
N?X-001 (NOR) = CokN20
N?X-001 (eMMC) = CokN40

I think the question mark is either... a "S" by using the same name convention than the previous model (MPX-001/MSX-001 ---to---> NPX-001/NSX-001)... or a "A" (to create the name NAmco for arcade PS3 models)

Im mentioning arcade PS3 models because in this table there are a couple of easter-eggs using the arcade keys... the weird thing is the order doesnt matches, im wondering if we have some mistake over there, or maybe we are missing some concept about why they was doing some things that seems to "break" his own standards

Anyway, i feel like i understand it a lot better now, i can smell this search is about to be completed, and i feel also that this kind of speculations and deductions should not be taken much far, we just need a few more samples and see if everything is confirmed

That's just due to the matching algorithm they use, could also be caused by the compiler.

But it was deleted later in the next syscon firmwares ?, i dont have dumps of SW-303/304 to check it
Is mostly a curiosity, but one way or the other i think is better to replace the sample in wiki by another sample of the list of platform IDs from the last syscon firmware version

And btw... incase this small variations in the list of platform IDs inside syscon firmware could be handy (i dont know) we could add more samples from all the syscon firmwares versions, for completionism
Not sure if this could be handy either for research, or for organizing a bit better the info in wiki, but the platform ID page is small, there is room for it... and actually we need to move some of the stuff from the "talk" page to front page


*Edit:
We need to update the section named "help request" too... by replacing the tool made by 3141card by the other tool you made a few weeks ago (technically, your tool superseeds it because it does the same + some extra goodies), right now i dont know where you posted the last version of it, if it was implemented inside other tools, or if someone hosted it in github... please when you have time update that wiki section of the page, we need to promote other people to help us completing this reasearch

 

The logic i followed is... we know that exists a MPX-001 (NOR) because we found a photo of it (unknown platform ID but is either the CokM10 or CokM40)
The fact that we found a photo of it so easily means that was produced for retail. I dont know where you found the syscon chip which dump was posted here using CokM10... but if i had to bet i would say it was taken from a retail motherboard
So... if the CokM10 belongs to retail, and there is a retail MPX-001 (NOR) asking for it... it seems is a match

I know the Syscons are from retail boards only.

Btw... it seems we should ignore the motherboard serial numbers when ordering them in the table for platform ID... for some reason the motherboard serial number is not directly related with the the order of the platform IDs. Probably is because the platform ID is given by sony at any time (they have freedom to choose the timing), but the serial number is given after the motherboard passes all kind of regulations by country (FCC, whatever)... or something like that... anyway, it seems at some point we will have to reorder that table ignoring the motherboard serial numbers

Yes, the motherboard serial wasn't assigned by the SCE engineers, same with the SKU model name.

Well, the CokM40 seems to belong to MSX-001 (eMMC), i thought it never was manufactured, but im changing my mind because it matches very well with the other samples we have. To be fair, the only reason why we are thinking about it as an easter egg is because we never found any report about this combination of a MSX-001 with a eMMC flash.. but maybe is just a coincidence and eventually someone if going to give a proof that exists and was produced for retail... it would not surprise much if that happens

It has all the necessary pads, I guess someone could even mod a NOR model .

Im mentioning arcade PS3 models because in this table there are a couple of easter-eggs using the arcade keys... the weird thing is the order doesnt matches, im wondering if we have some mistake over there, or maybe we are missing some concept about why they was doing some things that seems to "break" his own standards

The table is straight from lv1 and the information about the arcade keys from lv1ldr. I have no idea why they introduced these models (4.31 dates to October 2012).

But it was deleted later in the next syscon firmwares ?, i dont have dumps of SW-303/304 to check it
Is mostly a curiosity, but one way or the other i think is better to replace the sample in wiki by another sample of the list of platform IDs from the last syscon firmware version

The SW3-302 already has the latest Sherwood table, the 304 has the same since the newer models just use the eeprom overwrite function. I've included the latest Mullion table (little endian lol). The table changes can be seen in the "Adds support for Platform IDs" column: https://www.psdevwiki.com/ps3/System_Controller_Firmware#Syscon_firmwares . It doesn't include the removal of supported models though, for example Sherwood doesn't support the early Cookie platforms even though it has the Platform IDs listed.

We need to update the section named "help request" too... by replacing the tool made by 3141card by the other tool you made a few weeks ago (technically, your tool superseeds it because it does the same + some extra goodies), right now i dont know where you posted the last version of it, if it was implemented inside other tools, or if someone hosted it in github... please when you have time update that wiki section of the page, we need to promote other people to help us completing this reasearch

The current version of https://github.com/bucanero/psl1ghtv2_ports/releases/tag/v1.0.1 is broken, I've posted the newest version of my tool somewhere, I'd need to patch it into the older toolset so we'll get working pkg. Or we wait until bucaneros toolchain is fixed.

 

The SW3-302 already has the latest Sherwood table, the 304 has the same since the newer models just use the eeprom overwrite function. I've included the latest Mullion table (little endian lol). The table changes can be seen in the "Adds support for Platform IDs" column: https://www.psdevwiki.com/ps3/System_Controller_Firmware#Syscon_firmwares . It doesn't include the removal of supported models though, for example Sherwood doesn't support the early Cookie platforms even though it has the Platform IDs listed.

Im comparing the screenshot in your post with the list at top of the page here and there is a mistmatch that worths to be mentioned
The order (and maybe the hex values too?) of the Shr3.2-4 (with hex value 0x32)... and... Shr3.2 (with hex value 0x33) seems to be swapped
In your screenshot Shr3.2 goes first,and Shr3.2-4 after it. This makes more sense, so it looks like the problem is in the wiki list
Please review that for a confirmation, and check the hex values too
Btw, what are those hex value exactly ?, can we give them a name (official codename, or custom incase there is no codename for them). I been thinking in adding them to the table for platform ID, are very helpful because allows to see which platform ID names are "hardcoded" (in other words... are sharing the hex value)
That name of "hardcoded" is a bit confusing as a concept, i been thinking that "overriden" could be better, but showing the hex values in the table is even more explicit

The table is straight from lv1 and the information about the arcade keys from lv1ldr. I have no idea why they introduced these models (4.31 dates to October 2012).

I think there are a couple of problems in the Product Subcode table, tell me if you agree with what im going to say, i would ilke to have the agreement from someone involved in that research before doing big changes to it

The first problem is something we did since the begining when we was discussing it in this forum thread and in the first versions of the table here
In the table column most at left for the "PS3 Model" we are adding the suffix A,B,C that indicates the storage capacity (and indirectly can be used to know if the motherboard have a eMMC flash when the suffix is A)
The problem is... (as example) the "product subcode" 0x14 belongs to REX-001 (both motherboard variants NOR and eMMC)... but in the actual table we are telling 0x14 belongs to CECH-43xxA only
Thats wrong, product subcode 0x14 belongs to CECH-43xxA, but also to CECH-43xxB and CECH-43xxC
The best solution i see is to dont mention the letter suffix in the "PS3 Model" table column. In other words... im thinking in deleting that suffixes

The second problem is something i introduced few days ago, when i added a new column for the "platform ID", when i did that i kept the same number of table rows than the previous versions of the table
But now i realized every "product subcode" have 2 posibles values of "platform ID" (for NOR or eMMC)
In other words... the actual version of the table have 10 rows for superslims but needs to be 20, im thinking in adding them. And im going to fill the "platform id" cells for superslim with more question marks, just to prepare the table in the correct format... eventually we will be able to add the correct names for superslims platform ID in it

Btw, the "product subcode" 0x8F and 0x90 with the arcade keys (in theory) are 2 unknown motherboards, but are 4 different "platform ID". Lets say... if one of them is named XXX-001 and the other YYY-001 we have this 4 combinations:
XXX-001 (NOR) <---- platform ID = 1
XXX-001 (eMMC) <-- platform ID = 2
YYY-001 (NOR) <---- platform ID = 3
YYY-001 (eMMC) <-- platform ID = 4

Is a bit shocking that are not mentioned in the list of platform IDs of retail syscon firmwares, is making me wondering if this devices uses the value "platform ID" at all... or if are using some kind of special syscon because the syscon firmwares we have cant identify them, right ?... unless they are doing that trick with the "hardcoding" and the hex value is shared

Also, the arcade keys are making me think that maybe this was reserved to create farms of PS3's for internal use to create the server infrastructure of the "PS Now" service (to stream PS3 games by network)

 

The problem is... (as example) the "product subcode" 0x14 belongs to REX-001 (both motherboard variants NOR and eMMC)... but in the actual table we are telling 0x14 belongs to CECH-43xxA only
Thats wrong, product subcode 0x14 belongs to CECH-43xxA, but also to CECH-43xxB and CECH-43xxC
The best solution i see is to dont mention the letter suffix in the "PS3 Model" table column. In other words... im thinking in deleting that suffixes

I recorded one example of a CECH-4308C with product subcode 0x13. Unknown motherboard.

Edit: https://www.psx-place.com/threads/r...im-nor-emmc-consoles.16133/page-7#post-103347

https://mega.nz/file/FF0RUAiI#3PBptvwq6rXWHQtwuiXVSeQS-pBUhXMlpx8Nqy9KSWw

 

Im comparing the screenshot in your post with the list at top of the page here and there is a mistmatch that worths to be mentioned
The order (and maybe the hex values too?) of the Shr3.2-4 (with hex value 0x32)... and... Shr3.2 (with hex value 0x33) seems to be swapped
In your screenshot Shr3.2 goes first,and Shr3.2-4 after it. This makes more sense, so it looks like the problem is in the wiki list

Yes, they seem to be swapped on the wiki.

Btw, what are those hex value exactly ?, can we give them a name (official codename, or custom incase there is no codename for them). I been thinking in adding them to the table for platform ID, are very helpful because allows to see which platform ID names are "hardcoded" (in other words... are sharing the hex value)

Well, I would say the hex value is the Platform ID used by Syscon, it'll always translate the string to that ID, only the PS3 FW uses the actual string.

The first problem is something we did since the begining when we was discussing it in this forum thread and in the first versions of the table here
In the table column most at left for the "PS3 Model" we are adding the suffix A,B,C that indicates the storage capacity (and indirectly can be used to know if the motherboard have a eMMC flash when the suffix is A)
The problem is... (as example) the "product subcode" 0x14 belongs to REX-001 (both motherboard variants NOR and eMMC)... but in the actual table we are telling 0x14 belongs to CECH-43xxA only
Thats wrong, product subcode 0x14 belongs to CECH-43xxA, but also to CECH-43xxB and CECH-43xxC
The best solution i see is to dont mention the letter suffix in the "PS3 Model" table column. In other words... im thinking in deleting that suffixes

The second problem is something i introduced few days ago, when i added a new column for the "platform ID", when i did that i kept the same number of table rows than the previous versions of the table
But now i realized every "product subcode" have 2 posibles values of "platform ID" (for NOR or eMMC)
In other words... the actual version of the table have 10 rows for superslims but needs to be 20, im thinking in adding them. And im going to fill the "platform id" cells for superslim with more question marks, just to prepare the table in the correct format... eventually we will be able to add the correct names for superslims platform ID in it

The problems seem to be related, if you remove the suffix you can't indicate to which console the board or Platform ID belongs. It would make sense to include all the versions, so each superslim model would have at least 4 entries.

Btw, the "product subcode" 0x8F and 0x90 with the arcade keys (in theory) are 2 unknown motherboards, but are 4 different "platform ID". Lets say... if one of them is named XXX-001 and the other YYY-001 we have this 4 combinations:
XXX-001 (NOR) <---- platform ID = 1
XXX-001 (eMMC) <-- platform ID = 2
YYY-001 (NOR) <---- platform ID = 3
YYY-001 (eMMC) <-- platform ID = 4

Is a bit shocking that are not mentioned in the list of platform IDs of retail syscon firmwares, is making me wondering if this devices uses the value "platform ID" at all... or if are using some kind of special syscon because the syscon firmwares we have cant identify them, right ?... unless they are doing that trick with the "hardcoding" and the hex value is shared

I don't think there're 4 combinations for the special 0x8F and 0x90, typically Sony only uses NOR units internally. Could also be NAND, that's not tied to the product sub code. I would say the Platform ID gets overwritten or is just shared with some other board. Someone would have to reverse what Sony added in firmware 4.31, I think that would help identifying the hardware change.

Also, the arcade keys are making me think that maybe this was reserved to create farms of PS3's for internal use to create the server infrastructure of the "PS Now" service (to stream PS3 games by network)

Maybe, we know that Gnome is related to that as well. There was a special 2.00 firmware for server virtualization. The Zego unit is actually based on the DECR-1000 and the "PS Now" device is based on the Zego.

 

The current version of https://github.com/bucanero/psl1ghtv2_ports/releases/tag/v1.0.1 is broken, I've posted the newest version of my tool somewhere, I'd need to patch it into the older toolset so we'll get working pkg. Or we wait until bucaneros toolchain is fixed.

I have fixed it some time ago, I didn't release a new version, I just replaced the .pkg with a working one. I tested the .pkg on Rebug 4.84 (CEX), and the Toolset GUI launches as expected. I didn't compile or rebuild any of the tool.self because those were working fine.

Have you tried the new .pkg? just re-download it and delete the old one, it should work.

 

I have fixed it some time ago, I didn't release a new version, I just replaced the .pkg with a working one. I tested the .pkg on Rebug 4.84 (CEX), and the Toolset GUI launches as expected. I didn't compile or rebuild any of the tool.self because those were working fine.

Have you tried the new .pkg? just re-download it and delete the old one, it should work.

I didn't knew that you replaced the .pkg, the new version works fine .