Fully automated reverse-engineering orchestrator. Given a target (Android APK/AAB/XAPK, web URL, or Windows PE), it drives the end-to-end workflow — fingerprinting → planning the analysis chain → static analysis → dynamic analysis → native deep-dive → result synthesis → reproduction & verification — and produces a structured report. This is the entry point of the auto_reverse project, responsible for deciding "which skill/tool to invoke and when, and what to do next once results come back." Trigger scenarios: automated reversing, "reverse this app/website," auto-reverse, fully automated analysis, "here's an APK, run it automatically," "I don't know where to start."

2026-07-1115

js-trace-engine

warterbili/AUTO_REVERSE

Generic dynamic instrumentation / trace engine for heavily-obfuscated anti-bot JavaScript. Takes ANY obfuscated JS, weaves Babel AST probes (function enter/exit, variable assignments, member reads), recursively re-instruments every runtime-generated string (eval / new Function / string setTimeout) so code that only exists after decryption is also traced, runs it bare in a Node harness on top of an env-supplement-proxy environment, and dumps an aggregated execution trace (hot functions, hot variables, dynamic code-gen layers, candidate sign outputs). Ships an L2 anti-detection prelude (clock freeze defeats timing anti-debug; DebuggerStatement stripping; eval/Function toString spoofing). This is the OBSERVATION layer that stacks on top of env-supplement-proxy / node-bridge-build (which make the JS RUN) — it shows HOW the algorithm computes, not just its output. Use when you must understand the internal computation of obfuscated sign/cookie JS, capture runtime-decrypted algorithm code, or produce an execution tr

2026-06-2715

capa-triage

warterbili/AUTO_REVERSE

Use capa (Mandiant) + FLOSS to perform capability triage and string deobfuscation on native libraries (.so / ELF) and executables—before diving into IDA/Ghidra decompilation, automatically identify what capabilities a binary has (crypto/network/anti-debug/anti-analysis/file operations) and recover obfuscated/encoded/stack-built strings (URLs, keys, C2). Trigger scenarios — capa, floss, analyze .so capabilities, identify crypto algorithms, native library capability overview, deobfuscate strings, triage before digging deep.

2026-06-2015

android-re-decompile

warterbili/AUTO_REVERSE

Decompile Android APK, XAPK, JAR, and AAR files using jadx or Fernflower/Vineflower. Reverse engineer Android apps, extract HTTP API endpoints (Retrofit, OkHttp, Volley), and trace call flows from UI to network layer. Use when the user wants to decompile, analyze, or reverse engineer Android packages, find API endpoints, or follow call flows. Trigger keywords: decompile APK, Android reverse engineering, extract API, analyze Android app, decompile Android, reverse engineering, trace call chain, extract interfaces

2026-06-1815

android-re-fundamentals

warterbili/AUTO_REVERSE

Android reverse-engineering onboarding and fundamentals. Covers device preparation and rooting (unlock bootloader, flash a clean ROM, Magisk root, real-device vs emulator trade-offs), full environment setup (JDK, adb/fastboot, Frida server/tools, Charles/mitmproxy CA certificates), APK internal structure and the forward packaging pipeline, the Android filesystem and partition layout, decompile-and-hook basics, and phone UI automation. Use this when bootstrapping an Android RE workstation, when the user is new to Android reverse engineering, or when they ask how to root a phone, set up Frida/adb/Charles, understand APK/DEX structure, learn the Android filesystem, or automate a device. Trigger keywords — android reverse engineering basics, set up Frida, install adb, root phone, unlock bootloader, flash ROM, Magisk, APK structure, DEX, AndroidManifest, Android filesystem, phone automation, uiautomator2, Charles certificate, JDK install, Android reverse engineering getting started, flashing ROM, root, environment

2026-06-1815

apk-acquire

warterbili/AUTO_REVERSE

