entry-point-analyzer

entry-point-analyzer 技能概覽

entry-point-analyzer 技能可在你開始更深入的安全審查前，先幫你梳理智慧合約程式碼庫中會改變狀態的攻擊面。它是為這類稽核情境設計的：第一個問題不是「有沒有 bug？」，而是「哪些可由外部觸達的函式會改變狀態，又是誰能呼叫它們？」

entry-point-analyzer 是做什麼的

當你需要 Solidity、Vyper、Solana、Move、TON 或 CosmWasm 專案的實用入口點清單時，就適合使用 entry-point-analyzer 技能。它特別適合 entry-point-analyzer for Security Audit 這類工作流程：存取控制審查、特權操作發掘，以及稽核範圍界定。

entry-point-analyzer 會過濾掉什麼

這個技能刻意排除唯讀路徑、純工具函式，以及僅限內部使用的函式。當你要的是偏安全導向的呼叫面，而不是完整的程式碼導覽時，它會比一般提示更有決策價值。

誰最適合使用 entry-point-analyzer

最適合的對象是安全稽核人員、協議工程師，以及需要快速找出公開或受權限保護的狀態變更路徑的代理。如果你的目標是漏洞研究、gas 分析，或一般程式碼品質檢視，這就不是對的工具。

如何使用 entry-point-analyzer 技能

安裝並找到這個技能

請透過 trailofbits/skills plugin repository 的 entry-point-analyzer install 流程來使用：

npx skills add trailofbits/skills --skill entry-point-analyzer

接著先讀技能的入口檔。以這個 repo 來說，最有用的路徑是 plugins/entry-point-analyzer/skills/entry-point-analyzer/SKILL.md。

建立強而有力的輸入提示

entry-point-analyzer usage 的模式，在你一開始就把 repository、語言與審查目標講清楚時，效果最好。好的提示範例如下：

「分析這個 Solidity 協議，列出所有會改變狀態的 external/public entry point，並依 access control 與 deployment-time 行為分組。排除 view 和 pure 函式。標出僅 admin 可呼叫、受角色限制、fallback，以及 constructor 路徑。」

如果程式碼庫混用多種語言，請明確說明。如果你只想看某個 module、contract 或 package，也要直接點名。

先讀支援檔案

要拿到真正有品質的輸出，不要只看 SKILL.md。在這個技能裡，支援參考文件通常會補充各語言的入口點規則：

• references/solidity.md
• references/vyper.md
• references/solana.md
• references/move-aptos.md
• references/move-sui.md
• references/ton.md
• references/cosmwasm.md

這些檔案能幫你確認邊界情況，例如 fallback handlers、僅限交易的函式、message receivers，以及 access-control 模式。

能產出實用結果的工作流程

先要求做一份涵蓋整個 codebase 的 entry-point 地圖，接著再針對高風險入口做縮小範圍的第二輪分析。舉例來說，在完成第一份清單後，再要求只看 admin-gated 函式、只看 upgrade 或 migration 路徑，或只看會碰到 ownership 與 authorization 狀態的函式。這種順序會讓這個技能比一次性摘要更有用。

entry-point-analyzer 技能 FAQ

entry-point-analyzer 只適用於智慧合約嗎？

是。這個技能是為智慧合約 codebase 與各鏈特有的 entry-point 慣例而設計的，不是給一般後端、前端或通用應用程式碼使用的。

這和一般提示有什麼不同？

一般提示常常會漏掉特定語言的 entry-point 規則，尤其是在 Solidity、Move、TON 與 CosmWasm 之間。entry-point-analyzer 技能把目標縮得更窄：只看會改變狀態的外部介面，並透過排除規則減少雜訊。

entry-point-analyzer 適合初學者嗎？

如果你的目標是理解合約的外部狀態變更面，那它是適合的。若你期待它自己直接找出漏洞，那就沒那麼適合，因為這個技能的用途是範圍界定與分類，而不是直接做 exploit detection。

什麼情況下不該用它？

當你需要唯讀分析、一般程式碼審查，或 exploit 開發時，不要使用 entry-point-analyzer。如果 codebase 不是智慧合約系統，或你需要包含內部輔助函式在內的每一個函式，它也不適合。

如何改進 entry-point-analyzer 技能

給分析器正確的邊界

最好的 entry-point-analyzer usage，一開始就要有明確的範圍：一個 repo、一個協議，或一個部署套件。如果把無關的套件也一起丟進去，結果只會更吵、更難信任。

明確指出你關心的 access-control 問題

使用者通常只想知道三件事之一：「任何人都能呼叫什麼？」「哪些是 admin-only？」「部署或 migration 過程中哪些地方會改變狀態？」請直接提出來。這個技能在依可呼叫性與權限分組時最強，而不只是按檔案列出而已。

需要時提供語言層級的背景

對於多語言 repo，請告訴技能要優先看哪種 framework 慣例。例如，Solana 可提 Anchor，CosmWasm 可提 entry_point 模式，TON 可提 receive handlers。這樣能減少對 framework 特定入口的漏判。

從清單走到審查

先要求完整的 entry-point 地圖，再要求風險最高的前 5 個函式、它們依賴的授權檢查，以及任何看起來異常或保護不足的狀態變更路徑。這種兩步驟做法通常比一次要求完整安全稽核更有效，因為這個技能的輸出在從乾淨的 surface map 出發時最容易驗證。