M03 · CTF
CDHash 雪崩與 entitlement 風險
在雪崩面板改 entitlements XML 任一字元，預測哪個 special slot 失配、CDHash 是否全變； 再讀 entitlement taxonomy，指出哪些能力屬於「放寬保護」的高風險面。
程式碼簽章實驗室
模型邊界：CDHash 用瀏覽器 crypto.subtle 真算 SHA-256（雪崩無法造假，與 codesign 的 CandidateCDHashFull 一致）。 但 CMS 簽章鏈僅標 ad-hoc／有 CMS，不偽造 Apple 私鑰簽章驗證（DESIGN.md §5.6 / §10）。上傳檔案不離開瀏覽器。
過關目標
- 讓 avalanche.changedSlot 達到 -5
- 讓 avalanche.cdhashChanged 達到 true
- 用自己的話解釋：為什麼改一個 entitlement byte 會讓整個 CDHash 翻掉（而不是只動到一小段）？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
entitlements(XML) 落在 special slot −5。改它 → slot −5 的 SHA-256 變 → CodeDirectory 變 → CDHash 全變。
走錯方向時
對 CMS 簽章的 binary，cdhash 一變即簽章失配、AMFI 拒載。ad-hoc 沒有 CMS，但雪崩原理相同。
想更深入
get-task-allow / disable-library-validation / allow-dyld-environment-variables 都會「放寬」保護，是研究時的紅旗。
相關指令
codesign