Android Pentesting Mindmap:

MindMap Credit : h0tPlug1n

Setup Android Pentesting Lab

1. Download any emulator.
   • Genymotion
   • NoxPlayer
   • Android Studio

Get root Shell with ADB:

$ > adb shell
generic_x86:/ $
generic_x86:/ $ exit
$ > adb root
restarting adbd as root
$ > adb shell
generic_x86:/ #

Other Method

adb -e shell
su root
cd /system/bin
chmod 06755 su

2. Proxy Configuration
   • Export burpsuite certificate
   • Configured port and interface in burp sute.
   • Setup manul proxy in android device and enter the ip and port of burp config.
   • Send Burpsuite certificate in android and install.
   • Burp configuration done.

Check packages

#  List all installed package names
adb shell pm list packages

# List all installed packages with their APK file paths
adb shell pm list packages -f

#  (Windows PowerShell) Filter the list of packages to find ones containing "camera"
adb shell pm list packages | Select-String "camera"

#  (Linux/macOS or Git Bash) Filter the list of packages for "camera"
adb shell pm list packages | grep camera

Setup Frida server

• Check architecture and download frida-server

# Check androi architecture
adb shell getprop ro.product.cpu.abi

#  Step 1: Push frida-server to Android device
adb push frida-server-x86_64 /data/local/tmp/

#  Step 2: Set executable permissions
adb shell "chmod 755 /data/local/tmp/frida-server-x86_64"

#  Step 3: Start frida-server in background
adb shell
# Inside the shell:
su
/data/local/tmp/frida-server-x86_64 > /dev/null 2>&1 &

#  Step 4: Verify frida-server is running
ps | grep frida
netstat -an | grep 27042

#  Optional: From PC, test if Frida server is responding
frida-ps -U

SSL Pinning Bypass using Frida

# Run Frida to bypass SSL pinning using a custom script
frida -U -f com.example.app -l ssl-fridascript.js

# Run Frida to bypass SSL pinning using a public script from Frida's Codeshare
frida --codeshare pcipolloni/universal-android-ssl-pinning-bypass-with-frida -f YOUR_BINARY

# Use Objection to bypass SSL pinning dynamically on the app (with Frida)
objection --gadget com.example.app explore --disable-ssl-pinning

Explanation of Flags

- -U   : Connects to a USB-connected Android device
- -f   : Specifies the package name to spawn (e.g., com.example.app)
- -l   : Loads the provided Frida script (e.g., ssl-fridascript.js)

Root Detection Bypass:

# Run Frida to bypass SSL pinning using a custom script
frida -U -f com.example.app -l ssl-fridascript.js

# Run Frida to bypass SSL pinning using a public script from Frida's Codeshare
frida --codeshare pcipolloni/universal-android-ssl-pinning-bypass-with-frida -f YOUR_BINARY

# Use Objection to bypass SSL pinning dynamically on the app (with Frida)
# This command uses Objection, a Frida-based tool, to disable SSL pinning dynamically on the app
objection --gadget com.example.app explore --disable-ssl-pinning

# Use Objection to bypass root detection on the app dynamically
# This command uses Objection to bypass root detection mechanisms and provide an interactive shell for further exploration
objection --gadget com.example.app explore --disable-root-detection

Emulator Bypass

#root and emulator bypass
frida --codeshare cubetech126/root-and-emulator-detection-bypass -f YOUR_BINARY

Useful Frida and ADB Commands

# Check if frida-server is running on the device
adb shell "ps -e | grep frida-server"

# List all installed packages with APK paths
adb shell "pm list packages -f"

# List all running applications with identifiers (name, PID, etc.)
frida-ps -Ua

# List all applications with detailed metadata
frida-ps -Uai

---

SSL Unpinning using Xposed Module (Alternative Method)

1. Clone the SSL Unpinning Xposed module:

   git clone https://github.com/ac-pm/SSLUnpinning_Xposed.git

