101–110 of 113 posts
Earlier quoted context omitted.
I believe the solution present on this linked page will help you: https://www.vincedes3.com/save.html Opens imessage again with a message draft so that you can delete the conversation without fetching the linked bug
Warning - this link has dozens of not work appropriate ads on it now.
The linked blog assures people that this can't be used to access data. Once something is crashing an app/OS, can you really say that? I mean, can you be sure there's no one clever enough to capitalize on the underlying software error leading to this state?
That would be a general issue with app crashing, and a huge deal worth it’s own series of articles. iOS’ sandboxing makes it so unlikely this exists, it’s not worth mentioning and the sensational writing might be counterproductive to getting the actual issue fixed. To use an analogy, it’d be like mentioning that someone could hack Google in an article about Gmail downtime.
Earlier quoted context omitted.
Not just simple text, it's UTF-8. Rendering these UTF-8 "text bombs" seems to DoS several applications. This particular one crashes the messages app in iOS, crashes the tab in Chrome, and locks up FireFox. It also crashes several text editors which support UTF-8. Opens quickly in notepad, but takes several minutes in wordpad and it very laggy when scrolling.
> crashes the tab in Chrome, and locks up FireFox Both of which are WebKit wrappers on iOS.
Earlier quoted context omitted.
How do you update software without updating it? I'm literally at a loss with how you would like them to resolve it if you don't want to install updates.
I think what they're getting at it, release an iOS 10.3.4 or whatever so that people who don't want iOS 11 can still avoid this bug. They did this once before, around iOS 6 I believe, when the security certificate for Facetime ran out. And it's understandable. iOS 11 made my iPhone 7 - the newest one at the time - so unusable I sold it and got a different phone. It went from a good, snappy phone, to a slow mess that…
I always cringe a bit when there's an update because the companies never provide any way to downgrade if you're not happy after.
It's not only Apple responsible, I wish there was some kind of consumer protections.
There should always be a way for a consumer to get a product back to the state is was at the time of purchase.
Earlier quoted context omitted.
The text-segment of the code containing the machine instructions is in read-only memory. You won't be able to overflow a heap variable with the intention of writing to the text-segment of memory without causing a segfault.
But with ROP, there's usually no need to write into the text-segment to execute arbitrary code.
Earlier quoted context omitted.
The text-segment of the code containing the machine instructions is in read-only memory. You won't be able to overflow a heap variable with the intention of writing to the text-segment of memory without causing a segfault.
But with ROP, there's usually no need to write into the text-segment to execute arbitrary code.
Earlier quoted context omitted.
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 C…
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.
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...
Earlier quoted context omitted.
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.
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 fee…
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.
Earlier quoted context omitted.
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 fee…
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.
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...