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

摘要

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

继上个月的十二行代码分分钟让浏览器崩溃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没想到的是输入锁屏密码竟然有十来秒的延迟,然后设备又自动重启了!然后就一直白屏、发烫直到没电… 嗯,当时整个人的状态是这样的:

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

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,而不是病毒。

*作者/雪碧 0xroot,转载须注明来自FreeBuf黑客与极客(FreeBuf.COM)

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: