jadx – AndroidのAPKを読みやすいJavaにデコンパイルする

jadxは、Androidアプリのコンパイル済みコードを、人間が読めるJavaに戻すツールです。APKを指定すると、.javaファイルのフォルダとデコード済みのリソースが得られます。GUIでアプリを開けば、コードの検索や宣言へのジャンプ、メソッドの呼び出し元の追跡も可能です。アプリが実際に何をしているのかを知りたいとき、最初に手に取ることの多いツールといえます。ただし、すべてのコードをデコンパイルできるわけではありません。失敗した部分をjadxがどう示すかによって、読んだ内容をどこまで信頼できるかが決まります。

jadxとは

jadxはAndroid向けのオープンソースのデコンパイラです。Javaで書かれ、Apache 2.0ライセンスで公開されており、同じダウンロードにコマンドラインツールとGUIの両方が含まれています。APK、dex、AAB、XAPKなどのパッケージからDalvikバイトコードを読み込み、AndroidManifest.xmlとresources.arsc内のリソースをデコードして、コードをJavaに変換します。通常のJavaバイトコード（jar、class、aarファイル）やsmaliも開けます。名前が1文字に短縮されたアプリ向けには、難読化解除機能も備えています。

つまり、jadxは「読むためのツール」です。不審なアプリのトリアージ、ペネトレーションテストのレポートに必要なエンドポイントやハードコードされた鍵の発見、パッチを当てる必要があるチェック処理の特定などに使えます。一方で、アプリの再構築はできません。再構築にはApktoolが必要で、両者はしばしば併用されます（詳細は後述します）。

プロジェクトは2013年に始まり、現在も活発に開発が続いています。最新リリースは2026年7月10日公開の1.5.6で、10月末にもコミットが入っていました。

jadxのダウンロードとインストール方法

GitHubの各リリースには、3種類のダウンロードが用意されています。jadx-1.5.6.zipは全プラットフォーム共通で、bin配下にjadxとjadx-guiの両ツールが入っています。Windows向けには、それぞれの.bat版も含まれています。動作には64ビットのJava 11以降が必要です。Windows向けの2つのバンドルは、代わりにjadx-gui-1.5.6.exeを実行する形式です。より大きなwith-jreバンドル（99 MB）はJava自体を同梱しているため、JDKのないWindowsマシンではこちらを選ぶとよいでしょう。Macならbrew install jadx、Arch Linuxならsudo pacman -S jadxでインストールでき、Flathubでもcom.github.skylot.jadxとして提供されています。Kaliでもパッケージ化されており、sudo apt install jadxで導入できます。Repologyによると、Kali rolling、Arch、Homebrewはいずれも1.5.6を提供しています。

1.5.6のzipファイルは72,646,741バイトで、公開されているSHA-256は次のとおりです。

展開する前に、PowerShellで次のように確認してください。

jadxは設定とキャッシュをユーザープロファイル内に保存します。これらを作成できない場合、jadxは動作を停止します。筆者がプロファイルのないサンドボックスで実行したところ、デコンパイルはすべて即座に失敗し、「Failed to init common directories」というエラーと、AppData\Roaming\skylotへのアクセス拒否が表示されました。制限の厳しいアカウントや共有アカウントで同じ問題に遭遇した場合は、READMEに記載されている環境変数を使い、2つのフォルダを書き込み可能な場所に指定してください。

コマンドラインでjadxを使ってAPKをデコンパイルする方法

-dで出力先フォルダを指定し、続けてアプリを指定します。展開したフォルダ内で、PowerShellから次のように実行します。

LinuxやMacではbin/jadxを使います。パッケージでインストールした場合は、単にjadxと入力すれば実行できます。実際のアプリで試すため、今回はBinary Eye 1.75.5を使いました。F-Droidで配布されているオープンソースのバーコードスキャナで、Apktoolのガイドでも分解したアプリです。環境はTemurin 21です。jadxは2,539個のクラスを23.6秒で処理しました。

出力は2つのフォルダに分かれます。2,798個のJavaファイルを含むsourcesと、デコード済みのマニフェストやリソースを含むresourcesです。ただし、最終行に注目してください。jadxは「finished with errors, count: 8」と報告し、終了コード1で終了しました。出力自体は完全で、問題なく使えるものでした。起動時に失敗してデコンパイルを一切行わなかったサンドボックスでの実行も、同じく終了コード1でした。そのため、jadxをスクリプトから呼び出す場合、終了コードだけでは両者を区別できません。ログも合わせて確認してください。正常に使えた実行では、進捗カウントが最後まで進んで「finished with errors」で終わっています。失敗した実行は、進捗行が一度も出ないまま、9秒以内に「Process error」で停止しました。

最初から知っておくと便利なオプションがいくつかあります。-s（--no-src）はコードを、-r（--no-res）はリソースをスキップするため、必要な側だけをデコードできます。--single-classは、完全修飾名で指定した1つのクラスだけをデコンパイルします。-jはスレッド数の指定で、デフォルトはCPUスレッド数の半分です。--deobfは短縮されたクラスやメンバーの名前を付け替えます。Binary Eyeでは、R8で名前が変更され、jadxがdefpackageというフォルダに入れていたクラスがp000というフォルダに移動しました。ファイル数は同じです。読みやすい名前はコードを追うときに役立ちますが、あくまでjadxの推測であり、元の名前ではありません。

jadxがメソッドをデコンパイルできない場合の挙動

