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

[RoboKing's Cosmos]

Dear NiQ,
95% of the users can do with HEN what they would do with CFW. Very few features require CFW.
Only if you're a developer CFW is a must for certain features like DEX, Linux, LV1 peek/poke, etc.

Russian clone may have worked for some users but it is VERY DANGEREOUS to use. It's not me who said that. It was bguerville and NOBODY knows bgtoolset more than him. However, if a PS3 user wants to take the risk and brick their console, nobody can prohibit to do it. We only are providing responsible warnings; unlike the flasher clones that don't give any warning or support after a brick.

The Web Flasher in webMAN MOD is a work in progress... it's still far to be ready to public beta tests.
Currently only people with hardware flashers are accepted. So far, except @kostirez1, @bucanero and @littlebalup, nobody else has shown serious interest in the project.

It will be open when it's ready. The source code is open for anyone that want to review it.
And we will be happy to answer any questions by developers and testers interested.

Was it beta tested on a nand fat ps3? Or just the fat/slim nor?

 

[kostirez1]

Was it beta tested on a nand fat ps3? Or just the fat/slim nor?

From my testing with NAND and NOR images written to USB storage (read/write syscalls redirected to different device ID), it does produce satisfying results. At least when assuming that it's always constrained to sectors used by ROS0/ROS1, and that PyPS3checker has enough checks to detect corruption in ROS regions. This code was tested on both CFW and HEN, always writing laser precise patches.

That said, 4.89 HEN (Fat, CECHK, NOR) hanged on the first attempt to patch the actual flash, right at the start. Not that the whole console would crash, just the thread froze, never reaching the first checkpoint at sector 1433. I then tried to restore the contents with my modified clone of BGToolset. That also failed, since there can only be one handle per device with sys_storage_open(), and that one was still held by webMAN. The only option then was to reboot and pray that the currently active ROS wasn't the first one. I knew that sys_storage_write() went through at least once, leaving the contents in an unknown state. One reboot later - the console is bricked.

The question now is why did it freeze? My only guess is that writing 1 sector at a time (512 bytes) is a bad idea in this case, since it results in 14336 calls to sys_storage_write() per ROS region. BGToolset writes 2048 sectors (1 MiB) per call, lowering the number of syscalls just to 7. WebMAN (running under VSH) doesn't have this luxury, unfortunately, as it's constrained to a small memory segment to begin with. The highest reasonable amount of memory you can allocate is 128 KiB or 256 KiB, resulting in 56 or 28 calls. Is this low enough to not freeze the thread? I can only figure this out by testing it.

At least this experience gave us more ideas for checks before writing to critical NAND/NOR regions. The first one that comes to mind is to look for currently active ROS in Syscon's EEPROM. There were some talks about this by @bguerville, @sandungas and @M4j0r a year ago. Not sure what the end result was, or if it would even be possible with limitations of HEN. Another idea is to write a few sectors at the end of ROS region's padding first, checking if writes to the flash work or not. Is ROS checksumed on boot? Can't tell at this moment, I'm still waiting for that E3 flasher to arrive.

 

[GuilloteTesla]

At least this experience gave us more ideas for checks before writing to critical NAND/NOR regions. The first one that comes to mind is to look for currently active ROS in Syscon's EEPROM. There were some talks about this by @bguerville, @sandungas and @M4j0r a year ago. Not sure what the end result was, or if it would even be possible with limitations of HEN.

If my memory doesn't fail me, there is a sector that specifies which ROS bank to use, ROS0 or ROS1. The most simple approach would be:

1. Install HFW twice in order to have both ROS banks consistent.
2. Apply the patch to ROS1.
3. Check if ROS1 is correct.
4. Reboot the console and validate that it is not bricked.
5. If console isn't bricked, modify the ROS bank in use with another patch.

I think this approach would be the safest without having an E3 flasher or recovery tool at hand.

 

[kostirez1]

If my memory doesn't fail me, there is a sector that specifies which ROS bank to use, ROS0 or ROS1.

Yes, it should be possible to access that value with syscall sys_ss_update_manager(), using the parameter 0x600B (Read EPROM) of Update Manager service. The currently selected ROS should be the byte at 0x48C24. Update Manager doesn't allow you to read that offset by default, though. It only accepts some whitelisted ranges, and I'm not exactly sure if you can patch UM on HEN.

The most simple approach would be:

1. Install HFW twice in order to have both ROS banks consistent.
2. Apply the patch to ROS1.
3. Check if ROS1 is correct.
4. Reboot the console and validate that it is not bricked.
5. If console isn't bricked, modify the ROS bank in use with another patch.

I think this approach would be the safest without having an E3 flasher or recovery tool at hand.

There's no way to know which ROS is currently used at step 2, so it shouldn't matter if you pick ROS0 or ROS1. The risk is the same for both (50%/50%). 100% in real life due to Murphy's law.

Step 5 is doable in theory, I was able to change that byte to the unused ROS using Syscon's UART. It still didn't boot though, same problem that @poot36 reported here: https://www.psx-place.com/threads/f...and-error-reporting.30100/page-99#post-315215

The conversation about sys_ss_update_manager() patches is here btw: https://www.psx-place.com/threads/release-ps3-advanced-tools.34104/page-3#post-313614

 

[GuilloteTesla]

There's no way to know which ROS is currently used at step 2, so it shouldn't matter if you pick ROS0 or ROS1. The risk is the same for both (50%/50%). 100% in real life due to Murphy's law.

Really?. I know that the flash has a flag which specifies which ROS region to use everytime, in case of a bad FW update (pretty standard failsafe behaviour when flashing a ROM). I.e. the flag is set to use ROS1 because ROS0 got corrupted, then the console boots everytime with ROS1 until next FW update. I could be wrong as I don't remember how this ROS switching works exactly.

My approach is to keep the ROS0 region clean, patch ROS1, verify it and once everything is OK then switch ROS regions in order to not brick the console.

 

[kostirez1]

Yes, this does make sense, and I also assume that that's how it works with official firmware update process.
There are 3 prerequisites for this to work, though:

1. Obtain full SC EEPROM read access on PS3HEN
2. Obtain full SC EEPROM write access on PS3HEN
3. Figure out how to change the currently active ROS region, so far it's only known how to read its state (changing the flag using UART results in "[SSM] *** FATAL ERROR requested by OS ***", so just writing the flag from PS3HEN is not enough)

Without full read access, there's no way to know which ROS region is used. By installing firmware twice, you only know that you ended up using the same region that was used before installing it the first time.

 

[aldostools]

The question now is why did it freeze? My only guess is that writing 1 sector at a time (512 bytes) is a bad idea in this case, since it results in 14336 calls to sys_storage_write() per ROS region. BGToolset writes 2048 sectors (1 MiB) per call, lowering the number of syscalls just to 7. WebMAN (running under VSH) doesn't have this luxury, unfortunately, as it's constrained to a small memory segment to begin with. The highest reasonable amount of memory you can allocate is 128 KiB or 256 KiB, resulting in 56 or 28 calls. Is this low enough to not freeze the thread? I can only figure this out by testing it.

Yes, it was a bad idea writing 1 sector per cycle. I bricked my PS3 doing that.
The write to flash took over 1 hour and it didn't finish even the first ROS.
To make things worse, I got a power failure and the ROS0 was the active one.
(BTW the write to flash was active by a mistake in the code at the moment of the test)

webMAN MOD can allocate up to 128KiB or 256KiB using the default VSH container.
But using the vsh_memory_container 4-bg, it is possible to allocate up to 3MB using the custom function sys_mem_allocate() found in include/init/vsh.h

In webMAN MOD ros.h allocates 128KB, but it is possible to allocate up to 213MB using the 1-app container, since that process should be executed from XMB.

At least this experience gave us more ideas for checks before writing to critical NAND/NOR regions. The first one that comes to mind is to look for currently active ROS in Syscon's EEPROM. There were some talks about this by @bguerville, @sandungas and @M4j0r a year ago. Not sure what the end result was, or if it would even be possible with limitations of HEN. Another idea is to write a few sectors at the end of ROS region's padding first, checking if writes to the flash work or not. Is ROS checksumed on boot? Can't tell at this moment, I'm still waiting for that E3 flasher to arrive.

There was a recent post (I think it was by Sandungas) confirming that the active ROS is found in SYSCON.

As currently we don't have control of the active ROS, in the initial post of wMM flasher in github I reduced the output to 0x2C80 sectors / 6MB per ROS, for a total of 12MB instead of 14MB. In my tests it should reduce the time in approximately 20 seconds. It probably won't match the checksum, but should overwrite all the non-nulls region in ROS. I added a command line flag to write the full 0x3800 sectors / 7MB per ROS as an option.

The current version of wMM flasher in Github has kostirez1's implementation, that only writes full sectors.

 

[kostirez1]

The write to flash took over 1 hour and it didn't finish even the first ROS.
To make things worse, I got a power failure and the ROS0 was the active one.

So it was a bad idea on my part to pull the power cord after 15 minutes, thinking that the syscall never returned control to my code. But even if it did reach 10% after let's say 20 minutes, we are still talking about (20 minutes per 10%) * (10 times that for 100%) * (2,once for each ROS) = 6 hours and 40 minutes.

it is possible to allocate up to 213MB using the 1-app container, since that process should be executed from XMB.

Is this the virtual memory? Or does it take the space from normal apps/games? I always thought that VSH is restricted to ~18 MiB of real memory.

but should overwrite all the non-nulls region in ROS

Ah, so this was the reason to write only a part of the region. This also means that it should be possible to write some "garbage" to the 0x00 padding right around sectors ~37F0 (3800 is the total length) without the risk of bricking? It makes sense to me to write at least 1 sector with some predictable pattern first, to make sure it won't leave the sector 0 partially written if it crashes for some reason. And possibly a good check for the case that anything related to sys_storage_write() changes in PS3HEN, causing it to not work with flash for any reason.


Edit: So if I understand it correctly, VSH memory container ID 1 does indeed make the allocation in the space meant for games and apps.

Edit2: Looking at the datasheets for NOR and NAND models used in PS3, they all seem to use 128 KiB erase sectors. This means that we should always write multiples of 256 sectors, aligned to 128 KiB boundary. At least for the best performance and flash endurance. Conveniently enough, both ROS regions are aligned on both NAND and NOR layouts.

 

[aldostools]

So it was a bad idea on my part to pull the power cord after 15 minutes, thinking that the syscall never returned control to my code. But even if it did reach 10% after let's say 20 minutes, we are still talking about (20 minutes per 10%) * (10 times that for 100%) * (2,once for each ROS) = 6 hours and 40 minutes.

Definitively it was a bad idea to pull the power cord while the system is writing to flash memory.

Is this the virtual memory? Or does it take the space from normal apps/games? I always thought that VSH is restricted to ~18 MiB of real memory.

Edit: So if I understand it correctly, VSH memory container ID 1 does indeed make the allocation in the space meant for games and apps.

PS3 uses memory containers for different purposes.
https://www.psdevwiki.com/ps3/VSH#Memory_Containers

VSH uses 18MiB, memory container ID 1 allow allocate up to 213MiB meant for games/apps, and containers ID 3 and 4 allow allocate 3MB for background/foreground plugins.

Ah, so this was the reason to write only a part of the region. This also means that it should be possible to write some "garbage" to the 0x00 padding right around sectors ~37F0 (3800 is the total length) without the risk of bricking? It makes sense to me to write at least 1 sector with some predictable pattern first, to make sure it won't leave the sector 0 partially written if it crashes for some reason. And possibly a good check for the case that anything related to sys_storage_write() changes in PS3HEN, causing it to not work with flash for any reason.

Yes, but in my code I only was overwriting the non 0x00, since it is irrelevant to overwrite it with 0x00 again.

The initial wMM flasher had a function for verify that compared the read/written data.

Edit2: Looking at the datasheets for NOR and NAND models used in PS3, they all seem to use 128 KiB erase sectors. This means that we should always write multiples of 256 sectors, aligned to 128 KiB boundary. At least for the best performance and flash endurance. Conveniently enough, both ROS regions are aligned on both NAND and NOR layouts.

Writing using large buffers that are multiple of 128KiB should be fasters. But write in chunks of 1 sector / 512 bytes was the same mistake that I made (apart that it was not my intention to write during my test). It was super-slow.

 

[RoboKing's Cosmos]

Definitively it was a bad idea to pull the power cord while the system is writing to flash memory.


PS3 uses memory containers for different purposes.
https://www.psdevwiki.com/ps3/VSH#Memory_Containers

VSH uses 18MiB, memory container ID 1 allow allocate up to 213MiB meant for games/apps, and containers ID 3 and 4 allow allocate 3MB for background/foreground plugins.


Yes, but in my code I only was overwriting the non 0x00, since it is irrelevant to overwrite it with 0x00 again.

The initial wMM flasher had a function for verify that compared the read/written data.


Writing using large buffers that are multiple of 128KiB should be fasters. But write in chunks of 1 sector / 512 bytes was the same mistake that I made (apart that it was not my intention to write during my test). It was super-slow.

Will it be implemented to say ERROR METLDR2 so that someone can't brick their super slim or 3x? like to detect 3.56 or higher.

 

[kostirez1]

Yes, but in my code I only was overwriting the non 0x00, since it is irrelevant to overwrite it with 0x00 again.

That's a nice feature that I missed. Looks like there are at least 11 blocks of 256 sectors filled with 0x00 at the end of each ROS, out of 56 blocks total. Up to ~19.64% block erases and writes saved by that.

It was super-slow.

If my math and assumptions are right, writing it one sector at a time causes PS3 to read, erase and write each 128 KiB erase block 256 times. There are 56 erase blocks for each ROS => 2 * (2 * (128 * 256 * 56)) = 7340032 KiB or 7 GiB in transfers total? No idea how fast can PS3 transfer data to and from NOR flash, but even at 500 KiB/s average we are talking about ~4 hours.

Will it be implemented to say ERROR METLDR2 so that someone can't brick their super slim or 3x? like to detect 3.56 or higher.

Yes, that is the first thing to look for. Now that I think about it, it makes sense to make a dedicated app for flash patching just to fit all currently known checks (not necessarily related only to ROS regions) for people that are really paranoid. At least that would make webMAN MOD codebase less bloated and focused at the bare minimum for patching ROS regions safely.

 

[GuilloteTesla]

Yes, that is the first thing to look for. Now that I think about it, it makes sense to make a dedicated app for flash patching just to fit all currently known checks (not necessarily related only to ROS regions) for people that are really paranoid. At least that would make webMAN MOD codebase less bloated and focused at the bare minimum for patching ROS regions safely.

I would apply every check possible in the flash tool. That way, it will be the safest thing out there (first for the devs, then for the public).

 

[RoboKing's Cosmos]

Out of curiosity can any dev explain the obfuscated keys for firmware 3.60? What use are those? It doesn't look like it's even welcoming anyone to Metldr2 at the moment yet. here is the link: Keys - PS3 Developer wiki (psdevwiki.com)
There's some kinda tool that lets you decrypt a key

 

[aldostools]

Now that I think about it, it makes sense to make a dedicated app for flash patching just to fit all currently known checks (not necessarily related only to ROS regions) for people that are really paranoid. At least that would make webMAN MOD codebase less bloated and focused at the bare minimum for patching ROS regions safely.

The original idea was to take advantage of the existing code base in webMAN MOD for faster development and build a separate flasher edition that would have to be installed for that purpose.

Indeed, it is better to have a dedicated apps that patch the flash. I have talked to @bucanero to include it in his PS3 Advanced Tools, but he doesn't have a hardware flasher needed for the development and testing.

The native app could use tiny3d to show on screen errors, warnings and display the progress in a more friendly way.

 

[kostirez1]

The native app could use tiny3d to show on screen errors, warnings and display the progress in a more friendly way.

I already made some progress using PSL1GHT SDK and message dialogs. Should be able to test it sometimes next week when I get my hardware flasher setup up and running. Tiny3D looks a little complex for me though, I may need someone with enough experience to do the user interface.

I have talked to @bucanero to include it in his PS3 Advanced Tools...

I'm a little bit concerned about outdated/buggy versions of the code lurking on forever. Would it be reasonable to include a "timebomb" to prevent precompiled versions from working after some time? That would force users to look for the most recent version and prevent the same problems caused by BGToolset clones. At least until the code is stable enough and contains advanced tricks like changing active ROS.

...but he doesn't have a hardware flasher needed for the development and testing.

I would be more than happy to help, at least with NOR testing. Can't source a NAND based console, though. They are somewhat rare and expensive in Europe.
Using USB flash storage as a replacement for actual NAND flash seemed stable enough so far. Other than the fail with number of sectors written per call.

 

[aldostools]

I already made some progress using PSL1GHT SDK and message dialogs. Should be able to test it sometimes next week when I get my hardware flasher setup up and running. Tiny3D looks a little complex for me though, I may need someone with enough experience to do the user interface.


I'm a little bit concerned about outdated/buggy versions of the code lurking on forever. Would it be reasonable to include a "timebomb" to prevent precompiled versions from working after some time? That would force users to look for the most recent version and prevent the same problems caused by BGToolset clones. At least until the code is stable enough and contains advanced tricks like changing active ROS.

This post could help you with tiny3d
https://www.psx-place.com/threads/developing-my-first-homebrew.38476/#post-347338
It has a basic example to display text on screen

About the time bomb, it is better to limit the tool to specific FW versions.

 

[toxico_rock]

thanks

 

[RoboKing's Cosmos]

would the software flasher still work if the HEN payload had cobra updated to the latest cobra?

 

[kostirez1]

This post could help you with tiny3d

Thank you. I didn't realize that I could overlay simple bitmap based assets on top of each other to create a complex looking interface. This tutorial by Hermes helped a lot too, even when auto translated to English.

would the software flasher still work if the HEN payload had cobra updated to the latest cobra?

This is a good question. In theory, there shouldn't be any reason for the code to misbehave in catastrophic ways if something small changes. It's hard to tell for sure, though, as any memory based patch may introduce unexpected behavior or crashes. It does make sense to add checks for known firmware + PS3HEN/Cobra combinations in this case, like @aldostools suggested.

Another thing that I came across during development on PS3HEN is how often does the console lockup or crash due to seemingly non flasher related reasons. WebMAN MOD (and I can't find or confirm why exactly it happens) seems to hang from time to time during initialization, leaving the yellow LED blinking forever and blocking controller inputs in XMB. As if it never reached this line of code. PS3HEN in other cases crashes the console on homebrew app startup. While it may not be a huge issue in the end, it does make sense to me in case of a dedicated app to forcefully disable all plugins and reboot after that. That should hopefully make the software related risks as low as possible.

There are also hardware related reasons for the console to crash or shutdown during flash writes. Some users for example know about their CELL/RSX overheating issues, but go for the flash anyway. While it's their problem if it shuts down after reaching ~90 °C, it shouldn't be hard to add an algorithm that monitors and maintains steady temperatures during the process. Almost like the fan control in webMAN MOD, but with additional checks to look for temperature behavior after increase/decrease of fan speeds. Basically making sure it doesn't reach anywhere near the thermal shutdown during the 60s - 90s window of writing to flash.
Something like:

1. Monitor temperatures for 60 seconds, calculate the rate of increase proportional to current fan speed (with compensation for cold startup)
2. If peak temperature/delta is over some value (or if there's a risk of reaching it soon):
3. Increase fan speed by X % manually, make sure to get expected decrease of temperatures
4. If true, continue the rest of the process while maintaining stable temperatures. If false, abort the process or run the fans at 100 %, repeating step 3.

 

[GuilloteTesla]

There are also hardware related reasons for the console to crash or shutdown during flash writes. Some users for example know about their CELL/RSX overheating issues, but go for the flash anyway. While it's their problem if it shuts down after reaching ~90 °C, it shouldn't be hard to add an algorithm that monitors and maintains steady temperatures during the process.

In scenarios critical as this one, I would put the fan at 110% during all the flashing process. Better prevent than cure.