Androidのリバースエンジニアリングの進め方/やり方/流れや方法/手法/工程/手順

Androidのリバースエンジニアリングは、まず解析の目的と対象を決め、解析環境を整えるところから始まります。

そのうえで、静的解析と動的解析を組み合わせてアプリの中身を読み解き、設計や仕様に置き換えて成果物にまとめます。

▼全体ガイドの記事
・Androidのリバースエンジニアリングの完全ガイド

スマホアプリ開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。

Androidのリバースエンジニアリングの定義とAndroid固有の特性

Androidのリバースエンジニアリングとは、APK形式で配布されたAndroidアプリを逆方向に解析し、その内部構造・ロジック・仕様を明らかにする行為を指します。iOSなど他のプラットフォームとは異なるAndroid固有の技術特性を理解することが、解析を進める第一歩になります。

APKとDalvik/ART：Androidアーキテクチャの基礎

AndroidアプリはAPK（Android Package）という圧縮ファイル形式で配布されます。APKの中には、JavaコードがコンパイルされたDEX（Dalvik Executable）ファイルが格納されており、このDEXはDalvikまたはART（Android Runtime）という仮想マシン上で動作します。

iOSのネイティブバイナリ（ARM機械語）と違い、DalvikバイトコードはSmaliという中間アセンブリ言語に変換できます。さらに、APKToolやjadx、Procyonといった逆コンパイラを使えば、ほぼ元のJavaコードに近い形で復元できる点が大きな特徴です。APKを解析するときは、次の順で進めます。

1. 展開：APKToolでAPKファイルを展開し、Smali形式の中間コードとリソースファイルを取り出す
2. 逆コンパイル：jadxやProcyonでSmaliをJavaコードに変換し、開発者が当初書いたロジックに近い状態のコードを読めるようにする

こうした特徴から、AndroidはiOSに比べて解析の敷居が低く、オープンソースの開発者向けツールが豊富に揃っています。そのため、社内エンジニアが自力で対応できる場面も少なくありません。

主な用途：セキュリティ診断・仕様復元・ROM解析

Androidのリバースエンジニアリングは、セキュリティ診断、仕様の復元、組み込み機器のROM解析に使われます。

• セキュリティ診断：ISO 27001などのセキュリティ基準への適合を求められる企業で、自社アプリの脆弱性診断として使われる場面が最も多い
• 仕様書の復元：開発担当者が退職してドキュメントが失われた社内Androidアプリについて、APK解析でロジックを読み解き、設計書を再構築する
• カスタムROM解析：特殊なニーズとして、AOSPを利用した組み込みAndroid機器（産業用端末、医療機器、POS端末など）のファームウェアを解析する

セキュリティ診断は、平文での通信内容の確認、隠蔽されたAPIキーの検出、セッション管理の不備の発見などを目的に行われます。

組み込み機器のファームウェアを解析すると、機器の動作仕様を理解したり、セキュリティ上の問題点を洗い出したりできます。Binwalkを使ってSPIフラッシュから抽出したバイナリを解凍し、PEM DSA秘密鍵やOpenSSH公開鍵を直接発見した事例もあります。こうした例のように、Android/Linux系の組み込み機器の解析でも、類似した手法が有効に機能します。

Androidのリバースエンジニアリング6工程

Androidのリバースエンジニアリングを成功させるには、目的に合わせて工程を計画的に管理することが欠かせません。解析の開始から成果物の完成まで、実務で繰り返し確認されてきた標準的な進め方は、次の6工程です。

1. 工程1：対象の選定と目的の明確化
2. 工程2：解析環境とAndroid特化ツールの準備
3. 工程3：逆コンパイルとコードの静的解析
4. 工程4：デバッガと実行トレースによる動的解析
5. 工程5：実装から設計・仕様への抽象化
6. 工程6：仕様書や新システム設計書の作成

工程1：対象選定・目的の明確化

最初に、「何のためにリバースエンジニアリングを行うのか」を明確にします。自社アプリのセキュリティ診断なのか、仕様書が失われた社内アプリの設計復元なのか、カスタムROM機器の動作確認なのかによって、必要なツールも解析の深度も大きく異なります。

目的が曖昧なまま着手すると、解析範囲が際限なく広がり、工数が膨張するリスクがあります。着手前には、次の2点を確認することが必須です。

• 対象の権利関係：対象APKが自社の著作物かどうか
• 解析目的の適法性：解析目的が著作権法第30条の4の「非享受目的」（マルウェア解析・セキュリティ調査・仕様書復元など）に当たるか

平成30年の著作権法改正で、これらの目的でのリバースエンジニアリングは原則合法となりました。ただし、EULAの禁止条項や不正競争防止法に抵触するリスクは残ります。

このため、解析目的と法的根拠を文書にまとめてから作業を始めることが、後のトラブル回避につながります。

