📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
Every Android APK is a ZIP file containing Java bytecode, resources, and a manifest. Unzip it, decompile it, and you have the developer’s source code in a readable form. The hardcoded API key, the debug endpoint, the credentials baked in for “development only” — they’re all there. I’ve found production AWS credentials, Stripe secret keys, and internal admin panel URLs in publicly available apps this way. Here’s the exact workflow that takes any APK from download to decompiled source in 15 minutes.
🎯 What You’ll Learn
Understand the APK file structure and what each component contains
Decompile any APK to readable Java source using JADX
Decode resources and manifest with apktool
Find hardcoded secrets, API keys, and debug endpoints systematically
Use MobSF for automated static analysis
⏱️ 30 min read · 3 exercises #### 🔗 Related Resources - Tools needed: JADX (jadx-gui), apktool, MobSF (Docker) — all free, all open source - Test APK: OWASP MASTG Hacking Playground — intentionally vulnerable Android apps ### 📋 Reverse Android APK — Step by Step 1. APK Structure — What You’re Actually Looking At 2. JADX — Decompile Java Source in One Click 3. apktool — Decode Resources and Manifest 4. Finding Hardcoded Secrets Systematically 5. MobSF — Automated Static Analysis APK reverse engineering is one of the highest-ROI skills in mobile bug bounty — the same methodology that finds hardcoded secrets in one app works on every Android app. The Kali Linux Commands reference has all the grep patterns for secret hunting. The ethical hacking hub covers the broader mobile security attack surface.
APK Structure — What You’re Actually Looking At
My first step on any APK analysis is understanding the file structure before opening any tool. An APK is a ZIP file. Renaming it to .zip and extracting it gives you the raw contents — useful for a quick look, but not for reading code. The code is in classes.dex (compiled Dalvik bytecode) — readable only after decompilation. Here’s what each file contains.
APK STRUCTURE — KEY FILESCopy
Quick extraction (rename to .zip first)
mv app.apk app.zip && unzip app.zip -d app_extracted/
Key files and what they contain
AndroidManifest.xml → permissions, activities, services (binary encoded)
classes.dex → compiled Java bytecode → needs JADX to decompile
classes2.dex → additional bytecode (multi-dex apps)
res/ → UI layouts, strings, images
assets/ → raw files shipped with app (configs, databases)
lib/ → native libraries (.so files)
META-INF/ → signature files, certificate
Most valuable for finding secrets
classes.dex → decompile with JADX → find hardcoded strings in Java source
assets/ → config files, local databases, certificates
res/values/ → strings.xml — app-wide string constants including API endpoints
JADX — Decompile Java Source in One Click
JADX is the tool I reach for first — it gives the most readable source output of any decompiler. JADX is the tool I use first on every APK. It converts the .dex bytecode back to readable Java source code — not perfect reconstruction, but close enough to find logic, API calls, hardcoded values, and authentication flows. The GUI version makes navigation trivial.
JADX — INSTALLATION AND USAGECopy
Install JADX (Kali Linux)
sudo apt install jadx -y
GUI — drag and drop APK, browse source tree
jadx-gui app.apk &
CLI — export all decompiled source to directory
jadx -d output_dir/ app.apk
Output: output_dir/sources/ (Java files) + output_dir/resources/
After decompile — search for high-value patterns
grep -rn “api_key|apikey|API_KEY|secret|password|token” output_dir/sources/ –include=”.java”
grep -rn “http://|https://” output_dir/sources/ –include=”.java” | grep -i “dev|debug|test|internal|admin”
securityelites.com
JADX — Decompiled Source with Hardcoded API Key
com.example.app.network.ApiClient.java
public class ApiClient {
private static final String BASE_URL = “https://api.example.com”;
private static final String API_KEY = “sk-prod-a8f3d9e2b1c7f4…”;
private static final String DEBUG_URL = “http://internal.example.com:8080/debug”;
public static OkHttpClient getClient() {
return new OkHttpClient.Builder()
.addInterceptor(chain -> chain.proceed(
chain.request().newBuilder()
.addHeader(“X-API-Key”, API_KEY).build())).build();
FINDINGS: production API key + internal debug endpoint — both report-worthy
📸 JADX decompiled source showing two findings in a single class file: a hardcoded production API key (sk-prod-…) and an internal debug URL pointing to port 8080. These appear in the decompiled Java exactly as the developer wrote them. The API key is used in every request header — any app user could extract it by reversing the APK. The debug URL exposes an internal endpoint that may not be accessible from the internet but could be found via SSRF or internal recon. Both are High severity findings for a bug bounty report.
apktool — Decode Resources and Manifest
apktool decodes the binary-encoded AndroidManifest.xml and res/ resources into human-readable XML. The manifest is critical — it shows every permission the app requests, every exported activity (potential deeplink attack surface), and every declared service. These are attack surface components JADX alone doesn’t surface cleanly.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)