首页>新闻>苹果资讯>1970成为iOS之殇,熊孩子该如何自救?

1970成为iOS之殇,熊孩子该如何自救?

2016-02-26
5593
来源:freebuf

继上个月的十二行代码分分钟让浏览器崩溃iPhone重启事件之后,近日又有网友爆出:如果把64位的iOS设备(iPhone、iPad、iPod touch)系统时间修改为1970年1月1日,设备重启后将变砖。


1970成为iOS之殇,熊孩子该如何自救?



也有人称:即便是进DFU模式都无法刷机重启,只能到售后去解决问题。


今天抱着No Try No High Give Me Five的心态把自己的iPhone(型号:5S)系统时间设置成了1970年1月1日:


1970成为iOS之殇,熊孩子该如何自救?



当时的我心想:只要把时间设置成23点五十多分,只需十来分钟就能恢复正常,想想都觉得自己机智得不要不要的,然后安心地重启了设备。


重启之后,设备和大多数人的一样:变砖了,一直卡在开机的Logo界面,而且设备还比平时更烫。


原以为只有等十几分钟,系统日期转为1970年1月2日的时候就能恢复,可是苹果白屏持续了二十分钟,然后又关机放了二十分钟依旧不能开机!


1970成为iOS之殇,熊孩子该如何自救?



终于,设备在系统时间为1970年1月2日零点三十多分的时候进入了正常界面,BTW没想到的是输入锁屏密码竟然有十来秒的延迟,然后设备又自动重启了!然后就一直白屏、发烫直到没电… 嗯,当时整个人的状态是这样的:



No Zuo No Die Why You Cry,You Try You Die Don't Ask Why.


苹果客服给出了一个强制恢复方法:


1970成为iOS之殇,熊孩子该如何自救?



使用这一方法时建议最好采用windows机器来进行操作。


1970成为iOS之殇,熊孩子该如何自救?



到这一步时,选择更新或者恢复均可。


接着iTunes将会下载1.8个G的iOS9.2.1系统文件,下载完成将进行软件提取、恢复操作:


1970成为iOS之殇,熊孩子该如何自救?



恢复阶段时iTunes、苹果均会显示进度条:


1970成为iOS之殇,熊孩子该如何自救?

1970成为iOS之殇,熊孩子该如何自救?




之后只需耐心等待数十分钟即可。


如果之前未进行数据备份,通过这种方法对iPhone进行恢复后原有数据将全部丢失!


那么是否还有其他方法呢?答案是有的。那就是:拆机并拆出电池,放置10分钟后重新安装。(这一方法未进行验证,如不想数据丢失的小伙伴可尝试一下)


为什么会有这个Bug?(下面答案内容来自feomg@知乎)


iOS系统时间使用Unix时间戳(Unix epoch)表示(time_t数据类型)。在系统中,使用系统位数个二进制位储存时间。Unix时间戳规定:UTC时区的1970年1月1日 0点0时0秒的值为0,以秒为单位,即每过一秒,二进制数字加1。


在32位系统中,time_t是长度为32位的,有符号整数(signed int)类型。首个二进制位是符号位,用来储存正负。正数则为1970/1/1以后的时间,负数反之;其余的31位用来记数。当时间到达2038年1月19日 3时14分08秒时,数值位全部向前进1,导致符号位被置1,其余31位为0。介时,将出现『时间回归』的情况,系统时间变为1901年12月13日 20时45分52秒,系统将会出现错误。


1970成为iOS之殇,熊孩子该如何自救?



那么64位系统中又是怎样的问题呢?我们说到了以UTC时区的1970年1月1日 0点0时0秒为界限,数值为0,时间正常流逝为正数,反之为负数。不过各位需要留意的是,时间受到时区的影响。


假设一种情况,我原来是北京时区,假设将时间设置到了1970年1月1日0点0时0秒,那么我将这个时间转换为UTC时间,公式:北京时间= GMT+8 = UTC+8,那么UTC时间则为1969年12月31日16时0分0秒。这样就会出现时间负值,即时间回归bug触发,系统启动卡在Kernel阶段,时间错误,无法继续进行启动。


苹果是如何回应的?


苹果官方对这一事件做出了回应,确认如果将系统时间手动设置为1970年5月或者更早,iPhone、iPad、iPod touch将会无法重启。


苹果称会在未来的软件更新中解决这个问题,但不清楚会在如今的iOS 9.2.2上直接OTA,还是得等下个月的iOS 9.3。


苹果建议已经变砖的用户联系苹果售后,但是现在Apple Store里的很多员工都头疼死了:因为不少人很好奇这个Bug,但舍不得拿自己的iPhone做试验,就跑到苹果店里把人家的展示用iPhone、iPad给玩死了……


苹果的这一问题不禁让人想起:linux 2.6.18-164以下版本内核在处理闰秒事件的问题以及千年虫(计算机2000年问题,缩写为“Y2K”)


Linux内核闰秒问题


这一问题发生在2012年7月,当时水木社区用户称:低内核版Linux开启NTP服务将会在本月遇到闰秒BUG,从而导致服务器重启。该用户表示:国际地球自转和参考坐标系统服务(IERS)将在格林威治时间2012年6月30日午夜增加一闰秒。


由于Linux kernel和Posix关于NTP时间跳变的标准不同,将在2012年6月30日23:59:59跳变到2012年7月1日后引起ntpd进程锁死,从而造成部分开启ntp服务的linux系统重启。Linux内核在2.6.18-164.e15之后的版本中解决了这个问题。


格林威治时间对应到北京时间即7月1日的7点59分59秒,中国也曾于这个时间全球同步进行闰秒调整,出现了7点59分60秒的特殊现象。


千年虫问题


百科上的资料显示:计算机2000年问题,又叫做“千年虫”、“电脑千禧年千年虫问题”或“千年危机”。缩写为“Y2K”。是指在某些使用了计算机程序的智能系统(包括计算机系统、自动控制芯片等)中,由于其中的年份只使用两位十进制数来表示,因此当系统进行(或涉及到)跨世纪的日期处理运算时(如多个日期之间的计算或比较等),简单来说,就是由于早期的计算机配置比较低,为了节省空间就把年份只用后两位数表示,如1900就表示为00,这样到新千年时便会出现问题了:电脑把2000年认为是1900年。就会出现错误的结果,进而引发各种各样的系统功能紊乱甚至崩溃。因此从根本上说千年虫是一种程序处理日期上的bug,而不是病毒。