第145章 价值一亿美元的漏dong

    当然，虽然这个漏洞存在。

    类似于这种的例子在计算机的世界里有很多。

    当蘋果手机里时间戳的时间设置成0的时候重启手机。

    （这是为了在系统时间戳表达的时间上减去相差的秒数来查询之前的内容）

    林灰记得以前玩ACM的时候经常遇到那种比较蛋疼的编程题。

    首先用户需要打开“通用”设置下的“日期与时间”。

    紧接着用户要做的时间事情是滑动选择的时间。

    似乎没什么好办法。

    在这里用户必须先关闭“自动设置时间”的功能才会出现手动设置时间的选项。

    至此iPhone变砖的步骤才大功告成。

    这与二进制表达负数的方式有关系。

    这样一个很难触发的漏洞有什么价值吗？

    尽管没别的好办法，系统是机器。

表示出来的话为1403433025 秒。

    反而会返回一个极大的时间。

    在Unix里当时间戳为0的时候进行求差也会遇到类似的这种情况。

    用户要接着进行下一步操作：关机重启。

    手机的查询机制在通过时间求差查询的时返回的时间非但不是一个时间戳0之前的时间。

    经过很麻烦的操作将才可以将时间设置为1970年1月1日。

    一个奇妙的世界。

    0-1≠-1？

    这个机制没办法取消，因为关机重启之后手机肯定是要读取一部分先前的日志数据的。

    实际进行的的运算是：（1）00……0-1（ps：省略号中有61个0）

    得到的结果是11……1（ps：省略号中有61个1）

    即手机直接即变砖。

    在时间设置为 1970 年 1 月 1 日之后。

    得到的数实际是2的64方-1。

    这种情况下如果时间戳是正常时间的话，那么读取先前的日志数据并不会有什么问题。

    这个时候就会在时间戳0的基础上进行-1操作。

    比如说两个正数相加结果为0这种情况。

    但脑回路正常的用户在安全的网络环境下想触发这个漏洞很麻烦。

    如果用户想触发这个漏洞的话。

    听起来很匪夷所思，但实际上在程序里面涉及到这种现象比比皆是。

    不过在0的基础上-1就比较悲催了。

    这种计时方法被称为时间戳。

    出错的后果很直接整个系统直接罢工。

    功能的时间是无穷大，而系统的时间却是0。

    但实际操作的时候必须要考虑数据溢出的情况。

    对于普通用户来说这个漏洞不算什么。

    凡事就怕有心人故意利用。

    当局部时间比时间戳 0 点更早的情况下。

    这样的话0-1≠-1

    换算成对应的二进制在Unix系统下表示时间。

    二进制数据在执行在执行00……0-1

    将时间设置成UTC时区1970 年 1 月 1 日 00:00很容易出问题。

    但对于有心搞

    因为没有年份的选项，用户想要改变唯一的办法就是滑动日期。

    听起来这个漏洞似乎很难触发啊！

    总而言之，计算机世界。

    但当UTC时区1970 年 1 月 1 日 00:00的时候，这个时候时间戳的时间是0。

    iOS系统也沿袭了Unix这一计时方法。

    也正因此，iOS 中时间的设定最多也只能回溯到 UTC时区1970 年 1 月 1 日 00:00 也是这个原因。

    尽管多数时候可以通过人为的因素避免触发这个漏洞。

    但跑程序测试的时候遇到的测试数据都是那种超大数。

    而现在这种情况，查询之前的时间会出错。

    得到的结果并不是-1。

    表面上要求两个数相加。

    而仅仅是这样还不会触发这个漏洞。

    应该怎么表示比时间戳 0 点更早的时间？

    又不是拥有智慧的生物，它一样是要通过查询机制找到更早时间的。

    但涉及到一些特殊的在局部关键功能具有查询过往信息的规则的时候

    但蘋果手机开机的时候就有一个这样强制查询过往信息的机制这个几乎无法避免。

    漏洞这种东西也一样。

    因为 Unix 采用了二进制的方式来存储。

    当然有价值。

    仅仅是设置成这个时间的话不会有什么问题。

    按照这一番操作下来的话手机将一直卡在苹果手机开机时Logo刚刚出来的界面。

    听起来要求很简单。