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

Coldheart2236 said:
Correct. Use the 4.85 flash dumper and writer to first backup your NAND and verify it with PyPS3checker, and then patch it with flash_485.hex, then re-dump and verify again, then safely reboot and install CFW so long as you don't receive any 'Dangers' in the PyPS3checker checklog.

Edit: Louay is right. Install HFW twice (once by recovery menu if necessary) and then apply the exploit as described above.
Click to expand...

Everything went great, thank you guys so much. Now on Rebug 485.
 
Really need help here my ps3 died and I need to downgrade my replacement to use an exploit that'll let me transfer the hardrive directly as I couldn't back up.

Can this work if my ofw version is 4.80?
 
and do i still need to go to the website in my ps3 browser that page is inaccessible it's just a white screen i guess sony blocked it?
 
T_dab said:
Really need help here my ps3 died and I need to downgrade my replacement to use an exploit that'll let me transfer the hardrive directly as I couldn't back up.

Can this work if my ofw version is 4.80?
Click to expand...


nevermind the version question i just need to know if i still need to use the browser to the website for this or if there's a way around the apparent domain block?
 
ok nevermind again i solved the webpage issue by closing the browser and opening a fresh one after restarting my system apparently.
 
bguerville said:
All ps3 firmware builds from 4.82 to 4.85 (OFW/HFW/CFW) are supported by the Flash Memory Manager & the other tools in my new toolset. The Flash Memory Manager tool is currently in its "beta testing" phase. ETA hopefully for NY..
Click to expand...

Thanks for the reply.
We can still use 2.0 on 4.75 HFW, is that right?
I saw the flash_hex file is updated to 4.85, is this different from 4.82 hex file?
 
jjkkyu said:
Thanks for the reply.
We can still use 2.0 on 4.75 HFW, is that right?
I saw the flash_hex file is updated to 4.85, is this different from 4.82 hex file?
Click to expand...
With 2.0, only one ps3 fw version is supported at any given time, usually it is the latest fw released by Sony unless a new fw update has just been pushed & 2.0 has not yet been updated.

This was a choice we made unanimously at the time to help limit the number of user mistakes ending up in console bricking due to the fact that 2.0 doesn't check the patch file validity.

So if you use the very latest Flash Writer 2.0 update, only 4.85 is supported. And of course, as Flash Writer 2.0 cannot support any OFW after 4.82 because one of the webkit exploits it uses was patched, the latest update will only work on HFW 4.85 & NOT on OFW 4.85.

The hex file used by Flash Writer 2.0 corresponds to a 3Mb chunk of CoreOS that includes the system files that need patched to be able to install CFW.
When a new official fw update is pushed, if any official system file has changed inside the 3Mb CoreOS chunk, then in the updated Flash Writer 2.0, the flash.hex must also be modded to reflect those changes.

============================

On the other hand, my new toolset supports all fw versions released after 4.81.

The code of the various tools, including the Flash Memory Manager, actually works with older fw versions (down to 4.10+ at least, maybe even older) however the new toolset can only be accessed via https (no http allowed) & the SSL certificate it uses is not supported on a ps3 running a fw released before 4.82.
This limitation could of course be addressed by buying a SSL certificate that would work on fw versions older than 4.82 but given the price of such a compatible SSL certificate, I don't think it will ever happen, or at least not without a significant increase in donations.

The Flash Memory Manager detects your flash memory chip type, console type, kernel type as well as vsh type & whether or not custom syscalls for peek/poke can be found.
With that data, the FMM adjusts the GUI options, it gives users the possibility to patch the Flash Memory or not & if it does, it also gives the possibility to download the correct no-fsm patch file or use a local copy. The patch file is hashed with sha256 when loaded in memory just before patching & again depending on results, the FMM adjusts the GUI, the patching operations can only continue if the no-fsm patch file hash matches the one expected for your ps3 system according to the data detected earlier.

For info, the FMM does not use the same hex patch file format as the Flash Writer 2.0. The 3Mb chunk has been replaced by a full 7Mb no-fsm patch, the exact same no-fsm patch files that are used by pyps3patcher (pyps3tools by littlebalup).
So basically, the FMM uses the same no-fsm patch files as hardware flashing does.
 
Last edited:
bguerville said:
The code of the various tools, including the Flash Memory Manager, actually works with older fw versions (down to 4.10+ at least, maybe even older) however the new toolset can only be accessed via https (no http allowed) & the SSL certificate it uses is not supported on a ps3 running a fw released before 4.82.
This limitation could of course be addressed by buying a SSL certificate that would work on fw versions older than 4.82 but given the price of such a compatible SSL certificate, I don't think it will ever happen, or at least not without a significant increase in donations.
Click to expand...
I'm confused about this, are you saying that your new toolset will only be accessable via your web server and therefore requires https to be used, or does this new exploit rely on some kind of SSL vulnerability?
 
lmn7 said:
I'm confused about this, are you saying that your new toolset will only be accessable via your web server and therefore requires https to be used, or does this new exploit rely on some kind of SSL vulnerability?
Click to expand...
I created the toolset to provide users with a responsive GUI for flashing consoles as safely as possible & managing files, it was not an easy task given the ps3 browser (and plugins) single thread model & the absence of Web workers.

