Android アンチインストルメンテーション & SSL ピンニング回避 (Frida/Objection)

Tip

AWS Hackingを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hackingを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
Az Hackingを学び、実践する: HackTricks Training Azure Red Team Expert (AzRTE) HackTricks Trainingの全カタログ を閲覧して、評価トラック（ARTA/GRTA/AzRTA）と Linux Hacking Expert (LHE) を確認してください。

HackTricksをサポート

このページは、インストルメンテーションを検出/ブロックする、または TLS pinning を強制する Android アプリに対して動的解析を取り戻すための実用的なワークフローを提供します。高速なトリアージ、一般的な検出方法、可能な限りリパッキングせずに回避するためのコピペ可能なフック/戦術に焦点を当てています。

検出対象（アプリがチェックするもの）

  • Root checks: su バイナリ、Magisk パス、getprop 値、一般的な root パッケージ
  • Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), /proc のスキャン、classpath、ロード済みライブラリ
  • Native anti‑debug: ptrace(), syscalls、anti‑attach、ブレークポイント、inline hooks
  • Early init checks: Application.onCreate() やプロセス開始時のフックで、インストルメンテーションが存在するとクラッシュするもの
  • TLS pinning: カスタム TrustManager/HostnameVerifier、OkHttp CertificatePinner、Conscrypt pinning、ネイティブピン

Bypassing Anti‑Frida Detection / Stealth Frida Servers

phantom-frida は Frida をソースから再構築し、一般的な Frida のフィンガープリントが消えるように約90 のパッチを適用しますが、標準の Frida プロトコルとの互換性は維持されます（frida-tools は引き続き接続可能）。対象は /proc を grep する（cmdline、maps、task comm、fd readlink）、D-Bus サービス名、デフォルトポート、エクスポートされたシンボルを検出するアプリです。

フェーズ:

  • Source patches: frida 識別子（server/agent/helper）のグローバルリネームと、Java パッケージ名を変更した helper DEX の再構築
  • Targeted build/runtime patches: meson の調整、memfd ラベルを jit-cache に変更、SELinux ラベル（例: frida_file）のリネーム、libc の exit/signal フックを無効化してフック検出回避
  • Post-build rename: 最初のコンパイル後にエクスポートシンボル frida_agent_main をリネーム（Vala がそれを出力するため）、2 回目のインクリメンタルビルドが必要
  • Binary hex patches: スレッド名（gmain、gdbus、pool-spawner）を置換；オプションで残存する frida/Frida 文字列を一掃

カバーする検出ベクター:

  • Base (1–8): プロセス名 frida-server、マップされた libfrida-agent.so、スレッド名、memfd ラベル、エクスポートされた frida_agent_main、SELinux ラベル、libc フックの副作用、D-Bus サービス re.frida.server をリネーム／無効化
  • Extended (9–16): リスニングポートの変更（--port）、D-Bus インターフェイス／内部 C シンボル／GType 名のリネーム、.frida/frida- のような一時パス、バイナリ文字列の一掃、ビルド時の define やアセットパス（libdir/frida）のリネーム。ワイヤープロトコルの一部である D-Bus インターフェイス名は、標準クライアントを壊さないよう base モードでは変更されません。

Build/usage (Android arm64 example):

python3 build.py --version 17.7.2 --name myserver --port 27142 --extended --verify
adb push output/myserver-server-17.7.2-android-arm64 /data/local/tmp/myserver-server
adb shell chmod 755 /data/local/tmp/myserver-server
adb shell /data/local/tmp/myserver-server -D &
adb forward tcp:27142 tcp:27142
frida -H 127.0.0.1:27142 -f com.example.app

Flags: --skip-build (patch only), --skip-clone, --arch, --ndk-path, --temp-fixes; WSL helper: wsl -d Ubuntu bash build-wsl.sh.

ステップ1 — クイックウィン: Magisk DenyListでrootを隠す

  • MagiskでZygiskを有効化
  • DenyListを有効にし、対象パッケージを追加
  • 再起動して再テスト

多くのアプリは明白な指標（su/Magisk paths/getprop）のみをチェックします。DenyListはしばしば単純なチェックを無効化します。

参考:

  • Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk

Play Integrity / Zygisk の検出 (post‑SafetyNet)

最近の銀行・ID系アプリはランタイムチェックをGoogle Play Integrity (SafetyNetの後継) に結びつけており、Zygisk自体が存在するとクラッシュすることもあります。簡易トリアージのヒント：

  • 一時的にZygiskを無効化（トグルオフ＋再起動）して再試行してください。Zygoteの注入がロードされると即座にクラッシュするアプリもあります。
  • attestationがログインをブロックする場合、Google Play ServicesをPlayIntegrityFix/Fork + TrickyStoreでパッチするか、テスト時のみReZygisk/Zygisk‑Nextを使用してください。ターゲットはDenyListに入れておき、propsをleakするLSPosedモジュールは避けてください。
  • 一回限りの実行では、KernelSU/APatch（Zygote注入なし）を使ってZygiskのヒューリスティクスを回避し、その後Fridaをアタッチしてください。

ステップ2 — 30秒 Frida Codeshare テスト

深掘りする前に一般的なドロップインスクリプトを試す：

  • anti-root-bypass.js
  • anti-frida-detection.js
  • hide_frida_gum.js

例:

frida -U -f com.example.app -l anti-frida-detection.js

これらは通常、Java の root/debug チェック、process/service スキャン、およびネイティブ ptrace() をスタブ化します。軽度に保護されたアプリでは有用ですが、ハード化されたターゲットには個別に調整したフックが必要な場合があります。

  • Codeshare: https://codeshare.frida.re/

Medusa (Frida framework)で自動化

Medusa は SSL unpinning、root/emulator detection bypass、HTTP comms logging、crypto key interception などのための 90+ の既成モジュールを提供します。

git clone https://github.com/Ch0pin/medusa
cd medusa
pip install -r requirements.txt
python medusa.py

# Example interactive workflow
show categories
use http_communications/multiple_unpinner
use root_detection/universal_root_detection_bypass
run com.target.app

ヒント: Medusa はカスタム hooks を書く前のクイックウィンに最適です。modules を選んで自分の scripts と組み合わせることもできます。

Automate with Auto-Frida (spawn-mode + consolidated hooks)

Auto-Frida は、繰り返し可能なセットアップに加え、保護の 自動検出 と 統合された bypass script 生成 に注力した Frida automation toolkit です。アプリが非常に早い段階でチェックを実行する場合や、複数の bypass modules が同じ APIs を二重に hook してしまう場合に有用です。

Key automation ideas:

  • Spawn-mode analysis: Application.onCreate() より前に hooks を仕込むことで、早期の SSL pinning、root、emulator、または anti-Frida チェックを捕捉できます。
  • Protection detection + auto-bypass: 検出結果に基づいて、各 Java method/native symbol を一度だけ hook する単一の統合スクリプトを生成し、hooks の重複によるクラッシュを低減します。
  • Frida server lifecycle checks: ダウンロード/再起動の前にサーバーの健全性（process + port 27042 + frida-ps ハンドシェイク）を検証して実行を安定させます。

クイックスタート:

git clone https://github.com/ommirkute/Auto-Frida.git
cd Auto-Frida
pip install -r requirements.txt
python auto_frida.py

注意

  • Auto-Frida は不足している場合に frida/frida-tools を自動インストールでき、複数デバイスの選択をサポートします。
  • 生成されたスクリプトは解析後すぐに実行するか、カスタムフックとマージできます。

Step 3 — 初期化時の検出を遅れてアタッチして回避する

多くの検出は process spawn/onCreate() の間だけ実行される。Spawn‑time injection (-f) や gadgets は検知されやすいが、UI が読み込まれた後にアタッチすれば回避できることがある。

# Launch the app normally (launcher/adb), wait for UI, then attach
frida -U -n com.example.app
# Or with Objection to attach to running process
aobjection --gadget com.example.app explore  # if using gadget

これでうまくいったら、セッションを安定させたまま map と stub チェックに進んでください。

Step 4 — Jadx と文字列検索で検出ロジックをマップする

Jadxでの静的トリアージキーワード:

  • “frida”, “gum”, “root”, “magisk”, “ptrace”, “su”, “getprop”, “debugger”

