• Official PS3 Toolset is now supporting 4.92 Firmware

    View Official Release Post for additional information HERE

PS3 [BG Toolset] User Issues and Dump Submissions

PRIEST said:
Having issues on jailbreaking my ps3 console it keeps initializing ps3 toolset in the new BG toolset for hours and sometimes if i refresh a pop up appears saying, I should enable flash player plugin. But after the refresh I don't see any pop up for me to click enable flash player. And I played some video clips online it worked but still up to no avail to bypass the initialization toolset.
Ps3 FAT
Model:CECHM03
OFW:4.85 (INSTALLED V4.86.1 HFW)
Click to expand...
You need to follow the instructions on the main page of toolset . It specified to make a new user. The new user will have the flash prompt. There are other ways to fix if on HEN or already CFW by deleting the setting.xml

All these things are already listed.

Verify you have done that and report back
 
So it seems like I can't paste links to outside images in a private message to someone so I'll paste it here.

After I got his PM I proceeded to apply the patch only once.

I then went to recovery and proceeded to step 6: http://www.mediafire.com/file/kxcgi9kfs0jurfb/20200409_111941.jpg/file
Finally showing the correct firmware.

In installing REBUG 4.84.2 and got this error message:
http://www.mediafire.com/file/lnmucaenzb13yu5/20200409_114138.jpg/file

I was able to install the 4.86 OFW firmware but can't seem to be able to install any CFW such as REBUG 4.84.2 as above or 4.86.1 LITE or FERROX.

It just gives those error messages when I click step 6 on recovery.
 

Attachments

  • upload_2020-4-9_12-11-5.png
    upload_2020-4-9_12-11-5.png
    26.3 KB · Views: 140
444hz said:
So it seems like I can't paste links to outside images in a private message to someone so I'll paste it here.

After I got his PM I proceeded to apply the patch only once.

I then went to recovery and proceeded to step 6: http://www.mediafire.com/file/kxcgi9kfs0jurfb/20200409_111941.jpg/file
Finally showing the correct firmware.

In installing REBUG 4.84.2 and got this error message:
http://www.mediafire.com/file/lnmucaenzb13yu5/20200409_114138.jpg/file

I was able to install the 4.86 OFW firmware but can't seem to be able to install any CFW such as REBUG 4.84.2 as above or 4.86.1 LITE or FERROX.

It just gives those error messages when I click step 6 on recovery.
Click to expand...
Why are you installing ofw? You should be installing Rebug 4.86

Then qa, then can install 4.84

At this point you should be able to use normal patcher again, then install CFW lol

DO NOT RUN THE NAND FIX AGAIN!!
 
esc0rtd3w said:
Why are you installing ofw? You should be installing Rebug 4.86

Then qa, then can install 4.84

At this point you should be able to use normal patcher again, then install CFW lol

DO NOT RUN THE NAND FIX AGAIN!!
Click to expand...

esc0rtd3w like I mentioned in the previous reply I tried to install CFW, but couldn't because it kept giving that error. I tried Rebug 4.86 but it still gave the error. The ONLY file I was able to run was the OFW 4.86.
 
444hz said:
esc0rtd3w like I mentioned in the previous reply I tried to install CFW, but couldn't because it kept giving that error. I tried Rebug 4.86 but it still gave the error. The ONLY file I was able to run was the OFW 4.86 and HFW 4.86
Click to expand...
it says you tried installing Rebug 4.84, not 4.86, which would require QA flag being set.

Either way, you are on 4.86 OFW, then run normal toolset link and should be all good

EDIT: i just noticed you tried 4.86 rebug. Well, now that you are on OFW, try normal patch and install CFW after success
 
esc0rtd3w said:
it says you tried installing Rebug 4.84, not 4.86, which would require QA flag being set.

Either way, you are on 4.86 OFW, then run normal toolset link and should be all good

EDIT: i just noticed you tried 4.86 rebug. Well, now that you are on OFW, try normal patch and install CFW after success
Click to expand...

Thank you this was a success! Currently on 4.84.2 REBUG REX.

To bguerville, esc0rtd3w,