The toolset can only run from the ps3xploit web server using https.
In theory, it would be possible to rewrite part of the code & use the new exploit in an offline (local server or even local files) version, keeping in mind that the GUI would require jquery/jqueryui as well as jquery plugins, about 500kb of minified code..
In practice however, no offline version is planned for the moment, I will release the online toolset's 3 tools then move on to a more important ps3 exploitation project.
 
Last edited:
bguerville said:
I created the toolset to provide users with a responsive GUI for flashing consoles as safely as possible & managing files, it was not an easy task given the ps3 browser (and plugins) single thread model & the absence of Web workers.

The toolset can only run from the ps3xploit web server using https.
In theory, it would be possible to rewrite part of the code & use the new exploit in an offline (local server or even local files) version, keeping in mind that the GUI would require jquery/jqueryui as well as jquery plugins, about 500kb of minified code..
In practice however, no offline version is planned for the moment, I will release the online toolset's 3 tools then move on to a more important ps3 exploitation project.
Click to expand...
I was hoping there would be support for local web servers. I learned a lot from your original ROP exploit framework, would be interesting to take a look at this new toolset. Regardless, I look forward to the release.
 
lmn7 said:
I was hoping there would be support for local web servers. I learned a lot from your original ROP exploit framework, would be interesting to take a look at this new toolset. Regardless, I look forward to the release.
Click to expand...
I understand & I am sorry to disappoint.
I think the online version will serve its purpose though, after all, for most users, these tools are not really meant to be used on a daily basis but rather in quite exceptional circumstances, unlike tools such as HAN or HEN for which local versions make sense.

One of the most important aspect of the new framework implementation is that it enables the port of any C code snippet to js, using a js syntax close to C. All ROP is run transparently behind the scenes.

For example:

Consider this C snippet to print to console the string: "pointer offset 0x......" where 0x.... is the 32bit hex address in heap allocated memory of the ptr variable where the string itself is stored.

C code:

char* ptr = (char*)malloc(0x50);
const char* test = "pointer offset 0x%4X";
sprintf(ptr, test, ptr);
printf(ptr);
free(ptr);

Same code but rewritten in js for the new ROP Framework:

var ptr = libc.malloc(0x50);
var test = heap.store(("pointer offset 0x%4X").toAscii8()); //heap.store is a function that stores an ascii string in memory & returns its offset
libc.sprintf(ptr,test,ptr);
libc.printf(ptr);
libc.free(ptr);
heap.free(test);

With C code porting made so easy, in theory, there is no limit to what application you can write within the constraints of the ps3 system & available resources.
Unfortunately (lol) in practice there is still one limitation in play, the single thread model of the browser means that if ever some of the code requires running time consuming rop chains (file read/write, Flash memory read/write), you need to run them in separate threads otherwise the browser display freezes intermittently for the duration of time consuming commands & any hope of a decent GUI gets lost.
And without a way to generate custom bytecode to execute (no JIT generating bytecode to exploit in webkit or in Flash plugin, I dunno about Java but I surmise it's the same), new threads must also run on ROP only and without javascript logic support to process ROP returns like the framework does, making things more complex to develop.
If only ps3 webkit or Flash had featured Web workers, then there would really be no limitation at all...

Depending on the app you write, this limitation is a problem or not, but because the toolset tools mostly use time consuming ops, this limitation is the very reason why it took me 6 months to put the GUI together using multithreading, it was the only way I found to get stuff like progress bars & dialogs to work..

I am not planning to release any source code with the toolset either. The rop framework source should eventually be released with the next project though.
Next project is lower level, supervisor & hypervisor based, I will put the framework to good use without having to worry about browser display, GUI elements & multiple thread management..
If you are really interested in the inner workings of the new framework, we can eventually speak further by pm after the toolset release.
 
Last edited:
bguerville said:
I understand & I am sorry to disappoint.
I think the online version will serve its purpose though, after all, for most users, these tools are not really meant to be used on a daily basis but rather in quite exceptional circumstances, unlike tools such as HAN or HEN for which local versions make sense.
Click to expand...
It would have been cool to tinker with it, but I understand the reasoning behind the decision.

bguerville said:
One of the most important aspect of the new framework implementation is that it enables the port of any C code snippet to js, using a js syntax close to C. All ROP is run transparently behind the scenes.
Click to expand...
It sounds like a very ambitious project especially considering the limitations of the PS3's browser. Looks like you've also addressed some issues from the original framework. Will be interesting to see how it works when it releases.

bguerville said:
If you are really interested in the inner workings of the new framework, we can eventually speak further by pm after the toolset release.
Click to expand...
Sounds good.
 
Hi all, currently have a NOR system (CFW capable) on 4.86.1 HFW, HEN installed. I am wanting to install a CFW, I understand there isn't a 4.86.hex available or a writer.

Using the PS3xploit website, I've accessed the PS3 toolset page to view my flash memory using the Flash Memory manager tab.
Gained a copy of my flash and validated it, also downloaded the nofm_486 patch file.

My question is, is there anyway I can patch the flash so I can install a CFW using the tools currently available?

I am trying to avoid bringing out my E3 flasher, its been put away nicely with enthusiasm since HFW.

Thanks in advance.
 
Last edited:
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 must log in or register to reply here.

Similar threads

Back
Top