M15 · 階梯 4 · L4

橫向專題——把信任邊界延伸到深水區

六個可選修的橫向專題，每個都把前面學過的信任邊界延伸到一塊深水區——Network Extension 攻防、Rosetta 2 的安全意涵、虛擬化/VM 的安全模型與研究限制、SEP/firmware 深入、Keychain 與 macOS 資料保護的真實邊界、網路信任（Trust Store / ATS / 憑證釘選）。每節點到為止：給正確心智模型、根因類別、防禦與偵測方向、延伸閱讀，不深入任何可武器化細節。

●●● 前置：M09、M13、M14 systemextensionsctl · arch · sysctl · security · dscl · log · csrutil · bputil

這章怎麼讀

前面十四個模組沿著一條主線把 macOS 的信任邊界逐層拆開：啟動鏈（M01）、Mach-O（M02）、簽章（M03）、Gatekeeper（M04）、SIP（M05）、TCC（M06）、Sandbox（M07）、XPC（M08）、權限分層（M09）、漏洞模型（M13）、DFIR（M14）。這一章是橫向專題——六塊各自獨立、可選修的深水區，掛在相關模組下。

讀法和前面不同：每節都點到為止。目標不是把任一專題講到能動手做，而是：

給你一個正確的心智模型（這塊到底在保護什麼、威脅模型是什麼）；
標出這塊的攻擊面類別與根因（不是 PoC、不是繞過步驟）；
指出防禦與偵測方向；
給延伸閱讀的指北針，讓你知道往哪深挖。

⚠ 本章邊界（對齊 DESIGN.md §10）：本章涉及多個帶 🔴 的主題（SEP/firmware、VM 逃逸、憑證信任鏈攻擊）。所有 🔴 內容只教類別與根因——不提供可武器化的 offset / payload / 繞過腳本 / PoC 構造步驟。動手部分一律是唯讀觀察或在你自己擁有/受控授權的環境進行。這承接 M13「鏈的結構與防禦縱深評估，不是實作利用鏈」與 M14 的偵測視角。

先用探索器快速瀏覽六個專題的概念與防禦/研究切入點，再往下細讀：

橫向專題探索

Network Extension

概念　NE 框架讓第三方以 system extension 形式做 content filter / DNS proxy / packet tunnel（取代舊 kext）。流量在使用者授權下被導向 extension 處理。

防禦/研究切入　偵測面：哪個 App 裝了 NE、攔了什麼流量、是否被濫用做隱蔽通道；NE 本身也受 entitlement 與使用者同意約束。

各專題給正確心智模型與延伸方向；可選修、掛在相關模組下。深入細節以官方 Platform Security 指南與各章為準。

專題一：Network Extension 攻防（接 M07 / M08 / M14）

心智模型

Network Extension（NE）是 Apple 給「在系統層攔截/處理網路流量」用的框架，取代了已棄用的 kernel-level NKE（Network Kernel Extension）——現代 NE 跑在使用者空間的 system extension裡，不再塞進 kernel。常見型別：

型別	做什麼	典型用途
Content Filter（`NEFilterDataProvider`）	對每個 flow 給 allow/deny/peek 裁決	家長控管、企業 DLP、EDR 網路偵測
DNS Proxy / DNS Settings	接管 DNS 解析	企業 DNS、加密 DNS
Packet Tunnel / App Proxy	建 VPN 隧道、逐 App 代理	VPN、ZTNA
Transparent Proxy	透明攔截 TCP/UDP flow	企業流量檢查

攻擊面類別（不是步驟）

雙面性：NE 既是防禦工具（content filter 可做網路偵測），也是攻擊面——一個惡意或被濫用的 NE 站在所有流量的必經之路上，可以攔截、重導、改寫流量。這是典型「站在信任路徑上的中間人位置」類別問題，不是某個 bug。
安裝信任：NE 是 system extension，安裝需使用者核可 + 對應 entitlement（com.apple.developer.networking.networkextension）+ 簽章（接 M03/M04 的信任鏈）。攻擊面在於「誰能讓使用者點下核可」——社交工程、MDM 推送、供應鏈。
content filter 的決策延遲：和 M14 的 ES AUTH client 一樣，content filter 在 flow 上做同步裁決，寫得爛會拖垮網路，逾時的預設處置（fail-open vs fail-closed）本身就是一個要理解的設計取捨。

