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:
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?
I think is just needed to use the correct id of the thermal sensor, i was brainstorming about it in this post and other forum posts
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-12#post-227211

The syscalls should be the same, is just we are only using the id's of the first 2 sensors (but sensor 3 doesnt exists, and southbridge seems to be id 4)
 
I think is just needed to use the correct id of the thermal sensor, i was brainstorming about it in this post and other forum posts
https://www.psx-place.com/threads/s...o-what-does-it-mean.26148/page-12#post-227211

The syscalls should be the same, is just we are only using the id's of the first 2 sensors (but sensor 3 doesnt exists, and southbridge seems to be id 4)

thx for your reply, I will give that information to Aldotools. hope this will help him out :)


IS there also a way to show the EE+GS Temp in any kind? I know there is a PS2 App https://www.ps2-home.com/forum/viewtopic.php?t=8750 that allows to see the EE+GS Temps, but it only supports mechacon until 500+ Tested it on my PS2 3000x, does not work cause it uses mechacon x300 and the EE+GS on COK-001 using mechacon 309, so would be both nice, to make it compatible to ps2 older mechacons and in same way also for ps3 automatically. after this would be great to implement this feature in a moded netemu or HW BC ps3's in any kidn to see the temps without booting this ps2 homebrew. I never managed to start ps2 homebrews on ps3 don't know how.

Im a big freak about all this temperature and airflow thing ^^
 
Last edited:
thx for your reply, I will give that information to Aldotools. hope this will help him out :)
Dont worry, we was talking about it before, in some posts on this forum i dont remember the link now sorry

The problem is we dont have access to the syscon commands (the commands that can be seen from the UART terminal) from gameOS
As far i understood is posible to install a syscon patch (using the oficial patch format) that contains an exploit that unlocks access to syscon commands... but as far i know the info required to implement this exploit has not been released yet
So we cant use the command tsensor 3 mentioned by XestoX in the github link you posted

In the meantime the only thing we have are the syscalls, the same ones used to get the actual cell and rsx temperatures and fan speed, but using the sensor ID=3
It seems the sensors are given an ID starting by 0... so CELL is ID=0... RSX is ID=1... the ID=2 doesnt exists... and ID=3 seems to be the southbridge (is the fourth sensor)
 
This should not be easy because is not an universal location in syscon, it is different from models of sb, may work on similar syscon or same syscon, each model should have different setup. I may be wrong.
 
Aldotools tryed some things out: I will simply give you that information cause I have totaly no idea about this coding stuff, I would love to be able to help much more , Im more the soldering guy ^^

source: https://github.com/aldostools/webMAN-MOD/discussions/474
Interesting, @aldostools i think that test using unknown ID's (different than 0 and 1) should be made first with the oldest PS3 motherboard models

Keep an eye at how i "splitted" the hexadecimal view of the "thermal config" eeprom areas in this images
The weird thing is the way how the data is ordered inside the "thermal config" area of COK motherboards, it was intended to store settings for 6 "input" sensors... and there is valid data for 3 of them

Let me make a pause to mention something a bit conceptual, this is something i deduced from myself but i dont have any confirmation from @M4j0r or @zecoxao that what im going to say is correct, we had some talks in previous posts of this same thread because we was not sure why there are several fantables that seems to be active, but think in it this way. The main purpose of the "thermal config" area is to:
1) get samples from the sensors (several inputs)
2) run some logic functions with the inputs and the settings
3) set the signal to the fan (a single output)

So we have several inputs (thermal sensors, always more than 1) but only 1 output (the fan)
This is why there are several tables inside the "thermal configs" that seems to be active, because the fan speeds depends of all that sensors, the syscon is monitoring several sensors on runtime and the "hottest" one is going to be the responsible of the resulting fan speed

Ok, back to what i was mentioning about how is splitted the data inside the "thermal config" areas, when i made that images i assumed the first fantable is for CELL (because is more important, also because his temperature values are always smaller than the second fantable), i assigned the blue color for CELL in my images (and red for RSX)
But... there was another more fantable active in COK and SEM motherboards (i gave it color green in my images)... initially we thought it was BEVR (a theoretical thermal sensor located close to the CELL BE Voltage Regulator/s)... but after thinking more in it... i assumed is southbridge, mostly because is the "hottest" component in that motherboards after CELL/RSX


