Yaamlabs
Offensive Security

Mobile Application Penetration Testing

iOS and Android builds, the data they leave on the device, and the APIs behind them, tested on rooted and jailbroken hardware against the build you are about to ship.

A mobile app is three attack surfaces under one icon: the binary you shipped, the data it leaves on the device, and the backend it talks to. The client is not a security control. Anyone can pull the app off a device, unpack it, read what it stored, and replay its traffic once certificate pinning is bypassed. What matters is what the server still trusts after that.

We test all three surfaces on real rooted and jailbroken hardware, not an emulator alone, against the build you are about to release. Static analysis of the binary, runtime instrumentation to watch what it does with its data, and the backend API tested independently of the client. Findings arrive with the exact device, tooling and steps needed to reproduce them, written by the engineer who found them.

Usually, one of these is true

  • You are about to publish a first release, or a major update that changes login, payments, or how the app stores data.
  • The app handles health records, financial data, or anything that brings it under HIPAA, PCI DSS or a customer's security review.
  • An app store review, an MDM rollout, or an enterprise buyer wants evidence the build has been tested independently.
  • You have added biometric login, certificate pinning, or a payment SDK, and want to know whether it holds up on a rooted or jailbroken device.

What we test

We test the shipped build on both platforms where you support them, on hardware we control, plus the backend it depends on. Source code helps and we will use it, but we do not need it: we can reconstruct enough from the binary to test properly.

  • Static analysis. The binary and its dependencies: hardcoded secrets and API keys, debug flags, weak crypto, and what the manifest and entitlements actually permit.
  • Local storage. Keychain and Keystore use, cached responses, databases, logs, screenshots and backups: everything that survives the app being closed.
  • Runtime instrumentation. Hooking on rooted and jailbroken devices to observe and change what the app does with its data once the interface is out of the way.
  • Transport security. Certificate pinning and its bypasses, TLS configuration, and what the app accepts once pinning has been removed.
  • Platform and IPC. Exported components, custom URL schemes, deep links, intent handling, and anything another app on the device can call.
  • Backend API. The API the app depends on, tested independently of the client, since the client cannot enforce a control the server does not.

How the test runs

Five stages, agreed in writing before anything starts. One named engineer, one shared channel, findings as they are confirmed.

  1. Scope. We agree platforms, the build to test, accounts, devices and an abort path in writing, then sign rules of engagement. Nothing is touched before that.
  2. Unpack. We install the build on rooted and jailbroken hardware, unpack the binary, map its dependencies and entitlements, and set up interception and hooking.
  3. Test by hand. Static, runtime and network testing on the device, plus the backend API on its own. A finding is confirmed by reproducing it, not by a scanner rating.
  4. Report live. Confirmed findings reach your channel with the device, tooling and steps to reproduce them as they land. Anything critical is reported within the hour.
  5. Retest. Once fixes ship we re-run the affected tests on the updated build, confirm what closed, and issue a letter of attestation.

What you get

  • Findings report. Each issue with a reproduction on a device you own, the affected platform, a CWE mapping and a CVSS v4.0 rating, written by the tester.
  • Executive summary. A short account of what was tested across both platforms and the backend, and what it means, for people who will not read the technical detail.
  • Platform-specific remediation. Fixes written for iOS and Android as they actually behave, not generic advice that ignores Keychain, Keystore or the platform sandbox.
  • Live channel access. Direct contact with the engineer throughout, so questions about a device, a build or a finding are answered as they arise.
  • Retest and attestation. A second pass over the fixed build and a letter of attestation for your app store reviewers, customers and auditors, included.

What we need from you

  • The build to test, as an IPA and APK or through TestFlight and a Play internal track, matching what you will release.
  • Test accounts at each role, and any second-factor or device-enrolment steps needed to reach the logged-in app.
  • Backend API documentation where it exists: an OpenAPI or Swagger file, a Postman collection, or example requests and responses.
  • A named technical contact who can issue builds, reset accounts and answer questions while testing runs.
  • Written authorisation to test, and confirmation of anything out of scope, such as third-party SDKs or production data.

What we can show you

  • Research, not only testing. 70+ CVEs published by our researchers, with research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense. That reversing and platform-internals work goes into your app.
  • The tester writes the report. No account-manager layer and no junior bench. The engineer who reverses the binary writes the report, so platform detail is not lost to a report writer.
  • The fix comes with the finding. One team runs testing, hardening and mobile engineering, so a finding can become a fix without a hand-over, and the retest and attestation are part of the engagement.
  • Your name stays yours. Mutual NDA and PGP before you send a build. Evidence stays encrypted and least-privilege, and is destroyed after the retest on request. Client names stay undisclosed.

Standards we work to

We structure the work against the public mobile methodologies your reviewers recognise, so the report maps onto the framework you report into without translation.

  • OWASP MASVS
  • OWASP MASTG
  • OWASP Mobile Top 10
  • OWASP API Security Top 10
  • CWE
  • CVSS v4.0

Common questions

Do you need our source code?

It helps and we will use it if you share it, but we do not need it. We can reconstruct enough from the binary to test static, runtime and storage behaviour. Source code mainly saves time and lets us point remediation at the exact line rather than the observed behaviour.

Do you test on real devices or emulators?

Real rooted and jailbroken hardware. Pinning bypasses, Keychain and Keystore behaviour, biometric flows and anti-tampering checks do not behave the same on an emulator. We use emulators only where they add nothing to a specific finding.

Do you test the backend as well, or just the app?

Both. The API the app depends on is tested independently of the client, because the client cannot enforce a control the server does not. If the backend is large enough to be its own engagement, we say so during scoping rather than skimming it.

Can you get past certificate pinning and root or jailbreak detection?

We assess whether pinning and root or jailbreak detection can be bypassed, because a determined attacker will try, and then we test what the app and its API do once that protection is gone. Where they hold, you get evidence that they hold.

Will this satisfy an app store review or a customer's security questionnaire?

The report gives you tested evidence mapped to OWASP MASVS, with findings, CVSS v4.0 ratings and a retest confirming fixes, which covers what reviewers and questionnaires ask for. We do not issue certifications. We produce the testing and work alongside whoever signs off.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.