APK Reverse-Engineering Workflow: A Complete 6-Phase Guide for Analyzing Android Apps

The APK reverse-engineering workflow consists of six sequential phases: Triage, Java Logic Observation, Smali & Resource Inspection, Rebuild & Installation, Dynamic Hooking with Frida, and optional Native .so Analysis.

This structured process is defined in the apk-reverse skill within the zhaoxuya520/reverse-skill repository. The workflow enables security researchers and reverse engineers to systematically deconstruct Android applications, from initial static analysis through dynamic runtime manipulation. Each phase is mapped to specific tools, scripts, and validation checkpoints to ensure reproducible results.

The skill is registered in the global routing matrix at [skills/routing.md](skills/routing.md), where Target Type → APK / Android app automatically routes analysis tasks to this workflow. All scripts verify tool availability against [tool-index.md](tool-index.md) before execution.

---

Phase 1: Triage — Mapping the APK Structure

The first phase rapidly identifies structural components, entry points, and native library dependencies.

Primary tools: jadx (Java decompiler) and apktool (smali/resources extractor)

Run the unified decoding script:

pwsh -File "skills\apk-reverse\scripts\decode.ps1" `
     -ApkPath "C:\samples\app.apk" -Clean

This generates three key outputs:

• jadx_out/ — Decompiled Java source code
• apktool_out/ — Smali bytecode, resources, and AndroidManifest.xml
• A terminal summary showing package name, smali directories, and detected .so files

The -Clean flag removes previous output directories before processing. The script is defined at skills/apk-reverse/scripts/decode.ps1.

---

Phase 2: Java Logic Observation — Finding Critical Code

With decompiled Java available, search for security-sensitive implementation details.

Target patterns (listed in [apk-reverse/SKILL.md](skills/apk-refore/SKILL.md)#java-logic-observation):

Category	Search Terms
Authentication	login, authenticate, token, session
Cryptography	encrypt, decrypt, AES, RSA, cipher
Network Security	okhttp, certificate, ssl, pinning
Root Detection	root, su, magisk, busybox
Obfuscation Clues	a.a.a, b.b.c, ProGuard mappings

Browse jadx_out/ to locate classes handling these functions. If obfuscation obscures logic, proceed to Phase 3.

---

Phase 3: Smali & Resource Inspection — Low-Level Patching

When Java decompilation fails or modifications are required, work directly with smali bytecode.

Key inspection targets in apktool_out/:

• AndroidManifest.xml — Check android:exported, permissions, intent filters, and component declarations
• smali/ directories — Locate specific methods for patching (e.g., changing if-eqz to if-nez to invert a branch)

Use manifest-summary.ps1 for quick manifest analysis:

pwsh -File "skills\apk-reverse\scripts\manifest-summary.ps1" `
     -ManifestPath "apktool_out\AndroidManifest.xml"

This extracts package name, permission list, and exported components without manual XML parsing.

---

Phase 4: Rebuild, Sign & Install — Testing Modifications

After patching smali or resources, repackage the APK for device testing.

The rebuild-sign-install.ps1 script automates the full pipeline:

