都說 iOS 是目前最穩定，最安全，最省心的手機操作系統，真的是這樣嗎？
這個小編暫時持 “ 保留 ” 的觀點。
首先是安全，對於果子我來說，隻要不亂下載東西及亂跳彈窗，就算安全，反正 iCloud 我也不存資料。
而穩定，自 iOS 11 後，iOS 的穩定性就一直是個迷，iOS 11 公認最差勁的 iOS ，iOS 12 又好起來。
iOS 13 及目前的 14 ，說不上太好，但也說不上很差，就是沒有 iOS 10 之前的版本用的舒服。
至於省心，我想更多的原因歸結於 “ 卡，崩，死 ” 三項！
不用做任何優化及安裝多餘的 App ，就能維持相對的流暢，這或許也是 iOS 足夠省心的一個原因。
不過現在國產手機廠商的各種 “ 底層 ” 魔改優化，省心這方面也不輸 iOS 。
反觀 iOS 最近的幾代版本一直被噴。
有些漏洞及功能一直沒有完善。
比如 iOS 最近最新的 “ WiFi ” Bug ！
它能一直讓你打不開 WiFi ，甚至 AirDrop ！
重啟都沒用的那種。
不過也是，AirDrop 的傳輸條件就是需要 WiFi ，現在 WiFi 罷工瞭，AirDrop 怎麼可能正常工作。
那麼你們可能會好奇，為什麼我們現在沒有碰上這種情況呢？
原因很簡單，既然是漏洞，是 Bug 。
那麼肯定需要特定的 “ 觸發條件 ” 。
而這個觸發條件也非常簡單：
隻需將 WiFi 路由器的 SSID（WiFi 名稱）改為 “ %p%s%s%s%s%n ”
隨後連接
就會發現 iPhone 會自動重啟，重啟過後 WiFi 就再也打不開瞭！
AirDrop 等凡是依靠 WiFi 類的功能，一樣都處於自動關閉的階段。
就算把 WiFi 的名稱再改為正常，重啟等手段也一樣無濟於事。
根據外網一位名叫 Carl Schou 的工程師描述：
他第一次測試使用的是 iOS 14.4.2 ，隨後他升級為最新的 iOS 14.6 ，不過這個問題一直沒有得到蘋果的修復跟解決。
再經他在網上公佈之後，也有許多網友冒險嘗試，情況都基本一致。
有的小夥伴不會說打不開，而是根本無法加入這個網絡。
蘋果自傢的 Mac 及安卓機型，則沒有這個問題。
看來是 iOS 專享啊！
那麼問題來瞭！
為什麼 iPhone 的機型連接瞭，就會出現這樣的問題呢？
看到 Schou 推文的其他安全工程師認為：
是 iPhone 對 WiFi 名稱的解析出現問題導致瞭這個錯誤。
也就是說 iPhone 會將未經過濾的 “ % ” 之類的 WiFi 名稱傳遞給一些執行格式化字符串的內部庫。
而這會導致任意的內存寫入和緩沖區溢出，從而破壞內存數據。
說白瞭 iPhone 沒有把 “ %p%s%s%s%s%n ” 理解成普通文字，而是當成瞭特殊字符串來處理。
最終出於安全保護機制則禁止用戶去使用 WiFi 網絡。
iPhone 的 “ 錯誤日志 ” 也證明瞭這一點。
不過小編想應該沒有人會用這樣的 WiFi 名稱，所以大傢也不必擔心會變成這種情況。
要是真的有的小夥伴不小心陷入這種情況，隻需在設置——通用——還原中找到——還原網絡設置。
重新還原一遍網絡設置就可以啦！
而至於為什麼上述的 Carl Schou 會用到這樣的名字發現這樣的問題，單純是他工作的原因。
還是不建議大傢去連接甚至模仿這樣的行為，要是在外面看到有 “ % ” 號的 WiFi 。
也不要去連接，因為帶有這個符號的 WiFi 往往可能不安全甚至會出現上述的情況。
還是非常危險的。
當然！其實這也不是 iOS 第一次因為 “ 字符 ” 問題引起死機，無響應，功能休眠等情況。
此前由意大利國旗 Emoji 和一串信德文（南亞巴基斯坦信德人語言）組成的字符就成功將 iOS 直接弄崩潰。
這個字符 Bug 也在 iOS 中存活瞭很長一段時間，直至當時最新的 iOS 13.4.5 才解決瞭這個問題。
還有 “ 黑點 ” Bug 等種種字符文本類漏洞，此前也流行過很長一段時間。
其中包含瞭大量不可見的 Unicode 字符，這些字符會導致 CPU 在處理時負載過高。
在發送後就能讓 iPhone 和 iPad 直接卡死或崩潰。
總的來說，無論是現在或是以後，“ 字符類 ” 漏洞依舊會存在於系統中。
我們能做的，就是不去碰，不去試，等著 iOS 版本的更新去解決這樣的問題。
留言列表
