不知道昨天小伙伴们过得怎样
是收到了经济实惠的袋装玫瑰花
↓↓↓
还是这样浪(nue)漫(gou)的玫瑰花海
↓↓↓
又或者你们跟翼叔一样只能改名为
↓↓↓
/其实/
要说昨天最惨的还要数那些
刚收到恋人送的iPhone 6s
结果自己一作导致新机秒变砖的果粉
这大情人节的情侣约会约到苹果店也是没谁了
那么他们究竟做了什么呢？
据苹果店的工作人员说这是因为他们
将iOS系统时间修改为1970/01/01的缘故
▼
此操作会导致重启后系统将永远无法开机
那么这个bug又是为什么出现的呢
如果想要真正了解这一bug
小伙伴可能需要先了解以下知识
UNIX时间戳
在确认这件事情的真假前
你需要了解的一个知识是Unix时间戳
iOS系统时间使用Unix时间戳表示
在系统中使用系统位数个二进制位储存时间
Unix时间戳规定
UTC时区的1970年1月1日 0点0时0秒的值为0
以秒为单位 即每过一秒二进制数字加1
不能往前调那我把时间往后调
有些好奇的朋友拿出了自己手机
心想既然我不能往回调
那我要是把时间使劲往后调能怎样
细心的朋友发现了一个问题
iOS系统可以设置的最大时间是2038年1月1日
并不能再往后设置
苹果一定考虑到了这个问题为什么这么说呢
我们拿32位系统来举个栗子
在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秒
系统将会出现错误
▼
所以Apple为了避免这种问题导致的错误发生
将最大时间期限定在了
2038年1月1日 23时59分59秒
这样即使超出这个范围在18天内也不会有太大问题
况且32位设备到那个时候基本都已经淘汰了
可是64位系统会不会受到这个影响呢
通过计算我们可以得到
292,277,026,596年12月04日 15时30分08秒
是64位系统可以表示的最大时间
64位处理器的"时间回归"问题
有了刚才的知识储备现在我们回到正题
开始探讨搭载64位处理器设备的时间bug
我们说到了以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阶段
时间错误无法继续进行启动
触发bug条件与表现
满足以下条件『时间回归』bug被触发
系统版本:iOS 8.0 ~ iOS 9.3 beta 3
硬件设备:搭载64位处理器的设备
(即处理器为A7~A9X的设备)
进入『设置』-『通用』-『时间与日期』
关闭『自动设置』
并将时间修改为1970年1月1日分秒任意
修改时间后需要重启设备
Bug触发表现为当iOS设备启动时
画面会卡在苹果Logo无法继续启动
Bug危害分析
黑客可以利用此bug通过无线局域网发出攻击
当iOS设备连接到公共网络时
iOS系统将会使用NTP服务对时区时间进行校准
如果黑客发送恶意的NTP攻击
将iOS系统时间校准至UTC < 0的时间
那么所有用户设备均会受到此bug影响
在重新启动设备后无法使用设备
解决办法
NO.1
拆机并拆出电池放置10分钟后重新安装
(当然拆机有风险 操作请谨慎)
NO.2
添加Cydia源http://repo.ziph0n.com/
并安装BrickingDate插件
注意:此插件只可以防止人为修改时间
并无法防止代码恶意篡改时间
(安装效果如下图)
▼
NO.3
电量充足的情况下等待数小时
当Unix时间戳的数值大于等于0
系统时间生效可正常开机
NO.4
拿到苹果售后找工作人员解决
/据说/
心理学有个粉红色大象的思想实验
就是越告诉你别去想粉红色大象
你脑袋里越会出现这么个形象
这次的事件就是如此
人们越是说不要去尝试的事情
往往越有人去做
对此翼叔只想说
"NO ZUO NO DIE"
觉的翼叔的文章对你有帮助
请持续关注我们的账号吧
毕竟毛爷爷都说
“不以关注为目的的阅读,都是耍流氓”