2. Navigate to the directory:

   cd SSLUnpinning_Xposed

3. Install the APK:

   adb install mobi.acpm.sslunpinning_latest.apk

4. Open the installed app on the Android device and enable SSL unpinning.

Requires a rooted device with Xposed Framework or LSPosed installed.

---

Basics of Android

Android Manifest file

An Android Manifest file (AndroidManifest.xml) is a crucial part of any Android app. It provides essential information to the Android system, including the app's package name, components (activities, services, broadcast receivers, content providers), permissions, and hardware/software requirements.

A a comprehensive yet concise description of the Android terminologies from your image, along with examples:

---

1. Activity

• Definition: Represents a single screen with a user interface in an app.
• Example: A login screen (LoginActivity) or a home screen (HomeActivity).

---

2. Content Provider

• Definition: Manages access to a structured set of data, often shared between apps.
• Example: Contacts app provides contacts data via ContentProvider.

---

3. Content Resolver

• Definition: Acts as a client API to communicate with a ContentProvider.
• Example: Fetching contacts from the phone's ContactsProvider:

  Cursor cursor = getContentResolver().query(ContactsContract.Contacts.CONTENT_URI, null, null, null, null);

---

4. Broadcast Receiver

• Definition: Responds to system-wide or app-specific broadcast messages.
• Example: Receiving a broadcast when the device's battery is low:

  public class BatteryReceiver extends BroadcastReceiver {
      @Override
      public void onReceive(Context context, Intent intent) {
          // Handle the battery low broadcast
      }
  }

---

5. Intent

An Intent is a messaging object in Android used to communicate between components or trigger an action. It can either target components within the application or outside of it.

Types of Intents:

1. Explicit Intent:

   • Targets components within the application by explicitly specifying the name of the target component (e.g., activity, service, or broadcast receiver).
   • Example: Switching from one activity to another within the app:

     Intent intent = new Intent(this, SecondActivity.class);
     startActivity(intent);

2. Implicit Intent:

   • Targets components outside the application by specifying a general action. The Android system resolves the intent and finds an appropriate external app to handle the action.
   • Example: Opening a webpage in a browser:

     Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.example.com"));
     startActivity(intent);

---

6. Intent Filter

• Definition: Declares the capabilities of a component (like an Activity) to handle specific intents.
• Example: Enabling an activity to handle share actions:

  <intent-filter>
      <action android:name="android.intent.action.SEND" />
      <category android:name="android.intent.category.DEFAULT" />
      <data android:mimeType="text/plain" />
  </intent-filter>

---

7. Intent Resolution

• Definition: The process of matching an intent with a suitable Intent Filter.
• Example: Resolving an implicit intent to open a web page in the browser.

---

8. Services

• Definition: Background tasks running without a user interface.
• Example: Playing music in the background via MediaPlayerService.

---

Indentify and exploit components

Test Area	What to Check	Command / Example	Possible Impact
Exported Activity	Unauthorized screen access	adb shell am start -n com.app/.AdminActivity	Auth bypass
Deep Link	Parameter tampering	myapp://transfer?amount=9999	Business logic abuse
Intent Extras	Trusted external input	--es role admin	Privilege escalation
Broadcast Receiver	Sensitive broadcast actions	adb shell am broadcast -a com.app.RESET	Unauthorized actions
Service	Exported service misuse	adb shell am startservice -n com.app/.SyncService	Internal function abuse
Content Provider	Data exposure	adb shell content query --uri content://app/users	Sensitive data leak
WebView Deep Link	Arbitrary URL loading	myapp://open?url=https://evil.com	Phishing/XSS
Intent Redirection	Nested intent forwarding	Passing malicious intent	Protected activity access
Manifest Review	Exported components	Search android:exported="true"	Attack surface discovery
Deep Link Discovery	URI schemes	Search <intent-filter>	Entry point discovery

