转载

一个iOS程序员对XcodeGhost事件的解析与个人见解

　　文/胖花花

　　先放出我个人的结论：

这次 iCloud 的密码泄露了吗？不可能的事。
自称作者的说明可信吗？看过源码之后，我基本是相信的。
这件事很严重吗？影响面很广，但影响力不大。

　　事情经过

　　经过已经传的沸沸扬扬的了，我就不再重复了。简单说，就是编写 iOS App 的工具被修改过了，导致所有被使用了这个非官方提供的工具编译出来的 App 都做了一些不该做的事情。

　　那么第一个问题就来了，为什么会有人用非官方的被修改过的工具呢？微博上各种黑苹果啊、居然用盗版软件的乱喷，你们这样不懂装懂真的好吗？

　　什么叫黑苹果？就是在非 Mac 硬件上安装苹果的操作系统。如果你有闲时间你真的可以试试，不折腾死你才怪！

　　现在哪个互联网公司缺钱？一个比一个能烧钱，还会去折腾个黑苹果？时间就是成本，有你那折腾黑苹果的功夫，人家一个版本都发布出来了！

　　哪能下载到 Xcode ?

　　苹果官方提供了几个下载渠道：

Mac App Store

首先第一个，是所有人都能使用的 Mac App Store 应用市场，里面只提供最新的稳定版本。但是这个 Mac 的应用市场有多难用呢，我专门给大家截两张图看看：（后面的时间是预估的总用时）

当然，并不是所有人的速度都是这样，这和你所用的运营商、下载的时间段都有关系，有些人的速度可能会很快。
beta 版下载 https://developer.apple.com/xcode/download/

有些时候，可能需要的是未正式发布的 beta 测试版本。比如 iOS9 正式发布前，需要用有 iOS9 SDK 的 Xcode 7 beta 版本，来开发对应 iOS9 新特性的 App。

这里需要开发者账号登录，HTTP 直接下载，我再给大家截个图看看：

这里提供的信息只有这些，没有 MD5 SHA1 之类的校验码
历次正式版本下载 https://developer.apple.com/downloads/

这里能找到 Xcode 的历次稳定正式发布版本，当 Xcode 7 在 16 日正式发布时，这里也能下载到和第一种方式一样的版本了，下载方式和上面一样，也同样需要登录开发者账号，速度也和之前差不多，这里提供的信息就更简单了：

所以当需要新的 Xcode 的时候，通过迅雷下载官方链接应该算是最能接受的方式了吧。

刚开始也有人宣称这种方式下载的 Xcode 也被污染了，但后来他本人 @谁敢乱说话也澄清了，通过迅雷复制官方地址链接下载的是干净的。（我自己之前通过迅雷下载的 Xcode 7 GM 版本，也检查过，是没有被污染的）

　　最后就是这次中招的下载地址了：国内网盘了。

　　至于为什么会有人选择用国内的网盘呢？除了懒之外，我真的找不出其他借口了：懒得找链接？懒得登录开发者账号？懒得去申请开发者账号？。。。

　　然后在百度里一搜，发现有“好心人”在网盘里上传了各个版本的 Xcode ，省事又省力，何乐而不为吧？

　　至于苹果官方确实也存在一些问题：下载速度慢、没有提供校验码。但你要拿这个当挡箭牌的话，就又证明了你的懒了。

　　遇到问题，首先想到的应该是怎么解决，而不是去逃避。

　　为什么苹果没有审核出来？

　　苹果的审核机制分机器扫描和人工审核：

机器扫描只是去看看你有没有使用苹果私有的接口。
人工审核简单说就是去使用 App，看看有没有色情啊反动啊不符合苹果利益之类等等的东西。

　　而注入的代码，已经被污染过的 Xcode 融入成了 App 的一部分了，在苹果看来，这只是相当于是你程序自身的一个功能了。

　　代码没有使用任何不合法的接口，所以机器扫描没有任何问题；

　　收集的信息没有违反苹果的规定，而且这些信息本身也是被允许获取的（下面会具体说明），再加上人工审核也看不到这个功能，所以人工审核也没有问题。

　　举个例子，地铁安检，规定了很多不能携带的物品，你带了只铅笔，然后再地铁里伤了人，这不能怪地铁安检不严吧？

　　泄露了什么？

　　源码公布之前，也有人逆向分析过，和现在作者公布出来的源码表现是一致的。

　　注入的代码采集并传递的信息：（名称为源码中变量名）

bundleID
每个 iOS App 都有一个唯一的 ID，这是开发者自己定义的一个字符串。
app

收集的是 bundleName，App 包的名字
timeStamp

时间戳，记录当前时间。
osversion

手机系统版本，比如 9. 0 8. 4 之类的。
devicetype

硬件设备类型，比如是 iPhone6 还是 iPhone5s，可在这里对照查询。
language

系统设置的语言类型，比如中文是 zh-Hans-CN
name

设备名称，你在系统设置-通用-关于本机里设置的名称。
countryCode

国家代码，CN
idfv

identifierForVendor，开发商唯一标识，不是设备标识。比如微信和 QQ 都是企鹅的，所以在同一台手机中，这个值都是相同的。但是对于不同手机是不同的。
version

