問題まとめ¶

このスクリプト user-home/modules/script/enhanced_automation_wechat.yaml をダウンロードし、デバイスの ~/modules/script ディレクトリに配置してください。

古いバージョンでは一部の環境でこの問題が発生する可能性があります。現在の最新バージョンに変更してください。それでも最終的に問題が再発する場合は、すべての Magisk モジュールを無効化して再起動してください。

この現象は Android 16 で発生する可能性がありますが、下位バージョンでも発生しないとは限りません。まず、必ず最新バージョンのサーバーを使用していることを確認してください。それでも問題が発生する場合は、使用している Root ソフトウェアが KernelSU かどうかを確認してください。クラッシュは、古いバージョンの ksu がシステムの SELinux policy image を破損させることが原因です。最新版の ksu をお試しください。それでもクラッシュする場合は、Magisk に切り替えるか、シェル権限を降格して実行してください。

これは、一部のアプリが app-zygote を使用して Frida を検知していることが原因である可能性があります。リモートデスクトップで enhanced-stealth-mode=true を設定することで、この問題を回避できます（副作用として Frida の spawn 関連機能を使用できなくなります）。10.x では、デフォルトでこの設定は不要です。10.x が使用するデフォルトの frida-server バージョン自体がすでにこの問題を回避しています。（ただし、手動で 17.5.2 バージョンに切り替えた場合は、この設定が必要になる可能性があります）。それでも最終的に問題が再発する場合は、すべての Magisk モジュールを無効化して再起動してください。

パケットキャプチャ機能が完全かどうかを質問する必要はありません。FIRERPA がすべてを整えており、キャプチャに必要なあらゆる手順をすでに完了しています。他のキャプチャソフトでパケットを取得できない場合でも、FIRERPA は必ず取得できます。FIRERPA で取得できない場合、同じロジックのソフトウェアではどれも取得できません。証明書の信頼問題を心配する必要はありません。FIRERPA はキャプチャ時にアプリへシステムレベルのルート証明書を自動でインストールするため、手動操作は不要です。QUIC のダウングレードについては、startmitm が自動的に UDP プロトコルを無効化します。通常、アプリは UDP を使用できない場合、自動的にダウングレードして QUIC を使用しなくなります。これらはすべて手動で介入する必要はありません。

考えられる原因：1 つは、アプリ自体に証明書検証または証明書ピンニング機構が存在すること。もう 1 つは、前後処理が正しく行われていないことです。アプリに証明書検証機構があるかどうかを確認する方法：グローバルキャプチャを有効にし、ブラウザなど他のアプリを開いて正常にキャプチャできるか確認します。ネットワークに接続する複数のアプリで確認してください。キャプチャできるアプリとできないアプリがある場合、おそらくキャプチャできないアプリは独自プロトコルまたは証明書検証機構を採用しています。これは通常、startmitm のログに Client TLS handshake failed などの情報として出力されますが、これは重要ではありません。アプリに証明書検証が存在すると確認できた場合は、リバースエンジニアリングなどの手段で検証機構を動的に回避しなければキャプチャを続行できません。前後処理が正しく行われていない場合について：通常、一部のユーザーはシステムファイアウォールを無効にしていないため、プロキシポートにスマートフォンからアクセスできず、何の反応もありません。もう 1 つのケースは、キャプチャを開始する前にアプリが必要なネットワーク接続をすでに確立しているため、キャプチャ開始後のトラフィックがこれらの既存接続を通じて送信され、プロキシを経由しないことです。startmitm を起動した後、アプリを手動で完全に終了（強制停止）し、アプリを再度開いてください。

まず、ファイアウォールが無効になっているか確認してください。次に、スマートフォンのブラウザでウェブサイトにアクセスしたとき、ワンクリックキャプチャスクリプトがログを出力するか確認してください。No route to host のようなエラーが表示され、ブラウザでのアクセス動作と対応する場合（つまりアクセスのたびにスクリプトがこのエラーを出力する場合）、考えられる原因は次のとおりです。スマートフォン自体が IPv6 ネットワークアクセスに対応しており、デフォルトの DNS 解決も IPv6 を使用している一方で、スクリプトを実行しているパソコンで IPv6 が有効になっていないか対応していないため、No route to host が発生します。お使いのブロードバンドが IPv6 に対応している場合は、パソコンのネットワーク設定で手動で有効にしてください。または、スクリプトのコマンドラインで --proxy-dns 114.114.114.114 を指定して、正常に戻るかテストしてください。これらの方法がどちらも効果がない場合は、サポートにお問い合わせください。

この問題は上記と同じです。まず他のいくつかのアプリで正常にキャプチャできるかテストし、サービス側の問題を除外してください。正常にプロキシできる場合、この現象はデバイスが IPv6 に対応している一方で、startmitm を実行しているマシンに有効な IPv6 アドレスがないことが原因である可能性があります。ネットワークに利用可能なパブリック IPv6 が存在する場合は、パソコンに割り当ててください。または、ルーター側で IPv6 を完全に無効化してください。

関連アプリのパケットを正常にキャプチャできる場合は、この出力を気にする必要はありません。これは、システム内の他のアプリやアプリのサードパーティ SDK の証明書検証機構によって生成されたログである可能性があります。

自動起動 APK は、システムごとの設定によって制限されるため、システムと一緒に自動起動しない場合があります。起動後にアクセスできない場合は、アプリ内の 手動起動 ボタンをタップして手動で起動し、1 分待ってから再度アクセスしてください。それでも起動できない場合は、手動インストールまたはモジュールインストール方式を試してください。

環境準備 の章に記載されている関連設定を完了していることを確認し、その後デバイスを複数回（約 3 回）再起動してみてください。