AndroidManifest.xml Vulnerable configuration and Mitigation:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.vulnerableapp">

    <!-- VULNERABILITY: Outdated minSdkVersion -->
    <!-- RISK: Using a low minSdkVersion (e.g., 16) means the app could run on devices with old security mechanisms, exposing it to known vulnerabilities. -->
    <!-- SOLUTION: Set a higher minSdkVersion to exclude outdated, insecure Android versions. -->
    <uses-sdk
        android:minSdkVersion="16"  <!-- Very low API level -->
        android:targetSdkVersion="30"  <!-- Not targeting the latest SDK -->
        android:maxSdkVersion="31" />  <!-- RISK: Restricting maxSdkVersion limits future OS features. -->
    <!-- SOLUTION: Always target the latest stable SDK version. -->

    <!-- General Permissions -->
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_CONTACTS" />
    <uses-permission android:name="android.permission.SEND_SMS" />
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    <uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW" />
    <!-- SOLUTION: Only request permissions necessary for your app's functionality. Over-permissioning increases risk. -->

    <application
        android:allowBackup="true"  <!-- VULNERABILITY: Backup of app data can lead to sensitive data leaks -->
        android:debuggable="true"  <!-- VULNERABILITY: Enables debugging in production -->
        android:usesCleartextTraffic="true"  <!-- VULNERABILITY: Allows unencrypted communication -->
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:theme="@style/AppTheme">

        <!-- Exported Activities -->
        <activity android:name=".MainActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <!-- VULNERABILITY: Exported sensitive activity -->
        <activity android:name=".SensitiveActivity"
            android:exported="true">
            <intent-filter>
                <action android:name="com.example.SENSITIVE_ACTION" />
            </intent-filter>
        </activity>
        <!-- SOLUTION: Use `android:exported="false"` and restrict with permissions if needed. -->

        <!-- Content Provider Vulnerabilities -->
        <provider
            android:name=".VulnerableProvider"
            android:authorities="com.example.vulnerableapp.provider"
            android:exported="true"
            android:grantUriPermissions="true" />
        <!-- VULNERABILITY: Exposes sensitive app data to unauthorized access. -->
        <!-- SOLUTION: Set `android:exported="false"` and use permissions for accessing the provider. -->

        <!-- Broadcast Receiver Vulnerabilities -->
        <receiver android:name=".GlobalBroadcastReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED" />
            </intent-filter>
        </receiver>
        <!-- VULNERABILITY: Allows unauthorized apps to send malicious broadcasts -->
        <!-- SOLUTION: Use `android:permission` to restrict access or set `android:exported="false"`. -->

        <!-- VULNERABILITY: Broadcast receiver for sensitive data -->
        <receiver android:name=".SensitiveBroadcastReceiver"
            android:exported="true">
            <intent-filter>
                <action android:name="com.example.SENSITIVE_BROADCAST" />
            </intent-filter>
        </receiver>
        <!-- SOLUTION: Use permissions or limit the exported status. -->

        <!-- Services Vulnerabilities -->
        <service android:name=".BackgroundService"
            android:exported="true" />
        <!-- VULNERABILITY: Allows unauthorized apps to interact with this service -->
        <!-- SOLUTION: Set `android:exported="false"` unless interaction is explicitly required. -->

        <!-- File Provider Vulnerability -->
        <provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="com.example.vulnerableapp.fileprovider"
            android:exported="true"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/file_paths" />
        </provider>
        <!-- VULNERABILITY: Exposes app files to other apps -->
        <!-- SOLUTION: Set `android:exported="false"` and restrict URI permissions. -->

        <!-- Task Hijacking Vulnerability -->
        <activity android:name=".LoginActivity"
            android:launchMode="singleTask"
            android:taskAffinity="com.example.vulnerableapp.external" />
        <!-- VULNERABILITY: External tasks can hijack user navigation -->
        <!-- SOLUTION: Use default `taskAffinity` unless explicitly required. -->

        <!-- Dangerous Permissions -->
        <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
        <!-- VULNERABILITY: Sensitive data can be written to insecure external storage -->
        <!-- SOLUTION: Use `Scoped Storage` API and avoid using `WRITE_EXTERNAL_STORAGE`. -->

        <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
        <!-- VULNERABILITY: Any app can read insecure external storage -->
        <!-- SOLUTION: Store sensitive data in internal storage or encrypted locations. -->

        <!-- Dangerous Service -->
        <service android:name=".UnprotectedService"
            android:exported="true">
            <intent-filter>
                <action android:name="com.example.UNSAFE_SERVICE_ACTION" />
            </intent-filter>
        </service>
        <!-- VULNERABILITY: Unauthorized apps can interact with this service -->
        <!-- SOLUTION: Use permissions or set `android:exported="false"`. -->

    </application>
