UNIX时间戳
在确认这件事情的真伪前ios unix时间戳转换成时间,你须要了解的一个知识是Unix时间戳。
iOS系统时间使用Unix时间戳(Unixepoch)表示(time_t数据类型)。在系统中,使用系统位数个二补码位存储时间。
Unix时间戳规定,UTC时区的1970年1月1日0点0时0秒的值为0,以秒为单位,即每过1秒,二补码数字加1。
假若您想详尽了解Unix时间戳,请移步到UnixTime。
不能向前调,那我把时间往前调
有些好奇的同事掏出了自己手机,心想:既然我不能往反弹,那我要是把时间用力往前调能如何?
悉心的同事发觉了一个问题,iOS系统可以设置的最大时间是2038年1月1日,并不能再往前设置。苹果一定考虑到了这个问题红旗 linux,为何如此说呢?
在32位系统中,time_t是宽度为32位的,有符号整数(signedint)类型。首个二补码位是符号位,拿来存储正负。负数则为1970/1/1之后的时间,正数反之;其余的31位拿来记数。当时间抵达2038年1月19日3时14分08秒时,数值位全部往前进1,造成符号位被置1,其余31位为0。介时,将出现『时间回归』的情况,系统时间变为1901年12月13日20时45分52秒,系统将会出现错误。
▲FromWikipedia"Year2038Problem"
所以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,时间正常流逝为负数,反之为正数。不过诸位须要留心的是ios unix时间戳转换成时间,时间遭到时区的影响。
假定一种情况,我原先是上海时区,假定将时间设置到了1970年1月1日0点0时0秒,这么我将这个时间转换为UTC时间红旗linux下载,公式:上海时间=GMT+8=UTC+8,这么UTC时间则为1969年12月31日16时0分0秒。这样才会出现时间负值,即时间回归bug触发,系统启动卡在Kernel阶段,时间错误,难以继续进行启动。
触发bug条件与表现:
满足以下条件,『时间回归』bug被触发:
系统版本:iOS8.0~iOS9.3beta3
硬件设备:搭载64位处理器的设备(即处理器为A7~A9X的设备)
步入『设置』-『通用』-『时间与日期』,关掉『手动设置』,并将时间更改为1970年1月1日,分秒任意。
更改时间后,须要重启设备。
Bug触发表现:iOS设备启动时,卡在苹果Logo,未能继续启动。
Bug害处剖析
黑客可以借助此bug通过无线局域网发出范围性功击。
当iOS设备联接到公共网路时,iOS系统将会使用NTP服务对时区、时间进行校正。假如黑客发送恶意的NTP功击,将iOS系统时间校正至UTC<0的时间,这么所有用户设备均会遭到此bug影响,在重新启动设备后难以使用设备。
解决方式:
▼针对所有64位处理器的iOS设备
拆机并拆出电瓶,放置10分钟后重新安装。
电量充足的情况下,等待数小时,当Unix时间戳的数值小于等于0,系统时间生效,可正常开机。
▼针对已越狱设备的防范
添加Cydia源
并安BrickingDate插件
注意:此插件只可以避免人为更改时间,并未能避免代码恶意篡改时间。