PS3 PS3Xploit Flash Writer [aka CFW Installer] - (Supports All PS3 Fat Models & Most Slim Models)

[bguerville]

Hello, can anyone help me?.
bgtoolset is under maintenance?
I'm in official 4.88 and I go to the ps3xploit page, then I go to bgtoolset and it tells me that it's under maintenance, I've been waiting a couple of days, what can I do to install cfw again.

You have 4 options available to you at the time of writing.

1. You wait a little more until the Toolset becomes live again. When the deed is done and you have your system the way you want it, consider a donation to keep the project alive after October otherwise next time, you might find yourself with only the next 3 options.

2. You mod the old Flash Writer code yourself but I warn you, assuming you are savvy enough to make the JavaScript changes to support 4.89, it is complicated for someone without experience to make a custom patch file, the brick risk will be high.

3. You use unofficial stuff, you take your risks, not knowing whether you will brick or get data stolen from you, keeping in mind you will get no tech support from ps3xploit team.

4. You buy a hardware flasher, set it up properly to jailbreak your console. You will need a E3 flasher for nor consoles or Teensy 2.0++ for nand or nor. If you get a Teensy and dunno how to solder, you need to buy the appropriate extra parts to connect the board without soldering.

 

[kekus]

Okay, I'll wait, thank you very much.

 

[aldostools]

2. You mod the old Flash Writer code yourself but I warn you, assuming you are savvy enough to make the JavaScript changes to support 4.89, it is complicated for someone without experience to make a custom patch file, the brick risk will be high.

The javascript seems the easy part. The custom patch file is not documented anywhere explaining how to create it properly.

I'm trying to learn how to create it. I compared the old patches for 4.82-4.85 with the corresponding version of nofsm_patch.bin from @littlebalup PyPS3tools, but the files only matched partially.

Does someone have more information about how to create the custom patch? it would be very useful.

If someone is wondering if I plan to create a tool for that; the answer is no. I don't mess with flash stuff. I only want to learn, since the source code of the web flasher omitted that critical information for other developers.​

 

[bguerville]

The javascript seems the easy part. The custom patch file is not documented anywhere how to create it properly.

I'm trying to learn how to create it. I compared the old patches for 4.82-4.85 with the corresponding version of nofsm_patch.bin from @littlebalup PyPS3tools, but the files only matched partially.

Does someone have more information about how to create this custom patch? it would be useful.

If someone is wondering if I plan to create a tool for that. The answer is no. I don't mess with flash stuff. I only want to learn, since the source code of the web flasher omitted that critical information for other developers.

Those old patches were a terrible idea to begin with, they were meant to be minimal patching of the CoreOS files, only what was needed to install a CFW.
Given the CoreOS structure and the fact that you cannot read/write the flash memory any way you want, the access is per sector of 512 bytes at a time, it usually required patching at least the first 3Mb in order to cover all the files that needed covered while keeping intact the rest of the files, the patch itself could be slightly different from one version to the next depending on the official CoreOS package layout, which was why no tool was made to create them in the first place.
Having said that, it wouldn't have been an impossible thing to do either, just more work, but having people starting to make and redistribute patches was potentially a scary thought as well, making us a little uneasy at the time.

If you want my opinion, it's probably easier to mod the js code that builds the rop stack frames in order to support standard 7Mb patches than learn to make custom patches.
If you add to this, the lack of checks, the lack of feedback and the fact that the browser memory used to buffer the patch data is strictly speaking "unallocated" from the browser point of view and the hardcoded memory area could potentially be written to by the WebKit engine thus corrupting the patch data (and Habib made that mistake again with HEN btw when he reused my old code), this tool and the old patches are better left where they belong, in the scene's heap of legacy obsolete stuff, no longer to be used.

 

[aldostools]

Those old patches were a terrible idea to begin with, they were meant to be minimal patching of the CoreOS files, only what was needed to install a CFW.
Given the CoreOS structure, it usually requires patching at least the first 3Mb in order to cover all the files that needed covered while keeping intact the rest of the files, the patch itself would be slightly different from one version to the next depending on the official CoreOS package layout.

If you want my opinion, it's probably easier to mod the js code that builds the rop stack frames in order to support standard 7Mb patches than learn to make custom patches.

Thanks for the information. That's a progress... honestly I didn't expect that you were who answer

From your comments I understand that the hex file is not a continuous file. Reading the flasher's code it looks like they are 4 chunks from nofsm_patch and to make a web flasher support 4.80-4.89, I would have to modify the javascript to make the stack_frame apply the full nofsm_patch (7,340,000 bytes) instead the 4 custom chunks.

