Think of a mobile app like a digital vault, holding everything from user passwords to payment details. As a penetration tester, your job is to make sure that vault is sealed tight—long before any real attacker tries to break in. In this guide, we’ll walk you through the entire process of mobile pentesting, from gathering the right tools to analyzing code and traffic. Let’s jump in!
Introduction
We live in a world where mobile devices are almost an extension of ourselves. Because people do their banking, shopping, and socializing on phones, security is everything. And that’s why mobile pentesting matters: we simulate attacks against apps to expose weaknesses and help developers patch them up.
Here’s what’s in it for you:
Peace of Mind: You won’t lose sleep over data leaks or stolen credentials.
Compliance: Regulators (and your users) require strong protection standards.
Reputation Boost: Secure apps mean happier customers and less risk of negative headlines.
What Is Mobile Pentesting?
At its core, mobile pentesting is about finding creative ways to break into an app—just as a real attacker would—so you can fix the weaknesses first. It’s different from standard web pentesting because mobile apps:
Run on Unique Platforms: Android and iOS each have their own rules, security models, and quirks.
Store Data on Devices: Sensitive info can be saved locally, making it crucial to examine device-specific storage.
Rely Heavily on APIs: Mobile apps often talk to backend servers through APIs, which might be misconfigured or vulnerable if not tested properly.
Common challenges include dealing with root/jailbreak detection, bypassing SSL pinning, and analyzing both client-side and server-side logic.
Common Threats to Mobile Applications
Picture a medieval fortress—these are the typical “weak spots” attackers target:
Insecure Data Storage
Sensitive tokens or user credentials left unencrypted on the device.
Weak Server-Side Controls
Missing input validation or flawed API logic that hackers can exploit.
Insufficient Transport Layer Protection
Using HTTP or flawed HTTPS, allowing attackers to intercept or modify network traffic.
Insecure Authentication & Authorization
Poorly implemented login systems, session management, or permission checks.
Client-Side Vulnerabilities
Code that can be reverse-engineered to reveal secrets, or logic that can be manipulated at runtime.
Check out the OWASP Mobile Top 10 and the Mobile Application Security Testing Guide (MASTG) for more on these risks. They’re like maps highlighting all the possible pitfalls.
Prepare for Mobile Testing
Before you storm the castle, you need the right armour and weapons. In pentesting terms, that means setting up an environment where you can safely experiment without harming real-world data. Let’s cover the basics for both Android and iOS.
Android
When testing Android apps, you can spin up virtual devices using tools like Android Emulator or Genymotion. These emulators let you install and test apps quickly without needing a physical device. Detailed steps to set one up can be found in this guide.
However, using a physical device often yields more accurate results—especially when you need to test real-world network conditions, sensors, or biometric authentication. If you’re planning more advanced tests like root checks or in-depth data forensics, having actual hardware is a big plus.
If you decide to buy or borrow a dedicated device, keep in mind that some Android phones are easier to root. Rooting gives you deeper access to the operating system, allowing you to analyze hidden files, bypass app restrictions, and run powerful tools that require elevated permissions.
Rooting
Android Rooting is like finding a skeleton key to your phone’s operating system. Typically, you’ll:
Unlock the bootloader.
Flash a custom recovery (e.g., TWRP).
Install a root management tool like Magisk or SuperSU.
Each phone and OS version has its quirks, so be ready for a few tries. The good news is that once a device is rooted, it generally stays that way unless you factory-reset or upgrade the firmware. Keep in mind that iOS jailbreaks can be lost after a reboot—so Android sometimes offers a more persistent platform for testing.
Always follow trusted guides for your specific phone—improper rooting can corrupt the software or introduce security holes. And, of course, back up your data before diving in! Example of rooting a Pixel 3a
Proxy
Think of a proxy like Burp Suite as your “spyglass.” It lets you see and modify all the traffic going in and out of the app. You’ll catch insecure communication, flawed authentication, or shady requests. Setting up a proxy for mobile is similar on iOS and Android. You can find official instructions for each platform here.
Things get tricky with certain frameworks:
Xamarin sometimes ignores system-wide proxy settings due to custom networking libraries.
Flutter might respect proxies but could enforce certificate pinning, blocking you from viewing traffic.
To overcome these hurdles, you can tweak the code, use tools like Frida or Objection to turn off pinning or set up reverse proxies (e.g., mitmproxy) to capture traffic. Adapting your approach is part of the fun!
App Installation
If the app isn’t on the Google Play Store yet—common for pentests—you’ll likely have an APK file to sideload. You can share the APK through Google Drive or a direct download link. Another convenient option is using Firebase App Distribution, which organizes testing by sending out invites to stakeholders.
iOS
On iOS, a physical device also offers the most genuine testing experience. You can dive into hardware-specific features such as Face ID, Touch ID, and sensors while also capturing realistic network interactions. If you’re buying or using a personal device, consider models known to be simpler to jailbreak (since not all iPhones are equally friendly to this process). If you need virtual iOS devices, Corellium provides powerful cloud-based testing, though it’s not free. Most testers still rely on a physical device for thorough checks.
Jailbreaking
iOS Jailbreaking feels a lot like removing the padlocks Apple puts on its devices. You gain root privileges, letting you install tweaks, explore hidden file directories, or run advanced pentesting scripts. Popular tools include unc0ver and Checkra1n. The best choice depends on your iOS version and device model.
Remember:
Newer devices can be tougher to jailbreak.
Some jailbreaks don’t survive a reboot (“semi-untethered”).
Always back up your iPhone before messing with system files.
Also note that certain security layers are automatically reactivated when your device restarts, so you may need to re-jailbreak every time you power up.
App Installation
iOS apps come in IPA files—similar to APKs on Android. On a jailbroken phone, you can install IPAs using file managers like Filza or apps like Sideloadly. For a more official route, developers often rely on TestFlight, which lets them invite testers via email—just tap the link, and iOS handles the rest.
By setting up your environment properly—choosing the right devices (virtual or physical), configuring proxies, and understanding how to sideload apps—you’ll be ready for the deep dive into an app’s internal workings. It might take some tinkering, but once you’ve got that perfect setup, the real pentesting can begin!
Static Analysis (SAST)
Now let’s move on to examining the app itself—without fully running it. This is like reading the blueprint of a castle before you step inside. We look for hardcoded secrets, insecure configurations, and other issues in code or config files.
Key Areas to Focus On
Hardcoded Secrets
API keys, tokens, credentials, and encryption keys sometimes end up right in the source code. If attackers reverse-engineer the app, they can pluck these secrets out with minimal effort and impersonate users or services at will.
Insecure Configurations
Overly permissive permissions, debug flags left enabled, or improper signing can all punch holes in your app’s armor. A single setting—like NSAllowsArbitraryLoads in an iOS Info.plist or android:debuggable="true"—can open the door to man-in-the-middle (MITM) attacks or unprotected debugging.
Sensitive Data Exposure
Storing session tokens or personal info in plain text on the device (logs, shared preferences, local files) is a recipe for disaster. Anyone with physical access or a rooted/jailbroken phone could snoop around and steal valuable data—no brute force required.
App Logic and Flaws
Sometimes, the biggest problems lie in how the code implements features. If crucial checks (like authentication) are missing or poorly enforced, attackers can slip right past your defenses. Weak cryptographic functions or unprotected app components also make life easy for anyone probing your app.
MSTG Checklist
The Mobile Security Testing Guide (MSTG) offers a thorough checklist to help you tackle static analysis methodically:
[ ] MSTG-STORAGE-1: Sensitive data is not stored unencrypted on the device.
[ ] MSTG-STORAGE-2: No sensitive data is stored in shared storage.
[ ] MSTG-CRYPTO-1: Proper use of cryptographic algorithms and libraries.
[ ] MSTG-NETWORK-1: Secure communication channels (e.g., HTTPS/TLS).
[ ] MSTG-CODE-1: Absence of hardcoded secrets in the source code.
[ ] MSTG-CODE-3: Code obfuscation is applied appropriately.
[ ] MSTG-RESILIENCE-1: Protection against reverse engineering.
[ ] MSTG-RESILIENCE-2: Debugging capabilities are disabled in production.
[ ] MSTG-PRIVACY-1: Proper handling of user permissions and private data.
SAST Tools
Various tools can help you dissect your code, configs, and binaries without running the app:
MobSF (Mobile Security Framework)
Use: Plug in an APK/IPA and MobSF will generate a detailed report: it’ll list potential misconfigurations, suspicious permissions, or hardcoded secrets.
Bonus: It also has some dynamic features, making it a neat all-in-one solution.
APKTool (Android)
Use: Decompile and then recompile an APK to see what’s inside. This is perfect for reading AndroidManifest.xml, examining resources, or adjusting the app.
apktool d app.apk -o output_directorJADX (Android)
Use: Convert Dalvik bytecode (.dex) into readable Java. Great for spotting lines of code with potential vulnerabilities, like API keys.
jadx app.apk -d output_directoryClass-Dump, Hopper, Ghidra (iOS)
Use: Extract Objective-C class headers (Class-Dump) or disassemble iOS binaries (Hopper/Ghidra). If the app’s been Swiftified, you’ll also see Swift metadata.
Examples
Android
Information disclosure
Android apps can be decompiled from their APK files using tools like APKTool, JADX, or MobSF.
This process reveals source code, application structure, and sensitive components like AndroidManifest.xml or .smali files, which can expose app logic and permissions.
Allowing Cleartext Traffic
<application android:usesCleartextTraffic="true" />Attackers can exploit unencrypted (HTTP) communication for eavesdropping or tampering.
Debuggable Application
<application android:debuggable="true" />Anyone with a device (or emulator) can attach a debugger and rummage through sensitive data or logic.
Hardcoded API Keys
public class ApiClient { private static final String API_KEY = "12345-abcdef-67890"; private static final String API_SECRET = "superSecretPassword123!"; }A quick decompile with APKTool or JADX reveals these keys, allowing attackers to impersonate the app or access backend services unauthorized.
Sensitive Data in Plaintext
<map> <string name="session_token">abc123XYZ987</string> <string name="user_email">user@example.com</string> </map>If tokens or user details are stored in plain text, a rooted device can easily extract them.
iOS
Misconfigured Info.plist
<key>NSAppTransportSecurity</key> <dict> <key>NSAllowsArbitraryLoads</key> <true/> </dict>Apple enforces secure connections by default, so overriding this opens up the app to MITM risks or unencrypted traffic.
Decompilation tools like Class-Dump, Hopper Disassembler, and Ghidra extract the app’s IPA file content, including Objective-C classes, method names, and binary files.
Dynamic Analysis (DAST)
If static analysis is studying a castle’s blueprint, dynamic analysis is walking around inside the castle while checking every door and window. We run the app, watch how it behaves, and see if we can exploit any weaknesses in real-time.
Key Areas to Focus On
Network Communication
Make sure your app’s data isn’t leaking during transit. If your app relies on HTTP or improperly configured HTTPS, an attacker can step in, intercept, or even modify the data. The same goes for missing or weak SSL/TLS certificate pinning, exposing your app to man-in-the-middle (MITM) attacks.
Authentication & Authorization
Even if your login screens and user roles look sound on paper, the real test is whether someone can bypass them at runtime. For instance, can an attacker reuse session tokens or guess them? Does the app time out correctly or does it keep sessions open forever?
Runtime Integrity & Security Checks
Many apps try to detect if a device is rooted (Android) or jailbroken (iOS) and then refuse to run or block certain features. During dynamic analysis, you want to see if you can slip past these checks by hooking into the app’s code, so you can keep testing anyway. If you can easily bypass these measures, attackers can, too.
Data Leakage During Execution
Does the app log sensitive information (like passwords or tokens) in plaintext? When you switch apps or background the device, is the screen captured with confidential data still showing? This sort of unintentional “breadcrumb” trail can lead attackers right to the treasure.
API and Server-Side Verification
The app might look secure from a client perspective, but if the backend API doesn’t validate user permissions or input, an attacker could tweak requests on the fly to gain unauthorized access or break the system. It’s crucial to test both the client and server behaviours in tandem.
MSTG Checklist
The Mobile Security Testing Guide (MSTG) also covers dynamic analysis. Here are some checks to keep in mind:
[ ] MSTG-RESILIENCE-1: App detects and prevents tampering or reverse engineering attempts.
[ ] MSTG-RESILIENCE-2: App detects rooted or jailbroken devices.
[ ] MSTG-RESILIENCE-3: App validates the integrity of its code and resources at runtime.
[ ] MSTG-NETWORK-1: App encrypts all network traffic using strong cryptography.
[ ] MSTG-NETWORK-3: App enforces certificate pinning where applicable.
[ ] MSTG-PLATFORM-1: App does not rely on platform security mechanisms alone and enforces security measures independently.
[ ] MSTG-AUTH-2: App properly enforces session timeouts and user re-authentication requirements.
[ ] MSTG-STORAGE-4: App does not log sensitive data to system logs.
[ ] MSTG-STORAGE-5: App does not store sensitive data in an insecure location.
[ ] MSTG-CRYPTO-1: App uses up-to-date cryptographic algorithms for runtime operations.
Think of these like a roadmap for your real-world tests. They help you systematically poke at every door and window to confirm it’s locked down.
DAST Tools
Unlike SAST, which focuses on code inspection, DAST revolves around running the app and checking . Below are popular tools to make that process smoother:
Burp Suite / OWASP ZAP
Use: Both are intercepting proxies that let you capture and modify traffic between the app and backend servers. Ideal for spotting insecure endpoints, session flaws, or data leaks.
Frida
Use: A dynamic instrumentation toolkit that hooks into running processes, helping you bypass SSL pinning, root/jailbreak detection, or other client-side restrictions.
Common Frida Commands
Action | Command |
Attach to a Running Process | frida -U -n <process_name> |
List All Running Processes | frida-ps -U |
Inject a Custom Script | frida -U -n <process_name> -c script.js |
Trace Specific Functions | frida-trace -U -n <process_name> |
Hook a Specific Function | frida -U -n <process_name> --eval 'Interceptor.attach(Module.findExportByName(null, "function_name"), { onEnter: function (args) { console.log(args[0].toInt32()); } })’ |
Drozer (Android)
Use: Focuses on scanning Android components such as Activities, Services, Broadcast Receivers, and Content Providers for security weaknesses.
Common Drozer Commands
Action | Command |
Connect to a Device | drozer console connect |
Enumerate Activities | run app.activity.info -a <package_name> |
Interact with Exported Activities | run app.activity.start --component <package_name> <activity_name> |
Test for SQL Injection | run scanner.provider.injection -a <package_name> |
objection
Use: Built on Frida, but with simpler commands for tasks like disabling SSL pinning or exploring the app’s file system. Perfect if you’re not a scripting guru.
Common Objection Commands
Action | Command |
Attach to a Running App | objection -g <app_package> explore |
Disable SSL Pinning | android sslpinning disable / ios sslpinning disable |
Print Application Info | android application info or ios application info |
Examples
Android
Network Interception & Modification
By routing Android traffic through a tool like Burp Suite, testers can intercept and modify requests. For instance, if the app sends credentials over HTTP or fails to validate TLS certificates properly, an attacker could perform man-in-the-middle (MITM) attacks.
POST /login HTTP/1.1 Host: api.example.com Content-Type: application/json { "username": "test_user", "password": "secret_password" }Session tokens, personal data, or payment info could be exposed or manipulated.
Debug Logs Revealing Sensitive Data
03-09 12:34:56.789 1234 5678 I MyAppLogger: User token = "abc123XYZ987" 03-09 12:34:56.789 1234 5678 I MyAppLogger: Payment info: "card_number=4111111111111111"Anyone with ADB (or a malicious app) could read these logs and exploit them.
Insecure Activities / Content Providers
Output example from drozer tool Using Drozer, testers can discover exported activities or content providers that require no authentication.
drozer console connect run app.provider.query content://com.example.app.provider/usersIf data is returned without proper permissions, attackers can read or modify user info.
Bypassing Root Detection
Tools like Frida or Objection let you bypass root detection or SSL pinning checks at runtime:
frida -U -n com.example.app --eval "..." objection -g com.example.app explore android sslpinning disable android root disable ios sslpinning disable ios root disableAttackers on rooted phones can continue testing or hooking into sensitive functions, revealing secrets or tampering with app logic.
iOS
Jailbreak Detection Bypass
Example of hooking for iOS app Many iOS apps won’t run if they detect a jailbroken phone. With Frida, you can hook and override the detection method:
Interceptor.attach(Module.findExportByName(null, "jailbreakDetectionFunction"), { onEnter: function (args) { console.log("Bypassed jailbreak check!"); // Force return a 'clean' status } });Attackers can run the app on compromised devices and rummage through data or hooks.
Sensitive Data in System Logs
2023-03-09 12:34:56.789 MyApp[1234:5678] Payment info: card_number=4111111111111111 2023-03-09 12:34:56.789 MyApp[1234:5678] session_token=abc123XYZ987On jailbroken devices—or via external log collection—attackers harvest sensitive data directly.
Common Challenges in Mobile Pentesting
Platform Fragmentation: Android devices vary widely in OS versions, custom ROMs, and manufacturer modifications, making testing complex.
Application Security Measures: Features like SSL pinning, root/jailbreak detection, and obfuscation can hinder pentesting.
Limited Access to Source Code: Black-box testing often requires reverse engineering with tools like APKTool or JADX, which can be time-consuming.
Dynamic Analysis Restrictions: Sandboxing, memory protection, and the need for rooted/jailbroken devices complicate real-world workflow tests.
Network Security and Traffic Inspection: SSL pinning, certificate validation, or VPNs might prevent standard MITM proxies. Tools like Frida, Burp Suite, and mitmproxy become essential for bypass.
Frequently Asked Questions (FAQ)
What is mobile pentesting?
It’s testing how secure a mobile app is by simulating real-world attacks—looking for any cracks before the attackers do.
Why is mobile pentesting important?
Because smartphones hold a huge amount of personal and financial data, they are prime targets for cybercriminals.
What are the main steps?
Set up a controlled environment, do static analysis (SAST), do dynamic analysis (DAST), document findings, and retest after fixes.
What tools do I need?
Burp Suite or ZAP for traffic interception, MobSF for scans, APKTool/JADX (Android), Class-Dump/Hopper (iOS), plus hooking tools like Frida or objection.
How often should we pentest?
After major updates, new features, or significant infrastructure changes. Ideally, integrate it into CI/CD for continuous checks.
What are common vulnerabilities?
Insecure data storage, no HTTPS, hardcoded secrets, poor session management, and misconfigured APIs.
Can everything be automated?
Not really. Tools can automate some scans, but manual testing uncovers trickier logic flaws or complex business rules.
Do we need to test both Android and iOS?
Yes, each has unique security models and pitfalls.
Is it legal to pentest?
Absolutely, if you have explicit permission from the app owner. Otherwise, it’s illegal.
Where do I start?
Study the OWASP Mobile Security Testing Guide (MASTG), learn basic reversing, and practice with open-source apps or sample targets.
Conclusion
Mobile pentesting is like a grand quest—you start by gathering gear (tools and devices), then scout the terrain (SAST), and finally take a hands-on approach (DAST) to find every weak spot. By doing this regularly and reporting your findings, you’ll keep your apps solid and your users safe.
Remember: software evolves every day, and so do threats. Make pentesting a continuous part of your development lifecycle—because the best way to secure a kingdom is by never letting your guard down.
About the Author
This article was prepared by Anastasiia Tolkachova, a Security Testing Engineer at Sekurno, and reviewed by Alex Rozhniatovskyi, the CTO of Sekurno.
Anastasiia has over five years of hands-on experience in penetration testing and security assessments. She specializes in testing web applications, infrastructure (both on-premises and cloud), and mobile platforms (iOS and Android). Her expertise spans Black Box, Grey Box, and White Box methodologies, alongside proficiency in vulnerability assessments and source code security reviews.
Alex has seven years of experience in development and cybersecurity. He is an AWS Open-source Contributor dedicated to advancing secure coding practices. His expertise bridges the gap between software development and security, providing valuable insights into protecting modern web applications.