工程2：解析環境・ツール準備

Android解析では、APKの展開、逆コンパイル、動的解析、通信解析の段階ごとに、専用のツールを揃えます。

• APKの展開・再パッケージ：APKTool
• 逆コンパイル：SmaliをJavaに変換するjadxまたはProcyon、Java用逆コンパイラのCFR
• 動的解析：Frida（動的計装フレームワーク）、Burp Suite（通信傍受プロキシ）
• 通信解析の環境：ネットワーク通信を解析する場合に、Androidエミュレータ上でMITMプロキシを設定する構築作業

解析環境は、必ず隔離されたサンドボックス（専用の仮想マシンやエミュレータ）上に構築してください。本番端末での解析作業は避けるべきです。

また、解析過程をスクリーンショットやログファイルとして記録しておくと、後で「非享受目的であった」ことを証明する根拠資料になります。特に大規模な解析では、この記録が欠かせない実務上の慣行です。Pythonスクリプトで4,096バイトずつ分割してファームウェアを200万バイトのプレーンテキスト化した事例でも、その重要性が実証されています。

工程3：静的解析（逆コンパイル・コード読解）

APKToolでAPKを展開した後、DEXファイルをjadxで逆コンパイルし、Javaコードを取得します。最新のjadxは精度が高く、ほぼ元のJavaコードに近い形で復元できます。

ただし、ProGuardによる難読化が施されたアプリでは、クラス名がa、b、cのような意味の分からない単文字に、メソッド名もa1、b2のようなランダムな名称に置き換えられています。そのため、復元コードは可読性が著しく低下します。

ProGuardはAndroidアプリ開発で標準的に使われる難読化ツールです。このため、静的解析だけで完全なロジックを理解しようとせず、次の動的解析と組み合わせて進めることが欠かせません。静的解析では、次の箇所を順に確認します。

• マニフェストの宣言：AndroidManifest.xmlに宣言されたパーミッションとコンポーネント構成
• 攻撃対象領域（アタックサーフェス）：エクスポートされたActivity/Service/BroadcastReceiverから把握する
• ハードコードされた情報：Stringsファイルやres/rawディレクトリに残る認証情報・APIキー・エンドポイントURL

これらの発見だけで、セキュリティ診断の主要な知見が得られることも多く、費用対効果の高いアプローチです。

工程4：動的解析（デバッガ・実行トレース）

動的解析は、アプリを実際に実行しながら、その挙動をリアルタイムで観察する手法です。Fridaを使えば、実行中のAndroidアプリのメソッドにフックを仕掛け、引数や戻り値を取得したり、ロジックを書き換えたりできます。

ProGuardで難読化されたコードでも、実行時には実際のクラス名とメソッドが復元されています。このため、Fridaのフックと静的解析で得たSmaliコードを組み合わせれば、難読化を「迂回」した解析が実現できます。

ネットワーク通信を解析するには、Burp Suiteで端末の通信を傍受し、HTTPS通信の内容を読み取ります。ただし、Android 7.0以降はネットワークセキュリティ設定によってユーザー証明書の信頼が制限されるため、傍受には追加の準備が必要になる場合があります。

• CA証明書の導入：AndroidエミュレータにBurp SuiteのCA証明書をインストールし、HTTPS通信を復号・傍受する
• 把握できる内容：APIの通信仕様・認証フロー・データ構造
• 信頼制限への対処：root化またはAPKの再パッケージが必要な場合がある

動的解析は、静的解析で理解しきれなかった処理フローを補完する強力な手法です。なお、実際の通信を伴う解析は、必ず適切な許可のもとで実施してください。

工程5：抽象化（Design Recovery：実装→設計→仕様）

静的解析と動的解析で得た情報を統合し、実装レベルの知識を設計・仕様のレベルへ段階的に抽象化する工程が、Design Recoveryです。

具体的には、次の図を作ります。

• クラス図：逆コンパイルしたJavaコードのクラス間の依存関係を整理して作成する
• シーケンス図：メソッドの呼び出し関係から起こす
• Activity遷移図・ステートマシン図：状態遷移を整理して作る

難読化で変数名やクラス名が意味不明になっていても、実際の動作と照合すれば、ビジネスロジックの意味を推定できます。ただし、「コードがどう動くか（How）」はリバースエンジニアリングで復元できますが、「なぜその仕様なのか（Why）」は元の開発者や業務部門の担当者でなければ分からないケースが多くあります。

この点が、リバースエンジニアリングの本質的な限界です。そのため、業務システムの仕様復元では、元の担当者や業務ユーザーへのヒアリングをDesign Recoveryと並行して進めることが成功の鍵となります。

工程6：仕様書・新システム設計書の作成

解析で得た知見は、成果物として文書にまとめます。成果物の粒度は、目的によって大きく異なります。

