最近在網上沸騰的iOS時間bug鬧的沸沸揚揚，據說是將iOS系統(tǒng)時間修改為1970/1/1，重啟后系統(tǒng)將永遠無法開機。那么這個事情是真的嗎？如果是真的有什么合理的解釋嗎？

　　想要真正了解這一bug，您可能需要以下知識。

UNIX時間戳

　　在確認這件事情的真假前，你需要了解的一個知識是Unix時間戳。

　　iOS系統(tǒng)時間使用Unix時間戳(Unix epoch)表示(time_t數據類型)。在系統(tǒng)中，使用系統(tǒng)位數個二進制位儲存時間。

　　Unix時間戳規(guī)定，UTC時區(qū)的1970年1月1日 0點0時0秒的值為0，以秒為單位，即每過一秒，二進制數字加1。

不能往前調，那我把時間往后調

　　有些好奇的朋友拿出了自己手機，心想：既然我不能往回調，那我要是把時間使勁往后調能怎樣？

　　細心的朋友發(fā)現了一個問題，iOS系統(tǒng)可以設置的最大時間是2038年1月1日，并不能再往后設置。蘋果一定考慮到了這個問題，為什么這么說呢？

　　我們拿32位系統(tǒng)舉例。在32位系統(tǒng)中，time_t是長度為32位的，有符號整數(signed int)類型。首個二進制位是符號位，用來儲存正負。正數則為1970/1/1以后的時間，負數反之；其余的31位用來記數。當時間到達2038年1月19日 3時14分08秒時，數值位全部向前進1，導致符號位被置1，其余31位為0。介時，將出現『時間回歸』的情況，系統(tǒng)時間變?yōu)?901年12月13日 20時45分52秒，系統(tǒng)將會出現錯誤。

　　所以Apple為了避免這種問題導致的錯誤發(fā)生，將最大時間期限定在了2038年1月1日 23時59分59秒。這樣即使超出這個范圍，在18天內也不會有太大問題，況且32位設備到那個時候基本都已經淘汰了。

　　64位系統(tǒng)會不會受到這個影響呢？通過計算我們可以得到，292,277,026,596年12月04日 15時30分08秒是64位系統(tǒng)可以表示的最大時間。

　　如果你想了解更多關于32位系統(tǒng)在2038將出現的問題，請移步: Year 2038 problem。

64位處理器的『時間回歸』問題

　　有了剛才的知識儲備，現在我們回到正題，開始探討搭載64位處理器設備的時間bug。

　　我們說到了以UTC時區(qū)的1970年1月1日 0點0時0秒為界限，數值為0，時間正常流逝為正數，反之為負數。不過各位需要留意的是，時間受到時區(qū)的影響。

　　假設一種情況，我原來是北京時區(qū)，假設將時間設置到了1970年1月1日 0點0時0秒，那么我將這個時間轉換為UTC時間，公式：北京時間 = GMT+8 = UTC+8,那么UTC時間則為1969年12月31日 16時0分0秒。這樣就會出現時間負值，即時間回歸bug觸發(fā)，系統(tǒng)啟動卡在Kernel階段，時間錯誤，無法繼續(xù)進行啟動?！　?/p>

觸發(fā)bug條件與表現

　　滿足以下條件，『時間回歸』bug被觸發(fā)：

　　系統(tǒng)版本：iOS 8.0 ~ iOS 9.3 beta 3

　　硬件設備：搭載64位處理器的設備（即處理器為A7~A9X的設備）

　　進入『設置』-『通用』-『時間與日期』，關閉『自動設置』，并將時間修改為1970年1月1日，分秒任意。

　　修改時間后，需要重啟設備。

Bug觸發(fā)表現：iOS設備啟動時，卡在蘋果Logo，無法繼續(xù)啟動。

Bug危害分析

　　黑客可以利用此bug通過無線局域網發(fā)出范圍性攻擊。

　　當iOS設備連接到公共網絡時，iOS系統(tǒng)將會使用NTP服務對時區(qū)、時間進行校準。如果黑客發(fā)送惡意的NTP攻擊，將iOS系統(tǒng)時間校準至UTC < 0的時間，那么所有用戶設備均會受到此bug影響，在重新啟動設備后無法使用設備。

　　文章至此結束。

　　如果文章存在不妥、紕漏，歡迎各位批評指正。