What we still need to verify : 4 points in this profile are not yet confirmed against vendor documentation.
- Exact attack catalog and how results are scored: confirm against vendor docs
- Device fleet composition and OS coverage: unconfirmed
- CI/CD integration surface and API availability: unconfirmed
- On premises deployment availability: unconfirmed
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
esChecker comes from eShard, a vendor whose background is in hardware and software security evaluation, and the product reflects that lineage. Rather than scanning a build for coding weaknesses, it attacks the build. You submit a mobile application, and the service installs it on real devices and runs a catalog of adversarial techniques against it: rooted and jailbroken environments, debugger attachment, dynamic instrumentation and hooking, repackaging and resigning, and interception of the app's traffic. The output is an assessment of which of those attacks the application resisted and which it did not.
That framing makes it a validation tool for protection rather than a discovery tool for bugs. If your app ships obfuscation, anti tampering and runtime self protection, the question that matters is whether those controls actually stop an attacker, and the honest answer is only available by trying. Running the same catalog on each release also turns protection into something you can regression test, which is otherwise very hard to do.
Where it fits
This sits late in the release process, after protections have been applied to the build, and is owned by a security team rather than by developers. It is most useful to organizations that have already decided hardening matters and now need evidence, including evidence for external reviewers or certification bodies that expect resistance testing rather than a checklist. It presumes you have something to test: running it against an unprotected app will tell you, accurately and unhelpfully, that everything works.
Strengths
- Tests resistance empirically by running real attack techniques, which is a different and harder question than whether a control is present.
- Repeatable across releases, so a protection regression caught by a build change becomes visible instead of being discovered by an attacker.
- Real device execution avoids the emulator artifacts that make on device checks behave differently than they will in the field.
Limitations
- Narrow by design. It does not look for application logic flaws, insecure storage patterns, weak cryptography or backend API weaknesses, so it cannot be your only mobile testing.
- An automated attack catalog is a floor, not a ceiling. Passing does not mean a determined human analyst with time will fail.
- I could not verify the integration and deployment surface, so teams needing pipeline automation or an on premises option should confirm that directly.
Who it suits
Organizations that ship hardened mobile apps and need evidence the hardening works: banking, payments, identity and anything facing a certification scheme with resistance requirements. Teams without runtime protections in place have nothing here to measure yet.
Used esChecker? Recommend it under your own name and title.
Recommend this tool