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

kostirez1 said:
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.
Click to expand...

Yes, that's a great tutorial by Estwald (aka Hermes). If I recall correctly, he's one of the authors of tiny3d.

You can find advanced implementations of tiny3d in Iris Manager or IRISMAN, like: resize png or jpg, animated backgrounds, music, transformations, fonts, shades, etc. The example that I posted was just a simple text output (the minimum requirement for the flasher).
 
Just received and tested a donated E3 flasher. I'm still unable to get it working, though. Every single attempt to backup my NOR flash so far ended up with error 10001100 (Failed to initialize PS3 BIOS). The clip, ribbon and E3 board itself all look ok. I already tested every single tip on the Internet to fix this issue, and nothing has worked so far.

I never expected this process to be so frustrating. :cower:
 
kostirez1 said:
Just received and tested a donated E3 flasher. I'm still unable to get it working, though. Every single attempt to backup my NOR flash so far ended up with error 10001100 (Failed to initialize PS3 BIOS). The clip, ribbon and E3 board itself all look ok. I already tested every single tip on the Internet to fix this issue, and nothing has worked so far.

I never expected this process to be so frustrating. :cower:
Click to expand...

Oh, that's frustrating indeed. Did you press the clip over the NOR during all the process?. I've read that pressure must be applied over the clip in order for everything to work (don't know why as if the pins make contact everything should be fine... simple electrical physics).

Here are two video tutorials on how to use E3 Flasher, hope those will give you some insight. Both are oriented to downgrade the console but the steps are the same: dump your current NOR, flash the patched one, verify or reflash the dump.

 
If my clip wasn't broken when it arrived, it is for sure now. :applause:
My best guess is that the pins were bent outwards too much, either right from the start (as it was used before on a slim model) or by me when I tried to figure out why it can't get a connection. After that I must have bent them too much inwards, and now it wobbles back and forth, always leaving one side of the pins slightly exposed. Can't really tell if that's the issue just by looking at the motherboard, desoldering the flash chip from a donor board could tell me more.

Next attempt (if I can confirm that the clip is 100% dead) will be to solder the 50 or so wires required for the E3 Linker. I should have enough of solid core wire from Cat 5e cables. Only way to screw that up would be to break the solder pads, and I can practice for that on my donor board. Worst case I could switch to stranded wires when soldering it on to my main one. :encouragement:

... Damn, this project is becoming really expensive. 2 consoles in the process of hardware repair, including @RoboKing's Cosmos... :biggrin2:
 
The force that pushed the clip to the NOR flash has very likely killed my board. It stays running even after ungrounding the tristate (0.56M ohm tristate-GND), behaving like it is still grounded. This prevents the board from continuing to boot, since it should beep and shutdown due to invalid ROS contents.

RoboKing's Cosmos said:
Also can you guys have a look at the ps3xploit.me nand flasher? i might suggest that. @Evilnat @kostirez1
incase you wanna add on to the flasher to notice nand regions. Search NOR_NAND_writer_release_2.0.2_PS3Xploit.zip
Click to expand...
HFW flash writer got already updated to 4.89, but there were no testers with hardware flashers.
 
@STLcardsWS The main message should probably be updated - A few weeks ago the old site's hosting service has expired, which means it's now truly offline and no DNS tricks will work anymore.

Also, you should probably add a note that OFW 3.55 and below can still be switched to CFW.
 
NiQ said:
@STLcardsWS The main message should probably be updated - A few weeks ago the old site's hosting service has expired, which means it's now truly offline and no DNS tricks will work anymore.

Also, you should probably add a note that OFW 3.55 and below can still be switched to CFW.
Click to expand...

I am a bit curious why would i need to change something, when its suggest not to use ANY DNS tricks after bguerville suggested not to :). When certs expired it should not of been used. (Added note at end of the FAQ in DNS though as to much info is not a bad thing)

Edit:
Added note about 3.55 but this was a 4.89 Jailbreaking Thread.
Also Added PS3 vs CFW comparison link
 
