BBC Ch 23: Android Hacking

Source: Bug Bounty Bootcamp by Vickie Li

Android apps communicate with the same backend APIs as web apps. Many web vulnerabilities (IDORs, SQLi, XSS, auth bugs) appear in the mobile surface. Android-specific issues include certificate pinning bypass, hardcoded secrets in APKs, and insecure local storage.

Route Android traffic through Burp Suite to intercept HTTPS:

1. Configure Burp listener on 0.0.0.0:8080
2. On the device: Settings → Wi-Fi → proxy → manual → enter Burp machine IP:8080
3. Install Burp CA cert on the device (download from http://burp via the device browser)
4. For Android 7+: user-installed CAs are not trusted by apps; use a rooted device or emulator

Apps with certificate pinning reject Burp's CA. Bypass options:

Frida (dynamic instrumentation):

frida-server  # running on device
frida -U -f com.target.app -l ssl_bypass.js --no-pause

Objection (Frida-based, simpler interface):

objection -g com.target.app explore
android sslpinning disable

After disabling pinning, Burp intercepts all HTTPS traffic from the app.

An APK is a ZIP file. Key contents:

• AndroidManifest.xml – permissions, exported activities/receivers/providers, intent filters
• classes.dex – compiled Dalvik bytecode
• res/ – resources including strings.xml (often contains hardcoded secrets)
• assets/ – bundled files, sometimes including config and certificates
• lib/ – native .so libraries

ADB (Android Debug Bridge):

adb devices                         # list connected devices/emulators
adb install target.apk              # install APK
adb pull /data/data/com.target.app/ # pull app data directory (requires root)
adb push file.txt /sdcard/          # push file to device
adb shell                           # interactive shell on device

Apktool (decompile/recompile APK):

apktool d target.apk -o output/    # decompile to Smali + resources
apktool b output/ -o repackaged.apk  # rebuild

Frida (dynamic instrumentation): Hook Java methods at runtime, bypass cert pinning, trace function calls.

MobSF (Mobile Security Framework): Automated static + dynamic analysis. Upload APK to get a full vulnerability report: exported components, hardcoded secrets, insecure API usage, permissions audit.

Decompile the APK with Apktool or jadx, then:

grep -r "password\|secret\|api_key\|token\|AWS\|Bearer" output/
grep -r "http://" output/           # cleartext HTTP endpoints
cat output/res/values/strings.xml   # hardcoded strings
cat output/AndroidManifest.xml      # exported components

Exported activities, content providers, and broadcast receivers can be triggered by other apps or adb:

adb shell am start -n com.target.app/.AdminActivity
adb shell content query --uri content://com.target.app/users

• Route traffic through Burp; replay and manipulate API requests
• Look for the same bugs as web: IDORs (change user_id), broken auth, SQLi in search fields, XSS in WebViews
• Check local storage for sensitive data:

adb shell
run-as com.target.app
ls databases/
cat databases/app.db | strings
cat shared_prefs/*.xml

Apps often store data in unencrypted SQLite files:

adb pull /data/data/com.target.app/databases/app.db
sqlite3 app.db
.tables
SELECT * FROM users;

1. Set up Burp proxy; bypass cert pinning with Objection (android sslpinning disable) to intercept HTTPS.
2. Decompile APK with Apktool or jadx; grep strings.xml and source for hardcoded credentials, API keys, and HTTP endpoints.
3. Check AndroidManifest.xml for exported components accessible without permission; trigger them via adb.
4. Pull local databases and shared preferences; check for sensitive unencrypted data.
5. Replay and manipulate intercepted API requests looking for IDORs, broken auth, SQLi, and XSS – same methodology as web.