防禦與偵測方向（接 M14）

盤點誰註冊了 NE：systemextensionsctl list 列出已啟用的 system extension，未預期的 content filter / proxy 就是高價值訊號。
NE 的存在會改變網路 telemetry 的可信度——如果流量先經過一個你不信任的 NE，那麼端點看到的網路紀錄可能已被改寫。把「通往網路的路徑上有沒有非預期的中介」列入威脅建模。

延伸方向

往 M07（sandbox 如何約束 extension）、M08（NE 與主 App 之間的 XPC）、M14（NE 偵測面）三個方向交叉深挖；Apple 的 NetworkExtension framework 文件與 system extension 生命週期是起點。

專題二：Rosetta 2 的安全意涵（接 M02 / M12 / M13）

心智模型

Rosetta 2 是 Apple Silicon 上把 x86_64 指令翻譯成 arm64 執行的相容層。它的兩種模式：**AOT（提前翻譯，結果快取）**為主，**JIT（執行期動態翻譯）**處理無法提前翻的情況（自我修改碼、執行期生成碼）。

⚠ errata / 時效（驗證於 macOS 26）：macOS 26 Tahoe 是最後一個支援 Intel Mac 的 macOS；在 Apple Silicon 上，自 macOS 26.4 起啟動依賴 Rosetta 的 App 會跳出「未來將無法執行」警告。Rosetta 2 預計在 macOS 27 仍可用，macOS 28（預計 2027 秋）起大致停用，僅保留少數例外（部分老舊未維護的遊戲、以及 Linux VM 內的 Intel 二進位）。教材不要把 Rosetta 2 講成永久存在；它正在落日。

安全意涵（類別，不是利用）

JIT 與 W^X 的張力：任何 JIT（包含 Rosetta 的動態路徑、瀏覽器 JS 引擎）天生需要「可寫又最終可執行」的記憶體，這和 W^X / hardened runtime 的「不可同時 wx」有結構性張力。Apple 用 JIT entitlement（com.apple.security.cs.allow-jit 等）+ MAP_JIT + pthread_jit_write_protect_np 的 per-thread 切換來收斂這個面。重點是理解「為什麼 JIT 是一個需要特別 entitlement 與特殊記憶體管理的攻擊面類別」，而非任何具體手法。
翻譯快取的完整性：AOT 翻譯結果會被快取。「翻譯產物的信任從哪來、能不能被竄改」是一個值得理解的信任邊界問題（屬類別層次）。
指令語意落差：x86 與 arm64 的記憶體模型（x86 的 TSO 較強、arm64 較弱）與例外/旗標語意不同；翻譯層要彌平這些落差。對逆向（M12）的意義是：你在 Rosetta 下看到的執行行為是「翻譯後」的，不等於原生 arm64，分析時要意識到這層。

防禦與偵測方向

隨著落日，還在依賴 Rosetta 的二進位本身就是一個庫存風險訊號（過時、可能未維護）。盤點機隊裡哪些 App 仍走 x86_64 路徑，是個務實的 DFIR/IT 工作。
偵測上可關注：是否有非預期程序帶 JIT 相關 entitlement、是否有 x86_64 二進位在不該出現的位置落地執行（接 M14 的 is_platform_binary / 架構欄位思路）。

延伸方向

往 M02（fat binary 與架構選擇）、M12（在 Rosetta 下動態分析的注意事項）、M13（JIT 作為記憶體保護的軍備競賽一環）延伸。

專題三：虛擬化 / VM 的安全模型與研究限制（接 M01 / M05 / M13 / M14）

心智模型

Apple Silicon 用 Virtualization framework（VZ） 跑 guest（macOS / Linux）。對安全研究這是把雙刃：VM 是做黃色/紅色實驗的隔離場（降 SIP、跑可疑樣本都該在 VM 裡），但 VM 不是真機的完整等價物——而這個落差本身就是最重要的學習點。

⚠ errata / 研究限制（驗證於 macOS 26）：guest macOS VM 沒有真正的 Secure Enclave（SEP）。Apple 用一組 AppleVP*.kext（如 VP boot policy / credential manager / keystore）在 VM 裡模擬出缺少的 SEP 行為，讓多數 OS 功能能跑起來。後果：任何把信任根錨定在真 SEP 的保證（UCRT、SEP 管理的金鑰、生物辨識、某些 LocalPolicy 語意）在 VM 裡並不等價。研究時若把 VM 結果直接外推到真機的 SEP/開機安全，會得出錯誤結論。

