Why iphone reloads from arabic sms
DISCLAIMER
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!
DISCLAIMER 2
')
Don't even try to call it a Wi-fi point!
About 15 hours ago a funny post appeared on Reddit, which told about rebooting an iPhone after a strange message like:
My colleagues and I tried and made sure that it really works. And it does not necessarily work from SMS - the text was enough 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. Since 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 put the system out of order.
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.
Messages crashes for the same reason as the entire iOS, with the only difference being a separate application, it does not provoke the fall of 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. After receiving a new sms from the sender of the "virus", the last message will be the new sms and Messages, logically, it will stop falling.
I wondered why it was all so sad to be hurt, and I created a test project in xCode. When I tried to add the unfortunate text directly in Interface Builder, I got the crash of xCode itself, and it did not open until I deleted the test project from the hard drive.
At 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:
It's more interesting here. We print out the full stack trace with the bt llvm command 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 time of copying bytes of length 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?
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 a productive work week!
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!
DISCLAIMER 2
')
Don't even try to call it a Wi-fi point!
About 15 hours ago a funny post appeared on Reddit, which told about rebooting an iPhone after a strange message like:
Do not send to anyone on the iPhone
Power
لُلُصّبُلُلصّبُررً ॣ ॣ h ॣ ॣ
冗
لُلُصّبُلُلصّبُررً ॣ ॣ h ॣ ॣ
冗
My colleagues and I tried and made sure that it really works. And it does not necessarily work from SMS - the text was enough 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. Since 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 put the system out of order.
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.
Messages crashes for the same reason as the entire iOS, with the only difference being a separate application, it does not provoke the fall of 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. After receiving a new sms from the sender of the "virus", the last message will be the new sms and Messages, logically, it will stop falling.
I wondered why it was all so sad to be hurt, and I created a test project in xCode. When I tried to add the unfortunate text directly in Interface Builder, I got the crash of xCode itself, and it did not open until I deleted the test project from the hard drive.
At 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; 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=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<TLine const*, TCharStream const*, void const* (*)(__CTRun const*, __CFString const*, void*), void*, std::__1::shared_ptr<TBidiLevelsProvider>*, 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 time of copying bytes of length 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?
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 a productive work week!
Source: https://habr.com/ru/post/259007/
All Articles