@lmn7
I took a couple of hours yesterday to verify my earlier claim that the old exploit code could be made to initialize successfully close to 100% of the time & initialize much faster, if we were to fix the bug & make a few modifications, similar to those I made in the PS3 Toolset code.
Result: my assumption was correct!
I made a proof of concept with the "HAN Enabler + Mount dev_blind" tool included with the PS3HEN files in the official repo (not PS3HEN itself because I am working on Rebug CFW so it's not practical for me to test).
For the purpose of this test, I added basic GUI elements to that exploit page (as it didn't have any) to get logs & rewrote the code related to memory searching, the rest of the code, which I had half forgotten about, contains a number of things that would need removed or changed but it works as is & I am not too enclined to spend much time on it when I have my own project to worry about.
Anyway, the point is that using the revised code, I get 100% success rate on triggering the exploit even after browsing other pages or refreshing the exploit page. I get 80-90% success rate when multiple tabs are opened with complex pages containing Flash movies etc... filling the browser memory container with data.
Because the revised code is much faster too, it can afford to scan 16Mb of RAM in just one run instead of only 2Mb & it covers the entire 0x80000000-0x81000000 memory range by default & I assume that the 10-20% failures with multiple tabs opened is due to the planted data being located in memory above 0x81000000 ie outside the memory search area.
Of course the exploit page I have worked on is tiny making initialization success more likely & the revised code would need tested with every tool that needs it.
Also, as the memory search no longer fails, all the looping code to retry the planting of data in memory when the memory search fails should actually be removed or replaced by code that extends the memory search area, to say 32Mb or 64Mb rather than 16Mb when the exploit data is located higher up than usual in the browser memory container ie higher than 0x810000000, that would ensure exploit initialization success all the time even when multiple tabs are opened etc..
But that would mean code changes in the main function itself, not just swapping a couple of old functions with new versions..
If I have time over the weekend, I will give the memory search area extension idea a try too, see if I can get 100% success all the time no matter what else might be opened & running in the browser, just like the ps3 toolset.
+
button combo, to disable CFW syscalls and remove history of homebrew etc.
