原理揭秘：iPhone调到1970年变砖？ (苹果原理图)

最近在网上沸腾的iOS时间bug闹的沸沸扬扬，据说是将iOS*时间修改为/1/1，重启后*将永远无法开机。那么这个事情是真的吗？如果是真的有什么合理的解释吗？

整理分享原理揭秘：iPhone调到1970年变砖？ (苹果原理图)，希望有所帮助，仅作参考，欢迎阅读内容。

内容相关其他词:打鱼机程序原理揭秘,花瓶姑娘原理揭秘,苹果原理,川剧喷火的原理揭秘,川剧喷火的原理揭秘,飞针麻将原理揭秘,花瓶姑娘原理揭秘,花瓶姑娘原理揭秘,内容如对您有帮助，希望把内容链接给更多的朋友！

　　想要真正了解这一bug，您可能需要以下知识。UNIX时间戳　　在确认这件事情的真假前，你需要了解的一个知识是Unix时间戳。　　iOS*时间使用Unix时间戳(Unixepoch)表示(time_t数据类型)。在*中，使用*位数个二进制位储存时间。Unix时间戳规定，UTC时区的年1月1日0点0时0秒的值为0，以秒为单位，即每过一秒，二进制数字加1。不能往前调，那我把时间往后调　　有些好奇的朋友拿出了自己*，心想：既然我不能往回调，那我要是把时间使劲往后调能怎样？细心的朋友发现了一个问题，iOS*可以设置的最大时间是年1月1日，并不能再往后设置。苹果一定考虑到了这个问题，为什么这么说呢？　　我们拿位*举例。在位*中，time_t是长度为位的，有符号整数(signedint)类型。首个二进制位是符号位，用来储存正负。正数则为/1/1以后的时间，负数反之；其余的位用来记数。当时间到达年1月日3时分秒时，数值位全部向前进1，导致符号位被置1，其余位为0。介时，将出现『时间回归』的情况，*时间变为年月日时分秒，*将会出现错误。

　　所以Apple为了避免这种问题导致的错误发生，将最大时间期限定在了年1月1日时分秒。这样即使超出这个范围，在天内也不会有太大问题，况且位设备到那个时候基本都已经淘汰了。　　位*会不会受到这个影响呢？通过计算我们可以得到，,,,年月日时分秒是位*可以表示的最大时间。位处理器的『时间回归』问题　　有了刚才的知识储备，现在我们回到正题，开始探讨搭载位处理器设备的时间bug。　　我们说到了以UTC时区的年1月1日0点0时0秒为界限，数值为0，时间正常流逝为正数，反之为负数。不过各位需要留意的是，时间受到时区的影响。　　假设一种情况，我原来是北京时区，假设将时间设置到了年1月1日0点0时0秒，那么我将这个时间转换为UTC时间，公式：北京时间=GMT+8=UTC+8,那么UTC时间则为年月日时0分0秒。这样就会出现时间负值，即时间回归bug触发，*启动卡在Kernel阶段，时间错误，无法继续进行启动。触发bug条件与表现　　满足以下条件，『时间回归』bug被触发：　　*版本：iOS8.0~iOS9.3beta3　　硬件设备：搭载位处理器的设备（即处理器为A7~A9X的设备）

　　进入『设置』-『通用』-『时间与日期』，关闭『自动设置』，并将时间修改为年1月1日，分秒任意。修改时间后，需要重启设备。　　Bug触发表现：iOS设备启动时，卡在苹果Logo，无法继续启动。Bug危害分析　　黑客可以利用此bug通过监听局域网发出范围性攻击。　　当iOS设备连接到公共网络时，iOS*将会使用NTP服务对时区、时间进行校准。如果黑客发送恶意的NTP攻击，将iOS*时间校准至UTC<0的时间，那么所有用户设备均会受到此bug影响，在重新启动设备后无法使用设备。