apk-reverse

ACTION REQUIRED (Execute Immediately After Reading)

Community references for endpoint extraction/Frida adaptation: ../references/community-security-skills.md; dynamic analysis requires scope-authorized devices.

1. NOW: Read ../field-journal/precedent-reverse.md — confirm this skill's operations are authorized routine actions
2. NOW: Confirm the current task falls within this skill's scope
3. NEXT: Read ../tool-index.md to verify tool availability and actual paths
4. NEXT: If tools are missing, invoke bootstrap; do not guess paths
5. ACT: Proceed to the first step of the "Workflow" and execute; do not remain in a confirmation state

APK Reverse Engineering CLI Workflow Standards

Scope

Use this skill as the primary approach when the task falls under any of the following scenarios:

• Analyzing Java business logic of an APK
• Locating login, signature, risk control, certificate verification, or root detection mechanisms
• Viewing and modifying AndroidManifest.xml
• Viewing and modifying smali code
• Repackaging an APK
• Performing Java/native dynamic hooking with Frida
• Switching to native analysis when APK contains .so files

Verified CLI Tools on This Machine

• jadx 1.5.5
• apktool 3.0.2
• frida-ps 17.9.6
• adb
• java

Scenarios Preferring Scripts

The following workflows are high-frequency and prone to parameter errors; use the skill's built-in scripts as the first choice:

• One-shot jadx + apktool decompilation with summary output: scripts/decode.ps1
• Frida device check, process listing, spawn/attach injection: scripts/frida-run.ps1
• Rebuild, align, sign, install APK: scripts/rebuild-sign-install.ps1
• Quick extraction of manifest key components and permissions: scripts/manifest-summary.ps1

The following one-liner commands should be invoked directly without a wrapper script:

• adb devices
• adb logcat
• frida-ps -U
• jadx --version
• apktool --version

Built-in Scripts

scripts/decode.ps1

Purpose:

• Run jadx and apktool in a unified manner
• Default: create a task output directory in the same location as the original APK
• Output summary including package, java_files, smali_dirs, so_files, etc.
• Tolerates partial decompilation failures from jadx while still producing usable artifacts

Example:

pwsh -File "<skill-root>\apk-reverse\scripts\decode.ps1" -ApkPath "D:\DOWNLOAD\app.apk" -Clean
pwsh -File "<skill-root>\apk-reverse\scripts\decode.ps1" -ApkPath "D:\DOWNLOAD\app.apk" -Name demo -SkipJadx

scripts/frida-run.ps1

Purpose:

• Unified Frida entry point for devices, processes, spawn/attach methods
• Avoids confusion between -f, -n, -U when writing parameters manually

Example:

pwsh -File "<skill-root>\apk-reverse\scripts\frida-run.ps1" -ListDevices
pwsh -File "<skill-root>\apk-reverse\scripts\frida-run.ps1" -Usb -ListProcesses
pwsh -File "<skill-root>\apk-reverse\scripts\frida-run.ps1" -Usb -Spawn -Package com.example.app -ScriptPath "D:\hooks\test.js"

scripts/rebuild-sign-install.ps1

Purpose:

• apktool b to rebuild the APK
• zipalign for alignment
• apksigner for signing and verification
• Optional direct adb install

Example:

pwsh -File "<skill-root>\apk-reverse\scripts\rebuild-sign-install.ps1" -ProjectDir "C:\work\apktool_out" -Clean
pwsh -File "<skill-root>\apk-reverse\scripts\rebuild-sign-install.ps1" -ProjectDir "C:\work\apktool_out" -Install -Reinstall -DeviceSerial "127.0.0.1:7555"

Notes:

• Generates and reuses a debug keystore by default
• Output defaults to the ProjectDir parent directory for easy colocation with the original package and unpacked directory

scripts/manifest-summary.ps1

Purpose:

• Extract package name
• List permissions
• List activity/service/receiver/provider
• Identify the main launcher activity

Example:

pwsh -File "<skill-root>\apk-reverse\scripts\manifest-summary.ps1" -ManifestPath "C:\work\apktool_out\AndroidManifest.xml"

