M06 · CTF
換 binary 為什麼要重新授權
一個 client 已對某 service 有 auth_value=2 (allowed) 的紀錄；把它換成不同身分重簽後再存取。 說明 tccd 比對 csreq（designated requirement）的結果，以及為何 auth_value=3 (limited) 不能套用到這個相機/全磁碟類服務。
TCC 判定實驗室
情境
雙層 db：~/Library/.../TCC.db（user）先於 /Library/.../TCC.db（system）。此服務無 limited。
tccd 判定提示授權
- attribution用 audit token 歸屬到責任 client：com.example.app（非看 PID）。
- lookup雙層 tcc.db 都查無 (service, client) 紀錄 → 視為 unknown。
- prompt無紀錄 → 由系統跳出授權提示（若無 UI 環境則視為拒絕）。
查無紀錄 → 提示使用者授權（首次請求）。
試試：把「目前簽章符合 DR」關掉（模擬冒名/重簽）→ 既有 allowed 紀錄作廢、重新提示。把 audit token 關掉 → 連歸屬都失敗。
模型邊界：tccd 判定為**教學決策模型**（audit token 歸屬 → 雙層查表 → csreq DR → auth_value），非逐欄位實作。TCC.db 受 SIP/FDA 保護，本實驗室用合成資料。驗證於 macOS 26.3.1。
過關目標
- 讓 decision.csreqMatch.afterResign 達到 false
- 讓 decision.requiresReauthorization 達到 true
- 讓 service.kTCCServiceCamera.supportsLimited 達到 false
- 用自己的話解釋：為什麼換 binary（或改身分重簽）就要重新授權？以及為何 limited(3) 不適用於相機/全磁碟這類服務？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
授權釘在 csreq（DR）上，綁的是「身分」不是「路徑」。重簽改身分→當前簽章與釘選的 csreq 失配。
走錯方向時
csreq 失配 = 視同沒有有效授權，要重新走同意流程。舊的 allowed 不會沿用到新身分。
想更深入
auth_value 3 (limited) 主要用於 Photos 的「選取部分照片」；相機 / Full Disk Access 這類服務沒有 limited 態，別套四態。
相關指令
codesigncsreq