Last edited:
STLcardsWS said:
I am a bit curious why would i need to change something, when its suggest not to use ANY DNS tricks after bguerville suggested not to :). When certs expired it should not of been used. (Added note at end of the FAQ in DNS though as to much info is not a bad thing)

Edit:
Added note about 3.55 but this was a 4.89 Jailbreaking Thread.
Also Added PS3 vs CFW comparison link
Click to expand...
Oh, it's not super critical, just because you have a log describing everything related to the DNS trick up until August, so I thought you might as well want to add the last development for the sake of completeness.
Also, I know you would probably disagree with me but the DNS trick that worked until October was probably safe because not a single person has reported issues. It was likely still pointing to the real bgtoolset server, but now we know 100% that server is not online anymore so I think it may be worth mentioning that any DNS-related info is outdated.

In either case eventually it was just a suggestion.
 
NiQ said:
Oh, it's not super critical, just because you have a log describing everything related to the DNS trick up until August, so I thought you might as well want to add the last development for the sake of completeness.
Also, I know you would probably disagree with me but the DNS trick that worked until October was probably safe because not a single person has reported issues. It was likely still pointing to the real bgtoolset server, but now we know 100% that server is not online anymore so I think it may be worth mentioning that any DNS-related info is outdated.

In either case eventually it was just a suggestion.
Click to expand...

You say its probably safe and the guy who designs and codes it says its problematic
 
