reqable 抓包幕後：中間人、CA 證書與它為什麼能看懂 HTTPS

reqable 是一款什麼工具

reqable 是一款跨平台的 HTTP 開發與調試工具，最新版本為 3.0.30，安裝包約 30.80M。reqable下載 的核心能力很直白：攔截並解析裝置上所有 App 發出的網路請求，讓開發者與測試人員能夠即時看到請求頭、參數、響應內容，進而排查 bug、驗證介面行為。這不是 reqable 獨有的能力——市場上同類工具並不少——但 reqable 把這件事做得足夠輕量、足夠完整，從抓包、重發、比對到 API 集合管理，一條龍串起來，讓它在 Android 端佔了不小的市場。

它適合誰？簡單說，任何需要看 App 網路流量的人。不論是開發 App 想確認請求是否正確發出、測試人員複現介面偶發異常，還是安全研究人員觀察 App 的通訊行為，reqable 的基本版就能覆蓋大多數場景。但表面風平浪靜，底下其實藏著一整套設計取捨——它到底是怎麼「看」到 HTTPS 流量的？為什麼裝完 CA 證書才能抓？又為什麼有些 App 裝了證書還是抓不到？這些問題的答案，決定了你什麼時候該用 reqable、什麼時候該換別的方案。

安裝

reqable官網 提供的 Android APK 直接下載安裝即可，這部分沒有什麼特別的前置條件。首次啟動時它會引導你完成幾個關鍵設定：第一是選擇「獨立模式」或「協同模式」——獨立模式就是手機單機抓包，協同模式則是手機掃描電腦端 reqable 的二維碼，讓手機流量透過電腦端代理出去，兩台裝置共用同一個 CA 根證書，省掉手機上單獨安裝證書的麻煩。第二是 CA 根證書的安裝，這是抓 HTTPS 流量的硬性前置，跳過這一步就只能看到 HTTP 請求與一堆 CONNECT 隧道。證書安裝流程 reqable 會自己彈引導頁，跟著走就行，Android 新版本會提示「未知來源」放行，確認後裝到系統證書管理中心即可。第三是代理設定，reqable 會自動偵測目前的 Wi-Fi 網路並提示你把手機代理指向它的本地埠（預設 9000），也可以在系統設定裡手動設。舊版本升級時建議先解除安裝再裝新版，避免舊證書殘留導致握手失敗；如果之後抓不到流量，先檢查代理是否正確、證書是否還在系統證書裡，這兩樣是最常見的坑。

它到底怎麼「看」到 HTTPS：中間人原理拆解

好，進入正題。你打開 reqable，啟動抓包，突然就看到了 App 發往 api.somewhere.com 的每一個請求、每一段回應。這件事從技術上說，其實是在做一件很微妙的事：reqable 同時扮演了兩個角色——對 App 來說它是伺服器，對真伺服器來說它是客戶端。這個經典架構叫做 MITM，Man-in-the-Middle，中間人攻擊。

流程串起來是這樣的：App 以為自己連的是遠端伺服器，實際上它先連到了 reqable 的本地代理。當 App 發起 SSL 握手時，reqable 需要把自己偽裝成那個遠端伺服器。但問題來了——App 的 SSL 客戶端只信任系統證書管理中心裡受信任的 CA 根證書簽發的證書，reqable 偽裝用的那張證書，App 憑什麼信？

答案就是你安裝的那張 CA 根證書。reqable 在每台裝置啟動時都會為當前裝置自動生成一對獨特的 CA 根證書與私鑰，這張證書不在公共信任鏈裡，只在你自己的裝置上被信任。當你把它裝進系統證書管理中心後，App 就會接受由這張根證書簽發的任何伺服器證書。reqable 每攔截到一個新的域名，就用這張根證書臨時簽發一張該域名的伺服器證書冒充真伺服器，完成握手後 App 以為自己和真伺服器建立了安全連線，其實資料一路明文流經 reqable，被它完整記錄下來。

