PS3 4.89 Jailbreaking - PS3 CFW (Custom Firmware Capable Models) Status + Warnings

[NiQ]

Do you know about any additional checks to prevent you from downgrading to lower firmware version that is >= 3.56 and officially signed? My idea was to still allow the user to do the flash, but only in the case that the target version is >= minver and hash-checked against a list of official ones..

My guess is metldr may have the initial firmware version (which it had when it left the factory) hardcoded and will not boot anything lower. I'm pretty sure some people already tried flashing older firmware using hardware flashers and ended with a brick.

Still, I wonder whether it'd be possible to just take an old firmware and replace its reported version number to something like 9.99, resign and flash.

 

[kostirez1]

My guess is metldr may have the initial firmware version (which it had when it left the factory) hardcoded and will not boot anything lower. I'm pretty sure some people already tried flashing older firmware using hardware flashers and ended with a brick.

Still, I wonder whether it'd be possible to just take an old firmware and replace its reported version number to something like 9.99, resign and flash.

Yes, every console checks if the firmware version is equal or higher than the minimum supported one. There are additional reasons for it than just security - some CELL or RSX revisions got support only in later versions. Look for information about "Frankenstein PS3", where they replace the old 90nm RSX in Fat models with ones from Slim/Super Slim.

It is possible that even if you bypassed minver check during boot on Super Slim and flashed 2.16, it wouldn't boot anyway. It's very unlikely that 28nm RSX is supported by that firmware.

You can do the resign stuff with old metldr, but not with metldr.2, as the keys that were previously leaked (due to weak cryptography) have changed. It is currently understood that the new keys were generated and protected properly, so it is unlikely that we will ever get a hold of them.

 

[STLcardsWS]

I doubt at this point bgtoolset will ever be coming back.

Well, I have no doubt it will be back .

 

[RoboKing's Cosmos]

No. The flasher algorithm checks for metldr.2 and should halt if it's detected in flash.

So does that mean it is 3.56+ minimum firmware? And do you have plans to implement those once enough testers are in position? I've heard there was a partial breach of metldr2 and that some keys were used in the superior original bgtoolset until the chain of trust came to place in 3.60.

 

[aldostools]

So does that mean it is 3.56+ minimum firmware? And do you have plans to implement those once enough testers are in position? I've heard there was a partial breach of metldr2 and that some keys were used in the superior original bgtoolset until the chain of trust came to place in 3.60.

3.60 keys are still secure, therefore it is still not possible to jailbreak any console using metldr2.
To avoid a potential brick, the current software flashers should abort if metldr2 is detected in ROS region.

 

[kostirez1]

Do you know about any additional checks to prevent you from downgrading to lower firmware version that is >= 3.56 and officially signed? My idea was to still allow the user to do the flash, but only in the case that the target version is >= minver and hash-checked against a list of official ones.

So apparently this is not possible. Syscon supposedly keeps hashes and firmware versions of ROS regions in its own EEPROM and prevents PS3 from booting if a mismatch is detected. The only way to downgrade is therefore toggling QA flags (impossible on metldr.2 and HEN) and using the official firmware update process.

Sources: littlebalup, bguerville, Joonie

 

[RoboKing's Cosmos]

the best way was teensy 4.0 but i'm not willing to get involved in more personal problems if i attempt again, either way.

 

[RoboKing's Cosmos]

So apparently this is not possible. Syscon supposedly keeps hashes and firmware versions of ROS regions in its own EEPROM and prevents PS3 from booting if a mismatch is detected. The only way to downgrade is therefore toggling QA flags (impossible on metldr.2 and HEN) and using the official firmware update process.

Sources: littlebalup, bguerville, Joonie

Exploit-Writeups/lv0ldr-spi-mitm.md at main · MikeM64/Exploit-Writeups (github.com)

 

[Classified]

Hey guys any updates about bgtoolset?

 

[kostirez1]

Hey guys any updates about bgtoolset?

No, but if it makes your day any better, alternatives are in the works and will be ready for testing soon.

 

[GuilloteTesla]

No, but if it makes your day any better, alternatives are in the works and will be ready for testing soon.

View attachment 39217

Oh, this is very nice!.

One question though. On which console are you testing this?. Because in the screenshot it states that it is a NAND chip with minFW 4.46, which is imposible as the last NAND console is model CECHG and that came with minFW is 1.90 or 2.30 (depending on revision).

Maybe it's just a placeholder for development purposes, but that caught my attention.

Keep up the good work!.

 

[kostirez1]

Oh, this is very nice!.

One question though. On which console are you testing this?. Because in the screenshot it states that it is a NAND chip with minFW 4.46, which is imposible as the last NAND console is model CECHG and that came with minFW is 1.90 or 2.30 (depending on revision).

Maybe it's just a placeholder for development purposes, but that caught my attention.

Keep up the good work!.

Super Slim eMMC models actually reuse flash layout from old NAND based models, so it behaves the same.

 

[Classified]

No, but if it makes your day any better, alternatives are in the works and will be ready for testing soon.

View attachment 39217

Thanks, it definitely did make my day. Finally something good after waiting all these months

 

[GuilloteTesla]

Super Slim eMMC models actually reuse flash layout from old NAND based models, so it behaves the same.

Oh really?, didn't know that. Quiet interesting because I thought that Sony learned the lesson on using more faster, robust NOR chips than NAND, as the former type is easier to give service.

Maybe it's just an internal memory table design/location/handling strategy that they'd implemented.

 

[STLcardsWS]

Hey guys any updates about bgtoolset?

There is light at end of the tunnel, it's coming back, the project is not canceled.
Good things come to those with a bit of patients.

 

[NiQ]

There is light at end of the tunnel, it's coming back, the project is not canceled.
Good things come to those with a bit of patients.

Even if it does, I don't think we can afford not to have a backup method.

 

[kostirez1]

Even if it does, I don't think we can afford not to have a backup method.

What makes you think there won't be any?

 

[RoboKing's Cosmos]

No, but if it makes your day any better, alternatives are in the works and will be ready for testing soon.

View attachment 39217

Have you tested it on beta HEN?

 

[NiQ]

What makes you think there won't be any?

Well, it was the disappearance of bgtoolset that prompted the current effort in the first place.

 

[kostirez1]

Have you tested it on beta HEN?

Not my concern for now. It doesn't make sense to speculate what features make it to the next release of PS3HEN or not. Hopefully there won't be any changes breaking backwards compatibility, so it's only a matter of adding it to whitelist. We will see when it comes out.

Well, it was the disappearance of bgtoolset that prompted the current effort in the first place.

This comes to supply and demand. At the time when BGToolset had 100% uptime, there was no demand for alternatives. Now that it is not the case anymore, it became worthwhile to make alternatives that are using different exploits and work offline. Simple as that.

I don't think there was anyone who thought: "Hey, let's make something inferior and harder to use", given that BGToolset requires almost no setup and runs more or less on "autopilot".