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

1200px-SYSCON_GEN1.JPG

  • 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
 
Last edited:
Dumping nvs with python 2.7.18 and script didn't work for me. Tried to add this script on the end of original released and somehow got counting address 40 by 40 then file was empty. Tried few hours. Windows 7x64 fresh install. Probably a complete py file with full script would be released?
Could I get some help with it please? Thank you for your efforts.

If you're talking about the SW script, you can see that it has no error handling, so if something fails it won't tell you and there will be nothing written to the file. The CXR script does have the full error handling.

The "command()" command always returns a tuple, let's call it ret. ret[0] is the status code, if that's 0 everythings ok, else it's an error. ret[1] contains a list of the the return values (in this example EEP GET only returns on thing (data) so it's just ret[1][0]).
 
could even be with the microphone serial port that was used in the old days
I have another question, psp test tool firmwares cannot be installed on the slims, only fat, there is a test tool installer 6.60TT-A (Pandora battery) with syscon exploitation, you can install on slims, go etc?
 
Has anyone tried comparing the HDMI related sections of a DEX consoles syscon with a CEX consoles syscon to see if HDCP can be disabled?

That would be a cool patch to include in CFW going forward, if it was possible

It's the same, the HDMI controller is different though (the retail variant can't turn HDCP off).

@sandungas here is proper dump of nvs (you can only obtain this with working chip and EEP command), check if temperature table is there!
Here's the full eeprom from a SW-301 (dumped using a patched firmware): https://workupload.com/file/tr3aFnmP9gX . The NVS starts at 0x0, the SNVS starts at 0x3000.

Also, here's the complete SW2-301 ROM (the boot block was incomplete in the previous dump):
 

Attachments

Last edited:
Last edited:
@M4j0r the missing bytes inside the thermal config area with values 33FF0011FF (for minduty, maxduty, policy, select, active) doesnt matters ?
A plain rom dump doesn't represent the EEPROM content, since it's emulated. I've already shared the correct EEPROM dump.
 
