Android Pentesting Part 2
Static Analysis Findings:
With the AndroidManifest.xml, apktool.yml, and decompiled JAR available for review, the following findings were identified during static analysis. So lets jump into the main section of identifying the vulnerabilities.
GitHub Link :https://github.com/vishvesh1795/Android-Pentesting-Static-Checklist
SA-01 Application Runs on an Older, Vulnerable Android Platform
The application declares a minimum supported SDK level that allows it to be installed on Android OS versions with publicly known, unpatched vulnerabilities. An attacker who gains access to a device running one of these outdated OS versions can chain a known platform-level flaw with the application to compromise the device or extract sensitive information — without needing to find a bug in the app itself.
SA-02 No Source Code Obfuscation Implemented
Decompiling the APK produces Java source code that closely mirrors the original — class names, method names, and variable names are all intact and readable. This makes it straightforward for an attacker to understand business logic, locate security controls, and pinpoint high-value targets for further attack.
SA-03 Application Has Set Insecure Permissions
Reviewing the AndroidManifest.xml showed that the application requests or sets several insecure configuration values that widen its attack surface, including access to the device’s shared storage, the ability to track network connectivity state, and settings that expose the application to easier tampering.
The specific insecure settings identified were:
● WRITE_EXTERNAL_STORAGE — broad write access to shared/external storage that other apps can also read.
● android:allowBackup=”true” — application data can be extracted from the device using adb backup, even without root.
Get Aerialist71’s stories in your inbox
Join Medium for free to get updates from this writer.
● android:debuggable — a debugger can be attached to the application in a production build.
SA-04 printStackTrace() Used in Application Source Code
The application calls printStackTrace() and similar verbose logging in several places. When an exception surfaces a full stack trace to logs (or, worse, to the user or an intercepted response), it hands the attacker information that makes further attack meaningfully easier — for example, a malformed SQL query string, the type of database in use, or the version of an underlying framework or library. This kind of detail lets an attacker target known vulnerabilities in those specific components.
SA-05 Application Uses addJavascriptInterface()
The application exposes a native Java object to JavaScript running inside a WebView via addJavascriptInterface(). If that WebView ever renders content that isn’t fully trusted — a compromised third-party script, an open redirect, or any attacker-influenced page — the untrusted JavaScript can call the exposed Java methods directly, potentially reaching functionality or data that was never meant to be reachable from a web page.
SA-06 WebView Configured With JavaScript Enabled
WebView is the component Android apps use to render web content inline, using the WebKit rendering engine to display pages, navigate history, and run scripts. Because a WebView can render HTML and JavaScript supplied from outside the app, enabling it via setJavaScriptEnabled(true) reintroduces familiar web security issues — most notably cross-site scripting — into a native mobile context if the content it loads isn’t fully trusted.
SA-07 Sensitive Information Visible in Application Source Code
An AES encryption key was found hardcoded inside the APK. Because the key ships inside the application package itself, anyone who decompiles the app can recover it and use it to decrypt protected data, or to forge validly-encrypted payloads — defeating the encryption control entirely rather than merely weakening it.
Note: hardcoded sensitive information is not limited to cryptographic keys — the same risk applies equally to hardcoded credentials, embedded API secrets, or SQL query fragments left in the source or resources.
Chapter Summary & Key Takeaways
Android static analysis is a crucial phase of application security testing that helps identify potential vulnerabilities by examining the application’s source code, configuration files, and embedded resources without executing the application.
Testers should focus on AndroidManifest.xml configurations, insecure data storage, hardcoded credentials and API keys, cryptographic weaknesses, improper permission handling, insecure WebView configurations, and exposed application components.
It is equally important to review network security configurations, certificate validation mechanisms, third-party libraries, and debugging settings for potential security weaknesses.
Tools such as JADX, Apktool, and MobSF can help automate vulnerability detection and simplify manual code review. However, automated findings should always be manually validated to eliminate false positives and assess their actual security impact.
Finally, map confirmed vulnerabilities to the relevant OWASP Mobile Application Security Verification Standard (MASVS) and Mobile Application Security Testing Guide (MASTG) categories, and document their impact, evidence, and recommended remediation.
In the next chapter, we will move on to dynamic analysis of the Android application, where we will identify and validate security vulnerabilities through practical testing, demonstrate proof of concepts (PoCs), and explore effective mitigation strategies for each finding.
