PS3 PS3Xploit Flash Writer (4.90 HFW)

[bguerville]

Someone sent me a PM calling me a "big douche" and asking why I closed the thread. I will answer here for the benefit of all.

Because..."The main dev of unofficial version requested and all active ps3xploit members liked the post." Only reason. I was sure it would be reopened eventually.

[emoji23][emoji23]

 

[STLcardsWS]

Can a mod please close this thread? I don't see the point in talking in circles...

Bottom line is this: 300k thread views, ~200 replies, and I haven't seen a single brick report. So if you're concerned about "safety", think about that statistic before blindly spewing misinformation.

P.S the NAND concerns are more misinformation. No per-console data is overwritten (bguerville has said this himself multiple times), so recovering from a brick is always possible. Even when the flash writer was the only software solution available for jailbreaking, there were no reports of per-console data being overwritten unintentionally.

There is always going to be some degree of inherent risk with these things regardless of the exploit you are using. I don't know why bguerville wants his toolset to be online only and that's his prerogative, but the only motivation behind updating the old project is to have an offline solution and I think it serves that purpose. This is not intended to "compete" with the toolset, that notion is fundamentally ridiculous.

Thread Re-Opened.. No reason for it to be closed.

There is always a risk as you said.
The Flash Writer has always been more riskier then using the toolset.
How much of a risk? I personally do not know so i default to the creator's, until proven otherwise

but the only motivation behind updating the old project is to have an offline solution and I think it serves that purpose.

Then i really do not see the issue here, because i think everyone welcomes that.
There is a release ready but not very well tested. So why push something that is not a need and not tested? That's been the hold-up.

Currently Ps3Xploit team is being asked to test a project they have officially shelved. So of course we are going to hear reasons why they like the Toolset over the Flash Writer when asked about the Flash Writer. I do not think anyone was "Spewing Misinformation" i think its valid concerns.

I think many appreciate your work and the past has shown another solution's is a good thing In the community,

 

[lmn7]

Thread Re-Opened.. No reason for it to be closed.

There is always a risk as you said.
The Flash Writer has always been more riskier then using the toolset.
How much of a risk? I personally do not know so i default to the creator's.



Then i really do not see the issue here, because i think everyone welcomes that.
There is a release ready but not very well tested. So why push something that is not a need and not tested?

Currently Ps3Xploit team is being asked to test a project they have officially shelved. So of course we are going to hear reasons why they like the Toolset over the Flash Writer. I do not think anyone was "Spewing Misinformation",

I think many appreciate your work and the past has shown another solution's is a good thing In the community,

Flash Writer has a higher risk of hard brick on NAND systems. It's not something that can be remediated.

The flash writter lacks any sort of checks on flash memory consistency before and after patching, no console CFW compatibility, no patch integrity checks (which means it can apply a bad patch, rendering your console a shinny brick).

So no, it's not safer. Stop spreading misleading information.

Both posts contain inaccuracies regarding how safe the flash writer really is, and until I said something nobody had corrected them. Probably the most confusing part to me is one of these posts directly contradicts a previous post made by the same user.

I am not pushing anything, all I'm saying is people are really trying to make the toolset seem like the only option here (especially in terms of user safety) which is not true. Should the toolset be used over the flash writer where applicable? Absolutely, but that doesn't mean people need to push misinformation, that benefits nobody.

I personally didn't ask anybody to test anything, I have nothing to do with the 4.91 version. I do not see why any work is being done on it if this narrative that it's extremely unsafe compared to the toolset is being pushed. The reason why I wanted the thread closed is because I am no longer working on this project regardless, so if the 4.91 version gets released it should probably be posted in a separate thread.

 

[bguerville]

Thread Re-Opened.. No reason for it to be closed.

There is always a risk as you said.
The Flash Writer has always been more riskier then using the toolset.
How much of a risk? I personally do not know so i default to the creator's.



Then i really do not see the issue here, because i think everyone welcomes that.
There is a release ready but not very well tested. So why push something that is not a need and not tested?

