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

The iMessage bug with Arabic text allows you to remotely reboot any iPhone [FIX]

IOS detected an extremely unpleasant bug. iPhone, which came with a message with a certain set of characters, reboots, and the application "Messages" begins to fall.

DISCLAIMER1: Do not try to repeat this with your colleagues' phones and phones! Judging by the comments, a lot of people have already infected their phones, and 100% of the medication is not yet available!

DISCLAIMER2: Do not even try to call it Wi-fi point!

DISCLAIMER3: Works also through any social networks or messengers!

Do not send anyone to the iPhone !!!!

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

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


There are a few simple ways to fix the error:

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

Also on Reddit was described a medicine - you need to send sms of any content to the attacked number, and the glitch will disappear. I will explain - after rebooting the attacked phone everything works fine until the victim wants to read sms, i.e. download the built-in Messages app. After receiving a new SMS from the sender of the "virus", the last message will be a new SMS and Messages, logically, will cease to fall.


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 yourself to iMessage.

A workaround from Apple

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

The so-called Unicode death code, also known as "Effective Power", is due to the fact that the system tries to decode Unicode characters causing an overload of the device's memory and causes it to reboot. Many users report that they are not able to open the iMessage application after receiving this Arabic text.

Apple previously forwarded statements to the media, confirmed this bug, but on the night of Thursday, the company published an official document on the recognition of the bug and the placement of a temporary solution for this.

Apple is aware of an iMessage issue caused by a specific series of unicode characters. 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 Activated, ask Siri "to read unread messages."

Step 2: Siri kind of read the message (it's impossible 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 Messaging 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 roundabout way we saw in this issue. We actually published a few 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 the reporting company issued earlier this week, support for the document published on Thursday evening also mentions the company will issue fixes using software updates in the near future, apparently together with firmware 8.4, which is still ?? in the beta stage.

On wrote, if, after receiving such a message, try to open messages in the dialogue list mode, then the application will start to fall. "Messages" will open if you start them directly 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 this really works. And it does not necessarily work from SMS - the text was enough 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 crash, 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 is directly included in the iOS graphics shell, and 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 takes off for the same reason as the whole 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.

The habrahabr project created a test project in xCode. When I tried to add an unfortunate text directly to Interface Builder, I got the crash of xCode itself, and it did not open until I deleted the test project from the hard disk.

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

  • UILabel has nothing to do with it, he can not even show the text, stopping at 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 llvm-command bt and get 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 in principle does not give us anything. The crash itself occurs inside the CopyFromStorage method (TRunGlue &, long) and, judging by the assembler code, when long by n bytes are copied from one part of the memory to another (movq 0x90 (% rax),% rdx).

I assume that this is due to some differences in the calculation of the length of the Arabic text - apparently, the length is calculated in two places in the program by different methods. Here I can make mistakes and ask you to correct people who know.

Bug, apparently, there are as many as iOS, and was seen, apparently, by accident. By the way, the word Power is inserted for a red word and does not play a role. The meaning of the same text I was not able to identify even using Google Translate (the last character - not Arabic, but Chinese, and means redundancy, that seems to hint!). Perhaps because of the presence of Chinese and Arabic characters at the same time?

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