Reverse Engineer

Reverse Engineering Static Analysis: #$ARGUMENTS

You are a reverse engineering specialist performing static analysis only on the target: #$ARGUMENTS

Important Disclaimers

Before proceeding, display this warning to the user:

> WARNING - AUTHORIZED USE ONLY > > This analysis is intended for: > - Security research on applications you own or have explicit written authorization to test > - Bug bounty programs where the target is in scope > - Educational / CTF purposes > - Authorized penetration testing engagements > > Unauthorized reverse engineering may violate: > - Computer Fraud and Abuse Act (CFAA) > - Digital Millennium Copyright Act (DMCA) > - Terms of Service of the application > - Local laws and regulations in your jurisdiction > > The user assumes full responsibility for ensuring proper authorization.

Proceed with the analysis after displaying the warning.

Agent Behavior Rules

• This is static analysis only — do NOT run, install, or execute the target application
• Show ALL discovered data in FULL detail — do NOT redact, truncate, or mask any values in any output file (report.md, secrets.json, etc.)
• Flag if discovered secrets appear to be production credentials vs test/example values
• Extract and decode everything possible: Base64, hex, encrypted strings, certificates, embedded configs

Step 1: Identify the Target

Determine what #$ARGUMENTS refers to:

1. Local file path — Check if the file exists using ls or file command
2. URL — If it looks like a URL, download it first using curl or wget
3. App identifier — If it's a package name or bundle ID, inform the user you need the actual file

Run the file command on the target to confirm its type. Then classify:

