android-reverse-engineering

Android Reverse Engineering

Decompile Android APK, XAPK, JAR, and AAR files using jadx and Fernflower/Vineflower, trace call flows through application code and libraries, produce structured documentation of extracted APIs, and escalate to runtime analysis only after static triage shows that it is needed. Two decompiler engines are supported: jadx for broad Android coverage and Fernflower/Vineflower for higher-quality output on complex Java code.

Core Principle

Do not jump straight into Frida, packet capture, or SO analysis. Start with JADX and identify:

• The network stack in use
• The request builder or interceptor chain
• Where signing or encryption appears to happen
• Whether the logic is visible in Java or delegated to native code

Use dynamic analysis only to confirm or bridge gaps that static analysis cannot resolve.

When to Suggest IDA MCP

IDA MCP provides static binary analysis (disassembly, decompilation, cross-references) for .so files. Do NOT suggest it blindly — check these conditions first:

Suggest IDA MCP when the user asks to:

• Find function offsets or exports in a specific SO
• Decompile a known native function to C pseudocode
• Trace cross-references to a string, symbol, or address
• Check whether a SO imports crypto/network libraries
• Analyze a SO that is NOT obfuscated (standard compiler, recognizable function boundaries)

Do NOT suggest IDA MCP when:

• The SO uses control-flow flattening or similary heavy obfuscation — pseudocode will be unreadable. Use Frida scripts instead.
• All strings in the SO are encrypted — static search finds nothing. Use jni_method_trace.js to capture runtime decryption.
• The user needs runtime values (keys, tokens, parameters, decrypted data) — IDA can only show static code.
• The target SO has not yet been identified — suggest jni_method_trace.js first to find which SO handles the logic.
• The user needs to compute or generate a signature, ciphertext, or token — this requires runtime execution, not static analysis.