Fully automatic APK acquisition for Android reversing. Given a package name, it obtains the APK through the first route that works — pull from a connected adb device, use a local file, or download from APKPure's direct-link endpoint (XAPK with splits or single APK) — then optionally installs it back to a device and verifies the package name. This is Phase 0 (Intake) of the auto_reverse orchestrator: it answers "I don't have the APK yet, get it for me" without manual confirmation. Trigger terms: get the apk, download apk, acquire apk, pull apk, automatic apk acquisition, download apk, install apk, app not installed / not available locally.

2026-06-1815

name	apktool-decompile
description	A complete guide and workflow for decompiling, modifying, and repackaging Android APKs with apktool.

Apktool Decompilation Skill

Apktool is a powerful tool for reverse-engineering Android APK files. It can decode an APK into a near-original form (including resource files and smali code) and lets you repackage it after modification.

Version: 2.12.1 (with smali 3.0.9 and baksmali 3.0.9)

Core Commands

1. Decode an APK (decode)

Decompile an APK file into readable resources and smali code.

apktool d <apk-file> [options]

Common options:

Option	Description
`-o, --output <dir>`	Specify the output directory (default: apk.out)
`-f, --force`	Force-delete an existing target directory
`-r, --no-res`	Do not decode resource files (speeds up processing)
`-s, --no-src`	Do not decode source code (smali)
`-p, --frame-path <dir>`	Use framework files from the specified directory
`-t, --frame-tag <tag>`	Use framework files with the specified tag

Examples:

# Basic decode
apktool d app.apk

# Specify the output directory
apktool d app.apk -o app_decoded

# Force-overwrite an existing directory
apktool d app.apk -f -o app_decoded

# Decode resources only, not smali (quick look at resources)
apktool d app.apk -s -o app_res_only

# Decode smali only, not resources
apktool d app.apk -r -o app_smali_only

2. Rebuild an APK (build)

Rebuild an APK from a decoded directory.

apktool b <apk-dir> [options]

Common options:

Option	Description
`-o, --output <file>`	Specify the output file (default: dist/name.apk)
`-f, --force`	Skip change detection and rebuild all files
`-p, --frame-path <dir>`	Use framework files from the specified directory

Examples:

# Basic build
apktool b app_decoded

# Specify the output file
apktool b app_decoded -o app_modified.apk

# Force a rebuild
apktool b app_decoded -f -o app_modified.apk

3. Install a Framework File (install-framework)

Install a system framework APK so that apps depending on system resources decode correctly.

apktool if <framework.apk> [options]

Examples:

# Install the system framework
apktool if framework-res.apk

# Install to a specific directory with a tag
apktool if framework-res.apk -p ~/frameworks -t samsung

Decoded Directory Structure

app_decoded/
├── AndroidManifest.xml      # App manifest (decoded to readable XML)
├── apktool.yml              # apktool config file
├── assets/                  # Original asset files
├── lib/                     # Native libraries (.so files)
│   ├── arm64-v8a/
│   ├── armeabi-v7a/
│   └── x86_64/
├── original/                # Original META-INF and signature info
├── res/                     # Resource files (decoded)
│   ├── drawable/
│   ├── layout/
│   ├── values/
│   └── ...
├── smali/                   # smali code of the main dex
├── smali_classes2/          # smali code of classes2.dex
├── smali_classes3/          # smali code of classes3.dex
└── unknown/                 # Unrecognized files

Practical Workflows

Workflow 1: Quickly Inspect APK Contents

# 1. Decode the APK
apktool d target.apk -o target_decoded

# 2. View AndroidManifest.xml
cat target_decoded/AndroidManifest.xml

# 3. View resource strings
cat target_decoded/res/values/strings.xml

Workflow 2: Modify and Repackage

# 1. Decode
apktool d target.apk -f -o target_decoded

# 2. Modify files (e.g., smali code or resources)
# ... edit target_decoded/smali/... or target_decoded/res/...

