プロキシを介したSSLピンニングバイパス：モバイルアプリのトラフィックをキャプチャし、テストを壊さずに行う方法

```html

プロキシを設定し、デバイスを接続しても、アプリケーションがトラフィックを表示しないか、エラーでクラッシュすることがあります。おそらく、問題はSSLピンニングにあります。これは、開発者が意図的にアプリケーションに組み込む保護機能で、HTTPSリクエストの傍受を防ぎます。これは、競合アプリケーションの挙動を分析したり、広告統合をテストしたり、マーケットプレイスのAPIを調査したりするすべての人にとって頭痛の種です。

このガイドでは、SSLピンニングとは何か、なぜプロキシとの作業を妨げるのか、そしてそれをどのように回避するかを、余計な理論なしでステップバイステップで説明します。

SSLピンニングとは何か、アプリケーションに組み込む理由

SSLピンニング（または証明書ピンニング）は、モバイルアプリケーションが特定のSSL証明書またはサーバーの公開鍵を事前に「埋め込む」セキュリティメカニズムです。接続のたびに、アプリケーションはサーバーの証明書が内部に埋め込まれているものと一致するかどうかを確認します。一致しない場合、接続は切断されます。

通常のHTTPSスキームでは、ブラウザやアプリケーションは信頼された認証局（CA）によって署名された任意の証明書を信頼します。これを利用して、Charles Proxyやmitmproxyのようなプロキシツールは、自分の証明書を挿入し、トラフィックを復号化してさらに転送します。ユーザーはすべてのデータ交換をオープンな形で見ることができます。

SSLピンニングはこのスキームを壊します。アプリケーションはプロキシツールの証明書を確認し、それがサーバーの「オリジナル」証明書と一致しないことを理解し、動作を拒否します。これが、SSL handshake failed、Certificate verification failed、または単にアプリケーション内の空白画面のようなエラーが表示される理由です。

開発者がSSLピンニングを実装する理由はいくつかあります：

• 中間者攻撃（MITM）からの保護
• APIのリバースエンジニアリングの防止
• ボットや自動化されたリクエストからの保護
• 内部のマネタイズロジックや広告統合の隠蔽

SSLピンニングを積極的に使用しているアプリケーションには、銀行アプリ、マーケットプレイス（Wildberries、Ozon）、広告SDK（Facebook、TikTok）、決済システム、大規模なeコマースプラットフォームがあります。これが、マーケティング担当者、アービトラージャー、競合分析の専門家にとってSSLピンニングの回避が非常に重要である理由です。

アプリケーションにSSLピンニングがある場合、なぜプロキシが機能しないのか

電話でプロキシを設定すると（たとえば、Wi-Fi設定を介して）、すべてのHTTPおよびHTTPSトラフィックがプロキシサーバーを通過します。HTTPの場合、問題なく機能します—トラフィックはオープンだからです。しかし、HTTPSの場合、プロキシツールは自分の証明書を挿入してサーバーとして「名乗る」必要があります。

ここで対立が生じます。通常のアプリケーションは、デバイスのシステムストレージにプロキシツールのルート証明書をインストールした場合、この証明書を受け入れます。しかし、SSLピンニングのあるアプリケーションはシステムストレージを無視します—彼らは自分の「埋め込まれた」証明書のみを確認します。

重要なのは、問題はプロキシサーバー（居住型、モバイル、データセンター）にはないということです。プロキシはここでトラフィックをルーティングするための中間ノードとして機能します。問題は、変更された証明書を受け入れないアプリケーション自体にあります。したがって、解決策はアプリケーションまたはデバイスのレベルで探す必要があります。

SSLピンニングにはいくつかのタイプがあり、それぞれ回避の難易度が異なります：

ピンニングの種類	確認されるもの	回避の難易度
証明書ピンニング	サーバーの完全な証明書	中程度
公開鍵ピンニング	証明書からの公開鍵	高い
ハッシュピンニング	証明書または鍵のハッシュ	高い
ネットワークセキュリティ構成	Androidの設定ファイル（XML）	低–中程度

トラフィック傍受のためのツール：Charles、mitmproxy、Burp Suite

SSLピンニングの回避に進む前に、トラフィックを傍受するためのツールを選択する必要があります。すべてのツールは同じ原理で動作します：ローカルプロキシサーバーを立ち上げ、デバイスのトラフィックが通過します。違いは、使いやすさ、機能、価格です。

Charles Proxy

マーケティング担当者や深い技術的バックグラウンドを持たないテスターの間で最も人気のあるツールです。グラフィカルインターフェースがあり、WindowsおよびmacOSで動作します。すべてのリクエストとレスポンスを便利なツリーで表示し、ドメインでフィルタリングし、リクエストをリアルタイムで編集できます。有料ですが、試用期間があります。マーケットプレイスのAPIや広告SDKの分析に最適です。

mitmproxy

無料のオープンソースツールです。コマンドラインを介して動作しますが、ウェブインターフェース（mitmweb）もあります。非常に柔軟で、トラフィックの自動修正のためのスクリプトをサポートしています。分析を自動化したり、テストパイプラインに傍受を統合したりしたい人に適しています。Charlesよりも設定が少し難しいです。

Burp Suite

セキュリティテストのためのプロフェッショナルツールです。基本機能を備えた無料のCommunityバージョンがあります。リクエストの詳細な分析、クッキーやセッションの操作に特に便利です。競合のAPI分析や広告統合の調査に積極的に使用されます。インターフェースはCharlesよりも複雑ですが、機能は広範です。

ツール	インターフェース	価格	対象ユーザー
Charles Proxy	GUI（使いやすい）	有料（約$50）	マーケティング担当者、アナリスト
mitmproxy	CLI + Web UI	無料	技術者
Burp Suite	GUI（複雑）	無料 / プロ	セキュリティテスター

マーケティング担当者やアービトラージャーのほとんどのタスク—広告リクエストの分析、マーケットプレイスのAPIの調査、アプリケーションのトラフィックの監視—には、Charles Proxyが最適な選択です。自動化やGUIなしでの作業が必要な場合は、mitmproxyを使用します。

SSLピンニングの回避方法：簡単なものから高度なものまで

SSLピンニングを回避するためのいくつかのアプローチがあります。それぞれ難易度、デバイスの要件、信頼性が異なります。最も簡単なものから最も強力なものまで、それぞれを見ていきましょう。

方法1：システムストレージに証明書をインストール（Androidのみ）

最も簡単な方法ですが、システム証明書ストレージを使用するアプリケーションにのみ適用されます。Android 7.0以前では、ユーザー証明書はシステム証明書と同等に受け入れられました。Android 7.0以降、アプリケーションはデフォルトでユーザーCAを無視します。アプリケーションがnetwork_security_config.xmlでユーザー証明書を明示的に許可している場合、この方法は機能します。現代のSSLピンニングを持つアプリケーションのほとんどには役立ちません。

方法2：Frida — アプリケーションの動的パッチング

Fridaはアプリケーションの動的インストゥルメンテーションツールです。アプリケーション内の関数呼び出しを「リアルタイム」で傍受し、その動作を変更できます。SSLピンニングを回避するための既製のスクリプトがあり、APKを変更せずに証明書の検証を無効にします。Androidではrootが必要で、iOSではjailbreakが必要です。これは最も信頼性が高く、汎用的な方法です。

方法3：APKのパッチ（Android）

apktoolを使用してAPKファイルをデコンパイルし、SSLピンニングのコードを削除または修正し、アプリケーションを再構築して署名します。rootは不要ですが、smaliコードの技術的スキルが必要です。Network Security Configを介してシンプルなピンニングを実装しているアプリケーションには効果的です。ネイティブコード（C/C++）を持つアプリケーションには、はるかに難しいです。

方法4：Objection — 初心者向けのFridaラッパー

Objectionは、よりシンプルなコマンドラインインターフェースを持つFridaベースのツールです。SSLピンニングを1つのコマンドで回避するための組み込みコマンドを含んでいます：android sslpinning disable。Fridaスクリプトを手動で作成したくない人に適しています。rootまたはjailbreakが必要です。

方法5：root付きエミュレーターの使用

物理デバイスの代わりに、rootアクセスが有効なAndroidエミュレーター（たとえば、GenymotionやAndroid Studioの標準AVD）を使用できます。これにより、システム証明書をインストールし、Fridaをリスクなしで実行できます。作業環境での定期的なテストに便利なオプションです。

AndroidでのSSLピンニングのステップバイステップ回避

最も実用的なシナリオを見てみましょう：root付きのAndroidデバイスまたはエミュレーター、Objection + Fridaツール、Charles Proxyまたはmitmproxyプロキシツール。

ステップ1：コンピュータ上でプロキシツールを設定する

Charles Proxyまたはmitmproxyを起動します。デフォルトでは、ポート8888（Charles）または8080（mitmproxy）をリッスンします。デバイスのプロキシ設定に必要なローカルネットワーク内のコンピュータのIPアドレスを覚えておいてください。

ステップ2：Androidデバイスでプロキシを設定する

Wi-Fi設定に移動し、ネットワークを選択し、「変更」をクリックし、「詳細設定」を選択します。プロキシ：手動を選択します。コンピュータのIPとツールのポートを指定します。これで、デバイスのすべてのトラフィックがプロキシを通過します。

ステップ3：プロキシツールの証明書をインストールする

デバイスのブラウザを開き、chls.pro/ssl（Charlesの場合）またはmitm.it（mitmproxyの場合）にアクセスします。証明書をダウンロードしてインストールします。root付きのAndroidでは、証明書をシステムストレージに移動する必要があります—これは一部のアプリケーションに必要です。

ステップ4：デバイスでFrida-serverを起動する

GitHubから必要なバージョンのfrida-serverをダウンロードします（バージョンはコンピュータのFridaと一致する必要があります）。ADBを介してデバイスにファイルをアップロードします：

adb push frida-server /data/local/tmp/
adb shell "chmod 755 /data/local/tmp/frida-server"
adb shell "su -c /data/local/tmp/frida-server &"

ステップ5：Objectionを介して接続し、SSLピンニングを無効にする

コンピュータでpipを介してObjectionをインストールし、アプリケーションのパッケージ名を指定して起動します：

pip install objection
objection -g com.example.app explore

接続後、ObjectionコンソールでSSLピンニングを無効にするコマンドを実行します：

android sslpinning disable

その後、アプリケーションを開いて操作を開始します。トラフィックはCharlesまたはmitmproxyに復号化された形で表示されます。

ステップ6：Network Security Configを持つアプリケーションの場合

アプリケーションがnetwork_security_config.xmlを使用している場合、apktoolを介してAPKをデコンパイルし、このファイルを見つけてユーザー証明書の許可を追加し、APKを再構築して再署名します。これはrootなしで機能しますが、アプリケーションの署名検証を無効にする必要があります。

iOSでのSSLピンニングのステップバイステップ回避

iOSでは状況が複雑です：ほとんどの方法にはjailbreakが必要です。jailbreakなしでは、可能性が制限されます。両方のオプションを見てみましょう。

オプションA：jailbreakあり（iOS 14-16、checkra1n / palera1n）

ステップ1：プロキシを設定する

iPhoneで設定→Wi-Fi→ネットワーク→プロキシを設定→手動を選択します。コンピュータのIPとCharles/mitmproxyのポートを指定します。

ステップ2：証明書をインストールする

Safariを開き、chls.pro/sslにアクセスします。設定→一般→VPNとデバイス管理を介してプロファイルをインストールします。その後、設定→一般→証明書の信頼で有効にします。

ステップ3：Cydia/Sileoを介してSSL Kill Switch 2をインストールする

SSL Kill Switch 2は、すべてのアプリケーションに対してSSLピンニングをグローバルに無効にするためのjailbroken iOS向けのツイックです。CydiaまたはSileoで見つけてインストールし、デバイスを再起動します。その後、ほとんどのアプリケーションは証明書の検証を停止し、トラフィックはCharlesに表示されます。

ステップ4：代替案 — iOSでのFrida + Objection

Androidと同様に、Cydiaを介してfrida-serverをインストールし、コンピュータでObjectionを介して接続し、ios sslpinning disableを実行します。この方法はより柔軟で、SSL Kill Switch 2がカバーしないアプリケーションにも機能します。

オプションB：jailbreakなし（制限された機能）

jailbreakなしでiOSのSSLピンニングを回避するのはかなり難しいです。1つのオプションは、jailbreakなしでiOS用のSSLプロキシング機能を持つProxymanツールを使用することです。Proxymanはデバイスに特別なプロファイルをインストールし、トラフィックを傍受するためにVPNインターフェースを使用します。多くのアプリケーションで機能しますが、厳格なピンニングのあるすべてのアプリケーションには対応していません。

別のオプションは、XcodeでiOSシミュレーターを使用することです。シミュレーターはOSレベルでSSLピンニングを持たず、多くのアプリケーションを実行できます（シミュレーターをサポートしている場合）。しかし、これはテスト用であり、プロダクションアプリケーションの分析には適していません。

モバイルアプリケーションのテストに適したプロキシの種類

SSLピンニングが回避された後、アプリケーションのトラフィックはプロキシツール（Charles、mitmproxy）を通過します。しかし、特定のタスクでは、トラフィックを外部プロキシサーバーを介してルーティングする必要があります—たとえば、アプリケーションが別の地域や別のIPアドレスを「見る」ためです。ここで、プロキシの種類を正しく選択することが重要です。

居住型プロキシ

居住型プロキシは、実際の家庭ユーザーのIPアドレスを使用します。特に広告SDKやマーケットプレイスなどのモバイルアプリケーションは、データセンターのアドレスよりもこれらのIPを大幅に信頼します。アプリケーションの地域に応じた挙動を分析する場合、居住型プロキシは最も「クリーンな」画像を提供し、実際のユーザーに近いものになります。

モバイルプロキシ

モバイルプロキシは、実際のモバイルネットワーク（3G/4G/5G）を介して動作します。これは、モバイルアプリケーションのテストに特に重要です：モバイルネットワークのIPは、Facebook Ads SDK、TikTok、その他の広告プラットフォームで最高の信頼レベルを持っています。アプリケーションの広告リクエストを分析したり、モバイル環境でのSDKの挙動をテストしたりすることが目的であれば、モバイルプロキシが最適な選択です。

データセンターのプロキシ

データセンターのプロキシは、速度が重要であり、「自然さ」ではないタスクに適しています：たとえば、オープンAPIの大量パースやパフォーマンステストに使用されます。広告SDKや保護されたアプリケーションの分析にはあまり好ましくなく、詐欺防止システムによって簡単に認識されます。

プロキシの種類	アプリケーションの信頼性	速度	最適なシナリオ
居住型	高い	中程度	地域別分析、マーケットプレイス
モバイル	最大	中程度	広告SDK、Facebook、TikTok
データセンター	低い	高い	オープンAPIのパース、負荷テスト

実用的なシナリオ：アービトラージ、eコマース、マーケティング

マーケティング担当者やアービトラージャーがSSLピンニングを回避する理由となる具体的なタスクを見てみましょう。

シナリオ1：FacebookおよびTikTokの広告SDKの分析

Facebook AdsやTikTok Adsを扱うアービトラージャーは、SDKがサーバーに送信するデータを理解したいと考えています：どのイベントが記録され、アトリビューションリクエストがどのように形成され、どのパラメータがキャンペーンの最適化に影響を与えるか。SSLピンニングを回避しない限り、これは不可能です—両方のSDKは証明書ピンニングを使用しています。

Frida/Objectionを介して回避した後、CharlesでSDKのすべてのイベントを確認できます：インストール、購入、登録—トラッキングが正しく設定されていることを確認できます。これは、CAPI（Conversions API）の設定やイベントの重複排除を確認する際に特に重要です。

シナリオ2：WildberriesおよびOzonの価格監視アプリケーション

WildberriesおよびOzonアプリケーションは、APIを保護するためにSSLピンニングを使用しています。競合の価格をモバイルアプリケーション（ウェブバージョンではなく）を介して監視したいセラーは、この保護に直面します。SSLピンニングを回避した後、APIリクエストの構造を調査し、価格、在庫、商品評価に関するデータを取得するために使用されるエンドポイントを理解できます。

重要な点：取得したデータは個人的な分析にのみ使用できます。APIリクエストの再生を介した自動化されたパースは、プラットフォームの利用規約に違反します。

シナリオ3：異なる地域からの広告クリエイティブのテスト

Facebook AdsやTikTok Adsで異なる地域から広告をテストするマーケティング担当者は、特定の国のIPを介して接続したときにアプリケーションがどのように動作するかを見たいと考えています。SSLピンニングの回避と必要な地域の居住型プロキシの組み合わせにより、その地域のユーザーに表示されるコンテンツや価格を確認できます。

シナリオ4：自社アプリケーションのQAテスト

自社のモバイルアプリケーションを開発している場合や、開発チームと協力している場合、SSLピンニングを回避してトラフィックを傍受することはQAの標準的な実践です。これにより、リクエストの正確性を確認し、データ漏洩を見つけ、リリース前に実際の条件で分析や広告SDKの動作を確認できます。

シナリオ5：モバイルゲームやアプリの競合分析

モバイルゲームのマーケティング担当者は、競合のマネタイズを分析するためにトラフィックを傍受します：どのオファーが表示され、インゲーム購入システムがどのように機能し、どの広告ネットワークが使用されているか。これにより、より効果的なUA（ユーザー獲得）およびマネタイズ戦略を構築するのに役立ちます。

テスト前に設定を確認するためのチェックリスト

トラフィックの傍受を開始する前に、すべてが正しく設定されていることを確認してください。以下が完全なチェックリストです：

よくある問題とその解決策

問題	原因	解決策
トラフィックがCharlesに表示されない	プロキシのIP/ポートが無効	コンピュータのIPとポートを確認してください
CharlesでSSLエラー	証明書がインストールされていないか、無効になっている	証明書を再インストールし、アクティブにしてください
Fridaが接続できない	frida/frida-serverのバージョン不一致	バージョンを同期してください
Objectionがピンニングを無効にしない	ネイティブコード（C/C++）にピンニングがある	カスタムFridaスクリプトを使用してください
バイパス後にアプリケーションがクラッシュする	アプリケーションが整合性を確認している	Objectionを介してroot検出も無効にしてください

結論

SSLピンニングは厳重な保護ですが、克服できないわけではありません。マーケティング担当者やアービトラージャーのほとんどの実用的なタスクには、Androidエミュレーター（root付き）+ Frida/Objection + Charles Proxyの組み合わせが十分です。iOSでは、jailbreakがある場合はSSL Kill Switch 2、ない場合はProxymanを使用します。重要なのは、プロキシツールをコンピュータで設定し、トラフィックを通過させ、デバイスでピンニングを回避するチェーンを正しく設定することです。

サードパーティアプリケーションのSSLピンニングを回避することは、個人的な分析や研究のためにのみ許可されています。自動化されたパースやAPIリクエストの再生は、ほとんどのプラットフォームの利用規約に違反します。

モバイルアプリケーションのトラフィックを異なる地域で分析したり、特定の国の広告SDKの挙動をテストしたりする場合、SSLピンニングの回避だけでなく、高品質なプロキシサーバーも必要です。広告プラットフォーム（Facebook Ads、TikTok Ads）やマーケットプレイスでの作業には、詐欺防止システムで最高の信頼レベルを持ち、実際のモバイル環境を正しくエミュレートできるモバイルプロキシの使用をお勧めします。