How to Handle Cross-Module APK and .so Analysis in a Single Reverse Engineering Project

Use the routing matrix in zhaoxuya520/reverse-skill to link the apk-reverse skill for unpacking Android packages with radare2 or ida-reverse skills for native library analysis, enabling seamless correlation between Java/DEX and native code layers.

When analyzing Android malware or proprietary applications, security researchers frequently encounter cross-module APK and .so analysis scenarios where high-level Java logic invokes low-level native routines. The zhaoxuya520/reverse-skill repository provides a structured framework that unifies these multi-layer investigations within a single cohesive project, eliminating the friction of switching between disconnected toolchains.

The Routing Matrix Architecture

The foundation of cross-module analysis in this repository is defined in skills/routing.md, which implements a routing matrix that maps asset types to their corresponding analysis modules. According to the source, the matrix lists “APK / Android app → apk-reverse/ … optional JEB cross‑check; if core is in .so → ida‑reverse/ or radare2/”【https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md#L20】.

This routing table enables the same case to be processed by multiple modules without data duplication. When an APK contains native libraries, the workflow explicitly hands off binary assets to specialized reverse engineering tools while maintaining project continuity.

Step-by-Step Cross-Module Analysis Workflow

Unpack and Inspect the APK Layer

Begin every cross-module investigation with the APK layer. Use the apk-reverse skill to unpack the package, decompile Java/DEX code with apktool or jadx, and enumerate all embedded assets.

# Unpack the APK structure

apktool d MyApp.apk -o unpacked/

After extraction, inspect the unpacked/lib/ directory to identify target architectures (e.g., arm64-v8a, armeabi-v7a). Search for shared objects using standard shell utilities:

# Locate all native libraries

find unpacked/ -name "*.so" -type f

Identify and Route Native Libraries

Once you locate .so files, extract their metadata including architecture and exported symbols. The routing matrix explicitly supports transitioning from APK analysis to binary analysis at this stage. Rather than treating the native library as an isolated artifact, the workflow maintains the connection to the parent APK project.

The routing table documents this hand-off capability, ensuring that analysts can route ELF-compatible binaries to either IDA Pro or radare2 without restarting the investigation context【https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md#L20】.

Analyze Native Binaries with radare2 or IDA

Feed the extracted .so files to your chosen binary analysis module. The radare2 skill explicitly supports “apk, dex, …, so” files【https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/radare2/SKILL.md#L23】, making it ideal for Android native library analysis.

# Load the native library with radare2

r2 -AA unpacked/lib/arm64-v8a/libtarget.so

# Inside radare2 prompt:

aa                      # Analyze all functions

afl                     # List all functions

pdf @sym.someNativeMethod # Disassemble specific function

Alternatively, the ida-reverse skill provides GUI-based analysis for the same ELF/Android .so formats, offering advanced de-obfuscation capabilities when handling complex native protections.

Correlate Java and Native Call Sites

The critical step in cross-module APK and .so analysis is mapping native function names back to their Java/DEX call sites discovered during the initial APK unpacking. This correlation allows you to trace security-relevant routines—such as cryptographic implementations or root detection logic—from the native layer back to their invocation points in the Java code.

# Search Smali code for native method declarations

grep -R "nativeMethodName" unpacked/smali/

This bidirectional tracing enables you to verify how input flows from the Android framework into native code and how results return to the Java layer, exposing the complete data flow across the JNI boundary.

Generate Unified Reports

Consolidate your findings using the docs-generator skill, which produces a unified report merging APK static analysis data, Frida/Objection hook results, and native disassembly output. According to skills/docs-generator/SKILL.md#L157, this module ensures the final deliverable reflects the full stack rather than fragmented snapshots.

Complete Cross-Module Analysis Example

The following PowerShell sequence demonstrates the complete workflow from APK extraction through native analysis to final correlation:

# 1. Unpack the APK

apktool d MyApp.apk -o unpacked

# 2. List native libraries by architecture

Get-ChildItem -Recurse unpacked/lib | Where-Object {$_.Extension -eq ".so"}

# 3. Analyze a native library with radare2

r2 -AA unpacked/lib/arm64-v8a/libcrypto.so

# Inside radare2:

# aa      # analyze all

# afl     # list functions

# pdf @sym.someNativeMethod   # disassemble specific function

# 4. Correlate with Java layer

grep -R "nativeMethodName" unpacked/smali

Summary

• Route through the matrix: Use skills/routing.md to direct APK assets to apk-reverse and native .so files to radare2 or ida-reverse without breaking project context.
• Maintain layer correlation: Always map native function addresses back to Java native declarations using Smali grep patterns to preserve the cross-module data flow.
• Leverage unified reporting: The docs-generator skill merges findings from multiple analysis modules into a single coherent document that spans both DEX and ELF analysis.

Frequently Asked Questions

How does the routing matrix determine which module handles .so files?

The routing matrix in skills/routing.md defines explicit file-type-to-module mappings, specifying that APKs route to apk-reverse while ELF/shared objects route to either ida-reverse or radare2 based on analyst preference and tool availability【https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md#L20】.

Can I use both IDA Pro and radare2 in the same cross-module project?

Yes. The routing architecture supports multiple binary analysis modules operating on the same case. You can analyze specific .so files in IDA for interactive debugging while processing others in radare2 for automated scripting, with both sets of results feeding into the unified docs-generator workflow.

How do I trace a specific native function back to its Java caller?

After identifying the native function symbol in radare2 or IDA, search the unpacked Smali directories for the method name using grep -R "methodName" unpacked/smali/. This reveals the JNI registration and invocation points, allowing you to trace data flow across the Java-to-native boundary.

What file formats besides APK and .so does the routing matrix support?

According to the radare2 skill documentation, the framework supports APK, DEX, ELF, SO, DLL, PE, and WASM files【https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/radare2/SKILL.md#L23】, enabling cross-module analysis across Android, Windows, and Linux binary formats within a single project structure.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}