安全模型重點（類別層次）

隔離邊界 = guest↔host：VM 的核心安全假設是「guest 跑飛了也困在 guest 裡」。VM escape（從 guest 突破到 host）屬於 hypervisor / 裝置模擬層的攻擊面類別——本章只標出「這條邊界存在、它的根因常在裝置模擬與共享記憶體介面」，不教任何逃逸手法（🔴）。
VM 內的安全等級可調：VZ 的 guest 可以設成 reduced security、可降 SIP，方便研究；但這也意味著「VM 裡看到的 SIP/Gatekeeper 行為，取決於你怎麼配置這台 VM」，不能假設等同預設真機。
VM guest 跑在特殊脈絡（如 HACR_EL2 的 Apple ISA 位元被設定）——理解「VM 是被宿主特權層框住的」這個結構即可。

防禦與偵測方向

把 VM 當隔離場用對：跑可疑樣本、做降安全等級實驗一律在 VM；但取證/真實 SEP 行為的結論要回到真機驗證（接 M14 的「驗證於版本/環境」紀律）。
VM 偵測（anti-VM）是惡意樣本常見手法的類別——樣本可能偵測到自己在 VM 裡而改變行為，這會讓動態分析失真（接 M12）。

延伸方向

往 M01（真機的 SEP/LocalPolicy 才是完整信任根）、M13（hypervisor 攻擊面作為一個漏洞類別）延伸；Virtualization framework 文件與 macOS VM 的 SEP 模擬機制是深挖點。

專題四：SEP / firmware 深入（接 M01 / M13）🔴 概念為主

心智模型

Secure Enclave Processor（SEP）是和應用處理器並存但隔離的協處理器，跑自己的 sepOS、有自己的記憶體保護（SEP 有獨立的記憶體加密與隔離），管理：裝置金鑰、生物辨識（Touch ID / Face ID 模板，模板永不離開 SEP）、資料保護金鑰階層、以及開機信任的一部分。心智模型一句話：SEP 是「即使主核心被完全攻陷，仍要守住金鑰與生物辨識」的最後一道隔離。

為什麼這節幾乎全是 🔴

SEP/firmware 的可操作細節高度可武器化（sepOS 的漏洞可破壞整機信任根），因此本節嚴格只到類別與根因：

firmware 信任鏈：承接 M01——每一級（BootROM→iBoot→sepOS / kernelcache）用上級公鑰驗下級的 Image4 manifest，量測雜湊不符就拒絕並落入 recovery/DFU。SEP 的 firmware 也在這條鏈上。這是「結構」，不是任何繞過。
攻擊面類別：SEP 的攻擊面集中在「主核心↔SEP 的訊息介面（mailbox）」與「sepOS 自身的記憶體安全」。理解「為什麼把這麼少的程式碼放進一個隔離處理器，正是為了把可攻擊表面壓到最小」這個設計哲學即可。
mitigation 脈絡（接 M13）：SPTM/TXM、PPL 這類頁表/信任層保護的目的，就是即使核心被攻陷也守住關鍵不變量；SEP 是把這個思路推到硬體隔離的極致。

防禦與偵測方向

對絕大多數防禦者，SEP 是信任的基石而非操作對象——你依賴它（FileVault 金鑰、passkey、Touch ID）而不去戳它。
唯一務實的觀察是版本與啟動安全狀態（見下方真機卡的 csrutil status / bputil 唯讀查詢），確認機器處於預期的安全等級。

延伸方向

往 M01（boot chain 與 LocalPolicy）、M13（隔離處理器作為 mitigation 哲學的極致）延伸。深挖請走 Apple Platform Security Guide 的 SEP 章節——那是理解「保護什麼」的正確入口，不是找洞的清單。

專題五：Keychain 與 macOS 資料保護的真實邊界（接 M05 / M06 / M11）

心智模型

學習者最常見的兩個迷思，這節直接破除：