At this point, I'm not sure if I would like to continue the research since I don't have a way to test the changes.

Anyway I appreciate your time for answer

 

[bguerville]

The javascript seems the easy part. The custom patch file is not documented anywhere explaining how to create it properly.

I'm trying to learn how to create it. I compared the old patches for 4.82-4.85 with the corresponding version of nofsm_patch.bin from @littlebalup PyPS3tools, but the files only matched partially.

Does someone have more information about how to create the custom patch? it would be very useful.

If someone is wondering if I plan to create a tool for that; the answer is no. I don't mess with flash stuff. I only want to learn, since the source code of the web flasher omitted that critical information for other developers.​

For information, there's a couple of ways you could go about it, for instance you could dump the target OFW NOR, identify the active ROS (install ofw/hfw twice in a row so you avoid the possible inactive ros corruption after patching) and the CoreOS files that need patched by taking note of the offset entries in the ros table.

Then extract, decrypt, patch and reencrypt the required file(s), you need to hope that the size of the resulting file(s) hasn't changed. If not, you can reinsert it/them in the appropriate location in the ros data dump without further changes.
Once you are done patching the ros dump, you can extract the patch data.
It should start at sector 0x601 for NOR and cover 0x1802 sectors of continuous data data, each sector being 0x200 bytes in size.
For each ROS, the tool makes 4 storage write syscalls, 3 with 0x800 sectors and one with 2 sectors to complete the patch.

.. to make a web flasher support 4.80-4.89, I would have to modify the javascript to make the stack_frame apply the full nofsm_patch (7,340,000 bytes) instead the 4 custom chunks.

Yes, if you were to use this tool despite its inherent flaws, that would be the best option imho.
You would need to prep the patched ROS data in browser memory, dump the first sector of each ROS in browser memory first to keep the ros headers intact (0x20 bytes for one ROS and 0x30 bytes for the other iirc), then copy the 7Mb patch file from USB twice into memory to complete the ROSes prepping.
Finally apply the 14Mb of data for both ROSes in one continuous write sweep, 0x800 sectors at a time.

It's possible to write more than 0x800 sectors in a write syscall, up to 0x2000 iirc (TBC), but we noticed that on certain consoles from 0x1000 sectors up, some write syscalls happened to fail so because this tool doesn't do any checks of any kind, we couldn't detect any failures and we had to adjust the syscall calls argument to use 0x800 sectors max at a time to avoid any such issue which would inevitably lead to bricks without any warning whatsoever.

 

[bguerville]

From your comments I understand that the hex file is not a continuous file. Reading the flasher's code it looks like they are 4 chunks from nofsm_patch

The hex file is continuous in the version I worked on, I am pretty sure they remained that way afterwards, what I meant was that potentially this could change the day the CoreOS layout makes it necessary.
It also depends on the patches made and on any file size difference after patching.
I cannot say whether recent fw like 4.89 can be processed exactly like we processed 4.82 or 4.83, that needs to be double checked and confirmed.

Thanks for the information. That's a progress... honestly I didn't expect that you were who answer

...

Anyway I appreciate your time for answer

You are more than welcome, you can ALWAYS contact me privately or in forum for stuff like that, whenever you need, if I can help, I will.

 

[aldostools]

You are more than welcome, you can ALWAYS contact me privately or in forum for stuff like that, whenever you need, if I can help, I will.

The information that you provided is very valuable and I appreciate it very much!

I will continue reviewing the web flasher to try to have a better understanding of how it works.

As I mentioned earlier, my goal is to understand how it works and how it could be updated since that's the only public code available legally.

I hope that this information also helps to *REAL* developers willing to make some progress in this area.

Merci beaucoup mon ami.

 

[bguerville]

The information that you provided is very valuable and I appreciate it very much!

I will continue reviewing the web flasher to try to have a better understanding of how it works.

As I mentioned earlier, my goal is to understand how it works and how it could be updated since that's the only public code available legally.

I hope that this information also helps to *REAL* developers willing to make some progress in this area.

Merci beaucoup mon ami.

Due to the fact that Toolset 1.1 is already out there in whatever shape or form, I will most likely end up opening the source of that specific version officially, without obfuscation or whatever, it would make little sense to continue keeping that code entirely private anymore. As always, no ETA on that though.

Having said that, I encourage you to look at the flash writer exploit, the stuff might be intimidating at first but after a little while, you will realise it's all quite simple really, just logic at ppc level.

But the rop chain is not ideal to learn with because as is writing to Flash is not something you can casually tweak and test.
You would probably be better off using a simpler implementation like a buzzer syscall to get familiar with the exploit, practice changing arguments first, then practice adding other syscalls, say a sleep syscall then another buzzer syscall or whatever, then you can look at the Flash Writer.

 

