Louis Garry
Member
It would be even better if it supports OFW like bgtoolset.
No need to install HFW first.
PS3 PS3Xploit Flash Writer [aka CFW Installer] - (Supports All PS3 Fat Models & Most Slim Models)
- Thread starter STLcardsWS
- Start date
No need to install HFW first.
IMHO an alternative flash method (even if it requires to have HFW+HEN installed) would be a great option.
However if an alternative flash method is ever released, it must be as solid as bgtoolset.
That means that it requires to be tested in several scenarios and models to be public.
Any untested flash tool should not be made public to prevent massive bricks.
Indeed I have been working on a tool like that for webMAN MOD, but I haven't made it public due it haven't been tested.
To be honest I don't think I will be able to release it, due I don't have a console with a flasher to make proper tests.
Last edited:
Agreed, but as long as the tool is based on the old exploit framework, it will always require HFW. There's no getting around that unless a different exploit is used, which is beyond my capabilities and honestly just too much work considering the availability of bgtoolset.
Totally agree, I have a prototype build of the old flash writer which will work on 4.89 but I can only test it myself. I don't have the resources to test it extensively and ensure that it's suitable for a public release, so it has to remain private which is the way it should be. At least information regarding creating the custom patches is now publicly available, so anyone can use that information to create their own patcher tool, majority of the work is already done for them after all.
Here is the official answer by bguerville (in short, the domain was suspended by the host)
https://www.psx-place.com/threads/o...pporting-4-89-new-features.37806/#post-343372
The site will be online again soon in another server. Meanwhile you can try to access the original domain using the following custom DNS addresses:
173.245.59.128
173.245.58.122
arcadekidflo
Member
So, the old page is usable with flash_4.85.hex by lmn7 ?
he did an unofficial update to the 4.85 writer. added checks and no need for usb device. it is HERE. it is the safest of the old tools but bgtoolset is even safer. only works on 4.85 HFW.
For anyone interested, I have updated the unofficial flash writer for 4.89 usage. I confirmed it is working by writing OFW CoreOS data and dumping the flash, verifying the contents.
However, after using the CoreOS data from 4.89 dualboot FW as suggested by @littlebalup, it resulted in a semi-brick. It's not a big deal because it is a semi-brick, but anyone wanting to try this should know that using dualboot FW CoreOS data is NOT viable for an update to the old flash writer.
If anyone has any more info on how I could reproduce the correct patch for 4.89, I'd be interested to know.
However, after using the CoreOS data from 4.89 dualboot FW as suggested by @littlebalup, it resulted in a semi-brick. It's not a big deal because it is a semi-brick, but anyone wanting to try this should know that using dualboot FW CoreOS data is NOT viable for an update to the old flash writer.
If anyone has any more info on how I could reproduce the correct patch for 4.89, I'd be interested to know.
Louis Garry
Member
What do you mean by semi-brick? Did you patched from HFW4.89?
I am willing to send it to select people who own a flasher and completely understand the risks involved. If I send it to anyone who asks I would likely be blamed for them bricking their own consoles. The patch still uses the 3MB version.
I installed HFW 4.89 first, dumped the flash as a backup and then extracted the CoreOS from OFW 4.89. I saved the relevant 3 MBs of data to file and used that as a test patch for the flash writer, which worked. I confirmed it by dumping the flash again and checking both ROS regions, both had the same patch data applied.
Then I extracted the CoreOS from your 4.89 dualboot CFW, again saved the same 3MBs of data and used it with the flash writer which resulted in a brick (console turns on then beeps and turns off again with a flashing red LED). I called it a semi-brick (which now that I'm thinking about it is a poor choice of words) because no unique console data was overwritten, so it is still possible to save it with a physical flasher.
Can you PM me the 3MB patch you have? I would like to compare it with mine in case there are any differences, though I doubt it.
Louis Garry
Member
Yes, I understand the risks, and I'm used to using Teensy as a hardware flasher.
@lmn7, why not use the 7MB patch?
We can use the 7MB patch from @littlebalup which bgtools uses too.
Forget this, my PS3 NAND YLOD again, haha
Last edited by a moderator:
I'm far away my home since few months without access to my archives. But I'll remake it for you.
After a bit of reflexion... at least lv1 patch to disable hash check is missing from DB for a proper patch...
Because the ROP chain used would have to be rewritten entirely to use the 7MB patch, which is beyond my capabilities and honestly just not what I signed up for. I am interested in updating the old flash tools for personal reasons, and because it is very easy to do so in comparison to changing it entirely.
Your reasons are very valid. However the patch of 3MB is very risky if the flasher tool is executed in the incorrect firmware. It expects that the current ROS has a specific order of files.
What Louis Garry suggested is safer, because it overwrites the whole ROS area, preventing overwrite partial files.
Indeed only 5.5 or 6MB is needed to fully overwrite one ROS, due the last sectors are blank (00 filled). That would total 12MB for overwrite both ROS areas, which takes twice the time to write and put in risk the system in that short period of time.
If I recall correctly, the changes needed are not much. Mainly provide the correct patch file of 7MB and adjust the offsets and size.
Last edited:
Looking at the code now I can see that extending it to write the full patch does not seem very complicated and I agree that it would be a good addition. With that being said, I did implement a VSH check in the unofficial writer to prevent people from using it on CFW and there are firmware version checks already implemented. I understand these measures don't make it completely safe, but it is definitely better than nothing.
The real problem that comes with substantially changing the flash writer code is all the testing that would inevitably need to be done afterwards. I have no experience debugging this type of stuff on a PS3 and I seriously doubt I would find many people willing to test such a project given the risks involved. I'm not even planning on releasing the 4.89 version if I can't test it thoroughly enough (which would involve testing on various PS3 models) and that doesn't look likely at this point.
The original flash writer patching code has been widely used and is regarded as being relatively safe so long as the user takes the necessary precautions before using it, and with the additions in the unofficial version it becomes even safer because it places less responsibility on the end user. At some point you have to accept that if people are determined enough they will brick their consoles regardless.
Yes, the real problem is to find testers with a hardware flasher. In any case I suggest to try first on NOR consoles, then test NAND when the code is polished. Even if it was proven to be "safe" all measures that prevent potential bricks are welcome.
In wMM I developed an experimental software flasher of wMM (which is currently disabled due it hasn't been fully tested).
https://github.com/aldostools/webMAN-MOD/blob/master/include/cmd/ros.h
https://github.com/aldostools/webMAN-MOD/blob/master/include/feat/rospatch.h
Some of the checks that I implemented are:
1. NAND / NOR flash type
2. Applicable Version must be 3.56 or lower
3. The system should not be already on CFW
4. nofsm patch file must exist with a size of 7MB (7340000 bytes) / detect it in root of storage devices
5. MD5 of nofsm patch file must match current FW version
6. Ensures that metldr is not metldr.2
7. Writes minimal patch by default (5.5MB = 0x2C80 sectors) (can write full ros with ?full)
8. Verifies that current ROS is valid
9. Verifies written data (full mode only)
10. Both ROS are written (can be forced to write a single ROS using ?ros0 or ?ros1)
Last edited:
GuilloteTesla
Moderator
One question @aldostools, how can I load wMM to patch the ROS if I'm not in CFW? (chicken and egg :P). I don't know if it is possible to run a local web server to host wMM in a PC in order to call the ROS patcher from the OFW PS3.
Unless it's mandatory to install HFW + HEN in order to install wMM, and then patch the ROS to enable CFW.
You answered yourself.... it is intended to work only on HFW+HEN.
All these ps3xploit "webkit applications" are important to be able to run HEN, but once you are on HEN it is easier to create tools using C/C++ than continue using ROP exploit. Obviously this is a longer path (unlike bgtoolset it cannot run directly on OFW), but from a development perspective has some advantages.
bgtoolset is an awesome tool and all the knowledge behind it is admirable. The software flasher in wMM is only a PoC to show that more ambitious projects could be created to complement tools like bgtoolset (not to compete).
Similar threads
-
PS3Xploit Flash Writer (4.93 HFW Req)- Started by Evilnat
- Replies: 10
-
-
-
PS3 qCFW - Arrives to Slim (2500-3000) & SuperSlim (4000-NOR) PlayStation 3 Models
- Started by STLcardsWS
- Replies: 265