セキュリティ診断と仕様書の復元では、作る文書の中身が違います。

• セキュリティ診断：脆弱性レポートと対策提案書
• 仕様書の復元：画面遷移図・DB設計・API仕様書・業務フローチャートといった、詳細設計書レベルの文書群

単なるフローチャートの提供にとどまるか、新システム開発に直接使える詳細設計書まで作るかによって、費用と工数が大きく変わります。そのため、発注前に成果物の粒度を明確に合意しておくことが欠かせません。

成果物の評価基準には、「変換後コードの保守性」も含めるべきです。逆コンパイルで復元したコードは、ProGuardの難読化を解除した後も変数名が意味不明のままであることが多く、そのままでは若手エンジニアが保守できる品質になりません。

ベンダーに外注する場合は、変数名の再命名・コメント付与・業務ロジックの背景説明（Why）のドキュメント化を、成果物要件に明示的に含めることを強く推奨します。

Android固有の注意点と典型的な失敗パターン

Androidのリバースエンジニアリングには、プラットフォーム固有のハードルがあります。事前にリスクを把握しておけば、プロジェクトの失敗を未然に防げます。

典型的な失敗パターン3選

失敗が起きやすいのは、難読化の見積もり、解析手法の偏り、ストア規約の確認の3点です。

• 難読化の過小評価：最も多い失敗パターン
• 静的解析だけで完結させる：動的解析を組み合わせないまま進めるケース
• Play Storeポリシーの確認不足：Google規約との整合性を確かめないケース

ProGuardはAndroid Studioに標準搭載された難読化ツールで、リリース版APKには高い確率で難読化が施されています。難読化の解除には相応の工数がかかるため、見積もり段階で有無と深度を確認せずに固定価格で契約すると、後から工数が大幅に膨らむトラブルにつながります。

特に、実行時に動的に生成されるコードやReflection APIを多用するアプリでは、静的解析だけで全体像を把握できません。Fridaを用いた動的解析と組み合わせて、初めて正確な理解が得られます。しかし、動的解析環境の構築に慣れていないチームは、静的解析のみで報告書を作成してしまうことがあります。

Play Storeは「他のアプリの解析・改変」を明示的に制限しています。そのため、他社アプリを商業目的で解析する場合は、これらのポリシーとの整合性を法務担当者と事前に確認することが必須です。

難読化・暗号化への対処法

ProGuardによる基本的な難読化は、jadxの最新版でほぼ解除できます。ただし、より強力な商用難読化ツール（DexGuard、Guardsquare等）が使われていると、解除の難度が跳ね上がります。

強固な難読化には、静的解析での完全な復元を諦め、動的解析で実際の挙動を観察するアプローチに切り替えるのが現実的です。

ネイティブコード（NDK経由のC/C++ライブラリ）が組み込まれているアプリでは、DEXの逆コンパイルだけでは不十分です。.soファイルとして格納されたネイティブライブラリの解析には、バイナリ解析ツールが必要になり、よく使われるのはGhidraとIDA Proです。

• Ghidra：米国NSAが開発したオープンソースの逆アセンブラで、無償で利用できます
• IDA Pro：Ghidraと並んで挙げられるバイナリ解析ツール

コストを重視するなら、まずGhidraから試すことをお勧めします。また、チーム複数名で協調して解析プロジェクトを進める場合は、Ghidraのプロジェクト共有機能が特に有効です。

法的リスクの回避：クリーンルームと非享受目的の実務

Androidのリバースエンジニアリングには、iOS以上に法的なグレーゾーンが生じやすい面があります。オープンな開発環境でツールが揃っている一方で、不適切に使うと、著作権法・不正競争防止法・Play Storeポリシーという複数の法令に同時に抵触するおそれがあります。

クリーンルーム手法の実務的運用

クリーンルーム手法とは、解析を担当するチーム（Dirty Room）と、新たな実装を担当するチーム（Clean Room）を完全に分けるアプローチです。両チームの間には法務・仲介担当者を置き、著作権侵害の「依拠性」を回避します。

1980年代のフェニックス・テクノロジーズ対IBM BIOS訴訟の判例で、その有効性が確立されました。現在も大規模なリバースエンジニアリングプロジェクトでは、標準的な法的防衛手法として採用されています。

Androidプロジェクトでの実務的な運用は、次の順で進みます。

1. 仕様書の作成：解析チームがAPKを解析し、仕様書にまとめる
2. 法務レビュー：法務担当者が、著作権保護対象の「表現」（具体的なコードの記述）が混入していないかを確認する
3. 実装：開発チームが元のAPKを一切見ずに、法務チェック済みの仕様書だけを基に新たな実装を行う

手順を踏めば、競合他社のAndroidアプリと機能互換を持つ製品を、著作権侵害なく開発することが法的に認められています。

