Lab: Mobile App Reverse Engineering

This lab makes the first lesson of the mobile attack-surface map concrete: the app ships to the attacker’s device. Anyone who has it can take it apart. You will decompile a training app and find secrets its developers wrongly believed were hidden.

Rules of engagement

Decompile only apps that are built for this — deliberately-vulnerable training apps — or your own debug builds. Reverse-engineering proprietary apps you don’t own can breach their terms and local law. We use purpose-built targets.

Setup

On Windows?

Install jadx with winget install jadx (or run the release’s jadx-gui.bat), and unzip an APK with tar -xf app.apk or 7-Zip. WSL2 works too for the command-line jadx. Full details on Windows Setup.

Get the tools and a safe target:

# macOS
brew install jadx        # decompiler (also try `jadx-gui`)
# Linux: download jadx from github.com/skylot/jadx/releases

Target options (pick one — all are intentionally insecure training apps):

• DIVA (Damn Insecure and Vulnerable App)
• InsecureBankv2
• An OWASP MASTG Android crackme, or your own app-debug.apk

You only need the .apk file on disk.

The exercise

1. An APK is just a ZIP — look inside.

   unzip -l target.apk

   You’ll see classes.dex (the compiled code), resources.arsc, assets, and AndroidManifest.xml. Nothing here is secret — it’s all sitting on the device.

2. Decompile to readable Java.

   jadx-gui target.apk      # opens a browsable source tree
   # or: jadx -d out/ target.apk

   The compiled app becomes near-original source you can read class by class.

3. Read the manifest.

   Open AndroidManifest.xml. Note the permissions it requests (does a calculator really need SMS?) and any exported components other apps could call. Over-permissioning is map pin #4.

4. Hunt for hardcoded secrets (map pins #1 and #9).

   In jadx’s search, look for:

   http     apiKey     api_key     password     secret     token     AES     Base64

   You will typically find API keys, backend URLs, or encryption keys baked into the code — the developer assumed no one would look. Anyone with the APK now has them.

5. (Optional) Spot insecure storage & logging.

   Search for SharedPreferences, openFileOutput, or Log.d to find secrets written to the device in plaintext or leaked to logs — map pin #2.

What you just proved

Security that depends on the client being opaque is no security at all. Everything in the app — keys, logic, URLs — is visible to anyone who downloads it. Real protection lives on the server.

How it’s defended

• Hardcoded secrets → keep secrets on the server; have the app request short-lived tokens; rotate and tightly scope keys; never ship master keys in the binary.
• Reverse engineering → assume the client is fully visible; enforce every real check server-side. Obfuscation and tamper-detection raise the cost but are speed bumps, not walls.
• Over-permissioning / insecure storage → request only needed permissions; store secrets in the OS Keystore/Keychain, encrypted; never log sensitive data.

Debrief

• Re-read pins 1 and 9 on the mobile map — you’ve now lived them.
• Connect it to India’s loan-app problem (map pin #4/#5): the same decompilation reveals apps that scrape SMS and contacts.
• The fix is architectural, not cosmetic: move trust off the device. That’s the mindset the Trinetra capstone reinforces.