“1970/1/1”，这个词看似与 iPhone 无关，但 Google Trends（搜索趋势）的数据表明，5 天内将两者关联进行搜索的热度增长了 1000%。

因 为，只要你将采用 64-bit 处理器的 iPhone/iPad（iPhone 5S/6/6 Plus/6s/6s Plus、iPad Air/Air 2/mini 2/mini 3/mini 4  均包括在内）日期设置成 1970 年 1 月 1 日，设备就会变砖，并且无法通过寻常的备份还原等手段进行恢复。

由于问题来自 iOS，并且覆盖范围极大，关注度迅速提升，苹果官方却一直没有给出问题解释和修复方案。

同时，各大视频网站“iPone 作死秀”系列节目迅速更新，一大批 iPhone 惨死于“1970”时间设定之下。

想中招？过程实际不简单

只要将时间设定到 1970/1/1，iPhone 就变砖头。听起来简单，实际却并不“容易”：

首先你需要打开“通用”设置下的“日期与时间”，但你有很大机会看不到具体时间的设置项，因为你必须先关闭“自动设置时间”的功能才会出现手动设置时间的选项。

紧接着就是滑动选择的时间，这里并没有年份的选项，唯一的办法就是滑动日期，经过接近 20 秒让手指快抽搐的高度滑动之后，日期终于停止了滑动，这时的日期变成了 2002 年 6 月 9 日。

那怎么继续将日期往前滚动呢？有两种方法，第一种是退出“日期与时间”菜单之后再次进入，第二种是将日期稍微上滑之后继续下滑，速度上第二种相对更快。

在时间设置为 1970 年 1 月 1 日之后，你就要进行下一步操作：关机重启。至此变砖 iPhone 的步骤才大功告成，手机将一直卡在苹果 Logo 出来的界面。

可以看出这一系列的步骤相当复杂，一般用户更无可能进行同样的尝试。

罪魁祸首：时间戳

在苹果官方还没有进行解释的时候，网络上已经有大牛给出了这次 Bug 的原因，来自 iOS 系统的最底层，Unix 系统。

后者作为一款 1969 年启动开发的操作系统，具有安全可靠、高效强大的特点。直到现在也是一些数据中心的操作系统首选。而 iOS 基于的 Darwin 正是 Unix 的分支之一，可以这样说，iOS 既是 Unix 的一部分又与 Unix 不是同一个系统。

接下来我们解释一下时间戳。

既然是系统，那么不可避免会涉及到计时的问题。与人类一般使用“年 +  月 + 日”的计数格式不同，Unix 采用了一种完全不同的计时方式：

首先将 1970 年 1 月 1 日 00:00 设定为 0 点，随后计算到目前为止所经过的秒数。

这 样一来，2016 年 2 月 16 日 17:00 就能够表示为 1455613200 秒，换算成二进制就是“……（前面还有 33 个 0）1010110110000101110010100010000”。这种计时方法被称为时间戳，并且直接形成了 Unix 纪元。

iOS 中时间的设定最多也只能回溯到 1970 年 1 月 1 日 00:00 也是这个原因。好了，到这里我们终于可以解释出现 Bug 的原因了。

虽然苹果在设置项目中限定了日期不能设置在时间戳零点之前，但可能局部关键功能具有查询过往信息的规则，并且在开机时自动触发。当局部时间比时间戳 0 点更早之后，终极问题出现了：我们应该怎么表示比时间戳 0 点更早的时间？

因为 Unix 采用了二进制的方式来存储，那么一旦时间比 0 点早，系统最直接的思路就是减去相差的秒数。而在二进制中如果在一长串 0 上面 -1，你会得到的不是 -1 而是一长串的 1。

这与二进制表达负数的方式以及具体计数功能有没有做足例外排除有关系，但最终的结果是，系统得到了一个无穷大的时间结果：292277026596 年 12 月 4 日 15:30:17。这也是 Unix 纪年在 64 位二进制码中所能存储的最大年份。

功能的时间是无穷大，而系统的时间却是零点。打起架来的结果就是整个系统直接罢工。

具体是哪部分功能罢工我们暂不得知，但是肯定是来自于像电池检查、系统内部的关键性功能。外国视频博主 Tom Scott 在自己的视频中还表示：

这个功能应该是苹果将 iOS 从 32 位升级到 64 位时无意产生的。

证明这种说法的最有力证据是这个 Bug 对于使用 32 位处理器和 32 位系统的 iPhone 并不起作用。

无聊？还是真的危害巨大？