這個設計的聰明之處在於「每裝置獨立」。公共 MITM 工具常用一把通用私鑰給全世界所有使用者簽證書，這把鑰匙一旦洩漏，理論上任何人都能偽裝成你用過的任何伺服器發動攻擊。reqable 的自動生成機制把這個風險徹底消掉了——你手上的私鑰只存在你的裝置上，沒有人能拿去冒充你。這是一個不起眼但很重要的安全取捨。

那為什麼還是有 App 抓不到

原理講完了，但現實裡你很可能遇到過這種情況：同樣裝了證書，甲 App 的 HTTPS 流量看得清清楚楚，乙 App 卻全是握手失敗或直接報錯。這背後藏著另外幾個技術取捨，每個都能讓 reqable 的 MITM 策略失效。

最常見的一個是 SSL Pinning，有的 App 會把伺服器的證書指紋硬編碼進客戶端，握手時不但驗證證書鏈，還要比對證書本體是不是那一個特定的指紋——reqable 臨時簽的假證書當然不是那個指紋，直接被拒。更進階的還有 Certificate Transparency 檢查、HPKP 策略，本質都是繞開系統證書信任鏈，用 App 自己的邏輯判斷證書合法性。遇到這種情況，不是你證書裝錯了，是 App 根本不信任你。

還有一種情況是雙向驗證，伺服器要求客戶端上傳證書。reqable 能冒充伺服器，但冒充不了持有客戶端證書的那個客戶端，除非你把客戶端證書也導入給它，而這通常很麻煩，很多 App 的客戶端證書還是 App 自己的資產，根本拿不到。

最後，還有一個更底層的問題：Android 7+ 對未在系統 CA 裡的證書預設不信任，但對開發者自行安裝的 CA 證書（就是你裝的那張），App 可以選擇是否信任。這取決於 App 的 network_security_config.xml 裡有沒有把 user_certs 加進信任來源。有些 App 顯式排除了使用者安裝的證書——不是不信任 reqable，是不信任任何非系統預設的證書——這時你怎麼裝都沒用。

這套原理意味著什麼

講到這裡你大概能看出來，reqable 的 MITM + CA 根證書這一套是一個非常典型的取捨：它用一種「裝置級劫持但裝置級信任」的策略，換取了絕大多數場景下的零配置抓包能力。代價是三個——它拿不到 PINNED 的流量、雙向驗證搞不定、某些 App 的 network security config 會把它排除在外。但在這三個邊界之外，它跑得比任何同類工具都輕。

我自己用下來的感受是：reqable 真正厲害的地方不在 MITM 原理本身——那是所有抓包工具都用的老套路——而在它把原理層的複雜度盡量往下壓，對使用者只暴露「裝證書、設代理、啟動」三個動作。攔截到的請求在工作台裡按域名結構樹組織起來，一眼就能看出陌生網站的介面掛在哪些路徑下；選中任何請求可以直接重發、和另一條做差異比對、存進 API 集合複用；甚至可以寫腳本或設置中斷點，在請求發出去之前改掉參數或響應。這些功能單拿任何一個出來都是別的工具要另外裝外掛的，reqable 把它們從原理層到操作層串成了一條線。

當然也有不適合的場景。如果你的 App 啟了 SSL Pinning 又不想改它的邏輯，reqable 就幫不上忙，得換 Xposed/LSPosed 模組去 Hook 驗證函數，那是另一個層級的玩法。如果你需要抓的是 WebSocket 以外的自定義協議（比如 QUIC、純 UDP 通道），reqable 的 HTTP 視角也會顯得捉襟見肘，這時該換 Wireshark。但對於絕大多數移動 App 開發者每天面臨的問題——介面發出去了沒、參數對不對、響應裡哪個欄位變了、簽名為什麼失敗——reqable 的這一套 MITM + CA 根證書機制，已經是成本最低、成功率最高的解法。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。