App 的内部版本号（Build），不是一般说的 1.0.0 这种版本号，是自定义的字符串，不是所有 App 都会暴露给用户，比如网易新闻的“关于”里有写的 Build 446
status

唯一一个不是采集传递的数据，是注入的代码自己定义的一个程序运行状态的标识。

　　总共 11 个字段，除了最后一个不是采集到的外，剩下 10 个采集信息总结一下：

所有字段都是可以通过正常手段获取到的，也就是说，任何一个 App，如果想要得到这些信息，都是轻而易举的。
基本上，第三方统计平台都会收集这些信息；同时，国内的互联网公司肯定也都会收集这些信息。

　　所以换句话说：

　　你的这 10 项数据，已经不知道被多少公司采集保留过了，这一次，其实只是又多了个备份而已。而这个备份作者自己也已宣称删除了。

idfv 这个值，同一台手机上不同开发商的 App 是不同的，也就是说采集到了很多 idfv 值，可能都对应的是同一台手机；

　　对于不同手机来说，每个 App 采集到的都是不同的值。

　　所以总结来说：

　　当你仅仅拿到了一堆这个值的时候，是没有什么意义的。因为不同的值，既可能是同一个手机的又可能是不同的手机的，而相同的值，既可能是同一台手机上的不同 App，也可能是同一个 App。

这个值的意义只在同一台手机上，所以要想利用这个值，必须得跟其他能唯一区分出每台手机的值想结合使用。单独使用这个值是完全没意义的。

　　因此，作者自己所说的，这完全是一次试验，我至少是有八成相信的。因为这些采集的数据又无关痛痒的，又无意义的。

相比较而言，对于那些让你填写手机号、邮箱等个人信息的 App，同时再将这些采集到的设备信息和你个人信息绑定在一起，我觉得后者的潜在危险恐怕要更大些吧？

　　代码干了什么事

　　注入的代码绑架了 App，让他在程序启动、退出等状态，通知他将上面采集到的信息发送到服务器。之前第 11 项的 status 字段就是程序的当前状态，比如是在启动的时候还是退出的时候。

　　之后，根据服务器返回的指令，等待一段时间，进行后续操作，收到的指令可能是下面几种之一：

显示提示弹框

代码里只能显示一种弹框，文字全部由服务器返回定制：

所以你想输入你的密码？那还真有点困难啊。

当你点了确认按钮后，会在你当前程序内弹出一个苹果系统提供的某个 App 应用商店界面，这种方式和一些 App 内的应用推荐展示效果是一样的。
通过 scheme 跳转

这是苹果系统支持的应用间跳转方式，你在某个 App 里点击支付宝支付，然后跳转到支付宝里付款再跳转回来，都是一样的。

当然你也可以在苹果系统允许的范围内，拨打电话、展示网页等等。

只要你的手机没越狱，苹果系统会帮你把关，跳不出什么可怕的花样。

如果真有某种 NB 的跳转功能，请一定要相信，国内那么多没有节操的公司，早就利用起来了。

这种方式确实可以通过下载企业版 App，但是下载前会有系统提示框，确认是否按照？同时，如果是第一次安装带这个企业版证书的 App，系统还会再谈一个提示框，确认是否安装这个不受信任来源的 App，我觉得有这两次弹框，正常用户应该能分辨出来了吧？
直接展示某 App 的应用商店界面

和展示弹框后点击确认按钮效果一样，只是不展示弹框，直接就展示商店界面。

　　以上，就是全部可能执行的指令，所有这些操作都是用户能看的见的，没有什么看不见的后台操作。

还有两个关系不大的返回参数：一个是收到返回的信息后，等待多长时间再执行指令；一个是再次发送采集数据的等待时间。

　　总结一下：

作者说是为了做推广留的后门，我也八成相信。

因为三个指令操作确实都是为了推广展现某个 App 的，而且展现界面也是苹果系统提供的商店页面（就和你在 App Store 里看到的某一个单独 App 的界面是完全一样的），不存在钓鱼的可能性。

唯一要说的就是这种推广展现实在是太生硬，太明显了。

真要这么操作了，100% 我会认为系统或者是 App 有问题了。所以作者自己说从来没用过。要换作我，我也不会用这么 2 的方式推广的。
确实有可能通过 scheme 跳转到网页浏览器，打开某个钓鱼界面，然后你还能输入自己的用户名和密码。

如果能发生这种可能性的话，我觉得这就不是手机的问题，而是人的问题了。

你被钓鱼电话骗了，难道还要怪手机和运营商吗？

你把银行卡号、密码等一堆信息都告诉别人了，你还要指责这张卡设计的不安全吗？
没有任何诱骗你输入 iCloud 密码的文本框，传递的信息中也没有任何密码相关的东西。

也有人已经指出了，苹果支付系统已经设计的很安全了，是绝不会让 App 能随意拿到你的 iCloud 账户名的。你想用弹窗伪造欺骗用户输入 iCloud 密码，这个，真的，有些难。
至于其他的一些 scheme 跳转，代码是采用等待一段时间（比如设置个 5 秒，10 秒之类的）再进行跳转操作，所以这段代码根本不知道你当时在进行什么操作，出现恰巧你正在进行某个特殊操作时顺带跳转到某个 App 或网页的可能性，几率太小了。