
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 ensure that the 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!
We live in a world where mobile devices are almost an extension of ourselves. Because people do their banking, shopping, and socializing on phones, ensuring app security is paramount. 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:
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.
Picture a medieval fortress—these are the typical “weak spots” attackers target:
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.
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.
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.
Android Emulator
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.
Android Rooting is like finding a skeleton key to your phone’s operating system. Typically, you’ll:
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
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!
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.
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.
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:
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.
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.
Setting up your environment properly—choosing the right devices (virtual or physical), configuring proxies, and understanding how to sideload apps—ensures 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!
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.
Hardcoded Secrets
API keys, tokens, credentials, and encryption keys sometimes end up directly in the source code. If attackers reverse-engineer the app, they can pluck these secrets out with minimal effort and impersonate users or services.
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
Often, the root issues come from how features are implemented. When essential checks—like authentication—are missing or not strictly enforced, attackers can easily bypass your defenses. Similarly, weak cryptographic functions or unsecured app components can also make life easy for anyone probing your app.
The Mobile Security Testing Guide (MSTG) offers a thorough checklist to help you tackle static analysis methodically:
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_director
JADX (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_directory
Class-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.
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.
<application android:debuggable="true" />
Anyone with a device (or emulator) can attach a debugger and rummage through sensitive data or logic.
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.
<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.
<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.
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.
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.
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.
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 |
|
List All Running Processes |
|
Inject a Custom Script |
|
Trace Specific Functions |
|
Hook a Specific Function |
|
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 |
|
Enumerate Activities |
|
Interact with Exported Activities |
|
Test for SQL Injection |
|
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 |
|
Disable SSL Pinning |
|
Print Application Info |
|
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.
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
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/users
If data is returned without proper permissions, attackers can read or modify a user’s info.
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 disable
Attackers on rooted phones can continue testing or hooking into sensitive functions, revealing secrets or tampering with app logic.
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.
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=abc123XYZ987
On jailbroken devices—or via external log collection—attackers harvest sensitive data directly.
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?
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.
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.
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.