It really was not allowing me to install any custom firmware the MOMENT after you run the fix that esc0rtd3w sent to my inbox. The ONLY firmware I could run was the OFW 4.86 firmware on my USB drive from recovery. After that was done then It restarted into 4.86 OFW and then re-run the tool on the normal ** www.** ** www.ps3xploit.net > D...* (NEW URL = http://ps3toolset.com/bgtools/ ONLY ONCE. Then I restarted and was able to install the 4.86.1 REBUG LITE and then from REBUG LITE -> I installed REBUG TOOLBOX and went to the Utilities tab and changed "Toggle QA Flag" -> ENABLED. Then I was able (meaning didn't have to go back to recovery) to go to the XMB install update from storage and installed REBUG 4.84.2 REX.

This is what I have now.

Again thank you all for your help. I'm pretty freak en happy right now.

Now onto installing homebrews and installing LINUX so I can run as a server.

EDIT1: Also glad you guys took off the nand_fix for people because, people can easily make the mistake of running it more than once just to make sure it worked (such as when you mention in different threads to do things twice. Can't remember which ones exactly though but I believe I saw for other threads to do certain things twice.
 
Last edited:
444hz said:
Thank you this was a success! Currently on 4.84.2 REBUG REX.

To bguerville, esc0rtd3w,

It really was not allowing me to install any custom firmware the MOMENT after you run the fix that esc0rtd3w sent to my inbox. The ONLY firmware I could run was the OFW 4.86 firmware on my USB drive from recovery. After that was done then It restarted into 4.86 OFW and then re-run the tool on the normal ** www.** ** www.ps3xploit.net > D...* (NEW URL = http://ps3toolset.com/bgtools/ ONLY ONCE. Then I restarted and was able to install the 4.86.1 REBUG LITE and then from REBUG LITE -> I installed REBUG TOOLBOX and went to the Utilities tab and changed "Toggle QA Flag" -> ENABLED. Then I was able (meaning didn't have to go back to recovery) to go to the XMB install update from storage and installed REBUG 4.84.2 REX.

This is what I have now.

Again thank you all for your help. I'm pretty freak en happy right now.

Now onto installing homebrews and installing LINUX so I can run as a server.
Click to expand...
awesome to hear :)

glad you got it sorted
 
444hz said:
EDIT1: Also glad you guys took off the nand_fix for people because, people can easily make the mistake of running it more than once just to make sure it worked (such as when you mention in different threads to do things twice. Can't remember which ones exactly though but I believe I saw for other threads to do certain things twice.
Click to expand...
That mentions about installing firmwares twice are because inside the flash chip there are 2 areas (named ros0 and ros1) that are intended to store data from the "actual" and the "previous" firmware
Only one of them is active (the "actual", used to boot the console) and the other is ignored (the "previous")

Everytime you complete a firmware installation the identifyers that indicates which one is the "actual" and the "previous" are swapped
The new firmwares are installed always in the "previous" but that installation converts it to "actual"

Is a bit tricky to explain, sorry, english is not my native language :D
The point is... if you have some doubt about the content of your "previous" ros by installing the firmware twice you are writing the exact same data to both ros areas (so they becomes identical)



-------------------------------
As example... lets say we start with a PS3 that have:
ros0 = 486ofw <--- actual
ros1 = 482ofw <--- previous

In the exploit used some months ago (based in a vulnerability of the webkit) it was not posible to identify which one was "previous" and which one was "actual" so it was recommended to install the firmware twice to start like this (both ros areas containing the same data):
ros0 = 486ofw <--- actual
ros1 = 486ofw <--- previous

And the patch was applyed like this (keep in mind this patch is applyed by unnofficial means so the identifyers for "previous" and "actual" doesnt changes)
ros0 = 486patched <--- actual
ros1 = 486patched <--- previous

After that you was able to install a CFW (in the previous ros, and this installation converts it to actual ros) so the result was like this:
ros0 = 486patched <--- previous
ros1 = 486cfw <--- actual

If you install the same CFW again the result would be this:
ros0 = 486cfw <--- actual
ros1 = 486cfw <--- previous


----------------------
Now with the new bguerville toolset (based in a vulneratility of the flash player) is posible to identify which ros area is the "actual" and which is the "previous" so the patch is more precise, lets say you start like this:
ros0 = 486ofw <--- actual
ros1 = 482ofw <--- previous

The toolset detects that ros0 is the "actual", so the patch is applyed in ros0 (and ros1 is ignored), this way:
ros0 = 486patched <--- actual
ros1 = 482ofw <--- previous

At the next boot the PS3 loads the data from ros0 (actual), but installs the new firmware in ros1 (previous), note this is an standard firmware installation so the identifyers for "actual" and "previous" changes, and the result is like this:
ros0 = 486patched <--- previous
ros1 = 486cfw <--- actual

After that if you install the same cfw again the result is like this:
ros0 = 486cfw <--- actual
ros1 = 486cfw <--- previous




-------------------
*If i made some mistake or typo in this explaination feel free to correct me
 
Last edited:
@sandungas it doesnt detect active ros currently. The old writer only wrote 3mb of data to CoreOS (i think both still, but the ROP was very much more unstable), so we did recommend installing same fw twice so both versions would match in both ros banks, in case of some weird circumstance, it would be in a better state. In v2 that was more or less remedied because it did write to both ros, but still only the 3mb.

The BG Toolset writes the full 7mb Patched CoreOS to each bank, ros0 and ros1. It then currently sets active ros bank to ros1.

@bguerville can also correct any mistakes i just made lol :)

EDIT:
I do believe a future build will in fact detect the state of each ros bank, active or not active
 
Last edited:
FYI

1. The Toolset CAN DETECT the currently active ROS (on nand only) but the information is not used to select which ROS to patch or whatever. It always patches both ROS regions.

2. The Toolset DOES NOT need the double ofw installation prerequisite like old v2 tools did.
Think of the 7Mb patch as a full CoreOS package & the 3Mb patch as a CoreOS patch.
The 7Mb patch always ensures that both ROS regions are valid after patching, both containing a fully valid CoreOS, no matter what they contained before patching.
On the other hand, with the old v2 tools using a 3Mb patch applied on both ROS, whenever the inactive ROS region contained a different fw from the patch target OFW version, that ROS region CoreOS after patch became "corrupted" & in simple terms, the update process could detect invalid data leading to update failure.

3. The Toolset DOES NOT activate a ROS region in particular. It lets the system manage its active ROS swap in the standard way without interfering.

Note that on NAND, given the fact that the relative offset of the active ROS is part of the data that must be overwritten when patching, FMM first extracts, before patching, the relative offset of the active ROS & inserts it within the patch data so that when patching is complete, the active ROS offset stored in Flash Memory is still the same as it was before patching & on reboot, the system can proceed with its active ROS swap on CFW installation without interference.

;-)
 
Last edited:
Ohh, ok, im going to strike my previous post to dont confuse anyone, there is still something i dont understand
bguerville said:
the 7Mb patch always ensures that both ROS regions are valid after patching, no matter what they contained before patching.
Click to expand...
But this involves generating the patch dinamically for each "target" firmware version ? (by adding the surrounding bytes we was talking before, that are specific for each firmware version)
 
sandungas said:
Ohh, ok, im going to strike my previous post to dont confuse anyone, there is still something i dont understand

But this involves generating the patch dinamically for each "target" firmware version ? (by adding the surrounding bytes we was talking before, that are specific for each firmware version)
Click to expand...
Yes indeed.
I added a few details about that in my previous post.
Those bytes are not specific per fw version though, only CoreOS is.
The made up bytes are different on ros0/ros1 & nor/nand. And on nand specifically, an extra 0x10 bytes containing the active ROS relative offset must also be included.
 
I think i got it definitivelly, my confusion was that i thought the surrounding bytes was different by firmware version, but there are only 4 posible values for them: NANDros0, NANDros1, NORros0, NORros1... and you can identify which one is needed when the PS3 is scanned by the toolset
The toolset have that surrounding bytes hardcoded and generates the complete patch in the PS3 RAM that is going to be applyed in a later step to flash chip, right ?
sandungas said:
Got it :)
The center area of the noFSM patch is common, but the surrounding bytes (to increase the patch size up to 0x700000) are 4 posible scenarios, for: NANDros0, NANDros1, NORros0, NORros1
And the patch applyed by the toolset is composed by: center area (common) + surroundings (specific)
So are like 4 patches to support all the CFW compatible PS3 models
Click to expand...