典型的な Java パターン:

public boolean isFridaDetected() {
return getRunningServices().contains("frida");
}

確認・フックすべき一般的なAPI:

  • android.os.Debug.isDebuggerConnected
  • android.app.ActivityManager.getRunningAppProcesses / getRunningServices
  • java.lang.System.loadLibrary / System.load (ネイティブブリッジ)
  • java.lang.Runtime.exec / ProcessBuilder (プロービングコマンド)
  • android.os.SystemProperties.get (root/エミュレータのヒューリスティック)

ステップ5 — Frida (Java)を使ったランタイムスタブ

repackingせずに安全な値を返すためにカスタムガードをオーバーライドする:

Java.perform(() => {
const Checks = Java.use('com.example.security.Checks');
Checks.isFridaDetected.implementation = function () { return false; };

// Neutralize debugger checks
const Debug = Java.use('android.os.Debug');
Debug.isDebuggerConnected.implementation = function () { return false; };

// Example: kill ActivityManager scans
const AM = Java.use('android.app.ActivityManager');
AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
});

早期のクラッシュをトリアージしていますか？クラッシュ直前に classes をダンプして、検出に関係しそうな namespaces を特定します:

Java.perform(() => {
Java.enumerateLoadedClasses({
onMatch: n => console.log(n),
onComplete: () => console.log('Done')
});
});

簡単な root detection スタブの例（対象の package/class 名に合わせて調整してください）:

Java.perform(() => {
try {
const RootChecker = Java.use('com.target.security.RootCheck');
RootChecker.isDeviceRooted.implementation = function () { return false; };
} catch (e) {}
});

疑わしいメソッドをログ出力して無効化し、実行フローを確認する：

Java.perform(() => {
const Det = Java.use('com.example.security.DetectionManager');
Det.checkFrida.implementation = function () {
console.log('checkFrida() called');
return false;
};
});

Bypass emulator/VM detection (Java stubs)

一般的なヒューリスティック: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE に generic/goldfish/ranchu/sdk が含まれている; QEMU の痕跡（/dev/qemu_pipe, /dev/socket/qemud のような）; デフォルト MAC 02:00:00:00:00:00; 10.0.2.x の NAT; telephony/sensors が欠如している。

Build フィールドの簡単な偽装:

Java.perform(function(){
var Build = Java.use('android.os.Build');
Build.MODEL.value = 'Pixel 7 Pro';
Build.MANUFACTURER.value = 'Google';
Build.BRAND.value = 'google';
Build.FINGERPRINT.value = 'google/panther/panther:14/UP1A.231105.003/1234567:user/release-keys';
});

ファイルの存在チェックや識別子 (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList) のスタブを補完して、現実的な値を返すようにしてください。

SSL pinning bypass quick hook (Java)

カスタム TrustManagers を無効化し、許容的な SSL contexts を強制します:

Java.perform(function(){
var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager');
var SSLContext = Java.use('javax.net.ssl.SSLContext');

// No-op validations
X509TrustManager.checkClientTrusted.implementation = function(){ };
X509TrustManager.checkServerTrusted.implementation = function(){ };

// Force permissive TrustManagers
var TrustManagers = [ X509TrustManager.$new() ];
var SSLContextInit = SSLContext.init.overload('[Ljavax.net.ssl.KeyManager;','[Ljavax.net.ssl.TrustManager;','java.security.SecureRandom');
SSLContextInit.implementation = function(km, tm, sr){
return SSLContextInit.call(this, km, TrustManagers, sr);
};
});

ノート

  • OkHttp用に拡張：必要に応じて okhttp3.CertificatePinner と HostnameVerifier を hook するか、CodeShare の汎用 unpinning スクリプトを使用してください。
  • 実行例: frida -U -f com.target.app -l ssl-bypass.js --no-pause

OkHttp4 / gRPC / Cronet pinning (2024+)

最新のスタックは新しい API 内部で pinning を行います（OkHttp4+, gRPC over Cronet/BoringSSL）。基本的な SSLContext フックで対応できない場合は、これらのフックを追加してください：

