親，你是有多無聊才會把iPhone6s設置到1970年啊，不過既然這件悲傷並且悲劇的事情發生了，那麼我慢還是看看iPhone6s設置時間到1970年變磚解決辦法吧，至少先把手機搶救回來吧，希望iPhone6s設置時間到1970年變磚解決辦法能幫到你吧。
想要解決bug，還是先來了解一下知識吧。
UNIX時間戳
在確認這件事情的真假前，你需要了解的一個知識是Unix時間戳。
iOS係統時間使用Unix時間戳(Unix epoch)表示(time_t數據類型)。在係統中，使用係統位數個二進製位儲存時間。
Unix時間戳規定，UTC時區的1970年1月1日0點0時0秒的值為0，以秒為單位，即每過一秒，二進製數字加1。
如果您想詳細了解Unix時間戳，請移步到 Unix Time。
不能往前調，那我把時間往後調
有些好奇的朋友拿出了自己手機，心想：既然我不能往回調，那我要是把時間使勁往後調能怎樣?
細心的朋友發現了一個問題，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通過無線局域網發出範圍性攻擊。
當iOS設備連接到公共網絡時，iOS係統將會使用NTP服務對時區、時間進行校準。如果黑客發送惡意的NTP攻擊，將iOS係統時間校準至UTC < 0的時間，那麼所有用戶設備均會受到此bug影響，在重新啟動設備後無法使用設備。
[download]198603,197553[/download]
