1. JADX

JADX is the gold standard for decompiling Android APKs into readable Java source code. The GUI version (jadx-gui) lets you navigate the decompiled source, search for strings and method calls, and cross-reference code.

What makes JADX stand out is its accuracy. Other decompilers produce unreadable output for complex apps. JADX handles obfuscated code significantly better.

# Decompile an APK to source
jadx -d output_dir/ target.apk

# Search for hardcoded secrets
jadx -d output/ target.apk
grep -r "api_key\|password\|secret\|token" output/

2. apktool

Where JADX gives you decompiled Java, apktool gives you smali bytecode — the intermediate representation Android actually runs. More important for tasks like modifying and repackaging APKs, or analyzing code that JADX mishandles.

Use apktool to: decode resources and the manifest, modify app behavior by patching smali, rebuild signed APKs for dynamic testing.

apktool d target.apk -o decoded/
# Modify smali files, then rebuild:
apktool b decoded/ -o modified.apk

3. Ghidra

Ghidra is the NSA’s open-source reverse engineering framework and the primary free tool for analyzing Android native libraries (.so files). When you need to understand what a JNI function actually does at the assembly level, this is your tool.

The Android-specific workflow: extract .so files from the APK, load them in Ghidra, identify JNI exported functions (they start with Java_), and follow the code.

# Extract native libraries from APK
unzip target.apk -d extracted/
ls extracted/lib/arm64-v8a/*.so

4. Frida

Frida is essential. It lets you inject JavaScript into running Android processes to hook functions, modify return values, dump memory, and bypass security controls at runtime. Every professional Android security researcher knows Frida.

Key capabilities: SSL pinning bypass, root detection bypass, function interception, memory reading/writing, native function hooking.

# Basic function hook
Java.perform(function() {
    var SSLContext = Java.use("javax.net.ssl.SSLContext");
    SSLContext.init.overload(
        "[Ljavax.net.ssl.KeyManager;",
        "[Ljavax.net.ssl.TrustManager;",
        "java.security.SecureRandom"
    ).implementation = function(km, tm, sr) {
        this.init(km, null, sr); // bypass cert validation
    };
});

5. Objection

Objection is a Frida-based runtime mobile exploration toolkit. Think of it as “Frida with a command-line interface for common tasks.” It automates SSL pinning bypass, root detection bypass, file system enumeration, and activity launching without writing a single line of Frida script.

Essential for initial assessment of a target app before writing custom instrumentation.

objection -g com.target.app explore
# Inside objection:
android sslpinning disable
android root disable
android hooking list activities

6. Burp Suite

Burp Suite is the standard for intercepting and modifying mobile app HTTP/HTTPS traffic. Set up the proxy, route device traffic through it, and you see every API call the app makes — headers, bodies, authentication tokens.

For Android, the standard workflow involves: configuring the device Wi-Fi proxy to point at Burp, installing the Burp CA certificate on the device, and using Objection or a custom Frida script to bypass certificate pinning when apps implement it.

7. MobSF (Mobile Security Framework)

MobSF automates static and dynamic analysis for Android and iOS apps. It is not a replacement for manual analysis — automated scanners miss most serious vulnerabilities — but it is excellent for getting a rapid overview of a new target and identifying low-hanging fruit.

Use it at the start of an assessment to build an initial picture, then follow up manually on the areas it flags.

8. AFL++ (American Fuzzy Lop++)

AFL++ is the state-of-the-art coverage-guided fuzzer. For Android native library research, you use it to automatically feed malformed inputs to native code and find crashes. Those crashes are potential vulnerabilities.

AFL++ for Android requires writing a harness: a small C program that calls the target function with fuzzer-generated input. Once set up, it can run for hours automatically discovering new crash inputs.

This is the tool used to discover many high-severity Android CVEs, including memory corruption vulnerabilities in media parsers and image decoders.

# Basic AFL++ fuzzing loop
afl-fuzz -i input_corpus/ -o findings/ \
  -m none -- ./harness @@

9. Djini.ai

Djini.ai is the newest category: AI-autonomous vulnerability discovery for Android and iOS. Instead of manually writing fuzzing harnesses and analyzing crashes, Djini uses autonomous AI agents to execute real app flows, trigger edge cases, and identify exploitable vulnerabilities — with minimal setup.

Key capabilities: agentic runtime testing (AI executes real app flows), native surface fuzzing (automated blackbox fuzzing for memory corruption), and automated PoC generation for confirmed vulnerabilities.

For penetration testers and bug bounty hunters, the AppSec Bundle (€150/month) automates the tedious parts of mobile assessment and focuses researcher time on the findings that actually matter.

Learn more about Djini.ai →

10. GDB / LLDB with pwndbg

When AFL++ or Djini finds a crash, you need a debugger to understand exactly what went wrong. GDB with the pwndbg extension (or LLDB on iOS) is the standard.

The workflow: reproduce the crash under the debugger, inspect registers and memory at the crash point, determine the root cause (out-of-bounds write, use-after-free, etc.), and assess exploitability.

# Attach GDB to Android process
adb forward tcp:1234 tcp:1234
gdbserver :1234 --attach $(pidof target_process)
# Then on host:
gdb-multiarch target.so
target remote :1234