</manifest>

Top 20 vulnerabilities in the AndroidManifest.xml file:

1. Outdated minSdkVersion

   • Risk: Allows the app to run on older Android versions with outdated security features.
   • Solution: Use a higher minSdkVersion to enforce better security mechanisms.

2. Not Targeting the Latest targetSdkVersion

   • Risk: Misses modern Android security and privacy improvements.
   • Solution: Always target the latest stable SDK version.

3. Backup Data Exposure (android:allowBackup)

   • Risk: Allows attackers to retrieve app data through backup mechanisms.
   • Solution: Set android:allowBackup="false" unless absolutely necessary.

4. Debuggable Mode Enabled (android:debuggable)

   • Risk: Enables debugging in production, which attackers can exploit.
   • Solution: Ensure android:debuggable="false" for release builds.

5. Cleartext Traffic (android:usesCleartextTraffic)

   • Risk: Allows unencrypted HTTP communication, exposing data.
   • Solution: Set android:usesCleartextTraffic="false" and enforce HTTPS.

6. Exported Activities (android:exported="true")

   • Risk: Makes activities accessible to external apps without proper validation.
   • Solution: Set android:exported="false" unless explicitly required.

7. Exported Services

   • Risk: Unprotected services can be abused by malicious apps.
   • Solution: Set android:exported="false" for sensitive services.

8. Exported Content Providers

   • Risk: Exposes app data to unauthorized access.
   • Solution: Use android:exported="false" and restrict access with permissions.

9. Insecure External Storage Permissions

   • Risk: Sensitive data written to external storage can be accessed by other apps.
   • Solution: Store sensitive data in internal storage or encrypt it.

10. Excessive Permissions

    • Risk: Requesting unnecessary permissions increases the attack surface.
    • Solution: Minimize permissions to only those required for functionality.

11. Global Broadcast Receivers

    • Risk: Allows unauthorized apps to trigger receivers and potentially execute sensitive actions.
    • Solution: Use permissions to restrict broadcast receiver access.

12. Task Hijacking via taskAffinity

    • Risk: Poorly configured taskAffinity allows other tasks to impersonate your app's task.
    • Solution: Use default taskAffinity unless explicitly required.

13. Hardcoded Credentials in Metadata

    • Risk: API keys or secrets stored in the manifest can be extracted by attackers.
    • Solution: Store sensitive data securely (e.g., encrypted or in the backend).

14. Unprotected File Providers

    • Risk: Exposes private app files to unauthorized access.
    • Solution: Limit access to file providers with permissions and proper URI configuration.

15. Dynamic Permissions Misuse

    • Risk: Declaring permissions dynamically without proper checks can lead to privilege escalation.
    • Solution: Validate dynamically granted permissions properly.

16. Excessive Exported Activities

    • Risk: Exposing too many activities to external apps increases attack vectors.
    • Solution: Only export activities meant for external interaction.

17. Implicit Broadcasts

    • Risk: Apps can intercept sensitive implicit broadcasts and misuse them.
    • Solution: Use explicit broadcasts whenever possible.

18. Unencrypted Backups

    • Risk: Sensitive app data in backups can be accessed or tampered with.
    • Solution: Encrypt backup data or disable backups if unnecessary.