I was not aware about that feature for NAND that copies the 0x10 bytes that indicates the active ros and creates the patch dinamically with them to preserve them, thats nice
This is making me wonder what happens with NOR ?, is unknown where are located that 0x10 bytes ?, by reading them it would be posible to know which one is the active ros when the toolset scans the PS3 (and this would unlock other roads to implement new features to the toolset)
 
Last edited:
Problem : Ps3 do not accept any firmware after use dump
images :
https://uploadfiles.io/e41p8ov1
https://uploadfiles.io/cu3av0sv
https://uploadfiles.io/46rtyvd7
informations:
PS3 Model: CECH-C04 60 gb
Firmware Version: 4.86
Firmware Type:
IDPS Is Masked:
Have Original Dump: No
Dump 1 URL:
Have Patched Dump: Yes
Dump 2 URL: http://www.mediafire.com/file/dqkwjaphu7d5b4q/dump_after_patch.hex/file
System Boots To Recovery: Yes
Firmware Version Displayed In Recovery: 2.50
Minimum Firmware Version Displayed In Toolset: 1.0
Mounted Devices: None
Disc In Drive: No
 
Last edited:
sidou said:
Problem : Ps3 do not accept any firmware after use dump
images :
https://uploadfiles.io/e41p8ov1
https://uploadfiles.io/cu3av0sv
https://uploadfiles.io/46rtyvd7
informations:
PS3 Model: CECH-C04 60 gb
Firmware Version: 4.86
Firmware Type:
IDPS Is Masked: Yes
Have Original Dump: Yes
Dump 1 URL: http://www.mediafire.com/file/p5fi314p9pe43j1/Original_dump.hex.checklog.txt/file
Have Patched Dump: Yes
Dump 2 URL: http://www.mediafire.com/file/feeqhjuudawkj8d/dump_after_patch.hex.checklog.txt/file
System Boots To XMB: Yes
System Boots To Recovery: Yes
Firmware Version Displayed In Recovery: 2.50
Minimum Firmware Version Displayed In Toolset: 1.0
Mounted Devices: None
Disc In Drive: No
Click to expand...
dude, this txt files are not the dumps.

Those are just the txt results from PS3PyChecker.

Please post the actual dumps.

Also how is IDPS masked when this is not a dump

Good effort, but please re-submit or edit post
 
You must log in or register to reply here.

Similar threads

Back
Top