APK Reverse Engineering Workflow: A 6-Phase Guide Using the `reverse-skill` Framework

The APK reverse engineering workflow consists of six sequential phases: Triage, Java Logic Observation, Smali & Resources, Rebuild & Install, Dynamic Hook, and optional Native Analysis, each supported by specific tools and PowerShell automation scripts.

This guide walks through the complete APK reverse engineering workflow as defined in the zhaoxuya520/reverse-skill repository. The process is encapsulated in the apk-reverse skill, which provides a reproducible, tool-checked pipeline for analyzing Android applications. Whether you're a security researcher hunting for vulnerabilities or a developer understanding third-party code, this workflow ensures no critical step is skipped.

Phase 1: Triage — Rapid APK Structure Analysis

The first phase establishes a comprehensive foundation for all subsequent analysis. According to skills/apk-reverse/SKILL.md, triage simultaneously runs JADX for Java decompilation and Apktool for smali/resource extraction.

Execute the unified decode script:

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

This generates three critical outputs:

• jadx_out/ — Decompiled Java source for logic inspection
• apktool_out/ — Smali bytecode, resources, and AndroidManifest.xml
• A summary report containing package name, smali directory structure, and native .so library inventory

The -Clean flag removes previous outputs to prevent stale data contamination.

Phase 2: Java Logic Observation — Finding Critical Code Paths

With decompiled Java available, focus on locating business-critical implementations: authentication flows, cryptographic routines, root detection mechanisms, and SSL certificate pinning.

Key search targets from apk-reverse/SKILL.md include:

• login, sign, encrypt, decrypt — Credential handling
• root, su, superuser — Root detection bypasses
• certificate, pinning, okhttp, trustmanager — SSL interception points
• SafetyNet, PlayIntegrityApi — Google attestation checks

Browse jadx_out/ with these terms to rapidly surface protection mechanisms that may require patching or hooking.

Phase 3: Smali & Resources — Low-Level Inspection and Patching

When Java decompilation fails due to heavy obfuscation or when manifest modifications are required, pivot to the Apktool output in apktool_out/.

Critical inspection points:

• AndroidManifest.xml — Check android:exported flags on activities, services, and receivers; verify permission declarations
• Smali files — Edit conditional branches (e.g., flipping if-eqz to if-nez) to disable security checks
• res/values/ — Identify hardcoded strings, URLs, or API keys

This phase bridges the gap between readable high-level code and modifiable low-level implementation.

Phase 4: Rebuild & Install — From Modified Code to Running APK

After any smali or resource modifications, the APK must be reassembled, aligned, signed, and deployed. The rebuild-sign-install.ps1 script automates this entire chain:

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

Behind the scenes, this executes:

1. apktool b apktool_out — Rebuild the APK package
2. zipalign — Optimize data alignment for runtime performance
3. apksigner — Apply a debug or release signature
4. adb install — Push to the specified device or emulator

The -DeviceSerial parameter enables precise targeting when multiple Android devices are connected.

Phase 5: Dynamic Hook — Runtime Analysis with Frida

Static analysis has limits. When protections execute only at runtime or native libraries validate integrity, Frida provides dynamic instrumentation.

Launch a hooked session with standardized device handling:

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

The frida-run.ps1 script normalizes:

• USB device enumeration (frida-ps -U)
• Process attachment versus fresh spawn
• JavaScript hook injection

Typical Frida scripts bypass SSL pinning, disable root detection, or intercept cryptographic operations mid-execution.

Phase 6: Native Analysis — Deep Inspection of .so Libraries

When core logic resides in compiled native libraries rather than Dalvik bytecode, the workflow hands off to dedicated native reverse-engineering skills. As documented under "Native .so 分流" in apk-reverse/SKILL.md, two paths exist:

• Radare2 for rapid command-line triage:

  r2 -i analysis.r2 libtarget.so

• IDA Pro for comprehensive decompilation:

  ida -A -Sauto.idc libtarget.so

This phase is triggered selectively based on .so presence discovered during Phase 1 Triage.

Quick Reference: Essential One-Liners

# Complete decode (JADX + Apktool)

jadx -d jadx_out app.apk && apktool d app.apk -o apktool_out

# Manifest security review

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

# Full rebuild pipeline with install

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

# Attach Frida to running process (non-spawn)

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

Key Source Files

Path	Purpose
skills/apk-reverse/SKILL.md	Master workflow definition and tool specifications
skills/apk-reverse/scripts/decode.ps1	Unified JADX and Apktool wrapper
skills/apk-reverse/scripts/rebuild-sign-install.ps1	Automated rebuild, sign, and deployment
skills/apk-reverse/scripts/frida-run.ps1	Standardized Frida session management
skills/apk-reverse/scripts/manifest-summary.ps1	Manifest security analyzer
skills/routing.md	Global routing matrix mapping APK targets to this skill

Summary

• APK reverse engineering follows a structured six-phase workflow defined in the reverse-skill repository.
• Triage establishes the analytical foundation with parallel JADX and Apktool execution.
• Java Logic Observation and Smali inspection provide dual-layer static analysis capabilities.
• Rebuild automation ensures modified applications can be tested on physical devices or emulators.
• Frida integration enables runtime bypass of protections that resist static analysis.
• Native hand-off connects APK analysis to deep binary inspection when .so libraries contain critical logic.
• Each phase includes Task-Completion Self-Checks to enforce workflow integrity.

Frequently Asked Questions

What tools are required for the APK reverse engineering workflow?

The workflow depends on JADX for Java decompilation, Apktool for smali/resource handling, zipalign and apksigner for packaging, ADB for device communication, and Frida for dynamic instrumentation. The decode.ps1 and tool-index.md files verify tool availability before execution.

Can this workflow handle heavily obfuscated APKs?

Yes. When ProGuard or R8 obfuscation renders JADX output unreadable, the workflow pivots to Phase 3 Smali analysis where method names may be obfuscated but control flow remains editable. For native obfuscation, Phase 6 transfers analysis to Radare2 or IDA Pro.

How does the rebuild script handle APK signing?

The rebuild-sign-install.ps1 script automatically generates a debug signature using apksigner with default Android SDK keys. For production testing, substitute the -KeyStore parameter with your release keystore path and credentials.

When should I use Frida versus static patching?

Use Frida (Phase 5) when the protection mechanism validates APK integrity at runtime, detects modifications, or loads dynamically. Use static patching (Phase 3-4) when the check is simple, deterministic, and you need persistence without runtime overhead.

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