19. Insecure Intent Handling

    • Risk: Components receiving unvalidated intents are vulnerable to Intent spoofing attacks.
    • Solution: Validate all data passed through intents.

20. Excessive maxSdkVersion

    • Risk: Restricts compatibility with newer Android versions, breaking functionality and missing security updates.
    • Solution: Avoid using maxSdkVersion unless necessary.

---

Awesome Reference Links

Title	Link	Credit
Hail Frida: The Universal SSL Pinning Bypass for Android	Link	Author: @infosecwriteups
It's All About Android SSL Pinning Bypass and Intercepting Proxy-Unaware Applications	Link	Author: @kishorbalan
My Fav 7 Methods for Bypassing Android Root Detection	Link	Author: @kishorbalan
10 Vulnerable Android Applications for Beginners to Learn Hacking	Link	Author: Anugrah SR
Android App Pentest Workbook	Link	SecurityBoat
Mobile Pentesting AndroGoat Assessment Walkthrough	Link	Author: @infosecwriteups

Vulnerable APK

Name	APK Download Link	Credit
InjuredAndroid	Playstore Link	Creator: @B3nac
	GitHub Link	Walkthrough: YouTube
Android AppSec (Kotlin)	Playstore Link	Creator: @hpandro1337, @_RaviRamesh
	CTF Link	Walkthrough: YouTube Channel
Damn-Vulnerable-Bank	APK Download	Creator: @rewanthtammana, @akshanshjaiswl, @hkh4cks
	GitHub Link	Walkthrough: Website
InsecureShop	APK Download	Creator: Gaurang Bhatnagar
	GitHub Link	Walkthrough: Docs
AndroGoat	APK Download	Creator: @satish_patnayak
	GitHub Link	Walkthrough: Medium
Crackmes	APK Download	Creator: @muellerberndt, OWASP-MSTG
	GitHub Link	Walkthrough: GitHub
Android InsecureBank v2	APK Download	Creator: Dinesh Shetty
	GitHub Link
Oversecured Vulnerable App	GitHub Link	Creator: @oversecured
	Blog Link
DIVA Android	APK Download	Creator: @payatulabs
	Walkthrough
MSTG Hacking Playground	GitHub Link	Creator: Sven Schleier
	Java App
	Kotlin App

---

---

MOBILE PENTESTING CHECKLIST

Information Gathering

☐ Identify the target mobile platform (iOS, Android).

• Determine the OS version and device details.

☐ Gather information about the mobile application.

• Tools: Google Play Store, Apple App Store, Mobile Application Binary
• Command: adb pull <app_path>
• Look for app version, developer information, and permissions.

☐ Identify the app's backend services and APIs.

• Discover endpoints, authentication mechanisms, and data flow.

☐ Discover the app's functionality and features.

• Create a detailed app map with all functionalities.

☐ Enumerate app permissions and security configurations.

• Tools: Mobile Device Settings, Mobile Application Permissions
• Command: Check app settings and permissions
• Identify overly permissive or unnecessary permissions.

Static Analysis

☐ Decompile the mobile app binary.

• Tools: JADX, JADX-GUI (for Android), Hopper Disassembler (for iOS)
• Command: jadx -d <output_dir> <app_apk>
• Analyze the source code for vulnerabilities.
• Examine the manifest file for declared permissions.

☐ Inspect hardcoded credentials and sensitive data.

• Search for API keys, passwords, or encryption keys in the code.

☐ Identify code injection points and potential security flaws.

• Look for SQL injection, command injection, and other injection vulnerabilities.

☐ Review the app's encryption and data storage methods.

• Tools: Apktool (for Android), Class-dump (for iOS)
• Command: apktool d <app_apk> -o <output_dir>
• Verify how data is encrypted, stored, and accessed.

1. Cryptography:

   • Look for use of encryption algorithms and verify implementation correctness.
   • Check for hardcoded keys, weak encryption methods, or use of insecure cryptographic algorithms.

