mimic：把你自己的 App session 變成 Python client，這個工具在做什麼？

mimic GitHub repo

mimic 的重點不是幫你包一套現成的 API SDK，也不是要搞複雜的自動化逆向工程。它的切入點很窄、也很直接：先攔截你自己 App 的真實流量，再把那組 session 轉成可以直接呼叫的 Python client。

README 開頭寫得很直白：Intercept any app, then call it from Python like a library. 你不需要先手寫 hinge_client.py 的基礎架構，mimic 會先擷取你實際發出的 request，整理好 endpoint、body 範本與前後相依的 token 流程，再交給 AI 幫你生出第一版 client。

這件事吸引人的地方很明確。許多 App 沒有公開 API，或是 API 根本不是開給第三方用的。以往如果想把某個 App 的操作串進腳本，常見做法不是在 DevTools 複製 cURL，就是自己手抄 header、cookie、Authorization 再慢慢補齊 request body。mimic 試著把這段流程收成一條更順暢的開發路徑：

1. 先把你自己的流量抓下來
2. 抽出可重複使用的 auth / device header
3. 整理出 host 與 endpoint 清單
4. 讓 Claude 或 OpenCode 直接寫出一份 Python client

它到底在抓什麼

mimic 的核心假設很簡單：

很多 App 每次 request 隨附的，是一整包可重複使用的身份資料。

例如 bearer token、cookie、device id、session id 或 x-* 類型的自訂 header。

repo 裡的 mimic/extract.py 實作邏輯就是照這個原則處理。它會從最新一筆已認證的 request 中保留：

• authorization
• cookie
• user-agent
• accept-language
• content-type
• accept
• 所有 x- 開頭的 header

同時拋棄 HTTP 傳輸層的雜訊，例如 content-length、host、connection、accept-encoding、x-forwarded-for 等。換句話說，它並不是在做「API 破解」，而是幫你把你已經成功發送過的 request 身份整理好。

mimic 的工作流與輸入來源

很多人看到這類專案，第一反應會以為它只是另一個側錄抓包工具。但 mimic 實際上拆成「側錄整理」與「程式生成」兩段，而且支援三種輸入來源。

第一段：抓到可用流量與整理 Endpoint

最基本的側錄入口是：

mimic record

執行後它會啟動 mitmweb 並提示 iPhone 的設定步驟：

1. 將 Wi-Fi 代理指向 Mac
2. 透過 http://mitm.it 安裝 mitmproxy 憑證
3. 到 iPhone 的「憑證信任設定」開啟 full trust（完全信任）
4. 打開目標 App 正常操作

這段步驟不能省。README 和 CLI 說明都特別提醒：要是漏掉 full trust，封包就完全抓不到。

除了 iPhone 側錄外，mimic 的 capture source 現在支援三種模式：

1. mitmproxy / mitmweb：走 iPhone / iOS App 側錄的主要路線
2. Copy as cURL：有 Web 版時可直接貼上單筆 request
3. HAR file：吃 Chrome、Firefox、Charles 或 Proxyman 匯出的流量檔案

若拿 repo 內的 tests/fixtures/sample.har 測試 HAR 匯入功能：

python3 -m mimic.cli hosts --har tests/fixtures/sample.har
python3 -m mimic.cli learn api.example.com --har tests/fixtures/sample.har
python3 -m mimic.cli gen api.example.com --har tests/fixtures/sample.har --prompt-only

實測結果如下：

• hosts --har 會列出 request 次數最多的 host
• learn 會整理出去重後的 endpoint 清單
• gen --prompt-only 會將 endpoint 摘要成 prompt，不必強制當場呼叫 Claude

當時實跑 learn 的摘要結果為：

api.example.com: 2 endpoints

  GET   /v1/users   -> 200
  POST  /v1/messages   -> 201

這說明 mimic 不只靠 iPhone + mitmproxy，也可以直接吃代理工具或瀏覽器存下來的 HAR 檔。

在抓完流量後，可以用以下指令接續處理：

mimic hosts
mimic learn <host>
mimic gen <host>

這些指令會幫你看哪些 host 流量最多、列出 endpoint 清單，並決定是否生成 Python client。

第二段：將流量轉為可維護的 Python 程式

這才是 mimic 最具特色的部分。

mimic/codegen.py 的處理方式很直接：把抓到的 endpoint 摘要編成 prompt，再交給外部生成器。目前 repo 內建支援 claude 與 opencode（mimic doctor 亦會檢查本機是否有這兩個 CLI）。

mimic gen 要求生成器遵守幾項原則：

• 輸出單一 Python 檔案
• 繼承 mimic.App
• 不要硬編碼 token / header
• 將 endpoint 改寫為具備語意的方法名稱
• 把會變動的數值轉成方法參數
• 遇到多步驟 API 時，主動串聯前後相依的 token 或 id
• 過濾純 telemetry / analytics / config 類型的 endpoint

這個定位很務實：mimic 不是幫你自動搞定所有逆向，而是把你原本要手工打底的 SDK 粗胚，改用 AI 先生成第一版，再由你接手修改。

Session 物件不一定要靠 codegen

