RI APK Reverse vs R2 Mobile Reverse: Keyword Routing Differences Explained

The RI routing ID triggers high-level static analysis of Android packages (APK) using tools like apktool and jadx, while the R2 routing ID invokes radare2 CLI workflows for low-level native binary disassembly and runtime instrumentation.

In the zhaoxuya520/reverse-skill repository, keyword routing patterns defined in skills/MASTER-ROUTING.md direct reverse-engineering tasks to specialized skill modules. The RI APK reverse and R2 mobile reverse patterns represent two distinct abstraction layers: one targeting Java/Dex static analysis and the other targeting native binary inspection via command-line interfaces.

Routing Architecture in MASTER-ROUTING.md

The central routing table maps identifiers to concrete skill implementations. According to the source analysis, the repository defines these entries:

Routing ID	Keyword Pattern	Target Skill Folder	Core Toolchain
RI	apk-reverse	skills/apk-reverse/	apktool, jadx, apk-signer, frida-gadget
R2	mobile-reverse	skills/mobile-reverse/	radare2 (r2), frida, objection, MobSF

The RI identifier routes requests focused on Android application packages (APK files) to the static analysis pipeline. The R2 identifier—where R2 explicitly stands for radare2—routes requests to the mobile reverse workflow designed for binary-level inspection of native libraries (.so files) and runtime analysis.

RI APK Reverse: Static Android Package Analysis

The RI pattern handles high-level Android security assessment and modification workflows. As documented in skills/apk-reverse/SKILL.md, this pattern emphasizes decompilation, manifest inspection, and rebuilding.

Typical workflow:

1. Unpack the APK using apktool to extract Smali code and resources.
2. Decompile DEX bytecode to Java with jadx for source-level review.
3. Inspect AndroidManifest.xml for permissions, exported components, and deep links.
4. Re-sign modified packages using apksigner after patching.

This pattern relies on frida-gadget for static instrumentation (embedding the gadget into the APK) rather than dynamic runtime attachment. The security checklist in skills/apk-reverse/references/apk-security-checklist.md aligns with OWASP MASTG standards for static vulnerability scanning.

R2 Mobile Reverse: Native Binary and Runtime Analysis

The R2 pattern targets native binaries extracted from mobile applications. As implemented in skills/mobile-reverse/SKILL.md, this workflow uses the radare2 CLI as its primary engine for disassembly and debugging.

Typical workflow:

1. Extract native libraries (*.so) from the APK or IPA using standard archive tools.
2. Load the binary into radare2 (r2 -A libnative.so) for automated analysis.
3. Disassemble functions (pdf), analyze control flow (agf), and search for dangerous patterns (/c "strcpy").
4. Instrument runtime behavior using frida or objection to bypass SSL pinning or trace JNI calls.

The R2 pattern is essential for analyzing obfuscated native code, identifying buffer overflows in C/C++ components, and manipulating application behavior at the binary level. Deep instrumentation guides are located in skills/mobile-reverse/references/frida-objection-deep.md.

Key Differences in Scope and Tooling

Abstraction Level

• RI APK Reverse operates on the APK container as a whole, focusing on Java/Dex layers, XML manifests, and resource files.
• R2 Mobile Reverse operates on extracted ELF binaries (.so files) and raw memory structures, requiring knowledge of assembly and calling conventions.

Primary Use Cases

• RI: Permission enumeration, hardcoded secret discovery in Java code, rebuilding applications after modification.
• R2: Native library reverse engineering, packer/unpacker analysis, runtime hooking of JNI functions, and low-level vulnerability exploitation.

Instrumentation Model

• RI: Static pre-instrumentation via frida-gadget embedded during the rebuild phase.
• R2: Dynamic runtime instrumentation via frida attached to running processes or scripted within radare2 using r2frida.

Practical Implementation Examples

RI APK Reverse workflow (Static decompilation and re-signing):

# Unpack APK resources and Smali

apktool d target.apk -o unpacked_apk

# Decompile DEX to readable Java

jadx -d java_src unpacked_apk/classes.dex

# Inspect permissions and exported activities

grep "android.permission" unpacked_apk/AndroidManifest.xml

# Rebuild and re-sign after modifications

apktool b unpacked_apk -o modified.apk
apksigner sign --ks release.jks modified.apk

R2 Mobile Reverse workflow (Native binary analysis with radare2):

# Extract native libraries from the APK

unzip target.apk "lib/arm64-v8a/*.so" -d native_libs/

# Load library into radare2 with full analysis

r2 -A native_libs/lib/arm64-v8a/libtarget.so

# Inside radare2 shell:

[0x00001000]> aaaa          # Complete analysis

[0x00001000]> afl ~crypto   # List functions matching "crypto"

[0x00001000]> pdf @ sym.Java_com_example_nativeFunc  # Disassemble JNI function

[0x00001000]> /c "strcmp"   # Search for dangerous string comparisons

[0x00001000]> :!frida -U -f com.example.app -l ssl_bypass.js  # Attach Frida

Summary

• RI APK reverse routes to skills/apk-reverse/ for high-level Android static analysis using apktool and jadx, focusing on Java code and manifest inspection.
• R2 mobile reverse routes to skills/mobile-reverse/ for low-level native analysis using radare2, targeting ARM/x86 binaries and runtime instrumentation via frida.
• The distinction is encoded in skills/MASTER-ROUTING.md, separating container-level (APK) workflows from binary-level (ELF) workflows.
• RI workflows end with re-signing modified APKs, while R2 workflows culminate in dynamic tracing or binary patching.

Frequently Asked Questions

What does the R2 routing ID specifically refer to?

According to the repository's routing definitions, R2 explicitly designates the radare2 command-line analysis framework. This routing ID invokes the skill set located in skills/mobile-reverse/, which relies on r2 for disassembly, debugging, and scripting against native mobile binaries.

Which pattern should I use for inspecting AndroidManifest.xml permissions?

Use the RI APK reverse pattern. This routing targets the skills/apk-reverse/ module, which unpacks the APK container and exposes AndroidManifest.xml for static inspection of permissions, intent filters, and component exports using standard static analysis tools.

Can RI and R2 workflows be combined on the same target application?

Yes. A comprehensive assessment typically begins with RI to decompile the application and extract Java-layer logic, followed by R2 to analyze any packed native libraries (.so files) extracted during the initial unpacking phase. The architecture diagram in docs/ARCHITECTURE.md illustrates how these paths can interoperate.

Where are the security checklists for each pattern stored?

Static security checklists for the RI pattern are located at skills/apk-reverse/references/apk-security-checklist.md (OWASP MASTG aligned), while runtime instrumentation guides for the R2 pattern are stored at skills/mobile-reverse/references/frida-objection-deep.md.

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