REA Android 分析：這個 APK 把請求發到了哪裡？

01. 選擇一個介面或操作

「列出所有 API」通常範圍過大。先從可見操作開始，例如載入公開目錄。紀錄 APK 版本和介面名稱。目標是構建該請求的程式碼，而不是套件中所有看起來像 URL 的字串。

這是靜態分析，不會啟動 APK。內嵌字串可能包含廢棄主機、測試環境，或需要與執行時設定拼接的路徑。

使用 REA 分析 /absolute/path/app.apk。定位載入公開目錄的程式碼。從可能的介面類或 Repository 類別追蹤到網路方法。報告候選主機、路徑、HTTP 方法和引數，並提供類與方法證據。區分靜態宣告和已確認的執行時流量。

02. 連線 Android 分析後端

使用包含編譯器模組的完整 JDK。將 REA 指向已經安裝的分析後端 JAR。如果 REA 透過 AI 代理執行，為該伺服器設定相同環境並重新啟動；在另一個終端機設定變數，不會更新現有程序。

export REA_JADX_MCP_JAR="/absolute/path/jadx-headless-mcp-0.7.1-all.jar"
npx -y rea-agents@6.4.0 inspect-android-package "/absolute/path/app.apk" --json
npx -y rea-agents@6.4.0 search-android-classes "/absolute/path/app.apk" Catalog --json

03. 先檢視類別，再選擇方法

類別搜尋匹配類別名稱，並不搜尋方法體內的任意字串。試試功能名和常見網路名稱，例如 Api、Service 或 Repository。混淆後的套件可能需要其他入口，例如從 manifest 中的 activity 追蹤依賴。

將下方類別名稱替換成搜尋回傳的完整名稱。選擇方法前先檢視成員。同名方法存在多載時，使用類別成員清單回傳的多載索引。

npx -y rea-agents@6.4.0 inspect-android-class "/absolute/path/app.apk" com.example.CatalogRepository --json
npx -y rea-agents@6.4.0 inspect-android-method "/absolute/path/app.apk" com.example.CatalogRepository loadCatalog --json

04. 分別追蹤請求建構和呼叫方

分別閱讀請求的構建位置和方法呼叫位置。固定的基礎 URL 只是其中一環：構建器可能替換它，攔截器可能新增引數，原生庫也可能隱藏部分流程。紀錄每個邊界。

入向引用顯示分析引擎已知的靜態關係。反射和動態載入程式碼可能不在其中。如果結果回傳 smali 而非 Java，應把它視為同一方法的另一種表示，並明確分析它。

npx -y rea-agents@6.4.0 trace-android-references "/absolute/path/app.apk" com.example.CatalogRepository --method-name loadCatalog --json

• 哪個呼叫方將這個方法與選定功能關聯？
• 基礎 URL 是字面值、資源、設定值，還是執行時結果？
• 哪些欄位確實加入了請求？
• 靜態追蹤在哪裡停止？

05. 把發現寫成小型規格說明

編寫表格，包含候選方法、URL 建構、引數名和支持結論的方法引用。只能在執行時確定的值保留為未知。用本機模擬伺服器，按這份規格製作你自己的用戶端原型。

靜態端點列表不等於成功擷取請求。要得出這樣的結論，需要在合適的測試環境中，對匹配版本的應用程式另行執行並紀錄。本教學提供分析流程，不聲稱已測試某個 APK 或擷取 API 回應。