除了讓 AI 生成 client 之外，README 也提到可以手動建立 session。查閱 mimic/session.py，可以看到三個可用的入口：

Session.from_mitm(host)
Session.from_curl(text)
Session.from_har(path, host)

如果你不想讓 AI 寫 client，也可以單純把 mimic 當作「從真實流量抽取可重放 session」的 runtime 來用。

此外，它在 Session.request() 中處理了 retry 機制：

• 遇到 idempotent request
• 收到 401
• 且 mitmweb 中已經錄到新的 header 組

它會自動重新抓取 header 並再試一次。這種設計不複雜但很實用，因為許多 App 的 token 會定期異動，不需要每次都整包重新錄製。

真正的門檻不在 AI，而在流量能否重放

這個專案很坦白的一點，在於它沒有隱瞞關鍵的技術限制。README 和 docs 很明確地劃分出兩個主要障礙：

1. Certificate Pinning：會卡在流量擷取

若 App 啟用了 Certificate Pinning，即便安裝了 mitmproxy 憑證，App 依然會拒絕連線。這種狀況下不是 mimic 無法生成 client，而是一開始就攔不到流量。

repo 提供的解決管道是 mimic unpin。它背後不是自己重新寫一套 bypass 邏輯，而是包了一層流程去驅動 upstream 的 httptoolkit/frida-interception-and-unpinning：

• 將你的 mitmproxy CA 與代理位址帶入腳本
• 輔助生成 Frida 或 objection 的執行指令

由於 Pinning bypass 會隨 iOS 版本、TLS 堆疊與框架而變動，直接整合成熟工具是較合理的做法。但這也代表 mimic 並非一鍵解開所有 Pinning。

docs/pinning.md 也補上了邊界說明：

• React Native 通常可以走標準 hook 處理
• Flutter 因為常使用自行編譯的 BoringSSL 且不走系統代理，還需要另外靠 reFlutter

這些細節直接決定了你能不能跨過第一步。

2. DPoP：不是抓不到，而是重放本身會失效

另一個更硬的限制是 DPoP。docs/dpop.md 說明得很清楚：DPoP 不會阻止你攔截流量，但會讓你就算攔到了也無法直接重用。

因為每一個 request 都隨附了一個綁定特定 HTTP method、URL、時間戳記、nonce 與 access token 的密碼學簽章證明：

• Header 無法跨請求重用
• 單純抄走 token 沒有效果
• 必須擁有裝置端的簽署能力，無法單靠靜態 replay 達成

因此若目標 App 採用 sender-constrained token 或 DPoP 機制，mimic 的核心假設就會失效。它更適合處理「身份驗證可重放」的服務，而不是能通吃所有現代 App 安全機制的萬能框架。

適用場景與現況評估

綜合來看，mimic 最適合以下三種情境：

1. 目標 App 無公開 SDK，但你想自動化自己的個人操作：例如抓取自己帳號的推薦清單、批量發送固定請求，或將手機上的操作接到 Python 腳本與 agent 流程中。
2. 不想從零寫 SDK，需要先有一份可修改的 client 粗胚：利用 mimic gen 幫你命名方法、展開 body 範本並串好 API 依賴關係，之後再自行調優。
3. 目標服務有 Web 版或能取得 HAR 檔：利用 Session.from_curl(...) 或 Session.from_har(...) 直接匯入流量，跳過 iPhone 安裝憑證與設定代理的繁瑣步驟。

相對地，它不適合以下情況：

• 希望完全無技術背景、一鍵完成逆向工程
• 目標 App 有嚴格 Pinning 且極難 hook
• 目標服務使用了 DPoP / sender-constrained token
• 需要處理完整的對抗性逆向場景

專案現況

從 GitHub API 來看，該 repo 建立於 2026-07-13，截至查詢時約有 1,255 個 star，目前尚未發布正式 release 或 tag。repo 本體結構相當緊湊，主要包含 CLI、session runtime、extract、HAR / mitm source、codegen 以及 unpin 工具等幾個 Python 模組。

程式碼架構簡潔、沒有過度抽象，但它目前更像是一個主線清晰的早期工具。在生成 client 的穩定度、複雜多步流程的正確率，以及對各種新型 token 機制的支援上，仍需要使用者具備一定的網路請求與 session 重放知識才能順利使用。

結論

mimic 不是萬能的私有 API 提取器。更精確的定位是：把你自己能正常使用的真實 App / Web 流量整理成可重用 session，並進一步轉成 Python client 的小型工具鏈。

它最核心的價值，在於把「我已經能正常使用這個 App」順暢地轉銜為「我現在可以在 Python 中呼叫這個能力」，幫開發者省下大量手動拼湊 API 與撰寫 SDK 底層的時間。

參考資料

1. GitHub repo：<https://github.com/littledivy/mimic>
2. README：/tmp/mimic/README.md
3. Session runtime：/tmp/mimic/mimic/session.py
4. Codegen prompt / generator：/tmp/mimic/mimic/codegen.py
5. Header extraction：/tmp/mimic/mimic/extract.py
6. Pinning docs：/tmp/mimic/docs/pinning.md
7. DPoP docs：/tmp/mimic/docs/dpop.md