Java.perform(() => {
try {
const Pinner = Java.use('okhttp3.CertificatePinner');
Pinner.check.overload('java.lang.String', 'java.util.List').implementation = function(){};
Pinner.check$okhttp.implementation = function(){};
} catch (e) {}

try {
const CronetB = Java.use('org.chromium.net.CronetEngine$Builder');
CronetB.enablePublicKeyPinningBypassForLocalTrustAnchors.overload('boolean').implementation = function(){ return this; };
CronetB.setPublicKeyPins.overload('java.lang.String', 'java.util.Set', 'boolean').implementation = function(){ return this; };
} catch (e) {}
});

それでも TLS が失敗する場合は、native に落とし、Cronet/gRPC で使用される BoringSSL の verification entry points を patch してください:

const customVerify = Module.findExportByName(null, 'SSL_CTX_set_custom_verify');
if (customVerify) {
Interceptor.attach(customVerify, {
onEnter(args){
// arg0 = SSL_CTX*, arg1 = mode, arg2 = callback
args[1] = ptr(0); // SSL_VERIFY_NONE
args[2] = NULL;  // disable callback
}
});
}

Step 6 — Java hooks が失敗したときは JNI/native の経路を追う

JNI のエントリポイントを追跡して native loaders と detection init を特定する：

frida-trace -n com.example.app -i "JNI_OnLoad"

同梱された .so ファイルの簡易ネイティブトリアージ:

# List exported symbols & JNI
nm -D libfoo.so | head
objdump -T libfoo.so | grep Java_
strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root'

インタラクティブ/ネイティブ reversing:

  • Ghidra: https://ghidra-sre.org/
  • r2frida: https://github.com/nowsecure/r2frida

例: ptrace を無効化して libc の単純な anti‑debug を回避する:

const ptrace = Module.findExportByName(null, 'ptrace');
if (ptrace) {
Interceptor.replace(ptrace, new NativeCallback(function () {
return -1; // pretend failure
}, 'int', ['int', 'int', 'pointer', 'pointer']));
}

参照: Reversing Native Libraries

ステップ 7 — Objection パッチ適用 (embed gadget / strip basics)

repacking を runtime hooks より好む場合は、次を試してください:

objection patchapk --source app.apk

注意:

  • apktool が必要です。ビルドの問題を避けるため、公式ガイドから最新版を入手してください: https://apktool.org/docs/install
  • Gadget injection は root なしで instrumentation を可能にしますが、より強力な init‑time checks によって検出される可能性があります。

オプションとして、Zygisk 環境でのより強力な root 隠蔽のために LSPosed modules と Shamiko を追加し、子プロセスをカバーするよう DenyList を調整してください。

For a complete workflow including script-mode Gadget configuration and bundling your Frida 17+ agent into the APK, see:

Frida Tutorial — Self-contained agent + Gadget embedding

参照:

  • Objection: https://github.com/sensepost/objection

Step 8 — フォールバック: ネットワーク可視性のために TLS pinning をパッチする

もし instrumentation がブロックされている場合でも、pinning を静的に除去することでトラフィックを確認できます:

apk-mitm app.apk
# Then install the patched APK and proxy via Burp/mitmproxy
  • ツール: https://github.com/shroudedcode/apk-mitm
  • ネットワーク構成のCA信頼に関するトリック（および Android 7+ のユーザーCA信頼）については次を参照:

Make APK Accept CA Certificate

Install Burp Certificate

LSPosed/Xposed Hooking Abuse (Telephony/SMS)

root化された端末では、LSPosed/Xposedモジュールは実行時に Java の telephony/SMS API をフックでき、ディスク上の APK を変更せずにアプリが見る内容を完全に制御できます。これは、ローカルの telephony API やローカル SMS プロバイダの状態を信頼する SIM‑binding フローを回避するために悪用されることが一般的です。

主な手法

  • 送信される検証用SMSを抑止する — token を外部に持ち出しつつ、beforeHookedMethod 内で SmsManager.sendTextMessage をショートサーキットすることで実現します。
  • MSISDN/回線番号を偽装する — TelephonyManager.getLine1Number() と SubscriptionInfo.getNumber() が攻撃者制御の値を返すよう強制します。
  • 偽の “Sent” レコードを植え付ける — SMS プロバイダに偽の送信記録を作成し、アプリがローカルの SMS 履歴を確認した際に、キャリアが実際に受信していなくても送信が成功したように見せます。

