关于苹果iOS设备日期设置到1970年变砖的原理及解救方法

关于苹果iOS设备日期设置到1970年变砖的原理及解救方法

原理
UNIX时间戳

在确认这件事情的真假前,你需要了解的一个知识是Unix时间戳。

iOS系统时间使用Unix时间戳(Unix epoch)表示(time_t数据类型)。在系统中,使用系统位数个二进制位储存时间。

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被触发:
系统版本:iOS8.0 ~ iOS9.3 beta 3
硬件设备:搭载64位处理器的设备(即处理器为A7~A9X的设备)
进入『设置』-『通用』-『时间与日期』,关闭『自动设置』,并将时间修改为1970年1月1日,分秒任意。
修改时间后,需要重启设备。

Bug触发表现

iOS设备启动时,卡在苹果Logo,无法继续启动。

解决方案
▼针对所有64位处理器的iOS设备

拆机并拆出电池,放置10分钟后重新安装。
电量充足的情况下,等待数小时,当Unix时间戳的数值大于等于0,系统时间生效,可正常开机。

▼针对已越狱设备的防范

添加Cydia源http://repo.ziph0n.com/
并安BrickingDate插件
注意:此插件只可以防止人为修改时间,并无法防止代码恶意篡改时间

Bug危害分析

黑客可以利用此bug通过无线局域网发出范围性攻击。
当iOS设备连接到公共网络时,iOS系统将会使用NTP服务对时区、时间进行校准。如果黑客发送恶意的NTP攻击,将iOS系统时间校准至UTC < 0的时间,那么所有用户设备均会受到此bug影响,在重新启动设备后无法使用设备。

最近才开始往github上放东西 在公司写的又不能放= = 大家姑且看看吧

github地址: https://github.com/FuThD

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值