God hates me so much. I was just 10 wires away from having E3 Linker soldered to the board, and the pad for D4 (https://i.imgur.com/IWa5FQU.jpg) broke off. :biggrin2:

Now I will be forced to flip the board and get the signal from the NOR flash directly.

Does it make more sense to glue a needle that points at the DQ4 leg, or to mask neighboring pins with a tape and attach a stranded wire to it? Both options are meant as solderless, I can't risk touching something that is so small and fragile with a soldering iron.

NOR chip diagram, CECHK model - D4 is pin 44, right-hand side:
Screenshot_20221201-110823643_1.jpg

@ModderFokker619 any ideas?

Sewing needle idea:
unknown.png
Stranded wire idea:
unknown (1).png
 
Last edited:
Hey, have there been any updates regarding the ps3xploit site and a potential release date for the toolset?
This is my first time trying to jailbreak a ps3 and I think I just shot myself in the foot by updating it to 4.89. Thank you!
 
Drowss said:
Hey, have there been any updates regarding the ps3xploit site and a potential release date for the toolset?
This is my first time trying to jailbreak a ps3 and I think I just shot myself in the foot by updating it to 4.89. Thank you!
Click to expand...
just use HEN untill the site is ready.
 
kostirez1 said:
God hates me so much. I was just 10 wires away from having E3 Linker soldered to the board, and the pad for D4 (https://i.imgur.com/IWa5FQU.jpg) broke off. :biggrin2:

Now I will be forced to flip the board and get the signal from the NOR flash directly.

Does it make more sense to glue a needle that points at the DQ4 leg, or to mask neighboring pins with a tape and attach a stranded wire to it? Both options are meant as solderless, I can't risk touching something that is so small and fragile with a soldering iron.

NOR chip diagram, CECHK model - D4 is pin 44, right-hand side:
View attachment 39113

@ModderFokker619 any ideas?

Sewing needle idea:
View attachment 39114
Stranded wire idea:
View attachment 39115
Click to expand...
it would be best to start a new thread for this.
 
Drowss said:
Hey, have there been any updates regarding the ps3xploit site and a potential release date for the toolset?
This is my first time trying to jailbreak a ps3 and I think I just shot myself in the foot by updating it to 4.89. Thank you!
Click to expand...
I doubt at this point bgtoolset will ever be coming back but if you read the posts above yours, good people with flashers are currently testing and trying to stabilize a feature which would eventually allow you to flash using WebManMod. Let's hope the tests succeed and we'll have a new way of installing CFW.
BTW - You did not shoot yourself in the foot unless your previous version was 3.55 or below.
 
@aldostools Any ideas on how to get minimum applicable version (syscall 863, packet ID 0x6011) working on HEN? It always returns error 0x80010505 in my PSL1GHT based app. From what I've gathered online, it's necessary to patch some auth check. Everything I've come across online so far is using LV1 patches (here, here), which I can't use on HEN. Is there anything I'm not aware of that webMAN MOD does to access it?

Edit:
I do have capability flags set in scetool, other syscalls that require root permissions work fine.

Edit 2:
So apparently this syscall requires LAID and PAID values to be set correctly Dev Wiki - SS packet, or at the very least PAID to be set to 0x1070000052000001 (VSH modules). I'm not sure if this is possible outside the vsh.self process, but setting it as a parameter in scetool did not work. Loading a small VSH plugin may be therefore necessary to gain access to some values on HEN. At least if there's no way to execute syscalls in the context of vsh.self using Cobra.
 
Last edited:
kostirez1 said:
@aldostools Any ideas on how to get minimum applicable version (syscall 863, packet ID 0x6011) working on HEN? It always returns error 0x80010505 in my PSL1GHT based app. From what I've gathered online, it's necessary to patch some auth check. Everything I've come across online so far is using LV1 patches (here, here), which I can't use on HEN. Is there anything I'm not aware of that webMAN MOD does to access it?

Edit:
I do have capability flags set in scetool, other syscalls that require root permissions work fine.

Edit 2:
So apparently this syscall requires LAID and PAID values to be set correctly Dev Wiki - SS packet, or at the very least PAID to be set to 0x1070000052000001 (VSH modules). I'm not sure if this is possible outside the vsh.self process, but setting it as a parameter in scetool did not work. Loading a small VSH plugin may be therefore necessary to gain access to some values on HEN. At least if there's no way to execute syscalls in the context of vsh.self using Cobra.
Click to expand...
Sorry for the late reply. I don't remember to have used calls to SS packets. Maybe you can set it in HEN payload patching the vsh process. Another method could be remapping vsh.self to a patched vsh and reloading XMB.

I personally haven't tried any of them on HEN.

This is the code used in webMAN MOD:
Code: 
static u32 GetApplicableVersion(void * data)
{
  system_call_8(863, 0x6011, 1, (u32)data, 0, 0, 0, 0, 0); // lv2syscall8 on ps3l1ght
  return_to_user_prog(u32);
}
 
Last edited:
aldostools said:
This is the code used in webMAN MOD:
Code: 
static u32 GetApplicableVersion(void * data)
{
  system_call_8(863, 0x6011, 1, (u32)data, 0, 0, 0, 0, 0); // lv2syscall8 on ps3l1ght
  return_to_user_prog(u32);
}
Click to expand...
Yes, this is the same way I'm using it too. This syscall seems to do checks based on who called it in LV1, unfortunately. So, if I understand it correctly, the only process that can use this syscall is vsh.self (and plugins loaded into it).

My best idea so far is to make a small VSH plugin that would be loaded just for the purpose of calling this (and possibly anything else required) and sending back results. I could not find anything in PS3HEN/Cobra that could do "execute syscall as vsh.self". Other than possibly doing some modifications to the memory, which sounds too hacky as a solution. Especially when VSH plugins are available.
 
kostirez1 said:
Yes, this is the same way I'm using it too. This syscall seems to do checks based on who called it in LV1, unfortunately. So, if I understand it correctly, the only process that can use this syscall is vsh.self (and plugins loaded into it).

My best idea so far is to make a small VSH plugin that would be loaded just for the purpose of calling this (and possibly anything else required) and sending back results. I could not find anything in PS3HEN/Cobra that could do "execute syscall as vsh.self". Other than possibly doing some modifications to the memory, which sounds too hacky as a solution. Especially when VSH plugins are available.
Click to expand...

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>");
  }
}
 
You must log in or register to reply here.

Similar threads

Back
Top