在系統安全的長期防護中，位址隨機化（ASLR）向來被視為重要防線；然而此篇文章指出，Google Project Zero 的研究顯示，在特定資料結構與序列化流程下，即使沒有傳統的記憶體安全漏洞或時間側通道（timing side-channel），攻擊者也可能從序列化輸出推導出系統記憶體位址，進而削弱ASLR的保護效果。研究以macOS為測試場景，並強調目前仍屬概念驗證（proof-of-concept），未見可直接對外利用的攻擊面；同時 Apple 已於今年 3 月 31 日以 iOS 18.4、iPadOS 18.4、macOS Sequoia 15.4 等安全更新修補相關風險。
此項研究的核心在於「指標作為鍵（pointer as key）的資料結構」，以及序列化／反序列化（NSKeyedArchiver 與 NSKeyedUnarchiver）的行為如何成為洩漏來源。作者詳述研究人員如何藉由構造特製物件並取得系統輸出的序列化結果，觀察鍵值在序列化時的輸出順序與雜湊（hash）行為，進而推斷出物件在記憶體的相對位址位置——也就是挖掘出原本應被 ASLR 隱藏的記憶體資訊。
在實作細節上，強調 NSNull/CFNull 扮演關鍵角色：CFNull 在系統中是唯一的單例（singleton），其雜湊值會直接衍生自物件位址；當 CFNull 被插入 NSDictionary（或類似以雜湊為基礎的映射結構）後，序列化輸出中雜湊桶（hash bucket）的分布會反映出該單例的雜湊值位置。研究人員透過先以大量數值鍵（NSNumber）去填充不同雜湊桶，再插入 NSNull，觀察最終序列化結果中鍵值出現的順序差異，並運用數學組合還原雜湊值，最後回推出 CFNull（即該單例）的實際記憶體位址。
值得注意的是，文章反覆強調這類洩漏與以往的 hashDoS 或基於指標雜湊設計所衍生的資訊洩露概念有親緣關係，但本研究並不仰賴效能退化或時間觀察作為攻擊載具——只要攻擊者能獲得序列化的結果輸出（即可見的反序列化輸出），便能進行位址推演，這使得攻擊途徑在某些跨界（cross-boundary）資料流的場景下，顯得更危險。例如，若某服務把反序列化後的結果跨越信任邊界回傳給未受信任的實體（或外部可觀察輸出），便可能成為建立位址洩漏通道的機會。
另外亦提醒讀者冷靜評估實際風險：目前研究屬概念性演示（theoretical/demo），尚未找到直接可被濫用的現成攻擊面；研究人員也明確表示，除非存在會將序列化輸出回流到可被攻擊者觀察的服務或情境，否則一般使用者不會立即面臨風險。換句話說，攻擊成立通常需具備特定的環境條件——可操控的輸入、可取得的序列化輸出，且該流程跨越安全邊界。
在補救與防護建議上，作者說得很清楚：Apple 已在今年 3 月的安全更新中修補了相關潛在風險；對一般使用者與IT管理者而言，最直接且有效的行動是盡速將 iPhone、iPad 與 mac 端更新至廠商提供的最新系統版本。此外，對於開發者與系統設計者，建議要注意下列防護措施：
- 小心以指標或物件位址作為鍵值的資料結構設計，避免直接將指標導入可被序列化／外洩的輸出。
- 對序列化／反序列化流程的界線進行嚴格控管，避免把內部序列化結果回傳到外部或未受信任的上下文。
- 若必須序列化敏感物件，採用摘要（hashing）、遮蔽（masking）或不可逆轉換（one-way transform）等設計來避免直接洩漏位址相關資訊。
- 建立跨團隊的威脅模型（threat modelling），檢視資料流在系統各邊界是否可能被攻擊者觀察到序列化輸出。
最後本文，提出一個值得資安與軟體社群長期關注的命題：當系統越來越仰賴複雜的資料結構與自動化序列化流程時，傳統以記憶體安全漏洞與時間側通道為主的風險評估框架，已不足以涵蓋所有資訊洩漏路徑。這份Project Zero 的研究提醒我們，資訊安全必須把「語意層面的資料流」——而非僅是「記憶體層面的弱點」——納入威脅分析與防護設計。對企業來說，除了按時套用廠商安全更新外，還要審視系統設計中的序列化邊界與資料流可見性，才能避免類似的概念性攻擊在實務上被放大利用。