例：SMS の送信をブロックして内容をキャプチャする

XposedHelpers.findAndHookMethod(
"android.telephony.SmsManager",
lpparam.classLoader,
"sendTextMessage",
String.class, String.class, String.class, PendingIntent.class, PendingIntent.class,
new XC_MethodHook() {
protected void beforeHookedMethod(MethodHookParam param) {
String body = (String) param.args[2];
// exfiltrate body to operator channel
param.setResult(null); // suppress real SMS send
}
}
);

例: spoof デバイスの電話番号

XposedHelpers.findAndHookMethod(
"android.telephony.TelephonyManager",
lpparam.classLoader,
"getLine1Number",
new XC_MethodHook() {
protected void afterHookedMethod(MethodHookParam param) {
param.setResult(spoofedMsisdn);
}
}
);

XposedHelpers.findAndHookMethod(
"android.telephony.SubscriptionInfo",
lpparam.classLoader,
"getNumber",
new XC_MethodHook() {
protected void afterHookedMethod(MethodHookParam param) {
param.setResult(spoofedMsisdn);
}
}
);

例: 偽の “Sent” SMS レコードを挿入する

ContentValues v = new ContentValues();
v.put("address", dest);
v.put("body", body);
v.put("type", 2);   // sent
v.put("status", 0); // success
context.getContentResolver().insert(Uri.parse("content://sms/sent"), v);

便利なコマンド チートシート

# List processes and attach
frida-ps -Uai
frida -U -n com.example.app

# Spawn with a script (may trigger detectors)
frida -U -f com.example.app -l anti-frida-detection.js

# Trace native init
frida-trace -n com.example.app -i "JNI_OnLoad"

# Objection runtime
objection --gadget com.example.app explore

# Static TLS pinning removal
apk-mitm app.apk

Universal proxy forcing + TLS unpinning (HTTP Toolkit Frida hooks)

モダンなアプリはしばしばシステムの proxy を無視し、Java + native の複数層のピンニングを強制します。これにより、ユーザ/システム CA をインストールしていても通信のキャプチャが困難になります。実用的なアプローチは、既成の Frida hooks を使って universal TLS unpinning と proxy forcing を組み合わせ、すべてのトラフィックを mitmproxy/Burp 経由にルーティングすることです。

Workflow

  • ホストで mitmproxy（または Burp）を実行します。デバイスがホストの IP/ポートに到達できることを確認してください。
  • HTTP Toolkit の統合された Frida hooks を読み込んで、一般的なスタック（OkHttp/OkHttp3、HttpsURLConnection、Conscrypt、WebView など）に対して TLS の unpinning と proxy の強制を行います。これにより CertificatePinner/TrustManager のチェックをバイパスし、proxy selector を上書きするため、アプリ側が明示的に proxy を無効にしていても通信は常にあなたの proxy 経由で送信されます。
  • Frida とフックスクリプトでターゲットアプリを起動し、mitmproxy でリクエストをキャプチャします。

Example

# Device connected via ADB or over network (-U)
# See the repo for the exact script names & options
frida -U -f com.vendor.app \
-l ./android-unpinning-with-proxy.js \
--no-pause

# mitmproxy listening locally
mitmproxy -p 8080

ノート

  • 可能な場合は、システム全体のプロキシ（adb shell settings put global http_proxy <host>:<port>）と組み合わせてください。Frida hooks は、アプリがグローバル設定を回避してもプロキシ使用を強制します。
  • この手法は、pinning/proxy の回避が一般的な mobile-to-IoT のオンボーディングフローを MITM する必要がある場合に最適です。
  • Hooks: https://github.com/httptoolkit/frida-interception-and-unpinning

参考資料

Tip

AWS Hackingを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hackingを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
Az Hackingを学び、実践する: HackTricks Training Azure Red Team Expert (AzRTE) HackTricks Trainingの全カタログ を閲覧して、評価トラック（ARTA/GRTA/AzRTA）と Linux Hacking Expert (LHE) を確認してください。

HackTricksをサポート