<!-- hello, this was written by Abraham Masri @cheesecakeufo -->
<!-- I discovered this bug in like 10 minutes -->
If the entire code in the page was whipped up in 10 minutes, then a large part might well be some repetitive copy-paste of a core part...Not exactly sure what this core part does...but given the obvious lack of printable ascii characters (code is way above '0x7F' ), it looks that it could be some unicode type of thing, which then is a bit reminiscing of an old iOS bug back in 2015, as described at this link,
also notice the high frequency of 0xCC and 0xCD throughout the code, which are respectively Breakpoint and INT on x86 architecture -- with its 0xCD's always followed by a single byte whose value is less than 0xA0 -- possibly x86 was used as author's development platform...
https://mega.nz/#!X4piUYwA!zXH1vCliaO00V2v2554vegCnXzQ69jdAX...
11.7MB HTML file. It crashes the tab in Chrome 65.0.3324.2 64-bit and locks up Firefox 58.0 64-bit on Windows for me.
Works on my ff 58.0b16 win10 64bit
I tried to repeat the test in FF and you're right, it does not lock it up, but once I click in the black area of the page, it becomes unresponsive.
Here's an archived version: http://web.archive.org/web/20180117063656/https://iabem97.gi...
a mirror of the page could be found here...
google chrome browser seems to have disabled the display of the content but other browsers may still be fine with it...
if viewed in a hex editor, this same block of patterns repeated over and over again...seemingly to be an effort to overrun the buffer....
The author comment at the top of the page says,
If the entire code in the page was whipped up in 10 minutes, then a large part might well be some repetitive copy-paste of a core part...Not exactly sure what this core part does...but given the obvious lack of printable ascii characters (code is way above '0x7F' ), it looks that it could be some unicode type of thing, which then is a bit reminiscing of an old iOS bug back in 2015, as described at this link,
https://www.reddit.com/r/iphone/comments/37eaxs/um_can_someo...
also notice the high frequency of 0xCC and 0xCD throughout the code, which are respectively Breakpoint and INT on x86 architecture -- with its 0xCD's always followed by a single byte whose value is less than 0xA0 -- possibly x86 was used as author's development platform...
The pattern of bytes above 0x7F isn't anything to do with x86 architecture. It's UTF-8, the most common way to encode Unicode in bytes.
You'll have more success understanding what it's doing if you decode it from UTF-8 first.
4 replies →