2. Code Obfuscation:

   • Check for obfuscation techniques used to hide code.
   • Verify that obfuscation does not hide malicious code.

3. API Usage:

   • Verify absence of insecure or vulnerable APIs.
   • Look for APIs allowing unauthorized access or data leakage.

4. Hardcoded Sensitive Information:

   • Look for insecure storage of sensitive data.
   • Check for hardcoded database queries, passwords, keys, or URLs.

5. External Libraries:

   • Verify absence of insecure or vulnerable third-party libraries.

6. Integrity Checks:

   • Look for integrity checks to prevent tampering with code.

7. Native Code:

   • If present, verify secure compilation of native code.

8. Web View Related Checks:

   • setJavaScriptEnabled(): Ensure proper validation of input data to prevent injection of malicious JavaScript code.
   • setAllowFileAccess(): Validate input data to prevent unauthorized access/modification of local files.
   • addJavascriptInterface(): Validate input data to prevent execution of arbitrary Java code.
   • runtime.exec(): Prevent injection of malicious input data to avoid execution of arbitrary shell commands.

9. Root Detection Implementation Details:

   • Verify implementation details of root detection mechanisms.

10. SSL Pinning Implementation Details:

• Review implementation details of SSL pinning to ensure secure communication.

Dynamic Analysis

☐ Install and run the app on a mobile device or emulator.

• Tools: Android Emulator (for Android), Xcode Simulator (for iOS)
• Observe app behavior in a controlled environment.

☐ Intercept and manipulate network traffic.

• Tools: Burp Suite, Charles Proxy, Wireshark
• Analyze API calls, data transmission, and encryption.
• Test for insecure data storage and transmission.

☐ Test for authentication and session management vulnerabilities.

• Attempt session fixation, session hijacking, or token manipulation.

☐ Execute runtime analysis for code behavior.

• Tools: Frida, Cycript, LLDB (for iOS)
• Command: Use Frida scripts for dynamic analysis
• Test for code manipulation, function hooking, and runtime attacks.

Authentication and Authorization

☐ Test for weak authentication mechanisms.

• Try common credentials, default passwords, or weak password policies.
• Check for credential stuffing attacks.

☐ Attempt brute force attacks on login screens.

• Tools: Hydra, Burp Suite, OWASP ZAP
• Command: hydra -l <username> -P <password_file> <target>
• Test for account lockouts, CAPTCHA bypass, or rate limiting issues.

☐ Verify session management security.

• Test for session fixation, session timeout, and session ID randomness.
• Check for secure token storage and transmission.

☐ Test for privilege escalation vulnerabilities.

• Check role-based access control (RBAC) and permissions.

☐ Check for insecure direct object references.

• Test for unauthorized data access through object manipulation.

Data Validation and Security

☐ Test for input validation vulnerabilities.

• Try SQL injection, command injection, and XSS attacks.
• Check for input validation on all user inputs.

☐ Verify encryption of sensitive data.

• Check encryption algorithms and key management.
• Test for data leakage through logs or memory.

☐ Look for insecure data transmission.

• Inspect SSL/TLS configurations and certificate validation.
• Test for SSL pinning bypass.

☐ Test for secure file handling.

• Check file I/O operations, file permissions, and storage.

☐ Verify the use of secure coding practices.

• Check for OWASP Mobile Top 10 vulnerabilities.

Runtime Manipulation

☐ Use runtime analysis tools to modify app behavior.

• Inject code, intercept API calls, and manipulate data.

☐ Test for API vulnerabilities.

• Check for API rate limiting, input validation, and authentication.

☐ Attempt to execute malicious code on the device.

• Test for privilege escalation, root/jailbreak detection bypass, and malware installation.

☐ Test for reverse engineering and tampering detection.

• Check for code obfuscation, anti-debugging, and app integrity checks.

Reporting

☐ Document findings, vulnerabilities, and their impact.

• Create a detailed report with evidence and screenshots.