Read the binary the way an attacker does - before it ships.
Mobexa decompiles and inspects the exact APK, AAB or IPA your pipeline produces - bytecode, native libraries, manifest, resources and signing - and reports the weaknesses an attacker finds by pulling the app off a device. No source access. No agent in your build. No waiting for a pentest window.
Six layers of a shipped app, parsed in one pass
An installed mobile app is far more than your code. Mobexa takes the whole package apart and treats every layer as attack surface.
Bytecode & logic
Decompiled DEX and Kotlin/Java classes, including merged third-party SDKs and obfuscated paths your source tree never shows.
Native libraries
Bundled .so binaries inspected for exported symbols, embedded strings and risky calls that bypass managed code.
Manifest & components
Exported activities, services and receivers, permission posture, deep links, debuggable and backup flags, and cleartext-traffic policy.
Resources & assets
Strings, config files, certificates and pinning material, plus packed bundles from cross-platform frameworks.
Signing & build
Signature scheme, certificate details and build configuration that decide whether the artifact can be tampered with or re-signed.
Embedded secrets
API keys, tokens, cloud credentials and connection strings baked into code, resources or native blobs, each confirmed by structure.
From artifact to evidence in five stages
Every build follows the same deterministic path, so two scans of the same binary always agree - a property your auditors and your CI gates both depend on.
Submit the artifact
Upload through the dashboard or push from CI. The exact build you ship is the exact build that gets scanned.
Unpack & normalize
Decompile, extract native code, parse the manifest and index every resource into a queryable model.
Rules, heuristics & deterministic checks
Signature rules and structural checks run together - some weighted, some absolute - across the whole model.
Correlate & deduplicate
Related signals collapse into one finding with a single owner, so a key reused in three files is one ticket, not three.
Map, score & export
Each finding is scored, mapped to MASVS and emitted as SARIF plus a signed evidence record.
// one finding, as it exports to your code-scanning dashboard { "ruleId": "android.cleartext.firebase-credential", "level": "error", "severity": "critical", "detectionMethod": "deterministic", "confidence": "confirmed", "masvs": "MASVS-STORAGE-1", "location": { "artifact": "res/values/strings.xml", "symbol": "google_api_key" }, "evidence": "AIza••••••••••••••••••••••3kQ", "validated": true }
Findings a CTO can act on
Each result names the rule, the place in the artifact, the redacted evidence, the confidence level and the standard it maps to. Confirmed findings are flagged as facts; weighted ones are flagged as leads. Your engineers see exactly what was found and where, and your auditors get a signed record they can cite.
- SARIF output drops into GitHub code-scanning, GitLab and any SARIF-aware tool.
- Severity and MASVS mapping on every finding, ready for triage and SLA timers.
- Redacted evidence proves the issue without leaking the live secret into a report.
Some exposures are too important to be a maybe
For the classes of finding that get apps breached, Mobexa confirms by structure instead of guessing by pattern. These reach triage already validated.
Live cloud credentials
AWS, GCP and Azure keys checked for shape and origin, not just format - so a live key is a confirmed key.
Exposed Firebase config
Open databases, storage buckets and API configuration that turn a mobile build into a backend door.
Play Integrity posture
Whether the app actually asserts device and app integrity, or only claims to.
RN & Flutter secrets
Credentials hidden inside React Native bundles and Flutter blobs that source scanners walk straight past.
Designed against false positives
These deterministic checks were validated to zero false positives on a production banking app before release. A finding that wastes an engineer's afternoon is worse than no finding at all, so confirmed exposure and probable exposure are never presented as the same thing.
Static analysis, answered plainly
Do you need our source code to run static analysis?
No. Mobexa analyses the compiled artifact - the same APK, AAB or IPA your build pipeline produces. It decompiles bytecode, unpacks native libraries and parses the manifest and resources, which is exactly the material an attacker works from after pulling the app off a device. You get the attacker's view without handing over your repository.
How is this different from a linter or a build-time SAST tool?
Source linters reason about code you wrote. Mobexa reasons about the binary you shipped - including third-party SDKs, merged manifests, obfuscated classes and native code that never appears in your source tree. That is where most real mobile exposure lives, and it is invisible to source-only tooling.
What does a static finding actually contain?
Every finding carries the rule that fired, the file and location in the decompiled artifact, the evidence snippet, a severity, and the MASVS control it maps to. Findings export as SARIF so they drop straight into code-scanning dashboards and ticketing.
How do you keep false positives down?
Pattern rules are paired with deterministic checks for high-signal classes of exposure - live cloud credentials, exposed Firebase configuration, Play Integrity posture and secrets bundled by React Native and Flutter packers. These are confirmed by their structure, so they reach triage as facts rather than leads.
See what a static scan finds in an app you already ship.
Send us one APK, AAB or IPA. We will return a complete static report - findings, evidence and MASVS mapping - against your real code.