⚠ errata（DESIGN.md §11 P2 #9）：macOS 沒有 iOS 等級的「逐檔 Data Protection」作為一般狀態。iOS 對每個檔案綁 per-file class key、隨鎖屏狀態決定可不可解密；macOS 桌面多數檔案實際只受 FileVault（volume 級 XTS-AES）保護，per-file class key 在桌面多數情況不啟用。措辭上別讓學習者以為「Mac 上每個檔都有 iOS 那種逐檔加密保護」——威脅模型不同。

⚠ errata（DESIGN.md §11 P2 #10）：「未開 FileVault ≠ 沒加密」。Apple Silicon 一律啟用硬體儲存加密（金鑰由 SEP 管理）。FileVault 的作用是把 Volume Encryption Key（VEK）包進一把由使用者密碼派生的 KEK——也就是「把解密綁到使用者認證」。未開 FileVault 時資料仍是加密的，但機密性僅依賴裝置實體安全 + SEP（開機即可自動解出 VEK），不需要使用者密碼。理解這個差別才不會誤判「偷到一台沒開 FileVault 的關機 Mac，攻擊者能拿到什麼」。

Keychain 的保護模型（類別）

Keychain item 有 accessibility class（如 WhenUnlocked、AfterFirstUnlock、WhenPasscodeSetThisDeviceOnly…）決定「何時可被解密」，金鑰階層最終錨定回 SEP。
存取控制：哪個 App 能讀某個 keychain item 受 access group / 簽章（同 Team ID）+ ACL 約束——這接回 M03 的簽章身分與 M06 的「誰能存取受保護資源」。
WhenPasscodeSet… 與 …ThisDeviceOnly 這類旗標的差別（會不會隨 iCloud Keychain 同步、需不需要已設密碼）是理解 keychain 威脅模型的關鍵維度。

防禦與偵測方向

威脅建模要分清「機器開著被解鎖」vs「關機被偷」：FileVault 主要防後者；前者要靠鎖屏、TCC、sandbox 等執行期機制（接 M06/M07）。
唯讀盤點：fdesetup status（FileVault 開關狀態）、security 工具列舉自己 keychain 的結構（不導出機密）。

延伸方向

往 M05（FileVault/SSV 與開機安全）、M06（資源存取的 TCC 面）、M11（APFS 加密與 FileVault 的真實邊界）延伸。

專題六：網路信任——Trust Store / ATS / 憑證釘選（接 M03 / M04）

心智模型

這節把「簽章信任」（M03 的 code signing）延伸到另一條獨立的信任鏈：TLS/X.509 憑證信任。兩者都是公鑰密碼學，但信任根不同：code signing 錨定 Apple 的簽章根；TLS 錨定系統 Trust Store 裡的 CA 根憑證。

System Trust Store：macOS 內建一組受信任的 root CA，由 Apple 管理更新。使用者/MDM 可加入自訂 root（企業常見），但手動加入的 root 與 Apple 預載的 root 信任程度與用途受系統政策約束。
ATS（App Transport Security）：App 預設要求 TLS 連線符合最低安全標準（現代 TLS 版本、forward secrecy 等）。App 可在 Info.plist 宣告 ATS 例外——ATS 例外本身就是一個值得在威脅建模裡標記的弱化點。
憑證釘選（pinning）：App 主動只信任特定憑證/公鑰，縮小信任面到比整個 Trust Store 更小的集合。釘選是防禦強化（即使某 CA 被攻陷或被迫簽發，攻擊者也過不了釘選）。

攻擊面類別（不是步驟）

流氓 / 被迫簽發的 CA：信任鏈的根因風險在「Trust Store 裡任何一個 CA 被攻陷或被惡意安裝，就能對全站做中間人」。企業環境裡「被推送一個自訂 root」是合法功能，也是攻擊者覬覦的位置（接專題一的 NE 中間人位置）。
釘選的雙面性：釘選擋中間人，但也讓研究者/防禦者自己的流量檢查變難；攻擊者也可能用釘選讓 C2 流量更難被企業 proxy 拆解——這是防禦/攻擊都會用釘選的類別認知。
降級與例外：ATS 例外、過時 TLS 版本、弱密碼套件都是把這條信任鏈降級的面向。

防禦與偵測方向

盤點非預期的自訂 root CA（哪台機器的 Trust Store 被加了什麼）是高價值偵測——對應 NE 與 proxy 的中間人威脅。
App 端：是否宣告了 ATS 例外、有沒有對敏感連線做釘選，是 App 安全審查的固定項。

延伸方向

