据网友@唐巧_boy微博爆料，其朋友在第三方渠道下载的iOS开发工具xcode被插入恶意代码，会向一个网站上传数据，目前已知两个知名的App被注入。其中，“网易云音乐”不幸中招，该应用在AppStore上的最新版本2.8.3已经确认被感染。会将手机隐私信息发送到病毒作者的服务器 “init.icloud-analysis.com”上面，需要引起相关开发者和用户的注意。随后，众多网友均表示遭遇过此种情况。
据悉，通过在非官方渠道下载的Xcode编译出来的App被注入了第三方的代码，会向一个网站上传用户数据，数据包括一些iPhone和App的基本信息，例如时间，bundle id(包名)，应用名称，系统版本，语言，国家等。
病毒作者随后会把这些信息上传到init.icloud-analysis.com，该网站并不是apple的官方网站，而是病毒作者所申请的仿冒网站。
目前该网站的服务器已经关闭。用whois查询服务器信息也没有为挖掘出更多信息。分析人士指出，这说明病毒作者是个老手，并且非常小心，在代码和服务器上都没有留下什么痕迹，所以不排除以后还会继续作案的可能。
此外，虽然XCodeGhost并没有非常严重的恶意行为，但是这种病毒传播方式在iOS上还是首次。
大概的情况就是：以网易云音乐、12306、联通营业厅，中信银行信用卡动卡空间为代表的一批知名APP，因为开发这些APP的人没有从官方的渠道下载开发工具XCODE而是在其它渠道下载的，导致他们搞出来的APP是带后门的，目前后门的危害还在确认，和你越狱不越狱没关系，你从APP Store里面下了，就中招了。
看到大家清一色在骂，我来解释一下吧，使用非官方 Xcode 的原因大多是：阅兵期间前后国外线路十分不稳定，高达 5G 大小的 Xcode 无法顺利下载。你们该骂谁心里清楚，别一遇到问题就把屎盆扣给一线开发者。
用非官方Xcode的估计都是嫌APP Store里的下载速度太渣了吧……然而大公司们用盗版这有点打脸了。这个玩的有点大啊，直接从开发工具源头加恶意代码，不给鸡蛋下毒直接给母鸡下毒的节奏？
连我这个半调子iOS程序猿都用的是官方版，为嘛大公司却从乱七八糟的地方下载Xcode？
XCode编译器里有鬼 – XCodeGhost样本分析
事情的起因是@唐巧_boy在微博上发了一条微博说到：一个朋友告诉我他们通过在非官方渠道下载的 Xcode 编译出来的 app 被注入了第三方的代码，会向一个网站上传数据，目前已知两个知名的 App 被注入。
随后很多留言的小伙伴们纷纷表示中招，@谁敢乱说话表示：”还是不能相信迅雷，我是把官网上的下载URL复制到迅雷里下载的，还是中招了。我说一下：有问题的Xcode6.4.dmg的sha1是：a836d8fa0fce198e061b7b38b826178b44c053a8，官方正确的是：672e3dcb7727fc6db071e5a8528b70aa03900bb0，大家一定要校验。”另外还有一位小伙伴表示他是在百度网盘上下载的，也中招了。
样本分析
在@疯狗 @longye的帮助下，@JoeyBlue_ 为我们提供了病毒样本:CoreService库文件，因为用带这个库的Xcode编译出的app都会中毒，所以我们给这个样本起名为：XCodeGhost。CoreService是在”/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/”目录下发现的.
用ida打开，发现样本非常简单，只有少量函数。主要的功能就是先收集一些iPhone和app的基本信息，包括：时间，bundle id(包名)，应用名称，系统版本，语言，国家等。
随后会把这些信息上传到 init.icloud-analysis.com。
http://init.icloud-analysis.com并不是apple 的官方网站，而是病毒作者所申请的仿冒网站，用来收集数据信息的。
目前该网站的服务器已经关闭，用whois查询服务器信息也没有太多可以挖掘的地方。这说明病毒作者是个老手，并且非常小心，在代码和服务器上都没有留下什么痕迹，所以不排除以后还会继续做作案的可能。
检测方法
为了防止app被插入恶意库文件，开发者除了检测”/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs” 目录下是否有可疑的framework文件之外，还应该检测一下Target->Build Setting->Search Paths->Framework Search Paths中的设置。看看是否有可疑的frameworks混杂其中.
另外因为最近iOS dylib病毒也十分泛滥，为了防止开发者中招，支付宝的小伙伴还提供了一个防止被dylib hook的小技巧：在Build Settings中找到“Other Linker Flags”在其中加上”-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null”即可。
最后的建议是：以后下载XCode编译器尽可能使用官方渠道，以免app被打包进恶意的病毒库。如果非要用非官方渠道，一定要在下载后校验一下哈希值。
思考&总结
虽然XCodeGhost并没有非常严重的恶意行为，但是这种病毒传播方式在iOS上还是首次。也许这只是病毒作者试试水而已，可能随后还会有更大的动作，请开发者务必要小心。这个病毒让我想到了UNIX 之父 Ken Thompson 的图灵奖演讲 “Reflections of Trusting Trust”。他曾经假设可以实现了一个修改的 tcc，用它编译 su login 能产生后门，用修改的tcc编译“正版”的 tcc 代码也能够产生有着同样后门的 tcc。也就是不论 bootstrap (用 tcc 编译 tcc) 多少次，不论如何查看源码都无法发现后门，真是细思恐极啊。
1 很多开发者们担心最近下载的Xcode 7也不安全。这里笔者没有使用任何下载工具的情况在苹果官网上下载了Xcode_7.dmg并计算了sha1的值。
http://adcdownload.apple.com/Developer_Tools/Xcode_7/Xcode_7.dmg
$ shasum Xcode_7.dmg
4afc067e5fc9266413c157167a123c8cdfdfb15e Xcode_7.dmg
所以如果在非App Store下载的各位开发者们可以用sha sum校验一下自己下载的Xcode 7是否是原版。
2 @FlowerCode同学通过分析流量发现病毒开发者的服务器是搭建在Amazon EC2的云上的。服务器已经关闭 。
3 根据palo alto networks公司爆料，被感染的知名App Store应用为”网易云音乐”！该app应用在AppStore上的最新版本2.8.3已经确认被感染。并且该应用的Xcode编译版本为6.4（6E35b），也就是XcodeGhost病毒所感染的那个版本。
受感染的”网易云音乐”app会把手机隐私信息发送到病毒作者的服务器”init.icloud-analysis.com”上面.
4 根据热心网友举报，投毒者网名为”coderfun”。他在各种iOS开发者论坛或者weibo后留言引诱iOS开发者下载有毒版本的Xcode。并且中毒的版本不止Xcode 6.4，还有6.1，6.2和6.3等等。
5 根据热心网友提醒，我们在中信银行信用卡的应用”动卡空间”中也发现了被插入的XcodeGhost恶意代码，受感染的版本为3.4.4。
—------
这个事情跟苹果没一毛钱关系。 app 上传非隐私相关的使用数据是完全允许的，且不违反任何规则。审查是不会去审查这些东西的。
这事情跟黑苹果也没一毛钱关系，不论黑还是白，开发者都可以强行使用被修改过的 xcode 安装包。
最后，根本没有必要去算 hash 。任何在 mac 上运行的软件都是要有开发者签名的，否则 gatekeeper 会警告。被修改过的 xcode 开发包肯定是没有合法签名的。开发者安装的时候完全无视了 gatekeeper 的警告么？
这事已经闹两天了， coderfun 已经在第一时间把 Xcode7 正式版放上去了，说明他是非常活跃的，而他至今未现身留下任何辩解，所以 2 的可能性不是很大
XcodeGhost 可能的元凶是 XY 助手？
现在有三种可能性：
1. Coderfun 是 XY 助手专门用来干这个事儿的程序员；
2. Coderfun 和 XY 助手无关，只是一个离线包分享者，不小心从非官方途径获取了染毒的 Xcode 并且一直依附于该非官方渠道；
3. Coderfun 和 XY 助手等是合作关系
-------------------
XcodeGhost：墙、感染、信任和欺骗
据悉，通过在非官方渠道下载的Xcode编译出来的App被注入了第三方的代码，会向一个网站上传用户数据，数据包括一些iPhone和App的基本信息，例如时间，bundle id(包名)，应用名称，系统版本，语言，国家等。
病毒作者随后会把这些信息上传到init.icloud-analysis.com，该网站并不是apple的官方网站，而是病毒作者所申请的仿冒网站。
目前该网站的服务器已经关闭。用whois查询服务器信息也没有为挖掘出更多信息。分析人士指出，这说明病毒作者是个老手，并且非常小心，在代码和服务器上都没有留下什么痕迹，所以不排除以后还会继续作案的可能。
此外，虽然XCodeGhost并没有非常严重的恶意行为，但是这种病毒传播方式在iOS上还是首次。
大概的情况就是：以网易云音乐、12306、联通营业厅，中信银行信用卡动卡空间为代表的一批知名APP，因为开发这些APP的人没有从官方的渠道下载开发工具XCODE而是在其它渠道下载的，导致他们搞出来的APP是带后门的，目前后门的危害还在确认，和你越狱不越狱没关系，你从APP Store里面下了，就中招了。
看到大家清一色在骂，我来解释一下吧，使用非官方 Xcode 的原因大多是：阅兵期间前后国外线路十分不稳定，高达 5G 大小的 Xcode 无法顺利下载。你们该骂谁心里清楚，别一遇到问题就把屎盆扣给一线开发者。
用非官方Xcode的估计都是嫌APP Store里的下载速度太渣了吧……然而大公司们用盗版这有点打脸了。这个玩的有点大啊，直接从开发工具源头加恶意代码，不给鸡蛋下毒直接给母鸡下毒的节奏？
连我这个半调子iOS程序猿都用的是官方版，为嘛大公司却从乱七八糟的地方下载Xcode？
XCode编译器里有鬼 – XCodeGhost样本分析
事情的起因是@唐巧_boy在微博上发了一条微博说到：一个朋友告诉我他们通过在非官方渠道下载的 Xcode 编译出来的 app 被注入了第三方的代码，会向一个网站上传数据，目前已知两个知名的 App 被注入。
随后很多留言的小伙伴们纷纷表示中招，@谁敢乱说话表示：”还是不能相信迅雷，我是把官网上的下载URL复制到迅雷里下载的，还是中招了。我说一下：有问题的Xcode6.4.dmg的sha1是：a836d8fa0fce198e061b7b38b826178b44c053a8，官方正确的是：672e3dcb7727fc6db071e5a8528b70aa03900bb0，大家一定要校验。”另外还有一位小伙伴表示他是在百度网盘上下载的，也中招了。
样本分析
在@疯狗 @longye的帮助下，@JoeyBlue_ 为我们提供了病毒样本:CoreService库文件，因为用带这个库的Xcode编译出的app都会中毒，所以我们给这个样本起名为：XCodeGhost。CoreService是在”/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/Library/Frameworks/CoreServices.framework/”目录下发现的.
用ida打开，发现样本非常简单，只有少量函数。主要的功能就是先收集一些iPhone和app的基本信息，包括：时间，bundle id(包名)，应用名称，系统版本，语言，国家等。
随后会把这些信息上传到 init.icloud-analysis.com。
http://init.icloud-analysis.com并不是apple 的官方网站，而是病毒作者所申请的仿冒网站，用来收集数据信息的。
目前该网站的服务器已经关闭，用whois查询服务器信息也没有太多可以挖掘的地方。这说明病毒作者是个老手，并且非常小心，在代码和服务器上都没有留下什么痕迹，所以不排除以后还会继续做作案的可能。
检测方法
为了防止app被插入恶意库文件，开发者除了检测”/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs” 目录下是否有可疑的framework文件之外，还应该检测一下Target->Build Setting->Search Paths->Framework Search Paths中的设置。看看是否有可疑的frameworks混杂其中.
另外因为最近iOS dylib病毒也十分泛滥，为了防止开发者中招，支付宝的小伙伴还提供了一个防止被dylib hook的小技巧：在Build Settings中找到“Other Linker Flags”在其中加上”-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null”即可。
最后的建议是：以后下载XCode编译器尽可能使用官方渠道，以免app被打包进恶意的病毒库。如果非要用非官方渠道，一定要在下载后校验一下哈希值。
思考&总结
虽然XCodeGhost并没有非常严重的恶意行为，但是这种病毒传播方式在iOS上还是首次。也许这只是病毒作者试试水而已，可能随后还会有更大的动作，请开发者务必要小心。这个病毒让我想到了UNIX 之父 Ken Thompson 的图灵奖演讲 “Reflections of Trusting Trust”。他曾经假设可以实现了一个修改的 tcc，用它编译 su login 能产生后门，用修改的tcc编译“正版”的 tcc 代码也能够产生有着同样后门的 tcc。也就是不论 bootstrap (用 tcc 编译 tcc) 多少次，不论如何查看源码都无法发现后门，真是细思恐极啊。
1 很多开发者们担心最近下载的Xcode 7也不安全。这里笔者没有使用任何下载工具的情况在苹果官网上下载了Xcode_7.dmg并计算了sha1的值。
http://adcdownload.apple.com/Developer_Tools/Xcode_7/Xcode_7.dmg
$ shasum Xcode_7.dmg
4afc067e5fc9266413c157167a123c8cdfdfb15e Xcode_7.dmg
所以如果在非App Store下载的各位开发者们可以用sha sum校验一下自己下载的Xcode 7是否是原版。
2 @FlowerCode同学通过分析流量发现病毒开发者的服务器是搭建在Amazon EC2的云上的。服务器已经关闭 。
3 根据palo alto networks公司爆料，被感染的知名App Store应用为”网易云音乐”！该app应用在AppStore上的最新版本2.8.3已经确认被感染。并且该应用的Xcode编译版本为6.4（6E35b），也就是XcodeGhost病毒所感染的那个版本。
受感染的”网易云音乐”app会把手机隐私信息发送到病毒作者的服务器”init.icloud-analysis.com”上面.
4 根据热心网友举报，投毒者网名为”coderfun”。他在各种iOS开发者论坛或者weibo后留言引诱iOS开发者下载有毒版本的Xcode。并且中毒的版本不止Xcode 6.4，还有6.1，6.2和6.3等等。
5 根据热心网友提醒，我们在中信银行信用卡的应用”动卡空间”中也发现了被插入的XcodeGhost恶意代码，受感染的版本为3.4.4。
—------
这个事情跟苹果没一毛钱关系。 app 上传非隐私相关的使用数据是完全允许的，且不违反任何规则。审查是不会去审查这些东西的。
这事情跟黑苹果也没一毛钱关系，不论黑还是白，开发者都可以强行使用被修改过的 xcode 安装包。
最后，根本没有必要去算 hash 。任何在 mac 上运行的软件都是要有开发者签名的，否则 gatekeeper 会警告。被修改过的 xcode 开发包肯定是没有合法签名的。开发者安装的时候完全无视了 gatekeeper 的警告么？
这事已经闹两天了， coderfun 已经在第一时间把 Xcode7 正式版放上去了，说明他是非常活跃的，而他至今未现身留下任何辩解，所以 2 的可能性不是很大
XcodeGhost 可能的元凶是 XY 助手？
现在有三种可能性：
1. Coderfun 是 XY 助手专门用来干这个事儿的程序员；
2. Coderfun 和 XY 助手无关，只是一个离线包分享者，不小心从非官方途径获取了染毒的 Xcode 并且一直依附于该非官方渠道；
3. Coderfun 和 XY 助手等是合作关系
-------------------
XcodeGhost：墙、感染、信任和欺骗
霍炬
最近XcodeGhost导致的严重安全问题，相信大家已经从各个渠道知道了。简单概括一下——
有人在中国网盘和论坛上传播了一个修改过的Xcode，这个版本的Xcode会在编译出来的App上面加一些可以被远程控制的代码，并且发送数据到某个服务器上。这是iOS出现以来，未越狱系统遭遇的最大安全威胁，在此之前苹果的Sandbox模式几乎没遇到过挑战，iPhone用户甚至大量iOS开发者都认为系统固若金汤，不可能遇到问题。
在XcodeGhost开始被媒体报道的时，很多人大大低估了它的风险。我在乌云报道这个问题的当天，在朋友圈上建议大家先把中招的app都删掉，并且立刻修改iCloud密码，开两步验证。甚至遭到了不少人反对，还有好几位iOS开发者告诉我这件事没什么大问题，因为iOS有Sandbox，不会造成什么伤害。当时网易也发了一个关于云音乐被感染的说明，也是类似不痛不痒的口气。这些说法当然都是大错特错的，会有这种想法，是因为只会站在程序员角度看问题，如果对安全问题稍微有一点敏感性，就会立刻意识到这是极严重的威胁，稍微发挥一些想象力就会被吓着。
在XcodeGhost开始被媒体报道的时，很多人大大低估了它的风险。我在乌云报道这个问题的当天，在朋友圈上建议大家先把中招的app都删掉，并且立刻修改iCloud密码，开两步验证。甚至遭到了不少人反对，还有好几位iOS开发者告诉我这件事没什么大问题，因为iOS有Sandbox，不会造成什么伤害。当时网易也发了一个关于云音乐被感染的说明，也是类似不痛不痒的口气。这些说法当然都是大错特错的，会有这种想法，是因为只会站在程序员角度看问题，如果对安全问题稍微有一点敏感性，就会立刻意识到这是极严重的威胁，稍微发挥一些想象力就会被吓着。
所谓安全威胁，大部分都是在获取到非常有限资源的情况下，利用社会工程学（俗称：骗）来达到目的。比如，你觉得让别人看到你的通讯录有什么问题吗？很多人会认为虽然不舒服，但不会有什么威胁。实际上，骗子会从通讯录里面挑出来你父母的电话，打电话去骗他们。所以，这和iOS有没有Sandbox，能不能保护系统安全没关系，只要我获得了一个机会，能控制你信任的App上弹出对话框，我就可以利用这个对话框来骗你输入系统的重要密码。程序员应该想象力再丰富一点，不要把目光局限于“系统给了我什么权限”，而是要扩展到“如果我被完全信任了，我能进行什么样的欺骗”。
我不打算在这里讲太多直接的安全问题，毕竟已经很多人分析过了，在好几篇非常不完善，极大低估这次事件威胁的分析文章之后，腾讯给出了一篇相当详细的分析，比较符合我的观点，也把问题的严重性说的非常清楚。在腾讯的分析里面，说可以利用OpenUrl来操作用户拨打电话，同样又有iOS开发者说“OpenUrl不能控制iPhone打电话”。事实上，OpenUrl可以弹出一个带有固定电话号码的弹窗，上面有“拨打”和“取消”两个按钮，这确实不算直接拨打了电话，但如果给一千万个用户在某个特定环境下弹出一个这样的窗口，其中有多大比例的人会去点“拨打”呢？如果程序员不去提高想象力，总把安全问题和功能局限在系统文档提供的“能做什么”这个范围内，软件的安全性实在让人难以信任。
具体的安全问题有更专业的人去普及，本文不多说，在这里我更想谈谈关于信任的问题。在这次事件中，也有一些人想起了Ken Thompson大神（Unix系统/C语言的前身B语言/Go语言的直接贡献者，称作Unix之父也不过分）在1984年的一次演讲，在那次演讲中中，Ken讲了他在70年代在贝尔实验室捉弄同事的一次恶作剧，在那段时间里面，实验室里面所有的Unix系统，Ken都可以随便以最高权限登录，而同事反复检查用户，权限，甚至是当时使用的Unix代码，都没查不到后门，百思不得其解。14年之后，Ken在这次演讲里面才公开，后门其实隐藏在他写的编译器中，当用编译器编译Unix系统的时候，后门就被放在了编译出来的系统里面，但Unix本身的代码是干净的，所以同事无论如何也查不到问题。Ken的演讲所提到的核心问题并不是如何入侵一个操作系统，而是信任。其标题“Reflections on Trusting Trust” （我翻译为”深入思考我们信任的可信”，以下简称RoTT）开宗名义，明确强调这一点。
在80年代曾经有很多人用这样的办法给开发工具加各种外壳和后门，但当时联网条件并不好，很难产生大规模影响。很多案例是发生在相对封闭的企业内网和教育网中，Ken捉弄同事的原始案例也可以看作是企业内网上的传播。可以说，RoTT能产生的影响一直被人们低估，因为在现实世界想要具备适合它的条件，实在是太难了。历史上，虽然有很多底层代码Bug导致的安全事件（比如之前的OpenSSL心脏出血漏洞，可以参考我的另外一篇文章，点阅读原文可见），但直接通过这种在基础工具上制造的后门，从而衍生的大规模安全事件，从来没有真正发生过。这种手法一般是用在有限范围的网络上，比如在早年的教育网上或者企业网络里面，那时候在内网上传递一个被下了毒的软件，很容易传播开。
在互联网上，如果要重现Ken的案例，首先需要找到一个可信的源头感染，这本身就已经是极其困难的事了。用这次的事件做例子的话，在正常情况下，用户是通过Mac App Store来下载Xcode的，在下载安装的过程中，OS X本身会替用户进行加密签名校验，保证下载的东西确实是苹果原始分发的软件，这样才能被安装到用户的机器上。如果想把在Xcode中嵌入一个后门，你得先找到Apple服务器的漏洞，才能有机会把自己改过的包上传上去，而且还要弄到苹果的私钥去进行签名，才能装到用户计算机上。但如果同时具备了这两个条件，已经是荣华富贵唾手可得，有的是更可靠，获利更大的做法，谁又肯去舍近求远感染一个Xcode呢？
所以，只有在相对封闭的网络环境下，才有可能玩这个把戏。80年代，网络远远没有今天发达，人们更多的下载和网络活动是分布在各大机构自己的网络里面的，比如大型企业的内部网络，相对于互联网，这些内部网络网络速度会快的多，人们通常更倾向于从内部网络获得软件。这就给了入侵者（通常是商业间谍）通过替换内容软件来侵入公司内部的机会。但内网又造成了另外一个问题，在封闭网络下，入侵者获得的数据也没这么容易拿走，必须还要回到内网才有机会拿到之前的战果。这些特性造成了这种做法始终在小范围内有效，在公众网络上性价比不高。
这次XcodeGhost事件会给很多人启发，中国目前的网络环境类似于80年代的企业内网，但规模又比当年的内网大的多，而且不像那么难以进入。 于是，一些80年代流行但没造成大规模影响的办法，有机会可以在中国环境下重新应用了，并且造成巨大影响。以前的创业是Copy to China，现在同样可以复制30年前的安全问题。
Ken的演讲最后指出，你没办法信任那些不是自己写的代码。80年代达到这个目标尚且有可能，那时候的软件规模还很小。而今天，任何工作都需要建立在大量的现成软件基础之上，换句话说，你必须去信任其他人，才有可能制作出产品。如今的可信任环境就变得更加重要。
但在中国，因为GFW和相关政策的存在，要获得一个可信环境变得非常困难。
在这个环境里面，大量国外网站不能访问或者难于访问，非常多怕麻烦的人会使用国内替代品。这次的事件之所以影响巨大，就是因为通过苹果官方渠道升级Xcode速度太慢，少则10多个小时，多则几十个小时，其间还有可能中断和重新下载。从国内随便下载一个Xcode用当然是错的，但在这样的环境下也不是完全不能理解，考虑一下互联网的下载速度只有50K，企业内网速度能高达10M的时候，谁会不从内网下载呢？（编者注：GFW，Great Firewall of China。防火长城，指中国防火墙）
用一个现实世界的例子做个比喻吧，前面说了骗子拿到你父母的电话之后，会打电话去骗他们，比如跟你父母说你出了车祸，急需用钱。要让这个骗术成功，一个前提条件是要阻止你父母去找你验证真假，所以骗子同时会用各种办法来骚扰你的电话，迫使你不堪其扰关机或者始终占线。这样你父母和你的联系就断开了，他们没法找你验证了，此时骗子的话就更容易被相信。在这次事件里面，GFW让人们无法访问国外的可信网站，或者访问速度极慢，它起的作用就如同迫使你占线或者关机，从而让人们只能从不可信的地方获取软件。
GFW让中国本来开放的互联网环境，变成了一个巨大的企业内网，或者叫做中国局域网。除了速度和难以访问的影响，各种各样的DNS投毒，电信运营商干扰也是严重问题，你拿回来的DNS结果往往也未必是可信的，而运营商试图在HTTP请求中插入广告的行为，又经常会导致正常的应用表现不正常，而这些乱七八糟的毛病还经常变化，今天你可以这样对付，下周可能就需要换一个办法。要维持一个可信的软件环境，需要付出巨大的精力，能愿意付出这个代价的人越来越少。
在这个环境中，我们能信任的什么呢？网络链接不可信，运营商不可信，DNS不可信，大企业不可信。最后这一点更荒唐，如果是在正常的网络环境下，你很难相信苹果或者Google会坑害自己的用户，因为这和他们的利益直接相关，他们总是要尽量保护自己的用户。
但在中国，如果你敢信任百度，基本意味着你生活各方面都会出问题，用百度查个搬家公司，骗死你没商量，用百度查个快递电话，骗死你也没商量，用百度查个医院，你猜会怎么样？那是真要骗死你没商量，这里的骗死都不再是比喻了。你要信任百度的软件，更好玩了，它莫名其妙就给你把百度出的所有软件都装在你机器上了，人们管这个不请自来的大礼叫做百度全家桶。如此致力于坑害自己用户的大公司，在中国之外还真是罕见。
但在中国，如果你敢信任百度，基本意味着你生活各方面都会出问题，用百度查个搬家公司，骗死你没商量，用百度查个快递电话，骗死你也没商量，用百度查个医院，你猜会怎么样？那是真要骗死你没商量，这里的骗死都不再是比喻了。你要信任百度的软件，更好玩了，它莫名其妙就给你把百度出的所有软件都装在你机器上了，人们管这个不请自来的大礼叫做百度全家桶。如此致力于坑害自己用户的大公司，在中国之外还真是罕见。
在中国的网络环境下，这次事件产生的危害本身也更加危险。事件发生时，我告诉朋友们立刻删除所有被感染的软件，直至问题被修复。有人说，黑客自己的网站已经关闭了，没什么危险。这么说当然是错的，因为遍布中国各处的DNS投毒和劫持，创造一个一样域名的网站再简单不过了。比如到游客聚集的区域，带一个路由器，创建一个没有密码的WIFI热点，等着人们连上来，在这个热点上劫持XcodeGhost使用的域名，就可以利用已经中毒的app来骗iCloud密码了。这些都是非常容易实现的办法，千万不要低估安全问题能造成的后果，尤其是在中国特殊的网络环境下。
目前中国的网络环境和食品安全有诸多共同之处，你没法信任路边的小饭馆，但同时你也没法信任昂贵的大饭馆。你没法信任菜市场买的肉，但超市买的肉也并不那么可靠。在一切的背后是土壤和水的全面污染，可能一家好的饭馆未必打算毒害自己的顾客，但他们也很难保证自己原材料的供货商可靠，要保证使用的所有材料可靠，这是一家饭馆不可能具备的能力。比如，奶粉的三聚氰胺事件之前，一家有追求的饭馆大概会觉得，我不用来路不明的奶粉，我用大品牌的三鹿，伊利，这算是对顾客负责了吧？可惜，这些大品牌一样出问题。这绝非饭馆所希望的，他们也是受害者，就像是这次事件中的网易云音乐，他们确实没打算坑自己的用户，不过网易、腾讯这样的大公司一样中招了。
相对封闭的iOS尚且如此（单一开发工具，单一软件分发渠道，独家封闭系统iOS，独家硬件iPhone）尚且能出这么大问题，想想Android会怎么样？Android官方网站几年前就被封了无法访问，大部分开发者都是从国内渠道下载的开发工具。
App的安全可靠吗？国内无数家忙着改Android皮肤就称自己是“操作系统”厂商，他们能保证自己的定制Android版本是安全吗？他们有真正的操作系统厂商级别的能力吗？进一步，他们能保证自己使用的开发工具安全吗？每家手机厂商都恨不得做自己的Android app下载渠道，他们能保证这些渠道上分发的app安全吗？甚至，他们能保证自己的下载市场安全吗？
请大家继续联想吧。有朋友跟我说，你想多了，Android哪需要这么麻烦啊，本来国内环境就是木马遍地了。真实情况恐怕只能用惨烈来形容。顺便说一声，传说Google要把Play Store进入中国，提供一个受审查的版本，很多人说这是Google妥协了，我看这根本不是妥协了，是中国内部的Android环境太糟糕，已经威胁全球生态了，Google不得不自己出手解决这个问题。所以，一旦Google Play真的进了中国，请大家记得立刻把Play Store做为自己唯一的Android软件下载渠道，哪怕它不好用，不中国国情，甚至显得有点傻里傻气…千万记得，安全比方便更重要。
请大家继续联想吧。有朋友跟我说，你想多了，Android哪需要这么麻烦啊，本来国内环境就是木马遍地了。真实情况恐怕只能用惨烈来形容。顺便说一声，传说Google要把Play Store进入中国，提供一个受审查的版本，很多人说这是Google妥协了，我看这根本不是妥协了，是中国内部的Android环境太糟糕，已经威胁全球生态了，Google不得不自己出手解决这个问题。所以，一旦Google Play真的进了中国，请大家记得立刻把Play Store做为自己唯一的Android软件下载渠道，哪怕它不好用，不中国国情，甚至显得有点傻里傻气…千万记得，安全比方便更重要。
在这些前提下，重新认真考虑Ken的演讲提到的观点就显得更加重要，深入思考我们信任的可信。到底什么是可信的呢？开发工具可信吗？操作系统可信吗？你觉得下载来之后验证一下md5或者sha512总应该可信了，但你用来计算sha的工具是哪下载来的？你又如何知道这个工具本身是可信呢？在一个封闭的，难以和真正源头沟通的环境下，根本没办法谈所谓的信任。
在中国目前的环境下，难以直接套用成熟的软件开发和管理流程，除非保证团队所有人都必须翻墙，必须用Google查资料，必须不信任国内网站。你的团队中有一个习惯用百度查资料，顺着国内论坛的链接从百度网盘或者迅雷下载工具的人，就不知道会惹出来多大麻烦。这次事件充分证明了这一点，我起初认为腾讯应该不会有问题，因为我知道腾讯内部有极好的网络环境，但最终不幸的是微信也中招了。
我们的恶劣环境已经改变了工程师的习惯，甚至改变了教育，就算是在腾讯内部这么好的网络环境下，仍然有人会去百度查资料，用百度网盘下载开发工具。就像很多留学生到了美国仍然用百度搜索一样，环境的改变并不能直接逆转已经完成的用户习惯。
比较讽刺的是，在中国特色的现实世界反而又制约了出现大规模安全灾难的可能性。比如，中国有相当严重的网络监控、审查和实名制、以及互联网公司必须保存（而且要向有关部门开放）的各种用户数据，并且互联网和世界半隔绝，在出现这种问题的时候，要抓到始作俑者又相对简单。现实世界中，只要在论坛发个贴，去你家查水表就是分分钟的事情。这大概算是“不幸+不幸“互相抵消之后产生了一点点微小的幸运吧。
比较讽刺的是，在中国特色的现实世界反而又制约了出现大规模安全灾难的可能性。比如，中国有相当严重的网络监控、审查和实名制、以及互联网公司必须保存（而且要向有关部门开放）的各种用户数据，并且互联网和世界半隔绝，在出现这种问题的时候，要抓到始作俑者又相对简单。现实世界中，只要在论坛发个贴，去你家查水表就是分分钟的事情。这大概算是“不幸+不幸“互相抵消之后产生了一点点微小的幸运吧。
很多年前，我说招聘工程师有几个原则，比如，必须使用Google而不是百度，必须翻墙而不是用国内替代品，必须优先使用国外的工具。经常有人认为这种要求过于苛刻，甚至认为是装逼。这次事件告诉了我们，这些良好的习惯确实是工程师的第一道防线，融入世界主流，可以让你少遭遇很多中国特色的麻烦。虽然保持这些良好的习惯需要付出不小的代价，但事实证明这些代价是值得的。
这样的网络环境，是我们这一代工程师的耻辱，但我们如此愤怒于此 ，又如此无能为力，这是这个时代最令人悲哀的事情。
我们对此有多么无能为力呢？我写这篇文章的时候就在想，大家应该赶快传播它，因为我觉得它很快会被删掉。这就是无能为力的具体表现。
我们对此有多么无能为力呢？我写这篇文章的时候就在想，大家应该赶快传播它，因为我觉得它很快会被删掉。这就是无能为力的具体表现。
顺便说一句，1996年，受Ken的案例启发，我写过一篇科幻小说，大意是一种病毒把编译器做为感染的源头，最终感染了操作系统。在这个操作系统上，它会判断用户指令对它是否会造成伤害，如果是有害的指令，就假装执行一下，实际并不真执行，从而可以躲过杀毒软件和人工清除。这同样是信任问题，在这个环境下，没有任何可信的东西，这种病毒将会在操作系统中永存，并且把自己附着于任何在这台计算机上制造的软件中。在一个计算机一开机就无线联网的时代，病毒可以借此高速传播，最后人类已经找不到一台干净的计算机可以去编写真正干净的操作系统了。（90年代还没有无线网络，那时候甚至连有线网络都没普及，Sun还在号称网络就是计算机，那时候一台随时联网的计算机简直太奢侈了，但如今看来…世界确实已经发展到了这样，想找一台不联网的计算机倒是不容易了）。
不知道这种幻想中的病毒什么时候会真正出现……其实，前几年工信部推行绿坝的时候，我当时就觉得那简直是创造这种病毒的一个非常好的机会，还好最终绿坝计划被放弃了。中国网络和政策环境的特殊性，将来真的有可能制造出适合这种病毒生存的环境，就像这次因为GFW的正面和潜在影响，让70年代Ken设想的RoTT在2015年大规模流行，40多年的时间跨度……
著名科幻作家韩松说过霍炬
最近XcodeGhost导致的严重安全问题，相信大家已经从各个渠道知道了。简单概括一下——
有人在中国网盘和论坛上传播了一个修改过的Xcode，这个版本的Xcode会在编译出来的App上面加一些可以被远程控制的代码，并且发送数据到某个服务器上。这是iOS出现以来，未越狱系统遭遇的最大安全威胁，在此之前苹果的Sandbox模式几乎没遇到过挑战，iPhone用户甚至大量iOS开发者都认为系统固若金汤，不可能遇到问题。
在XcodeGhost开始被媒体报道的时，很多人大大低估了它的风险。我在乌云报道这个问题的当天，在朋友圈上建议大家先把中招的app都删掉，并且立刻修改iCloud密码，开两步验证。甚至遭到了不少人反对，还有好几位iOS开发者告诉我这件事没什么大问题，因为iOS有Sandbox，不会造成什么伤害。当时网易也发了一个关于云音乐被感染的说明，也是类似不痛不痒的口气。这些说法当然都是大错特错的，会有这种想法，是因为只会站在程序员角度看问题，如果对安全问题稍微有一点敏感性，就会立刻意识到这是极严重的威胁，稍微发挥一些想象力就会被吓着。
在XcodeGhost开始被媒体报道的时，很多人大大低估了它的风险。我在乌云报道这个问题的当天，在朋友圈上建议大家先把中招的app都删掉，并且立刻修改iCloud密码，开两步验证。甚至遭到了不少人反对，还有好几位iOS开发者告诉我这件事没什么大问题，因为iOS有Sandbox，不会造成什么伤害。当时网易也发了一个关于云音乐被感染的说明，也是类似不痛不痒的口气。这些说法当然都是大错特错的，会有这种想法，是因为只会站在程序员角度看问题，如果对安全问题稍微有一点敏感性，就会立刻意识到这是极严重的威胁，稍微发挥一些想象力就会被吓着。
所谓安全威胁，大部分都是在获取到非常有限资源的情况下，利用社会工程学（俗称：骗）来达到目的。比如，你觉得让别人看到你的通讯录有什么问题吗？很多人会认为虽然不舒服，但不会有什么威胁。实际上，骗子会从通讯录里面挑出来你父母的电话，打电话去骗他们。所以，这和iOS有没有Sandbox，能不能保护系统安全没关系，只要我获得了一个机会，能控制你信任的App上弹出对话框，我就可以利用这个对话框来骗你输入系统的重要密码。程序员应该想象力再丰富一点，不要把目光局限于“系统给了我什么权限”，而是要扩展到“如果我被完全信任了，我能进行什么样的欺骗”。
我不打算在这里讲太多直接的安全问题，毕竟已经很多人分析过了，在好几篇非常不完善，极大低估这次事件威胁的分析文章之后，腾讯给出了一篇相当详细的分析，比较符合我的观点，也把问题的严重性说的非常清楚。在腾讯的分析里面，说可以利用OpenUrl来操作用户拨打电话，同样又有iOS开发者说“OpenUrl不能控制iPhone打电话”。事实上，OpenUrl可以弹出一个带有固定电话号码的弹窗，上面有“拨打”和“取消”两个按钮，这确实不算直接拨打了电话，但如果给一千万个用户在某个特定环境下弹出一个这样的窗口，其中有多大比例的人会去点“拨打”呢？如果程序员不去提高想象力，总把安全问题和功能局限在系统文档提供的“能做什么”这个范围内，软件的安全性实在让人难以信任。
具体的安全问题有更专业的人去普及，本文不多说，在这里我更想谈谈关于信任的问题。在这次事件中，也有一些人想起了Ken Thompson大神（Unix系统/C语言的前身B语言/Go语言的直接贡献者，称作Unix之父也不过分）在1984年的一次演讲，在那次演讲中中，Ken讲了他在70年代在贝尔实验室捉弄同事的一次恶作剧，在那段时间里面，实验室里面所有的Unix系统，Ken都可以随便以最高权限登录，而同事反复检查用户，权限，甚至是当时使用的Unix代码，都没查不到后门，百思不得其解。14年之后，Ken在这次演讲里面才公开，后门其实隐藏在他写的编译器中，当用编译器编译Unix系统的时候，后门就被放在了编译出来的系统里面，但Unix本身的代码是干净的，所以同事无论如何也查不到问题。Ken的演讲所提到的核心问题并不是如何入侵一个操作系统，而是信任。其标题“Reflections on Trusting Trust” （我翻译为”深入思考我们信任的可信”，以下简称RoTT）开宗名义，明确强调这一点。
在80年代曾经有很多人用这样的办法给开发工具加各种外壳和后门，但当时联网条件并不好，很难产生大规模影响。很多案例是发生在相对封闭的企业内网和教育网中，Ken捉弄同事的原始案例也可以看作是企业内网上的传播。可以说，RoTT能产生的影响一直被人们低估，因为在现实世界想要具备适合它的条件，实在是太难了。历史上，虽然有很多底层代码Bug导致的安全事件（比如之前的OpenSSL心脏出血漏洞，可以参考我的另外一篇文章，点阅读原文可见），但直接通过这种在基础工具上制造的后门，从而衍生的大规模安全事件，从来没有真正发生过。这种手法一般是用在有限范围的网络上，比如在早年的教育网上或者企业网络里面，那时候在内网上传递一个被下了毒的软件，很容易传播开。
在互联网上，如果要重现Ken的案例，首先需要找到一个可信的源头感染，这本身就已经是极其困难的事了。用这次的事件做例子的话，在正常情况下，用户是通过Mac App Store来下载Xcode的，在下载安装的过程中，OS X本身会替用户进行加密签名校验，保证下载的东西确实是苹果原始分发的软件，这样才能被安装到用户的机器上。如果想把在Xcode中嵌入一个后门，你得先找到Apple服务器的漏洞，才能有机会把自己改过的包上传上去，而且还要弄到苹果的私钥去进行签名，才能装到用户计算机上。但如果同时具备了这两个条件，已经是荣华富贵唾手可得，有的是更可靠，获利更大的做法，谁又肯去舍近求远感染一个Xcode呢？
所以，只有在相对封闭的网络环境下，才有可能玩这个把戏。80年代，网络远远没有今天发达，人们更多的下载和网络活动是分布在各大机构自己的网络里面的，比如大型企业的内部网络，相对于互联网，这些内部网络网络速度会快的多，人们通常更倾向于从内部网络获得软件。这就给了入侵者（通常是商业间谍）通过替换内容软件来侵入公司内部的机会。但内网又造成了另外一个问题，在封闭网络下，入侵者获得的数据也没这么容易拿走，必须还要回到内网才有机会拿到之前的战果。这些特性造成了这种做法始终在小范围内有效，在公众网络上性价比不高。
这次XcodeGhost事件会给很多人启发，中国目前的网络环境类似于80年代的企业内网，但规模又比当年的内网大的多，而且不像那么难以进入。 于是，一些80年代流行但没造成大规模影响的办法，有机会可以在中国环境下重新应用了，并且造成巨大影响。以前的创业是Copy to China，现在同样可以复制30年前的安全问题。
Ken的演讲最后指出，你没办法信任那些不是自己写的代码。80年代达到这个目标尚且有可能，那时候的软件规模还很小。而今天，任何工作都需要建立在大量的现成软件基础之上，换句话说，你必须去信任其他人，才有可能制作出产品。如今的可信任环境就变得更加重要。
但在中国，因为GFW和相关政策的存在，要获得一个可信环境变得非常困难。
在这个环境里面，大量国外网站不能访问或者难于访问，非常多怕麻烦的人会使用国内替代品。这次的事件之所以影响巨大，就是因为通过苹果官方渠道升级Xcode速度太慢，少则10多个小时，多则几十个小时，其间还有可能中断和重新下载。从国内随便下载一个Xcode用当然是错的，但在这样的环境下也不是完全不能理解，考虑一下互联网的下载速度只有50K，企业内网速度能高达10M的时候，谁会不从内网下载呢？（编者注：GFW，Great Firewall of China。防火长城，指中国防火墙）
用一个现实世界的例子做个比喻吧，前面说了骗子拿到你父母的电话之后，会打电话去骗他们，比如跟你父母说你出了车祸，急需用钱。要让这个骗术成功，一个前提条件是要阻止你父母去找你验证真假，所以骗子同时会用各种办法来骚扰你的电话，迫使你不堪其扰关机或者始终占线。这样你父母和你的联系就断开了，他们没法找你验证了，此时骗子的话就更容易被相信。在这次事件里面，GFW让人们无法访问国外的可信网站，或者访问速度极慢，它起的作用就如同迫使你占线或者关机，从而让人们只能从不可信的地方获取软件。
GFW让中国本来开放的互联网环境，变成了一个巨大的企业内网，或者叫做中国局域网。除了速度和难以访问的影响，各种各样的DNS投毒，电信运营商干扰也是严重问题，你拿回来的DNS结果往往也未必是可信的，而运营商试图在HTTP请求中插入广告的行为，又经常会导致正常的应用表现不正常，而这些乱七八糟的毛病还经常变化，今天你可以这样对付，下周可能就需要换一个办法。要维持一个可信的软件环境，需要付出巨大的精力，能愿意付出这个代价的人越来越少。
在这个环境中，我们能信任的什么呢？网络链接不可信，运营商不可信，DNS不可信，大企业不可信。最后这一点更荒唐，如果是在正常的网络环境下，你很难相信苹果或者Google会坑害自己的用户，因为这和他们的利益直接相关，他们总是要尽量保护自己的用户。
但在中国，如果你敢信任百度，基本意味着你生活各方面都会出问题，用百度查个搬家公司，骗死你没商量，用百度查个快递电话，骗死你也没商量，用百度查个医院，你猜会怎么样？那是真要骗死你没商量，这里的骗死都不再是比喻了。你要信任百度的软件，更好玩了，它莫名其妙就给你把百度出的所有软件都装在你机器上了，人们管这个不请自来的大礼叫做百度全家桶。如此致力于坑害自己用户的大公司，在中国之外还真是罕见。
但在中国，如果你敢信任百度，基本意味着你生活各方面都会出问题，用百度查个搬家公司，骗死你没商量，用百度查个快递电话，骗死你也没商量，用百度查个医院，你猜会怎么样？那是真要骗死你没商量，这里的骗死都不再是比喻了。你要信任百度的软件，更好玩了，它莫名其妙就给你把百度出的所有软件都装在你机器上了，人们管这个不请自来的大礼叫做百度全家桶。如此致力于坑害自己用户的大公司，在中国之外还真是罕见。
在中国的网络环境下，这次事件产生的危害本身也更加危险。事件发生时，我告诉朋友们立刻删除所有被感染的软件，直至问题被修复。有人说，黑客自己的网站已经关闭了，没什么危险。这么说当然是错的，因为遍布中国各处的DNS投毒和劫持，创造一个一样域名的网站再简单不过了。比如到游客聚集的区域，带一个路由器，创建一个没有密码的WIFI热点，等着人们连上来，在这个热点上劫持XcodeGhost使用的域名，就可以利用已经中毒的app来骗iCloud密码了。这些都是非常容易实现的办法，千万不要低估安全问题能造成的后果，尤其是在中国特殊的网络环境下。
目前中国的网络环境和食品安全有诸多共同之处，你没法信任路边的小饭馆，但同时你也没法信任昂贵的大饭馆。你没法信任菜市场买的肉，但超市买的肉也并不那么可靠。在一切的背后是土壤和水的全面污染，可能一家好的饭馆未必打算毒害自己的顾客，但他们也很难保证自己原材料的供货商可靠，要保证使用的所有材料可靠，这是一家饭馆不可能具备的能力。比如，奶粉的三聚氰胺事件之前，一家有追求的饭馆大概会觉得，我不用来路不明的奶粉，我用大品牌的三鹿，伊利，这算是对顾客负责了吧？可惜，这些大品牌一样出问题。这绝非饭馆所希望的，他们也是受害者，就像是这次事件中的网易云音乐，他们确实没打算坑自己的用户，不过网易、腾讯这样的大公司一样中招了。
相对封闭的iOS尚且如此（单一开发工具，单一软件分发渠道，独家封闭系统iOS，独家硬件iPhone）尚且能出这么大问题，想想Android会怎么样？Android官方网站几年前就被封了无法访问，大部分开发者都是从国内渠道下载的开发工具。
App的安全可靠吗？国内无数家忙着改Android皮肤就称自己是“操作系统”厂商，他们能保证自己的定制Android版本是安全吗？他们有真正的操作系统厂商级别的能力吗？进一步，他们能保证自己使用的开发工具安全吗？每家手机厂商都恨不得做自己的Android app下载渠道，他们能保证这些渠道上分发的app安全吗？甚至，他们能保证自己的下载市场安全吗？
请大家继续联想吧。有朋友跟我说，你想多了，Android哪需要这么麻烦啊，本来国内环境就是木马遍地了。真实情况恐怕只能用惨烈来形容。顺便说一声，传说Google要把Play Store进入中国，提供一个受审查的版本，很多人说这是Google妥协了，我看这根本不是妥协了，是中国内部的Android环境太糟糕，已经威胁全球生态了，Google不得不自己出手解决这个问题。所以，一旦Google Play真的进了中国，请大家记得立刻把Play Store做为自己唯一的Android软件下载渠道，哪怕它不好用，不中国国情，甚至显得有点傻里傻气…千万记得，安全比方便更重要。
请大家继续联想吧。有朋友跟我说，你想多了，Android哪需要这么麻烦啊，本来国内环境就是木马遍地了。真实情况恐怕只能用惨烈来形容。顺便说一声，传说Google要把Play Store进入中国，提供一个受审查的版本，很多人说这是Google妥协了，我看这根本不是妥协了，是中国内部的Android环境太糟糕，已经威胁全球生态了，Google不得不自己出手解决这个问题。所以，一旦Google Play真的进了中国，请大家记得立刻把Play Store做为自己唯一的Android软件下载渠道，哪怕它不好用，不中国国情，甚至显得有点傻里傻气…千万记得，安全比方便更重要。
在这些前提下，重新认真考虑Ken的演讲提到的观点就显得更加重要，深入思考我们信任的可信。到底什么是可信的呢？开发工具可信吗？操作系统可信吗？你觉得下载来之后验证一下md5或者sha512总应该可信了，但你用来计算sha的工具是哪下载来的？你又如何知道这个工具本身是可信呢？在一个封闭的，难以和真正源头沟通的环境下，根本没办法谈所谓的信任。
在中国目前的环境下，难以直接套用成熟的软件开发和管理流程，除非保证团队所有人都必须翻墙，必须用Google查资料，必须不信任国内网站。你的团队中有一个习惯用百度查资料，顺着国内论坛的链接从百度网盘或者迅雷下载工具的人，就不知道会惹出来多大麻烦。这次事件充分证明了这一点，我起初认为腾讯应该不会有问题，因为我知道腾讯内部有极好的网络环境，但最终不幸的是微信也中招了。
我们的恶劣环境已经改变了工程师的习惯，甚至改变了教育，就算是在腾讯内部这么好的网络环境下，仍然有人会去百度查资料，用百度网盘下载开发工具。就像很多留学生到了美国仍然用百度搜索一样，环境的改变并不能直接逆转已经完成的用户习惯。
比较讽刺的是，在中国特色的现实世界反而又制约了出现大规模安全灾难的可能性。比如，中国有相当严重的网络监控、审查和实名制、以及互联网公司必须保存（而且要向有关部门开放）的各种用户数据，并且互联网和世界半隔绝，在出现这种问题的时候，要抓到始作俑者又相对简单。现实世界中，只要在论坛发个贴，去你家查水表就是分分钟的事情。这大概算是“不幸+不幸“互相抵消之后产生了一点点微小的幸运吧。
比较讽刺的是，在中国特色的现实世界反而又制约了出现大规模安全灾难的可能性。比如，中国有相当严重的网络监控、审查和实名制、以及互联网公司必须保存（而且要向有关部门开放）的各种用户数据，并且互联网和世界半隔绝，在出现这种问题的时候，要抓到始作俑者又相对简单。现实世界中，只要在论坛发个贴，去你家查水表就是分分钟的事情。这大概算是“不幸+不幸“互相抵消之后产生了一点点微小的幸运吧。
很多年前，我说招聘工程师有几个原则，比如，必须使用Google而不是百度，必须翻墙而不是用国内替代品，必须优先使用国外的工具。经常有人认为这种要求过于苛刻，甚至认为是装逼。这次事件告诉了我们，这些良好的习惯确实是工程师的第一道防线，融入世界主流，可以让你少遭遇很多中国特色的麻烦。虽然保持这些良好的习惯需要付出不小的代价，但事实证明这些代价是值得的。
这样的网络环境，是我们这一代工程师的耻辱，但我们如此愤怒于此 ，又如此无能为力，这是这个时代最令人悲哀的事情。
我们对此有多么无能为力呢？我写这篇文章的时候就在想，大家应该赶快传播它，因为我觉得它很快会被删掉。这就是无能为力的具体表现。
我们对此有多么无能为力呢？我写这篇文章的时候就在想，大家应该赶快传播它，因为我觉得它很快会被删掉。这就是无能为力的具体表现。
顺便说一句，1996年，受Ken的案例启发，我写过一篇科幻小说，大意是一种病毒把编译器做为感染的源头，最终感染了操作系统。在这个操作系统上，它会判断用户指令对它是否会造成伤害，如果是有害的指令，就假装执行一下，实际并不真执行，从而可以躲过杀毒软件和人工清除。这同样是信任问题，在这个环境下，没有任何可信的东西，这种病毒将会在操作系统中永存，并且把自己附着于任何在这台计算机上制造的软件中。在一个计算机一开机就无线联网的时代，病毒可以借此高速传播，最后人类已经找不到一台干净的计算机可以去编写真正干净的操作系统了。（90年代还没有无线网络，那时候甚至连有线网络都没普及，Sun还在号称网络就是计算机，那时候一台随时联网的计算机简直太奢侈了，但如今看来…世界确实已经发展到了这样，想找一台不联网的计算机倒是不容易了）。
不知道这种幻想中的病毒什么时候会真正出现……其实，前几年工信部推行绿坝的时候，我当时就觉得那简直是创造这种病毒的一个非常好的机会，还好最终绿坝计划被放弃了。中国网络和政策环境的特殊性，将来真的有可能制造出适合这种病毒生存的环境，就像这次因为GFW的正面和潜在影响，让70年代Ken设想的RoTT在2015年大规模流行，40多年的时间跨度……
著名科幻作家韩松说过：“中国的现实变得比科幻还要科幻”。深以为然：“中国的现实变得比科幻还要科幻”。深以为然。
