M14 · CTF
telemetry 盲區——mute inversion 與 event-flooding 下的漏報
延續 lvl1 那條規則。這次拉動 mute-inversion 與 event-flooding 兩支滑桿，觀察惡意 exec 如何從事件流裡「消失」——一個是事件壓根沒被產生（mute），一個是事件被洪泛擠掉（drop）。 你要分辨這兩種盲區的成因不同，並說明為什麼這不是「規則沒寫好」而是 ES 的結構性邊界， 以及該如何用獨立來源（OpenBSM、FSEvents、Time Machine 快照）交叉補洞。
ES 事件流 + 偵測規則
| # | type | kind | proc | path | plat |
|---|---|---|---|---|---|
| 1 | exec | AUTH | Terminal | /bin/zsh | ✓ |
| 2 | exec | AUTH | zsh | /tmp/.x/helper | ✗ |
| 3 | open | NOTIFY | helper | ~/Library/LaunchAgents/com.x.plist | ✗ |
| 4 | btm_add | NOTIFY | helper | com.x.agent | ✗ |
| 5 | mmap | NOTIFY | Safari | /usr/lib/dyld | ✓ |
| 6 | exec | AUTH | launchd | /tmp/.x/helper | ✗ |
| 7 | open | NOTIFY | Spotlight | ~/Documents/a.pdf | ✓ |
命中 2 筆
AUTH（黃）事件可即時放行/拒絕（同步、有背壓）；NOTIFY 只是事後通知。predicate 太鬆 → 雜訊（FP），太緊 → 漏報（FN）。mute / event-flooding 是真實盲區：被 mute 的程序事件根本不送達 client。純教學合成流。
過關目標
- 讓 blindspot.muteInversion.maliciousEventEmitted 達到 false
- 讓 blindspot.flooding.maliciousEventDropped 達到 true
- 用自己的話解釋：mute 造成的漏報和 event-flooding 造成的漏報，成因有什麼本質不同（事件未產生 vs 事件被丟）？為什麼這是 ES 的結構性盲區而非規則 bug？你會用哪些「獨立於 ES」的來源來交叉補洞，各能補到什麼、補不到什麼？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
mute 讓 kernel 不再為某 process/path 送事件——事件「沒產生」，再好的 predicate 也命不中。flooding 是事件「產生了但被丟」。兩者都讓你漏報，但補洞方式不同。
走錯方向時
別在 predicate 上鑽——盲區不在規則層。mute inversion（只看白名單）把白名單外開成全黑洞；flooding 把 AUTH client 拖到 deadline，逾時多半 fail-open 放行。
想更深入
補洞靠獨立軌：OpenBSM trail 攻擊者常忘了清，FSEvents 記得目錄曾被寫，Time Machine 舊快照可能還留著被刪的檔。ES 不是唯一真相來源。
相關指令
esloggerpraudittmutil