M12 · CTF
anti-debug 不是要繞——是辨類別、找根因、變偵測訊號
延續 lvl1 的 binary，這次它帶了反偵錯特徵（如 ptrace(PT_DENY_ATTACH)、自檢 P_TRACED、 掃描分析工具指紋）。你的任務不是繞過它，而是用靜態分析把這些 anti-debug 行為「分類」、 說出每一類的「根因（為何讓動態分析變難）」，並指出它在 telemetry（接 M14 ES）上會留下 什麼可偵測訊號。明確不示範任何繞過步驟。
此關卡對應的模擬器（reverse-bench）尚未提供。
過關目標
- 讓 analysis.antiDebug.classified 達到 true
- 讓 analysis.bypassAttempted 達到 false
- 用自己的話解釋：把這個 binary 的反偵錯行為分成哪幾類、各自根因（為何讓動態分析變難）是什麼？為什麼本章只停在「辨類別＋根因＋偵測訊號」而不教繞過？對 DFIR 來說，「偵測到 anti-debug」為何往往比「成功繞過」更有價值？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
靜態就能看出它呼叫了 ptrace / sysctl 自檢 / 掃工具特徵——用 nm 或 otool -oV/反組譯找這些呼叫，不必執行它。把每個落到「主動拒附加 / 自問是否被偵錯 / 偵測工具指紋 / 計時」四類之一。
走錯方向時
你在找「怎麼讓 PT_DENY_ATTACH 失效」？那是 🔴 僅概念、本章不做。改問：這個行為的根因是什麼、對 DFIR 它本身就是訊號嗎。分析可改走靜態或非附加式觀測，繞過不是目標。
想更深入
正常 app 通常不需要 anti-debug。所以「偵測到 anti-debug」對 M14 比「繞過它」更有價值——把它當成「該樣本在反分析」的高價值偵測訊號列入規則。
相關指令
otoolnmdyld_info