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

IMessage bug with Arabic text allows you to remotely restart any iPhone [FIX]

In iOS, found a very unpleasant bug. The iPhone, to which the message came with a certain set of characters, restarts, and the Messaging application starts to fall.

DISCLAIMER1: Do not try this with your phones and colleagues! 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 !!!!

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

Open the 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 will disappear. 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.


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 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 the fix will be available via software update soon.

The so-called Unicode death code, also known as "Effective Power", occurs because the system attempts to decode 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. After activating, 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, a 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, 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. Because The 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 ill-fated text directly to 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 = '', 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 suppose 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?

For this I will take my leave, I wish all 200 codes, builds without exc_bad_access and stackoverflow, and a pleasant ending of a productive work week!