IMessage bug with Arabic text allows you to remotely restart any iPhone [FIX]
In iOS, found a very unpleasant bug. The iPhone, which received a message with a specific set of characters, restarts, and the Messaging application starts to fall.
DISCLAIMER1: Do not try to repeat this with your phones and colleagues' phones! Judging by the comments, many people have already infected their phones, but there is no 100% medicine yet!
DISCLAIMER2: Don't even try to call that Wi-fi point like that!
DISCLAIMER3: It also works through any social networks or messengers!
Do not send anyone to iPhone !!!!
Open a message bug in a separate window (do not open using the iPhone!).
There are some simple ways to fix the error:
- open messages on the last conversation and send a reply to the joker;
- if you have already opened messages in the dialogue list mode, ask a friend to send you any other message;
- send a message to yourself using Siri;
- Create a note and send it as a message to your phone number using the "Share" button.
Also on Reddit the medicine was described - it is required to send SMS of any content to the attacked number, and the glitch disappears. Let me explain - after restarting the attacked phone, everything works fine until the victim wants to read the SMS, i.e. Download the built-in Messages application. After receiving a new SMS from the sender of the "virus", the last message will be the new SMS and Messages, it is logical that it will stop falling.
WORKING FIX from shram.kiev.ua
Ask Siri to read the last unopened message ("Siri read last unread message" or "Siri read my last message"), then create a note and send it to yourself via iMessage.
On Thursday night, in a new help desk document , Apple recognizes this bug, which was discovered two days ago, and offers a simple solution to work around this problem temporarily, announcing a fix will be available through a software update soon.
The so-called Unicode death code, also known as "Effective Power", occurs because the system tries to decode the Unicode characters causing the device to overload the device and causes it to reboot. Many users report that they are unable to open the iMessage application after receiving this Arabic text.
Apple, previously sent statements to the media, confirmed this bug, but on the night of Thursday, the company published an official document recognizing the bug and placing a temporary solution for this.
It is not a problem for the iMessage. Until the update is available, you can use the Messages app.
Step 1: Press and hold the Home button to call Siri. Once activated, ask Siri to "read unread messages."
Step 2: Siri kind of read the message (this is not possible in order to actually speak it in proper English), and then it will ask if you want to reply to the message. Say yes.
Step 3: Say something. The actual content of the answer does not matter. The important thing is sending a message.
Step 4: After the response has been sent, you should be able to open the Messages application. From there, swipe to delete the entire conversation containing a string of characters, or press and hold a malicious message, click Advanced, and then delete the message from the conversation.
This is not the first workaround we have seen in this matter. We actually published several options yesterday. People with hacked devices also have the ability to install third-party tricks that will prevent the issue from happening in the first place.
Like the reporting company issued earlier this week, the support document published on Thursday evening also mentions the company will release fixes using software updates soon, apparently alongside firmware 8.4, which is still in beta stages.
They wrote on habrhabr.ru, if, after receiving such a message, to try to open messages in the dialogue list mode, the application will start to fall. “Messages” will open if you launch them immediately on the screen of a separate conversation, however, when you try to go to the list of conversations, the application will start to fall again.
We tried and made sure that it really works. And it does not necessarily work from SMS - it was enough for a text to appear in any push message, for example from viber, watzup, VKontakte or facebook and other services.
Of course, this is not a reboot or a crash, but a crash of the graphics subsystem, which causes a reboot of the entire system. Since a window with the text of push messages is directly included in the graphical shell of iOS, and is not a separate widget (as, for example, in Android), it is logical that any error at such a high level will bring the system down.
iMessages crashes for the same reason as the entire iOS, with the only difference being a separate application, it does not provoke a drop in the mainthread of iOS itself. Crash Messages is due to the fact that on the main screen you see the texts of the last sent and received messages.
On the project, habrahabr created a test project in xCode. When trying to add the unfortunate text directly in Interface Builder, they got the crash of xCode itself, and it did not open until the test project was deleted from the hard disk.
At the second attempt, Arabic text was added with code from a text file and after several attempts, by trial and error, they found that:
- UILabel has nothing to do with it; he cannot even show text, dwelling on the word Power;
- UITextField is similar;
- UITextView perfectly displayed the full text;
- UIButton generated bad access !!
It's more interesting here. We print out the full stack trace with the bt llvm command and get something like this:
* thread # 1: tid = 0xf611cd, 0x00000001120ce5f3 CoreText`CopyFromStorage (TRunGlue &, long) + 28, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code = 1, address = 0x) frame # 0: 0x00000001120ce5f3 CoreText`CopyFromStorage (TRunGlue &, long) + 28 frame # 1: 0x00000001120ce283 CoreText`TRunGlue :: RotateGlyphs (CFRange, long) + 527 frame # 2: 0x000000011212b71b CoreText`OpenTypeShapingEngine :: ApplyScriptShaping (unsigned int *) + 465 frame # 3: 0x00000001120d0201 CoreText`TOpenTypeMorph :: ApplyShapingEngine (OTL :: GSUB &, OTL :: GlyphLookups &, unsigned int *, CFRange, bool &) + 739 frame # 4: 0x00000001120d1007 CoreText`TOpenTypeMorph :: ShapeGlyphs (bool &) + 331 frame # 5: 0x0000000112056c4e CoreText`TShapingEngine :: ShapeGlyphs (TLine &, TCharStream const *) + 264 frame # 6: 0x000000011205c48b CoreText`TTypesetter :: FinishEncoding (std :: __ 1 :: tuple
*, unsigned int, unsigned char> const &, TLine &, signed char) + 127 frame # 7: 0x0000000112070586 CoreText`TTypesetterAttrString :: Initialize (__ CFAttributedString const *) + 674 frame # 8: 0x000000011207029a CoreText`TTypesetterAttrString :: TTypesetterAttrString (__ CFAttributedString const *) + 158 frame # 9: 0x000000011205d79f CoreText`CTLineCreateWithAttributedString + 63 frame # 10: 0x0000000110c6d8bd UIFoundation`__NSStringDrawingEngine + 18744 frame # 11: 0x0000000110c68f5f UIFoundation`- [NSString (NSExtendedStringDrawing) boundingRectWithSize: options: attributes: context:] + 198 frame # 12: 0x000000010e875788 UIKit`- [UIButton _intrinsicSizeWithinSize:] + 946 frame # 13: 0x000000010ec2466d UIKit`- [UIView (UIConstraintBasedLayout) intrinsicContentSize] + 37 frame # 14: 0x000000010ec24b6c UIKit`- [UIView (UIConstraintBasedLayout) _generateContentSizeConstraints] + 33 frame # 15: 0x000000010ec24930 UIKit`- [UIView (UIConstraintBasedLayout) _updateContentSizeConstraints] + 422 frame # 16: 0x000000010ec2bd25 UIKit`- [UIView (AdditionalLayoutSupport) updateConstraints] + 162 frame # 17: 0x000000010e87521b UIKit`- [UIButton updateConstraints] + 2925 frame # 18: 0x000000010ec2b346 UIKit`- [UIView (AdditionalLayoutSupport) _internalUpdateConstraintsIfNeededAccumulatingViewsNeedingSecondPassAndViewsNeedingBaselineUpdate:] + 242 frame # 19: 0x000000010ec2b53e UIKit`- [UIView (AdditionalLayoutSupport) _updateConstraintsIfNeededAccumulatingViewsNeedingSecondPassAndViewsNeedingBaselineUpdate:] + 124 frame # 20: 0x000000010e0bd354 CoreFoundation`CFArrayApplyFunction + 68 frame # 21: 0x000000010ec2b2ed UIKit`- [UIView (AdditionalLayoutSupport) _internalUpdateConstraintsIfNeededAccumulatingViewsNeedingSecondPassAndViewsNeedingBaselineUpdate:] + 153 frame # 22: 0x000000010d9ef1be Foundation`- [NSISEngine withBehaviors: performModifications:] + 155 frame # 23: 0x000000010ec2b53e UIKit`- [UIView (AdditionalLayoutSupport) _updateConstraintsIfNeededAccumulatingViewsNeedingSecondPassAndViewsNeedingBaselineUpdate:] + 124 frame # 24: 0x000000010ec2ba0e UIKit`__60- [UIView (AdditionalLayoutSupport) updateConstraintsIfNeeded] _block_invoke + 96 frame # 25: 0x000000010d9ef1be Foundation`- [NSISEngine withBehaviors: performModifications:] + 155 frame # 26: 0x000000010ec2b6d6 UIKit`- [UIView (AdditionalLayoutSupport) updateConstraintsIfNeeded] + 231 frame # 27: 0x000000010ec2bdde UIKit`- [UIView (AdditionalLayoutSupport) _updateConstraintsAtEngineLevelIfNeeded] + 146 frame # 28: 0x000000010e623a3d UIKit`- [UIView (Hierarchy) _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 114 frame # 29: 0x000000010e62fa2b UIKit`- [UIView (CALayerDelegate) layoutSublayersOfLayer:] + 536 frame # 30: 0x0000000111e08ec2 QuartzCore`- [CALayer layoutSublayers] + 146 frame # 31: 0x0000000111dfd6d6 QuartzCore`CA :: Layer :: layout_if_needed (CA :: Transaction *) + 380 frame # 32: 0x0000000111dfd546 QuartzCore`CA :: Layer :: layout_and_display_if_needed (CA :: Transaction *) + 24 frame # 33: 0x0000000111d69886 QuartzCore`CA :: Context :: commit_transaction (CA :: Transaction *) + 242 frame # 34: 0x0000000111d6aa3a QuartzCore`CA :: Transaction :: commit () + 462 frame # 35: 0x000000010e5ada2d UIKit`- [UIApplication _reportMainSceneUpdateFinished:] + 44 frame # 36: 0x000000010e5ae6f1 UIKit`- [UIApplication _runWithMainScene: transitionContext: completion:] + 2648 frame # 37: 0x000000010e5ad0d5 UIKit`- [UIApplication workspaceDidEndTransaction:] + 179 frame # 38: 0x0000000110d835e5 FrontBoardServices`__31- [FBSSerialQueue performAsync:] _ block_invoke_2 + 21 frame # 39: 0x000000010e0ea41c CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 frame # 40: 0x000000010e0e0165 CoreFoundation`__CFRunLoopDoBlocks + 341 frame # 41: 0x000000010e0dff25 CoreFoundation`__CFRunLoopRun + 2389 frame # 42: 0x000000010e0df366 CoreFoundation`CFRunLoopRunSpecific + 470 frame # 43: 0x000000010e5acb42 UIKit`- [UIApplication _run] + 413 frame # 44: 0x000000010e5af900 UIKit`UIApplicationMain + 1282 * frame # 45: 0x000000010d91ed0f Islam`main (argc = 1, argv = 0x00007fff522e1330) + 111 at main.m: 14 frame # 46: 0x000000011076e145 libdyld.dylib`start + 1
The last documented function is CTLineCreateWithAttributedString, which basically gives us nothing. The very same crash occurs inside the CopyFromStorage method (TRunGlue &, long) and, judging by the assembler code, at the time of copying bytes long n from one part of memory to another (movq 0x90 (% rax),% rdx).
I assume that this happens because of some differences in the calculation of the length of the Arabic text - apparently, the length is calculated in two places of the program by different methods. Here I can be wrong and ask for knowledgeable people.
The bug apparently exists as much as iOS, and was seen, apparently by accident. By the way, the word Power is inserted for red word and does not matter. The meaning of the text I was not able to identify even with the help of Google Translate (the last character is not Arabic at all, but Chinese, and means Redundancy, which hints, so to speak!). Perhaps because of the presence of Chinese and Arabic characters at the same time?
I will take my leave behind this, I wish you all 200 codes, builds without exc_bad_access and stackoverflow and a pleasant ending of the productive work week!