[aldostools]

Due to the fact that Toolset 1.1 is already out there in whatever shape or form, I will most likely end up opening the source of that specific version officially, without obfuscation or whatever, it would make little sense to continue keeping that code entirely private anymore. As always, no ETA on that though.

Having said that, I encourage you to look at the flash writer exploit, the stuff might be intimidating at first but after a little while, you will realise it's all quite simple really, just logic at ppc level.

But the rop chain is not ideal to learn with because as is writing to Flash is not something you can casually tweak and test.
You would probably be better off using a simpler implementation like a buzzer syscall to get familiar with the exploit, practice changing arguments first, then practice adding other syscalls, say a sleep syscall then another buzzer syscall or whatever, then you can look at the Flash Writer.

I know I could use the leaked framework.js... indeed I "beautified" it for better understanding, but as you said it is intimidating to try to understand a script of +2600 lines

ATM I'm not trying to experiment with ROP... I'm only trying to understand how the nofsm_patch is applied on flash memory.
So far I have found that it was applied in a different order in my NOR flash. Also that some segments are not identical and that my 2 ROS are different.

I used webMAN MOD to dump 16MB of the NOR flash using this web command.
http://10.0.0.8/getmem.ps3mapi?proc=3&addr=0&len=256&dump=1000000

 

[kekus]

Hello I have a problem, I start by parts, I was in cfw 4.89 cex and I decided to downgrade to 4.84 to change to dex, suddenly my console is in 4.25 ofw, I think my ps3 has a 4.25 update file saved somewhere, and I tried to install cfw again with toolset and it has worked perfectly, but when installing the update file it returns me to 4.25 ofw, does anyone know how I can solve it?

 

[aldostools]

Hello I have a problem, I start by parts, I was in cfw 4.89 cex and I decided to downgrade to 4.84 to change to dex, suddenly my console is in 4.25 ofw, I think my ps3 has a 4.25 update file saved somewhere, and I tried to install cfw again with toolset and it has worked perfectly, but when installing the update file it returns me to 4.25 ofw, does anyone know how I can solve it?

Eject the game disc from the drive. Evilnat CFW 4.88 or 4.89 don't have the patch that blocks /dev_bdvd/PS3_UPDATE/PS3UPDAT.PUP (Evilnat commented that this patch will be included in the next release)

Make sure that there are not other PUP in the root of the USB or in /dev_hdd0. The system searches for the PUP in many other places in addition to /dev_usb000/PS3/UPDATE/PS3UPDAT.PUP

Also verify that the MD5 of the PUP in the USB drive to confirm that it is 4.84.2 Rebug REX.

 

[Coro]

@aldostools

below is an improved flash writer for 4.85 by @lmn7 (in case you do not have it). he added some checks (see changelog) and merged the nor/nand versions into one. the js is inside the html and the patch is downloaded as a p3t file.

he was interested in updating it again but not knowing how to make the patch stopped that. he mentioned possibly using the 7mb patch but IIRC that was more work than he had time for.

 

[littlebalup]

The javascript seems the easy part. The custom patch file is not documented anywhere explaining how to create it properly.

I'm trying to learn how to create it. I compared the old patches for 4.82-4.85 with the corresponding version of nofsm_patch.bin from @littlebalup PyPS3tools, but the files only matched partially.

Does someone have more information about how to create the custom patch? it would be very useful.

If someone is wondering if I plan to create a tool for that; the answer is no. I don't mess with flash stuff. I only want to learn, since the source code of the web flasher omitted that critical information for other developers.​

Hello aldo,
From what I remember of the discutions I had with Habib, the flash writer is only capable to write entire sectors at given sector adresses.
So the regular nofsm patches are not suitable. Instead the patch is a minimal fraction of coreos blocks of data that includes patched lv0 and spu_pkg_rvk_verifier.self files. The CoreOS files layout and sizes must be exactly the same as the OFW.
So, to make a suitable patch, my DB CoreOS should do the trick.

 

[aldostools]

Hello aldo,
From what I remember of the discutions I had with Habib, the flash writer is only capable to write entire sectors at given sector adresses.
So the regular nofsm patches are not suitable. Instead the patch is a minimal fraction of coreos blocks of data that includes patched lv0 and spu_pkg_rvk_verifier.self files. The CoreOS files layout and sizes must be exactly the same as the OFW.
So, to make a suitable patch, my DB CoreOS should do the trick.

Thank you @littlebalup. Now it has more sense. From your post I understand that the custom patch was created dumping the flash with one specific HFW installed.

