APK analysis (reversing Android apps)

When a web service offers an Android app to download, that .apk is a goldmine: it's just a ZIP bundling the app's code, resources and configuration. Because the mobile client needs to know which API to talk to and how to authenticate, it usually ships with endpoints, subdomains, keys and sometimes tokens baked in that you can't see from the outside.

The usual flow is to decompile the package and grep through the result. apktool disassembles the .apk into a readable form (.smali files, the Dalvik bytecode as text, plus resources and the AndroidManifest.xml):

apktool d instant.apk

From there you grep the decompiled tree for interesting strings. API domains and paths reveal the real surface (often vhosts that weren't linked anywhere on the site, see vhost fuzzing):

grep -r "example.htb" .          # embedded subdomains and endpoints
grep -r "api/v1" .               # API routes
grep -rE "ey[A-Za-z0-9_-]+\." .   # candidate JWTs (they always start with "ey")

The juiciest find is a hardcoded secret: an API key, a password or, as here, an admin JWT left in a test class. That token grants the privileged role against the API directly, no need to break authentication.

Why. Developers assume that whatever lives inside the binary is "hidden", but anyone who downloads the app can read it. The manifest's network_security_config.xml also lists the domains the app trusts, which confirms the vhosts worth attacking.

How to detect it. Analysing the .apk is offline and leaves no trace, but its fruit does: the use of a secret that only lives in the mobile client (an API key, an embedded admin JWT) from a client that isn't the app is the signature, a different User-Agent, missing the app's own headers, or from a new IP. On the server, direct requests to endpoints/vhosts that only appeared in the APK (never linked on the site) shortly after an .apk download is the other indicator. Rotating/expiring those tokens renders the find useless.

Defence. Don't embed credentials or tokens in the client; issue short-lived per-user tokens; obfuscation is not protection (it only delays). Any secret shipped in the binary must be treated as public.