Local data storage
Databases, preferences, caches, logs and temporary files examined on a rooted or jailbroken device — including the personal data written to logs during error handling.
Application Security
Once your application is installed, it is running on hardware controlled by someone else. Assume the user is rooted, the traffic is intercepted and the binary has been pulled apart — because for the attackers who matter, all three are true.
Mobile applications are built by teams who are used to controlling the runtime. On a server you decide what executes. On a phone you ship a binary to a stranger and hope. Anything you put in that binary — an API key, a signing secret, an encryption key, a feature flag that unlocks premium functionality — is available to anybody who cares to look, and pulling apart an APK is a fifteen-minute job for someone with the right tools.
The pattern we see repeatedly is validation performed in the app and trusted by the server. The application checks that the amount is positive, that the coupon is valid, that the user has a subscription — and the API accepts whatever arrives. Remove the app from the equation, speak to the API directly, and every one of those checks disappears.
So a mobile assessment is really two assessments. One looks at the application on the device: what it stores, what it logs, how it protects its own traffic, and what falls out of the binary when it is decompiled. The other looks at the backend the way a modified client would — which is where most of the severe findings end up.
Coverage
Coverage follows the OWASP Mobile Application Security Verification Standard and the associated testing guide.
Databases, preferences, caches, logs and temporary files examined on a rooted or jailbroken device — including the personal data written to logs during error handling.
Key generation and storage, use of Keychain and Keystore, hardcoded keys, and homegrown encryption where a platform primitive should have been used.
Transport configuration, certificate validation, certificate pinning and whether that pinning survives a determined attempt to remove it.
Token storage and lifetime, biometric implementation, background and lock behaviour, and whether a session survives a device compromise.
Exported components, deep links, custom URL schemes, clipboard behaviour, screenshot and backup exposure, and inter-process communication.
Obfuscation, anti-tampering, root and jailbreak detection, and debug functionality left in a release build.
Static analysis of the decompiled application for secrets, endpoints, hidden functionality and business logic that should never have been client-side.
The services the application talks to, tested as an API in their own right — usually where the highest-severity findings are.
Approach
Typically six to ten working days per platform, depending on the size of the application and whether the backend is in scope.
Builds for each platform, test accounts at every privilege level, and a walkthrough of what the application is for.
The binary is decompiled and examined for secrets, endpoints, debug artefacts and hardcoded logic, alongside automated analysis across the relevant language packs.
The application is run on instrumented rooted and jailbroken devices, with storage, logging, memory and inter-process behaviour observed under real use.
All network communication is inspected, including whatever protections exist against inspection.
The API is tested independently of the app, with client-side controls deliberately bypassed.
Findings split by platform and by layer, with a free retest once fixes are released.
Deliverables
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Android and iOS reported separately, because the fixes usually are.
The secrets, endpoints and logic we recovered from the binary, shown as recovered.
Which verification requirements were met at the level you are targeting.
API issues reported as API issues, with the client-side control that was supposed to prevent them noted.
Verification against the fixed build once it is available.
Is this for you?
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping callHow we work
The same engagement model applies to every piece of work we take on, so you always know what happens next.
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
The questions clients actually ask during scoping. If yours is not here, ask it directly.
No. We test the compiled application the way an attacker would, which means decompiling the binary you actually ship. Source access is welcome and makes the review deeper — we can combine it with a secure code review — but it is not required, and testing without it is a more honest simulation of the real threat.
Both. Emulators are efficient for repeatable analysis, but some behaviour only appears on physical hardware — biometric flows, hardware-backed key storage, and certain platform protections. We use rooted and jailbroken physical devices for the parts that require them.
It should be, and we recommend scoping it in. The majority of high and critical findings in mobile engagements are in the API rather than the app, because that is where the real authorisation decisions are made. If the backend is genuinely out of scope we will say so clearly in the report so nobody mistakes a limited test for a complete one.
Yes. Obfuscation raises the effort required, it does not prevent analysis, and root detection is routinely bypassed. Both are worth having — they filter out casual attackers — but they are speed bumps, not controls. The test tells you what an attacker finds after they get past them, which is the question that actually matters.
Six to ten working days per platform for a typical application, plus reporting. Testing both Android and iOS together is more efficient than two separate engagements, since the backend work is shared.
Next step
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.