# 3. Rebuild
apktool b target_decoded -o target_modified.apk

# 4. Sign (using jarsigner or apksigner)
# Note: a repackaged APK must be re-signed before it can be installed
jarsigner -verbose -keystore my.keystore target_modified.apk alias_name
# or
apksigner sign --ks my.keystore target_modified.apk

Workflow 3: Extract and Analyze Native Libraries

# 1. Decode only the resource structure (skip smali for speed)
apktool d target.apk -s -o target_libs

# 2. Extract the native library for analysis
cp target_libs/lib/arm64-v8a/libtarget.so ./

# 3. Analyze with IDA or Ghidra

Workflow 4: Analyze Smali Code

# 1. Decode
apktool d target.apk -o target_decoded

# 2. Search for specific strings or methods
grep -r "signature" target_decoded/smali/
grep -r "encrypt" target_decoded/smali/

# 3. Find a specific class
find target_decoded/smali* -name "SignatureHelper.smali"

Smali Basics

Smali is a readable representation of Android Dalvik bytecode.

Class Definition

.class public Lcom/example/MyClass;
.super Ljava/lang/Object;
.source "MyClass.java"

Method Definition

.method public static myMethod(Ljava/lang/String;I)Ljava/lang/String;
    .registers 4
    # code...
    return-object v0
.end method

Common Type Signatures

Signature	Java type
`V`	void
`Z`	boolean
`B`	byte
`I`	int
`J`	long
`F`	float
`D`	double
`[I`	int[]
`Ljava/lang/String;`	String

Common Smali Modifications

Bypass a method check (return true):

# Original code
.method public isValid()Z
    # ... complex check logic
.end method

# Modified to always return true
.method public isValid()Z
    .registers 1
    const/4 v0, 0x1
    return v0
.end method

Add a logging call:

const-string v0, "TAG"
const-string v1, "Debug message"
invoke-static {v0, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

Best Practices

1. Handling Large APKs

Use the -r or -s option to decode only the parts you need
A multi-dex APK produces smali_classes2/, smali_classes3/, etc.

2. Handling System Apps

First install the framework-res.apk that matches the device
Use the -t tag to distinguish frameworks from different devices

3. Repackaging Notes

A repackaged APK must be re-signed
Some apps verify their signature and require extra handling
Keep the apktool.yml file to ensure a correct rebuild

4. Pairing with Other Tools

JADX: view more readable Java source
IDA/Ghidra: analyze native libraries
Frida: dynamic hooking and debugging

Common Issues

Decode Failure

# Try installing the corresponding framework file
apktool if /path/to/framework-res.apk

# Or skip resource decoding
apktool d app.apk -r

Rebuild Failure

# Check for smali syntax errors
# Force a rebuild
apktool b app_decoded -f

Signature Issues

# Generate a test keystore
keytool -genkey -v -keystore test.keystore -alias test -keyalg RSA -keysize 2048 -validity 10000

# Sign the APK
apksigner sign --ks test.keystore --ks-key-alias test app_modified.apk

# Or use jarsigner
jarsigner -keystore test.keystore app_modified.apk test

Helper Scripts

This skill provides the following helper scripts:

analyze_apk.sh

Quickly analyzes an APK file, showing basic info, permissions, smali statistics, and the native library list.

./resources/analyze_apk.sh target.apk

rebuild_and_sign.sh

Rebuilds and signs a modified APK in one step.

./resources/rebuild_and_sign.sh app_decoded output.apk

search_smali.sh

Searches smali code for a specific pattern, with filtering by method, class, string, or native method.

./resources/search_smali.sh app_decoded "signature"
./resources/search_smali.sh app_decoded "encrypt" -m  # search methods only
./resources/search_smali.sh app_decoded "api_key" -s  # search strings only

References

Official docs: https://apktool.org
Smali/Baksmali: https://github.com/google/smali
Android signing tools: https://developer.android.com/studio/command-line/apksigner