Deutsch: această pagină nu e încă tradusă. Textul de mai jos e în English.
Unlike a web application, a mobile app physically lands on the attacker’s territory. It runs on a phone they fully control: they can root it, decompile the binary, read what the app writes to disk and instrument its functions while it runs. The wrong assumption we find most often is that client-side protections — certificate pinning, root detection, obfuscation — are impenetrable. They aren’t; we bypass them routinely. The real question is what remains exposed once they’re bypassed.
Three targets, tested together
A mobile application is the code on the device, the data stored locally and the backend API. The most severe issues appear at the boundaries between them — for example, a backend that checks permissions only in the app, assuming nobody will call the API directly. That’s why the backend API receives a full web/API test, not a passing glance.
What we test (OWASP MASVS)
- Storage — sensitive data in preferences, SQLite databases, logs, screenshots and backups; correct (and frequently incorrect) use of Keychain / Keystore
- Cryptography — weak algorithms, hardcoded keys found through reverse engineering, poor key management
- Network — TLS validation and, in particular, the presence and bypass of certificate pinning
- Platform and IPC — exported components, deep links and URL schemes, WebView with
addJavascriptInterface, insecure intents and broadcasts - Resilience — root/jailbreak detection, anti-debugging, obfuscation, RASP, integrity checks — and, more importantly, whether they can be bypassed with Frida or through repackaging
- Privacy — what personal data the app collects and leaks, including to third-party SDKs
How we work
We combine static analysis (decompiling the APK and IPA, searching for secrets, endpoints and hidden logic), dynamic analysis (instrumentation with Frida/Objection on a rooted device or emulator, hooking functions and bypassing controls) and full backend testing. On Android we decompile; on iOS we analyse the binary at runtime or request the source. The methodology follows OWASP MASVS 2.0 and the MASTG guide, at MAS-L1 (baseline) or MAS-L2 — defence in depth, mandatory for banking and healthcare applications.
What you get
- Executive summary + findings with CVSS scores, clearly split across the three planes: application, on-device storage, backend APIs
- Evidence and reproduction steps on the specific platform and device
- Prioritised remediation, retesting after fixes and a presentation session