# Android App Pentesting Checklist **1. SSL Pinning** > An SSL pinning vulnerability in an Android app occurs when the app does not properly verify the server's SSL certificate or public key during the SSL/TLS handshake process, allowing a man-in-the-middle attacker to intercept and decrypt the app's communication. * [ ] Check if SSL pinning is implemented. * [ ] Objection: Use the `android sslpinning disable` command. * [ ] Frida: Use ***frida-multiple-unpinning** -> `frida -U --codeshare akabe1/frida-multiple-unpinning -f YOUR_BINARY`* * [ ] Xposed: Install the [TrustMeAlready ↗](https://github.com/ViRb3/TrustMeAlready) or the [ *SSLUnpinning*](https://mas.owasp.org/MASTG-TOOL-0025) module. * [ ] SSL Pinning Bypass Using [APKLab](https://apklab.surendrajat.xyz/docs/user-guide/getting-started/) * [ ] Check if code manipulation is possible. **2. Root Detection** > A root detection vulnerability in an Android app occurs when the app does not properly detect and prevent access by rooted devices, allowing users to potentially gain unauthorized access to the app's data or functionality. * [ ] Check if root detection is implemented. * [ ] MagiskHide module in the Magisk application (= \v23.0) * [ ] Tampering the Smali code * [ ] Frida -> * [ ] Medusa Framework -> *We have to use the **helpers/anti\_debug** module* * [ ] Using Objection’s Common method -> ``` First convert the apk file into class files using dex2jar Analyse the class files and identify which library is being used for the root detection objection -g com.test.app explore android hooking list class_methods android hooking set return_value false ``` > *If the root detection prompt is still there on the application, just press the back button and exit from the application (don’t kill the app from background) and open it again.* > > The root detection will disappear :) * [ ] Renaming binaries. For example, in some cases simply renaming the `su` binary is enough to defeat root detection (try not to break your environment though!). * [ ] Unmounting `/proc` to prevent reading of process lists. Sometimes, the unavailability of `/proc` is enough to bypass such checks. * [ ] Using Frida or Xposed to hook APIs on the Java and native layers. This hides files and processes, hides the contents of files, and returns all kinds of bogus values that the app requests. * [ ] Hooking low-level APIs by using kernel modules. * [ ] Patching the app to remove the checks. * [ ] Check if root detection can be bypassed using Frida/Objection. **3. Emulator Detection** > An emulator detection vulnerability in an Android app occurs when the app does not properly detect and prevent access by emulators, allowing users to potentially bypass security controls or access unauthorized functionality. * [ ] Check if emulator detection is implemented. * [ ] Modifying build.prop properties * [ ] Patch the emulator detection functionality. Disable the unwanted behavior by simply overwriting the associated bytecode or native code with NOP instructions. * [ ] Use Frida or Xposed APIs to hook file system APIs on the Java and native layers. Return innocent-looking values (preferably taken from a real device) instead of the telltale emulator values. For example, you can override the `TelephonyManager.getDeviceID` method to return an IMEI value. **4. Sensitive Data in ADB Logcat Logs** > A sensitive data in ADB Logcat vulnerability in an Android app occurs when the app logs sensitive data, such as passwords or personal information, to the system log using Android Debug Bridge (ADB), potentially exposing the data to attackers or unauthorized users. * [ ] Check Logcat logs for sensitive data. * ``` adb logcat | grep "$(adb shell ps | grep | awk '{print $2}')" ``` * [ ] Check if logs can be accessed or manipulated using Frida/Objection. * [ ] Check for unencrypted requests/data in Logcat logs. **5. Sensitive Data Stored in Local Storage** > A sensitive data stored in local storage vulnerability in an Android app occurs when the app stores sensitive data, such as passwords or personal information, in unencrypted or unsecured local storage on the device, potentially exposing the data to attackers or unauthorized users. * [ ] Check both internal and external local storage for any files created by the application that contain sensitive data. * [ ] Identify development files, backup files, and old files that shouldn't be included with a production release. * [ ] Determine whether SQLite databases are available and whether they contain sensitive information. SQLite databases are stored in `/data/data//databases`. * [ ] Identify if SQLite databases are encrypted. If so, determine how the database password is generated and stored and if this is sufficiently protected as described in the "[Storing a Key](https://mas.owasp.org/MASTG/0x05d-Testing-Data-Storage/#storing-a-cryptographic-key-techniques)" section of the Keystore overview. * [ ] Check Shared Preferences that are stored as XML files (in `/data/data//shared_prefs`) for sensitive information. Shared Preferences are insecure and unencrypted by default. Some apps might opt to use [secure-preferences ↗](https://github.com/scottyab/secure-preferences) to encrypt the values stored in Shared Preferences. * [ ] Check the permissions of the files in `/data/data/`. Only the user and group created when you installed the app (e.g., u0\_a82) should have user read, write, and execute permissions (`rwx`). Other users should not have permission to access files, but they may have execute permissions for directories. * [ ] Cherck for [Ghost Files in Shared Preferences](https://valsamaras.medium.com/ghost-files-in-the-shared-preferences-8d75226c23c0) > If you have **WRITE** permissions to an app’s `shared_prefs` folder—but not overwrite rights—you can still exploit this behavior. Instead of attempting to overwrite an existing file, create the `.bak` file yourself. On the next app load, Android’s SharedPreferences logic will rename that `.bak` file to replace the original settings silently. * [ ] Check for the usage of any Firebase Real-time databases and attempt to identify if they are misconfigured by making the following network call: * `https://_firebaseProjectName_.firebaseio.com/.json` * [ ] Determine whether a Realm database is available in `/data/data//files/`, whether it is unencrypted, and whether it contains sensitive information. By default, the file extension is `realm` and the file name is `default`. Inspect the Realm database with the [Realm Browser ↗](https://github.com/realm/realm-browser-osx) **6. Sensitive Data in Application Memory** > A sensitive data in application memory vulnerability in an Android app occurs when the app stores sensitive data, such as passwords or personal information, in memory in an unencrypted or unsecured manner, potentially exposing the data to attackers or unauthorized users who have access to the device's memory. * [ ] Check for sensitive data in application memory using `fridump.py`. **7. Weak Signer Certificate** > A weak signer certificate vulnerability in an Android app occurs when the app is signed with a weak or compromised certificate, potentially allowing attackers to modify the app or gain unauthorized access to the app's functionality. * [ ] Check if the app is signed with weak algorithms like "SHA1withRSA". * [ ] Check for Janus vulnerability. * [ ] Check if the app is signed with a debug certificate. **8. Vulnerable Android Activities** > Android activities are components of an Android app that represent a screen or part of the app's user interface. A vulnerable Android activity is one that contains vulnerabilities, such as insecure coding practices or the use of third-party libraries with known vulnerabilities, that could be exploited by attackers to gain unauthorized access to the app's data or functionality. * [ ] \[**Authentication Bypass**] Check if protected activities can be accessed via ADB. * [ ] \[**Exported Sensitive Activity**] Check if exported activities are properly restricted. * [ ] \[**Task Hijacking**] Check for activity hijacking possibilities. * [ ] \[**DOS**] Check for activities causing app crashes or denial of service. **9. WebView Vulnerabilities** > Android WebView is a component of an Android app that allows the app to display web content within the app's user interface. It can contain vulnerabilities, such as insecure coding practices improper validation, etc. * [ ] Check for **Cross-Site Scripting (XSS)** vulnerabilities. * [ ] Check for **Local File Inclusion (LFI)** vulnerabilities. * [ ] Check if **JavaScript** is insecurely **enabled**. * [ ] Check for **Insecure URL Loading** `loadUrl()` Allows attackers to inject malicious URLs. * [ ] Check for Usage of Javascript Interface **`setJavaScriptEnabled(true)`**Allows JavaScript execution, leading to potential XSS. **10. Intent Filters** > Intent redirection is an embedded intent it can be implicit or explicit Intent which is used to move one android component to another component. This vulnerability occurs when the developer does not retrieve the intent data via filtering. This vulnerability is similar to OpenRedirect for web security. * [ ] Check for intent spoofing and sniffing vulnerabilities. **11. Broadcast Receivers** **Description:** > A vulnerable Android Broadcast Receiver is a component of an Android app that allows the app to receive and respond to system-wide broadcasts, such as the receipt of a text message or the disconnection of a charger. It can be exploited * [ ] Check if exported receivers lack proper permissions. **12. Content Provider Security** > Content providers in Android are used to share data between applications. They use standard insert, update, delete, and query methods to access data and are assigned a special URI starting with "content://". If proper security controls are not implemented, it can lead to the leakage of information. An example of a content provider is the built-in SMS application, which can be accessed by other apps using a specific URI and the READ\_SMS permission. There may be cases where content providers are not implemented for sharing data or where access is restricted to apps with proper permissions. * [ ] Check for SQL injection vulnerabilities. * [ ] Check for path traversal vulnerabilities. * [ ] Check for internal data access vulnerabilities. * [ ] If IInsert is enabled Check for [**Flooding the Provider with Infinite Data**](https://medium.com/@muhammedgalal66/content-provider-exploitation-from-simple-misconfiguration-to-application-lockdown-fd09520e9d3a) **13. Source Code Obfuscation** {% embed url="" %} > Source code obfuscation in Android is the process of making the source code of an Android app difficult to understand or reverse engineer, typically to protect intellectual property or prevent unauthorized modifications. * [ ] Check if ProGuard or other obfuscation tools are implemented. * [ ] Check if sensitive code is properly obfuscated. **14. Hardcoded Sensitive Information/Auth-Keys** > Hardcoded information vulnerability is the practice of storing sensitive data, such as passwords or security keys, directly in the source code of an application, potentially exposing the data to attackers or unauthorized users who have access to the source code. * [ ] Check the source code for hardcoded API keys, tokens, passwords, or credentials. **15. Insecure Coding Practices** > Insecure coding practice refers to the use of coding techniques or practices that do not adequately protect an application or system from security vulnerabilities or threats, such as using weak passwords or failing to properly validate user input. Insecure coding practices can make an application or system more susceptible to attacks or data breaches. To prevent insecure coding practices, developers should follow best practices for secure coding and regularly review and test their code for vulnerabilities. * [ ] Check for insecure random number generators. * [ ] Check for usage of insecure functions. * [ ] Check for weak cryptography (e.g., MD5, Base64 encoding). * [ ] Check for other insecure coding weaknesses. **16. Insecure Deeplinks** > Insecure deeplinks in Android can allow attackers to access sensitive data or functionality within an app. Developers can prevent this by validating and securing deeplinks and implementing appropriate security controls. * [ ] Check for **explicit deeplinks** with **PendingIntent**. * [ ] Check for **implicit deeplinks** leading to **sensitive app destinations**. * [ ] Check for **Open Redirect** * [ ] Check for **Local File Disclosure** * [ ] **Check if you can** Exploit **Lack of Authentication for sensetive actions** ### **Insecure Services** > As service is basically something that **can receive data**, **process** it and **returns** (or not) a response. Then, if an application is exporting some services you should **check** the **code** to understand what is it doing and **test** it **dynamically** for extracting confidential info, bypassing authentication measures... * [ ] Check for existence of services without prober permissions * [ ] Use Drozer or activity manager to list and exploit the flow of exported service ```bash ## Using Drozer # Check services and it's permissions dz> run app.service.info -a com.mwr.example.sieve Package: com.mwr.example.sieve com.mwr.example.sieve.AuthService Permission: null com.mwr.example.sieve.CryptoService Permission: null # exploit services with drozer run app.service.send com.mwr.example.sieve com.mwr.example.sieve.AuthService --msg 2354 9234 1 --extra string com.mwr.example.sieve.PIN 1337 --bundle-as-obj -------------------------------- ## Using activity manager # List Running Services adb shell dumpsys activity services | grep com.vulnapp # Start a Service Manually adb shell am startservice -n com.vulnapp/.SensitiveService # Send Data to a Service adb shell am startservice -n com.vulnapp/.DataSyncService --es "sync" "malicious_data" ``` **17. Missing Integrity Checks** > Integrity checks in Android refer to the process of verifying the authenticity or integrity of an app's source code, to ensure that it has not been tampered with or modified by an unauthorized party. This can help protect against attacks that aim to inject malicious code or modify the app's functionality, such as man-in-the-middle attacks or repackaging attacks. * [ ] Decompile, modify, recompile, and check if the app still functions. **18. Insecure Android Permissions** > Android applications have a number of permissions that can be set in the "AndroidManifest.xml" file. If these permissions are not properly filtered or validated, they can be exploited. * [ ] Check if clear text traffic is enabled in `AndroidManifest.xml`. * [ ] Check if debug mode is enabled. * [ ] Check if `dataExtractionRules` are defined. * [ ] Check if backup mode is enabled. * [ ] Check for unnecessary permissions. **19. Background Screen Caching** > Screen caching is a mobile vulnerability, caused due to a performance/usability feature present in mobile OS’s. * [ ] Check if screenshots are taken when the app is sent to the background. **20. Insecure Firebase Database** > Firebase Database is a cloud-based real-time database service that allows developers to store and sync data across multiple devices and platforms. * [ ] Append `.json` to Firebase instance to check read permissions. * [ ] Replace `firebaseio.com` with `appspot.com/.json` to check for CORS issues. **21. Android Lock/Biometric Authentication Bypass** > Some applications use the Android Screen Lock/Biometric Authentication to validate the user before providing any specific service or before launching the application's main interface. * [ ] Check if authentication can be bypassed via runtime hooking or code modification. **22. Key Checks in Dynamic Analysis** > Some applications use the Android Screen Lock/Biometric Authentication to validate the user before providing any specific service or before launching the application's main interface. * [ ] Perform API security tests. * [ ] Check for broken access controls. * [ ] Test for server-side injections. * [ ] Identify sensitive data exposure. * [ ] Conduct fuzz testing. **23. Other Security Checks** > Additional security measures to ensure app security. * [ ] Check if cryptographic keys are reused. * [ ] Check for sensitive data leaks in the UI or screenshots. * [ ] Check if keyboard cache is disabled. * [ ] Check if copy/paste is disabled for sensitive fields. * [ ] Check if sensitive data is masked during app switching. * [ ] Check if third-party keyboards are disabled in sensitive fields. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://sallam.gitbook.io/sec-88/android-appsec/apk-pentesting-checklist.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.