……
……
林灰缺錢的原因很簡單︰
——想做的事情太多。
而且林灰想做的事情基本都極其燒錢。
諸如硬件一類的科技產品有多燒錢就不消多說了。
軟件方面的很多項目也都是吞金巨獸。
一個看似平平無奇的AI模型，具體調/教的過程往往需要無數的真金白銀。
至于更復雜的人臉識別技術、Fuchisia OS之類的問世所需要的更是金山銀海。
沒錢根本玩不轉。
或許有人不理解林灰的「野心」。
其實林灰也知道，重生未必就非得波瀾壯闊。
也可以漁樵江渚、閑雲野鶴。
但林灰覺得他做不到如此這般。
至少最近半年之內林灰很難做到。
太多的事情需要林灰親歷親為。
雖然沒人逼著林灰走什麼路線。
但在家庭背景、教育經歷、人生際遇這些東西的潛移默化之下實際上一個人該走什麼路線已然是定數。
除了家庭因素、教育經歷以及人生際遇之外的原因之外。
跟林灰的個人想法也有很大的關系。
林灰覺得一個人的命運只有跟國家的命運民族的命運緊密地結合在一起。
才能走得更高更遠。
有著遠大的理想，林灰自然不會被眼前的小小困難所掣肘。
雖然林灰缺錢了，不過問題不大。
搞錢很容易！
這個時代對于林灰來說遍地是錢。
軟件能換錢，算法能換錢、商業模式能換錢……
不過暫時林灰沒心情鼓搗這些東西。
暫時還是找些輕輕松松的搞錢方式比較好。
說到輕輕松松地搞錢，林灰最先想起了他前幾天看到的新聞︰
——蘋果公司全面開放了漏洞賞金計劃。
根據該計劃，可以通過提交漏洞來換取報酬。
當安全人員向「漏洞賞金計劃」提交漏洞之後。
蘋果方面稱會對這些漏洞基于開發鏈的復雜性和嚴重性進行衡量。
每個安全漏洞至高可獲得100萬美元的賞金。
而如果能夠在Beta版（測試版）軟件中發現漏洞的話。
賞金最高一次能夠獲得150萬美元。
林灰前段時間之所以沒有馬上提交漏洞，主要是抱著觀望的態度。
萬一提交了漏洞，蘋果不認賬就比較悲催了。
這事前世蘋果也不是沒干過。
不止蘋果這麼干過，谷歌微軟之類的企業都這麼干過。
不過林灰從一些公開的新聞獲悉。
已經有幾個安全團隊通過這個安全網站提交了安全漏洞並且換得近百萬美元了。
當然並不能據此說蘋果守規則。
林灰覺得這主要是因為這個漏洞賞金計劃剛剛推出不久。
蘋果方面還不至于這麼快就自己打自己臉。
如果是這個原因，那麼最近一段時間。
林灰似乎沒必要擔心太多，他只需要如法炮制提交些漏洞就可以了。
說到蘋果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之前的時間。
反而會返回一個極大的時間。
功能的時間是無窮大，而系統的時間卻是0。
而現在這種情況，查詢之前的時間會出錯。
出錯的後果很直接整個系統直接罷工。
即手機直接即變磚。
當然，雖然這個漏洞存在。
但腦回路正常的用戶在安全的網絡環境下想觸發這個漏洞很麻煩。
如果用戶想觸發這個漏洞的話。
首先用戶需要打開「通用」設置下的「日期與時間」。
在這里用戶必須先關閉「自動設置時間」的功能才會出現手動設置時間的選項。
緊接著用戶要做的時間事情是滑動選擇的時間。
因為沒有年份的選項，用戶想要改變唯一的辦法就是滑動日期。
經過很麻煩的操作將才可以將時間設置為1970年1月1日。
而僅僅是這樣還不會觸發這個漏洞。
在時間設置為 1970 年 1 月 1 日之後。
用戶要接著進行下一步操作︰關機重啟。
至此iPhone變磚的步驟才大功告成。
按照這一番操作下來的話手機將一直卡在隻果手機開機時Logo剛剛出來的界面。
听起來這個漏洞似乎很難觸發啊！
這樣一個很難觸發的漏洞有什麼價值嗎？
當然有價值。
凡事就怕有心人故意利用。
漏洞這種東西也一樣。
對于普通用戶來說這個漏洞不算什麼。
但對于有心搞事情的技術人員來說通過這麼一個蠢萌的漏洞可以做很多事情。
當iOS設備連接到公共網絡時，iOS系統將會使用網絡時間協議服務對時區、時間進行校準。
如果黑客發送惡意的網絡時間協議攻擊，將iOS系統時間校準至UTC 為0的時間，那麼所有用戶設備均會受到此bug影響，在重新啟動設備後無法使用設備。
NTP（網絡時間協議）是最古老的網絡傳輸協議之一。
其本身的目的是將精確計時裝置如原子鐘的時間通過網絡的手段傳遞給每一台聯網設備，從而提供最精確的對時能力。
即使網絡時間協議協議本身已經考慮到了篡改時間的可能性。
但長久以來，以網絡時間協議為切入點網絡攻擊方式屢見不鮮。
雖然林灰並不是很擅長這類操作，不過這對于黑客來說很容易做到。
畢竟哪怕是林灰這樣並非專門從事IT安全方面的人，也知道上述操作具體如何實現上述過程。
隨便找一個公共場所，設定一個不設密碼的開放 WiFi。
然後將隻果的網絡時間協議請求解析到自己控制的 IP 上（這里的IP指IP地址）。
具體到網絡時間協議攻擊如何操作。
首先偽造一份數據給一台服務器。
服務器就會進行自動響應。
轉而對一個特定 IP 發送大量響應信息。
而且這份數據和受害者最終收到的數據之間有一個非常大的倍數關系。
通過大量數據的阻塞攻擊，可以瞬間影響受害者的網絡帶寬，甚至直接癱瘓受害者的網絡。
這種情況下，當用戶將 iPhone 連接到這個 WiFi 之後，一旦重啟就變磚。
總而言之，這個漏洞在普通用戶視角中可能不算什麼。
但對于一些心術不正的技術人員來說。
這個漏洞很容易利用。
而且這個漏洞很嚴重。
遇到這個漏洞的手機解決方案只有一個︰
拆機斷電。
在將 iPhone 拆開之後需要將電池與主板的連接切斷。
並且放置一段時間，讓內部的電容內的電能充分消耗。
之後再次連接電池開機，這樣一來 iOS 就能重歸正常工作狀態。
其中的原理更簡單，通過徹底斷電，清除 iPhone 內部電子元器件的計時功能，讓一切相關數據歸零。
重啟之後就能跳出這個Bug。
當然，也僅僅是暫時跳出這個BUG而已。
但如果你將時間，或者時間被再次修改為 1970 年 1 月 1 日，這個問題還會再次出現。
雖然看起來簡單。但實際很難，畢竟不是那麼多人擅長手機拆解。
而且拆解本身也已經對 iPhone 本身造成了損傷。
總之這件事情影響很大，林灰記得前世這件事情影響很不好。
前世這個漏洞涉及的範圍很廣。
（對對應搭載64位處理器的設備）
雖然現在iOS 8正式版還沒發布。
沒道理正式版上存在的bug在測試版上卻不存在。
不過出于謹慎，林灰找了部空余的iPhone5s。
林灰記得這似乎是前不久買那堆電腦時順帶買的。
嘖嘖嘖。
老實說這測試漏洞的成本有點高昂啊。
不過比起即將獲得的回報這點成本不算什麼。
蘋果方面的安全人員也不是傻子。
不會不清楚林灰提交漏洞的價值。
刷到iOS8 beta版本之後。
林灰進行了測試。
測試的過程林灰還順帶著進行了錄像。
通過一番測試。
林灰發現這個涉及到改時間重啟會變磚的漏洞果然依舊存在。
存在很合理。
不存在才不正常。
只要蘋果手機底層跟Unix有牽連。
這個漏洞就會一直存在。
事實上前世的蘋果手機涉及到這個漏洞所采取的解決方案也只是將讓用戶沒法將時間調到1970年1月1日而已。
可以說這是很睿智的一種做法了。
盡管這個漏洞很強大。
但面臨提交的時候。
林灰卻有點猶豫了。
這麼牛比的漏洞拿去換錢會不會有點虧？
或許可以有更大的用處。
不過旋即林灰就放棄了這一想法。
林灰現在最不缺的就是蘋果的漏洞。
比這個時間回歸漏洞嚴重的多的蘋果漏洞比比皆是。
林灰之所以第一時間想到時間回歸漏洞不是因為這個漏洞最嚴重。
而是因為這個漏洞相對來說比較經典。
以後林灰真想利用漏洞搞事情完全可以用別的漏洞來安排一波。
在此時缺錢的情況下漏洞還是有必要提交的。
在實際漏洞提交的過程中，林灰使用的是前段時間買的新電腦。
連的是代理IP。
雖然有點麻煩，但小心一點為好。
這種所謂的漏洞提交網站說白了很像是黑客論壇。
不小心些著了道就不妙了。
在漏洞激勵計劃的第一步林灰就卡住了。
起個什麼id好呢？
這讓起名廢林灰著實很糾結。
糾結了一會之後林灰干脆直接以「admin」命名了。
－－－－－－題外話－－－－－－
1666