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

aldostools said:
I don't have a HEN console to test, but I guess PS3HEN payload could be modified to perform the syscall from kernel and return the minVer using an opcode in syscall8.
Click to expand...
I'm stuck with HEN only at the moment. If the payload has the right permissions (I assume PAID is at blame here), then I suppose that is ultimately the best option.

aldostools said:
The unofficial flash writer by lmn7 verifies the minVer checking directly the memory at 0x8AFFFFF0, but it's called from the PS3 browser. I don't know if the offset is the same in ps3l1ght.
Code: 
function minVer() {
  minver = checkMemOld(0x8B000000 - 0x8, 0x100, 0x100, 10);
  minver = s2hex(minver).toString().slice(3, 8).replace("00", ".");
  if (parseFloat(minver.toString()) > 3.56) {
    showResult("<h2><span style='color:red'>Your console is not compatible with CFW!</h2></span>");
  }
}
Click to expand...
Just tried this on 4.89 + PS3HEN 3.1.1 and the memory segment is unavailable/different when the browser is closed - all requests end up with access errors. Even after I start the browser, PS3MAPI in webMAN MOD returns all zeros when I ask for 4 MB block from 0x8AFFFFF0.

Edit:
PS: I'm a total idiot. The D4 pad that I broke off during E3 flasher install is actually the path between the flash chip and the south bridge. No wonder that it no longer boots then.
 
Last edited:
Hello,

when will the site be online again? Is there any information on this or do we have to continue to wait hopelessly?
Alternatively PS3Hen, I'm also aware.
 
free1616 said:
Hello,

when will the site be online again? Is there any information on this or do we have to continue to wait hopelessly?
Alternatively PS3Hen, I'm also aware.
Click to expand...
Other people would say otherwise but I think that at this point it's safe to assume bgtoolset is gone for good. Probably there will be an alternative in the future but there's no schedule yet.