Currently Ps3Xploit team is being asked to test a project they have officially shelved. So of course we are going to hear reasons why they like the Toolset over the Flash Writer. I do not think anyone was "Spewing Misinformation",

I think many appreciate your work and the past has shown another solution's is a good thing In the community,

Don't get me wrong, it's a good thing people finally take that work a little further, that's not the point, otherwise it would never have been open source.
The Flash Writer was never deemed dangerous per se otherwise we would never have released it but it's a bad design, my own bad design!! That's why I moved on, even though the code can still be useful for certain things obviously..

The thing is, it's like hen, it's the same core code, nobody understands why it's a dodgy implementation which will unavoidably result in issues you could actually calculate statistics for.

The entire thing relies on using unreserved memory, memory which could be used at any time by the browser for one reason or another. That memory is where the entire exploit code and the patches, payload are stored, so basically all that crucial stuff is at the mercy of fate. It turns out because the system is quite deterministic that it works without glitch because often that memory portion is not used, but Murphy's law, what can happen eventually happens and some folks will get fucked..
Another weakness is that the flashing procedure takes place directly on the browser main thread which means that closing, crashing the browser (maybe even changing tabs or loading a new page closes the process, so if you have multi-stack frames in play and exit the browser accidentally or not, it means half the stuff will never be executed.
And of course there's the non standard 3Mb patch thingie too..
That and other issues I won't bother to describe..

These issues would be easy to fix really if you knew what you were doing but few do and none of them bother, I am too busy to go back to this, but I fixed them all in the Toolset already long ago.

 

[lmn7]

The entire thing relies on using unreserved memory, memory which could be used at any time by the browser for one reason or another. That memory is where the entire exploit code and the patches, payload are stored, so basically all that crucial stuff is at the mercy of fate. It turns out because the system is quite deterministic that it works without glitch because often that memory portion is not used, but Murphy's law, what can happen eventually happens and some folks will get fucked..

We knew about this, and it's probably true that there is a chance the browser can use that memory at any point - but in testing we never saw this happen once, not on RPCS3, not on real hardware, never. To add to this, we also re-added the stack frame check before the exploit trigger to prevent this exact issue, which for whatever reason was left out of the official release. We can say there is a chance for things like this to go wrong but if it never happens in practical situations, I don't think it's worth bringing up as a valid (or high) risk.

Another weakness is that the flashing procedure takes place directly on the browser main thread which means that closing, crashing the browser (maybe even changing tabs or loading a new page closes the process, so if you have multi-stack frames in play and exit the browser accidentally or not, it means half the stuff will never be executed.

This is true, but to be honest at some point the end user needs to be expected to know what they are doing, and to be held accountable if they make simple mistakes like this. There's no 100% way to make these things foolproof. I imagine if someone turned off the console while bgtoolset is patching, you would also end up with a brick. One thing I need to mention is, we never had any crashes during the patch process either. Now, you can say this is anecdotal, but we also never got any reports of this since release.

And of course there's the non standard 3Mb patch thingie too..

Can't argue with this, the decision to use the 3MB patches was made because we didn't want to enlarge the scope of the project too much - we knew the patch chain worked and we did not want to go through all of the testing scenarios that would inevitably be required if we had changed it. Remember, in the beginning this was only being worked on by myself and @kostirez1, we did not have the resources to test every single scenario so we elected to use the chain that had already seen widespread use, which as far as we knew had no major reliability issues.

Everybody knows bgtoolset is more robust and much better written and should be used over this, it's obvious because it's an evolution of the PS3Xploit project. Nobody is advocating otherwise. The only thing I want to clear up is the misinformation that's being spread about the flash writer, because I did genuinely put in effort to find workarounds for its limitations. Again, I would prefer to refer to statistics and practical use over theoretical concerns, and if you look at this thread and the comment sections of YouTube videos showing the flash writer, you'll be hard pressed to find anyone mentioning these issues (or by extension anything about their console being bricked). Does that mean it's 100% safe? No, nothing is, but I feel that it's a good indication of what you can expect when using it.

 

[bguerville]

We knew about this, and it's probably true that there is a chance the browser can use that memory at any point - but in testing we never saw this happen once, not on RPCS3, not on real hardware, never. To add to this, we also re-added the stack frame check before the exploit trigger to prevent this exact issue, which for whatever reason was left out of the official release. We can say there is a chance for things like this to go wrong but if it never happens in practical situations, I don't think it's worth bringing up as a valid (or high) risk.



This is true, but to be honest at some point the end user needs to be expected to know what they are doing, and to be held accountable if they make simple mistakes like this. There's no 100% way to make these things foolproof. I imagine if someone turned off the console while bgtoolset is patching, you would also end up with a brick. One thing I need to mention is, we never had any crashes during the patch process either. Now, you can say this is anecdotal, but we also never got any reports of this since release.




Can't argue with this, the decision to use the 3MB patches was made because we didn't want to enlarge the scope of the project too much - we knew the patch chain worked and we did not want to go through all of the testing scenarios that would inevitably be required if we had changed it. Remember, in the beginning this was only being worked on by myself and @kostirez1, we did not have the resources to test every single scenario so we elected to use the chain that had already seen widespread use, which as far as we knew had no major reliability issues.

Everybody knows bgtoolset is more robust and much better written and should be used over this, it's obvious because it's an evolution of the PS3Xploit project. Nobody is advocating otherwise. The only thing I want to clear up is the misinformation that's being spread about the flash writer, because I did genuinely put in effort to find workarounds for its limitations. Again, I would prefer to refer to statistics and practical use over theoretical concerns, and if you look at this thread and the comment sections of YouTube videos showing the flash writer, you'll be hard pressed to find anyone mentioning these issues (or by extension anything about their console being bricked). Does that mean it's 100% safe? No, nothing is, but I feel that it's a good indication of what you can expect when using it.

Have you not noticed that the ONLY code I criticized is the one I wrote myself?
Single threaded, me, multi stack frame, me, the fact that it never moved on to 7Mb patches, me, and the other weaknesses I didn't detail, also of my own design.
I believe I am perfectly entitled to constructively criticize my own past work.
And I don't really care if there is only one issue in 10000 or less therefore giving great stats, it's still one issue too many when it's easy to avoid in the first place.

There's not one single mention of code written by others in my posts.
Consequently I really don't see how any of what I said could be taken as a criticism of anyone else's work.

Good luck with it all. I mean it, sincerely, I always did.
Am through with this convo though.

 

[lmn7]

Have you not noticed that the ONLY code I criticized is the one I wrote myself?
Single threaded, me, multi stack frame, me, the fact that it never moved on to 7Mb patches, me, and the other weaknesses I didn't detail, also of my own design.
I believe I am perfectly entitled to constructively criticize my own past work.
And I don't really care if there is only one issue in 10000 or less therefore giving great stats, it's still one issue too many when it's easy to avoid in the first place.

There's not one single mention of code written by others in my posts.
Consequently I really don't see how any of what I said could be taken as a criticism of anyone else's work.

Good luck with it all. I mean it, sincerely, I always did.
Am through with this convo though.

Every time you bring up an issue with the old project, it feels to me as though you are criticizing us for not fixing it - if that's not your intention, then I apologize for assuming that. There's no animosity here either way.

I never did back then, and I want to personally thank you for making PS3Xploit an open source project, it allowed me to learn much more about the PS3 and these types of exploits in general, so working on it in whatever capacity was a good experience for me, even if I am done with PS3 stuff nowadays.

 

[Saki22]

any progress updates for the next release please

 

[baber]

Ok ps3 ready

 

[RoboKing's Cosmos]

Is this being tested on new hardware? oO
I hope we can maintain our lead ahead of the PS4 scene by unlocking lv0 on later ps3s

 

[aldostools]

Is this being tested on new hardware? oO
I hope we can maintain our lead ahead of the PS4 scene by unlocking lv0 on later ps3s

No, it doesn't work on super slims or slims 25xx & 3xxx with minimum firmware 3.60 or later.

The PS3Xploit flash writer for 4.91 has been "ready" almost one week later after 4.91 was released.

The new version was confirmed working by Joonie on one phat model. Although the main changes should work for slims too, it needs to be checked to be sure that it's 100% safe to release.

 

[NiQ]

No, it doesn't work on super slims or slims 25xx & 3xxx with minimum firmware 3.60 or later.

The PS3Xploit flash writer for 4.91 has been "ready" almost one week later after 4.91 was released.

The new version was confirmed working by Joonie on one phat model. Although the main changes should work for slims too, it needs to be checked to be sure that it's 100% safe to release.

Maybe you should just privately send it to people who are willing to take the risk so they can serve as guinea pigs?

 

[aldostools]

Maybe you should just privately send it to people who are willing to take the risk so they can serve as guinea pigs?

In particular I only trust very few people. Once made public it will spread uncontrollably... as used to happen with Evilnat's "private" betas.

There is no need to rush the release of an untested method when we have a much better online solution with no issues.IMHO it's better to wait until it can be reliably tested.

 

[DippyLychrono]

Hi checking on any update on the flash writer 4.91 since the tool set is down. Hopefully for not too long while the ssl issues are being looked into on finding a reseller for a renewed ps3 compatible ssl to get the toolset site back up for ps3s again.Any update on how the testing and stability of the 4.91 flash writer came? Hoping to see it stable and safe to release soon as a backup if or when the toolset encounters unexpected outages.

 

[RoboKing's Cosmos]

@aldostools @bguerville I dunno if you guys might do this or already did but can you guys add support for OFW offsets as well for the Flash writer? And make it customizable from the background and buttons etc manually. Looks too basic imo. Could use an interesting look for @Evilnat
Maybe some sort of black theme?

 

[aldostools]

@aldostools @bguerville I dunno if you guys might do this or already did but can you guys add support for OFW offsets as well for the Flash writer? And make it customizable from the background and buttons etc manually. Looks too basic imo. Could use an interesting look for @Evilnat
Maybe some sort of black theme?

The flash writer for HFW 4.91 was ready since March 2024. I updated the offets in the html and Joonie updated the flash491.P3T. He also tested it on a NAND console. There haven't been much interest in fully test it on NOR consoles. So I gave up.

The support for OFW offsets uses a private exploit found by bguerville. It was leaked in 2022, but it's usage is unauthorized by the author.

The same happens with the ps3xploit flash writer... it's usage is discouraged by the original author. So it's better to wait until the SSL issues are resolved in ps3toolset.com

 

[aldostools]

The PS3Xploit Flashwriter 4.91 finally was tested on NOR and NAND. It's now released.
https://github.com/aldostools/flashwriter/releases

@STLcardsWS

 

[RoboKing's Cosmos]

Sorry for reviving this thread lol just wondering if there's gonna be ports of it for other firmwares like HFW 4.84-4.89. Ik there is already one available for 4.85 but could use some redos too for not just that but other firmware versions. not everyone upgrades to the latest firmware.

Also to add HFW DEX 4.84

 

[gameboss]

The flash writer for HFW 4.91 was ready since March 2024. I updated the offets in the html and Joonie updated the flash491.P3T. He also tested it on a NAND console. There haven't been much interest in fully test it on NOR consoles. So I gave up.

The support for OFW offsets uses a private exploit found by bguerville. It was leaked in 2022, but it's usage is unauthorized by the author.

The same happens with the ps3xploit flash writer... it's usage is discouraged by the original author. So it's better to wait until the SSL issues are resolved in ps3toolset.com

It's good

 

[alimadhi]

Any plan to update the Great "Flash Writer 4.91" to 4.92
Thankful