林灰前段時間之所以沒有馬上提交漏洞，主要是抱著觀望的態度。

萬一提交了漏洞，蘋果不認賬就比較悲催了。

這事前世蘋果也不是沒幹過。

不止蘋果這麼幹過，谷歌微軟之類的企業都這麼幹過。

不過林灰從一些公開的新聞獲悉。

已經有幾個安全團隊透過這個安全網站提交了安全漏洞並且換得近百萬美元了。

當然並不能據此說蘋果守規則。

林灰覺得這主要是因為這個漏洞賞金計劃剛剛推出不久。

蘋果方面還不至於這麼快就自己打自己臉。

如果是這個原因，那麼最近一段時間。

林灰似乎沒必要擔心太多，他只需要如法炮製提交些漏洞就可以了。

說到蘋果iOS的漏洞，林灰最先想到的是“時間迴歸漏洞”。

時間迴歸漏洞可以說是iOS系統最經典的漏洞之一。

所謂的時間迴歸漏洞指的是有一段時間蘋果手機調整時間會變磚。

調整時間手機會變磚？

聽起來可能有點滑稽，不過這漏洞真實存在。

在iOS 64位裝置的早期版本上。

只要將蘋果手機時間設定到 1970年1月1日，然後重啟，蘋果手機就變磚頭。

之所以存在這樣一個漏洞跟iOS 系統的最底層——Unix 系統有很大的關係。

Unix作業系統，是一個強大的多用戶、多工作業系統。

該系統支援多種處理器架構。

按照作業系統的分類，屬於分時操作系統。

該系統最早由肯·湯普遜、丹尼斯·裡奇和道格拉斯·麥克羅尹於1969年在AT＆T的貝爾實驗室開發。

Unix系統有很多衍生產物。

iOS 基於的 Darwin 正是 Unix 的分支之一。

iOS作為一個系統一定程度上繼承了Unix的特性。

既然是系統，那麼不可避免會涉及到計時的問題。

與人類一般使用“年+月+日”的計數格式不同。

Unix 採用了一種完全不同的計時方式：

在Unix系統中計時方式是先將（UTC時區） 1970 年 1 月 1 日 00:00 設定為 0 點。

隨後計算到目前為止所經過的秒數。

舉個栗子。

2014年6月22日18時30分25秒。

表示出來的話為1403433025 秒。

換算成對應的二進制在Unix系統下表示時間。

這種計時方法被稱為時間戳。

iOS系統也沿襲了Unix這一計時方法。

也正因此，iOS 中時間的設定最多也只能回朔到 UTC時區1970 年 1 月 1 日 00:00 也是這個原因。

僅僅是設定成這個時間的話不會有什麼問題。

但涉及到一些特殊的在區域性關鍵功能具有查詢過往資訊的規則的時候

將時間設定成UTC時區1970 年 1 月 1 日 00:00很容易出問題。

儘管多數時候可以透過人為的因素避免觸發這個漏洞。

但蘋果手機開機的時候就有一個這樣強制查詢過往資訊的機制這個幾乎無法避免。

這個機制沒辦法取消，因為關機重啟之後手機肯定是要讀取一部分先前的日誌資料的。

這種情況下如果時間戳是正常時間的話，那麼讀取先前的日誌資料並不會有什麼問題。

但當UTC時區1970 年 1 月 1 日 00:00的時候，這個時候時間戳的時間是0。

當區域性時間比時間戳 0 點更早的情況下。

應該怎麼表示比時間戳 0 點更早的時間？

似乎沒什麼好辦法。

儘管沒別的好辦法，系統是機器。

又不是擁有智慧的生物，它一樣是要透過查詢機制找到更早時間的。

這個時候就會在時間戳0的基礎上進行-1操作。

（這是為了在系統時間戳表達的時間上減去相差的秒數來查詢之前的內容）

不過在0的基礎上-1就比較悲催了。

得到的結果並不是-1。

0-1≠-1？

聽起來很匪夷所思，但實際上在程式裡面涉及到這種現象比比皆是。

這與二進制表達負數的方式有關係。

因為 Unix 採用了二進制的方式來儲存。

二進制資料在執行在執行00……0-1

實際進行的的運算是：（1）00……0-1（ps：省略號中有61個0）

得到的結果是11……1（ps：省略號中有61個1）

這樣的話0-1≠-1

得到的數實際是2的64方-1。

類似於這種的例子在計算機的世界裡有很多。

比如說兩個正數相加結果為0這種情況。

林灰記得以前玩ACM的時候經常遇到那種比較蛋疼的程式設計題。

表面上要求兩個數相加。

聽起來要求很簡單。

但跑程式測試的時候遇到的測試數據都是那種超大數。

但實際操作的時候必須要考慮資料溢位的情況。

總而言之，計算機世界。

一個奇妙的世界。

在Unix裡當時間戳為0的時候進行求差也會遇到類似的這種情況。

當蘋果手機裡時間戳的時間設定成0的時候重啟手機。

手機的查詢機制在透過時間求差查詢的時返回的時間非但不是一個時間戳0之前的時間。

【穩定運行多年的小說app，媲美老版追書神器，老書蟲都在用的換源App，huanyuanapp.org】

反而會返回一個極大的時間。

功能的時間是無窮大，而系統的時間卻是0。

而現在這種情況，查詢之前的時間會出錯。

出錯的後果很直接整個系統直接罷工。

即手機直接即變磚。

當然，雖然這個漏洞存在。

但腦迴路正常的使用者在安全的網路環境下想觸發這個漏洞很麻煩。

如果使用者想觸發這個漏洞的話。

首先使用者需要開啟“通用”設定下的“日期與時間”。

在這裡使用者必須先關閉“自動設定時間”的功能才會出現手動設定時間的選項。

緊接著使用者要做的時間事情是滑動選擇的時間。

因為沒有年份的選項，使用者想要改變唯一的辦法就是滑動日期。

經過很麻煩的操作將才可以將時間設定為1970年1月1日。

而僅僅是這樣還不會觸發這個漏洞。

在時間設定為 1970 年 1 月 1 日之後。

使用者要接著進行下一步操作：關機重啟。

至此iPhone變磚的步驟才大功告成。

按照這一番操作下來的話手機將一直卡在蘋果手機開機時Logo剛剛出來的介面。

聽起來這個漏洞似乎很難觸發啊！

這樣一個很難觸發的漏洞有什麼價值嗎？

當然有價值。

凡事就怕有心人故意利用。

漏洞這種東西也一樣。

對於普通用戶來說這個漏洞不算什麼。

但對於有心搞事情的技術人員來說透過這麼一個蠢萌的漏洞可以做很多事情。