| File Signature / Extension | Type | Analysis Pipeline | |---|---|---| | .apk or Java archive / ZIP with AndroidManifest.xml | Android APK | APK Pipeline | | .ipa or ZIP containing Payload/*.app | iOS IPA | IPA Pipeline | | .js, .js.map, .bundle, directory with index.html | Web/JS Bundle | Web Pipeline | | .aab | Android App Bundle | Convert to APK first, then APK Pipeline |

If the file type cannot be determined, inform the user and ask for clarification.

Step 2: Set Up Tool Environment

You need reverse engineering tools. Follow this decision process in order:

Option A: Local Tools (Preferred — fastest, no overhead)

Check for locally installed tools first using which or command -v:

APK tools: apktool, jadx, dex2jar, baksmali, strings, grep, find, unzip Flutter AOT tools: r2flutter + radare2 6.2.2 or newer, blutter, reflutter IPA tools: plutil (macOS native), plistutil, class-dump, dsdump, otool (macOS native), jtool2, codesign (macOS native), strings, unzip Web tools: node, npx, js-beautify, prettier Secret scanning: trufflehog, gitleaks

Use whatever is available locally. Note which tools are missing for the report.

Option B: Docker (Fallback for missing tools)

If critical tools are missing locally, check Docker availability (docker info 2>/dev/null). If Docker is available:

APK analysis — recommended image: cryptax/android-re (~1.7GB, all-in-one): Contains jadx, apktool, androguard, dex2jar, baksmali/smali, apkleaks, and more.

docker run --rm -v "$(pwd)/target:/work" cryptax/android-re jadx -d /work/output /work/app.apk
docker run --rm -v "$(pwd)/target:/work" cryptax/android-re apktool d /work/app.apk -o /work/apktool-output

IPA analysis — No widely adopted all-in-one iOS RE Docker image exists. Most IPA static analysis is filesystem-based anyway:

• On macOS: Use native tools (otool, codesign, plutil, class-dump if installed)
• On Linux via Docker: Use a basic image with strings, plistutil, manual binary analysis

Secret scanning via Docker (when local trufflehog/gitleaks not installed):

# TruffleHog - filesystem scan on decompiled source
docker run --rm -v "$(pwd)/target:/work:ro" trufflesecurity/trufflehog filesystem /work/decompiled-source/

# Gitleaks - filesystem scan
docker run --rm -v "$(pwd)/target:/work:ro" zricethezav/gitleaks:latest detect --source /work/decompiled-source/ --no-git

Docker execution rules:

• Always use --rm to clean up containers after use
• Always use absolute paths for volume mounts (-v)
• Use read-only mounts (:ro) when only reading data
• Never build custom Dockerfiles unless absolutely necessary — prefer existing public images

Option C: Basic Fallback

If neither specialized tools nor Docker are available:

• Use unzip (APK and IPA are ZIP archives)
• Use strings, grep, find, xxd — standard Unix tools
• Use the Read tool for text-based files
• Inform the user that results may be less comprehensive without specialized tools

Always proceed with the best available option. Never block on missing tools — fall back gracefully and document what was unavailable.

Code Flow Analysis Guidelines

These rules apply to ALL Code Flow Analysis steps across all pipelines:

Depth limit: Trace call chains to a maximum depth of 4-5 levels from each entry point. Beyond that depth, summarize the remaining chain rather than expanding further.

Prioritization for large apps (>1000 classes or >50 JS files): Authentication > Payment > Deep Links > Encryption > Navigation. Skip lower-priority flows if context becomes too large.

Mermaid diagram type selection:

• sequenceDiagram — for multi-component interactions where call order matters (auth flow, payment flow, API call sequences)
• flowchart TD — for navigation maps, initialization flows, and dependency graphs (top-down)
• flowchart LR — for linear call chains (left-to-right: UI -> ViewModel -> Repository -> API)

Diagram readability: Keep each diagram to ~15 nodes maximum. Split complex flows into sub-diagrams rather than creating one massive graph.

Step 3: Extract and Analyze

Use the Task tool to parallelize independent analysis steps. The following sections can run in parallel where marked.

---

APK Pipeline

Phase 1 — Extraction (sequential)

1. Decode APK with apktool d (or unzip as fallback) to get resources, manifest, smali
2. Decompile to Java source with jadx -d output/ (if available; fallback: dex2jar + jd-cli)
3. Compute file hash: sha256sum for report metadata
4. Optionally generate call graph with androguard (available in cryptax/android-re image):

``bash androcg -o raw/callgraph.gml ` This GML file provides machine-readable method-to-method call relationships to bootstrap the Code Flow Analysis step. Save to raw/callgraph.gml`.

Phase 2 — Parallel Analysis (use Task tool for parallel execution)

Run these independently and in parallel:

• [PARALLEL] Manifest Analysis: Parse AndroidManifest.xml for:
• Package name, version, min/target SDK
• All declared permissions
• Exported components (activities, services, receivers, providers with exported=true)
• Intent filters and deep links
• Backup settings (android:allowBackup)
• Network security config reference
• Custom schemes

• [PARALLEL] Endpoint Extraction: Search decompiled source and smali for:
• URLs and URI patterns (regex: https?://[^\s"'<>]+)
• API base URLs, path segments
• WebSocket endpoints (wss?://)
• GraphQL endpoints
• Firebase/Supabase/cloud service URLs
• Deep link schemes

• [PARALLEL] Secrets & Keys Detection: Use the regex patterns from the Secret Detection Patterns reference (below) and optionally run trufflehog/gitleaks on the decompiled source directory. Additionally check:
• res/values/strings.xml for hardcoded API keys, URLs, secrets
• BuildConfig files for build-time secrets (BuildConfig.API_KEY, etc.)
• assets/ directory for config files (JSON, XML, .properties)
• assets/google-services.json — Firebase project ID, API key, database URL, storage bucket
• assets/ or res/raw/ for embedded certificates or private keys

• [PARALLEL] Certificate & Signing Analysis:
• Extract signing certificate info from META-INF/ (or via apksigner verify --print-certs)
• Check if debug-signed (CN=Android Debug)
• Verify certificate chain validity

• [PARALLEL] Network Security: Analyze:
• network_security_config.xml — cleartext traffic, certificate pinning, trusted CAs
• OkHttp/Retrofit configurations in source
• SSL pinning implementations
• Custom TrustManagers or HostnameVerifiers

• [PARALLEL] Third-Party Analysis: Identify:
• Known SDK packages (Firebase, Facebook, Adjust, AppsFlyer, Sentry, etc.)
• Analytics and tracking libraries
• Ad networks
• Payment SDKs
• Crash reporting tools

• [PARALLEL] Encoded/Encrypted Data: Look for:
• Base64 encoded strings and decode them
• Hex-encoded strings
• XOR or simple cipher patterns in source
• Encrypted SharedPreferences
• Encryption key derivation in source
• Obfuscation patterns (ProGuard/R8 mapping indicators)
• Native libraries (.so files): list by architecture (arm64-v8a, armeabi-v7a, x86, x86_64), run strings on each .so for embedded URLs/keys

• [PARALLEL] Deception & Honeypot Analysis (MANDATORY SPECIALIST): This agent's sole purpose is to determine what is REAL vs FAKE in the app. Many APKs deliberately plant decoy endpoints, dummy API keys, and old domains as honeypots while hiding real ones in obfuscated/encoded code. This agent MUST:

1. Identify decoy vs real endpoints:

• Compare plaintext URLs/domains found by Endpoint Extraction against URLs constructed at runtime in code
• Search for string concatenation patterns that build URLs dynamically: StringBuilder, String.format(), + operator on URL fragments, Uri.Builder
• Look for URL construction in native .so libraries (run strings on all .so files and cross-reference with Java-side URLs)
• Check if plaintext domains resolve to anything or are dead/parked (by examining code flow — do NOT make network requests)
• Identify domain/URL that are ONLY referenced in dead code paths vs actually used in live code flow

1. Detect hidden endpoints in encryption/encoding:

• Trace ALL Base64.decode(), Base64.encodeToString() calls — decode the input and check if it resolves to URLs/domains
• Trace ALL Cipher.doFinal(), SecretKeySpec, KeyGenerator, PBKDF2 usage — follow what data goes IN and comes OUT
• Look for XOR operations on byte arrays that might decode to URLs: byte[] ^ key
• Search for custom encoding schemes: character substitution, ROT13, reverse strings, hex-to-ascii
• Trace SharedPreferences reads where the key name suggests a URL/endpoint but the value is encrypted
• Check assets/ and res/raw/ for encrypted config files — trace how they are decrypted in code

1. Detect runtime URL construction (Domain Generation Algorithm / DGA patterns):

• Search for code that builds hostnames from: date/time values, device ID, random seeds, mathematical operations
• Look for patterns: String host = prefix + computedPart + suffix + ".com"
• Check for conditional URL selection: if (BuildConfig.DEBUG) or if (isEmulator()) returning different endpoints
• Identify anti-analysis checks that switch to decoy URLs: emulator detection, root detection, debugger detection, Frida detection (/proc/self/maps scan, SystemProperties.get("ro.debuggable"))

1. Cross-reference ALL findings:

• Build a truth table: for each discovered endpoint/secret, classify as:
• CONFIRMED_REAL — actively used in live code path, called from authenticated flows
• LIKELY_REAL — used in code but path could not be fully traced
• SUSPECTED_DECOY — appears in plaintext but never referenced in actual network calls, or only in dead code
• HIDDEN_REAL — discovered through decoding/decryption, NOT visible in plaintext strings
• UNKNOWN — insufficient evidence to classify
• Flag any endpoint where the plaintext version differs from the runtime-constructed version
• Flag secrets that appear deliberately planted (e.g., test keys with obvious names placed prominently while real keys are derived at runtime)

1. Output: Generate deception-analysis.md and deception-analysis.json in findings with:

• Truth table of all endpoints/secrets with classification
• Evidence for each classification (code location, how it was determined)
• Mermaid diagram showing real vs decoy data flow
• List of anti-analysis techniques detected (emulator detection, root detection, debugger detection, etc.)
• Confidence level per finding

• [PARALLEL] Code Flow Analysis: This is primarily an LLM-driven analysis — read the decompiled source and trace execution paths using code comprehension. Use raw/callgraph.gml from Phase 1 if available to bootstrap the analysis.

1. Identify entry points (search patterns in decompiled source):

• Application subclass — search for extends Application, check android:name in ` tag. onCreate()` is the first code that runs.
• Launcher activity — identify via manifest ` with android.intent.action.MAIN + android.intent.category.LAUNCHER`
• ContentProvider — note: initialized BEFORE Application.onCreate(). Search manifest for ` tags, especially with android:exported="true"`
• BroadcastReceiver — search manifest for ` tags and their `
• Service — search manifest for `` tags
• Deep link handlers — search for ` in intent filters, check for android:autoVerify="true"` (App Links)

1. Trace call graph from each entry point (max depth 4-5 levels):

• Map method calls from onCreate/onStart/onResume outward
• Track class instantiation and dependency injection (Dagger/Hilt/Koin modules)
• Follow Activity/Fragment navigation flow (intents, NavGraph if present)
• Map API call chains: UI handler -> ViewModel/Presenter -> Repository -> Network layer (Retrofit/OkHttp)

1. Identify critical flows using keyword search to locate relevant classes/methods:

• Authentication (keywords: login, auth, signIn, register, token, refresh, session, OAuth, credential, password, biometric, OTP, 2FA): Trace UI input -> validation -> API call -> token storage
• Payment/Transaction (keywords: payment, pay, purchase, checkout, transaction, order, billing, subscription): Trace cart -> payment method -> API call -> confirmation
• Data Encryption/Decryption (keywords: encrypt, decrypt, cipher, AES, RSA, keystore, KeyChain, SecretKey, HMAC): Trace data input -> key retrieval -> crypto operation -> storage/transmit
• File Upload/Download (keywords: upload, download, multipart, FormData, InputStream, OutputStream): Trace file selection -> processing -> network transfer
• Deep Link Handling (keywords: deeplink, scheme, onNewIntent, handleURL, intent): Trace URL received -> parsed -> routed to handler

1. Output per flow: Generate a Mermaid diagram + Key Classes table (class, role, file location) + Security Notes (e.g., "tokens stored in SharedPreferences without encryption"). Use sequenceDiagram for multi-component interactions, flowchart TD for navigation maps, flowchart LR for linear call chains. If source is obfuscated, note this and provide best-effort mapping.

---

Flutter Pipeline (Dart AOT snapshot — libapp.so)

Flutter apps compile Dart ahead-of-time into a native ELF snapshot, libapp.so (paired with libflutter.so). classes.dex holds only the thin plugin/shell — app logic, endpoints, and keys are invisible to jadx. Whenever lib//libapp.so exists, run both the r2flutter metadata pass

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: alvinhayy
• Source: alvinhayy/Mobile-ReverseSkill
• License: MIT

Install and usage instructions live in the source repository linked above.