pwsh -File "skills\apk-reverse\scripts\rebuild-sign-install.ps1" `
     -ProjectDir "apktool_out" `
     -Install `
     -DeviceSerial "127.0.0.1:7555"

Execution sequence:

1. apktool b — Rebuilds APK from modified project directory
2. zipalign -v 4 — Aligns uncompressed data for runtime efficiency
3. apksigner sign — Signs with debug or specified keystore
4. adb install — Pushes to connected device (if -Install specified)

The -DeviceSerial parameter targets specific ADB devices. Omit for single-device auto-detection.

---

Phase 5: Dynamic Hooking with Frida — Runtime Manipulation

When static analysis cannot bypass protections (e.g., native SSL pinning, root detection), use dynamic instrumentation.

Frida wrapper script: frida-run.ps1

pwsh -File "skills\apk-reverse\scripts\frida-run.ps1" `
     -Usb `
     -Spawn `
     -Package com.example.app `
     -ScriptPath "hooks\bypass.js"

Parameters explained:

Flag	Function
-Usb	Target USB-connected device (-Network for TCP)
-Spawn	Start fresh process (vs. -Attach for running app)
-Package	Application package identifier
-ScriptPath	JavaScript hook payload

The script normalizes device enumeration (frida-ps -U), resolves process names to PIDs, and handles Frida server detection. This abstracts common Frida boilerplate for reliable automation.

---

Phase 6: Native .so Analysis (Optional) — Deep Binary Inspection

If the Triage phase identified critical logic in native libraries (ARM .so files), escalate to native reverse-engineering skills.

Hand-off triggers (documented under "Native .so 分流" in the SKILL file):

• Core algorithms implemented in JNI
• Anti-tampering checks in native code
• Heavy obfuscation making Java analysis insufficient

Recommended tool paths:

Tool	Use Case	Invocation
radare2	Quick triage, scripting, batch analysis	r2 -i analysis.r2 libtarget.so
IDA Pro	Full decompilation, complex control flow	ida -A -Sscript.idc libtarget.so (batch)

The routing matrix at skills/routing.md maps these to dedicated ida-reverse or radare2 skills for continued analysis.

---

Workflow Completion Verification

Each phase includes validation before progression. The Task-Completion Self-Check at the end of [apk-reverse/SKILL.md](skills/apk-reverse/SKILL.md) enforces:

• Directory existence (Test-Path jadx_out)
• File generation checks (Get-ChildItem *.smali)
• Tool exit code verification ($LASTEXITCODE -eq 0)
• Device connectivity (adb devices)

Failure at any checkpoint halts execution with diagnostic output, preventing incomplete analysis states.

---

Essential Command Reference

Consolidated one-liners for manual execution:

# Phase 1: Decode with jadx only

jadx -d jadx_out app.apk

# Phase 1: Decode with apktool only

apktool d app.apk -o apktool_out --no-src

# Phase 3: Quick manifest permission list

grep -E "android\.permission\." apktool_out/AndroidManifest.xml | sort -u

# Phase 4: Manual rebuild pipeline

apktool b apktool_out -o unsigned.apk
zipalign -v 4 unsigned.apk aligned.apk
apksigner sign --ks debug.keystore aligned.apk
adb install aligned.apk

# Phase 5: Direct Frida spawn (no wrapper)

frida -U -f com.example.app -l hooks/bypass.js --no-pause

---

Summary

• APK reverse-engineering follows a six-phase workflow defined in the apk-reverse skill
• Phase 1 (Triage) uses decode.ps1 to run jadx and apktool simultaneously
• Phases 2-3 alternate between Java source and smali bytecode based on obfuscation level
• Phase 4 automates rebuild, alignment, signing, and installation via rebuild-sign-install.ps1
• Phase 5 enables runtime instrumentation through frida-run.ps1 with normalized device handling
• Phase 6 provides native escalation paths to radare2 or ida-reverse for .so analysis
• All scripts validate tool presence and step completion before proceeding

---

Frequently Asked Questions

What tools are required for the APK reverse-engineering workflow?

The workflow requires jadx, apktool, zipalign, apksigner (Android SDK), adb, and frida. Optional tools include radare2 or IDA Pro for native analysis. The decode.ps1, rebuild-sign-install.ps1, and frida-run.ps1 scripts verify tool availability before execution by reference to tool-index.md. Install missing tools via Android Studio SDK Manager or system package managers.

How do I patch an APK after finding vulnerable code?

Modify the smali files in apktool_out/smali/, then run rebuild-sign-install.ps1 with -ProjectDir pointing to your modified directory. The script handles rebuilding (apktool b), alignment (zipalign), signing (apksigner), and optional device installation. For Java-level changes, edit smali directly—apktool does not recompile from Java source.

When should I use Frida versus static analysis alone?

Use Frida dynamic hooking when: (1) code is heavily obfuscated or native-packed, (2) protections execute only at runtime (anti-debug, root detection), (3) cryptographic keys are generated procedurally, or (4) SSL pinning prevents traffic interception. The frida-run.ps1 script abstracts device detection and process management for reliable instrumentation.

Can this workflow analyze native libraries (.so files)?

Yes, but as a hand-off. The Triage phase flags critical native libraries. For these, pivot to the radare2 or ida-reverse skills documented under "Native .so 分流" in apk-reverse/SKILL.md. The workflow intentionally separates Java/native analysis to maintain tool specialization while preserving investigation continuity through the routing matrix.

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