Android recon for Bug Bounty hunters from APK extraction to ...

src/mobile-pentesting/android-app-pentesting/README.md

@@ -71,6 +71,103 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
 First of all, for analysing an APK you should **take a look to the to the Java code** using a decompiler.\
 Please, [**read here to find information about different available decompilers**](apk-decompilers.md).
 
+### Android APK Recon & Static Attack Surface Mapping
+
+#### 1. Acquire authentic builds
+- Use [APKeep](https://github.com/EFForg/apkeep) to pull the exact package/region without a device:
+
+```bash
+cargo install --git https://github.com/EFForg/apkeep.git
+apkeep -a com.instagram.android .
+apkeep -a com.instagram.android -o 'arch=arm64-v8a' .
+```
+
+- Capture a fresh Google Play `oauth2_4/...` cookie (DevTools → Network) and pass it with `-t` to fetch hotfixes or region-locked builds: `apkeep -a <pkg> -d google-play -e you@gmail.com -t oauth_token .`
+- Mirror APK archives (APKCombo/APKMirror) and diff releases; comparing `res/` and source exports between `vX` and `vX+1` exposes deprecated endpoints, new pinning, or features that still exist server-side.
+
+#### 2. Pull device builds & handle split APKs
+- Dump what is actually installed (post dynamic module downloads) using the extraction commands already shown in [Other interesting tricks](#other-interesting-tricks).
+- Keep every `split_config.*` module because locale/ABI-only packages often ship payment, admin, or debug flows that never appear in the base APK. Merge splits with APKEditor/APKTool only to ease analysis so split-only logic does not get lost.
+
+#### 3. Verify signatures before wasting time
+Run `apksigner verify --print-certs target.apk` and compare the fingerprint to a clean Play install. Mismatches usually mean you are reversing a repackaged APK, so the findings are invalid for bug bounty.
+
+#### 4. Unpack & map components with APKTool
+
+```bash
+apktool d target.apk -o target_unpacked
+```
+
+- Reconcile `AndroidManifest.xml` with the checklist in [Basic understanding of the application - Manifest.xml, strings.xml](#basic-understanding-of-the-application---manifestxml-stringsxml) and note extras such as `android:queries`, custom permissions, and risky `android:exported` + intent-filter combinations.
+- Review `res/xml/network_security_config.xml`, other `res/xml/*`, and `res/values/strings.xml` for alternate hosts, certificate pins, and feature toggles you can later abuse.
+- Diff `lib/<abi>/` per architecture to reveal ABI-specific `.so` files and native attack surface that might only load on certain devices.
+- Inspect `assets/` and bundled databases for Firebase buckets, S3/GCS endpoints, or feature-flag tables that disclose hidden flows.
+
+#### 5. Enumerate URLs and backend inventory
+- Grep `res/values/strings.xml`, Smali, and decompiled Java for markers such as `api`, `token`, `staging`, or `dev`.
+- Automate discovery with [apk2url](https://github.com/n0mi1k/apk2url):
+
+```bash
+git clone https://github.com/n0mi1k/apk2url
+./apk2url.sh target.apk
+```
+
+Feed the resulting host list to Burp/HTTP tooling and prioritize staging/admin endpoints that still accept production tokens.
+
+#### 6. Review Java logic with jadx
+Open the APK in `jadx-gui`, use `Ctrl+Shift+F` for cross-class searches, and `File → Save all` to export sources for `ripgrep`/diffing. Track how tokens are created, where crypto lives, and which network clients skip TLS validation. Hardcoded credentials stand out immediately:
+
+```java
+private static final String API_KEY = "sk_live_ABC123XYZ789";
+private static final String SECRET  = "prod_secret_key_2024";
+```
+
+Validate minimally (without touching customer data) to confirm scope, then report as credential exposure.
+
+#### 7. Catch client-side auth & role logic
+Look for authentication/authorization handled entirely on the device. Typical anti-patterns:
+
+```java
+if (username.equals("admin") && password.equals("test123")) {
+    return true;
+}
+
+public boolean verifyToken(String token) {
+    return token.startsWith("auth_");
+}
+```
+
+If the backend trusts these states, patch the Smali (see [smali-changes.md](smali-changes.md)) or hook with Frida to bypass login, forge sessions, or unlock admin panels.
+
+#### 8. Identify plaintext local storage
+- During recon, note any `SharedPreferences`, `openFileOutput`, or SQLite writes that store tokens/passwords—these map directly to the issues described in [Insecure data storage](#insecure-data-storage).
+- Strings like the following indicate instantly retrievable secrets:
+
+```java
+SharedPreferences prefs = getSharedPreferences("user_data", MODE_PRIVATE);
+prefs.edit().putString("auth_token", token).putString("password", pwd).commit();
+```
+
+Anything stored like this is recoverable via backups, rooted malware, or misconfigured `android:allowBackup`. Flag it unless the app uses `EncryptedSharedPreferences` backed by the keystore.
+
+#### 9. Audit exported intents & WebViews
+- Use the manifest map to queue tests from [Intent Injection](intent-injection.md) and [WebView Attacks](webview-attacks.md) before launching the app. Dangerous patterns include untrusted extras flowing directly into WebView or file APIs:
+
+```java
+String url = getIntent().getStringExtra("url");
+webView.loadUrl(url);
+```
+
+If you control these extras you get local file disclosure, deep-link XSS, or privilege escalation from any other app.
+
+#### 10. Build a prioritized attack list
+Document findings before proxying traffic:
+- Endpoint inventory (prod/staging/debug/admin hosts, Firebase/GCS buckets, third-party APIs).
+- Secret inventory (API keys, OAuth tokens, license keys) plus how they are used.
+- Component map (exported ICC surface, broadcast receivers, feature modules tied to specific ABIs/locales).
+- Dependency/native coverage (ABI-only `.so` files, vulnerable SDKs) to plan CVE hunts.
+- Client-side trust decisions (auth/role logic, weak token validation, insecure storage) ready for patching/hooking during dynamic testing.
+
 ### Looking for interesting Info
 
 Just taking a look to the **strings** of the APK you can search for **passwords**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** keys, **encryption**, **bluetooth uuids**, **tokens** and anything interesting... look even for code execution **backdoors** or authentication backdoors (hardcoded admin credentials to the app).
@@ -874,5 +971,7 @@ AndroL4b is an Android security virtual machine based on ubuntu-mate includes th
 - [smali-sslpin-patterns](https://github.com/aancw/smali-sslpin-patterns)
 - [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
 - [CoRPhone — Android in-memory JNI execution and packaging pipeline](https://github.com/0xdevil/corphone)
+- [Android recon for Bug Bounty hunters: from APK extraction to attack surface mapping](https://www.yeswehack.com/learn-bug-bounty/android-recon-bug-bounty-guide)
+- [APKeep documentation](https://github.com/EFForg/apkeep)
 
 {{#include ../../banners/hacktricks-training.md}}