モバイルアプリの隠されたAPI：mitmproxyとプロキシ

```html

サイトはCloudflareによって閉鎖され、Turnstileは2回目のリクエストごとに表示され、レイアウトは2週間ごとに変更されます。それにもかかわらず、同じサービスにはモバイルアプリがあり、バックエンドに直接アクセスして準備されたJSONを取得します - チャレンジなし、マークアップなし、安定したフィールドスキーマで。これが「隠れたAPI」です：文書化されていないが完全に機能するインターフェースで、公式クライアントが使用しています。

mitmproxyを使用してそれを見つける手順を説明し、証明書ピンニングに対処する方法と、プロキシなしで収集をスケールアップする段階でなぜすべてが崩れるのかを説明します。

アプリケーションのトラフィックにアクセスする理由

ウェブバージョンのスクレイピングとプライベートAPIの呼び出しは、コストが異なるタスクです。比較してみましょう：

ウェブ。 ヘッドレスブラウザ、アンチボットの回避、HTMLのパース、セレクタの定期的な修正が必要です。1回のリクエスト = メガバイトのトラフィックと数秒のCPU時間。
プライベートAPI。 ヘッダーのペアを持つ通常のHTTPリクエスト、応答は型付きフィールドを持つコンパクトなJSONです。インターフェースが表示するよりも多くのデータを返すことが多く、内部識別子、フラグ、サービスフィールドが含まれます。

モバイルバックエンドは歴史的にウェブよりも弱く保護されています。理由は単純です：アンチボットプラットフォームはブラウザトラフィック（JSチャレンジ、キャンバス、行動信号）に特化しており、モバイルクライアントはそれを通過できませんでした。その代わりに、開発者はアプリケーションの静的キーとTLSピンニングに依存しています - 両方ともローカルデバイスで解除されます。

必要なもの

mitmproxy - オープンソースのHTTPSプロキシインターセプター（GitHubで44,000以上のスター、最新のブランチ12.2.2は2026年4月にリリース、Python 3.12+が必要）。1つのコマンドでインストールできます：pip install mitmproxy。HTTP/1、HTTP/2、HTTP/3、WebSocket、そして生のTCPを理解し、TLS 1.2および1.3で動作します。
Androidデバイスまたはroot付きエミュレーター。 実践的には、Android 7〜11が最も便利です：新しいバージョンは証明書の取り扱いを厳しくしました。
ADB - デバイスとの通信に必要で、Frida（pip install frida-tools） - アプリが証明書をピン留めしている場合に必要です。

mitmproxyには1つのエンジンの上に3つのインターフェースがあります：mitmproxy（ターミナルTUI）、mitmweb（初心者向けのウェブインターフェース）、およびmitmdump（ヘッドレス、スクリプトと自動化用）。

ステップ1. インターセプターを起動する

ウェブインターフェースを外部接続をリッスンするように起動します。localhostだけではありません：

mitmweb --web-host 0.0.0.0

デフォルトでは、プロキシはポート8080で起動します。mitmproxyを初めて起動すると、独自の認証局が作成され、キーが~/.mitmproxyディレクトリに保存されます。そこには4つのファイルが作成されます：mitmproxy-ca.pem（プライベートキーを含む証明書）、mitmproxy-ca-cert.pem（証明書のみ）、mitmproxy-ca-cert.p12（Windows用）、およびmitmproxy-ca-cert.cer（Android用のフォーマット）。

ステップ2. デバイスをプロキシ経由で接続する

電話のWi-Fi設定で手動プロキシを選択します：ローカルネットワーク内のコンピュータのIPとポート8080。次に、デバイスのブラウザで特別なドメインmitm.itを開きます - これはmitmproxyに組み込まれたページで、プラットフォームを自動的に検出し、必要な形式の証明書を指示とともに提供します。

iOSでは、手順は3つの部分から構成されており、後半をすべて忘れてしまいます：Safariを介してプロファイルをダウンロードし、「設定 → 一般 → VPNとデバイス管理」にインストールし、その後別途完全な信頼を有効にする必要があります。「設定 → 一般 → このデバイスについて → 証明書の信頼」を選択します。最後のステップがないと、証明書はインストールされますが、機能しません。

Wi-Fi設定をいじりたくない場合、mitmproxyにはVPNサーバーモードがあります：mitmweb --mode wireguard。デバイスはWireGuardの標準クライアントを介して接続され、トラフィックは透明にキャプチャされ、システムでプロキシを手動で設定することなく行われます。

ステップ3. 主要な壁 - 証明書への信頼

ここでほとんどの試みが失敗します。問題は2つあり、それぞれ異なります。

ユーザーCAは2016年から評価されていない

Android 7 Nougat（API 24）以降、アプリケーションはデフォルトでシステム証明書ストアにのみ信頼を置きます。ユーザーCAは、開発者がNetwork Security Configで明示的に許可しない限り無視されます - trust anchors内の<certificates src="user" />ブロックを介して。これは攻撃面を削減するためにGoogleが意図的に行った決定であり、電話の設定で回避することはできません。ちなみに、Chromeもユーザー証明書を信頼しません。Android 11では制限がさらに厳しくなりました。

実践的な結論：root付きのデバイスでは、mitmproxyの証明書をシステムストレージに配置する必要があります、ユーザー用ではありません。これが要求事項にrootが含まれている理由です。

証明書ピンニング

2つ目の壁はピンニングです：アプリケーションは期待されるサーバー証明書のフィンガープリンを内部に持ち、他の誰とも通信することを拒否します。システムCAでも救えません。2022年のACMの研究では、ピンニングは「高リスク」セクター（銀行、タクシー、暗号）で広く普及していることが示されましたが、しばしば不完全に実装されているため、回避可能です。

このタスクにはいくつかのツールがあり、それぞれ異なる方法で解決します：

Frida - ランタイムでの動作修正：証明書チェック関数をフックし、成功を返すようにします。この場合、アプリケーションは変更されず、最も柔軟なオプションです。典型的な起動：frida -U -f com.target.app -l ssl_bypass.js --no-pause。
apk-mitm - APKファイルからピンニングを静的に自動的に削除します。
android-unpinner - Fridaとピンニング解除スクリプトを埋め込んでAPKを再構築します。
objection - Fridaの上にあるツールキットで、iOSとAndroidの両方に対応しています。
ssl-kill-switch2 - iOSおよびmacOSアプリケーションのピンニングを無効にします。

特定のドメインが完全にピンニングされていて作業を妨げる場合は、ignore_hostsオプションを使用してキャプチャから除外できます（正規表現を受け入れます） - トラフィックはmitmproxyを通過せずに流れます。

ステップ4. 必要なリクエストを見つける

次はルーチンです。アプリケーションを開き、意味のあるアクションを1つだけ実行します（商品カードを開く、フィードをスクロールする、フィルターを適用する）そして、どのリクエストが発生したかを確認します。ターミナルインターフェースでは、これを迅速に行えます：Zはストリームリストをクリアし、Enterは選択したリクエストを開き、Eはそれをエクスポートします - curlの準備されたコマンドも含まれます。

キャプチャされたリクエストで探すべきもの：

エンドポイントとパラメータ。 アプリケーションのインターフェースが使用するよりも多くのものがあることがよくあります。
クライアントキー。 定番のスタティックIDで、アプリケーションに埋め込まれています。有名なMyAnimeListの公開APIの解析では、このキーはx-mal-client-idというヘッダーで、値は6591a087c62b3e94d769cd8e35ffe909で、api.myanimelist.net/v3/anime/seasonおよび/v3/animeのエンドポイントにアクセスするためのものでした。
User-Agent。 モバイルクライアントは特有で、「パス」の一部として機能します - 同じ例ではMAL (ios, 139)です。
トークンとその有効期限。 すぐに、キーが静的か更新されるかを確認します：これによって、収集者の今後のアーキテクチャが決まります。

エクスポートされたcurlをコードに変換するのはcurlconverterを使用すると便利です - requestsの準備されたリクエストを取得し、その後は通常のHTTPクライアントで作業します。

ステップ5. スケーリング - そしてすべてが壊れる場所

ここで、試したことのあるすべての人が知っている失望が訪れます：自宅のIPからプライベートAPIは最初の30分間は完璧に応答しますが、その後429や403を返し始めます。モバイルバックエンドはクライアントの偽造に対して弱く保護されていますが、IPによる制限は厳しいです - サーバーはアドレスの背後に1台の電話がいると想定していますが、20のスレッドで動作するパーサーではありません。

ここからの実践的な結論。

リクエストのプロファイルを信頼できるものに保つ。 実際のアプリケーションは1秒間に50のリクエストを行わず、厳密にスケジュール通りに動作しません。呼び出しの順序も重要です：本物のクライアントはまずセッションの設定を要求し、その後コンテンツを取得します。
負荷をアドレスに分散させる。 1つのIP = 1つの「電話」。アドレスのローテーション、ジッターを伴う遅延、指数バックオフの戦略については、プロキシを介したAPIレート制限を回避する方法で詳しく説明しています。
地理を考慮する。 多くのモバイルAPIは、アドレスの国に応じて異なるコンテンツや異なる価格を返します - これは同時に制限であり、機会でもあります。

デバッグはmitmproxyを離れずに行うのが便利です：上位プロキシに接続できます。コマンドmitmdump --mode upstream:http://example.com:8081は、すべてのトラフィックをアップストリームに転送し、認証は--upstream-authオプションでusername:password形式で指定します。これにより、以前と同じリクエストが見えますが、外部アドレスから送信されます - APIが特定の国またはIPタイプにどのように反応するかをすぐに確認できます。

モバイルAPI用のプロキシの種類を選ぶ

ここでの選択は抽象的ではなく、あなたが誰であるかに基づいています。

モバイルプロキシ - 優先オプションです。アプリケーショントラフィックを模倣し、携帯電話会社のアドレスはバックエンドにとって完全に自然に見えます：CGNATのおかげで、実際には数百の加入者が1つのアドレスの背後にいるため、これらのIPに対する制限は緩やかです。モバイルプロキシ4G/LTEが適しています。
レジデンシャルプロキシ - 大量のトラフィックがある場合に機能する中間オプションで、オペレーターへの依存が重要でない場合：家庭用IPプロバイダーは、適正価格で広範な地理的カバレッジを提供します。これはレジデンシャルプロキシです。
データセンター - 重大なアドレスの評判チェックがないエンドポイントのみで使用します。彼らのASNは瞬時に識別され、モバイルバックエンドでは奇妙に見えます：データセンターには電話はありません。

遅れて知る落とし穴

HTTP/3。 mitmproxyにはQUICのサポートがあり、デフォルトで有効ですが、実際のモバイルトラフィックでは制限されています：ALPNの操作を通じてHTTP/2に強制的に戻す必要があることがよくあります。QUICはリバースおよびWireGuardモードで最もよく機能します。
プライベートAPIは予告なしに変更されます。 それには後方互換性の義務はありません - これは内部インターフェースです。User-Agentのアプリケーションバージョンはいつかサービスを停止し、収集者は静かに空の応答を受け取るようになります。応答コードだけでなく、JSONの構造も監視してください。
「キーを見つけた」と「権利を得た」を混同しないでください。 スタティッククライアントキーは無制限の収集の許可ではありません。

法的側面について

自分のデバイスでのトラフィックのキャプチャは合法で日常的なデバッグの実践であり、モバイル開発者やセキュリティ専門家が使用しています。境界はさらに先にあります：サービスの利用規約を遵守し、法的根拠なしに個人データを収集せず（EUではGDPRによって直接規制されています）、他者の認証を必要とするエンドポイントに触れず、サービスの運営を妨げないレベルで負荷を維持してください。実践的な指針として、データがアカウントにログインせずにアプリケーション内のすべてのユーザーに表示される場合 - あなたは比較的安全なゾーンにいます。アクセスするために他者のアカウントが必要な場合 - あなたはすでにその境界を越えています。

簡潔に

このスキームは機能し、アンチボットとの数週間の格闘を節約します：mitmproxyを立ち上げ、root付きデバイスのシステムストレージに証明書を配置し、必要に応じてFridaを介してピンニングを解除し、意味のあるリクエストを1つキャッチし、それをcurlにエクスポートしてPythonに書き換えます。次に、「保護を回避する」タスクは「負荷を適切に分配する」タスクに変わり、アドレスのローテーション、合理的な間隔、および適切なプロキシタイプで解決されます。最も簡単に始めるのはモバイルプロキシです：それらはバックエンドが期待するトラフィックに最も近いです。