What we look at first when we unpack a mobile build
Before any dynamic testing, the shipped binary tells you a lot. These are the first commands we run and what they tend to turn up.
Anything inside the app you ship to the store is public. Anyone can download it and take it apart, so we start where they would:
$ apktool d app-release.apk -o out
I: Decoding AndroidManifest.xml with resources...
$ grep -n 'exported="true"' out/AndroidManifest.xml
41: <activity android:name=".debug.AdminActivity" android:exported="true"/>
$ grep -nE 'allowBackup|usesCleartextTraffic' out/AndroidManifest.xml
12: android:allowBackup="true"
13: android:usesCleartextTraffic="true"
$ grep -rEn 'sk_live_|AKIA[0-9A-Z]{16}' out/
out/smali/com/example/pay/Config.smali:9: const-string v0, "sk_live_51H••••••••"
→ 4 findings · 1 critical (payment secret in the app) · 1 high · 2 medium
apktool d app-release.apk -o out
# Components other apps can launch without a permission
grep -n 'exported="true"' out/AndroidManifest.xml
# Backups, cleartext HTTP, debug builds shipped by mistake
grep -nE 'allowBackup|usesCleartextTraffic|debuggable' out/AndroidManifest.xml
# Keys and credentials compiled into the app
grep -rEn 'sk_live_|AKIA[0-9A-Z]{16}|-----BEGIN' out/# Exceptions to App Transport Security (plain HTTP allowed?)
plutil -p Payload/App.app/Info.plist | grep -A6 NSAppTransportSecurity
# Strings in the binary that look like secrets
strings Payload/App.app/App | grep -Ei 'secret|private_key|bearer'- Exported activities or receivers that open an internal screen with no login check.
allowBackupleft on, so app data can be pulled over adb from an unlocked phone.- Server-side API keys compiled in. Some keys are meant to be public (a restricted Maps key); a payment secret never is.
- Tokens written to logs, which end up in crash reports.
None of this needs a jailbroken device or special access. It's the ten minutes an attacker spends before deciding whether your app is worth more time.
This comes from our security review & hardening work.