It may be that the iCloud backup has a bug that backs up the information used for app thinning and uses it on restore when it should not. Instead it should use the architecture information from the target device.
Uhm, Apple already buys the majority of the world’s NAND. They buy so much it constrains and chokes the supplies available to other vendors. Do you really think Apple increasing the amount of NAND would be a good thing for non-Apple devices?
Err, I forgot to mention Bitcode is extraordinarily sensitive to the target ABI. So a single Bitcode file cannot be used to compile to both 32-bit and 64-bit, the ABIs re just way too different.
The description of bitcode’s purpose is just a bit wrong.
Bitcode is designed to remove the requirement of needing multiple architecture slices for architectures that are just slightly different. For example, when the iPhone 5 came out it supported an “ARMv7s” ISA. This added a few new instructions to ARMv7 like integer divide to increase performance. However, in order for developers to take advantage of it, their app had to have executable code slices for both ARMv7 and ARMv7s, increasing binary sizes. Furthermore, it required every library ARMv7s code linked to also have an ARMv7s slice.
This quickly became a pain in the ass and ARMv7s was dropped in Xcode 6.
Bitcode would address this issue. A developer would compile their app to Bitcode (a specific type of LLVM IR) and then Apple would later compile it fully into the target ISA.
This is especially relevant for ARMv8 as ARMv8.1 is the latest version with slight changes.
Slow installation of Xcode? Xcode doesn't have an installer. You either download the app and copy it to wherever via drag and drop or grab it from the Mac App Store.
They have the app name, there's no reason to do that with a UUID
But as I mentioned before, there's no phishing support in XcodeGhost as their use of UIAlertView doesn't allow for any text input fields. Even if a different malware tried to phish with a fake dialog, real Apple ID password dialogs on iOS never have a blank entry for the username, it's always part of the dialog text because iOS knows what your Apple ID is. This makes it significantly easier to not be fooled by just taking a cursory glance of the dialog.
Why do you ask? It is a damaged executeable... or so the dialog says.
Is this some kind of weird, surreal art project of yours? You just asked in response to my post that included a screenshot of the dialog:
Gatekeeper is not preventing third party apps from launching, it only asks: "look, this is a third party app, downloaded from the internet, do you want to launch it anyway?" Guess what I answer: yes!
There is no OK, Open, or "Yes" button on that Gatekeeper dialog.
It's not that they were trying to bypass a payment (Xcode is free to download). It's that Apple's severs are just so damn slow if you can't get access to their content distribution network. Sadly, this is pretty much the case of everyone in China due to the Great firewall of China that strangles access to non-China networks.
It also used to be true if you used Google DNS because previous primary Apple's CDN, Akamai, used DNS to route traffic. In that case, many developers would rather use BitTorrent to grab Xcode than to disable Google DNS.
The real issue is the fact that these developers disabled Gatekeeper. Gatekeeper would have prevented infection.
The author of XcodeGhost released the source after they heard what was happening. It includes an apology at the bottom (in Chinese) that makes it seem like it was just a proof of concept and he had no intention of it getting out but was picked up and spread via Baidu by others.
The PoC angle would explain why it looks so damn much like any other basic analytics package. This is also likely why Apple's app scanners didn't pick it up, it doesn't do anything that's not permitted. The only weirdness is that it tries to hide from the debugger, but that's also done by legitimate apps that use DRM.
I found about about the code on GitHub from a fellow Mac/iOS developer/reverse engineer. As for getting samples of the actual infected Xcode, the author of the Palo Alto Networks article uploaded it to his DropBox account so others could confirm the findings and detect the malware. That's where I got the infected Xcode from for my own tests.
If they had done it, it wouldn't have been the same malware or the same code. These articles are about the actual XcodeGhost malware in the wild. Not some made up version everyone seems to wish existed.
Wait, you seriously said, "Sure, while XcodeGhost doesn't do anything they say XcodeGhost does, a totally different piece of malware could possibly do it in the future. Maybe."?!
Then in what way would that have anything to do with XcodeGhost, which these articles are about?
The entire reason an Xcode infected with malware even ran is because the developers that fell for it had to explicitly bypass gatekeeper (Mac OS X's built in anti-malware), which otherwise prevents the infected Xcode from launching.
The name might be (although it's easy to change it to an arbitrary value in Settings -> General -> About and can't really be considered a unique value), but the identifierForVendor is not. It's only the same for apps with the same bundle ID prefix on a device (apps from the same developer). Different infected apps will have entirely different identifiers.
Huh? Here's what the article I just linked to says:
In previous reports, we discussed that XcodeGhostâ(TM)s malicious code can be used for phishing by prompt deceptive alert dialog with built-in remote control functionalities. Here we actually made a mistake in our initial reporting. In the current version of the code, XcodeGhost cannot be directly used to phish iCloud passwords. However, by changing a few simple lines of code, it can do that. .
In iOS, if an app prompts a dialog by the UIAlertView class, thereâ(TM)s a property alertViewStyle to specify which kind of dialog it wants to show. For example, if a password input dialog is needed, the property should be assigned to UIAlertViewStyleLoginAndPasswordInput. If the iOS developer didnâ(TM)t specify any value, by default the dialog will have no input form but is just an alert with message and buttons.
We checked all versions of malicious files in XcodeGhost we have available, and didnâ(TM)t find any one of them specified this property when prompting the alert dialog. Hence, current XcodeGhost cannot be directly used for iCloud password phishing.
It seems you didn't actually bother to look at the source code? It doesn't not attempt to phish anything. I even linked to the precise line of code for the alert creation.
It's actually the opposite. It's much, much less malicious that people say. The source code is available.
For one, it cannot be used for phishing attacks. The UIAlertView is shows has no text input fields and it never attempts to get anything from the dialog other than the integer value of the button that was pressed.
It also cannot get the UDID of the device because it uses -identifierForVendor which is a UUID that is specific to that specific app, so it can't be used to track users. iOS can and will change it.
It can't be used to dial premium services either as iOS always shows a dialog when opening telephone URLs and iOS 9 always shows a dialog when using URLs that open another app. But the fact it can open Twitter so what? It can't do anything with that. It can't control Twitter.
This functionality was actually designed to open the App Store so the user can review/rate the app or to show users similar apps.
It's even significantly less bad than most ad/analytics packages.
Xcode is signed and Gatekeeper warns about a corrupted binary. The issue is that these developers that were infected intentionally disabled Gatekeeper checks so they could run the infected Xcode.
Uhm, the username and password entry is required before the controlling app even gets a chance to control anything, an admin has to approve the controlling.
That is, the approval window (let's call it B) the article is talking about showing is not the approval window (that requires an admin's username and password, let's call it A) shown in order to allow one application to control another. A is shown before B is shown.
Yeah, the AppleScript only works after the user has entered the administrator's username and password to allow it to use accessibility features to control other applications
Slashdot Mirror
It may be that the iCloud backup has a bug that backs up the information used for app thinning and uses it on restore when it should not. Instead it should use the architecture information from the target device.
Uhm, Apple already buys the majority of the world’s NAND. They buy so much it constrains and chokes the supplies available to other vendors. Do you really think Apple increasing the amount of NAND would be a good thing for non-Apple devices?
Err, I forgot to mention Bitcode is extraordinarily sensitive to the target ABI. So a single Bitcode file cannot be used to compile to both 32-bit and 64-bit, the ABIs re just way too different.
The description of bitcode’s purpose is just a bit wrong.
Bitcode is designed to remove the requirement of needing multiple architecture slices for architectures that are just slightly different. For example, when the iPhone 5 came out it supported an “ARMv7s” ISA. This added a few new instructions to ARMv7 like integer divide to increase performance. However, in order for developers to take advantage of it, their app had to have executable code slices for both ARMv7 and ARMv7s, increasing binary sizes. Furthermore, it required every library ARMv7s code linked to also have an ARMv7s slice.
This quickly became a pain in the ass and ARMv7s was dropped in Xcode 6.
Bitcode would address this issue. A developer would compile their app to Bitcode (a specific type of LLVM IR) and then Apple would later compile it fully into the target ISA.
This is especially relevant for ARMv8 as ARMv8.1 is the latest version with slight changes.
Slow installation of Xcode? Xcode doesn't have an installer. You either download the app and copy it to wherever via drag and drop or grab it from the Mac App Store.
They have the app name, there's no reason to do that with a UUID
But as I mentioned before, there's no phishing support in XcodeGhost as their use of UIAlertView doesn't allow for any text input fields. Even if a different malware tried to phish with a fake dialog, real Apple ID password dialogs on iOS never have a blank entry for the username, it's always part of the dialog text because iOS knows what your Apple ID is. This makes it significantly easier to not be fooled by just taking a cursory glance of the dialog.
Why do you ask? It is a damaged executeable ... or so the dialog says.
Is this some kind of weird, surreal art project of yours? You just asked in response to my post that included a screenshot of the dialog:
Gatekeeper is not preventing third party apps from launching, it only asks: "look, this is a third party app, downloaded from the internet, do you want to launch it anyway?"
Guess what I answer: yes!
There is no OK, Open, or "Yes" button on that Gatekeeper dialog.
So where exactly is the OK or Open button on the dialog I just posted a screenshot of?
That Palo Alto article has been updated it now includes
It's not that they were trying to bypass a payment (Xcode is free to download). It's that Apple's severs are just so damn slow if you can't get access to their content distribution network. Sadly, this is pretty much the case of everyone in China due to the Great firewall of China that strangles access to non-China networks.
It also used to be true if you used Google DNS because previous primary Apple's CDN, Akamai, used DNS to route traffic. In that case, many developers would rather use BitTorrent to grab Xcode than to disable Google DNS.
The real issue is the fact that these developers disabled Gatekeeper. Gatekeeper would have prevented infection.
The author of XcodeGhost released the source after they heard what was happening. It includes an apology at the bottom (in Chinese) that makes it seem like it was just a proof of concept and he had no intention of it getting out but was picked up and spread via Baidu by others.
The PoC angle would explain why it looks so damn much like any other basic analytics package. This is also likely why Apple's app scanners didn't pick it up, it doesn't do anything that's not permitted. The only weirdness is that it tries to hide from the debugger, but that's also done by legitimate apps that use DRM.
I found about about the code on GitHub from a fellow Mac/iOS developer/reverse engineer. As for getting samples of the actual infected Xcode, the author of the Palo Alto Networks article uploaded it to his DropBox account so others could confirm the findings and detect the malware. That's where I got the infected Xcode from for my own tests.
If they had done it, it wouldn't have been the same malware or the same code. These articles are about the actual XcodeGhost malware in the wild. Not some made up version everyone seems to wish existed.
Wait, you seriously said, "Sure, while XcodeGhost doesn't do anything they say XcodeGhost does, a totally different piece of malware could possibly do it in the future. Maybe."?!
Then in what way would that have anything to do with XcodeGhost, which these articles are about?
The entire reason an Xcode infected with malware even ran is because the developers that fell for it had to explicitly bypass gatekeeper (Mac OS X's built in anti-malware), which otherwise prevents the infected Xcode from launching.
The name might be (although it's easy to change it to an arbitrary value in Settings -> General -> About and can't really be considered a unique value), but the identifierForVendor is not. It's only the same for apps with the same bundle ID prefix on a device (apps from the same developer). Different infected apps will have entirely different identifiers.
Huh? Here's what the article I just linked to says:
Sigh. You do realize that I linked to a newer article that says they made a mistake about the capabilities? You could have at least read thatâ¦
The Network Workd article that is full of inaccuracies. Hell, anyone that's used iOS should know a dialog is shown before any number can be dialed.
First, I'm not "some poster" and two, I'm suggesting you read the updated article that says phishing is not possible with XcodeGhost.
Because you can verify that it's the same code by simply looking at the disassembly in the Palo Alto Networks articles?
The author of said article confirmed it was the same source code and updated his post after I pointed out the discrepancy.
It seems you didn't actually bother to look at the source code? It doesn't not attempt to phish anything. I even linked to the precise line of code for the alert creation.
It's actually the opposite. It's much, much less malicious that people say. The source code is available.
For one, it cannot be used for phishing attacks. The UIAlertView is shows has no text input fields and it never attempts to get anything from the dialog other than the integer value of the button that was pressed.
It also cannot get the UDID of the device because it uses -identifierForVendor which is a UUID that is specific to that specific app, so it can't be used to track users. iOS can and will change it.
It can't be used to dial premium services either as iOS always shows a dialog when opening telephone URLs and iOS 9 always shows a dialog when using URLs that open another app. But the fact it can open Twitter so what? It can't do anything with that. It can't control Twitter.
This functionality was actually designed to open the App Store so the user can review/rate the app or to show users similar apps.
It's even significantly less bad than most ad/analytics packages.
Xcode is signed and Gatekeeper warns about a corrupted binary. The issue is that these developers that were infected intentionally disabled Gatekeeper checks so they could run the infected Xcode.
Uhm, the username and password entry is required before the controlling app even gets a chance to control anything, an admin has to approve the controlling.
That is, the approval window (let's call it B) the article is talking about showing is not the approval window (that requires an admin's username and password, let's call it A) shown in order to allow one application to control another. A is shown before B is shown.
Yeah, the AppleScript only works after the user has entered the administrator's username and password to allow it to use accessibility features to control other applications
It is isolated. In order to interact with it, a user must explicitly permit it by entering an admin's username and password.