------------
Long story short... the "thermal config" from COK and SEM motherboards contains an additional fantable for a thermal sensor that seems to be southbridge
But the "thermal config" of the other PS3 motherboard models doesnt contains a fantable for it... maybe this indicates that syscon is not even monitoring the southbridge sensor

In other words... maybe your test code (where you tryed different ID's than 0 or 1) could work in a COK or SEM motherboard
But it was not working for you because you dont have a COK or SEM motherboard ?
 
Can someone help me to find location of metldr2 ?Any explained addreses wold be appreciated .Which version should i work with 16,32,64?

http://s.go.ro/cndeo8w9

I would try to brick few ss, patching only core os won't be enough for downgrade to min version of factory, I am interested only for ofw test looking inside pup files tried to understand bd drive fw and syscon fw version. I tried to understand simple and easy way what address I should exchange if I want to swap bd drive ic between same boards.
 
Last edited:
Can someone help me to find location of metldr2 ?Any explained addreses wold be appreciated .Which version should i work with 16,32,64?

http://s.go.ro/cndeo8w9
metldr.2 is encrypted with a perconsole key located in CELL, which by itself runs at 3.2GHz, part of the secure design implemented by IBM (not even AMD thought of making SAMU run at this speed for the secure boot process). to decrypt the metldr.2 you'd need a very expensive oscilloscope and knowledge of DPA/DFA attacks, or to decap it and analyse it via SEM (scanning electronic microscope) which, again, is something that costs a few thousand dollars. the scene made metldr dumping possible thanks to a failure in the implementation of the system (you can take a look at the bug in the wiki: https://psdevwiki.com/ps3/Dumping_Metldr

It MIGHT be possible to dump metldr again in its newer form, but for that we need a lv1 bug to achieve code execution at hypervisor level. Luckily, several tools are available (ghidra and latest leaked ida) which help the process a lot, but in the end, it's up to the hackers to find a vulnerability, if it exists
 
metldr.2 is encrypted with a perconsole key located in CELL, which by itself runs at 3.2GHz, part of the secure design implemented by IBM (not even AMD thought of making SAMU run at this speed for the secure boot process). to decrypt the metldr.2 you'd need a very expensive oscilloscope and knowledge of DPA/DFA attacks, or to decap it and analyse it via SEM (scanning electronic microscope) which, again, is something that costs a few thousand dollars. the scene made metldr dumping possible thanks to a failure in the implementation of the system (you can take a look at the bug in the wiki: https://psdevwiki.com/ps3/Dumping_Metldr

It MIGHT be possible to dump metldr again in its newer form, but for that we need a lv1 bug to achieve code execution at hypervisor level. Luckily, several tools are available (ghidra and latest leaked ida) which help the process a lot, but in the end, it's up to the hackers to find a vulnerability, if it exists
Well looking at pup file we could try revive something like cobra on hardware via sata line that could help. Looking at rest of apps they still act as games, which they come from bd drive emulation in simple words. I don't say its simple. Not an easy install for end users just experimental purposes only to revive an old cobra pcb emulator in new ofw. I still have one since 2014 when they uploaded 4.60 and stopped to work from there. Not sure atm at studi level.
Not sure if an mfw will be good enough and if so I could probably compare only bd fw or not and may be tied to rest of unknown files in entire fw.
Decompressed few files inside hfw
http://s.go.ro/67klqmlw
Why cobra because it was only hardware that was working with metldr2 up to the point 4.6fw
 
Last edited:
metldr.2 is encrypted with a perconsole key located in CELL, which by itself runs at 3.2GHz, part of the secure design implemented by IBM (not even AMD thought of making SAMU run at this speed for the secure boot process). to decrypt the metldr.2 you'd need a very expensive oscilloscope and knowledge of DPA/DFA attacks, or to decap it and analyse it via SEM (scanning electronic microscope) which, again, is something that costs a few thousand dollars. the scene made metldr dumping possible thanks to a failure in the implementation of the system (you can take a look at the bug in the wiki: https://psdevwiki.com/ps3/Dumping_Metldr

It MIGHT be possible to dump metldr again in its newer form, but for that we need a lv1 bug to achieve code execution at hypervisor level. Luckily, several tools are available (ghidra and latest leaked ida) which help the process a lot, but in the end, it's up to the hackers to find a vulnerability, if it exists

a hacker by the name of modrob was using this method to dump metldr2. I don't know what happened with it though.
 
As there is no no answer for questions on cobra ode hardware I have to test myself and find out.
Deleted out of topic questions.
 
Last edited:
Hola, espero que toda la comunidad de ps3 pueda hacerlo superdelgado, estamos muy contentos, una pregunta, ¿podemos desbancar con cfw? jugar unline? Me refiero a desbancar los idps y psid.
¿Qué hay de nuevo en el syscoon?

Desbanear sorry

English:
Hi, I hope the whole ps3 community can make it super slim, we are very happy, one question, can we unseat with cfw? play unline? I mean unseat the idps and psid. What's new in the syscoon?

unban sorry
 
Last edited by a moderator:
Hola, espero que toda la comunidad de ps3 pueda hacerlo superdelgado, estamos muy contentos, una pregunta, ¿podemos desbancar con cfw? jugar unline? Me refiero a desbancar los idps y psid.
¿Qué hay de nuevo en el syscoon?

Desbanear sorry

English:
Hi, I hope the whole ps3 community can make it super slim, we are very happy, one question, can we unseat with cfw? play unline? I mean unseat the idps and psid. What's new in the syscoon?

unban sorry
please remember to either write in English or provide a translation :)

