Need to nip this in the bud cos myths like this spread quickly.
True & seemingly a very difficult problem to address successfully ;-)
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
a) 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. Leftover cookies from other sites are not used anyway so clearing them to help initialization is doubly pointless.
b) similarly caching has no impact on exploit initialization, cache clearing for improving success rates is just as pointless as cookie clearing.
The rumours had been so persistent, they made me doubt & I proceeded to testing both theories a couple of years ago.
According 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.
The only proven success rate improvements came from
A] using a fresh & clean browser with blank home page and no browsing prior to exploit launching
B] using a "browser launch with url" like in the case of XMB links.
C] modding the code
To be honest, there is only one way to improve initialization success rate decisively & permanently in the old exploit code. 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. That bug just needs fixed. 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. 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.
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. And afaik nobody else bothered to try to fix this bug in any of the various releases that rely on that 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. On the contrary, the more the browser memory gets filled, the more likely the data will be located at an offset missed by the search.
So that's the theory but you may ask what does it translate into in practice?
Well, that explains why the exploit never (or at least very rarely) fails when launched from a XMB link, initialization always succeeds because the data is always located at an offset the search algo checks.
On the other hand, using the ps3 browser to navigate the Internet, after a while, go to **ps3xploit.com >Domain no Longer owned by team** (ps3xploit.me =new), look around then finally launch HEN, HAN or whatever other tool hosted there, is extremely likely to result in initialization failure for the reasons described above.
In the improved version of this algorithm used by the PS3 Toolset & in which the bug described above has been fixed, the searches the algo performs are 100% reliable & successful. I have to assume that if the bug was corrected in tools using the old code, initialization in HAN/HEN & all tools using that exploit would become just as reliable.