说完原因，接下来我们说说危害。如果你仔细看了个人尝试“1970”Bug 的过程，你最有可能的想法是，“哪个白痴会做这么复杂的操作，只是为了尝试手机最早日期能设定到多少，然后弄坏了自己的手机？”

没错，这个 Bug 对于一般用户来说，充其量只是个笑料。

可是！有一种情况我们不得不防：“1970”Bug 的恶意使用。昨天在朋友圈就开始流传这样一种设想：

随便找一个热闹的公共场所，设定一个不设密码的开放 WiFi，然后将苹果的 NTP 请求解析到自己控制的 IP 上，将日期修改成 1970/1/1 之后，再用 DNS 劫持的方式触发安全重启警告。

最终我们得到的结果是，只要你将 iPhone 连接到这个 WiFi 之后，一旦重启，就变砖！

参考目前苹果手机在整体市场占有方面的比例，想找一个人不小心连个开放 WiFi 什么的并不难。

从原理上来说，也完全可行，1985 年开始使用的 NTP（网络时间协议）是最古老的网络传输协议之一。其本身的目的是将精确计时装置如原子钟的时间通过网络的手段传递给每一台联网设备，从而提供最精确的对时能力。

即使 NTP 协议本身已经考虑到了篡改时间的可能性，但长久以来，以 NTP 为切入点的各种网络攻击方式并不少见，其中的一种就是反射和放大攻击。

简单点说就是伪造一份数据给一台服务器，服务器就会进行自动响应，转而对一个特定 IP 发送大量响应信息，而且这份数据和受害者最终收到的数据之间有一个非常大的倍数关系。

通过大量数据的阻塞攻击，可以瞬间影响受害者的网络带宽，甚至直接瘫痪受害者的网络。

至此，可以得出一个结论：“1970”Bug 非常严重！！！

唯一修复方法：拆机断电

既然问题出在时间上，各路大牛纷纷开始寻找恢复之法，并且很快就被外国网友所发现。答案也极其简单：拆机、断电。

在将 iPhone 拆开之后需要将电池与主板的连接切断，并且最好放置一段时间，让内部的电容内的电能充分消耗之后，再次连接电池开机，这样一来 iOS 就能重归正常工作状态。

其中的原理更简单，通过彻底断电，清楚 iPhone 内部电子元器件的计时功能，让一切相关数据归零。重启之后就能跳出“1970”Bug，但如果你将时间，或者时间被再次修改为 1970 年 1 月 1 日，这个问题还会再次出现。

虽然看起来简单，但拆解实际上已经对 iPhone 本身造成了损伤。不要说 iPhone 6 以上的屏幕粘合影响，哪怕是 iPhone 5s 也有可能会因此产生部件松动。

苹果，这个锅你真的要背

通过上文的解释中，可以看出这个 Bug 根源是 Unix 纪年的设定方式。所以我们是否能够说苹果是无辜的呢？

答案：并不。

时间戳问题其实并不少见，在各种网站和应用中也曾出现，所以这是一个已知的可能存在的风险，也是产品在开发完毕之后必须进行测试的一个项目。

而在 64 位系统已经发展了这么多个版本之后还出现这么低级的错误，只能说明苹果在将 iOS 升级为 64 位系统之后并未进行这方面的完整测试。

所以这个锅，苹果你真的要背。

苹果官方对于这个问题的评论很简短：

手动将 iOS 设备的日期设置到 1970 年 5 月或之前时间，你的 iOS 设备将无法重启。受到该问题影响的任何用户都应该联系苹果技术支持以寻求帮助。

少部分 iPhone 用户还想出了一个歪招：故意将自己手头的设备设置到 Bug 时间，从而获得换新服务；更有甚者对苹果店内的展示设备下毒手，让设备无法正常运行。

不过根据部分网友的反馈，具体的处理方式并不完全一致。少部分用户直接得到了换新处理，另外一些被告知不支持换新，只能等待苹果出台解决方案。

根据我们的一位“热心”网友爆料，他今天在北京苹果店进行了“1970”Bug 的试验，但是最终并没有得到“变砖”的结果。这一点究竟是通过加强时间验证，还是已经在固件层面做出了修改尚不得而知。

但是想要大面积修复这个问题还是需要从固件层间来进行，究竟是等到 9.3 还是像 9.2.2 那样提前推出 OTA 漏洞修复版本尚无消息。只能等待苹果给出答案了。

最后提醒，请不要轻易尝试！请不要轻易尝试！请不要轻易尝试！

楼主可以试试！

写的蛮好的

官方已经承认此BUG了，大家可以去apple store试试

引用2楼Mr_Captain的回复

楼主可以试试！

这可不敢···