NPatchでルート不要のXposedモジュール実行する方法
他社製Androidアプリの内部を調査したり、SSLピニングをバイパスしたり、非表示のデバッグ機能を有効にしたい場合、多くの人はMagiskやKernelSUに手を伸ばします。しかし、日常使いのスマホを1つのユーティリティのためにルート化するのは面倒です。銀行アプリが動作しなくなったり、Play Integrityが失敗したり、企業端末ではセキュリティポリシーによりルート化が禁止されていたりと、問題が山積みです。
長い間、この問題はLSPatchプロジェクトによって解決されてきました。 готовый APKを取得し、内部にLSPosedランタイムと必要なフックを埋め込むことで、システム権限なしでXposedモジュールを実行できました。元のLSPatchの開発が停止治疗后、forkであるNPatch（Neo LSPatch）がその空白を埋めるために登場しました。
このツールできること
このプロジェクトは通常のAPKファイルを取得して再パッケージします。アーカイブ内部には、ローダーのDEXファイルとART（Android Runtime）コールの傍受を担当するネイティブライブラリ（.so）が注入されます。パッチ適用済みのアプリが起動すると、この埋め込まれたレイヤーが最初に起動し、分離されたアプリプロセス内で直接Xposed API実行環境を初期化します。
システムの残りの部分にとっては、あなたはただの通常のユーザープログラムを実行しているだけです。スーパーユーザー権限は不要で、システムパーティション /systemに触れず、 zygote を置き換えようともしません。すべての変更とフックは、その特定のパッケージのサンドボックス内に厳密に閉じ込められます。
Android 9以降から現在のAndroidリリースまで、JingMatrix/LSPosedコードベースと互換性のあるバージョンがサポートされています。
パッチプロセスの仕組み
内部的には、NPatchはいくつかのオープンソースプロジェクトの成果に基づいています：
- LSPosedはXposed APIコールとARTにおけるランタイムメソッド傍受を処理します。
- Xpatchはシステム介さずにAPKにコードを注入するという中核的な概念を提供しました。
- ApkzlibはZIPアーカイブの展開と変更、そしてsmaliへの完全デコンパイルなしに素早く再パッケージするために使用されます。
クラシックなapktool + jarsignerの組み合わせとは異なり、大きな難読化プロジェクトをデコンパイルするとエラーでクラッシュすることがよくありますが、このアプローチはより高速で信頼性があります。リソースとマニフェストが直接調整された後、ローダーが注入されます。
使用方法
このツールは2つの方法で使えます：パソコン上でターミナル経由、またはデバイス上で直接。
方法1. jarによるコンソール
CIでのテストビルド自動化やワークステーションでのソフトウェア分析をしている場合、Releasesから готовую jarファイルをダウンロードする方が便利です：
# Базовый синтаксис запуска утилиты
java -jar npatch.jar [аргументы]
このユーティリティはソースAPKと埋め込むモジュールを入力として受け取ります。出力はテストキーで署名し、 adb install でインストールするだけでよい、変更済みパッケージです。
方法2. デバイス上のマネージャー
日常的なタスクには、GitHubのReleasesセクションから manager.apk をダウンロードする方が簡単です。
- Androidデバイスにマネージャーをインストールします。
- インストール済みのアプリまたはローカルのAPKファイルを選びます。
- 起動時に読み込む必要があるXposedモジュールを指定します。
- マネージャーが新しいインストールパッケージを構築し、元のものを削除してから改造版をインストールすることを提案します。
再パッケージ化 과정에서アプリの署名が неизбежно変更されるため、元のプログラムをその上にアップデートすることはできません。削除する必要があり、同期されていなかった場合はローカルデータが失われます。
実践的なユースケース
リバースエンジニアリングやモバイルクライアントテストで、これらのパッチャーを定期的に使っています。
- トラフィック傍受のためのSSLピニングバイパス。 Burp Suiteやmitmproxyでトラフィックをラップする場合、TrustMeAlreadyやJustTrustMeのようなモジュールを直接APKに埋め込めば、ずっとシンプルになります。Magisk経由でシステムストアに証明書をプッシュする必要がありません。
- 計装とログ収集。 サードパーティ製SDKのプライベートメソッドに渡される引数を確認する必要がある場合、小さなXposedフックを書き、ビルドに注入して、logcatにコールスタックをログ出力します。
- クリーンなデバイスでのモジュールのテスト。 モジュール開発者は、システムLSPosedなしでコードがどのように動作するかを分離して確認するのに便利です。
注意点と制限事項
ルートレスアプローチには事前に把握しておくべき自然な限界があります：
- システムモジュールは動作しません。フックが
SystemUI、通知シェード、Androidサービスの動作を変更するように設計されている場合、NPatchではこれに対処できません。ユーザープロセス内に厳密に存在します。 - 厳格なアンチチートや高度な自己保護（署名の整合性チェック、外部.soファイルの検出など）を持つ一部のアプリは、改ざんを検出して起動時に終了します。
- リポジトリのドキュメントはまだ稀疏です。ほとんどの詳細はプロジェクトのTelegramチャットで議論されており、最新のビルドは多くの場合GitHub Actionsアーティファクトから直接取得する必要があります。
試してみる価値があるか
他社製Androidアプリの内部を定期的に調査したり、デバイスを再フラッシュせずに仮説を素早くテストする必要がある場合は、 npatch.jar をツールボックスに追加してください。このプロジェクトはLSPatchコードベースを最新の状態に保ち、より新しいAndroidバージョンでのアプリ再パッケージを問題なく処理します。
関連プロジェクト