問題彙總¶

請下載此指令碼 user-home/modules/script/enhanced_automation_wechat.yaml 並將其放置到裝置的 ~/modules/script 目錄下即可。

老舊版本可能在部分環境下會產生此問題，請換用目前的最新版本。

這種情況可能出現於 Android 16，但不排除低版本也存在該情況。首先，請務必確保您使用的是最新版本的服務端。如果仍然出現此問題，請檢查您使用的 Root 軟體是否為 KernelSU。執行崩潰是因為舊版本 ksu 損壞了系統的 SELinux policy image，請嘗試使用最新版 ksu。如果仍然崩潰，請改用 Magisk 或者降級 shell 權限執行。

這可能是因為某些 APP 使用了 app-zygote 來檢測 Frida。在 10.0 以下版本，您可嘗試在 properties.local 中配置 enhanced-stealth-mode=true 來規避該問題（副作用是無法使用 Frida 的 spawn 相關功能）。10.0 及以上版本已移除此配置項，請升級至最新版本並聯絡我們回饋具體情況。

無需提問抓包功能是否完善，FIRERPA 已安排好一切，他已經給您做完了抓包所需的任何流程。如果您使用的其他抓包軟體抓不到包，FIRERPA 一定能抓到；如果 FIRERPA 抓不到，那麼沒有任何同邏輯的軟體能抓到。無需擔心憑證不信任問題，FIRERPA 會在抓包時自動為應用安裝系統級根憑證，無需您手動操作。對於 QUIC 降級，startmitm 會自動禁用 UDP 協定，正常情況下 APP 無法使用 UDP 時會自動降級而不使用 QUIC，這一切都無需您手動干預。

可能原因：一是 APP 本身存在憑證校驗或憑證固定機制；二是沒有正確進行前後期處理。如何確定是否是 APP 存在憑證校驗機制：開啟全域抓包，然後開啟瀏覽器等其他 APP 檢視是否正常抓取。多試幾個聯網 APP 確認：如果有的應用可以抓包有的不行，那大機率無法抓包的應用了私有協定或憑證校驗機制，這通常會在 startmitm 的日誌中輸出 Client TLS handshake failed 等資訊，但這並非重點。若確認 APP 存在憑證校驗，則應透過逆向等其他手段動態繞過校驗機制才能繼續抓包。關於沒有正確進行前後期處理：通常情況下，部分使用者可能未關閉系統防火牆，導致代理埠無法被手機訪問而沒有任何反應。另一種情況是，APP 在您啟動抓包之前已經建立了必要的網路連線，導致抓包啟動後的流量仍透過這些已有連線傳送，而未經過代理。您需要在啟動 startmitm 後，手動完全結束 APP（強制停止），再重新開啟 APP 即可。

首先，請檢查防火牆是否已關閉。其次，檢視在手機瀏覽器訪問網站時，一鍵抓包指令碼是否輸出日誌。如果出現類似 No route to host 的錯誤，並能與瀏覽器訪問動作對應（即每次訪問指令碼都輸出該錯誤），那麼可能的原因是：手機本身支援 IPv6 網路訪問，且預設 DNS 解析也使用 IPv6，但執行指令碼的電腦未開啟或不支援 IPv6，導致出現 No route to host。如果您的寬頻支援 IPv6，請在電腦網路設定中手動開啟；或者在指令碼命令列中嘗試指定 --proxy-dns 114.114.114.114 並測試是否恢復正常。若這兩種方法均無效，請聯絡支援。

此問題同上。您可以先測試其他一些 APP 是否能正常抓包，以排除服務問題。如果可以正常代理，那麼這種情況可能是因為裝置支援 IPv6，而您執行 startmitm 的機器不具備有效的 IPv6 位址。如果您的網路存在可用的公網 IPv6，請為您的電腦分配一個；或者在路由器端徹底禁用 IPv6。

如果您可以正常抓取相關應用的資料包，無需關心此輸出，這可能是系統內其他 APP 或 APP 的第三方 SDK 的憑證校驗機制產生的日誌。

請確認該問題是在啟動 FIRERPA 之後才出現的。如已確認，請升級至最新版本後仍異常，請聯絡我們。（enhanced-stealth-mode 配置自 10.0 開始已移除，不再適用。）

自啟動 APK 受限於不同系統的設定，可能不會隨系統自動啟動。如果開機後無法訪問，請透過 APP 中的 手動啟動 按鈕點選手動啟動，等待一分鐘後重試訪問。如仍無法啟動，請嘗試手動安裝或模組安裝方式。

請確保您已完成 環境準備 章節中的相關設定內容，隨後嘗試多次重啟裝置（約 3 次）。