Then the nofsm was applied (manually??) to that dump, keeping the files layout.

Then from the patched dump the 3MB were extracted starting at the given sector address. This results in the minimal nofsm patch used by the web flasher.

The patch is applied to both ROS because the flasher doesn't know which one is active. If both ROS are different, one would become corrupted.

Is that correct? Or am I missing something?

@aldostools

below is an improved flash writer for 4.85 by @lmn7 (in case you do not have it). he added some checks (see changelog) and merged the nor/nand versions into one. the js is inside the html and the patch is downloaded as a p3t file.

he was interested in updating it again but not knowing how to make the patch stopped that. he mentioned possibly using the 7mb patch but IIRC that was more work than he had time for.

Thank you @Coro. I will check it.

If the procedure described above is correct, the web flasher could be updated for the versions after 4.85.

 

[littlebalup]

Thank you @littlebalup. Now it has more sense. From your post I understand that the custom patch was created dumping the flash with one specific HFW installed.

Then the nofsm was applied (manually??) to that dump, keeping the files layout.

Then from the patched dump the 3MB were extracted starting at the given sector address. This results in the minimal nofsm patch used by the web flasher.

The patch is applied to both ROS because the flasher doesn't know which one is active. If both ROS are different, one would become corrupted.

Is that correct? Or am I missing something?



Thank you @Coro. I will check it.

If the procedure described above is correct, the web flasher could be updated for the versions after 4.85.

It's even more simple. No HFW is required (I mean HFW and OFW CoreOS are exactly the same. HFW is only required to run the exploit. Not to make the patch).
So, just make a dualboot pup from the OFW with the proper tools keeping the CoreOS file table and file size strictly indentical than the original. Then extract from CoreOS content the data needed.

To make my dualboot, I extract, patch the iso loader and spu_pkg_rvk_verifier modules using Glevand's ps3tools (unself, lv0tool, patchtool, iso_rebuilder). This make the new patched lv0 and spu_pkg_rvk_verifier.self with original proper size (SCEtool don't).
Then I unpack/repack the CoreOS using PUAD. This make the CoreOS with the same file structure than the original.

Or... you can directly use my 4.89 DB
I already made a 3MB flash_489.hex if you want but I'll not share it publicly. PM if you want.

 

[aldostools]

It's even more simple. No HFW is required (I mean HFW and OFW CoreOS are exactly the same. HFW is only required to run the exploit. Not to make the patch).
So, just make a dualboot pup from the OFW with the proper tools keeping the CoreOS file table and file size strictly indentical than the original. Then extract from CoreOS content the data needed.

To make my dualboot, I extract, patch the iso loader and spu_pkg_rvk_verifier modules using Glevand's ps3tools (unself, lv0tool, patchtool, iso_rebuilder). This make the new patched lv0 and spu_pkg_rvk_verifier.self with original proper size (SCEtool don't).
Then I unpack/repack the CoreOS using PUAD. This make the CoreOS with the same file structure than the original.

Or... you can directly use my 4.89 DB
I already made a 3MB flash_489.hex if you want but I'll not share it publicly. PM if you want.

Well HFW is needed any for 4.83 to 4.89. That's why I mentioned HFW.

I guess that this completes the missing information needed for anyone to update their own web flash writer for current and future versions.

I appreciate your offer for flash_489.hex but I really don't needed it. As I commented earlier, my interest is in learn how to create the custom patch. Not to use it, since my console already has CFW.

Thank you @littlebalup & @bguerville for your explanations. Also @Coro and @lmn7 for the improved flash writer.

 

[Louis Garry]

@aldostools

below is an improved flash writer for 4.85 by @lmn7 (in case you do not have it). he added some checks (see changelog) and merged the nor/nand versions into one. the js is inside the html and the patch is downloaded as a p3t file.

he was interested in updating it again but not knowing how to make the patch stopped that. he mentioned possibly using the 7mb patch but IIRC that was more work than he had time for.

Interesting, @lmn7 how to calculate vsh and patch hash?
if(vshchk.hashCode()!='-1196652973')
Thanks.

 

[aldostools]

Interesting, @lmn7 how to calculate vsh and patch hash?
if(vshchk.hashCode()!='-1196652973')
Thanks.

You could put: alert(vshchk.hashCode());
or create a <div id='hash'></div> then write the value to show it:
document.getElementById('hash').innerHTML = vshchk.hashCode();

 

[lmn7]

I know this is late, but I really appreciate all of the information in this thread. I had wanted to update the old flash writer tools for a long time and now that is possible if I ever want to come back to it. I think these tools should keep their legacy status, but it is nice to have an alternative if it's ever needed.