往 M03（兩條公鑰信任鏈的對照：code signing vs TLS）、專題一（NE 作為流量中介）、M14（網路 telemetry 可信度）延伸。

🟢/🟡 真機操作卡（macOS 26 適用 · 全唯讀/安全）

以下皆為唯讀觀察，在你自己的機器上安全執行（部分輸出格式可能隨版本變動，標「驗證於版本」）。需要 root 的會標 sudo。這些指令只讀狀態、不改任何安全設定。

# ── 專題一 Network Extension：盤點誰註冊了 NE/system extension ──
systemextensionsctl list                    # 已啟用的 system extension（含 content filter / proxy / NE）
# ⚠ systemextensionsctl developer 等開發模式會降低系統限制，屬授權研究環境，不在唯讀盤點範圍。

# ── 專題二 Rosetta 2：看自己機器的架構與相容層狀態 ──
arch                                         # 機器原生架構（Apple Silicon 上恆為 arm64）；是否在 Rosetta 下看下一行
sysctl -n sysctl.proc_translated 2>/dev/null # 1=在 Rosetta 下翻譯執行；0=原生 arm64；無輸出/錯誤=此 sysctl 不存在（Intel/舊系統）
sysctl -n hw.optional.arm64 2>/dev/null      # 1=Apple Silicon

# ── 專題三 虛擬化：判斷自己是否在 VM、看開機安全等級（唯讀）──
sysctl -n kern.hv_vmm_present 2>/dev/null    # 非 0/有值=偵測到 hypervisor（自己在 VM 裡）
csrutil status                               # SIP 狀態（接 M05；VM 裡可能與真機不同）

# ── 專題四 SEP/firmware：只查啟動安全狀態，不操作 SEP ──
csrutil status                               # System Integrity Protection 狀態
sudo bputil -d 2>/dev/null | head            # 顯示目前 LocalPolicy / 開機安全等級（唯讀 dump）
# ⚠ bputil 帶寫入旗標（如降安全等級）會永久改變開機安全並需 owner 認證——本卡只用 -d 唯讀顯示。

# ── 專題五 Keychain / 資料保護：看 FileVault 與自己 keychain 結構（不導出機密）──
fdesetup status                              # FileVault 是否開啟（接 errata：未開≠沒加密）
security list-keychains                       # 目前搜尋清單裡的 keychain 檔
security dump-keychain 2>/dev/null | head      # 自己 keychain 的「項目結構」（不含明文機密）

# ── 專題六 網路信任 Trust Store：盤點「非預期」的自訂/MDM root（高價值偵測點）──
security find-certificate -a /Library/Keychains/System.keychain | grep -c "labl"
                                              # System.keychain 放的是 admin/MDM 後加入的憑證（內建 ~155 張 Apple root 另在
                                              # /System/Library/Keychains/SystemRootCertificates.keychain）→ 這裡查非預期自訂 root
security dump-trust-settings -d 2>/dev/null    # admin domain 的 trust 覆寫（-s 才是系統內建、無旗標是 user）；自訂信任常留在 admin domain

⚠ 危險/授權邊界（DESIGN.md §10）：本卡所有指令皆唯讀。任何改變安全狀態的操作都不在範圍內，包括：bputil 的寫入旗標（降開機安全等級、需 owner 認證、會影響整機信任）、csrutil disable/authenticated-root disable（需 recoveryOS/1TR、會降低系統完整性甚至永久打破 SSV 封印）、systemextensionsctl developer on（降低 system extension 限制）、安裝任何自訂 root CA 或 NE。涉及 SEP/firmware/開機安全的可武器化細節全章只到類別與根因（🔴），不提供任何 offset / payload / 繞過或 PoC。動態分析可疑樣本一律在你自己的或受控授權的 VM內進行，且結論回真機驗證。

恭喜——你走完了整條主線到橫向專題。回頭看，這六個專題其實是同一套能力的不同投影：找出信任根在哪、信任鏈如何延伸、哪裡有中間人位置或降級面、出事時哪裡留訊號。把任一專題往「攻擊面類別 → 根因 → 防禦 → 偵測」四步展開，就是階梯 4「對一條鏈做結構與防禦縱深評估」的日常工作方式。深挖任一塊時，記得守住本章從頭到尾的那條線：理解防護模型以評估影響，不等於提供攻擊腳本。