非享受目的での記録方法と立証準備

著作権法第30条の4は、「著作物を享受することを目的としない利用」を原則として合法としています。セキュリティ診断やマルウェア解析、仕様書の復元、機械学習のデータ収集などが、その典型例とされています。

しかし、将来の法的紛争に備えるには、次のとおり準備しておくことが重要です。

• 解析目的：事前に文書にまとめる
• 解析環境：専用の環境を用意する
• 解析過程：レポートや作業ログとして残す

記録には、「この解析はセキュリティ診断目的であり、アプリのコンテンツを享受・利用するためではない」という事実を、客観的に立証できる形で残しておくことが肝心です。

EULAに「リバースエンジニアリング禁止」の条項が含まれていても、互換性（インターオペラビリティ）の確保にリバースエンジニアリングが不可欠なケースがあります。その場合、当該条項は独占禁止法上の「不公正な取引方法（拘束条件付取引）」に該当し、無効となる可能性があります。

ただし、この判断には専門的な法的分析が必要です。そのため、外部弁護士への事前相談を強く推奨します。

外注 vs 内製の判断軸：Androidならではの考え方

Androidのリバースエンジニアリングは、他のプラットフォームと比べて解析ツールが充実しています。そのため、社内エンジニアが内製で対応できる範囲も広いのが特徴です。一方で、プロジェクトの目的・規模・難読化レベルによっては、外注が合理的な選択になる場合もあります。

社内対応が適するケース

自社開発のアプリや機器が対象であれば、社内エンジニアだけで解析を進められる場合があります。

• 自己診断：自社開発のAndroidアプリを定期的にセキュリティ自己診断する
• カスタムROM機器の解析：AOSPを活用した自社カスタムROM機器の解析
• 仕様書の整備：自社開発アプリのアーキテクチャ理解を目的とした仕様書の整備

APKTool・jadx・Fridaは、いずれも無償で利用できます。Androidアプリ開発の経験があるエンジニアであれば、比較的短期間で習得できます。

自動ツールによる診断（MobSF等のモバイルセキュリティフレームワーク）を使えば、10〜30万円程度のコストで網羅的なチェックが可能です。自社アプリの難読化レベルを把握したうえで、既知のリスクを定期的に確認する目的であれば、内製対応が最も費用対効果の高い選択です。

内製対応では、対象の業務知識をもつ社内エンジニアが主体的に関わることで、「Why（なぜその仕様か）」の理解と「How（どう動くか）」の解析を一体で進められる利点があります。

外注が必要になるケースと選定基準

外注が推奨されるのは、次のような場合です。

• 強力な難読化：DexGuard等の商用難読化が施されていて、内製チームでは解除が困難な場合
• 高難度のアプリ：ネイティブコード（NDK）を多用したアプリの解析が必要な場合
• 客観的な診断：監査・認証取得などで、第三者機関によるセキュリティ診断レポートが必要な場合
• 大規模な業務システム：詳細仕様書を復元し、モダナイゼーションにつなげる場合

手動診断（標準）では50〜150万円、モバイルアプリの高精度診断では50〜250万円程度が相場となっており、目的に応じた適切な規模感での発注が重要です。

外注先の選定では、まずAndroidアプリの解析実績（特にProGuard難読化解除の経験）と、クリーンルーム手法を自社のプロセスとして運用できる体制を見ます。そのうえで、法務・仲介担当者の配置の有無と、成果物として「保守性の高い仕様書」を提供できるかを確かめてください。

セキュリティ専門企業と業務システムSIerでは、得意な領域が異なります。そのため、解析目的がセキュリティ診断であればセキュリティ専門企業を、仕様書の復元やモダナイゼーションであれば業務システムSIerを優先して選ぶことをお勧めします。

まとめ

Androidのリバースエンジニアリングは、APK（DalvikバイトコードおよびARTバイトコード）という中間言語形式のおかげで、iOSや他のプラットフォームと比べて解析ツールが豊富です。APKTool・jadx・Fridaを組み合わせれば、ほぼ元のJavaコードを復元できます。

一方で、ProGuardによる難読化が標準的に施されているため、復元コードの変数名やクラス名は意味を持たないことが多くあります。そのため、静的解析と動的解析を補い合うアプローチが不可欠です。

6工程（目的明確化→ツール準備→静的解析→動的解析→Design Recovery→成果物の作成）を計画的に進めます。法的リスクには、クリーンルーム手法と非享受目的の記録管理で対応します。その結果、適法かつ有益なリバースエンジニアリングのプロジェクトを実現できます。

内製か外注かは、解析目的・難読化レベル・社内エンジニアの習熟度の3点で判断します。外注する場合は、成果物の保守性まで含めた仕様書を発注前に明確にしておくことが、成功の鍵です。

▼開発を相談する前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。