This page has been robot translated, sorry for typos if any. Original content here.

Arabic text iMessage bug remotely reboots any iPhone [FIX]

An extremely unpleasant bug has been detected in iOS. The iPhone, to which a message with a certain set of characters has arrived, restarts, and the Messages application starts to crash.

DISCLAIMER1: Do not try to repeat this with your phones and the phones of colleagues! Judging by the comments, a lot of people have already infected their phones, and there’s no 100% cure yet!

DISCLAIMER2: Don't even try to call a Wi-fi point like that!

DISCLAIMER3: Works also through any social networks or instant messengers!

Do not send anyone to the iPhone !!!!

"Click to show the spoiler - click again to hide ..."

Open the bug message in a separate window (do not open it with the iPhone!).


There are several easy ways to fix the error:

  • open the messages in the last conversation and send the answer to the joker;
  • if you have already opened messages in the dialog list mode, ask a friend to send you any other message;
  • send yourself a message using Siri;
  • create a note and send it as a message to your phone number using the "Share" button.

Also, a medicine was described on Reddit - you need to send SMS of any content to the attacked number, and the glitch will disappear. Let me explain - after rebooting 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 a new SMS and Messages, logically, will stop falling.


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.

Apple workaround

On Thursday, in a new support document , Apple recognizes this bug, which was discovered two days ago, and offers a simple solution to temporarily work around this problem, announcing a fix will be available through a software update in the near future.

The so-called Unicode death code, also known as "Effective Power", occurs because the system tries to decode Unicode characters, causing the device memory to be overloaded and rebooting. Many users report that they are not able to open the iMessage application after receiving this Arabic text.

Apple previously sent statements to the media to confirm this bug, but on Thursday night, the company published an official document recognizing the bug and posting a workaround for this.

Apple is aware of an iMessage issue caused by a specific series of unicode characters and we will make a fix available in a software update. Until the update is available, you can use these steps to re-open the Messages app.

Step 1: Press and hold the Home button to call Siri. After Activ ovanny, 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 he will ask if you want to reply to the message. Say yes.

Step 3: Say something. The actual content of the response does not matter. The important thing is by 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 string containing the character string, or press and hold the malicious message, click Advanced, and then remove 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 option of installing third-party tricks that will prevent the issue from happening in the first place.

Similar to company reporting issued earlier this week, a support document published Thursday night also mentions the company will be releasing patches with a software update soon, apparently together with firmware 8.4, which is still in beta.

They wrote on, if, after receiving such a message, try to open the messages in the dialog list mode, the application will start to crash. “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. Moreover, it doesn’t necessarily work from SMS - it was enough for the 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 breakdown, but a crash of the graphics subsystem, which causes a reboot of the entire system. Because the window with the text of the push message directly enters 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 disable the system.

iMessages crashes for the same reason as the whole iOS, with the only difference being a separate application, it does not provoke the mainthread of iOS itself to crash. Messages crash occurs due to the fact that on the main screen you see the texts of the last sent and received messages.

On the habrahabr project, we created a test project in xCode. When I tried to add the ill-fated text directly to Interface Builder, we got the xCode crash itself, and it did not open until the test project was deleted from the hard drive.

On the second attempt, Arabic text was added with code from a text file, and after several attempts, we found out through trial and error that:

  • UILabel has nothing to do with it; it cannot even show the text, dwelling on the word Power;
  • UITextField is similar;
  • UITextView perfectly displayed the full text;
  • UIButton generated bad access !!

There is already more interesting. We print the full stack trace with the llvm-command bt and get something like the following:

  * thread # 1: tid = 0xf611cd, 0x00000001120ce5f3 CoreText`CopyFromStorage (TRunGlue &, long) + 28, queue = '', stop reason = EXC_BAD_ACCESS (code = 1, address = 0x90)
  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 crash itself occurs inside the CopyFromStorage method (TRunGlue &, long) and, judging by the assembler code, at the moment of copying bytes of length long n from one part of the memory to another (movq 0x90 (% rax),% rdx).

I suppose that this is due to some differences in calculating the length of the Arabic text - apparently, the length is calculated in two places in the program using different methods. Here I can be wrong and ask to correct knowledgeable people.

The bug, apparently, exists as much as iOS, and was noticed, apparently by accident. By the way, the word Power is inserted for a red word and does not play a role. I could not even find out the meaning of the text even with the help of Google Translate (the last character is not at all Arabic, but Chinese, and means Redundancy, which seems to hint!). Perhaps due to the presence of Chinese and Arabic characters at the same time?

For sim, I bow, I wish you all 200 codes, builds without exc_bad_access and stackoverflow and a pleasant end to a productive work week!