[68c12c16]

a mirror of the page could be found here...

  view-source:https://web.archive.org/web/20180117063656/https://iabem97.github.io/chaiOS/

google chrome browser seems to have disabled the display of the content but other browsers may still be fine with it...

[68c12c16]

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....

  0x00007B90: A5CCBACD 8774CCB4 CD81CC8D CC92CD8C     .....t..........
  0x00007BA0: CD84CC86 CC8FCD8B CD97CD86 CC9BCC8F     ................
  0x00007BB0: CC8ECC95 CC87CC82 CC94CC9B CC92CC92     ................
  0x00007BC0: CC86CD91 CD9BCC86 CC8ECCBD CC84CC8B     ................
  0x00007BD0: CC91CC88 CD9DCC81 CD81CC81 CC84CCBE     ................
  0x00007BE0: CC85CCBE CC86CC84 CD82CC86 CD9DCC89     ................
  0x00007BF0: CC85CC87 CD8CCD9D CC81CC88 CCBFCC9A     ................
  0x00007C00: CC82CC86 CD8CCC90 CD9DCC82 CC9ACC80     ................
  0x00007C10: CC93CC9B CD84CC89 CD82CD8A CCBECD8B     ................
  0x00007C20: CDA0CC83 CC8ACC8E CD98CC89 CD97CC80     ................
  0x00007C30: CD80CC8A CC8FCDA0 CC80CC80 CD84CD80     ................
  0x00007C40: CD8CCD92 CD92CD91 CC90CD98 CC83CC88     ................
  0x00007C50: CD84CD9B CCBDCD9B CC84CC8D CDA0CC8C     ................
  0x00007C60: CC81CD97 CD8BCD86 CD9BCD91 CC8ECCAA     ................
  0x00007C70: CCA7CD87 CD95CCB1 CCA8CCBC CD9CCCA6     ................
  0x00007C80: CCA6CC9D CCAFCCAA CC97CCA0 CC9ECD85     ................
  0x00007C90: CCAACCA4 CCB2CCAB CD8ECCAB CD89CD8D     ................
  0x00007CA0: CCA2CCA8 CCAACC97 CCACCCA3 CCBACD93     ................
  0x00007CB0: CC9ECCA9 CD87CCA8 CD96CCAF CCBACCA7     ................
  0x00007CC0: CCB1CCBB CCA3CCAE CCABCCA7 CD96CCBA     ................
  0x00007CD0: CCAFCCA9 CCA0CCB2 CC96CD95 CCAACCAD     ................
  0x00007CE0: CD9ACCA8 CCB9CCB9 CCB0CCA0 CD88CCBA     ................
  0x00007CF0: CCA9CD9C CCA3CCA1 CCA0CD8D CC98CCA1     ................
  0x00007D00: CCAFCCA1 CC9DCD87 CCA6CC9D CCBACCBA     ................
  0x00007D10: CCAACD9A CCBACD8D CD88CD93 CCB1CCBC     ................
  0x00007D20: CCA1CCB1 CCB3CCA4 CD9ACCB0 CCA9CCB2     ................
  0x00007D30: CC9DCCAC CCADCCB9 CC9ECD89 CD89CD9C     ................
  0x00007D40: CCA5CCA8 CC9DCD89 CCBACCA2 CC9CCC9F     ................
  0x00007D50: CCA5CCBA CD8774CC B4CD81CC 8DCC92CD     ......t.........

The author comment at the top of the page says,

  <!-- 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,

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...

[rspeer]

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.

[68c12c16]

Yes, that's what I meant by "some unicode type of thing.... reminiscing to an old bug emerged two years ago" in my last post...

But on the hand, note the strong pattern of "0xCC" and "0xCD" (could be a coincidence to the x86 Breakpoint/INT code), pacing at a fixed distance throughout the code, as well as the numeric characteristics those parameters (or simply garbage code) to the "0xCC" and "0xCD" exhibit. I just feel that if there are certain numeric relations among those code chunks (for instance, all falling within a certain relatively narrow range, as all the parameters to "0xCD" are less than 0xA0 but above 0x80, a width of 32 units), it probably tells something (assuming it has been crafted in that way, with a meaningful purpose) -- but of course, my chunking method might be wrong and each character point (or instruction) might be longer 2 bytes...

And also note that a 12-MB buffer data devised within 10 minutes always seems to be a bit brute force -- so buffer overrun is quite likely in such case; and then out-of-bound data triggers some unhandlable action (as the app crashes) throughout all the exception handling stack -- in the simplistic scenario, would be a segfault -- but of course, that cheesecakeufo could do a bit more exploration with this buffer overrun -- but I guess that normally takes more than 10 minutes, for normal people....

I stopped working on this bug -- it would be a luxury to play a whole afternoon with this puzzle...do you have any further findings? Well, if I had more time, I probably would change the code a little and open it on an extra device, and see if there are any different effects...

[rspeer]

I saw a tweet about what it looks like (in some piece of software that at least manages to render something): https://twitter.com/BagusAlexandria/status/95347388267712921...

The fact that the embellished t's form these big overlapping blocks makes me think that it's hitting the worst-case behavior of some text layout algorithm.

I don't understand what all the hex digits and apostrophes are for, though.

[68c12c16]

I don't have a spare ios system at hand right now to do more testing on this bug (if the bug is inside the library code and not at the API level, then an emulator usually would not be able to replicate the problem in the same way a real system produces)...

hence I can only make guesses...if I had a spare one, I would try to modify the content of code and see what would happen (do things such as reducing the code size -- most of the code are repetitive -- and see what would happen if we only retain the core part; or only retain the first half of the entire code -- those 0xCC and 0xCD part; or only retain the second half, those displayable ascii chars)...trim the code down to smaller units and test on them individually (in the same sense as modular testing).

[68c12c16]

each displayed lines of characters in that twitter image is exactly the same...they only shift their position a bit.

it looks like the black shades over the character lines are the vestiges left by the non-ascii characters at the beginning of the code.

the displayed part is not just ascii hex and apostrophes characters, there are also punctuation characters there...My guess is that if they are displayed, then that means the system has already successfully handled them and their triggered actions have been contained in defined system behaviors...