jadxはコード内に警告を出し、デフォルトでは推測せずにバイトコードを表示します。READMEには、ほとんどの場合jadxはアプリのすべてをデコンパイルできないと明記されています。Binary Eyeでもそのとおりでした。406個のJavaファイルにJADX WARNまたはWARNINGのコメントが1つ以上含まれ、20個のファイルに「Code decompiled incorrectly」と記されたメソッドがあり、12個のファイルにはダンプ自体が省略されたメソッドがありました。

この20個のうち、アプリ自身のコードに含まれるものはありません。アプリ自身のコードとは、de.markusfisch.android.binaryeye配下の86個のJavaファイルのことです。失敗はすべて、AndroidX、Material Components、そしてR8で名前が変更されたクラスにありました。実際の調査対象では、出力をどこまで信頼するかを決める前に、警告がどこにあるかを確認してください。目的のコードはきれいにデコンパイルされ、周囲のライブラリが失敗していることもあれば、その逆もあります。

失敗例の1つとして、AndroidXのInitializationProviderにあるonCreateメソッドを、jadxがデフォルトで出力した状態で示します。

メソッドの本体は残っていますが、コメント内にレジスタとgotoラベルで表現されているため、Javaのふりをしているものは何もありません。コメントには--show-bad-codeが案内されており、このオプションを付けると、同じメソッドが通常のコードのように読めるようになります。

このほうがはるかに追いやすくなり、警告コメントもその上に残ります。jadx自身のヘルプはこれを「inconsistent code（一貫性のないコード）」と呼び、コメントでは「partially-correct（部分的に正しい）」と表現しています。そのため、ロジックの大まかな形をつかむために読み、パッチを当てる予定の条件など、依拠する部分についてはsmaliと照合して確認してください。よくある回避策は、プロジェクトのトラブルシューティングガイドにまとめられています。

APKをGradleプロジェクトとしてエクスポートする方法

-e（--export-gradle）を指定すると、結果をGradleプロジェクトとして出力できます。Android StudioやIntelliJで開けるため、大規模なアプリをIDEの検索やナビゲーション機能で読むには快適な方法です。Binary Eyeの場合、appフォルダと、その横にbuild.gradleおよびsettings.gradleが生成されました。アプリ側のbuild.gradleには、APKから読み取ったパッケージ名、バージョン1.75.5、最小SDK 21、ターゲット37が入力されていました。

ただし、これらのGradleファイルは、第三者が作成したアプリ内の文字列から生成される点に注意してください。IDEでGradleプロジェクトを開くと、ビルドスクリプトが実行される可能性があります。1.5.6のセキュリティ修正の1つは、まさにこの領域を対象にしています。

jadx 1.5.6の変更点

1.5.6のリリースノートは、3件のセキュリティ修正から始まります。jadxは、絶対パスまたはカレントディレクトリへのパスを持つzipエントリを拒否するようになりました。また、エクスポート時にGradleスクリプトへ書き込むすべての文字列値をサニタイズし、サマリーページで欠けていたエスケープ処理も追加しました。リリースノートはこれらを列挙しているだけで、詳細には触れていません。3件とも、アプリ自身の内容がマシンやIDEと接する部分に関わるものです。自分で作成していないアプリを開く機会が多い（この仕事では大半がそうです）場合は、1.5.6へ更新してください。

同リリースでは、GUIにグラフビューが追加され、コードペインもそれに連動して動くようになりました。加えて、GUIの細かな変更と、コールグラフを扱う新しいモジュールも追加されています。

2月公開の1.5.4での変更点も、古いガイドを参考にしている人がつまずきやすいポイントです。スクリプティングプラグインがリリースバンドルに含まれなくなり、jadx-script-kotlinという独立したプロジェクトになりました。インストール手順も別途用意されています。新規にダウンロードしたものに対して.jadx.ktsスクリプトを実行するチュートリアルは、すでに存在しないバンドルを前提に書かれています。現在のjadxは、pluginsコマンドでプラグインを自ら管理します。--availableオプションでインストール可能なものを一覧表示でき、--installで追加できます。

jadx-gui

jadx-gui（Windowsのバンドルでは.exe）を実行し、APKを開きます。READMEによると、シンタックスハイライト付きのデコンパイル済みコード、宣言へのジャンプ、使用箇所の検索、アプリ全体を対象にした全文検索が利用できます。これがjadxの日常的な使い方の中心です。URLやAPI名、アプリの画面に表示される文字列を検索し、見つかった箇所から周辺へ辿っていきます。GUIにはsmaliデバッガも搭載されており、設定方法はプロジェクトのwikiで解説されています。

GUIのデコンパイル方式はコマンドラインと同じです。そのため、失敗したメソッドに関するここまでの説明は、GUIの表示内容にもそのまま当てはまります。

jadxとApktool、その他のデコンパイラの比較

jadxは「読む」ためのツール、Apktoolは「変更する」ためのツールです。Apktoolが出力するのはJavaではなくsmaliで、読みにくい反面、編集の対象となるのはこちらです。編集したフォルダはAPKに再構築できます。一方、jadxのREADMEにはビルド手順の記載がありません。そのため、jadxでロジックを見つけ、Apktoolのsmaliで変更を加え、再構築して署名するという流れが一般的です。

検索ではjadxと並んでJD-GUIも出てきますが、最新リリースの1.6.6は2019年12月のものです。また、jadxはAndroidアプリだけでなく、jarやclassファイルも開けます。当サイトの過去記事では、Androguardが参考になります。Pythonで多数のAPKにまたがる解析をスクリプト化したい場合に向いています。

jadxは次の場所からダウンロードできます。

GitHub上のjadx 1.5.6

詳しくはこちらをご覧ください。

広告