Your app refuses to run on an emulator. We find out how true that is.
Most mobile penetration tests spend their budget on storage, crypto, network and API findings, then tick the anti-tampering box with a stock emulator and an off-the-shelf hooking tool — the two things your app is already built to spot. TajApps tests only the layer everyone skims, using a device built specifically to get past it.
Why the resilience layer gets tested badly
OWASP MASVS separates resilience (MASVS-RESILIENCE) from the rest of the standard for a reason: it's the control group that decides whether every other control can be trusted at runtime. It is also the group that generic testing handles worst, for a simple reason — testing it properly requires an environment your app cannot detect, and building one of those is a multi-month engineering problem, not a tool you install.
So the finding you usually get back is "root and emulator detection present, functioning as designed." Which is true of the stock emulator the tester used, and tells you nothing about the attacker who spent a weekend on it.
Two ways to engage
Detection Audit
1 Android app · 5 business days
- We attempt to launch and operate your shipping build on a de-emulated device
- Control-by-control result: which integrity checks fired, which stayed silent, in what order
- Screen recording of the exact point each control triggered — or didn't
- Severity-ranked findings memo, 6–10 pages
- 30-minute engineer-to-engineer debrief
- Fee credited in full against a Resilience Assessment booked within 60 days
Resilience Assessment
1 Android app · 2–3 weeks
- Everything in the Detection Audit, taken to the end of the chain
- Full documented bypass path — every step, reproducible, with the effort each cost
- Coverage across the resilience surface: emulator, root, debugger, hooking, repackaging, pinning, RASP behaviour, attestation handling
- Server-side trust review: what your backend accepts on a client's word
- Prioritised remediation guidance, written for engineers, ranked by attacker-cost gained per hour of work
- Reproducible device image so your team can replay every finding
- Executive summary suitable for a board or a customer security review
- One round of re-testing after your fixes, with an updated report
Resilience Retainer
Per-release · rolling
- Re-test of the resilience surface on every release, or monthly
- Regression alerts when a hardening control silently stops working
- Standing access to a Privara device for your own QA and fraud teams
- Advisory line to our engineers on hardening decisions before you build them
- Priority scheduling ahead of one-off engagements
Prices in USD, excluding tax. Multi-app, iOS, backend-API and full MASVS-scope engagements are quoted after scoping. Every engagement is fixed-price and agreed in writing before work begins.
What we actually test
- Emulator and virtual-device detection
- Root and superuser detection
- Debugger and tracing detection
- Hooking and instrumentation defences
- Repackaging and signature verification
- Certificate and public-key pinning
- RASP / app-shielding SDK behaviour
- Play Integrity verdict handling
- Obfuscation efficacy in practice
- Device-fingerprint stability and reset behaviour
- Locale, time-zone and geolocation trust
- Sensor and hardware-profile trust
- Secure-storage and keystore assumptions
- Server-side enforcement of client claims
- Failure modes: what happens when a check errors
- Onboarding, KYC and liveness device gates
The last two matter more than teams expect. A great many hardening failures aren't a control being beaten — they're a control returning an error, timing out, or being evaluated client-side, and the app quietly deciding to let the user through. We look for that specifically, because it's cheap to exploit and cheap to fix.
How an engagement runs
- Scope and authorise. A short call, then a fixed-price statement of work and a written authorisation to test naming the app, package ID, build, dates and the person authorising it. Nothing starts before that's signed.
- Baseline. We establish how your app behaves on a stock emulator and on a clean physical-equivalent device, so every later result has something to be measured against.
- Escalate. We work up the ladder — de-emulated device, then hidden root, then instrumentation, then repackaging — recording precisely where each control stops us and what it costs to get past. Effort is tracked per step, because that number is the finding.
- Report. Findings ranked by attacker-cost reduction, each with reproduction steps, evidence, and a specific remediation. Plus an executive summary that a non-engineer can act on.
- Debrief and re-test. A working session with your engineers, then — on the Resilience Assessment — a full re-test after your fixes and an updated report you can show a customer or a regulator.
Who buys this
- Fintechs, banks and payment apps whose fraud losses depend on device-integrity controls actually holding.
- Identity-verification and RegTech vendors who need to state, with evidence, how their SDK behaves under a determined attacker — and whose customers now ask.
- Games and apps with anti-cheat or anti-abuse where a working bypass spreads in days once it exists.
- Marketplaces and social platforms fighting automated account creation at the device layer.
- RASP and app-shielding vendors who want independent, adversarial validation of their own product rather than their own test suite.
- Any team facing a customer security questionnaire that asks how anti-tampering was verified, and by whom.
What this is not
We'd rather scope this out now than in week two. This is not a full-breadth MASVS or MASTG assessment by default — API, backend, cryptography and storage testing are available, but they are scoped and priced separately rather than smuggled into a resilience engagement and done thinly. It is not a compliance certificate; it is evidence you can put in front of an auditor, not a stamp. It is not a claim that we defeat hardware-backed attestation, because no virtual device does — what we test is how your app handles attestation, which is where the real defects usually are. And we do not test apps a client doesn't own or isn't contractually entitled to have tested, under any circumstances.
Prefer to run it yourself?
The same device we test with is available as a product. If you have the in-house skill and would rather build this into your own CI and red-team practice, licence Privara directly — as a malware-analysis and pentest environment, as a rig for testing your own KYC and anti-fraud flows, or see per-device pricing. Plenty of teams start with an audit and move to a licence once they know what to look for.
Start with the $5,000 audit
Five business days, fixed price, and the fee comes straight off a full assessment if you book one within 60 days. The fastest way to find out whether your hardening does what the last report said it did.
Email support@tajapps.com →