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

> Understand RI APK reverse vs R2 mobile reverse keyword routing differences. Explore static analysis for APKs and low-level binary analysis with radare2.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-28

---

**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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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):

```bash

# 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):

```bash

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/mobile-reverse/references/frida-objection-deep.md).