PS3 What do I have to do if both ROS0 and ROS1 are BAD after flash?

Sorry, I forgot it. My PS3 is a CECH-2501 (min version 3.40). I installed HFW twice only on "first CFW" install. On second, I installed HFW only one time.

 

To clarify a little further as its not 100% clear from esc0rtd3ws quote: ONE error on only ROS area is ok as far as i know. If there are errors on BOTH it can indicate a bigger issue and console should not be rebooted IMO. I may be wrong but this was my understanding of it.

I think he gets errors on his as its had its IDPS modified, as this is not possible on OFW/HFW it does not really apply to those users.

Well it would depend if you are coming from 4.84 OFW too, as if you are already on 4.84 OFW, then you only need to install HFW once.

Basically the console stores the last 2 versions that were installed on it, So to make both of those say "4.84" you need to install any 4.84 version twice. This can be 4.84 OFW + 4.84 HFW, OR 4.84 HFW + 4.84 HFW again.

 

Cool, well it sounds like you might have one of those false-positive systems then! From what I quoted and have been told, that could be expected from your model. As long as your errors/dangers specifically are 0, it seems you're in the safe zone.

@DeViL303 From what OP has posted, these are warnings, not dangers. It doesn't sound like they have any dangers/errors, unless I misread it.

 

I was not on OFW, I was on REBUG, and changed my HDD. After try to install REBUG again, it shows me an error ("corrupted data") every time I tried to install (I used REBUG 4.84.1), then tries STARBUGED, but it also shows me corrupted data errors, then I install HFW again (only one time) and proceed to install CFW. I thought it was ok, because the PS3 was already on 4.84. But ok, only ROS1 was bad, and I installed CFW again. I only opened this topic because I didn't find any information about what to do if both ROS0 and ROS1 are bad. I'm also interested to correct ROS1 on my PS3 .

 

I think it's not a false positive, because on "first CFW install", everything was ok, before and after flash.

 

Possibly, Its just hard to know as people can use warnings/errors/dangers in conversation to all mean same thing.

I think esc0rtd3ws console is a CFW console with modified IDPS, I do not think there are any false positives on OFW/HFW as far as i know, except maybe in the case where it is previously unseen ROS area is found that has not been added to the checker yet like from a refurb, not sure about that though.

Again, not my area, and @littlebalup and @esc0rtd3w would know more. Maybe they can confirm 100% for us about exact specific error that is allowed.

Well, in the case that you was on 4.84 CFW, then went to 4.84 HFW, you should have been fine as both ROS areas should have read the same, so i dont know

 

Well, a lot of confusions. I'll try to clearly explain, letter today, how the dump checkers works with the ROS hash stuf, CoreOS and patches.

 

And, someone knows what to do if both, ROS0 and ROS1, are bad (with errors)? How to recover from this state after flash?

 

Give the ROS hashes please. Or post PypS3checker log.

 

I think most of the warnings that i get is from installing so many diff firmware and hashes not matching. My 2501a used to have a modified IDPS and would change minver (falsely), but has 0 issues with writer, in those states.

@littlebalup is better at explaining the actual reasons. I just have a good test environment to try different things to see what happens!

 

Right on then, @esc0rtd3w. So it sounds like what OP is doing would easily have generated a warning? Was already on CFW, then flashed HFW, then flashed CFW according to their order of operations.

 

thats another tricky one that has also been added to new v4 tools, to check known CFW/OFW ROS hashes in memory after write, to verify.

we have tested more than 15 CFW/OFW and added hashes. i am sure @littlebalup has added plenty more in his tool hehe

 

ROS hash checks explanation:


The ROS, what it is?.. explanation :

A ROS is a Region in the flash memory (NOR, NAND or EMMC) where the firmware Core OS is stored (lv0, lv1, lv2, modules...).
So we can say ROS = Region OS = Core OS data.
There are two ROS in the flash memory. Called ROS0 and ROS1. Those two regions are populated/overwritten alternativelly when a System Update (firmware installation) is performed. So the active/currently used ROS is not overwritten while the inactive ROS is overwritten during the update process. Once the update is complete, the inactive ROS become the active ROS and vice versa.

Example:
My active ROS is ROS0, filled with 4.82 OFW CoreOS. Means I'm running 4.82 OFW. (I don't know what is inside the inactive ROS1 but I don't care).
Current state: ROS0 = active with 4.82 OFW CoreOS. ROS1 = inactive with x.xx CoreOS.
I'll update to 4.83 OFW. So I'll load 4.83 OFW CoreOS into the inactive ROS1. ROS1 will become the active ROS once update is complete.
Result: ROS0 = inactive with 4.82 OFW CoreOS. ROS1 = active with 4.83 OFW CoreOS.
Then I'll update to 4.84 OFW.
Result: ROS0 = active with 4.84 OFW CoreOS. ROS1 = inactive with 4.83 OFW CoreOS.
Then I'll update to 4.84 HFW.
Result: ROS0 = inactive with 4.84 OFW CoreOS. ROS1 = active with 4.84 HFW CoreOS.
but, in fact the 4.84 HFW CoreOS is exactly the same as the 4.84 OFW CoreOS. So:
Result: ROS0 = inactive with 4.84 OFW CoreOS. ROS1 = active with 4.84 OFW CoreOS.

Pretty easy. I'm sure (hope) you got it.

