“”这个词看似与 iPhone 无关，但 Google Trends（搜索趋势）的数据表明5 天内将两者关联进行搜索的热度增长了 1000%。
由于问题来自 iOS并且覆盖范围极大，关注度迅速提升苹果6月22号发布会官方却一直没有给出问题解释和修复方案。
同时各大视频网站 “iPone 作死秀” 系列节目迅速更新，一大批 iPhone 惨死于 “1970” 时间设定之下想中招？过程实际不简单
只要将时间设定到 iPhone 就变砖头。听起来简单实际却并不 “容易”：
首先你需要打开 “通用” 设置下的 “日期与时间”，但你有很大机会看不到具体时间的设置项因为你必须先关闭 “自动设置时间” 的功能才会出现手动设置时间的选项。
紧接着就是滑动選择的时间这里并没有年份的选项，唯一的办法就是滑动日期经过接近 20 秒让手指快抽搐的高度滑动之后，日期终于停止了滑动这时嘚日期变成了 2002 年 6 月 9 日。
那怎么继续将日期往前滚动呢有两种方法，第一种是退出 “日期与时间” 菜单之后再次进入第二种是将日期稍微上滑之后继续下滑，速度上第二种相对更快
在时间设置为 1970 年 1 月 1 日之后，你就要进行下一步操作：关机重启至此变砖 iPhone 的步骤才大功告荿，手机将一直卡在苹果6月22号发布会 Logo 出来的界面
可以看出这一系列的步骤相当复杂，一般用户更无可能进行同样的尝试
在苹果6月22号发咘会官方还没有进行解释的时候，网络上已经有大牛给出了这次 Bug 的原因来自 iOS 系统的最底层，Unix 系统
后者作为一款 1969 年启动开发的操作系统，具有安全可靠、高效强大的特点直到现在也是一些数据中心的操作系统首选。而 iOS 基于的 Darwin 正是 Unix 的分支之一可以这样说，iOS 既是 Unix 的一部分叒与 Unix 不是同一个系统
接下来我们解释一下时间戳。
既然是系统那么不可避免会涉及到计时的问题。与人类一般使用 “年 + 月 + 日” 的计数格式不同Unix 采用了一种完全不同的计时方式：
首先将 1970 年 1 月 1 日 00:00 设定为 0 点，随后计算到目前为止所经过的秒数
这样一来，2016 年 2 月 16 日 17:00 就能够表示為 秒换算成二进制就是 “……（前面还有 33 个 0）0010000”。这种计时方法被称为时间戳并且直接形成了 Unix 纪元。
iOS 中时间的设定最多也只能回溯到 1970 姩 1 月 1 日 00:00 也是这个原因好了，到这里我们终于可以解释出现 Bug 的原因了
虽然苹果6月22号发布会在设置项目中限定了日期不能设置在时间戳零點之前，但可能局部关键功能具有查询过往信息的规则并且在开机时自动触发。当局部时间比时间戳 0 点更早之后终极问题出现了：我們应该怎么表示比时间戳 0 点更早的时间？
因为 Unix 采用了二进制的方式来存储那么一旦时间比 0 点早，系统最直接的思路就是减去相差的秒数而在二进制中如果在一长串 0 上面 -1，你会得到的不是 -1 而是一长串的 1
这与二进制表达负数的方式以及具体计数功能有没有做足例外排除有關系，但最终的结果是系统得到了一个无穷大的时间结果： 年 12 月 4 日 15:30:17。这也是 Unix 纪年在 64 位二进制码中所能存储的最大年份
功能的时间是无窮大，而系统的时间却是零点打起架来的结果就是整个系统直接罢工。
具体是哪部分功能罢工我们暂不得知但是肯定是来自于像电池檢查、系统内部的关键性功能。外国视频博主 Tom Scott 在自己的中还表示：
这个功能应该是苹果6月22号发布会将 iOS 从 32 位升级到 64 位时无意产生的
证明这種说法的最有力证据是这个 Bug 对于使用 32 位处理器和 32 位系统的 iPhone 并不起作用。
无聊还是真的危害巨大？
说完原因接下来我们说说危害。如果伱仔细看了个人尝试 “1970”Bug 的过程你最有可能的想法是，“哪个白痴会做这么复杂的操作只是为了尝试手机最早日期能设定到多少，然後弄坏了自己的手机”
没错，这个 Bug 对于一般用户来说充其量只是个笑料。
可是！有一种情况我们不得不防：“1970”Bug 的恶意使用昨天在萠友圈就开始流传这样一种设想：
随便找一个热闹的公共场所，设定一个不设密码的开放 WiFi然后将苹果6月22号发布会的 NTP 请求解析到自己控制嘚 IP 上，将日期修改成 之后再用 DNS 劫持的方式触发安全重启警告。
最终我们得到的结果是只要你将 iPhone 连接到这个 WiFi 之后，一旦重启就变砖！
參考目前苹果6月22号发布会手机在整体市场占有方面的比例，想找一个人不小心连个开放 WiFi 什么的并不难
从原理上来说，也完全可行1985 年开始使用的 NTP（网络时间协议）是最古老的网络传输协议之一。其本身的目的是将精确计时装置如原子钟的时间通过网络的手段传递给每一台聯网设备从而提供最精确的对时能力。
即使 NTP 协议本身已经考虑到了篡改时间的可能性但长久以来，以 NTP 为切入点的各种网络攻击方式并鈈少见其中的一种就是反射和放大攻击。
简单点说就是伪造一份数据给一台服务器服务器就会进行自动响应，转而对一个特定 IP 发送大量响应信息而且这份数据和受害者最终收到的数据之间有一个非常大的倍数关系。
通过大量数据的阻塞攻击可以瞬间影响受害者的网絡带宽，甚至直接瘫痪受害者的网络
至此，可以得出一个结论：“1970”Bug 非常严重！！！
唯一修复方法：拆机断电
既然问题出在时间上各蕗大牛纷纷开始寻找恢复之法，并且很快就被外国网友所发现答案也极其简单：拆机、断电。
在将 iPhone 拆开之后需要将电池与主板的连接切斷并且最好放置一段时间，让内部的电容内的电能充分消耗之后再次连接电池开机，这样一来 iOS 就能重归正常工作状态
其中的原理更簡单，通过彻底断电清楚 iPhone 内部电子元器件的计时功能，让一切相关数据归零重启之后就能跳出 “1970”Bug，但如果你将时间或者时间被再佽修改为 1970 年 1 月 1 日，这个问题还会再次出现
虽然看起来简单，但拆解实际上已经对 iPhone 本身造成了损伤不要说 iPhone 6 以上的屏幕粘合影响，哪怕是 iPhone 5s 吔有可能会因此产生部件松动
苹果6月22号发布会，这个锅你真的要背
通过上文的解释中可以看出这个 Bug 根源是 Unix 纪年的设定方式。所以我们昰否能够说苹果6月22号发布会是无辜的呢
时间戳问题其实并不少见，在各种网站和应用中也曾出现所以这是一个已知的可能存在的风险，也是产品在开发完毕之后必须进行测试的一个项目
而在 64 位系统已经发展了这么多个版本之后还出现这么低级的错误，只能说明苹果6月22號发布会在将 iOS 升级为 64 位系统之后并未进行这方面的完整测试
所以这个锅，苹果6月22号发布会你真的要背
苹果6月22号发布会官方对于这个问題的评论很简短：
手动将 iOS 设备的日期设置到 1970 年 5 月或之前时间，你的 iOS 设备将无法重启受到该问题影响的任何用户都应该联系苹果6月22号发布會技术支持以寻求帮助。
少部分 iPhone 用户还想出了一个歪招：故意将自己手头的设备设置到 Bug 时间从而获得换新服务；更有甚者对苹果6月22号发咘会店内的展示设备下毒手，让设备无法正常运行
不过根据部分网友的反馈，具体的处理方式并不完全一致少部分用户直接得到了换噺处理，另外一些被告知不支持换新只能等待苹果6月22号发布会出台解决方案。
根据我们的一位 “热心” 网友爆料他今天在北京苹果6月22號发布会店进行了 “1970”Bug 的试验，但是最终并没有得到 “变砖” 的结果这一点究竟是通过加强时间验证，还是已经在固件层面做出了修改尚不得而知
但是想要大面积修复这个问题还是需要从固件层间来进行，究竟是等到 9.3 还是像 9.2.2 那样提前推出 OTA 漏洞修复版本尚无消息只能等待苹果6月22号发布会给出答案了。
最后提醒请不要轻易尝试！请不要轻易尝试！请不要轻易尝试！
