iPhone转移到1970年的换砖原理拯救方法

大家好，今日小科来聊聊一篇关于iPhone转移到1970年的换砖原理拯救方法的文章，现在让我们往下看看吧！

最近网上出现了很多iOS时间bug。据说iOS系统时间改为1970/1/1，重启后系统永远无法开机。那么这件事是真的吗？如果有，有没有合理的解释？要真正理解这个bug，您可能需要以下知识。

unix纪元，unix时间，posix时间

在确认这件事的真相之前，你需要知道一件事，那就是Unix时间戳。

IOS系统时间用Unix epoch (time_t数据类型)表示。在系统中，系统位用于存储时间。

Unix时间戳规定，1970年1月1日UTC时区0: 00: 00秒的值为0，以秒为单位，即每秒钟二进制数递增1。

我不能前进，所以我要把时间往后移。

有好奇的朋友拿出手机想：既然不能回拨，把时间往后推怎么办？

我细心的朋友发现了一个问题。iOS系统可以设置的最长时间是2038年1月1日，以后不能设置。苹果肯定考虑过这个问题。为什么这么说？

让我们以32位系统为例。在32位系统中，time_t是一个32位有符号整数类型。第一个二进制位是符号位，用于存储正位和负位。正数是1970/1/1之后的时间，负数则相反；剩余的31位用于计数。当时间到达2038年1月19日3: 14: 08时，数字位全部提前1，导致符号位设置为1，其余31位为0。届时会出现“时间倒退”的情况，系统时间会改为1901年12月13日20: 45: 52，系统会出现错误。

因此，为了避免这个问题带来的错误，苹果将最大时限设定在2038年1月1日23: 59: 59。即使超出这个范围，18天内也不是大问题。此外，到那时，所有32位设备都已被淘汰。

64位系统会受此影响吗？通过计算我们可以得到，596年12月4日292，277，026和15: 30: 08是一个64位系统所能代表的最大时间。

如果你想了解更多32位系统在2038年会出现的问题，请移至： Year 2038问题。

64位处理器的时间回归问题

有了刚才的知识储备，现在回到主题，开始讨论64位处理器设备的时间bug。

我们讲过以1970年1月1日0: 00: 00 UTC时区为界，数值为0，时间的正常流逝为正，否则为负。但是需要注意的是，时间是受时区影响的。

假设我曾经在北京时区。如果时间设置为1970年1月1日0: 00: 00，那么我将把这个时间转换为UTC时间。公式为：北京时间=格林尼治时间8=世界协调时8，那么世界协调时时间为1969年12月31日16: 00: 00。这样就会出现负时间值，即时间回归bug触发，系统引导卡处于Kernel阶段，时间不对，无法继续引导。

触发bug条件和表现

当满足以下条件时，会触发“时间回归”错误：

系统版本：iOS 8.0 ~ iOS 9.3 beta 3

硬件：配备64位处理器的设备(即配备处理器A7~A9X的设备)

进入“设置”-“常规”-“时间和日期”，关闭“自动设置”，将时间改为1970年1月1日，每分每秒。

修改时间后，设备需要重新启动。

Bug触发性能：iOS设备启动时卡在Apple Logo里，无法继续启动。

解决办法

适用于所有64位处理器的IOS设备

拆卸机器并取出电池，放置10分钟后重新安装。

当电量充足时，等待几个小时。当Unix时间戳的值大于等于0时，系统时间生效，可以正常开启。

防范越狱设备

1.添加Cydia源http://repo.ziph0n.com/

2.并行安装BrickingDate插件。

注意：这个插件只能防止人为修改时间，不能恶意篡改代码(安装效果如下图所示)。

Bug危害分析

黑客可以利用这个bug通过WLAN发起范围攻击。

当iOS设备连接到公共网络时，iOS系统将使用NTP服务来校准时区和时间。如果黑客发送恶意NTP攻击，将iOS系统时间校准到UTC 0，所有用户设备都会受到此bug的影响，重启设备后无法使用设备。

这篇好文章是转载于：知行礼动