You receive a message on Signal from someone you trust. It contains a link to a new version of an official mobile app. The website doesn’t look suspicious: a familiar logo, authentic design, and a "Download" button. You install the APK, agree to a few access requests and go back to work.
At this point, the attacker no longer needs to exploit complex vulnerabilities, bypass firewalls, or hack servers. They have achieved their goal in a much simpler way — by convincing the user to install a malicious application himself.
This exact method was used in spring 2024 during a campaign identified by Ukraine’s CERT-UA together with MILCERT, the cyber defense unit under the Ministry of Defense's Cyber Defense Center.
Links to fake app pages named "GRISELDA" and "Ochi" were spread via Signal, offering downloads for what looked like official mobile versions. While the technical details of the malware are not important here, the attack clearly demonstrates the main point of this article: today, a mobile app is a full-fledged attack surface, and a security breach often begins on the user's device rather than on a server.
That is why mobile application security testing is no longer just an extra step added to a web pentest. Android and iOS have their own threat models, built-in protective mechanisms and completely different sets of common issues. Because of this, mobile pentesting is a dedicated discipline with its own methods, tools and standards, particularly OWASP MASVS.
In this article, we will look at the specifics of Android and iOS, the OWASP MASVS standard, and what security experts actually look for during a mobile pentest.
How mobile application penetration testing differs from a web application pentest
If in a web application all the code runs on the server and the client only receives HTML/JS — which can generally be considered "untrusted by default" — a mobile application is a completely different story. A significant part of the logic runs locally on the user's device, which is physically outside your control.
This means an attacker gains access to things that simply do not exist on the web:
- the complete application binary file (APK or IPA), which can be decompiled to read the underlying logic;
- local device storage — SQLite databases, configuration files, cache;
- the ability to attach a debugger, modify system calls and bypass security checks while the app is running;
- physical control of the device — root access on Android or jailbreak on iOS, which removes almost all client-side protections.
Therefore, a mobile pentest is always a combination of three approaches: static code analysis (examining code without running the app), dynamic analysis (running the app, intercepting network traffic, and intercepting function calls in real time), and testing the backend API that the app communicates with — which is essentially the same as web pentesting, just with a mobile client instead of a browser.
OWASP MASVS (Mobile Application Security Verification Standard): the foundation of security
Just as web pentesting relies on the OWASP Top 10, the mobile world relies on the OWASP Mobile framework, specifically the OWASP Mobile Application Security Verification Standard (MASVS), supported by the practical guide MASTG (Mobile Application Security Testing Guide), which was previously called MSTG.
MASVS is not just a list of vulnerabilities, but a structured list of requirements for a secure application, grouped into categories. MASTG provides specific test cases to verify each requirement, along with step-by-step instructions and tools.
Let's look at the main MASVS control groups:
MASVS-STORAGE — Data Storage
The most common category of findings in real security reports. It checks whether the app stores sensitive data in plain text: unencrypted passwords and tokens in SharedPreferences (Android) or plist/UserDefaults (iOS), unprotected personal data in SQLite databases, sensitive remnants in keyboard cache, or app switcher screenshots (the preview image iOS displays when you minimize an app where a payment card number might suddenly be visible). This also includes logging practices: applications often write sensitive data into logs, and Logcat is accessible to any app with the appropriate permission on older Android versions.
MASVS-CRYPTO — Cryptography
This section does not just check whether encryption is used, but whether it is implemented correctly: whether custom encryption algorithms are used instead of tested libraries, whether outdated primitives are used (ECB mode, MD5/SHA1 for sensitive operations, hardcoded IVs), and whether encryption keys are stored separately from the encrypted data itself (because encrypting data with the key stored in the same file is just encoding, not security).
MASVS-AUTH — Authentication and Session Management
Local authentication (PIN, biometrics) is tested separately from server-side authentication. The key question is whether biometric authentication truly protects access to sensitive data or if it is merely a UI overlay that can be bypassed by launching the required Activity or ViewController directly to skip the lock screen. It also tests session management logic: whether digital authorization tokens are invalidated on the server upon logging out, whether tokens can be reused after a password change, and whether the session is bound to a specific device.
MASVS-NETWORK — Network Communication
Verifies TLS implementation, ensuring apps do not trust arbitrary certificates (a common mistake with TrustManager configurations that ignore validation errors which still happens today). It also checks whether certificate or public key pinning is implemented — hardcoding a reference to your specific server key to prevent traffic manipulation where justified. And, importantly for a pentester, it checks whether this pinning can be bypassed (more on this below, in dynamic analysis).
MASVS-PLATFORM — Platform Interaction
Focuses on platform-specific mechanisms. On Android: proper configuration of Intents, Broadcast Receivers, and Content Providers (ensuring they are not exposed externally to allow other apps on the device to interfere), and secure WebView usage (verifying JavaScript bridges are not enabled unnecessarily and arbitrary URLs cannot be loaded). On iOS: proper handling of Custom URL Schemes and Universal Links, which can become vectors for inter-app attacks.
MASVS-CODE — Code Quality and Security
Checks whether outdated or vulnerable third-party libraries are used (Software Composition Analysis for mobile), whether debugging features were accidentally left in the release build, and whether errors are handled cleanly without exposing internal application structures.
MASVS-RESILIENCE — Resilience to Reverse Engineering and Tampering
This is the most interesting and mobile-specific category, with no direct equivalent in web pentesting. It includes: code obfuscation (deliberately making code complex to read, and how much it actually slows down analysis rather than just renaming variables to a, b, c), root/jailbreak detection and how easily it can be bypassed, active debugger or tool detection (like Frida), and application integrity checks (anti-tampering, runtime signature verification).
An important detail that product managers often overlook: MASVS-RESILIENCE controls are not a replacement for server-side security. They are an obstacle for an attacker, not an impassable wall. If your entire security model relies on obfuscation to stop reverse engineering, you have a vulnerability, not a security feature.
Android application security: how an Android pentest is conducted
Static code analysis
It all starts with inspecting the APK file. The pentester uses specialized tools (apktool, jadx) to unpack the app and examine its main configuration file, AndroidManifest.xml.
This immediately reveals basic vulnerabilities:
- dangerously exported components (exported="true" without permission checks) — screens that other applications can launch directly;
- allowed backups (allowBackup="true"), which make it possible to extract private app data via the command line (adb backup) even without root access;
- developer mode (debuggable="true") left active in the release build, allowing third parties to attach to internal application processes.
Next, the internal code (Java/Kotlin or its low-level Smali version, if decompiling to clean code failed) is reviewed. Pentesters look for critical flaws: hardcoded secrets (passwords and access keys embedded directly in the code), weak encryption algorithms, and dangerous commands like Runtime.exec(), which allow user input to execute commands in the operating system and run malicious code.
Dynamic analysis
Here, tools like Frida and Objection come into play. These dynamic instrumentation frameworks allow pentesters to intercept function calls in real time while the app is running, without needing to recompile it. This makes it possible to bypass root checks (by modifying the function's return value to indicate the device is clean), bypass SSL pinning (to intercept and analyze traffic using proxies like Burp Suite), or extract decrypted data directly from memory while the app is actively using it.
This is the point where a mobile pentest moves beyond reading code and becomes active real-time analysis: the application operates as usual, while key processes are monitored and evaluated by the tester.
Security testing specifics for the iOS operating system
Apple's ecosystem is historically considered more secure by default due to strict sandboxing and App Store review policies. However, security risks still exist, but simply take different forms.
An IPA file is unpacked just like an APK. Inside lies the compiled binary executable, which cannot be opened and read as plain text. To understand how the app is structured internally without source code, analysts use specialized tools like class-dump or Hopper/IDA. These tools reveal the class structure and internal functions of the application.
The key takeaway here is simple: doing this on iOS is actually easier than it seems. Objective-C, which is often used for iOS apps, leaves many descriptive hints in the compiled file — such as class and method names — that developers might prefer to hide. Because of this, reverse engineering on iOS often turns out to be straightforward.
Pentesters also review the iOS Keychain, where apps store passwords, tokens, and other secrets. Although secure by design, developers often configure it incorrectly in practice. Two common examples: saving data with settings that allow it to be read even when the device is locked, or failing to remove Keychain entries when the app is uninstalled — meaning if the app is reinstalled later, old credentials are still there waiting.
In addition, tests cover App Transport Security (ATS) — an iOS mechanism that requires all app connections to be encrypted via HTTPS by default. The problem is that this requirement can be disabled with a single line in the configuration. Developers sometimes do this when setting up certificates, which leaves the app sending unencrypted data.
Dynamic testing on iOS is also performed using Frida, but with a specific requirement: Frida needs a jailbroken device. If no jailbroken device is available, an alternative approach is to repackage the app with the Frida component embedded directly inside it. The checks are similar to Android: testing jailbreak detection bypasses, intercepting network traffic, and inspecting process memory while the app is running.
Backend API testing: the same story as on the web
It is important to understand that most mobile vulnerabilities are actually hidden not in the app itself, but in the API — the set of endpoints through which the app communicates with the server. A mobile app is just one client interface used to interact with this API. The same server endpoints can be called directly using other tools (such as Postman or curl) once a request is intercepted.
Therefore, a complete mobile pentest always includes standard API security checks: Broken Access Control, IDOR, mass assignment, and weak authorization at the endpoint level. The main difference is that these endpoints are rarely documented publicly, so they must first be identified by intercepting traffic during dynamic analysis. Once identified, standard web testing methodologies apply.
Most common findings: a quick overview
- Hardcoded secrets in the binary: API keys, third-party service credentials, or administrative test passwords left in code and forgotten before release.
- Unencrypted local databases: Storing personal data, messages, or transaction histories in plain SQLite files that can be copied and read with free database viewers.
- Weak or missing SSL pinning (Network Security): Allowing traffic interception (Man-in-the-Middle attacks) on unsecured Wi-Fi networks.
- Dangerously exported Android components: Allowing other apps on the device to launch internal features outside the intended workflow.
- Client-trust logic: Performing permission, price, or access limit checks only inside the mobile app while the backend accepts incoming data without verification.
- Debug features in release builds: Test endpoints, developer menus, and temporary functions left in production code.
How long a mobile pentest takes
A mobile pentest usually takes longer than a web application test. The reason is simple: it requires additional work to inspect the app file itself (static and dynamic analysis of the binary), on top of testing the API the app communicates with.
Typical timelines for traditional manual testing:
- Small app with basic functionality: 5–7 business days.
- Medium-complexity app with custom APIs and multiple user roles: 2–3 weeks.
- Testing both Android and iOS platforms: Adds roughly 30–50% more time. While the backend server is shared, platform-specific code and features must be tested separately for each operating system.
However, as AI technology advances in cybersecurity, testing times have decreased significantly. Teams no longer need to wait weeks for security results or delay releases to complete security checks.
How to prepare for a mobile app pentest
Things to prepare in advance:
- An un-obfuscated debug build (or symbol maps for an obfuscated build): This speeds up static code analysis without changing the quality of the results, as obfuscation slows down analysis rather than preventing it.
- Test accounts for different user roles: Just like in web pentesting.
- A device configured for root/jailbreak or supported dynamic testing methods: If testing is performed on a standard client device without these capabilities, certain MASVS-RESILIENCE checks will be limited.
- API documentation: Optional (pentesters will discover endpoints from traffic interception anyway), but saves time.
How AI is changing mobile pentesting
It is best to be honest here: full reverse engineering of a mobile binary is an area where complete automation does not yet work seamlessly. Understanding why a specific function in decompiled Smali code controls a root check and how to bypass it during runtime using Frida requires context, reasoning, and experimentation. Dynamic instrumentation and anti-tampering bypasses remain largely within the domain of human expertise.
However, static code analysis — SAST (Static Application Security Testing) — can be automated effectively today. An example of this is AI SAST by A42.
The main advantage of AI SAST by A42 is that it detects many issues early in the development stage before code reaches production, as the scan takes only a few minutes. AI SAST systematically analyzes decompiled application code: searching for hardcoded secrets, insecure cryptographic primitives, exported components without access checks, and risky platform API calls. It automates the initial hours of manual code review before a pentester dives into deeper analysis.
How it differs from classic static scanners (regex matching): The AI agents analyze the context around API calls, which reduces false positives. It can distinguish a real working key from a sample placeholder in unit tests, or confirm whether a TrustManager actually skips certificate validation rather than flagging it simply because the word "trust" appears in the class name — eliminating much of the noise typical of traditional static scanners.
Practical result: AI SAST scans every new build published by the team and catches regressions — for instance, if a new release accidentally re-introduces a TrustManager that appears valid but bypasses certificate chain checks. While an annual pentest would miss this until the next audit cycle, AI SAST detects it right after the build is completed.
This does not make manual mobile pentesting unnecessary — deep dynamic analysis, custom anti-tampering bypasses, and complex business logic checks still require an experienced pentester. However, combining AI SAST for static analysis with periodic mobile pentesting for dynamic and architectural analysis provides significantly more complete and up-to-date security coverage than either approach alone.
How to start using AI SAST
AI SAST is available free of charge to all users of the A42 Recon+Exposure platform, including trial users. You can start scanning right away without complex technical setups: simply open the AI SAST section in your A42 dashboard, upload your code (via ZIP archive), and click "Scan".
If you are not yet a platform user, you can request trial access by submitting a contact form or booking an introductory call with the A42 technical team.
