Local storage
What is left behind on a phone that is lost, sold or seized.
- Tokens and credentials in preferences or plists
- Keychain and Keystore use and protection class
- Databases, caches and logs
- Screenshots and clipboard leakage
An app on a customer’s phone is running on hardware you do not control, in the hands of someone who may want to take it apart. Protonyte tests Android and iOS applications against the OWASP Mobile Application Security Verification Standard: what the app stores, what it sends, what it accepts back, and what it still does once the phone is rooted and the pinning is gone.
Most of what a mobile application is worth attacking for sits in two places: on the device, and in the API behind it. The screens in between are only a way of reaching them.
So the test runs on both sides at once. Statically, we take the package apart and read what shipped inside it - keys, endpoints, debug flags, third-party SDKs. Dynamically, we run it on a rooted Android device and a jailbroken iPhone, defeat the certificate pinning, and watch every request it makes. An app that trusts the phone it is running on is an app that trusts an attacker.
The structure follows the OWASP Mobile Application Security Verification Standard and its testing guide, across both platforms.
What is left behind on a phone that is lost, sold or seized.
A release build is a file anybody can download and open.
Everything between the app and your server.
How the app proves who the user is, and for how long.
The parts of Android and iOS an app can hand away by accident.
Tested as its own surface, because that is where the data is.
We agree the platforms, the build to test and the accounts, and ask for a build that is as close to release as possible.
The package is unpacked and read before it is ever run.
On a rooted device and a jailbroken phone, with the traffic in front of us.
The server is tested as its own target, using the app only to learn how to talk to it.
One report covering device and server, then a free retest.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows OWASP MASVS, OWASP MASTG, OWASP Mobile Top 10 and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our penetration testing service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
No. We test the compiled app the way an attacker gets it, from the store or from a build you send us. If you do give us the source we will use it, and the test goes deeper for the same money, but it is never a requirement.
Real devices, rooted Android and jailbroken iOS, plus an emulator where it is useful. Several protections behave differently on real hardware, and a test that only ran in an emulator will miss them.
It stops a casual attacker, which is exactly why it is worth having. It does not stop a test: pinning is removed at runtime so we can see the traffic, and part of the report is how much effort that took and how to make it take more.
The API the app talks to is in scope by default, because that is where most serious mobile findings actually live. A separate web portal on the same backend is a separate test; we will say so during scoping rather than after.
No. We test with accounts you create for us, against whichever environment you choose, and we do not run destructive techniques. If the only environment is production we agree a window and the rules first.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.