She's known for being able to break the fourth wall (unlike the other ponies in FiM) and doing other "impossible" things, which I'm figuring the hacker may have connected to breaking out of a sandbox.
You may also want to see: https://secure.wikimedia.org/wikipedia/en/wiki/My_Little_Pon...
He guessed "some predictable addresses allocated by Windows" though. Not detracting from the achievement, but this could arguably be stashed in the non-Chrome side of things.
I ask, as wish to know at a high level what tools and code they are using to find and exploit Chrome.
According to Wikipedia, Windows provides one of the best ASLR on the market. I'm not sure why you are singling out Windows as a weak point here.
Windows has for a long time been the prime target of most exploits, and thus have spent considerable effort, on OS-level, to prevent the potential damage. OS X for instance, has almost none of the OS-level security features found in Windows and is a much easier target to exploit.
http://en.wikipedia.org/wiki/Address_space_layout_randomizat...
According to the same page, ASLR is enabled only for Windows binaries who had the option set at compile/link time. Also I see no sign of your Wikipedia-attributed affirmation; the article even notes a number of deficiencies.
> OS X for instance, has almost none of the OS-level security features found in Windows
I don't know which precise security features you are talking about, but Mac OS X has been iteratively improving on that front: a limited form of ASLR (along with NX bit and W^X) was available since Leopard for 64-bit processes and was iteratively improved in Snow Leopard and Lion. Full parity was brought to 32-bit processes in Lion. Kernel and kexts are fully randomized in Mountain Lion. Also, as far as I know Windows does not enable NX/DEP for non-system processes by default, and does not implement W^X at all. This is a far cry from 'almost none'.