Mobile application penetration testing
Mobile apps,
tested on device.
A mobile application is a client you handed to your attacker. They can decompile it, instrument it, and watch every call it makes. We test it the same way, on real hardware, including the backend it depends on.
The app is not the boundary. The API is.
Certificate pinning, root detection and obfuscation raise the cost of analysis. They do not stop it, and they are not a security control for your data. Every meaningful mobile finding eventually lands on the server, which is why we test the backend as part of the same engagement rather than selling it separately.
Client, transport,
and backend.
Tested against the OWASP Mobile Application Security Verification Standard, on real devices rather than an emulator only.
01 · Storage
Insecure local storage
Credentials, tokens and personal data written to shared preferences, plist files, SQLite databases, logs and backups. Keychain and Keystore usage checked for the accessibility flags that actually matter.
02 · Transport
Pinning and transport security
Certificate pinning implementation and bypass, cleartext fallbacks, mixed content in web views, and whether the app fails open when pinning fails.
03 · Runtime
Runtime manipulation
Hooking with Frida, patching client side checks, defeating root and jailbreak detection, and confirming which security decisions were left on the device that should have been on the server.
04 · IPC
Platform interaction
Exported activities, services and content providers on Android. URL schemes, universal links and pasteboard exposure on iOS. Deep links that take untrusted input into an authenticated context.
05 · Auth
Authentication and session
Biometric bypass, token storage and lifetime, session invalidation on logout, and whether device binding actually binds to anything.
06 · Backend
The API behind the app
Full API testing as part of the engagement, because that is where the data lives. See the API method.
Seen in the field
What it looks like
in practice.
An illustrative example of the class of issue this engagement is built to find, and what changes after it.
Illustrative example, not client data
BeforeWhat we found
# pull app storage off the device $ adb pull /data/data/com.example.app/shared_prefs $ cat auth.xml <string name="refresh_token"> eyJhbGciOi... </string> <string name="pin">4417</string> # token still valid, no device binding
AfterAfter the fix
# same pull, storage now hardware backed $ adb pull /data/data/com.example.app/shared_prefs $ cat auth.xml <string name="refresh_token"> <encrypted, Keystore bound> </string> # PIN never stored, token bound to device key
Insecure local storage. A long lived refresh token and the user PIN sat in plaintext, readable from any backup or a rooted handset, and the token was accepted from any device. Keystore backed encryption plus device binding removes both halves of the problem.
How we test
a mobile app.
Static analysis to understand it, dynamic analysis to break it, backend testing to prove the impact.
01
Static analysis
Decompile the binary, review the manifest and entitlements, recover hardcoded secrets and endpoints, and map the client side logic worth attacking.
02
Device instrumentation
Install on a real rooted or jailbroken device, hook the runtime, defeat pinning, and observe every request the app makes with full visibility.
03
Client side attacks
Local data extraction, IPC abuse, deep link injection, and bypassing any control the developer left on the device instead of the server.
04
Backend exploitation
Attack the API with the tokens and endpoints recovered, from multiple accounts, to prove what a modified client can actually reach.
Send us the build.
Request a quoteThe usual
questions.
Do you test both iOS and Android?
Yes. They are scoped as separate targets because the platform attack surface genuinely differs, though they usually share a backend which is tested once.
Do you need the source code?
No, we can test a compiled binary. Source access makes the review deeper and is worth providing if you can, but it is not required to start.
Do you test on emulators or real devices?
Real devices for the dynamic work. Emulators miss hardware backed keystore behaviour, biometric flows and some pinning implementations, which are exactly the areas worth testing.
Our app uses certificate pinning. Can you still test it?
Yes, and we will show you how quickly it comes off. Pinning is a speed bump for an attacker with the device in hand, which is the correct threat model for a mobile client.
Is the backend API included?
Yes. Testing the client without the server would miss the findings that matter. Full API testing is part of the mobile engagement.
Related
Where to
go next.
Send us the build.
A senior operator replies within one business day. No sales pipeline, no bot.