Last edited:
I meant... in some of the previous SW dumps (as far i remember uploaded to the forum by zeco) the 2 active fantables contains the 33FF0100FF, and the inactive fantable contains the 33FF010000
When i saw it i thought that was correct, because are the same values used in previous syscon models, we are used to them, also it allowed me to find his position
But in some other dumps that values doesnt exists (are replaced by FF's)

That difference is making me doubt about the real values of minduty, maxduty, policy, select, active for each fantable
 
I meant... in some of the previous SW dumps (as far i remember uploaded to the forum by zeco) the 2 active fantables contains the 33FF0100FF, and the inactive fantable contains the 33FF010000
When i saw it i thought that was correct, because are the same values used in previous syscon models, we are used to them, also it allowed me to find his position
But in some other dumps that values doesnt exists (are replaced by FF's)

That difference is making me doubt about the real values of minduty, maxduty, policy, select, active for each fantable

Only these are valid eeprom dumps:
- SYSCON Firmware key is now public (release by zecoxao) - What does it mean?
- SYSCON Firmware key is now public (release by zecoxao) - What does it mean? (the linked file)

The plain rom which is dumped from the chip doesn't contain the plain eeprom, you need to dump the eeprom using the read commands. It will be constructed from the data on the ROM (but differs in some areas).
 
Sorry for my previous imprecissions, i will try to explain more accuratelly what is confusing me
Yes, thats the file i meant (and belongs to a VER-001 motherboard, right ?), in it we can see the values 33FF0100FF (for active fantables), and the value 33FF010000 (for inactive fantables) used exactly like in all the previous syscon dumps from the CXR series

This is the first fantable (active), with the 33FF0100FF located at his bottom
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000250  33 44 00 00 00 39 45 00 39 00 3B 46 00 39 80 3E  3D...9E.9.;F.9€>
00000260  47 00 3A 00 40 48 00 3A 80 43 4C 00 40 00 45 50  G.:.@H.:€[email protected]
00000270  00 44 00 48 51 00 44 80 4A 52 00 45 00 50 53 00  .D.HQ.D€JR.E.PS.
00000280  45 80 55 54 00 46 00 5A 55 00 46 80 66 56 00 47  E€UT.F.ZU.F€fV.G
00000290  00 80 57 00 48 00 99 58 00 4F 80 FF 5B 00 50 00  .€W.H.™X.O€ÿ[.P.
000002A0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000002B0  FF FF FF FF 33 FF 01 00 FF FF FF FF FF FF FF FF  ÿÿÿÿ3ÿ..ÿÿÿÿÿÿÿÿ

This is the second fantable (active), again with the 33FF0100FF located at his bottom
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000002C0  33 50 00 00 00 39 51 00 45 00 3B 52 00 45 80 3E  3P...9Q.E.;R.E€>
000002D0  53 00 46 00 40 54 00 46 80 43 55 00 47 00 45 56  [email protected]€CU.G.EV
000002E0  00 47 80 48 57 00 48 00 4A 58 00 48 80 50 59 00  .G€HW.H.JX.H€PY.
000002F0  49 00 55 5A 00 49 80 5A 5B 00 4A 00 66 5C 00 4A  I.UZ.I€Z[.J.f\.J
00000300  80 80 5D 00 4B 00 99 5E 00 51 80 FF 61 00 52 00  €€].K.™^.Q€ÿa.R.
00000310  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000320  FF FF FF FF 33 FF 01 00 FF FF FF FF FF FF FF FF  ÿÿÿÿ3ÿ..ÿÿÿÿÿÿÿÿ

And this is the third fantable (inactive), with the 33FF010000 located at his bottom
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000330  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000340  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000350  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000360  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000370  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000380  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000390  FF FF FF FF 33 FF 01 00 00 FF FF FF FF FF FF FF  ÿÿÿÿ3ÿ...ÿÿÿÿÿÿÿ

When i realized about it i thought... ok, so minduty, maxduty, policy, select, active seems to work exactly the same in CXR and SW syscon series
So... when i made the coordinate graph image for VER-001 i represented them as usual
https://www.psx-place.com/threads/syscon-fan-settings-coordinate-graphs.31188/#post-259669
XAn19oK.png


But in this one that values doesnt exists (this is a DYN-001 motherboard, right ?)

The first fantable (active, but the values for minduty, maxduty, policy, select, active doesnt exists)
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000A0250  33 35 00 00 00 39 36 00 2F 00 3B 37 00 31 00 3E  35...96./.;7.1.>
000A0260  38 00 31 80 40 39 00 33 80 43 3A 00 34 00 45 3B  8.1€@9.3€C:.4.E;
000A0270  00 36 80 48 45 00 37 00 4A 46 00 3D 80 50 49 00  .6€HE.7.JF.=€PI.
000A0280  3E 00 55 4A 00 3E 80 5A 4B 00 3F 00 66 4C 00 3F  >.UJ.>€ZK.?.fL.?
000A0290  80 80 4D 00 40 00 B3 4E 00 41 00 FF 55 00 46 00  €€M.@.³N.A.ÿU.F.
000A02A0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A02B0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

The second fantable (active, but the values for minduty, maxduty, policy, select, active doesnt exists)
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000A02C0  33 4E 00 00 00 39 4F 00 42 80 3B 50 00 43 00 3E  3N...9O.B€;P.C.>
000A02D0  51 00 43 80 40 52 00 44 00 43 53 00 44 80 45 54  Q.C€@R.D.CS.D€ET
000A02E0  00 45 00 48 55 00 45 80 4A 56 00 46 00 50 57 00  .E.HU.E€JV.F.PW.
000A02F0  46 80 55 58 00 47 00 5A 59 00 47 80 66 5A 00 48  F€UX.G.ZY.G€fZ.H
000A0300  00 80 5B 00 48 80 B3 5C 00 4A 00 FF 5F 00 52 00  .€[.H€³\.J.ÿ_.R.
000A0310  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0320  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

The third fantable (inactive, but the values for minduty, maxduty, policy, select, active doesnt exists)
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000A0330  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0340  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0350  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0360  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0370  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0380  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000A0390  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

When i was doing the coordinate graph images and i realized about this missing values i thought that was something a bit weird and i was not sure why it happened (at that point you was mentioning the dumped data was "reconstrusted" and i was not sure how this reconstruction works)
But based in the layout from the VER-001 i knew where was supposed to be located... and based in his meaning from all previous syscon dumps i knew what they means (because you identifyed them)... so i decided to add them in my image and ask to you later about it
https://www.psx-place.com/threads/syscon-fan-settings-coordinate-graphs.31188/#post-259670
g6WvMwt.png


My question is... should i rebuild that image for DYN-001 replacing the value 33FF0100FF (for the 2 active fantables) and 33FF010000 (for the inactive fantable) by FF's ?

Im trying to do all that images with the biggest precission posible and adding all the info posible we have... i dont mind to edit them, actually i count with it because all the previous images i made contains some values labeled as "unknown", if someone identifyes that unknown values eventually i will rebuild all them
 
Last edited:
My question is... should i rebuild that image for DYN-001 replacing the value 33FF0100FF (for the 2 active fantables) and 33FF010000 (for the inactive fantable) by FF's ?

You can't just "rebuild" them, it's a complex process which needs to be reversed first, the actual mapping is done using huge tables which are bigger than the actual NVS (and I just use the read/write commands).
Both the dumps:
- SYSCON Firmware key is now public (release by zecoxao) - What does it mean? (DYN-001)
- SYSCON Firmware key is now public (release by zecoxao) - What does it mean? (VER-001)
have been correctly dumped - that's how the syscon sees them.
 
You can't just "rebuild" them, it's a complex process which needs to be reversed first, the actual mapping is done using huge tables which are bigger than the actual NVS (and I just use the read/write commands).
Both the dumps:
- SYSCON Firmware key is now public (release by zecoxao) - What does it mean? (DYN-001)
- SYSCON Firmware key is now public (release by zecoxao) - What does it mean? (VER-001)
have been correctly dumped - that's how the syscon sees them.
When i said "rebuild" i mean to modify the image in photoshop this way:
v92FrOj.jpg
 
Last edited:
We only had the chip, a SW3-304, the "platform id" is CokP10, so one of the boards used in the CECH-42xx. According to the wiki CokP40 is the PPX-001, so I would guess CokP10 is NPX-001.
Thx, this clarifyes a lot what we have, it seems CokM30 (for MPX-001) and CokP40 (for PPX-001) was reported by @littlebalup so i guess are right, and are "surrounding" that theoretical CokP10
So the only posible candidate for CokP10 seems to be NPX-001, unless you got that syscon chip from a rare PS3 prototype :D

Im trying to consider all posible alternatives but yeah i would bet thats right, CokP10 "should be" NPX-001
 
Hey guys,

I looked through a list of UART Syscon commadns and found one that seems to shows the actual SB tmperature.

I talked to Aldotools on github, to add it to webman mod https://github.com/aldostools/webMAN-MOD/discussions/474

He said he would easiely do it but don't know the code for it or something, Im not really into it, for further information check out the link to github.

Is here anybody that got the time and effort to help "us" out to realise this feature?
 
Hey guys,

I looked through a list of UART Syscon commadns and found one that seems to shows the actual SB tmperature.

I talked to Aldotools on github, to add it to webman mod https://github.com/aldostools/webMAN-MOD/discussions/474

He said he would easiely do it but don't know the code for it or something, Im not really into it, for further information check out the link to github.

Is here anybody that got the time and effort to help "us" out to realise this feature?

You have to communicate with syscon via CELL, if you want to know SB temperature, when using webman. a few examples are shown here:

https://psdevwiki.com/ps3/SC_Communication
https://psdevwiki.com/ps3/Talk:SC_Communication
 

Featured content

Trending content

Latest posts

Back
Top