M10 · CTF
現代核可與盲區——SMAppService/BTM 看得到什麼、看不到什麼
延續 lvl1 的同一台機器。這次聚焦「現代核可路徑」與其偵測邊界：辨認哪些背景項目是透過 SMAppService（現代、會進 BTM、使用者可見）註冊的，哪些是繞過這條路徑、只落在 LaunchAgents 目錄或 cron 的觸發點。你要說明為什麼 SMJobBless/SMLoginItemSetEnabled 已被棄用、SMAppService 取代它後對「可盤點化/可見性」帶來什麼改變，並指出 BTM 作為登記簿的盲區——哪些持久化面 不一定出現在 BTM，該用什麼獨立來源交叉補洞。
此關卡對應的模擬器（persistence-panorama）尚未提供。
過關目標
- 讓 modern.smAppServiceItemsClassified 達到 true
- 讓 blindspot.outsideBtmItemFound 達到 true
- 用自己的話解釋：為什麼 SMJobBless 與 SMLoginItemSetEnabled 被棄用、SMAppService 取代後對「可盤點化與使用者可見性」帶來什麼改變（會進 BTM、顯示在系統設定面板、可撤銷）？BTM 作為登記簿的盲區是什麼——哪些持久化面不一定出現在 BTM？你會用哪些獨立來源（cron、profiles、以及 M14 的事件來源）交叉補洞，各能補到什麼？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
現代路徑：app 用 SMAppService 註冊 daemon/agent/login item → 進 BTM、顯示在系統設定登入項面板、使用者可撤銷。舊的 SMJobBless/SMLoginItemSetEnabled 已棄用，那種「悄悄裝 helper」的不透明度被收斂。
走錯方向時
別假設「不在 BTM 就沒持久化」。cron、某些 Configuration Profile payload、直接落在 LaunchAgents 目錄的 plist 不一定都反映在 BTM——這是登記簿的結構性盲區，不是 BTM 壞了。
想更深入
補洞靠把靜態盤點接上事件來源（M14）。「現在有什麼」用 sfltool dumpbtm / launchctl list / profiles；「什麼時候多出來」用 BTM 通知與 ES 的 BTM_LAUNCH_ITEM_ADD、對 Launch* 目錄的 WRITE 事件。兩者合起來才完整。