-
-
1970成为iOS之殇，熊孩子又该如何自救？
-
发表于: 2016-2-22 22:14
-
新闻链接：1970成为iOS之殇，熊孩子又该如何自救？
新闻时间：2016-02-16
新闻正文：
继上个月的十二行代码分分钟让浏览器崩溃iPhone重启事件之后，近日又有网友爆出：如果把64位的iOS设备（iPhone、iPad、iPod touch）系统时间修改为1970年1月1日，设备重启后将变砖。
也有人称：即便是进DFU模式都无法刷机重启，只能到售后去解决问题。
今天抱着No Try No High Give Me Five的心态把自己的iPhone（型号：5S）系统时间设置成了1970年1月1日：
当时的我心想：只要把时间设置成23点五十多分，只需十来分钟就能恢复正常，想想都觉得自己机智得不要不要的，然后安心地重启了设备。
重启之后，设备和大多数人的一样：变砖了，一直卡在开机的Logo界面，而且设备还比平时更烫。
原以为只有等十几分钟，系统日期转为1970年1月2日的时候就能恢复，可是苹果白屏持续了二十分钟，然后又关机放了二十分钟依旧不能开机！
终于，设备在系统时间为1970年1月2日零点三十多分的时候进入了正常界面，BTW没想到的是输入锁屏密码竟然有十来秒的延迟，然后设备又自动重启了！然后就一直白屏、发烫直到没电… 嗯，当时整个人的状态是这样的：
No Zuo No Die Why You Cry,You Try You Die Don't Ask Why.
苹果客服给出了一个强制恢复方法：
使用这一方法时建议最好采用windows机器来进行操作。
到这一步时，选择更新或者恢复均可。
接着iTunes将会下载1.8个G的iOS9.2.1系统文件，下载完成将进行软件提取、恢复操作：
恢复阶段时iTunes、苹果均会显示进度条：
之后只需耐心等待数十分钟即可。
如果之前未进行数据备份，通过这种方法对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秒，系统将会出现错误。
那么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）
新闻时间：2016-02-16
新闻正文：
继上个月的十二行代码分分钟让浏览器崩溃iPhone重启事件之后，近日又有网友爆出：如果把64位的iOS设备（iPhone、iPad、iPod touch）系统时间修改为1970年1月1日，设备重启后将变砖。
也有人称：即便是进DFU模式都无法刷机重启，只能到售后去解决问题。
今天抱着No Try No High Give Me Five的心态把自己的iPhone（型号：5S）系统时间设置成了1970年1月1日：
当时的我心想：只要把时间设置成23点五十多分，只需十来分钟就能恢复正常，想想都觉得自己机智得不要不要的，然后安心地重启了设备。
重启之后，设备和大多数人的一样：变砖了，一直卡在开机的Logo界面，而且设备还比平时更烫。
原以为只有等十几分钟，系统日期转为1970年1月2日的时候就能恢复，可是苹果白屏持续了二十分钟，然后又关机放了二十分钟依旧不能开机！
终于，设备在系统时间为1970年1月2日零点三十多分的时候进入了正常界面，BTW没想到的是输入锁屏密码竟然有十来秒的延迟，然后设备又自动重启了！然后就一直白屏、发烫直到没电… 嗯，当时整个人的状态是这样的：
No Zuo No Die Why You Cry,You Try You Die Don't Ask Why.
苹果客服给出了一个强制恢复方法：
使用这一方法时建议最好采用windows机器来进行操作。
到这一步时，选择更新或者恢复均可。
接着iTunes将会下载1.8个G的iOS9.2.1系统文件，下载完成将进行软件提取、恢复操作：
恢复阶段时iTunes、苹果均会显示进度条：
之后只需耐心等待数十分钟即可。
如果之前未进行数据备份，通过这种方法对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秒，系统将会出现错误。
那么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）
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
