Mobile App Reverse Engineering & Anti-Tamper Assessment
What an attacker learns from your APK or IPA: exposed secrets, discoverable endpoints, client-side trust assumptions that the server should be enforcing, and an honest assessment of how much your anti-tamper posture actually buys you.
Verified Solvex Specialist
Verified by SolvexDirect specialist contact for Solvex engagements
What this means. An authorized Solvex administrator registered and approved this exact public identity. What it does not. Solvex has not inspected the account on the platform, and this is not the platform's own verification.
Solvex specialists never ask for your passwords, recovery phrases, one-time codes, or payments to a personal account. Work, scope and invoices are agreed in writing through the official channels on this site.
Signed authorization required. This engagement is performed only against systems you own or are contractually authorized to have tested, under an agreed scope. See the responsible testing policy.
What's covered
- APK and IPA structure, resources and build configuration analysis
- Embedded secret discovery: keys, tokens, endpoints and credentials
- API endpoint enumeration from the client binary
- Client-side trust analysis — what the app decides that the server should
- Anti-tamper, obfuscation and integrity-check assessment
- Root and jailbreak detection review, and its realistic value
- Certificate pinning implementation and bypass resistance
- Local storage and cache exposure review
What you receive
- Reverse engineering assessment with severity-ranked findings
- Extracted secrets and endpoint inventory with rotation guidance
- Client-side trust findings, mapped to the server controls that should replace them
- Anti-tamper posture assessment with realistic expectations
- Prioritised remediation plan
Evidence and reporting
How the work is kept honest- Evidence, frozen at issuanceFindings tie to something observed. When the report is issued, the evidence behind it is frozen in the same transaction and cannot be edited afterwards.
- A signed reportAn Ed25519 signature covers both the report content and the delivered file. Alter a byte of either and verification fails.
- Signed scope firstTesting starts only after written scope and signed authorization for systems you own or are entitled to have tested.
Anyone holding a Solvex report can verify it publicly without seeing its contents.
Our boundaries
What this engagement does not do, stated before it starts.
- Written authorization required — your app, or documented permission
- No account takeover, no attacks on other users, no production data access
- Client-side protections raise cost and cannot be made absolute; we will not claim otherwise
- Backend testing is a separate engagement unless explicitly included
How this engagement runs
- 01
Intake
Tell us the system, the goal and the constraints. If the work is not a good fit, we say so before anyone is invoiced.
- 02
Scope and authorization
Written scope and signed authorization before anything is touched. Security testing runs only against systems you own or are contractually entitled to have tested.
- 03
Investigation or build
Specialists matched to the work. Findings are proven by hand — scanner output is a lead, never a finding.
- 04
Evidence
Every finding ties to something observed. When a report is issued, its evidence is frozen in the same transaction, so what backed the report cannot change afterwards.
- 05
Delivery
A signed report: an Ed25519 signature over both the content and the file, with a short verification reference you can read down a phone.
- 06
Verification and retest
Anyone holding the report can verify it publicly without seeing its contents. Fixes are retested as part of the engagement — “fixed” means we confirmed it.
Questions we are asked
- Is obfuscation worth paying for?
- It buys time against casual analysis and is close to worthless against a determined analyst. It is worth having, and it is not a control. If your security depends on nobody reading the binary, you have a server-side authorisation problem wearing an obfuscation costume.
- We found our API keys in the app. How bad is that?
- Depends entirely on what the key authorises. A key scoped to public read is a nuisance; a key that can write, spend or read other users' data is an incident. Any secret shipped in a client should be treated as public — the fix is scoping and server-side authorisation, not better hiding.
- Does root detection actually help?
- Against opportunistic misuse, somewhat. Against anyone using standard tooling, it is a speed bump that is routinely bypassed. It is reasonable defence in depth and a poor foundation, and we will tell you which of those you are relying on.
Related services
Offensive / Testing
Mobile Application Penetration Testing
Your mobile app runs on devices you don't control. We test iOS and Android builds for insecure storage, weak crypto, and backend flaws, covering the app, its APIs and the data it leaves behind.
Engineering
Secure Mobile App Development & Hardening
Native or hybrid mobile engineering for applications that handle money, identity or sensitive data — built against an explicit mobile threat model, with anti-tamper posture, secure update strategy and release hardening designed in.
Reverse Engineering
Authorized Software Reverse Engineering
Structured analysis of software you own or are authorized to examine — understanding an undocumented binary, an inherited system with no source, a protocol you must interoperate with, or the behaviour of a dependency you cannot audit any other way.