Another important thing to know about ROS : there are no way to determine what is the active ROS only looking inside a single flash dump data as that information is stored in the syscon (the eeprom memory) and not in the flash.
The only way to be 100% sure what is the active ROS, is to make a first dump, update firmware to a higher version, make a second dump then analyse that second dump. So the higher ROS version is the active ROS.
That said, a dump checker, with a single dump, can't determine what is the active ROS. But you can.


What is the jailbreak flash process?... explanation :

It consists to modify (patch) the CoreOS (raw) data, directly inside the ROS's, in order to be able to install a Custom FirmWare.
As we can't determine for sure what is the active ROS, the patches are applied to both ROS0 and ROS1.

The regular ROS patches:
A regular ROS patch is a complete custom CoreOS that will fully overwritte both ROS.
It's applied to the flash dump with a third party PC software then flashed using an hardware flasher.
Once flashed, both ROS are filled with the same custom CoreOS.

The PS3Xploit v2 patches (aka. flash_484.hex):
PS3Xploit patch is partial custom CoreOS data. It is applied using the PS3Xploit flash Writer tool from the PS3 web browser. It will partially overwritte both ROS.
So, to not corrupt the ROS's by applying the patch to a wrong CoreOS version, both ROS must be previously populated with the CoreOS the PS3Xploit patch is made for.
It's not that serious to corrupt the inactive ROS as it will be overwritten at the next system update, before to be activated. But it's better to not for dump check purpose (see next chapter).
It's mandatory to not corrupt the active ROS otherwise it will result a brick at console reboot!
That's why before flash, you must:
- Ensure your flash_484.hex file is what it must be (MD5 checksum).
- Ensure you just installed 4.84 HFW so the active ROS is filled with 4.84 OFW/HFW CoreOS (and incidentally be able to use the exploit...)
- To not corrupt the inactive ROS, install the 4.84 HFW a second time. So both ROS are filled with 4.84 OFW/HFW CoreOS.


How the dump checkers works?... explanation :

Mainly the checkers (PS3DumpChecker as well as PyPS3checker) will analyse your flash dump data against a database. That database has been made empirically, based on many many years of dump analisys with a lot of corrections. So, it's not an exact science and many data are unknown or crypted.
The PS3DumpChecker checks database is the "default.cfg" file : https://github.com/Swizzy/PS3DumpChecker/blob/master/Latest Compiled Version/default.cfg
The PyPS3checker checks database is the "checklist.xml" file : https://github.com/littlebalup/PyPS3tools/blob/master/PyPS3checker/checklist.xml
Checks and data are almost the same for the both apps.

About the ROS's verification. The ckecker will calculate the MD5 checksum (hash) of the ROS content (CoreOS) and compare it against another dedicated database.
The PS3DumpChecker checksum database is the "default.hashlist" file : https://github.com/Swizzy/PS3DumpChecker/blob/master/Latest Compiled Version/default.hashlist
The PyPS3checker checksum database is the "hashlist.xml" file : https://github.com/littlebalup/PyPS3tools/blob/master/PyPS3checker/hashlist.xml
If the calculated checksum from the ROS data is not found in the database, PS3DumpChecker will return a "BAD" and PyPS3checker a "Warning".


The big deferences between PS3DumpChecker and PyPS3checker:

- PS3DumpChecker is binary. A result is "Ok" or "Bad".
- For PyPS3checker, a result can be "Ok", "Warning" or "Danger" depending how the check has been set in the database. A ROS hash check can be "Ok" or "Warning" but never "Danger". "Danger" are mainly reserved for "Per console" data.

- PS3DumpChecker have only OFW , "No-FSM" and PS3Xploit patched CoreOS hashes in its database. The reason is because is actually unable to get CoreOS size and to calculate the checksum dynamically. (OFW and "No-FSM" CoreOS have always the same size while CFW CoreOS can have smaller size with remaining data in ROS from previous installed CoreOS. )

- PyPS3checker have OFW, Regular CFW, "No-FSM" and PS3Xploit patched CoreOS hashes in its database.


That means:

PS3DumpChecker will return a "Bad" ROS hash if :
- the ROS is filled with any CFW CoreOS!
- the ROS is filled with any corrupted OFW CoreOS.
- the default.haslist file is not up to date and doen't contain the hash of the OFW CoreOS you installed (or patched)...

PyPS3checker will return a "Warning" on the ROS hash if :
- the ROS is filled with any "exotic" or modded CFW CoreOS not listed in the database.
- the ROS is filled with any corrupted OFW CoreOS.
- the haslist.xml file is not up to date and doen't contain the hash of the CoreOS you installed (or patched)...


Conclusion:

- Install 4.84 HFW twice before to flash to be sure to not get a "Warning" (or a "Bad") on the inactive ROS.
Note: a "Warning" to both ROS right after flash means something wrong and your active ROS is corrupted for sure. It can be the case if you flash from a 4.84 CFW...

- Do not use PS3DumpChecker to check a dump made from a CFW or you'll obtain a "Bad" at least on one of the ROS (the active one).

- Don't be surprised if you get a "Warning" with PyPS3checker if you installed, or previously installed an "exotic" CFW or MFW not listed in the hashlist. The good method is alway to install a regular CFW twice before to dump from CFW.



P.S.: probably a lot of typo here. I'll do my best to clean it latter. Then it maybe good to make a dédicated sticked thread with those explanations...

 

https://github.com/littlebalup/PyPS...c382708c8f0ec8/PyPS3checker/hashlist.xml#L355

 

@littlebalup thats a great explanation! +1 for sticky

maybe some of that text can be worked into official dumper/writer help