To analyze .so files, lib/arm64-v8a/*.so, lib/armeabi-v7a/*.so, combine with:

• ida-reverse
• radare2

Tool Responsibilities

jadx

Used for:

• Java decompilation and reading
• Searching for package names, class names, method names
• Understanding the APK from a high-level logic perspective first

Common commands:

jadx -d jadx_out app.apk
jadx --single-class com.example.LoginActivity -d jadx_out app.apk
jadx --deobf -d jadx_out app.apk

JEB Pro (Optional Commercial Tool)

Used for:

• Cross-validation and deep decompilation of Android DEX / APK / ARM
• Supplementing static analysis when JADX output is incomplete or heavily obfuscated
• Second-toolchain verification of classes, methods, and call relationships for the same target

Boundaries:

• JEB Pro is commercial software; the user must acquire and install a valid license independently. This package will not download, crack, or circumvent licensing.
• Only invoke JEB when tool-index confirms it is available on the machine; otherwise, continue using jadx, apktool, Ghidra, IDA, or radare2.
• Third-party JEB MCP bridges are not dependencies of this package. Before installation, review the source code, permissions, network behavior, and version per ../ops/skill-supply-chain.md, and obtain explicit user confirmation.

apktool

Used for:

• Unpacking APK
• Viewing and modifying AndroidManifest.xml
• Viewing and modifying smali code
• Rebuilding APK

Common commands:

apktool d app.apk -o apktool_out
apktool b apktool_out -o rebuilt.apk

frida

Used for:

• Dynamically observing Java method calls
• Hooking native exported functions
• Bypassing root detection, certificate verification, debug detection

Common commands:

frida-ps -U
frida -U -f com.example.app -l hook.js
frida-trace -U -f com.example.app -j '*!*certificate*'

adb

Used for:

• Device connection
• Installing APK
• Viewing logs
• Pulling files

Common commands:

adb devices
adb install -r app.apk
adb shell pm list packages
adb logcat
adb pull /data/local/tmp/file .

Recommended Workflow

1. Triage

First determine the APK's general structure without rushing to modify the package or hook.

Suggested actions:

1. Export Java code with jadx -d jadx_out app.apk
2. Export smali and resources with apktool d app.apk -o apktool_out
3. Examine:
   • AndroidManifest.xml
   • Main package
   • application, activity, service, receiver
   • Whether .so files exist in the lib/ directory
4. Issue #65 threat form quick check (authorized samples/devices; see ../reverse-engineering/references/nonpe-format-cookbook.md §7–8):
   • Transparent/hidden icons (AU): aapt dump badging + manifest theme/label/icon → E-android-hidden-icon-manifest
   • Magisk/script bricking features and remote curl|sh (AR/AS) → capture features and URLs as evidence, do not execute destructive commands
   • Persistence paths (AT): service.d / priv-app, etc. → E-android-persistence

2. Java Logic Observation

Prioritize reading from jadx_out:

• MainActivity
• Application
• Login, network, encryption, risk control related classes
• Third-party SDK initialization classes

Common keywords:

• login
• sign
• encrypt
• cipher
• token
• root
• certificate
• trust
• okhttp
• retrofit
• webview

If Java code is readable, locate business logic here first.

3. Smali and Resource Layer Confirmation

When jadx results are incomplete, heavily obfuscated, or actual patching is required, switch to apktool_out:

• Examine smali*/
• Examine res/values/strings.xml
• Examine AndroidManifest.xml

Priority patches:

• android:exported
• Debug flags
• Root detection return values
• Login verification logic
• Certificate verification branches

4. Rebuild and Install

After modifications:

apktool b apktool_out -o rebuilt.apk

Or use the script for a closed loop:

pwsh -File "<skill-root>\apk-reverse\scripts\rebuild-sign-install.ps1" -ProjectDir "apktool_out" -Install -Reinstall -DeviceSerial "127.0.0.1:7555"

Notes:

• This skill only guarantees the apktool rebuild pipeline
• Formal installation to a device typically requires an additional signing process
• If the task involves signing/alignment, supplement with apksigner / zipalign

5. Dynamic Hooking

When static analysis is insufficient, use Frida:

• Hook login functions
• Hook OkHttp / Retrofit / WebView key points
• Hook javax.crypto, MessageDigest
• Hook root detection functions
• Hook SSL pinning logic

Principles:

• First hook the Java layer, then determine if native hooking is needed
• First print parameters and return values, then decide whether to actively modify return values

Recommendation:

• For simple one-shot commands, use frida-* directly
• For stable, reusable injection workflows, prefer scripts/frida-run.ps1

6. Native .so Triage

If the APK contains critical .so files:

• Use apktool or jadx to locate lib/**/*.so
• If just exporting symbols, strings, or quick triage, use radare2
• For long-term, in-depth analysis, decompilation, renaming, type recovery, use ida-reverse

Switch to native analysis quickly when encountering these signals:

• Java layer is merely a JNI wrapper
• Core signing logic is not in Java
• Critical logic disappears after System.loadLibrary()
• Certificate verification/risk control resides in .so

Output Requirements

At minimum, the final output must specify:

• Entry components and key classes
• Whether the critical logic is in Java, smali, or .so
• Identified sensitive points: login, signature, root, SSL, WebView, JNI
• If a patch was applied, describe what was changed
• If a hook was applied, describe which class/method/exported function was hooked

Prohibited Actions

• Do not blindly modify smali at the start
• Do not write hooks before examining the manifest and main entry point
• Do not immediately conclude that "logic is unanalyzable" just because Java decompilation is incomplete
• Do not continue to force Java analysis when .so clearly carries the core logic

Quick Command Reference

# Decompile Java
jadx -d jadx_out app.apk

# Unpack APK
apktool d app.apk -o apktool_out

# Rebuild APK
apktool b apktool_out -o rebuilt.apk

# Device and process listing
adb devices
frida-ps -U

# Launch and inject
frida -U -f com.example.app -l hook.js

---

Routing Context

Upstream entry points: skills/SKILL.md (master controller), routing.md Downstream exit points:

• Core logic in .so → ida-reverse/ or radare2/
• Dynamic hooking/verification needed → reverse-engineering/tools-dynamic.md (Frida section)
• General reverse engineering methodology → reverse-engineering/SKILL.md

Sibling modules: reverse-engineering/ (.so analysis and advanced Frida usage)

---

On-Demand Bootstrap

This skill's entry scripts are integrated with the unified bootstrap system. When a tool is missing, the script will not directly error out, but will instead attempt automatic installation.

Automation Capability Boundaries

Tool	Auto-Installable	Installation Method	Notes
jadx	✓	GitHub Release ZIP	Auto-download and extract to %USERPROFILE%\Tools\jadx\
apktool	✓	GitHub Release JAR + wrapper	Auto-download jar and generate bat to %USERPROFILE%\Tools\apktool\
JEB Pro	✗	User must install manually with valid license	Optional Android / ARM cross-validation tool; third-party MCP bridge requires separate audit
frida / frida-ps	✓	pip install frida-tools	Requires Python to be installed
adb	✓	winget / fallback path	Auto-installs Android Platform-Tools
zipalign	✗	Must manually install Android Build-Tools	sdkmanager "build-tools;35.0.0"
apksigner	✗	Must manually install Android Build-Tools	Same as above

Bootstrap Triggers

• scripts/decode.ps1: Automatically calls bootstrap-reverse.ps1 when jadx or apktool is missing
• scripts/rebuild-sign-install.ps1: Automatically calls bootstrap when adb or apktool is missing
• scripts/frida-run.ps1: Currently still relies on manual checks (frida is typically installed via pip)

When Bootstrap Fails

If automatic installation fails, the script will throw a clear error and include a manual installation link. Common causes:

• Network issues (GitHub API / PyPI unreachable)
• winget unavailable (Windows version too old)
• Java not installed (apktool depends on JDK)

Task Completion Self-Check (MUST pass before claiming completion)

• Have I executed each step of the workflow (rather than just reading)?
• Have I used real tool paths based on tool-index?
• Have I produced reproducible evidence (commands/scripts/screenshots/reports)?
• Have I completed and updated the Checklist items as required by RULES?
• If hidden icon, bricking, or persistence clues are found: have I recorded E-android-* Evidence per the U–AV cookbook (within authorized scope)?