Android APK Reverse Engineering: From JADX to Frida, Ghidra and ART

Android APK reverse engineering is more than simply decompiling Java code.

A modern APK may contain DEX, Smali, SO libraries, JNI interfaces, encrypted code, runtime loaders, and protection mechanisms. To understand how an application actually works, static analysis and dynamic analysis need to be combined.

This article introduces a practical workflow using JADX, Apktool, Frida, Ghidra/IDA, DEX, SO, and ART.

---

1. Understand the APK Structure

An APK is essentially a ZIP package. After extracting it, you will commonly find:

AndroidManifest.xml
classes.dex
classes2.dex
resources.arsc
res/
assets/
lib/
META-INF/

Native libraries are usually located under:

lib/arm64-v8a/
lib/armeabi-v7a/

A simple mental model is:

APK
├── Java / Kotlin → DEX
├── Native        → SO
├── Resources
└── Manifest / Signature

---

2. JADX: The First Static Analysis Tool

JADX is commonly used to decompile DEX files into Java-like code.

jadx app.apk

It is useful for quickly finding:

• Activities
• Services
• Network logic
• Encryption functions
• Native methods
• Important business logic

However, JADX output is not the original source code.

Obfuscation, R8, Kotlin features, native code, and application protection can significantly affect the decompiled result.

---

3. Apktool and Smali

Jadx is mainly for understanding code, while Apktool is useful for APK resources, Manifest files, and Smali.

apktool d app.apk -o app_out

You may get:

app_out/
├── AndroidManifest.xml
├── smali/
├── smali_classes2/
├── res/
└── assets/

Smali is a low-level representation of DEX instructions.

For example:

const/4 v0, 0x1
return v0

is essentially:

v0 = 1
return v0

JADX helps understand the overall logic, while Smali helps verify the actual implementation.

---

4. From DEX to Native SO

During analysis, you may encounter:

public native boolean verify(String data);

or:

System.loadLibrary("xxx");

This usually means that part of the logic is implemented in a native library:

Java / Kotlin
      ↓
     JNI
      ↓
   C / C++
      ↓
      SO

At this point, tools such as Ghidra or IDA become useful.

Important areas to investigate include:

JNI_OnLoad
RegisterNatives
Exports
Imports
Strings
Functions

---

5. Frida: Dynamic Analysis

Static analysis tells us what code looks like.

Dynamic analysis tells us what actually happens at runtime.

Frida can be used to observe application behavior, including:

Method calls
Parameters
Return values
Java ↔ Native interaction
Runtime behavior

A typical workflow is:

JADX / Apktool
       ↓
Find interesting logic
       ↓
Frida
       ↓
Observe runtime behavior
       ↓
Ghidra / IDA
       ↓
Analyze Native code

This combination is much more effective than relying on a single tool.

---

6. Why Does APK Protection Make Analysis Harder?

A normal application may roughly follow:

DEX
 ↓
ClassLoader
 ↓
ART
 ↓
Execution

A protected application may instead use:

Protected APK
      ↓
   Loader / Shell
      ↓
Runtime restoration
      ↓
   Real DEX / Code
      ↓
   ClassLoader
      ↓
      ART

This is why a protected APK may expose very little useful business code through JADX.

From a research perspective, the important question is not simply "Where is the DEX?", but:

When is the code restored, how is it loaded, and where does it finally execute?

---

7. DEX Protection, SO Protection and VMP

Android protection can operate at several layers.

DEX Protection

Common approaches include:

DEX Encryption
DEX Packing
Class Encryption
Runtime Loading
VMP

SO Protection

Native protection may involve:

ELF Protection
Symbol Stripping
Code Encryption
Integrity Checks
Runtime Decryption

VMP

Virtualization protection converts code into virtual instructions and executes them through a custom virtual machine:

Original Code
     ↓
Virtual Instructions
     ↓
Virtual Machine
     ↓
Interpreter
     ↓
Execution

This can make static control-flow and code analysis considerably more complicated.

---

8. ART Is the Key to Understanding Modern Android Protection

If you want to go deeper into Android protection, eventually you need to understand ART (Android Runtime).

A simplified execution path is:

DEX
 ↓
ClassLoader
 ↓
DexFile
 ↓
Class
 ↓
Method
 ↓
ART
 ↓
JIT / AOT / Execution

Android versions continuously evolve, so protection mechanisms that depend heavily on ART internals may require significant compatibility work across Android releases.

---

9. A Practical Learning Path

A good learning sequence is:

APK Basics
    ↓
JADX
    ↓
Apktool / Smali
    ↓
DEX
    ↓
JNI
    ↓
Ghidra / IDA
    ↓
Frida
    ↓
ART
    ↓
DEX / SO Protection
    ↓
VMP / RASP

The goal is not to memorize tools, but to understand the complete chain:

Where is the code?
       ↓
How is it loaded?
       ↓
When is it restored?
       ↓
How does it execute?
       ↓
How can it be protected?

---

Conclusion

Android APK reverse engineering is essentially a combination of static analysis, dynamic analysis, Native analysis, and runtime research.

JADX and Apktool provide the starting point. Smali helps understand DEX at a lower level. Frida provides runtime visibility, while Ghidra/IDA opens the door to Native and ARM64 analysis.

Once DEX, SO, JNI, ClassLoader, and ART are connected together, it becomes much easier to understand both APK reverse engineering and modern Android application protection.

The core chain is:

APK
 ↓
DEX
 ↓
ClassLoader
 ↓
ART
 ↓
JNI
 ↓
SO
 ↓
Native
 ↓
Runtime