- #4.87 custom firmware ps3 install#
- #4.87 custom firmware ps3 mod#
- #4.87 custom firmware ps3 update#
- #4.87 custom firmware ps3 Patch#
- #4.87 custom firmware ps3 code#
I spare you the technical details, to make a long story short, the cleaner the browser memory is, the more likely the memory search is to succeed because the data the algorithm searches for is more likely to be located at an offset that is never missed by the search algo. And afaik nobody else bothered to try to fix this bug in any of the various releases that rely on that code. I found the bug & the algo's other inadequacies while I was implementing a new version of the memory search exploit for the PS3 Toolset 4.xx framework, at the time I had already abandoned any work on the old code. In javascript, string is probably the most optimised object because it is so commonly used, string manipulation is usually faster than arrays or whatever & when it comes to performance, it is often better to stick to using strings when possible.
#4.87 custom firmware ps3 code#
Additionally the old memory search code is extremely slow, using a loop to cut a huge string in small chunks that are parsed into numbers to be compared to a reference value until a match is found, none of this is necessary, it turns out that a simple & fast native js string search function can do the same job at a fraction of the performance cost. I remember posting about this over a year ago or so but I think it went unnoticed, the issue with initialization failures in the old exploit code is caused by a bug in the memory search algorithm which basically fails to check every potentially valid offset as it should. To be honest, there is only one way to improve initialization success rate decisively & permanently in the old exploit code. The only proven success rate improvements came fromĪ] using a fresh & clean browser with blank home page and no browsing prior to exploit launchingī] using a "browser launch with url" like in the case of XMB links. The rumours had been so persistent, they made me doubt & I proceeded to testing both theories a couple of years ago.Īccording to my stats, there is no evidence that cookie and/or cache clearing helps initialization in any way, which confirms the theory, the opposite would have been surprising. Leftover cookies from other sites are not used anyway so clearing them to help initialization is doubly pointless.ī) similarly caching has no impact on exploit initialization, cache clearing for improving success rates is just as pointless as cookie clearing.
Years after the first wave of ps3xploit tools, many people still believe that initialization success rates of the old code used in HAN/HEN can be improved by clearing cookies & clearing cache even thoughĪ) no cookie is used by the old exploit so there is no cookie to clear in the first place & even if there were, clearing it/them should have no impact on initialization success or failure. If jailbreak succeeds (PS3 Toolset makes it clear) & a CFW is installed, any problem after that comes from the setup, past jailbreak operations with the Toolset have nothing to do with it.Ĭlick to expand.True & seemingly a very difficult problem to address successfully -)
#4.87 custom firmware ps3 install#
Generally speaking, there is absolutely no reason to install any firmware twice during jailbreak operations using the Toolset.Īdditionally, jailbreak operations succeed or don't succeed. However, since its release, the PS3 Toolset v1.x uses standard 7Mb no-fsm patches & it ensures that no ROS corruption can take place. I spare you the specific details, in short let us say that without the double OFW installation, that patching method could sometimes make CFW installation fail after flashing in which case the entire Flash Writer process had to be redone.
#4.87 custom firmware ps3 Patch#
That tool used a custom 3Mb patch which corrupted the inactive ROS region whenever it contained a different CoreOS from the active ROS.
#4.87 custom firmware ps3 mod#
#4.87 custom firmware ps3 update#
0 kommentar(er)
