Ethical Hacking Mobile Application Security Testing

Billions of people access sensitive services — banking, healthcare, corporate email, financial trading — through mobile apps on Android and iOS devices. Mobile apps process, store, and transmit sensitive data, authenticate users, and interact with backend APIs. Mobile application security testing evaluates whether these apps are designed and built in a way that protects users and their data from attackers.

The OWASP Mobile Top 10

OWASP publishes a Mobile Top 10 listing the most critical mobile application security risks. The key categories include: Improper Credential Usage, Inadequate Supply Chain Security, Insecure Authentication and Authorization, Insufficient Input and Output Validation, Insecure Communication, Inadequate Privacy Controls, Insufficient Binary Protections, Security Misconfiguration, Insecure Data Storage, and Insufficient Cryptography.

These categories guide the structure of a mobile application penetration test.

Android vs iOS: Architecture Differences

Android

Android is an open platform. APK files (the Android app package format) can be downloaded and installed from sources other than the official Play Store — a process called sideloading. This openness makes Android easier to test: APKs can be extracted from devices, decompiled, and analyzed without restrictions in most cases.

iOS

iOS is a closed platform. Apple controls the distribution of apps through the App Store. Testing iOS apps typically requires a jailbroken device (a device with Apple's security restrictions removed) or using specialized tools on non-jailbroken devices. Apple's security model is stricter, but vulnerabilities still exist in how apps handle data and communicate with servers.

Static Analysis: Examining the App Without Running It

Static analysis involves inspecting an app's code and resources directly — without executing it. For Android APKs:

Decompiling an APK

An APK is a ZIP archive containing compiled code (Dalvik bytecode), resources, and a manifest file. Decompiling it reveals the app's structure and logic.

• jadx — Decompiles Dalvik bytecode into readable Java code. The output is not identical to the original source but is close enough to identify security issues.
• apktool — Disassembles the APK into Smali (a human-readable version of Dalvik bytecode) and extracts all resources including the AndroidManifest.xml.

What to Look for in Static Analysis

• Hardcoded secrets — API keys, passwords, encryption keys embedded directly in the source code. Searching for strings like "password", "apikey", "secret", "token" often yields immediate findings.
• Exported components — The AndroidManifest.xml lists all Activities, Services, and BroadcastReceivers. Components marked exported="true" without permission requirements can be accessed by any other app on the device — potentially triggering actions, accessing data, or bypassing authentication.
• Insecure data storage — Sensitive data written to Shared Preferences, SQLite databases, or external storage in plaintext.
• Insecure network configuration — usesCleartextTraffic=true in the network security config allows the app to transmit data over unencrypted HTTP.
• Disabled certificate validation — Code that accepts all SSL certificates regardless of validity is a critical finding: it makes the app vulnerable to MitM attacks on any network.

Dynamic Analysis: Testing the Running App

Dynamic analysis tests the app while it runs, observing its behavior, intercepting its network traffic, and manipulating its runtime state.

Setting Up a Testing Environment

A dedicated Android emulator or physical test device with Android Debug Bridge (ADB) enabled allows full control over the device environment. Rooted Android devices provide deeper access for hooking and patching app behavior at runtime.

Intercepting Traffic with Burp Suite

Configuring the test device to route all traffic through Burp Suite's proxy captures every API call the app makes. This reveals what data the app sends, what endpoints it contacts, how authentication tokens are transmitted, and whether the API behind the app has vulnerabilities separate from the app itself.

Many modern apps implement SSL pinning — they only accept their own server's certificate and reject any proxy certificate, blocking interception. Bypassing SSL pinning is a standard mobile testing step.

SSL Pinning Bypass

Tools for bypassing SSL pinning on Android include:

• Frida — A dynamic instrumentation toolkit that hooks into running processes and modifies their behavior. Frida scripts can patch the SSL pinning logic in memory at runtime, forcing the app to accept any certificate.
• Objection — Built on Frida, Objection provides a command-line interface for common mobile testing tasks including SSL pinning bypass: objection -g com.example.app explore then android sslpinning disable

Insecure Data Storage

Apps frequently store sensitive data — tokens, credentials, personal information — in locations that are accessible to other apps or to anyone with physical access to an unencrypted device.

Shared Preferences

Android's Shared Preferences stores key-value pairs in an XML file. It is designed for small configuration data. Apps that store authentication tokens or user credentials here store them in plaintext readable by any app with root access or any attacker who extracts a device backup.

SQLite Databases

Many apps use SQLite for local storage. If the database is not encrypted and contains sensitive data, an attacker with device access — through physical access, ADB over USB, or a backup — can read the entire database.

Log Files

Android's logcat logging system captures debug output from all apps. Developers frequently log sensitive data — user input, authentication tokens, API responses — during development and forget to remove logging before release. The adb logcat command reads all log output from a connected device.

Insecure API Communication

The backend APIs that mobile apps communicate with are as important to test as the app itself. Common mobile API vulnerabilities include:

• Broken Object Level Authorization — The API does not verify that the requesting user owns the object they are requesting. Changing a user ID in an API request accesses another user's data.
• Lack of rate limiting — Login endpoints without rate limiting allow unlimited brute-force attempts.
• JWT vulnerabilities — JSON Web Tokens used for authentication may be signed with weak algorithms (the "none" algorithm vulnerability accepts unsigned tokens as valid) or contain sensitive data in their unencrypted payload.
• Verbose error messages — APIs that return detailed error messages including stack traces, database queries, or internal paths expose information that helps attackers.

MobSF: Automated Mobile Security Testing

Mobile Security Framework (MobSF) is an open-source automated analysis platform for Android and iOS apps. Upload an APK or IPA file and MobSF performs comprehensive static analysis — decompiling the app, checking permissions, searching for hardcoded secrets, identifying insecure configurations, and scoring the app's security posture. It also supports dynamic analysis when configured with an emulator.

MobSF produces a detailed report that serves as the starting point for a manual mobile penetration test.

Key Points

• Android's open platform makes static analysis simpler; iOS's closed platform requires jailbroken devices or specialized tooling.
• Static analysis of APKs using jadx and apktool reveals hardcoded secrets, exported components, and insecure configurations without running the app.
• Dynamic analysis intercepts live API traffic using Burp Suite; SSL pinning bypass with Frida or Objection is required for apps that implement certificate pinning.
• Sensitive data stored in Shared Preferences, SQLite, or log files is a common and impactful finding in mobile app tests.
• Backend API security — BOLA, rate limiting, JWT flaws — is as important as the app itself and tested as part of a complete mobile assessment.
• MobSF automates the initial static analysis phase and produces a structured report as a testing baseline.