May 28, 2015 at 14:44Why does the iPhone reboot from the Arab SMS
DISCLAIMER
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 is no 100% cure yet!
DISCLAIMER 2
Don't even try to call a Wi-fi point like that!
About 15 hours ago, a funny post appeared on Reddit that talked about rebooting an iPhone after a strange message of the form:
My colleagues and I 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.
Of course, this is not a reboot, 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 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.
Also, a medicine was described on Reddit - 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 the SMS, i.e. Download the built-in Messages application.
Messages crashes for the same reason that the whole of iOS, with the only difference being that it is a separate application, it does not cause the mainthread of iOS 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. 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.
I wondered why exactly everything crashes so sadly, and I created a test project in xCode. When I tried to add the ill-fated text directly to Interface Builder, I got the xCode crash itself, and it did not open until I deleted the test project from the hard drive.
On the second attempt, I added Arabic text with code from a text file and after several attempts, through trial and error I found out that:
There is already more interesting. We print the full stack trace llvm-command bt and get something like this:
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!
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 is no 100% cure yet!
DISCLAIMER 2
Don't even try to call a Wi-fi point like that!
About 15 hours ago, a funny post appeared on Reddit that talked about rebooting an iPhone after a strange message of the form:
Do not send anyone to an iPhone
Power
لُلُصّبُلُلصّبُررً ॣ ॣ h ॣ ॣ
冗
لُلُصّبُلُلصّبُررً ॣ ॣ h ॣ ॣ
冗
My colleagues and I 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.
Of course, this is not a reboot, 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 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.
Also, a medicine was described on Reddit - 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 the SMS, i.e. Download the built-in Messages application.
Messages crashes for the same reason that the whole of iOS, with the only difference being that it is a separate application, it does not cause the mainthread of iOS 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. 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.
I wondered why exactly everything crashes so sadly, and I created a test project in xCode. When I tried to add the ill-fated text directly to Interface Builder, I got the xCode crash itself, and it did not open until I deleted the test project from the hard drive.
On the second attempt, I added Arabic text with code from a text file and after several attempts, through trial and error I found out 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 llvm-command bt 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=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!