super slim can change IDPS using "webMAN MOD".
 
Hello I have a ps3 model 3001A and I have a failure in the wifi module therefore I can not update it, is there any way either a file that skips that of the module.
There are no technicians in my region to fix the module, thanks :)
 
Hello I have a ps3 model 3001A and I have a failure in the wifi module therefore I can not update it, is there any way either a file that skips that of the module.
There are no technicians in my region to fix the module, thanks :)
Your model is not CFW compatible therefore you cannot make permanent changes to the system files without bricking or use customised PUP files.

When hardware like BT, WiFi or BD is malfunctioning, you are usually stuck at your current firmware as the update procedure fails & that can only be remedied on CFW compatible consoles.

Maybe one day CFW support will be brought to 3xxx & 4xxx models & you will be able to bypass the wifi checks but you may wait a long time for it & a dead WiFi usually impacts the OS in multiple ways, wifi issues often means generalised network issues & servers like webMAN-MOD cannot work etc..
 
@zecoxao
I wish to help but need to understand exactly procedure for dumps.
Not very familiar with all informations on devwiki.
I have buspirate 3v6 with his stock firmware (untouched).
Now dumped one faulty dia002 with syscon on board using alternative points. The only dump was made with Syscon flasher program. Putty did not work for me as mentioned in devwiki (all 0x00) at command [0xA8 0x00 0x00 r:32768].
I may be dumb but kind understand I have to dump syscon on board or outside? What schematic exactly for buspirate ? What else need to be done when syscon is out of board to be powered simple by 3v3 from buspirate? Then check with developers here if is good or not, then flash a patched dump with syscon out of board, solder syscon back and at the moment of power it will show up the ROM data of 512k over UART?
Realterm or can be putty? Which UART? SB or syscon?
 
Last edited:
@zecoxao
I wish to help but need to understand exactly procedure for dumps.
Not very familiar with all informations on devwiki.
I have buspirate 3v6 with his stock firmware (untouched).
Now dumped one faulty dia002 with syscon on board using alternative points. The only dump was made with Syscon flasher program. Putty did not work for me as mentioned in devwiki (all 0x00) at command [0xA8 0x00 0x00 r:32768].
I may be dumb but kind understand I have to dump syscon on board or outside? What schematic exactly for buspirate ? What else need to be done when syscon is out of board to be powered simple by 3v3 from buspirate? Then check with developers here if is good or not, then flash a patched dump with syscon out of board, solder syscon back and at the moment of power it will show up the ROM data of 512k over UART?
Realterm or can be putty? Which UART? SB or syscon?

M4j0r will guide you through it.
 
Back
Top