any tips for search tweaks for a higher success rate?
BTW do file write automatically overwrites on existing files? tried replacing a 200mb file from the usb to hdd but the game update becomes small. BTW I set the size to 0xCCF1E83 when doing this
Actually the success rate depends on so many unknown factors it is currently impossible for me to fundamentally improve it without having a full understanding of the webkit heap management.
Now this is my current understanding of the situation & obviously I could be wrong about one or 2 things but still here goes:
Every time something gets added to the page or a js snippet is added or changed, it actually modifies the memory conditions. The javascript interpreter runs on the same memory range as our exploit variables are located. Javascript processing gets done & the interpreter may need on the fly to move a string that's in his way to avoid overwriting it. When this happens, we have a "freeze" condition, if we launch the exploit, one of the strings won't be where it is supposed to be anymore & our execution chain gets broken, the OS freezes then.
That's why new checks were introduced at the end of initRop function to ensure the 3 smallest strings (most likely to be moved) are still at the locations we just scanned them at after all the processing has been done. If not, it's an initialization fail & we reload or end.
This trick is sufficient to reduce the freeze situations to near 0. It works fine but the success rate is what it is & it fluctuates depending on used code.
One way to verify this is simple.
Take the search size for instance, try adding 0x80000 to your current search size & you will see a difference in your success rate. Same thing if you modify the search base actually, allocations begin at 0x80190000, never lower, so you can also use 0x80180000 or even 0x80100000. Try & you will notice a difference in the success rate.
In the same way, using a different javascript code will lead to different rates.
Moreover, the bigger the stack frame string, the bigger the memory range to scan because although a big string is likely to be placed much higher than the others it can also turn out to in the lower range. Then you have to play with probabilities & choose the best scan options knowing that changing search base & search size also alter the conditions... You get the tricky situation here???
However, one of the reason for this headache is rooted in the fact that I have not had the time to properly analyse the webkit heap source to try to improve the odds.
The heap is deterministic so in theory, analysing the webkit heap source code should lead to getting an optimum success rate, whatever that may be.
However imo what we really need is another method altogether. Scanning memory for offsets is like bruteforcing it's wasteful on all levels.
This has been on my mind for a while tbph, I have theoretical plans for a different implementation but again there are time constraints, we cannot work on everything at the same time.
Since October when development really accelerated, we have been working at a high rythm ie 2/3 people working from 6 up to 20h(!) daily for combined work between reversing, coding in C++, testing, making ROP chains, testing again, debugging... No breaks, not even Xmas day or NY. Lol
So in short, I/we will probably look into it at some point in the coming weeks. In the meantime, you guys could experiment with slightly tweaked search sizes and/or search bases. After all it's the objective of this tutorial, don't expect all the answers, get some on your own.
