第145章 价值一亿美元的漏洞（1 / 2）
……
……
林灰缺钱的原因很简单：
——想做的事情太多。
而且林灰想做的事情基本都极其烧钱。
诸如硬件一类的科技产品有多烧钱就不消多说了。
软件方面的很多项目也都是吞金巨兽。
一个看似平平无奇的AI模型，具体调/教的过程往往需要无数的真金白银。
至于更复杂的人脸识别技术、FuchisiaOS之类的问世所需要的更是金山银海。
没钱根本玩不转。
或许有人不理解林灰的“野心”。
其实林灰也知道，重生未必就非得波澜壮阔。
也可以渔樵江渚、闲云野鹤。
但林灰觉得他做不到如此这般。
至少最近半年之内林灰很难做到。
太多的事情需要林灰亲历亲为。
虽然没人逼着林灰走什么路线。
但在家庭背景、教育经历、人生际遇这些东西的潜移默化之下实际上一个人该走什么路线已然是定数。
除了家庭因素、教育经历以及人生际遇之外的原因之外。
跟林灰的个人想法也有很大的关系。
林灰觉得一个人的命运只有跟国家的命运民族的命运紧密地结合在一起。
才能走得更高更远。
有着远大的理想，林灰自然不会被眼前的小小困难所掣肘。
虽然林灰缺钱了，不过问题不大。
搞钱很容易！
这个时代对于林灰来说遍地是钱。
软件能换钱，算法能换钱、商业模式能换钱……
不过暂时林灰没心情鼓捣这些东西。
暂时还是找些轻轻松松的搞钱方式比较好。
说到轻轻松松地搞钱，林灰最先想起了他前几天看到的新闻：
——蘋果公司全面开放了漏洞赏金计划。
根据该计划，可以通过提交漏洞来换取报酬。
当安全人员向“漏洞赏金计划”提交漏洞之后。
蘋果方面称会对这些漏洞基于开发链的复杂性和严重性进行衡量。
每个安全漏洞至高可获得100万美元的赏金。
而如果能够在Beta版（测试版）软件中发现漏洞的话。
赏金最高一次能够获得150万美元。
林灰前段时间之所以没有马上提交漏洞，主要是抱着观望的态度。
万一提交了漏洞，蘋果不认账就比较悲催了。
这事前世蘋果也不是没干过。
不止蘋果这么干过，谷歌微软之类的企业都这么干过。
不过林灰从一些公开的新闻获悉。
已经有几个安全团队通过这个安全网站提交了安全漏洞并且换得近百万美元了。
当然并不能据此说蘋果守规则。
林灰觉得这主要是因为这个漏洞赏金计划刚刚推出不久。
蘋果方面还不至于这么快就自己打自己脸。
如果是这个原因，那么最近一段时间。
林灰似乎没必要担心太多，他只需要如法炮制提交些漏洞就可以了。
说到蘋果iOS的漏洞，林灰最先想到的是“时间回归漏洞”。
所谓的时间回归漏洞指的是有一段时间蘋果手机调整时间会变砖。
调整时间手机会变砖？
听起来可能有点滑稽，不过这漏洞真实存在。
在iOS64位设备的早期版本上。
只要将苹果手机时间设定到1970年1月1日，然后重启，苹果手机就变砖头。
之所以存在这样一个漏洞跟iOS系统的最底层——Unix系统有很大的关系。
Unix操作系统，是一个强大的多用户、多任务操作系统。
该系统支持多种处理器架构。
按照操作系统的分类，属于分时操作系统。
该系统最早由肯·汤普逊、丹尼斯·里奇和道格拉斯·麦克罗伊于1969年在AT＆T的贝尔实验室开发。
Unix系统有很多衍生产物。
iOS基于的Darwin正是Unix的分支之一。
iOS作为一个系统一定程度上继承了Unix的特性。
既然是系统，那么不可避免会涉及到计时的问题。
与人类一般使用“年+月+日”的计数格式不同。
Unix采用了一种完全不同的计时方式：
在Unix系统中计时方式是先将（UTC时区）1970年1月1日00:00设定为0点。
随后计算到目前为止所经过的秒数。
举个栗子。
2014年6月22日18时30分25秒。
表示出来的话为1403433025秒。
换算成对应的二进制在Unix系统下表示时间。
这种计时方法被称为时间戳。
iOS系统也沿袭了Unix这一计时方法。
也正因此，iOS中时间的设定最多也只能回溯到UTC时区1970年1月1日00:00也是这个原因。
仅仅是设置成这个时间的话不会有什么问题。
但涉及到一些特殊的在局部关键功能具有查询过往信息的规则的时候
将时间设置成UTC时区1970年1月1日00:00很容易出问题。
尽管多数时候可以通过人为的因素避免触发这个漏洞。
但蘋果手机开机的时候就有一个这样强制查询过往信息的机制这个几乎无法避免。
这个机制没办法取消，因为关机重启之后手机肯定是要读取一部分先前的日志数据的。
这种情况下如果时间戳是正常时间的话，那么读取先前的日志数据并不会有什么问题。
但当UTC时区1970年1月1日00:00的时候，这个时候时间戳的时间是0。
当局部时间比时间戳0点更早的情况下。
应该怎么表示比时间戳0点更早的时间？
似乎没什么好办法。
尽管没别的好办法，系统是机器。
又不是拥有智慧的生物，它一样是要通过查询机制找到更早时间的。
这个时候就会在时间戳0的基础上进行-1操作。
（这是为了在系统时间戳表达的时间上减去相差的秒数来查询之前的内容）
不过在0的基础上-1就比较悲催了。
得到的结果并不是-1。
0-1≠-1？
听起来很匪夷所思，但实际上在程序里面涉及到这种现象比比皆是。
这与二进制表达负数的方式有关系。
因为Unix采用了二进制的方式来存储。
二进制数据在执行在执行00……
实际进行的的运算是：（1）00……0-1（ps：省略号中有61个0）
得到的结果是11……1（ps：省略号中有61个1）
这样的话0-1≠
得到的数实际是2的64方-1。
类似于这种的例子在计算机的世界里有很多。
比如说两个正数相加结果为0这种情况。
林灰记得以前玩ACM的时候经常遇到那种比较蛋疼的编程题。
表面上要求两个数相加。
听起来要求很简单。
但跑程序测试的时候遇到的测试数据都是那种超大数。
但实际操作的时候必须要考虑数据溢出的情况。
总而言之，计算机世界。
一个奇妙的世界。