PS3 bgtoolset update??

[MemeBassOB]

Does anyone know/have an estimate on how long we'll be waiting for the BG Toolset to be available again? I understand that it is currently unavailable on ps3xploit.me due to the issues a short while ago. Alternatively is there a way to mod without BG?

 

[AdmiralLatias]

i just saw the responses for the bgtoolset, i been wondering when they will be up and going again

 

[Coro]

we don't really know. some people probably think that nothing is happening. i noticed something recently that makes me more optimistic. but as i said, we do not know.

there is only knock-offs and speculation right now.

 

[neogba]

It's been a few months since bgtools went down. Has anyone heard anything? Will they be up soon?
As far as I know there is no other way to get CFW

 

[RoboKing's Cosmos]

There is no way to get CFW safely without a brick risk or possible tracking, which is why we don't allow unofficial clones.
There was a report of someone on a NAND console bricking their console and we don't have NAND testers with HW flashers yet.
so if you're on a CECHA CECHB CECHC CECHE CECHF CECHG then you're outta luck you can't install CFW to it. Even if you have a later model after those.. you still gotta wait for more testers.

 

[NiQ]

we don't really know. some people probably think that nothing is happening. i noticed something recently that makes me more optimistic. but as i said, we do not know.

there is only knock-offs and speculation right now.

You think WebManMod can happen eventually? Or is it still bricking consoles more often than not?

 

[djvoyager]

It's been a few months since bgtools went down. Has anyone heard anything? Will they be up soon?
As far as I know there is no other way to get CFW

There is a way. I just jailbroke one ps3 console.

 

[STLcardsWS]

There is a way. I just jailbroke one ps3 console.

There is a way but you risk your console. (Some will be okay, other will lost their console to a hardware brick)

There are some imposter's posing as bgtoolset but they are using an old incomplete stripped down and buggy (reversed portion) of the toolset. That has all the safety protection mechanisms removed. So various scenario's just result in a brick to the hardware.

Also, you have to be very cautious even if you do not care about your hardware potentially getting toast as some are rumored to be stealing things like Console-ID's and other sensitive data about your console.

Glad it worked out for you, but its not something you should be encouraging other's to do.

 

[NiQ]

There is a way but you risk your console. (Some will be okay, other will lost their console to a hardware brick)

There are some imposter's posing as bgtoolset but they are using an old incomplete stripped down and buggy (reversed portion) of the toolset. That has all the safety protection mechanisms removed. So various scenario's just result in a brick to the hardware.

Also, you have to be very cautious even if you do not care about your hardware potentially getting toast as some are rumored to be stealing things like Console-ID's and other sensitive data about your console.

Glad it worked out for you, but its not something you should be encouraging other's to do.

I assume nobody managed to determine which consoles work and which get bricked right?

Also, do you happen to know what's the current status of WebManMod? I know they said they can't patch large sections in one operation, which increases the risk of bricking. Does that mean it won't be possible? Or is it still being worked on?

 

[kostirez1]

I assume nobody managed to determine which consoles work and which get bricked right?

This research would be pointless anyway, as the person who hosts it can change it at any moment. Some clones for example have version checks removed, others blindly replace existing ROS patches with newer ones. Some people host it for a profit, others with somewhat good intentions. One thing is common for all of them, though - they don't give a single f if you brick your hardware. Never acknowledging the problems, never responding to requests for help, always downplaying the risks.

The sad thing about this is that if alternative implementations received the same amount of "testers" (users willing to brick their hardware), there could be many PS3HEN based solutions already. All of them safer than cloned code hosted by shady people, of course.

Also, do you happen to know what's the current status of WebManMod? I know they said they can't patch large sections in one operation, which increases the risk of bricking. Does that mean it won't be possible? Or is it still being worked on?

WMM implementation is more or less complete. Not in the sense that users could run it without risks on their hardware. As a matter a fact, I bricked my main dev PS3 using this version of the code. From my understanding, NOR and NAND flashes used in PS3 require you to write data in blocks of 128 KB (= 256 sectors), while the code used 512 B (= 1 sector) blocks. This makes the process take ~7 hours or more, instead of tens of seconds. WMM is unfortunately very limited in resources. You could read and write the patch in 128/256 KB blocks, but then you depend on the hard drive to not freeze or fail during the process. Is it safe enough for users with hardware flashers on hand? Yes. Is it safe for everyone? Probably not. The code otherwise produces correct results, so it can be used as a reference implementation for other projects.

Since my dev PS3 is still bricked, I moved on to develop the base of a dedicated homebrew app using my Super Slim. Can't tell at this moment when it will be ready for testers, but I plan to publish the code once it is. There's no reason to hurry however, as there are no volunteers with hardware flashers anyway. At least that I know of.

 

[NiQ]

WMM implementation is more or less complete. Not in the sense that users could run it without risks on their hardware. As a matter a fact, I bricked my main dev PS3 using this version of the code. From my understanding, NOR and NAND flashes used in PS3 require you to write data in blocks of 128 KB (= 256 sectors), while the code used 512 B (= 1 sector) blocks. This makes the process take ~7 hours or more, instead of tens of seconds. WMM is unfortunately very limited in resources. You could read and write the patch in 128/256 KB blocks, but then you depend on the hard drive to not freeze or fail during the process. Is it safe enough for users with hardware flashers on hand? Yes. Is it safe for everyone? Probably not. The code otherwise produces correct results, so it can be used as a reference implementation for other projects.

Since my dev PS3 is still bricked, I moved on to develop the base of a dedicated homebrew app using my Super Slim. Can't tell at this moment when it will be ready for testers, but I plan to publish the code once it is. There's no reason to hurry however, as there are no volunteers with hardware flashers anyway. At least that I know of.

I'm pretty sure 7 hours would be unacceptable either way since you can't even assume you won't lose power in the middle if it takes that long.
Maybe if you used an SSD it would be quicker?
Also how did bgtoolset overcome the issue in the first place?

 

[RoboKing's Cosmos]

This research would be pointless anyway, as the person who hosts it can change it at any moment. Some clones for example have version checks removed, others blindly replace existing ROS patches with newer ones. Some people host it for a profit, others with somewhat good intentions. One thing is common for all of them, though - they don't give a single f if you brick your hardware. Never acknowledging the problems, never responding to requests for help, always downplaying the risks.

The sad thing about this is that if alternative implementations received the same amount of "testers" (users willing to brick their hardware), there could be many PS3HEN based solutions already. All of them safer than cloned code hosted by shady people, of course.



WMM implementation is more or less complete. Not in the sense that users could run it without risks on their hardware. As a matter a fact, I bricked my main dev PS3 using this version of the code. From my understanding, NOR and NAND flashes used in PS3 require you to write data in blocks of 128 KB (= 256 sectors), while the code used 512 B (= 1 sector) blocks. This makes the process take ~7 hours or more, instead of tens of seconds. WMM is unfortunately very limited in resources. You could read and write the patch in 128/256 KB blocks, but then you depend on the hard drive to not freeze or fail during the process. Is it safe enough for users with hardware flashers on hand? Yes. Is it safe for everyone? Probably not. The code otherwise produces correct results, so it can be used as a reference implementation for other projects.

Since my dev PS3 is still bricked, I moved on to develop the base of a dedicated homebrew app using my Super Slim. Can't tell at this moment when it will be ready for testers, but I plan to publish the code once it is. There's no reason to hurry however, as there are no volunteers with hardware flashers anyway. At least that I know of.

What model is your super slim? Mine is 4301C with 500 GB. I have my e3 nor flasher but no use of it due to metldr2.

 

[kronosx]

bgtoolset will be back online .So currently there is no way to install full CFW other than a e3 flasher..is this correct....

 

[kostirez1]

I'm pretty sure 7 hours would be unacceptable either way since you can't even assume you won't lose power in the middle if it takes that long.

To be clear, it shouldn't ever take 7 hours, since you are always able to allocate at least the bare minimum of 128 KB. The reason why it used only 512 B was that I didn't expect it to behave differently for USB flash storage and onboard flash. It looked good enough when writing to USB, something like 90 seconds total. Of course the size would have been raised to 128K+ before releasing it to the public, as it was expected to be faster anyway.

Sidenote: While it is possible to "borrow" memory from the part used for games or apps, you still hope that the memory is (and will stay) unused for the whole process.

Maybe if you used an SSD it would be quicker?

Unfortunately not always. HDD seek times are not that substantial in this case. You are however expecting it to execute 112 reads (128K) or 56 reads (256K) with no room for a failure. You can't even roll the contents back if the drive becomes unavailable for some reason.

Also how did bgtoolset overcome the issue in the first place?

BGToolset has access to the whole memory just like the web browser or games/apps do. It allocates 7 MB buffer for the raw ROS patch and another 7 MB buffer for the per console customized ROS contents. The customized patch is then written to flash using 1 MB (= 2048 sectors) blocks. It therefore doesn't have to rely on the hard drive in any way.

What model is your super slim? Mine is 4301C with 500 GB. I have my e3 nor flasher but no use of it due to metldr2.

42xx with eMMC flash. Does the flasher work on your model? It could come in handy for a feature that would downgrade the firmware to a lower OFW version (released after metldr.2 and higher or equal to minver - let's say ~4.25+ for Super Slims).

 

[NiQ]

BGToolset has access to the whole memory just like the web browser or games/apps do. It allocates 7 MB buffer for the raw ROS patch and another 7 MB buffer for the per console customized ROS contents. The customized patch is then written to flash using 1 MB (= 2048 sectors) blocks. It therefore doesn't have to rely on the hard drive in any way.

Does it mean that an app like Multiman could also use that whole memory approach (if it supported flashing)?
Also do you think there's any way of moving forward with WebManMod? I assume that even if it becomes more reliable, 7 hours of critical process where power loss can brick your console is probably not an affordable risk for most.

 

[kostirez1]

Does it mean that an app like Multiman could also use that whole memory approach (if it supported flashing)?

Yes

Also do you think there's any way of moving forward with WebManMod? I assume that even if it becomes more reliable, 7 hours of critical process where power loss can brick your console is probably not an affordable risk for most.

No. Again, the "7 hour problem" won't be an issue by the time it is released to the public. It will, however, require more checks to rule out all issues that wouldn't arise in the case of a dedicated app. I can already imagine dumb situations like that the user wants to "save time" transferring files using FTP to the PS3 while patching the flash. This would lower the number of available memory and flood the hard drive with requests, causing slower reads for the flasher process at the same time.

Since there are 2 ROS segments - one used, one unused, the "holy grail" of ROS patching would be to figure out how to read and change the currently "active ROS" to the unused one, on PS3HEN. Power or hardware failures won't be a problem from there on, given that it will be possible to validate the contents before risking anything. Presumably this is the same way the official firmware update process works. The active ROS switch is supposed to be so fast that it is very unlikely to brick it during that. As long as you first confirm that the target ROS has valid contents, that is.

 

[RoboKing's Cosmos]

To be clear, it shouldn't ever take 7 hours, since you are always able to allocate at least the bare minimum of 128 KB. The reason why it used only 512 B was that I didn't expect it to behave differently for USB flash storage and onboard flash. It looked good enough when writing to USB, something like 90 seconds total. Of course the size would have been raised to 128K+ before releasing it to the public, as it was expected to be faster anyway.

Sidenote: While it is possible to "borrow" memory from the part used for games or apps, you still hope that the memory is (and will stay) unused for the whole process.


Unfortunately not always. HDD seek times are not that substantial in this case. You are however expecting it to execute 112 reads (128K) or 56 reads (256K) with no room for a failure. You can't even roll the contents back if the drive becomes unavailable for some reason.


BGToolset has access to the whole memory just like the web browser or games/apps do. It allocates 7 MB buffer for the raw ROS patch and another 7 MB buffer for the per console customized ROS contents. The customized patch is then written to flash using 1 MB (= 2048 sectors) blocks. It therefore doesn't have to rely on the hard drive in any way.


42xx with eMMC flash. Does the flasher work on your model? It could come in handy for a feature that would downgrade the firmware to a lower OFW version (released after metldr.2 and higher or equal to minver - let's say ~4.25+ for Super Slims).

Minimum firmware on mine is 4.60

 

[ModderFokker619]

bgtoolset will be back online .So currently there is no way to install full CFW other than a e3 flasher..is this correct....

There's a few ways

1. Use a cloned BGToolset - I've done about 5 and 1 was nand and all worked perfect
2. e3 flasher for nors - I use progskeet for all models nand or nor
3. Nand flasher for nands

I have both flashers so if I get a brick I can fix it with flashers

If any of you need testing let me know as I have flashers for all models cfw possible

 

[NiQ]

There's a few ways

1. Use a cloned BGToolset - I've done about 5 and 1 was nand and all worked perfect
2. e3 flasher for nors - I use progskeet for all models nand or nor
3. Nand flasher for nands

I have both flashers so if I get a brick I can fix it with flashers

If any of you need testing let me know as I have flashers for all models cfw possible

Can you post a link to a NAND flasher available for purchase?

 

[NiQ]

bgtoolset will be back online .So currently there is no way to install full CFW other than a e3 flasher..is this correct....

Yes and no. There is no safe way of installing CFW at the moment, unless your console happens to be running 3.55 or lower, in which case you can just install a CFW without any hack.
Anyway if you consider your console expendable you can either use a cloned version of the toolset, which may or may not work (some people reported success while others ended up with a brick), or better yet help test flashing using WebManMod.