Android Application Penetration Testing

Android application penetration testing is a security assessment of your APK that covers insecure data storage (SharedPreferences, SQLite), reverse engineering, root detection bypass, intent injection, and API communication security using tools like Frida, jadx, and Burp Suite.

No. We perform greybox testing using the APK file plus any API documentation you provide. We decompile and analyze the binary. Source code access is helpful but not required.

Cybersecify Android pentest uses the standard MASTG-aligned toolchain. Static analysis: apktool (resource and AndroidManifest extraction), jadx-gui and jadx-cli (Java source decompilation from DEX bytecode), bytecode-viewer (cross-decompiler verification), MobSF (automated static report as a baseline), apkleaks (regex sweep for API keys, JWT, AWS access keys, Firebase URLs, Stripe keys, hardcoded secrets), Androguard (programmatic APK analysis). Dynamic analysis: Frida (runtime hooking, SSL pinning bypass, root detection bypass, native function hooking), Objection (Frida-based pentest helper for keystore dumps, intent broadcast, file system browsing), Drozer (Android security assessment framework for IPC + content provider testing), Burp Suite Pro (HTTPS proxy with installed Burp CA on the test device). Test devices: rooted Pixel (Android 14 + Android 13) plus an emulator pool (Android 9, 11, 12, 14) for backwards-compatibility coverage.

Data-at-rest on Android lives primarily in /data/data/com.your.app/. SharedPreferences XML files in shared_prefs/ are world-readable on rooted devices unless wrapped with EncryptedSharedPreferences (Jetpack Security). SQLite databases in databases/ are similarly exposed. Cybersecify dynamic testing: install the APK on a rooted Pixel, exercise the app through all user flows (login, password reset, payment, profile edit, document upload), then pull /data/data/ via ADB and inspect for plaintext tokens, JWT, refresh tokens, PAN, Aadhaar fragments, transaction history, message history, MFA secrets. We test both internal storage (default scope) and external storage (legacy WRITE_EXTERNAL_STORAGE permission, scoped storage Android 10+ exceptions). Findings include exact file path + sensitive content + remediation (EncryptedSharedPreferences API, SQLCipher for databases, or platform Keystore for tokens).

Root detection bypass is required to exercise the runtime attack surface on apps that block rooted devices at startup. Cybersecify approach: Magisk + Magisk Hide for app-level root hiding (target app cannot enumerate Magisk binary, su binary, or Magisk Manager package), Frida script for runtime patching of common root-check libraries (RootBeer, SafetyNet, Play Integrity API client-side bypass), Objection one-liners for stock root-detection patterns (build.tags=test-keys check, ro.debuggable property check, /system rw remount check, su binary path enumeration). For apps using server-side Play Integrity verdict, we document the limitation (server-side check is the correct fix; client-side checks are bypassable by design). We test on Android 13 + Android 14 Pixel devices with Magisk 26+. Bypass findings are documented with the exact technique + recommended hardening (server-side Play Integrity verdict + risk-based step-up auth).

Yes. IPC testing is a high-frequency finding category on Android. Cybersecify methodology: parse AndroidManifest.xml for all exported Activities, Services, Broadcast Receivers, and Content Providers (android:exported=true or implied by intent-filter). Test each exported Activity for direct invocation via adb shell am start (does it require authentication, does it accept attacker-controlled extras, can it bypass the lockscreen). Test deep links for parameter injection (does the app trust the URI path/query, does it open WebView with the attacker URL, does it auto-execute JavaScript). Test Content Providers for cross-app data read (can a malicious app read your provider via content:// URI). Test Broadcast Receivers for spoofed system broadcasts. Findings include the exact adb command to reproduce + the exact AndroidManifest line to harden.

Yes. Cybersecify Android pentests follow OWASP Mobile Application Security Testing Guide (MASTG) v1.7+ as the methodology baseline and OWASP Mobile Application Security Verification Standard (MASVS) v2.1 as the verification standard. We cover the MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE, and MASVS-PRIVACY control categories. Reports cite MASTG test IDs (MASTG-TEST-0001 to 0220) per finding so engineering teams can cross-reference remediation guidance with the OWASP source. The Growth Pentest plan adds OWASP Mobile Top 10 (2024) cross-mapping per finding for buyer-side categorical reporting.

Yes. Certificate pinning bypass is required to intercept HTTPS traffic and exercise the API attack surface from the app. Cybersecify approach: install Burp Suite CA on the rooted test device (system-level trust store on Android 7+ requires root), attempt direct HTTPS proxy first. If pinning blocks (most apps using OkHttp3 CertificatePinner or TrustKit), apply Frida pinning-bypass script for OkHttp3 / TrustManager / X509TrustManager. For Network Security Config-based pinning (Android 7+), patch the network-security-config.xml during repackage. For native pinning (BoringSSL via NDK), hook the SSL_CTX_set_custom_verify or SSL_set_verify functions at runtime via Frida. We document the bypass technique used + the recommendation (server-side mutual TLS for high-sensitivity flows; pinning is best-effort client-side defense not a guarantee).

Single-scope Android pentest at Cybersecify takes 7 calendar days under the Startup Pentest plan at INR 74,999 and covers one APK (one app, one production build). A two-scope engagement (typically Android + API, or Android + iOS for cross-platform apps) takes 10 calendar days under the Growth Pentest plan at INR 1,79,999 and includes SOC 2 + ISO 27001 audit-prep evidence with control mapping per finding. International pricing: Startup ~USD 900 / ~EUR 830, Growth ~USD 2,150 / ~EUR 1,990 at snapshot FX. Test device + emulator setup is on Cybersecify (no buyer hardware shipment required). APK and any test accounts are buyer responsibility. All Android pentests include 1 free retest within 30 days of report delivery.

Yes. Android pentest reports follow PTES + OWASP MASTG v1.7+ + OWASP MASVS v2.1. Reports identify findings that overlap Google Play Store Developer Policy (User Data, Permissions, Security and Performance, Malicious Behavior) so the engineering team can fix Play Store compliance issues alongside security findings before re-submission. The Growth Pentest plan adds SOC 2 Trust Services Criteria (CC6.1 Logical Access, CC6.7 Restricted Transmission, CC7.1 Vulnerability Detection) + ISO 27001 Annex A (A.8.8 Technical Vulnerabilities, A.8.26 Application Security Requirements, A.8.28 Secure Coding) control mapping per finding. Reports have been accepted by SOC 2 Type 1, Type 2, and ISO 27001 auditors for the mobile-app component of buyer audits. The Growth plan includes a Letter of Attestation signed by the Lead Pen Tester (OSCP) for app-store re-submission appeals or buyer security questionnaires.

Yes. Third-party SDKs are the most common source of high-severity findings on Android apps because their CVE-tracking is delegated to the SDK vendor and rarely updated. Cybersecify approach: parse the APK for embedded native libraries (.so files) and Java/Kotlin libraries (via classes.dex inspection and jadx package enumeration). Cross-reference detected library + version against NVD CVE database for the relevant date range. Specific SDK families we routinely flag: Facebook SDK (account linkage attack surface), Firebase SDK (default rule misconfiguration), AppsFlyer / Branch (deep link tampering), Stripe / Razorpay (test mode left enabled, public key vs publishable key confusion), MoEngage / OneSignal (push token exposure), and embedded WebView SDKs (outdated Chromium with known CVEs). Findings include SDK + version + the specific CVE + the upgrade path. Where the buyer cannot upgrade due to vendor lock-in, we recommend compensating controls.