For the time being if you really want CFW these are your options -
1. If your current firmware is 3.55 or below you don't need any hacks, just take Evilnat's 4.89.2 CFW and install it like you would any firmware update. Make sure you don't accidentally use OFW or HFW cause then you won't be able to install CFW or downgrade until some method of installing CFW shows up.
2. If you don't mind taking a chance of bricking your console - There are some Russian bgtoolset-clone sites. They are anything but safe. Results of using them vary widely. Some people have reported success while others have bricked their console completely. Due to the dangerous nature of said websites posting links to them here is prohibited by admins but if you really want to take that chance, well, Google is your friend.
3. If you're willing to buy a new 2nd-hand console for CFW - There are plenty of consoles still on 3.55 available on eBay, and they're not too expensive. Get one then install CFW (see option #1).
4. If you have a hardware flasher (e.g., E3 NOR flasher) you can use it to force-downgrade your console to 3.55, then install CFW.
5. If you have a hardware flasher and willing to help the community - The author of WebManMod is currently testing flashing the hack from within WebManMod. If that's successful it means we'd have a flashing method which doesn't rely on external websites, and is probably the best bet we have. Unfortunately it's far from stable and still causes quite a few bricks so they're looking mainly for people with hardware flashers, because those can be used to un-brick the console if the test fails.
 
NiQ said:
Other people would say otherwise but I think that at this point it's safe to assume bgtoolset is gone for good. Probably there will be an alternative in the future but there's no schedule yet.

For the time being if you really want CFW these are your options -
1. If your current firmware is 3.55 or below you don't need any hacks, just take Evilnat's 4.89.2 CFW and install it like you would any firmware update. Make sure you don't accidentally use OFW or HFW cause then you won't be able to install CFW or downgrade until some method of installing CFW shows up.
2. If you don't mind taking a chance of bricking your console - There are some Russian bgtoolset-clone sites. They are anything but safe. Results of using them vary widely. Some people have reported success while others have bricked their console completely. Due to the dangerous nature of said websites posting links to them here is prohibited by admins but if you really want to take that chance, well, Google is your friend.
3. If you're willing to buy a new 2nd-hand console for CFW - There are plenty of consoles still on 3.55 available on eBay, and they're not too expensive. Get one then install CFW (see option #1).
4. If you have a hardware flasher (e.g., E3 NOR flasher) you can use it to force-downgrade your console to 3.55, then install CFW.
5. If you have a hardware flasher and willing to help the community - The author of WebManMod is currently testing flashing the hack from within WebManMod. If that's successful it means we'd have a flashing method which doesn't rely on external websites, and is probably the best bet we have. Unfortunately it's far from stable and still causes quite a few bricks so they're looking mainly for people with hardware flashers, because those can be used to un-brick the console if the test fails.
Click to expand...

First of all I would like to thank you for your detailed answer to my question.
I also fear that bgtoolset will never be online again. Really unfortunate and sad.


Unfortunately, I already own two PS3s with OFW 4.89.

I'm hoping as you said for an alternative to jailbreak OFW 4.89.
 
free1616 said:
First of all I would like to thank you for your detailed answer to my question.
I also fear that bgtoolset will never be online again. Really unfortunate and sad.


Unfortunately, I already own two PS3s with OFW 4.89.

I'm hoping as you said for an alternative to jailbreak OFW 4.89.
Click to expand...
Like I said, there's work being done on WebManMod. It won't be as good as bgtoolset (will probably take ~8 hours to flash) but hopefully (eventually) it'll be a safe process, then you can flash using it.
 
NiQ said:
Like I said, there's work being done on WebManMod. It won't be as good as bgtoolset (will probably take ~8 hours to flash) but hopefully (eventually) it'll be a safe process, then you can flash using it.
Click to expand...
8 hours is not acceptable and too risky. If that's the case it will never be released.

It looks like @kostirez1 is working on a standalone software flasher for HEN, based on the work done by us on webMAN MOD.

@lmn7 also ported the ps3xploit software flasher to 4.89. But decided to not release it.

The main limitation is the lack of testers with hardware flasher willing to help to ensure that any these software flasher solutions are safe for use.
 
aldostools said:
8 hours is not acceptable and too risky. If that's the case it will never be released.

It looks like @kostirez1 is working on a standalone software flasher for HEN, based on the work done by us on webMAN MOD.

@lmn7 also ported the ps3xploit software flasher to 4.89. But decided to not release it.

The main limitation is the lack of testers with hardware flasher willing to help to ensure that any these software flasher solutions are safe for use.
Click to expand...
I'm really not sure who was the one I've spoken to, but they said (if I understood correctly) that their main goal is to make it safe, i.e., not brick the unit even if it crashes, and that speed is not really a concern.
 
NiQ said:
I'm really not sure who was the one I've spoken to, but they said (if I understood correctly) that their main goal is to make it safe, i.e., not brick the unit even if it crashes, and that speed is not really a concern.
Click to expand...
it must be quick. seconds or minutes. some places in the world do not have the electrical grid to gurantee several hours of uninterrupted power. much bigger chance of somebody's kid or pet accidently unplugging it if it runs that long. it is just too risky to be practical for too many people.
 
Coro said:
it must be quick. seconds or minutes. some places in the world do not have the electrical grid to gurantee several hours of uninterrupted power. much bigger chance of somebody's kid or pet accidently unplugging it if it runs that long. it is just too risky to be practical for too many people.
Click to expand...
Wouldn't that be impossible considering the constraints?
 
NiQ said:
Wouldn't that be impossible considering the constraints?
Click to expand...
As Coro answered, if it cannot be done in a few minutes or seconds, then it would be too risky and the bricked consoles will rain.

ps3xploit flash writer and bgtoolset can do it in minutes, if it takes hours something is wrong.

The main constraint is the lack of testers with hardware flasher. The developers are available and the code is almost ready, but none have hardware flasher to certify the tools.
 
aldostools said:
As Coro answered, if it cannot be done in a few minutes or seconds, then it would be too risky and the bricked consoles will rain.

ps3xploit flash writer and bgtoolset can do it in minutes, if it takes hours something is wrong.

The main constraint is the lack of testers with hardware flasher. The developers are available and the code is almost ready, but none have hardware flasher to certify the tools.
Click to expand...
Again, I'm really not sure who I was talking to but I'm pretty sure it was a mod.
They said that due to the memory access limits of WebManMod (and other XMB plugins) it would be impossible to go over the entire ROM quickly (he said that a standalone app though will be able to do this).
 
NiQ said:
I'm really not sure who was the one I've spoken to, but they said (if I understood correctly) that their main goal is to make it safe, i.e., not brick the unit even if it crashes, and that speed is not really a concern.
Click to expand...
This was probably me. I think you misunderstood the time requirements to do the flash. If done correctly, the time to write 2x 7 MB (or ~5 MB if slightly optimized) to the flash memory shouldn't take longer than 1 or 2 minutes. In this case, we assume that we don't know which of the two regions are currently labeled as "active", and therefore used to boot the console. If the process is interrupted for whatever reason during writes to the active region, the console is bricked.

It is possible that someone in the future figures out how to read the "active region" flag using PS3HEN (currently impossible due to permission checks in LV1, impossible to modify from PS3HEN). In that case, it would be possible to only overwrite the active region, making the process much faster and also more efficient, as only one region is used anyway. Furthermore, if it ever becomes possible to read and write the flag, it could be optimized to the point where it is almost impossible to brick the board. This would be done by overwriting the currently unused region and switching to it only once it is verified that you can boot from it properly.

Check out a visual explanation of this process by Modded Warfare - Reverting a PS4 from 10.01 to a Jailbreakable (50:32). PS3 works the same as PS4 in this case. What is referred to as "partition" in this video is the same thing as "region" in this post.

Edit:
It is possible to take a guess which one of the regions is currently active by comparing the contents of both regions to the currently running firmware version. In the case that you are on 4.89 and can confirm that one region contains let's say 4.85 OFW/HFW and the other one 4.89 OFW/HFW, you can be sure that the second one is active. This won't be the case for people that have installed the same firmware version twice, however. This happens when you go from 4.89 OFW to 4.89 HFW, for example.
 
Last edited:
kostirez1 said:
This was probably me. I think you misunderstood the time requirements to do the flash. If done correctly, the time to write 2x 7 MB (or ~5 MB if slightly optimized) to the flash memory shouldn't take longer than 1 or 2 minutes. In this case, we assume that we don't know which of the two regions are currently labeled as "active", and therefore used to boot the console. If the process is interrupted for whatever reason during writes to the active region, the console is bricked.

It is possible that someone in the future figures out how to read the "active region" flag using PS3HEN (currently impossible due to permission checks in LV1, impossible to modify from PS3HEN). In that case, it would be possible to only overwrite the active region, making the process much faster and also more efficient, as only one region is used anyway. Furthermore, if it ever becomes possible to read and write the flag, it could be optimized to the point where it is almost impossible to brick the board. This would be done by overwriting the currently unused region and switching to it only once it is verified that you can boot from it properly.

Check out a visual explanation of this process by Modded Warfare - Reverting a PS4 from 10.01 to a Jailbreakable (50:32). PS3 works the same as PS4 in this case. What is referred to as "partition" in this video is the same thing as "region" in this post.

Edit:
It is possible to take a guess which one of the regions is currently active by comparing the contents of both regions to the currently running firmware version. In the case that you are on 4.89 and can confirm that one region contains let's say 4.85 OFW/HFW and the other one 4.89 OFW/HFW, you can be sure that the second one is active. This won't be the case for people that have installed the same firmware version twice, however. This happens when you go from 4.89 OFW to 4.89 HFW, for example.
Click to expand...
I'm sorry but I think it wasn't you.
I remember the issue was plugins not being able to address large portions of RAM or something at the sort. The only thing I truly remember is that they said that if someone created a standalone app (or added it to something running as an app, like Multiman) then it wouldn't have that problem and would be able to run quickly.
 
aldostools said:
I don't have a HEN console to test, but I guess PS3HEN payload could be modified to perform the syscall from kernel and return the minVer using an opcode in syscall8.

If the VSH plugin works, it's ok but it sounds more hacky than reading the minVer directly from memory.

The unofficial flash writer by lmn7 verifies the minVer checking directly the memory at 0x8AFFFFF0, but it's called from the PS3 browser. I don't know if the offset is the same in ps3l1ght.
Code: 
function minVer() {
  minver = checkMemOld(0x8B000000 - 0x8, 0x100, 0x100, 10);
  minver = s2hex(minver).toString().slice(3, 8).replace("00", ".");
  if (parseFloat(minver.toString()) > 3.56) {
    showResult("<h2><span style='color:red'>Your console is not compatible with CFW!</h2></span>");
  }
}
Click to expand...
I used sys_ss_update_manager to read the minimum firmware version into memory at 0x8B000000. While using the browser, this area of memory is empty, which is why I used it.

Code: 
+syscall(0x35F,0x00006011,0x1,0x8B000000,0,0,0,0,0)

aldostools said:
8 hours is not acceptable and too risky. If that's the case it will never be released.

It looks like @kostirez1 is working on a standalone software flasher for HEN, based on the work done by us on webMAN MOD.

@lmn7 also ported the ps3xploit software flasher to 4.89. But decided to not release it.

The main limitation is the lack of testers with hardware flasher willing to help to ensure that any these software flasher solutions are safe for use.
Click to expand...
I'm happy to release the flash writer as soon as it's been tested on both NOR & NAND. To be totally honest, even one test on each model is enough to confirm that it's okay to use. The reason being is that from the beginning I never wanted to touch the actual patching code, and I never did, apart from when I was editing it to test writing the full CoreOS patch.

More tests are welcome, but not strictly necessary. The same code has been used for years by now, and we know that it works. The extra safety checks just make it safer to use.
 
aldostools said:
The flasher algorithm checks for metldr.2 and should halt if it's detected in flash.
Click to expand...
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.

One of the reasons to downgrade to older OFW versions might be to get access to old and patched exploits, or to version that has less bugs. I think that 4.89 is one of the versions with broken remote play and XMB layouts (never actually tested that, but the users are complaining). Only the ones lucky enough to be on old metldr are currently able to toggle QA flags and downgrade to let's say 4.88.

lmn7 said:
I used sys_ss_update_manager to read the minimum firmware version into memory at 0x8B000000. While using the browser, this area of memory is empty, which is why I used it.
Click to expand...
Thanks for clearing that up. I should have looked for this particular syscall before scanning the memory :glee:.
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top